YieldSpace Contracts Discovery

[apbendi]

Investigate the YieldSpace v2 contracts.

Key things to understand:

• [ ] Do the pool and pool factory contracts work as is with ReimbursmentTokens? If not, why not?
• [ ] To implement a frontend with the features described below:
  • [ ] What YieldSpace functions would we need to call?
  • [ ] What data would we need to call them, and how can we get it?

High level frontend spec:

Bold elements are those most likely to touch the YieldSpace contracts

• The frontend will be easy for projects launching reimbursement tokens to fork, configure, white label, and deploy
• It will adopt the UI of a typical DEX app, drawing on the YieldSpace UI for inspiration
• It will allow users to see if they qualify to receive reimbursement tokens via the Merkle distribution and claim them if they do
• It will allow the user to swap between the reimbursement token and the treasury token
• It will display the “effective interest rate,” denominated in the treasury token, if the user purchases reimbursement tokens and holds until maturity
• It will display the maturity date
• It will allow the user to add or remove liquidity from the AMM liquidity pool

[mds1]

General notes

• The underlying() method from our IReimbursementToken interface is never called
• Additionally, reimbursement tokens only implement the underlying and maturity methods, so do not comform to the full FYToken interface, but this does not seem to be a problem as only maturity is used in YieldSpace
• ts, g1, and g2 are read from the factory during Pool construction. I'm not yet clear on (1) what these values should be, (2) should they be the same for all riToken pools, and (3) should riToken pools have the same values as regular fyToken pools? If (3) is "no", we need a new YieldSpace factory with different parameters. If (2) is also "no", then that new factory needs to be modified so ts, g1, and g2 are inputs to the createPool method instead of storage variables
• Pools only support tokens up to 18 decimals so we're safe by making the same assumption

Creating Pools

• PoolFactory.createPool, but this is behind an auth modifier, so seems you cannot permissionlessly create pools
• PoolFactory.getPool to locate the pool a user is looking for

Adding/Removing Liquidity

• Pool.mintto add liquidity or Pool.mintWithBaseto add liquidity by only providing the base token and buying fyTokens from the pool
• Similarly, Pool.burn and Pool.burnForBase to exit the pool

Swaps

• Pool.sellBasePreview for a quote followed by Pool.sellBase to sell base token for fyToken
• Pool.buyBasePreview for a quote followed by Pool.buyBase to sell fyToken for base token
• All 4 methods above also have fyToken varieties. The difference seems be analogous to Uniswap's "swap exact tokens for tokens" vs. "swap tokens for exact tokens"
• For preview methods to get quotes, the input argument is just the amount the user wants to buy or sell

Effective interest rate

Assuming effective interest rate is calculated as follows, but let me know if this is incorrect:

// At maturity, the token is expected to be worth `percentToAccrue` more than it is now
const percentToAccrue = (maturityValue - currentValue) / currentValue;

// Number of seconds over which that value increase will occur
const timeRemaining = riToken.maturity - (new Date().getTime() / 1000);

// Convert that interest rate into an APR (pretty sure this gives APR, not APY,
// since there's no compounding considered here)
const effectiveInterestRateAPR = percentToAccrue * secondsPerYear / timeRemaining

If so, we get maturityValue based on the riToken target exchange rate, currentValue by getting a quote from the pool (what quote inputs?), and the riToken's maturity is read from its contract