[Coupon Finance] LTIPP Application FINAL

DAO Grant Programs Long Term Incentives Pilot Program
1

Application Template

SECTION 1: APPLICANT INFORMATION

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:

  • Kevin

Project Name:

  • Coupon Finance

Project Description

Short Description

  • Coupon Finance is a peer-to-pool lending protocol that enhances capital efficiency of lending markets by eliminating term spreads through orderbooks to ensure more competitive rates for both borrowers and lenders, while also allowing adaptable loan durations through yield tokenization.

Please take a look at this 3-minute explanatory video to understand what it is, how it works, and why we need it (We’re trying our best to describe it in the following paragraphs too, but the video explains better with visual contents) - https://twitter.com/CouponFinance/status/1729166317448757411

CDC(Certificate of Deposit with Coupons)

Coupon Finance introduces a novel instrument called Certificate of Deposit with Coupons (CDC).

  • In traditional finance, a certificate of deposit (CD) is a type of savings account that pays a fixed interest rate on money held for an agreed-upon period of time. (Definition from Investopia)
  • Coupon Finance adopts a CD mechanism to implement fixed-term, fixed-rate lending, for enhanced capital efficiency (compared to “variable-rate demand deposits” and “variable-rate perpetual loans” that existing lending protocols such as Aave or Compound offer)
  • But CDs have low fungibility in that CDs with different maturity are not compatible with each other.
  • To solve the fungibility problem, we added “Coupons” to CD and created CDC.

“Coupons” in CDC

  • Coupons are tokenized representations of “rights to utilize given asset for an agreed-upon period of time”
  • Depositors can issue “coupons” of various “epochs” against their deposits, making the deposits non-withdrawable for the epochs. By selling those coupons, usually to borrowers,they can effectively get paid with an upfront yield.
  • Borrowers need to stake the coupons to borrow assets from Coupon Finance. By purchasing the coupons, usually from depositors, they effectively are paying for the interest.

Example

  • Alice deposits 100 ARB and issues 100 “ARB epoch-1 coupons.” (To make it simple, let’s assume it’s the beginning of epoch-1, and each epoch represents each calendar year – e.g., Epoch 1 is 2024, Epoch 2 is 2025, and so on, though in the actual implementation epochs are calendar-months)
  • She sells them to Bob at 4 ARB (i.e., 1 coupon = 0.04 ARB)
  • By doing so, Alice effectively gets 4.16% APY (since the interest is paid up-front, the rate is slightly higher than 4/100) on her 1-year 100 ARB deposits.
  • To borrow 100 ARB for epoch-1, Bob purchases and stakes 100 “ARB epoch-1 coupons”
  • Now that he has the coupons, he can borrow 100 ARB from Coupon Finance until epoch-1 passes (of course, as long as he has enough collaterals to back the loan)
  • Since coupons are fungible, Bob does not have to purchase the “exact” coupons Alice issued to borrow from “Alice’s” deposit. As long as Bob holds enough coupons, no matter who the issuer is, Bob has right to borrow corresponding assets from Coupon Finance.

Market Makers’ Roles (in coupon markets – or “yield markets”)

  • But what if there’s no borrower waiting to buy coupons when a depositor makes a deposit and tries to sell coupons?
  • Like any other market, market makers come in to take a role here.
  • Instead of Alice placing a limit-sell order for her coupons on the orderbook and waiting for that to be filled by Bob, she can trade her coupons against market makers to get yields instantly. The market maker can then place a limit-sell order with the purchased coupons on the orderbook, usually at a higher price, waiting for someone like Bob to come and buy them.
  • This way, market makers can connect depositors and borrowers using coupons, generating profit from the bid-ask spread as a result.

Team Members and Roles:

  • Kevin: Co-founder & CEO
  • Jay: Co-founder & Tech Lead
  • Sean: Smart Contract Dev
  • Gray: Frontend & Backend Dev
  • Xavier: Frontend & Backend Dev
  • Luna: Product Designer

