# âtv tokenization

\> âtv tokenization platform

### What are âtv vaults?

The aarnâ tokenization platform enables decentralized, structured on-chain investment products âtv vaults, deployed on Ethereum, Sonic, and Arbitrum (soon on Base). It comprises:

1. Ethereum: 9 smart contracts (6 tokenization + delayModule + timelock + ASRT)
2. Sonic: 10 smart contracts (6 tokenization + dexAdapter + delayModule + timelock + ASRT)
3. Arbitrum: 10 smart contracts (6 tokenization + sequencer + delayModule + timelock + ASRT)

All smart contracts have undergone comprehensive audits and are fully tested for security and composability.

### vault types:

1. 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
2. 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
3. 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.

### âtv tokenization platform

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.

Ethereum >

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXckGK0M5q4G7wWdhOGcfITtwu4a0b5hExsDiCcqomn8EWtee9Z_xpWR_ckQJ1K6AozW9b_jo1_NEc4l8ryomukgnygo_gf_7BXPdsRJZZAgSye9LQPJ2-S-QcwEoKopAgLoh16s?key=4ZTbAfLFbnB8eJGb8BPb1A" alt=""><figcaption></figcaption></figure>

Sonic >

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXctebHjH8wv38KIQ5KbdixZyRTIt3AUy3RnyFvVvJDA3CnzxWqfe6cKtD6kFeTVDa_udgdXjD0AJK6PnR220U1zybzFW5vf2dNG7oxZCJ86_WEYEfpdASxVWUrWRZU6udEWtU61eg?key=4ZTbAfLFbnB8eJGb8BPb1A" alt=""><figcaption></figcaption></figure>

Arbitrum >

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXfLmIHKO8UbCQjnf2EhKpVh3MeaYRndB80-JsAkYzKvzSk0rPK2nx-KjTcjGyxaLzyxdW9s8uezLwDPECIwF5fzhm-3E5QoIqTH1xwUF5cRUgbY3BR16h4CuiFAhhw8Ii56HTrA2w?key=4ZTbAfLFbnB8eJGb8BPb1A" alt=""><figcaption></figcaption></figure>

### âtv smart contracts architecture

1. **â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.
2. **â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.
3. **â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.
4. **âtvStorage**: Stores all âtv product details, accessed through âtvBase and âtvManager. It contains TVL-related calculations for âtv products.
5. **âtvPassiveRebalanceStrategies**: Includes passive rebalancing strategies, which are enabled at vault creation. Rebalancing occurs automatically at set intervals.
6. **â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.
7. **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.
8. **TimeLock**: Timelock contract provides the stake/Deposit and unstake/Withdraw functionality to the users to generate rewards in $AARNA tokens. On staking, users receive ASRT (aarnâ Staking Reward Token) token as reward which can be exchanged with the AARNA.
9. **ASRT**: aarnâ Staking Reward Token is a standard ERC-20 token used as a reward token which can be exchanged for AARNA. The maximum supply of ASRT is set according to the staking program and each token has a fixed value of USD 1.
10. **DexAdapter**: The DexAdapter module encapsulates DEX swap operations within the ATV infrastructure. It abstracts and isolates chain-specific swap logic, enabling support for different networks, such as Sonic and Base Chain through dedicated implementations.
11. **DataConsumerWithSequencerCheck**: On L2 chains like Arbitrum, if the sequencer goes down, oracle prices can become outdated. Chainlink’s Sequencer Uptime Feeds let contracts detect when the sequencer is offline or has just come back online. This helps prevent using stale prices during critical actions like swaps or rebalances, reducing risk and improving protocol safety. "DataConsumerWithSequencerCheck" follows Chainlink's Sequencer to serve the above purpose.

### Key âtv design features&#x20;

#### deployment & upgrade flow

* Initial deployment is handled via aarnâ ops wallet.
* Post-deployment, ownership of contracts is split across multisig wallets:
  * W#1 controls factory, base, manager, and rebalancer contracts.
  * W#2 controls oracle, storage, and delay module.
* Contracts are non-upgradeable; upgrades are implemented through new deployments and vault migrations.
* DAO control increases progressively with decentralization milestones.

#### vault creation

Vault creation at aarnâ is initiated either by the DAO or by approved alpha creators who propose new strategies. After passing an off-chain governance process (soon to move fully on-chain) the âtvFactory smart contract is triggered to deploy a new vault with the selected strategy logic and token configuration. Each vault is a standalone, modular smart contract inheriting core infrastructure for NAV computation, tokenization, and execution flow.

Vaults follow a transparent, on-chain fee structure designed to align incentives across users, alpha creators, and the protocol. A 1% platform fee is charged at the time of deposit and held in the protocol’s platform wallet. Additionally, a performance fee, capped at 10% may be applied on realized gains, split between the alpha creator and the DAO based on a predefined ratio. These fees are automatically enforced via smart contracts and are reflected in the real-time NAV, ensuring clarity, accountability, and trust across the system.

