âtv tokenization
Last updated
Last updated
> âtv tokenization platform
aarnâ tokenization platform facilitates the creation of âtv vaults and is deployed on both Ethereum & Arbitrum. The platform includes eight smart contracts on Ethereum (6 tokenization + delayModule + 1 timelock), and nine smart contracts on Arbitrum (6 tokenization + delayModule + 1 sequencer + 1 timelock), To ensure reliability, all smart contracts have undergone comprehensive security audits. The âtv contracts are designed to handle three different types of on-chain structured products:
structured trading: This vault actively trades on fixed schedules using predictions generated from aarnâ AI models, starting with rules or algorithms to buy and sell assets, automatically rebalancing underlying assets. Akin to quant funds, but fully onchain, permissionless, self-custodied
value build (+ yield aggregation): Builds value by holding appreciating ERC20 tokens and staking them for yield. It can passively or actively rebalance the portfolio to optimize returns. Akin to ETFs, but fully onchain, permissionless, self-custodied, and with yield optimisation
yield optimization: It automatically allocates stablecoins (deposited as ERC-20 tokens) to various DeFi platforms (like Aave, Compound) for lending or staking. This earns the user passive yield on their stablecoins. The system also automatically rebalances user holdings to optimize returns.
In the future, the âtv tokenization platform will handle RWA and other DeFi innovations like Liquid Staking.
At the heart of aarnâ protocol lies the âtv tokenization platform, a DeFi infrastructure enabling the creation of structured on-chain investment products called âtv vaults. These vaults feature a wide range of strategies, including capital multiplication and yield optimization, AI-driven algorithmic products, derivatives, and future plans for Real World Asset (RWA) products.
Ethereum >
Arbitrum >
âtvFactory: Creates âtv vaults using Clones (EIP-1167) and 2 step Ownable with time delay module contract. It clones the âtvBase implementation contract, enabling or disabling features as needed, and takes pool data as an argument.
âtvBase: The implementation contract used to clone âtv vaults. When users deposit stablecoins, specific âtv vault shares are minted based on NAV and transferred to users' wallets. The aarnâ DAO can pause and unpause vaults. All features are coded in âtvBase and can be enabled or disabled during vault creation.
âtvManager: Acts as the controller for âtv tokenization, handling rebalancing and managing team wallets in âtv vaults. Team wallets, once added, cannot be removed. The contract allows activation and deactivation of wallets by aarnâ DAO to prevent malicious activity or compromised private keys. New versions of âtvManager can be deployed for updated rebalancing strategies.
âtvStorage: Stores all âtv product details, accessed through âtvBase and âtvManager. It contains TVL-related calculations for âtv products.
âtvPassiveRebalanceStrategies: Includes passive rebalancing strategies, which are enabled at vault creation. Rebalancing occurs automatically at set intervals.
âtvOracle: Converts token prices to USDC using Uniswap V3 TWAP and Chainlink oracles. It includes functions for price estimation, and in Arbitrum, a sequencer fetches prices from Chainlink. It also optimizes gas costs for withdrawals via a queuing system, allowing cumulative swaps for grouped user withdrawals.
TimeDelay: TimeDelayModule enforces a delay for critical functions, to enhance security by ensuring that specific actions can only be executed after a predefined delay, allowing time for review and potential rescind of queued transactions.
Users can queue withdrawals to save on gas fees, processed by the Cumulative Swap Controller. Profits are calculated based on NAV differences, with up to 10% of the profit retained for later distribution. Queued withdrawals can be canceled if not yet unstaked.
âtv Tokenization Platform Deployment & Upgrades:
The first deployment of the âtv contracts will be handled directly by aarnâ using a single wallet. Once this initial deployment is completed, ownership of the contracts will be transferred to the aarnâ DAO SAFE wallet. As the protocol becomes more decentralized, the responsibility for deploying new versions of the contracts will shift to the aarnâ DAO. It's important to note that ownership of âtvOracle, âtvStorage, and TimeDelay will be transfered to Wallet #2 (W#2) and the others (âtvFactory, âtvBase, âtvManager, and âtvPassiveRebalanceStrategies) will be transfered to Wallet #1 (W#1). For security reasons, the current contracts are designed to be non-upgradeable. Any new features or updates will be introduced through versioning, ensuring that the system remains robust and secure.
âtv Vault Creation & Deployment:
The process of creating and deploying âtv vaults begins with strategy proposals, which can be initiated by an alpha creator on the aarnâ DAO or by the DAO itself. These proposals are then subject to approval based on the aarnâ DAO’s governance procedures (which are currently handled off-chain but will be finalized in future iterations). Upon approval, the aarnâ DAO (W#1) invokes the âtvFactory to create new vaults, potentially in collaboration with alpha creators.
Deposits [Stablecoins]:
Users can deposit stablecoins like USDC, USDT, or DAI into these vaults and receive âtv tokens in return, calculated according to the Net Asset Value (NAV) after deducting a 1% deposit fee. The deposited amount goes into a non withdrawable container with respect to the user. These deposited stablecoins are subsequently swapped into the underlying assets of the vault using platforms such as Uniswap V3 or Camelot V3 (specific to Arbitrum). The Deposit function can be paused in a critical situation by the pause() function that resides in the vault.
Net Asset Value (NAV) Calculation:
NAV calculation is based on the TVL of the âtv product and the total supply of âtv tokens. The TVL includes the value of the wrapper/LP token and its rewards, reflected in the NAV at any point in time. TVL is calculated by considering the balance of underlying and pre-deposited stables on the vault, staked assets in protocols, accrued staking rewards, and deposit tokens on the vault (until the next cumulative swap). These values are converted to USD using Chainlink/Uniswap V3 prices and summed to get the TVL. The NAV of an âtv token is equal to the TVL divided by the total supply of âtv tokens, representing the value of an âtv token in USD.
Cumulative Swaps:
Deposits into âtv vaults are not immediately converted to underlying tokens. Instead, all deposited stablecoins are periodically swapped in a single transaction to save on gas costs, which are paid by the user. This swap is executed by a designated account known as the cumulative swap controller wallet, set by the DAO owner of the vault. For the swap to occur, the deposited stablecoins must meet a predefined threshold called the preSwapDepositLimit, and the swap must be conducted at regular intervals specified in the âtvOracle contract. On the Ethereum chain, there are three external protocols available for staking, and similarly, four options are available on the Arbitrum chain. Staking into these external protocols is done during the cumulative swap at the time of the rearrange() call.
Rebalancing:
Rebalancing in the âtv tokenization platform optimizes returns or aligns with the vault's objectives, either actively or passively. During vault creation, aarnâ DAO selects rebalancing options via âtvBase and âtvFactory, including active, passive, or no rebalancing. Passive Rebalancing is managed algorithmically based on pre-programmed logic, rebalancing at fixed intervals to maintain design proportions. This method does not allow for the removal or substitution of tokens. Current strategies include: Continuously using the default design underlying token proportion, regardless of TVL changes. And updating token proportions during cumulative swaps based on current units and TVL. Active rebalancing, on the other hand, involves manual adjustments by the alpha creator or manager, approved by the DAO. This includes scenarios like withdrawing underperforming tokens, replacing them, or redistributing their value among existing tokens. New rebalancing strategies can be introduced in future versions of the âtvManager, allowing the DAO to update rebalancing methodologies as needed. Algo Product Rebalancing allows adding, removing, or replacing multiple tokens at once, with equal distribution among all tokens. For instance, if there are five tokens, each will have a 20% proportion. Algo Rebalance 2 allows removing one token from the underlying list and keeps the removed token in a stable token(whitelisted iToken) that should be considered in the next cumulative swap. Emergency Rebalance addresses non-performing tokens by withdrawing them from their staking protocols and updating the vault's underlying tokens. The removed token's balance is transferred to the vault contract and can be withdrawn using the emergencyWithdraw() function, which requires specifying a recipient wallet address.
Staking & Unstaking:
âtv vaults are designed for yield aggregation, with options for passive yield optimization through staking in external protocols like Aave, CompoundV2, and CompoundV3 on Eth and CompoundV3, AaveV3, DForce and Readiant on Arbitrum. During cumulative swaps, 90% of the tokens are staked, while 10% remain on the âtv base contract. Unstaking occurs during redemptions or queued withdrawals, with 90% of the required tokens unstaked and 10% drawn from the base contract. This process ensures efficient management of user assets while capturing rewards and yields, which are reflected in the NAV. Emergency withdrawal features are also available to manage risks and ensure liquidity.
Redemption:
Investors can queue their âtv vault tokens to withdraw anytime after at least one cumulative swap since the last deposit. Upon depositing stablecoins, they receive locked âtv tokens, which can be queued to be withdrawn after a swap. Time-locked âtv tokens for additional yield must be unlocked first. Redemption occurs at the vault's prevailing NAV, with tokens swapped on Uniswap V3 into the chosen stablecoin, transferred to the user's wallet, and the redeemed âtv tokens burnt. Users have three withdrawal options: specifying a stablecoin (oToken), checking withdrawal amounts against contract proportions, or unstaking assets and swapping into the oToken. Withdrawal tokens can be paused/unpaused or removed/added to the input token list.
Fee distribution:
The fee structure comprises a 1% transaction fee deducted from the user's stables and credited to the aarnâ DAO multisig wallet, as defined in the âtvBase contract. The performance fee, set by aarnâ DAO at vault creation, ranges from 0% to 10% based on profits during redemption. Typically, a 10% fee is split with 6% going to the alpha creator and 4% to aarnâ DAO. âtvBase distributes the performance fee in stablecoins before depositing the redemption balance. Deductibles include a 1% fee to aarnâ protocol (DAO wallet#1) at investment, and up to a 10% profit share when redemption NAV exceeds deposit NAV, divided as 3-6% to the alpha creator (W#4), 2% to the engine, and 2% to aarnâ DAO (W#3). Profit sharing differs for instant and queued redemptions: instant profit is shared within the withdraw() function, while queued profit is collected by âtvOracle and distributed via unstakingProfitDistribution() by the cumulative swap controller. Funds are secured by the âtv base contract, accessible only to the specific investor.
Gas Fee optimization:
To lower transaction costs for aarnâ users interacting with âtv vaults, several design steps have been implemented. The cumulative swap design prevents users from incurring gas fees for swapping and staking deposit tokens, while the Queue Withdraw and Redeem mechanism eliminates high gas fees for unstaking and swapping, allowing users to initiate a withdrawal and claim tokens after platform execution.
To address centralization risks or single points of failure, the protocol has implemented multiple security features including multisigs, segregation of wallets for related functions, and a time-delay for critical functions. This setup enhances security by ensuring that specific actions can only be executed after a predefined delay, allowing time for review and potential rescind of queued transactions. Here's how the TimeDelayModule is utilized within the âtvBase:
Delayed Execution of Critical Functions: The TimeDelayModule is used to call critical functions such as emergencyWithdraw and updateTVLUpdatePeriod. This ensures that these functions cannot be executed immediately and must go through the delay period set in the DelayModule.
Emergency Withdrawals: The emergencyWithdraw function allows for the withdrawal of tokens from the contract to a specified wallet. This function is protected by the onlyDelayModule modifier, ensuring that it can only be called by the TimeDelayModule. This adds a layer of security by requiring the transaction to be queued and delayed before execution.
Updating TVL Update Period: The updateTVLUpdatePeriod function allows for updating the TVL (Total Value Locked) update period. This function is also protected by the onlyDelayModule modifier, ensuring that any changes to the TVL update period are subject to the delay period.
The transferOwnership function allows for passing on the ownership of a contract. This function is also protected by the onlyDelayModule modifier, ensuring that transferring ownership is subject to the delay period. The function imposes two step ownable’s pending owner functionality so that ownership is finally transferred to the receiver when it is accepted.
The pause() and unPause() functions within an âtv vault's withdraw() are protected by the timeDelay module, ensuring requests come only from the timeDelay contract. To pause or unpause, first set the timeDelay period to a shorter duration. Then, request a pause via the timeDelay contract with queueTransaction() and execute it with executeTransaction(). Finally, reset the timeDelay period to a longer duration.
aarnâ DAO is the owner or administrator of the âtv tokenization platform, and uses Gnosis multisig to govern or execute the features of the smart contracts. To adhere to the hierarchy approval and also manage roles and distribution of performance fees, the âtv system handles the transaction process by utilizing five wallets. Two of the main hierarchy wallets use Gnosis Safe multisig for approvals. Related functions are by design handled by different wallets to enhance security flow, for eg For the EmergencyRebalance() function that resides in âtvManager, the responsible wallet should be different from the caller of EmergencyWithdraw() in the âtvBase/Vault. Also, if profit Share Fee of Alpha Creator is present, it is included in Team Wallet
The âtv vault tokens are generally non-transferable or tradable by default, but this can be configured to allow transferability later. On redemption, the vault tokens are burnt.
The pricing of âtv tokens is based on the Net Asset Value (NAV) approach, reflecting the value and composition of underlying tokens plus any passive yield incomes from staking. NAV is calculated based on the total value locked divided by the sum of âtv tokens, with investments and redemptions based on the NAV. The initial price of each vault token is set at USD 100.
To reward early investors/liquidity providers to âtv vaults, aarnâ protocol has a staking and timelock rewards program. Users can stake (or lock) the âtv tokens on aarnâ for a selected time period. Based on the duration of lock and based on how early an investor invests and locks, a fixed APY would be applicable, which will be paid out in aarnâ tokens at the time of unlock.
Smart contract security efforts start before writing the first line of code – during planning, design, and development processes and end with securing against cyberattacks and potential vulnerabilities such as re-entrancy, front running, ETH send a rejection, integer overflow/underflow, DoS, Insufficient Gas briefing. The contracts have been extensively tested and have 100% test case coverage. And they have undergone a preliminary audit, and then a final audit by top tier audit firm , Certik.are undergoing a second audit by a top tier audit firm to ensure that the smart contracts go through manual code reviews and automated testing to certify full security of the aarnâ tokenization platform.