Project Links: [Enter Any Relevant Project Links (website, demo, github, twitter, etc.)]

Contact Information

Point of Contact (note: this should be an individual’s name, not the name of the protocol): Kevin

Point of Contact’s TG handle: @kevinSohn

Twitter: @0xvinsohn

Email: kevin@coupon.finance

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.

Team experience:

We are a team dedicated to bringing novel innovations that can bring progress to the DeFi ecosystem.

Clober, our first invention, a fully on-chain orderbook infrastructure for EVM

  1. When we started our team in late 2022, we figured that the biggest bottleneck of the DeFi ecosystem was the lack of a fully on-chain orderbook infrastructure, which had been considered the “holy grail” of DeFi – which seemed impossible. After roughly three weeks of research, we came up with a fully on-chain order-matching algorithm for CLOB(Central Limit Order Book) and published it via Ethresearch.
    2 Based on that paper, we have developed Clober, the first fully on-chain CLOB infrastructure protocol for EVM.
  2. We designed Clober to be a public infrastructure that anyone can plug into to build applications that leverage on-chain orderbooks because that way, we can bring more novel innovations to DeFi.

Coupon Finance – a peer-to-pool lending protocol with enhanced capital efficiency powered by on-chain orderbooks

  1. We found major capital inefficiencies in the current lending market induced by term spreads - or cash drags.
  2. Various fixed-term lending protocols were trying to solve this, but they lacked flexibility in terms of duration management due to non-fungibility and fragmented liquidity, which was a significant obstacle for their adoption.
  3. We came up with a novel design that solves both problems, enhancing capital efficiency while maintaining flexibility, through yield tokenization and orderbook-based interest rate markets.

What novelty or innovation does your product bring to Arbitrum?

TL;DR:

  • It is the only lending protocol to offer fixed-term, fixed-rate lending in a peer-to-pool manner, achieving better rates for both borrowers and lenders while maintaining flexibility in loan durations.

Detailed Version:

  • Matching the terms between borrowers and lenders eliminates cash drags and enhances capital efficiency, resulting in lower loan-deposit spread and better rates for both sides. However, this usually results in liquidity segmentation per duration and rate, making the loan positions illiquid. (i.e., users cannot adjust the durations whatsoever)
  • We solved this by introducing something called a “CDC(Certificate of Deposits with Coupons)” – our unique way of tokenizing principals and yields separately – and adopting on-chain orderbooks for yield markets.
  • This way, we keep the peer-to-pool fungibility feature of the existing lending markets (such as Aave) while offering better rates through fixed-term, fixed-rate lending. (i.e., even though users are getting better rates through fixed-term, fixed-rate deposits/loans, they still have options to withdraw/repay before their durations – or extend the durations, etc.)

Is your project composable with other projects on Arbitrum? If so, please explain:

TL;DR:

  • Yes. Everything in Coupon finance is fully on-chain, making it fully composable with other applications on Arbitrum.

Detailed Version:

  • For example, a DEX aggregator can integrate our interest-rate orderbook markets to offer interest-rate trading to its users. Third-party token projects can use their treasury to conduct a yield-curve-control on their tokens. Leveraged trading or yield-farming platforms can plug into Coupon Finance to reduce the financing cost, offering users better yield (or lower borrowing rates).

Do you have any comparable protocols within the Arbitrum ecosystem or other blockchains?

  • No. The closest protocols might be Aave protocol in that it offers peer-to-pool lending, and Term Finance in that it offers better rates through fixed-term lending.

How do you measure and think about retention internally? (metrics, target KPIs)

Relevant usage metrics - Please refer to the OBL relevant metrics chart . For your category (DEX, lending, gaming, etc) please provide a list of all respective metrics as well as all metrics in the general section:

  • General: All metrics in the OBL relevant metrics chart.
  • Lending: All metrics in the OBL relevant metrics chart.

