Chronicle Labs LTIPP Application FINAL
Provide personal or organizational details, including applicant name, contact information, and any associated organization. This information ensures proper identification and communication throughout the grant process.
Applicant Name: Jen Senhaji
Project Name: Chronicle Labs
Project Description:
Chronicle Protocol is a novel Oracle solution that has exclusively secured over $20B in assets for MakerDAO and its ecosystem since 2017. With a history of innovation, including the invention of the first Oracle on Ethereum, Chronicle Protocol continues to redefine Oracle networks. Chronicle overcomes the current limitations of transferring data on-chain by developing the first truly scalable, cost-efficient, decentralized, and verifiable Oracles, rewriting the rulebook on data transparency and accessibility
Team Members and Roles:
Nik Kunkel - Founder
Jen Senhaji Head BD & Growth
Project Links:
Website
Oracle Dashboard
https://twitter.com/ChronicleLabs
Github
Documentation https://docs.chroniclelabs.org/
Contact Information
Point of Contact Jen Senhaji
Point of Contact’s TG handle: @ jensenhaji
Twitter: @ jensenhaji
Email: jenn@chroniclelabs.org
Do you acknowledge that your team will be subject to a KYC requirement?: Yes
SECTION 2a: Team and Product Information
Provide details on your team’s past and current experience. Any details relating to past projects, recent achievements and any past experience utilizing incentives. Additionally, please provide further details on the state of your product, audience segments, and how you expect incentives to impact the product’s long-term growth and sustainability.
Nik Kunkel, Founder of Chronicle, co-developed the first on-chain Oracle in 2017 to facilitate the creation of SAI (a single-collateral stablecoin). Many iterations later, Chronicle Protocol remains the steadfast guardian of assets within MakerDAO. At times, this responsibility extended to securing over $20 billion, enabling Maker to solidify its role as the leading DeFi protocol and the largest on-chain lender in the space.
**Team experience (Any relevant experience that may be useful in evaluating ability to ship, or execution with grant incentives. Please provide references knowledgeable about past work, where relevant. If you wish to do so privately, indicate that. [Optional, but recommended]): **
Chronicle Protocol - Cost-Efficient, Verifiable Blockchain Oracles
The full team includes 15 full time contributors with the majority of the team transitioning from MakerDAO to Chronicle including the Founder, BD/Growth & Engineering. The team collectively has decades of experience across research and solidity contract auditing, a former founder of a cryptography security firm and engineering experience from AWS, Craigslist, Blockscout, Mycelium, Blockdaemon, Spearbit, and Consensys.
The first version of Chronicle went live in May of 2017 as the in-house Oracle infrastructure built exclusively for MakerDAO to launch DAI. This was before any other Oracle provider was fully live in production, so out of necessity, Maker built its own Oracle infra in order to launch its main product, a decentralized stablecoin. Since then, Chronicle has secured Maker and spun out as its own team, brand and service, under the name Chronicle, late in 2023. It is now, for the first time, available to all EVM applications and chains. The uniqueness of Chronicle is that while it is a newer brand, it’s actually the 1st Oracle launched on Ethereum, battle-tested with years of experience securing billions in TVL ($22B peak).
Oracle landscape:
There is a lack of shared knowledge on how Oracle protocols are designed and what they cost to operate. Importantly, all Oracle protocols are not created equal and as a builder selecting an Oracle to use in their protocol, the design tradeoffs are usually not fully considered. Accessibility of what assets are supported and cost to use the Oracle are usually the key considerations, while left unexamined; who are the validators (is it a centralized set up or decentralized network), how many validators participate in a price update, what data sources are utilized (centralized and decentralized exchanges/amms), and is the data modeling robust or can it be easily manipulated based on a low liquidity asset traded on a single low quality venue? Lastly, what is the route from the Oracle architecture to the chain, is there a bridging mechanism from another chain involved that introduces additional trust layers? These design choices are directly correlated to the security and decentralization profile of an Oracle protocol.
Chronicle has designed its Oracle infrastructure to address cost, scalability and the security challenges that have confronted Oracle operators. For Oracles to produce a price update, it requires gas for the transaction to be pushed on-chain. During past bull markets, the cost of operating an Oracle protocol on Ethereum mainnet has been extremely expensive. To address this cost, most Oracle providers limit the number of updates they push and/or limit the number of validators or price feeds in their system. In L2s specifically, the more validator signatures there are per update, the larger the call data and the more expensive the transaction to update the Oracle becomes. To solve this, Chronicle implemented Schnorr signatures in its latest version, a first for an Oracle protocol on Ethereum.
Schnorr signatures decouple the linear relationship between the number of validators and the cost to update the Oracle. Other Oracle protocols reduce the number of validators, thereby reducing security and decentralization, in order to constrain costs. In contrast, Chronicle has a near-constant Oracle update cost for any number of validators. While the Dencun update will reduce the cost of transactions on L2s across the board, the utilization of Schnorr with this update, will continue to deliver the most cost reductions on an Oracle update.
Additionally, the validator network within Chronicle includes reputable Defi brands such as Gnosis, Gitcoin, Etherscan, Maker, dydx and Defi Saver to name a few, which allows users to identify who the participants are in providing a price update. Brands that are highly regarded and visible in Defi.
Is your project composable with other projects on Arbitrum?
Chronicle is plug-and-play and backwards compatible with Chainlink, and can support any Defi application requesting DeFi price feeds.
Do you have any comparable protocols within the Arbitrum ecosystem or other blockchains?
Chainlink, Redstone, Pyth. Comparable in all provide Defi price updates from an Oracle however the design architecture between them vary considerably.
How do you measure and think about retention internally?
Oracles secure a protocol with accurate price information that informs the functions of a protocol (i.e. liquidation triggers, trading, lending/borrowing). Chronicles job is to provide protocols with real time price accuracy with constant uptime. This should be done in a trust minimized way, where anyone can verify how a price update was derived, what validators participated and what data sources are included. Chronicles dashboard displays every data source in real-time and historically.
Anyone can look at a Chronicle Oracle, choose a time and date on the graph, and hit the drop-down arrow on any validator to see which exchanges they queried for the price data. Providing full visibility and verifiability of an Oracle price update.
A key metric for Oracle performance is total value secured/TVS. Chronicle is currently the 2nd largest Oracle provider based on TVS driven from Maker and Spark which are high TVL protocols. Having credibility and experience securing, blue chip, high TVL protocols like Maker and Spark provide other protocols seeking an Oracle provider, with confidence and a reference to Chronicles experience managing high TVL protocols for many years. Through battle tested tech, an openly verifiable system, competitive Oracle costs, developer on-boarding education and new asset support, Chronicle has a strong customer acquisition and retention program in place for its upcoming L2 deployments.
Relevant usage metrics - Please refer to the [OBL relevant metrics chart](OBL Data Reporting + KPIs - Google Docs). For your category (DEX, lending, gaming, etc) please provide a list of all respective metrics as well as all metrics in the general section:
In this section, it’s a challenge for Chronicle to illustrate its growth beyond Maker and Spark since we are in the beginning of our GTM and are about to allow usage of Chronicle Oracles to all EVM apps. Since our spin out of Maker in late 2023, our GTM has focused exclusively on the technical deployment of our Oracle architecture on key L2s and establishing bootstrapping in the form of grants or direct agreements in order to enter those markets that are already heavily subsidized by the chains for Oracle usage.
Chronicle is currently the 2nd largest Oracle protocol by TVS and has been securing Maker since 2017 with constant liveness
Daily Active Users: 2 current contracts approved to access Chronicle/Maker and Spark.
Daily User Growth: We will update this once we begin on-boarding protocols
Daily Transaction Count: You can view all Oracle updates on Ethereum (Chronicle Protocol - Cost-Efficient, Verifiable Blockchain Oracles)
Daily Protocol Fee: NA
Daily Transaction Fee: A time series, daily total transaction fees generated daily by interactions with the protocol’s contracts. NA
Daily ARB Expenditure and User Claims: NA
Incentivized User List & Gini: NA
Do you agree to remove team-controlled wallets from all milestone metrics AND exclude team-controlled wallets from any incentives included in your plan: Yes
Did you utilize a grants consultant or other third party not named as a grantee to draft this proposal? If so, please disclose the details of that arrangement here, including conflicts of interest (Note: this does NOT disqualify an applicant): No
SECTION 2b: PROTOCOL DETAILS
Provide details about the Arbitrum protocol requirements relevant to the grant. This information ensures that the applicant is aligned with the technical specifications and commitments of the grant.
Is the protocol native to Arbitrum No, launched on Mainnet in 2017 and EVM compatible.
On what other networks is the protocol deployed?: Ethereum, Polygon zkevm, Mantle, Gnosis
What date did you deploy on Arbitrum mainnet?: [Date + transaction ID.
- ARB/USD - Chronicle_ARB_USD_1 - Arbitrum 0x91Fa05bCab98aD3DdEaE33DF7213EE8642e3c66c
- BTC/USD - Chronicle_BTC_USD_1 - Arbitrum 0x898D1aB819a24880F636416df7D1493C94143262
- ETH/USD - Chronicle_ETH_USD_1 - Arbitrum 0x5E16CA75000fb2B9d7B1184Fa24fF5D938a345Ef
WUSDM/USD - Chronicle_WUSDM_USD_1 - Arbitrum 0xdC6720c996Fad27256c7fd6E0a271e2A4687eF18
Chronicle spun out from Maker as an independent team, product and service available for all EVM chains in late 2023. We are deploying to L2s based on growth opportunities
Do you have a native token?: No token yet
Past Incentivization: What liquidity mining/incentive programs, if any, have you previously run? Please share results and dashboards, as applicable? NA
Current Incentivization:
We are working with grants and establishing direct service agreements with the chains we deploy on in order to allow protocols on those chains with gas subsidies for Oracle updates on Chronicle. As stated before, our GTM is focused on L2 deployments first, with established bootstrapping from the chains in place, otherwise Chronicle is at a disadvantage in those markets where protocols are getting heavily subsidized Oracle usage from other Oracle providers, coming from grants/agreements with the chain operators. The cost for Chronicle to deploy to a chain and have to compete against heavily subsidized Oracle providers, without bootstrapping from that chain is not strategic for us, and we are selecting L2 deployments based on a mutually beneficial working arrangement with the chains. In an effort to promote better Oracle diversity and price competitiveness, it is in the interest of L2 operators to neutrally support Oracle infrastructure providers, otherwise Oracle usage on a network becomes centralized and skewed to what provider has the most subsidies from that chain, with less consideration on the overall quality profile of the Oracle tech. The Oracle selection and usage from protocols is driven primarily from how much it costs them, which goes back to what Oracles are most subsidized, vs highest quality. If chains want to be decentralized from top to bottom, the infrastructure powering the protocols running on it, should be decentralized.
Have you received a grant from the DAO, Foundation, or any Arbitrum ecosystem related program? [yes/no, please provide any details around how the funds were allocated and any relevant results/learnings(Note: this does NOT disqualify an applicant)]
No
Protocol Performance: [Detail the past performance of the protocol and relevance, including any key metrics or achievements, dashboards, etc.]
- 1st Oracle protocol launched on Ethereum
- Securing 20B+ since its deployment in 2017
- 1st Oracle to utilize Schnorr Signatures on Ethereum
- 60% reduction in Oracle update costs compared to other leading oracle providers
- 2nd largest Oracle per TVS (Defillama)
Protocol Roadmap:
DeFi Oracle product which is now being rolled out in our initial GTM phase. We soft launched to the public, spinning out of Maker as an independent brand/team late this past fall, and have focused on integrating with L2s as our main distribution partners, acquiring direct service agreements/grants to allow us to bootstrap app adoption. To date we’re deploying with Polygon zkEVM, Mantle, zkSync and Optimism with others in the pipeline. We have capabilities for a push and pull Oracle mechanism. Default settings are for push based updates and we have a pull configurable offering being released in June.
RWA Oracle infrastructure is our other product vertical which Chronicle has a unique strategic advantage and immediate market share with given our origin and close partnership with MakerDAO. Given MakerDAO’s unique position in DeFi as being the dominant demand-side player of RWAs, we will leverage our experience to build out a robust data infrastructure solution and partner with traditional financial institutions who have an interest in entering the RWA space but lack the technical capability to execute.
Audit History & Security Vendors: [Provide historic audits and audit results. Do you have a bug bounty program? Please provide details around your security implementation including any advisors and vendors.]
Security Incidents: [Has your protocol ever been exploited? If so, please describe what, when and how for ALL incidents as well as the remedies to solve and mitigate for future incidents]
No
SECTION 3: GRANT INFORMATION
Detail the requested grant size, provide an overview of the budget breakdown, specify the funding and contract addresses, and describe any matching funds if relevant.
Requested Grant Size: 150,000 Arb
Justification for the size of the grant:
Chronicle will deploy Oracles on Arbitrum and provide protocols with high integrity, battle tested, decentralized Oracles. The grant will be used to cover the gas costs (gas rebate) to update the Oracle for protocols choosing to use Chronicle.
Pre Dencun this is an example of the cost of a transaction on Arbitrum testnet from Chronicle: Arbitrum Transaction Hash (Txhash) Details | Arbiscan
- Using 20 Validators/signers in the price update
- Cost= 0.91$
Post Dencun update this is a transaction cost for a Chronicle price update (March 15)
- Using 7 Validators
- Cost = $0.09
For comparison against other leading Oracle providers, this is a Chainlink transaction (March 15):
- Using 4 Validators
- Cost $0.15
Notable is the gas cost difference between the two:
402k(Chainlink) vs 204k (Chronicle) which demonstrates the cost reduction that Chronicles Oracle architecture provides (along with increased decentralization). This matters for the grant dollars being used most efficiently because “dollar for dollar”, an Oracle update on Chronicle costs less, benefiting the Arbitrum DAO’s grant distribution.
Grant Matching: [Enter Amount of Matching Funds Provided - If Relevant]
We don’t have a token launched yet nor will be providing grant matching at this time
Grant Breakdown: [Please provide a high-level overview of the budget breakdown and planned use of funds]
- 25,000 ARB for chain integration and ongoing maintenance
- 125,00 ARB for 20 Oracles (asset pairs) available for apps on Arbitrum to consume with gas costs covered by this grant.
- This grant will not be used to pay Chronicle validators (aka data publishers) or help develop a new product within Chronicles product suite, it will be used only to benefit Chronicle customers (protocols consuming Chronicle Oracles) in the form of gas rebate/subsidies for push or pull oracle updates. We have a pipeline of ~10 protocols (lending protocols, stablecoin issuers and LST providers) who are interested in using Chronicle once we’re available on Arbitrum. Over the 12 week LTIPP pilot program we anticipate a potential TVS of 15-20M+
Funding Address: 0x2E0681907fC36A1A41EEB1624E329D67BeE5C7c0
Funding Address Characteristics: [Enter details on the status of the address; the eligible address must be a 2/3, 3/5 or similar setup multisig with unique signers and private keys securely stored (or an equivalent custody setup that is clearly stated). The multisig must be able to accept and interact with ERC-721s in order to accept the funding stream.
⅔ multi-sig
Treasury Address: Chronicle is not a DAO and does not have a public treasury address
Contract Address: see above with Oracle contract addresses on Arbitrum mainnet
SECTION 4: GRANT OBJECTIVES, EXECUTION AND MILESTONES
Clearly outline the primary objectives of the program and the Key Performance Indicators (KPIs), execution strategy, and milestones used to measure success. This helps reviewers understand what the program aims to achieve and how progress will be assessed.
Objectives: [Clearly state the primary objectives of the grant and what you intend to achieve]
We envision this as a long-term growth plan with Arbitrum to support its ecosystem with the highest quality, battle tested decentralized Oracle infrastructure. In practice, this means that any protocol deployed on Arbitrum who integrates with Chronicle will get gas costs covered for the duration that the grant lasts. This provides protocols with Oracle infra that allows them to scale safely and with accuracy in their price updates.
Execution Strategy: [Describe the plan for executing including token distribution method (e.g. farming, staking, bonds, referral program, etc), what you are incentivizing, resources, products, use of funds, and risk management. This includes allocations for specific pools, eligible assets, products, etc.]
As an Oracle solution we provide applications who need price feeds with data. We don’t have a token to add additional incentives for our usage. The most impactful incentive to the application using Chronicle is having their cost for accessing an Oracle be paid for by this grant. Chronicle will apply its BD, DevRel and Marketing resources to help Arbitrum builders access high quality data from us and support them with co-marketing via social, blog and hackathons where we can offer additional lift.
What mechanisms within the incentive design will you implement to incentivize “stickiness” whether it be users, liquidity or some other targeted metric? [Provide relevant design and implementation details]
Chronicle will provide on-boarding support and developer education within the Arbitrum ecosystem and develop new Oracle (assets pairs) on request from protocols as long as it meets Chronicles data modeling requirements.
Specify the KPIs that will be used to measure success in achieving the grant objectives and designate a source of truth for governance to use to verify accuracy. [Please also justify why these specific KPIs will indicate that the grant has met its objective. Distribution of the grant itself should not be one of the KPIs.]
- TVS on Arbitrum
- Number of protocols using Chronicle on Arbitrum
Grant Timeline and Milestones: [Describe the timeline for the grant, including ideal milestones with respective KPIs. Include at least one milestone that shows progress en route to a final outcome. Please justify the feasibility of these milestones.]
Grant Timeline and Milestones:
Month 1-2
- Chronicle marketing for Arbitrum ecosystem; blog announcement, X spaces, discord channel for Arbitrum builders to learn how to use Chronicle. Ongoing partnership announcements for Arbitrum protocols integrating Chronicle Oracles.
- Addition of 15 Oracles (asset pairs) from Chronicle for Arbitrum protocols to utilize with the grant.
Month 2-3
- TVS estimate range for Chronicle Oracles across Arbitrum is hard to estimate but we anticipate 20M in new TVS from Chronicle by end of the 12 week LTIPP program.
- Approximately 5-10 protocols on Arbitrum using Chronicle
- Continuation of co-branding with Arbitrum builders on social media and events Chronicle has planned participation in like ETHCC and future hackathon bounties.
How will receiving a grant enable you to foster growth or innovation within the Arbitrum ecosystem? [Clearly explain how the inputs of your program justify the expected benefits to the DAO. Be very clear and tangible, and you must back up your claims with data]
Chronicle Oracle infrastructure brings builders on Arbitrum high integrity, battle tested, resilient and decentralized infrastructure that they can safely scale their own protocols with. It also brings Oracle diversity and price competitiveness to Arbitrum which is beneficial for all parties involved.
The expectation of an Oracle should be to provide reliable price feeds. We don’t have a token to incentivize additional farming activity on Arbitrum and if that is the intention of the LTIPP, we should reconsider our participation at this time.
Additionally, the value Chronicle provides back to the Arbitrum DAO, in addition to securing its ecosystem with high quality infrastructure, is the mileage the grant allocation will get compared to other Oracle providers. The system parameters of our push Oracle are designed to update prices when there is a change in price that is materially impacting users, not updating unnecessarily without a price deviation, resulting in wasted grant dollars. Each asset supported on Chronicle is configured with a deviation threshold % and heartbeat that is relative to the volatility of that asset. Our pull Oracles (releasing in early summer) are predicated on an end user triggering the price request, vs the Chronicle default push settings.
Looking at a year of price updates within Maker for ETH/USD there were approximately 3k+ price updates = 8.5 updates per day with a setting to push an update at a price deviation of >1% or > 24 hours.
Chronicle can set these parameters accordingly and uses its historical data to determine risk parameters for these settings. In “classic” lending protocols like Maker, Aave and Compound for example, push settings at these ranges are suitable and cost effective. In lower latency protocols, having more frequent updates is desirable. Chronicle can serve both use cases, but doesn’t combine them and over update, and by default, incur unnecessary Oracle costs and in the context of a grant allocation, there isn’t wasted grant dollars by excessive updates. Chronicle will release its pull Oracle this summer and enable low latency protocols with either setting based on their needs.
Do you accept the funding of your grant streamed linearly for the duration of your grant proposal, and that the multisig holds the power to halt your stream?
Yes
SECTION 5: Data and Reporting
OpenBlock Labs has developed a comprehensive data and reporting checklist for tracking essential metrics across participating protocols. Teams must adhere to the specifications outlined in the provided link here: Onboarding Checklist from OBL. Along with this list, please answer the following:
**Is your team prepared to comply with OBL’s data requirements for the entire life of the program and three months following and then handoff to the Arbitrum DAO? Are there any special requests/considerations that should be considered?
Yes but would like to better understand the specific reporting expected for an Oracle protocol.
Does your team agree to provide bi-weekly program updates on the Arbitrum Forum thread that reference your OBL dashboard? [Please describe your strategy and capabilities for data/reporting]
Yes but this needs further clarification for an Oracle protocol.
First Offense: *In the event that a project does not provide a bi-weekly update, they will be reminded by an involved party (council, advisor, or program manager). Upon this reminder, the project is given 72 hours to complete the requirement or their funding will be halted.
Second Offense: Discussion with an involved party (advisor, pm, council member) that will lead to understanding if funds should keep flowing or not.
Third Offense: Funding is halted permanently
Does your team agree to provide a final closeout report not later than two weeks from the ending date of your program? This report should include summaries of work completed, final cost structure, whether any funds were returned, and any lessons the grantee feels came out of this grant. Where applicable, be sure to include final estimates of acquisition costs of any users, developers, or assets onboarded to Arbitrum chains. (NOTE: No future grants from this program can be given until a closeout report is provided.)
Yes
Does your team acknowledge that failure to comply with any of the above requests can result in the halting of the program’s funding stream?: Yes