### vault mechanics

1. **Deposits \[Stablecoins]:**

Users can deposit the selected iTokens 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 1inch or Uniswap V3 on Ethereum and Arbitrum or Odos on Sonic. The Deposit function can be paused in a critical situation by the pause() function that resides in the vault.&#x20;

2. **Net Asset Value (NAV):**

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.

3. **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.

4. **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. reinitializeVault function can also be invoked when the underlying token list is empty to Reinitialize the vault with a new set of underlying token configurations, ensuring proper accounting and functionality continuity.

5. **Staking & Unstaking:**

âtv vaults are designed for yield aggregation, offering passive yield optimization by staking assets into external protocols. On Ethereum, assets are aggregated across Aave, Compound V2, and Compound V3; on Arbitrum, staking is done via Aave, Compound V3, DForce, Morpho, and Dolomite; while on Sonic, assets are routed through Aave and then paired with Pendle LP pools. The staking strategy on Ethereum and Arbitrum focuses on aggregating liquidity into integrated lending protocols. On Sonic, the strategy is extended—staked aUSDC is further supplied into Pendle LP pools to capture additional yield layers.&#x20;

During cumulative swaps, a portion (x%) of the vault’s assets is staked based on the stakePercentage configured for the vault, while the remaining (100-x)% stays on the âtv base contract. Unstaking is triggered during redemptions or queued withdrawals, where x% of the required amount is unstaked and the remaining (100-x)% is sourced directly from the vault contract. This design ensures efficient asset management while capturing rewards and yields, which are reflected in the vault’s NAV. Emergency withdrawal functions are also integrated to manage protocol risks and maintain liquidity when needed.

6. **Redemption:**

Investors can either have the option for Direct withdrawal or queue their âtv vault tokens to withdraw anytime after at least one cumulative swap since the last deposit based on the vaults. 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.

7. **Fee distribution:**

The âtv vaults implement a two-tier fee structure. A 1% platform fee is deducted from user deposits and credited to the aarnâ DAO multisig wallet, as defined in the âtvBase contract. Additionally, a performance fee—ranging from 0% to 10% and set by the aarnâ DAO at vault creation—is applied on profits at redemption. Typically, a 10% performance fee is split as 6% to the alpha creator and 4% to the DAO. This fee is distributed in stablecoins before the redemption balance is deposited. Thus, total deductibles include a 1% investment fee and a variable performance fee (up to 10%) if the redemption NAV exceeds the deposit NAV. For instant withdrawals, profit sharing is executed within the withdraw() function, whereas for queued redemptions, profits are tracked by the âtvOracle and distributed via unstakingProfitDistribution() by the cumulative swap controller. All user funds are securely held in the âtvBase contract and are only accessible to the specific investor.

8. **composability via âtvUSDC (WTL - erc4626 wrapper)**

To enable composability across DeFi protocols, yield optimization âtv vaults can be wrapped into âtvUSDC, a yield-bearing ERC-4626 token. This is done via the Wrapped Timelock (WTL) contract.

* Users deposit their âtv tokens into WTL
* âtvUSDC is minted 1:1 based on current NAV
* Yield continues to accrue while locked
* Tokens are composable with protocols like Pendle

This design allows external DeFi protocols to integrate with âtv yield mechanics without disrupting vault-level accounting or NAV calculation. Unwrapping reverses the process.

9. **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.

### Multisig and TimeDelay&#x20;

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:

1. **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.
2. **Emergency Withdrawals:** The emergencyWithdraw function allows for the withdrawal of stray tokens (Not in iToken or uToken list) 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.
3. **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.
4. **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.

## Approval hierarchy for âtv

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

## Tokenomics of âtv vaults

1. ### Transferability&#x20;

The  âtv vault tokens are generally non-transferable or tradable by default, However, this is configurable. So, the token can be made transferable if needed. Tokens are minted in the user wallet at the time of deposit and burned at redemption.&#x20;

2. ### NAV based âtv pricing

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.&#x20;

3. ### âtv staking & timelock rewards&#x20;

To reward early investors/liquidity providers to âtv vaults, aarnâ offers two types of staking and timelock reward programs based on the vault type. In the first timeLock 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. In the Wrapped Timelock (WTL) model, users deposit âtv tokens to receive âtvUSDC, a yield-bearing ERC-4626 composable token, and earn rewards based on the yield generated over the holding period.

## Security audit of âtv

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, obtaining a high security score on Skynet. Also aarnâ has a running Bug bounty program for both the smart contracts and the Dapp.

[Link to audit report >](https://skynet.certik.com/projects/aarna-protocol)

\