TVL Retention measurement through “dollar-months”:

  • Since we offer fixed-term lending, we can keep track of the “TVL Retention” through the outstanding coupons issued against deposits. For instance, suppose there are two deposits, one with 100 USDC face value maturing in 2 months and the other with 150 USDC face value maturing in 3 months. We can calculate a “dollar-month” sum of the deposits as follows: (100 USDC * 2 months) + (150 USDC * 3 months) = 650 “dollar-months”

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?:

  • Yes

What date did you deploy on Arbitrum mainnet?:

Do you have a native token?:

Current Incentivization: How are you currently incentivizing your protocol?

  • Providing higher “real yields” than other lending protocols through our orderbook-based interest rates market.
  • Haven’t started token emission-based incentive programs yet.

Have you received a grant from the DAO, Foundation, or any Arbitrum ecosystem related program?

  • No

Protocol Performance: [Detail the past performance of the protocol and relevance, including any key metrics or achievements, dashboards, etc.]

Please note that we’re still at the alpha-launch stage yet. (Ready to go live anytime in terms of development)

  • Number of Unique Depositors: 364
  • Number of Deposit Positions Created: 525
  • Number of Unique Borrowers: 21
  • Number of Borrow Positions Created: 172

Protocol Roadmap:

  1. Q1 2024
    1.a Official launch
    1.b Liquidity incentive program for depositors (farming phase 1) starts → Target Market Size: $3M
  2. Q2 2024
    2.a Liquidity incentive program for depositors (farming phase 2) starts → Target Market Size: $10M
    2.b Launch an easy-to-use frontend interface for market makers in Coupon Finance’s rates market.
  3. Q3 2024
    3.a Launch an easy-to-use frontend interface for yield trading.
    3.b Acieve $3M monthly trading volume in rates market.
    3.c Achieve $60M Total Market Size.
  4. Q4 2024
    4.a. Liquidity incentive program for market makers (farming phase 3) starts → Target Liquidity in rates market: $5M
    4.b. Achieve $10M monthly trading volume in rates market.
    4.c Achieve $200M Total Market Size.

Audit History & Security Vendors:

Security Incidents:

  • None

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:

  • 100,000 $ARB for YCC(Yield Curve Control) activities on the $ARB rates market.

Justification for the size of the grant :

Detailed concept of the YCC program is described in Section 4.

Simple description of what 100,000 $ARB can do here

  • Assuming that 4% APY is sufficient for $ARB 3-month deposits, we can secure and maintain up to 10,252,000 $ARB deposits throughout the following 3 months, using 100,000 $ARB.
  • We assumed that 4% APY is enough since the current variable rate for ARB in Aave is around 0.06% APY
  • The APY of paying100,000 $ARB upfront for locking 10,252,200 $ARB for three months = (face_value/effective_deposit_amount)^(12-months/3-months) = ( 10,252,000/(10,252,000-100,000) )^(12/3) = 1.04

Justification for the Target TVL of 10,000,000 $ARB

  • The core objective of this grant proposal is to prove the effectiveness and efficiency of the YCC program in terms of incentivizing long-term holdings and disincentivizing short-selling of $ARB tokens.
  • Technically, any number can be used as a target TVL since the point here is “with only 100K $ARB, we can lure 10M $ARB”
  • However, we chose 10,000,000 for the target because (i) it is a rather intuitive number, (ii) it does not require too much of a budget, and (iii) it is a non-trivial goal to achieve.
  • This way, we can minimize the cost of this “experiment” while making it easier for the community to grasp its effectiveness when it turns out to be successful.
  • Additionally, we can see that currently, there are 24,000,000 $ARB deposited in Aave for a variable rate below 0.1% APY(24M ARB chasing for sub-10BP rates!). This indicates that there is enough demand in the market for yield-generating products for $ARB. By offering 4% APY, we would be able to see how big that demand is.

Grant Breakdown

  • All grant tokens will be allocated to offering deposit yields to $ARB depositors through YCC activities on the orderbook. More details on what this would look like in practice and the value it brings to the Arbitrum community are described in Section 4.

Funding Address:

  • TBD

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.

  • TBD

Treasury Address: [Please list out ALL DAO wallets that hold ANY DAO funds]

  • TBD

