Litepaper
Last updated
Last updated
The APY.Finance platform is a yield farming robo-advisor that runs a portfolio of yield farming strategies from a single pool of liquidity.
Key features of APY.Finance include:
Capture growth across the DeFi industry with a single deposit.
Diversified portfolio of yield farming strategies to reduce smart contract risk and yield volatility.
Automatic portfolio rebalancing to optimize risk-adjusted yield.
Over 99% gas savings on rebalance fees compared to independent manual yield farming.
Over 80% gas savings on deposit and withdrawal fees compared to other yield farming aggregators.
The APY liquidity pool is actually a collection of contracts that handle the deposit and withdrawal of a single currency. These contracts work together to form a single pool of liquidity. When a sender deposits into a contract, they are issued APT tokens to represent their share of the pool.
Each liquidity contract determines the notional value of its reserves using existing Chainlink aggregators. We use the ETH denominated aggregators because they are updated more frequently and have more sponsors.
You can view some of the Chainlink aggregators we use here.
The APY strategy portfolio is a library of strategy contracts that interact with financial primitives to earn yield.
Every strategy has an asset schema that describes the types of assets and which assets are used for each type.
Type | Description | Example |
Input assets | Required to begin earning yield from the strategy. | DAI, USDC |
Intermediary assets | Held by the contract while running the strategy. | cDAI, yCRV |
Output assets | Generated by the strategy and swapped for yield. | COMP, CRV |
Every strategy has three different sequences that are used over the course of its life-cycle.
Sequence | Description | Example |
Entry | Deploys input assets to the strategy. | Using DAI to mint cDAI. |
Loop | Performs regular upkeep for the strategy. | Swapping COMP for DAI to mint cDAI. |
Exit | Unwinds the strategy. | Retrieving DAI by redeeming cDAI. |
These assets and sequences for each strategy are used by the APY manager to process deposits, withdrawals, new portfolio optimizations, and to earn yield.
Every strategy has a view function to calculate the yield estimate for a given amount of input assets at the current block state. This estimate is used when comparing strategies and determining optimal strategy allocations.
Every strategy has a risk score associated with it. This score is represented by a number between 0 and 10e18. The initial risk score is set when the strategy contract is first deployed, however it can be updated through governance proposals.
The team looks at a variety of risk factors to asses the risk score using the DeFi Score whitepaper as a template.
Risk scores are used to weight a strategy's estimated yield to get a risk-adjusted yield. It is this risk-adjusted yield that is primarily used when optimizing portfolio allocations.
You can read the DeFi Score whitepaper here.
Strategy | Description |
Compound DAI^3 | COMP farming with leveraged DAI using dYdX flash loan. |
Boosted yCRV | CRV farming with 1 week locked veCRV with the yCRV pool. |
DODO USDT-USDC | DODO farming with the USDT-USDC DODO pool. |
DeFiDollar DUSD-USDC Balancer | DFD, BAL, and CRV farming with the DUSD-USDC Balancer pool. |
The APY manager automates the movement of liquidity through the APY system.
The manager contract contains a rebalance function that sets in motion several important processes:
If there is any reserves sitting idle in the liquidity pool from new deposits, they will be deployed proportionally to the current strategy portfolio.
If the notional amount of withdrawal requests is less than the amount idle reserves in the liquidity pool, the reserves will be locked for withdrawal and the requests will pass.
If the notional amount of withdrawal requests exceeds the amount of idle reserves in the liquidity pool, portions of the strategy portfolio will be unwound until all the withdrawal requests can be processed. These reserves are then locked for withdrawal and the requests will pass.
If the notional value of assets in any strategy are no longer within a certain threshold of the currently selected allocation ratios, it will be rebalanced to match the desired ratios.
Executing each strategy's loop sequence if the threshold conditions for a loop are met.
The rebalance function can be called by any external address.
Because Ethereum does not natively support trigger-based automation, this rebalance function must be called regularly for the system to function. To prevent dependencies on a centralized authority for automation, third parties have an incentive to make rebalance calls.
Rebalance incentives are issued from a rebalance pool that reserves small portions of yield earned by the strategy portfolio.
The APY manager handles swaps between liquidity pool assets and the strategy portfolio input assets. When the proportions of available liquidity pool assets do not match the desired proportions of input assets, they are swapped to meet thresholds.
Example:
There are 3 portfolio strategies and the current portfolio optimization expects a ratio of 50/25/25.
The first and second strategies require DAI and the third strategy requires USDC.
The liquidity pool is 50/50 DAI and USDC.
Given these conditions, the APY manager will swap half of the USDC reserves for DAI before deploying to the strategy portfolio on the next rebalance.
The transaction fees and slippage of these swaps are considered when determining the transaction cost of a portfolio optimization.
Portfolio optimization for risk-adjusted yield that varies based on the amount of deployed liquidity is essentially a network flow problem. For portfolios with fewer strategies, the optimal portfolio allocation can be computed on-chain. However, as the number of strategies inevitably increases, the computation required to optimize the portfolio will begin to exceed the block gas limit.
To solve this issue, the APY platform allows off-chain computation of portfolio allocations that can be submitted to the APY manager for verification. The APY manager compares this new set of allocations with the old set using the on-chain yield estimates for each strategy. If the new set of allocations results in a greater risk-adjusted yield, and the transaction costs of rebalancing are lower than the gain in yield by a threshold, the new set of allocations can be automatically accepted.
Because it is unnecessary to verify that an allocation is perfectly optimal, only that it is more optimal, the APY platform can safely allow this off-chain computation without relying on a central authority to sign off on new allocations.
The generic strategy executor is a type of strategy contract that will be used heavily with the second and third phase of governance.
The executor takes a series of arbitrary function calls to external contracts and encodes them into sequences of call data that are then used in place of a standard strategy's enter, loop, and exit sequences.
The executor can use a library of adapters to process the return values of external function calls for use as parameters in other function calls in the sequence.
To produce a single step of call data from a function call, the contract takes the 4 byte keccak256 encoded function selector and combines it with a set of parameters encoded using the contract ABI specification.
You can read the official Solidity documentation to learn more about encoding function calls here.
This architecture allows for the development of a drag-and-drop style UI that takes any sequence built by a user and uses the external contract ABIs to create the arrays of call data accepted by the executor contract. Designing strategies with executor contract will dramatically lower the barrier-of-entry for governing strategies by eliminating the need for specialized knowledge of smart contract engineering.
Because of the wide range of possibilities with generic call data execution, safeguards are in place to limit the attack surface. This includes whitelists of external contracts and whitelists of function selectors.
APY is our ERC-20 governance token. It will be used to vote on system-wide parameters, changes to strategies in the portfolio, and the inclusion of entirely new strategies. Our governance roadmap covers the different stages of decentralization the platform will undergo as it progresses towards full community ownership. The APY team will make critical decisions with feedback from the community to stay nimble in the early stages of development.
The APY liquidity mining program is an incentive for liquidity providers to deposit their stablecoin into the APY platform. Accounts earn APY tokens for every block they have a deposit in the APY platform. We have allocated 31.2% of the token supply to this purpose and the initial emission rate of rewards started at 30,000 per day.
You can read more about our token distribution here.
Every week the team runs a script to calculate the block-by-block rewards for each account that has deposited into the APY platform. The script uses the following formula to calculate account rewards per block from an amount of rewards issued per second:
Once the script is finished a blob of balances is released in the APY GitHub blob repository.
You can view the weekly APY balance blobs here.
Rewards from the APY liquidity mining program vest over a period of 6 months. Vesting rewards discourages those just looking to sell the tokens, leaving greater rewards available for those that see the long term utility of APY governance.
Instructions on how to use the vesting claim contract is available here.
The formula used to calculate the vested rewards for an account is shown below:
The standard vesting contracts used by many projects have high gas costs because they perform all vesting calculations on-chain. Normally performing calculations on-chain allows for greater decentralization, but in the case of vesting contracts, the rewards must still be issued by a centralized admin key.
The APY vesting contract instead uses signature based claims. Vesting calculations are done off-chain and the amounts are signed by an admin key. The resulting signature can be used by an account to process their claim at a much lower gas cost than typical vesting contracts.
The signatures are generated according to the EIP-712 standard using the OpenZeppelin ECDSA implementation. The contract uses a unique domain separator and per-claim nonces to protect against replay attacks. An insufficient domain separator can result in replay attacks stemming from other networks or other contracts. The nonces prevent an account from receiving multiple signatures with increasing rewards unclaimed rewards and then claiming them all at once.
You can view the EIP-712 standard here.