Contract Address: [Enter any specific address that will be used to disburse funds for grant recipients]

  • TBD

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:

  1. Our goal is to prove the YCC program’s effectiveness in incentivizing long-term deposits and disincentivizing short-sellings of $ARB, so that this program can be extended further in the future.
  2. To show this, we aim to accrue up to 10,252,000 3-month $ARB deposits using relatively small capital, 100,000 $ARB, proving its huge leverage effect and great capital efficiency.

Important Note

Our objective here is NOT just to grow the TVL of Coupon Finance. In fact, it aims more to contribute to the Arbitrum community by incentivizing long-term holdings of $ARB tokens.

Execution Strategy:

We will “market-make” the rates market with the received $ARBs.

YCC - Bid side (or “purchasing coupons”)

  • By placing a bid order at a price corresponding to 4% APY in the $ARB coupon market on our orderbook using 100,000 $ARB, we can offer 4% APY to 10,252,000 $ARB deposits.
  • In other words, a user can make a 3-month deposit of 10,252,000 $ARB, receive corresponding coupons, and sell them via orderbook to get 100,000 $ARB. This way, the user has effectively deposited 10,152,000 $ARB and will be able to redeem 10,252,000 $ARB 3 months later, effectively getting 4% APY for the 3-month deposit.
  • This way, we can secure 10,252,000 $ARB TVL for a three months

YCC - Ask side (or “selling coupons”)

  • The purchased coupons will be sold via orderbook at a much higher rate, say 8%, which allows the depositors to withdraw before the maturity, but at a certain cost, allowing but disincentivizing early withdrawals.
  • Borrowers need to purchase the corresponding amount of coupons to borrow $ARB from Coupon Finance. Since the ask order is placed at a much higher price, it relatively disincentivizes borrowings and short-sellings.

What mechanisms within the incentive design will you implement to incentivize “stickiness” whether it be users, liquidity or some other targeted metric?

Metric

  • We can keep track of the stickiness using the “dollar-months” metric we introduced above.

During the grant program

  • Due to the lending-deposit spread we set via market-making activities on the orderbook, depositors are disincentivized to withdraw their deposits before maturity, contributing to the “stickiness” of the TVL.

“After” the grant program

  • Technically, the YCC program does not necessarily “consume” the fund, because even though we distribute 100% of the grant $ARB to the depositors, the coupons acquired as proceeds can be sold back to borrowers.
  • Optimistically, if both borrowing and lending sides are active, it can even be “profitable,” in which case we can sustainably continue this incentive program on our own, which contributes further to the Arbitrum community.

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.

  • Number of $ARB tokens deposited in Coupon Finance.
  • The criteria for minimal success would be 3,000,000 $ARB deposits. (It wouldn’t be an ideal outcome, but getting 3,000,000 $ARB 3-month-deposits with only 100,000 $ARB budget would still be a great achievement)

Grant Timeline and Milestones:

  • April: Secure 1,139,000 $ARB 3-month deposits (10,000 $ARB released)
  • May: Secure 3,417,000 $ARB 3-month deposits (30,000 $ARB released)
  • June: Secure 10,252,000 $ARB 3-month deposits (100,000 $ARB released)

How will receiving a grant enable you to foster growth or innovation within the Arbitrum ecosystem?

  • If this program succeeds, Arbitrum DAO can expand this by conducting the YCC on our rates market using the DAO treasury, further incentivizing long-term holdings and deposits.

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

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

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?: [Y/N]

  • Yes
2

Hello @Kevin

Thank you for your application! We can confirm your application has been submitted and you will be assigned an advisor shortly.

3

Hello @Kevin ,

Thank you for your application! Your advisor will be Castle Capital @Atomist.

Please join the LTIPP discord and ping your advisor in the general chat so they can create a new channel and start communicating with you.

4

Hey @Matt_StableLab

Just confirming that this is the final version of our application

(didn’t know I should change the title from “Draft” to “Final” – hope that’s not an issue)

1 Like