# Protocol Overview Access the value of your crypto without selling it, and let your collateral pay down the loan for you. Altitude is a non-custodial protocol that puts your deposited assets to work, automatically reducing your debt over time. Altitude actively manages users' debt and collateral in real-time. Most lending protocols leave your unused borrowing power sitting idle. Altitude puts that capital to work earning yield that pays down your loan.
When a user takes out a loan from the Altitude it will be optimized in the following : 1. Your debt is continuously refinanced at competitive rates across integrated protocols 2. Altitude borrows on your behalf to earn yield for you 3. The earned yield reduces your debt One deposit. One dashboard. Capital that works while you wait. # Optimizing Borrowing Rates Borrow rates fluctuate constantly across DeFi lending pools as utilization changes. Altitude monitors these rates continuously to see when more advantageous rates become available. When Altitude finds a lower rate on an integrated protocol like Aave or Morpho, it refinances your loan to capture that rate. No manual monitoring required. # Actively Managing Idle Capital When you borrow less than the maximum allowed, you have unused borrowing power. Most protocols let this sit idle, doing nothing. We call this 'idle capital,' and Altitude puts it to work earning yield on your behalf. For example, if you deposit $10,000 of ETH, you could borrow up to 80% ($8,000 USDC). But borrowing at the maximum is risky if ETH drops in value, so you might borrow only 30% ($3,000 USDC) to stay safe. That leaves 50% of your borrowing power unused. Most protocols let that sit idle. Altitude activates a portion of it to generate yield that pays down your loan.
Altitude automatically activates part of this idle capital to generate yield on behalf of its users. Yield earned is automatically used to repay part of users’ debt. ## Changes in value of collateral If the value of a user's collateral goes **up** and the user doesn't add or remove collateral, the loan-to-value for the user will **decrease** (just like other lending protocols). Altitude will then borrow more, so that there's more capital at work. If the value of a user's collateral goes **down** and the user doesn't add or remove collateral, the loan-to-value for the user will **increase** (just like other lending protocols). Altitude will then borrow less, to reduce the overall loan-to-value to the vault's preset. Your capital is finally working as hard as you did to earn it. # How do users interact with a vault? Using Altitude follows a simple flow: deposit your collateral (cbBTC or wstETH), borrow USDC against it, and let your collateral earn yield that automatically pays down your loan. When you're ready, repay any remaining balance and withdraw your collateral. In this section you'll find details on each action. # Deposit The deposit function allows a user to transfer the supply asset of the vault and receive supplyTokens in exchange. `deposit(uint256 amount, address onBehalfOf)` * **amount** - the amount the user wants to deposit. The user must approve this amount prior to deposit. * **onBehalfOf** - the address onBehalfOf who this deposit is made, typically the user themselves Upon receiving a deposit the vault will deploy this collateral into the active lending provider to be used as collateral. {% hint style="info" %} **supplyToken** A supply token is issued to represent each supply asset the user is owed. This is an interest bearing token and its value can go up over time, in line with interest received on our lender deposits. Each supply token represents one supply asset (e.g. WETH) token. {% endhint %} # Borrow User borrows the specified amount of borrow assets from the vault and receives borrowTokens in exchange to represent their debt. `borrow(uint256 amount)` * **amount** - the amount the user wants to borrow Upon receiving a request for a borrow the vault will check how this request would affect the users position and if within specified margins will borrow the required amount from the active lending provider. {% hint style="info" %} **borrowToken** A borrow token is issued to represent the debt owed by the user. This is an interest bearing token and therefore the users debt can go up over time, where this increase will be in line with interest charged on our lender debt. When calling the `balanceOf` function on a borrow token any loan reductions will be calculated also. As debt is non-transferrable, borrow tokens can not be transferred to other users. {% endhint %} {% hint style="warning" %} **Thresholds** There are several thresholds that impact the user position: **supplyThreshold** → users can actively borrow and withdraw but their loan-to-value should stay below this value **liquidationThreshold** → the user position can be liquidated if their loan-to-value is higher than this value {% endhint %} # Withdraw User transfers supplyTokens and receives the vault supply assets in return `withdraw(uint256 amount, address to)` * amount - amount the user wants to withdraw * to - address to which the funds should be sent The user can withdraw up a loan-to-value ratio of the specified `supplyThreshold`. #### Withdraw fee There is a withdrawal fee applied for the users depositing and withdrawing within a short period of time. The fee is charged in the supply asset and is distributed among the other users. The reason for having such a fee is that when one deposits, the vault will do a rebalance to borrow more and deposit it into the farm provider for generating more yield. This can incur fees and slippage. With the time the fee is covered by the yield rewards. But without enough time, this is a cost to the vault. The fee is currently configured to be 0.5% for withdraws within 150 blocks (\~30 minutes). # Repay User transfers vault borrow assets to reduce their own debt or the debt of another user who has approved them to repay `repay(uint256 amount, address onBehalfOf)` * amount - amount the user wants to withdraw * onBehalfOf - address onBehalfOf who the loan should be repaid # Claim Rewards If you've deposited collateral but haven't taken out a loan, your share of the yield still accumulates. Instead of reducing a loan balance, these rewards collect in your account and can be withdrawn anytime through the claimRewards function. This option suits users who want yield exposure without borrowing. These earnings can be withdrawn through the claimRewards function. `claimRewards(uint256 amountRequested)` * amountRequested - amount the user wants to withdraw # Other user functions There are a number of other functions that can be utilized by users in specific scenarios. * **depositAndBorrow** → combining deposit and borrow in a single transaction * **repayAndWithdraw →** combining repaying and withdrawing in a single transaction * **commitUser** → update an individual account, recognising earnings/losses from yield farming * **liquidateUsers** → liquidate one or more user unhealthy user positions * **allowOnBehalf** → allowing a users to authorize a specific address to act on its behalf * **borrowOnBehalfOf →** a pre-approved user borrows assets on behalf of another user * **repayBadDebt →** repaying bad debt for a user who’s supply token balance is 0 # User Position Health If your personal loan-to-value ratio rises above the liquidation threshold (due to collateral value dropping or debt increasing), your position may be liquidated. During liquidation, a portion of your collateral is sold to repay your debt, and a liquidation penalty applies. You can see details of the configuration on the transparency page in the app. Altitude's rebalancing process helps maintain healthy vault-level positions, but individual users are still responsible for monitoring their own LTV and adding collateral if needed. The section below covers a different scenario: what happens if the entire vault faces liquidation. This is rare and requires multiple safety mechanisms to fail simultaneously. # Vault Health Each vault has defined Loan-to-Value parameters. Check the app dashboard for current thresholds per vault. To keep its own loan-to-value ratio healthy, the vault may withdraw the required borrow amount from the farmStrategy during the following user transactions: * withdraw → withdrawing from the farmStrategy and repaying part of the lender debt * borrow → withdrawing from the farmStrategy and providing funds to the user * claimRewards → withdrawing from the farmStrategy and providing funds to the user If the farmStrategy has this amount available in its buffer it will provide this amount from the buffer. Where this is not the case it will withdraw the requested amount from the yield farm directly. # Ingress Control For improved security we have an ingress control contract that independently controls under which conditions certain user functions can be executed. Capabilities include: * pausing → ability to pause either the whole protocol or specific functions * rate limit → restricted outflows of funds (for withdraws, borrows and claim rewards) * allow/sanctioned lists → ability to control access from specific addresses These allow the protocol to be more resilient to extreme market conditions. # Yield Generation Process Altitude generates yield by deploying your idle capital into carefully vetted strategies across protocols like Pendle, Morpho Earn, and Ethena. This yield is harvested regularly and automatically applied to reduce your loan balance. The sections below cover how this process works and how individual supply token holders can influence where yield is allocated.
# What is a vault? The protocol uses a vault for each currency pair, each with a fixed supply asset and fixed borrow asset. The supply asset is the crypto asset users can deposit and use as collateral for a loan; the loan received will always be received in the borrow asset. # How much is deployed into yield farms? Once a user has successfully supplied the supply asset into a vault, this is added to the vault position with an external lender and can subsequently be used as both: 1. collateral for a loan by the user 2. collateral used for yield generation on behalf of users For each vault, a vault target threshold (vtt) is configured, which is the loan-to-value ratio the vault will aim to rebalance to during certain transactions (see more later in document). The amount of assets deployed into yield farms is determined by the following formula: $$$ $$ vTAA = (vS \* P \* vTT) - vUB $$ $$$ where: * vTAA = vault target active assets is the target amount deployed into yield farms * vS = vault supply assets, the total amount supplied by users into the vault * P = price of the borrow asset * vTT = vault target threshold, determining how much to deploy in yield farms * vUB = vault user borrows, total amount of borrow assets borrowed by users Factors such as price movements and changes in either the amount of supply assets and/or user borrows will affect vault target active assets. # When do we interact with Yield Farms? Certain vault actions will trigger the vault to either deposit or withdraw to/from the yield farms. ## Rebalance Calling the rebalance function will result in the protocol either depositing in or withdrawing from the Yield Farm. If we are actively farming, then the loan-to-value ratio with the lender will be close to the vault target threshold after the rebalance has completed. ## Out-of-buffer user actions Whenever a user either borrows, withdraws or claims rewards, the vault checks (in addition to user position checks) if the vault will be borrowing more than the vault target active asset amount after the user action. At this point the vault will aim to get back to its target borrow amount by withdrawing from the Yield Farms and repaying part of its outstanding debt. As interactions with the Yield Farms tend to be associated with high gas costs we have a buffer to shield users from these gas costs. Therefore, only actions that can’t be supported from this buffer will interact directly with the external Yield Farm(s) ## Maintenance In addition to the above, there are a few areas such as migrations from one Yield Farm to another, withdrawing from the reserve and managing potential losses where we will also interact with the Yield Farms. # Migrations ## Yield Farm Migrations When we choose to migrate from one farm to another all funds in one farm strategy and withdrawn and redeposited into the specified strategy. ## Lender Migrations When we choose to migrate from one lender to another, all funds in the lender strategy are repaid using a flash loan and the position is moved to the new lender strategy. High level steps are: 1. take flashloan 2. repay debt from old lender 3. withdraw collateral from old lender 4. deposit collateral with new lender 5. borrow from new lender 6. repay flash loan {% hint style="info" %} Migration fees in the form of flash loan fees are distributed to users. {% endhint %} # Liquidation of vault In rare conditions, it would be possible for the entire vault to get liquidated, which would trigger a supplyLoss event. The scenarios in which this can happen are: 1. **Failure of Liquidation**: If the liquidation process for individual users isn’t happening, this can cause the protocol as a whole to be at risk. If users with high LTVs aren’t being liquidated then the overall vault LTV would be affected by this. 2. **Failure of Rebalancing**: The rebalancing processes doesn’t manage to keep the vault position healthy, this could be when the rebalancing process isn’t triggered on time (note: anyone can execute this and there are multiple mechanisms in place to do so) Although this scenario is unlikely we do have capability built in to deal with it if it does occur. ### What happens on a supplyLoss event? If the vault is liquidated then the following would happen to the balances of the lenderStrategy: * Borrowed amount would reduce * Supply amount would reduce by the same amount + liquidation incentive ## How we deal with supplyLoss events? In order to deal with a this scenario correctly we need to treat impacts originating from user loans and farm loans differently. 1. **Farm Loans**: the vault has access to a farmWindfall as its loan will be partially repaid 2. **User Loans**: the user will still have access to the funds they borrowed Key goals for the process are: * *Don’t increase user LTV’s -* We want to avoid a vault liquidation causing a user to become subject to liquidation. To achieve this we don’t want users with a healthy LTV see their LTV increase. * *Don’t increase user accessible balances -* we don’t want an individual user to benefit from the vault being liquidated. This means their accessible balance (consisting of the amount they can withdraw from the vault and the amount they originally borrowed) should not increase. ### Approach What we want to do when dealing with a supplyLoss event is breaking the impacts of supplyLoss into two separate problems; deal with impacts arising from the vault borrowing on behalf of users and deal with impacts arising from user borrowing. #### SupplyLoss Event (e.g. vault liquidation) When the supplyLoss event happens we have the following immediate impacts to our position with the lender: * **liquidationIncentives**: the liquidation bonus received by the liquidator. Typically expressed as a percentage of the amount repaid * S**hifting balances**: the balances are shifted from the supplyAsset to the borrowAsset (loan is repaid and collateral is reduced) #### Step 1: Settle vault balances To allow for clean distribution we need to deal with any positions the vault has taken on behalf of users first. Therefore if the vault had any lending position prior to the supplyLoss event occurring, we settle any outstanding balances: * Close down any positions it has taken (`withdraw & repay`) * Use any surplus (farmWindfall) to restore as much as possible of the supplyLoss caused by the vault position (`swap & deposit`) This leaves us with a balance that is as close as possible to what it would be if the vault had not taken out a lending position. Settling impacts: * **Increase supply:** we use the unintended farmWindfall to improve the overall position of the vault with the lender. * S**lippage**: any slippage paid when swapping from the borrowCurrency to the supplyCurrency * **DepositFees**: any fees paid when depositing into the lender (these are expected to be close to 0) The resulting position the vault has with the lender is now closer to what it would be if the vault had not taken out a position for farming on behalf of users. #### Step 2: **Distribute impacts** After this we end up with the following impacts that need to be distributed to users as best as possible: * **Fees:** we have liquidation, slippage and deposit fees that cause a real reduction in the assets we have available. As all users benefit from vault farming activities, it makes sense for these costs to be distributed to all users equally, we distribute these based on user supply positions. * **Shifted positions:** in addition we still have positions that have shifted. As we have already settled the changes resulting from the vault lending on behalf of users, we now only need to deal with changes in positions cause by user borrowing. To achieve this we distribute the remaining supplyLoss & borrowLoss based on user borrowing positions. # FarmMode Decisions ## Introduction There are a few specific scenarios where we believe the risk of farming is too high and we will aim to stop any farming processes. These are: * **Farm value drops**: when the value of the assets in the farm has dropped * **Price discrepancies**: when there is an inconsistency between prices reported by selected oracles * **Extreme market conditions**: in some cases there may be extreme market conditions We have a smart contract (`farmModeDecisionMaker`) that is specifically looking at cases in which this has happened. This contract monitors both unexpected pricing behaviour as well as drops in farm balance value. # How are yields recognised? Yields are recognised through the harvest process. During this process, we: * Claim and swap any reward tokens received from the Yield Farm * Recognise any balance changes (positive or negative) These changes in the farm balance are logged in a harvest snapshot that can be used for distribution to users at a later date. In case of earnings, these are either used to decrease the users loan or give the user access to claimable rewards. When there are farm earnings, we also reserve a certain percentage as vault reserve as displayed on the vault information page. Should the farm have suffered a loss, this is distributed to users in the form of an increase in their loan value. The harvest process is run periodically. {% hint style="info" %} Each harvest is captured in a snapshot that stores key details about yields recognised and the state of the vault at the time. {% endhint %} ## When do harvests happen? Harvests happen weekly, usually on Wednesdays between 8am UTC and 11am UTC. # How are yields distributed? Generated yields are fully distributed to users after they (or someone else on their behalf) interacts with the protocol. At this point, any balance changes, resulting from previous harvests, are committed to the users’ account. Distribution from each harvest performed based on the following calculation: $$ uCh = ( uSh \* Ph \* vLTh - uBh ) \* nCh / ( vSh \* Ph \* vLTh - vUBh ) $$ where: * uCh = user change resulting from the harvest * uSh = user supply at time of the harvest * Ph = price of the borrow asset at time of harvest * vLTh = vault liquidation threshold at time of harvest * uBh = user borrows at time of harvest * nCh = net change in harvest (farm earnings - farm losses) * vSh = vault supply at time of harvest * vUBh = vault user borrows at time of harvest The value of uCh is either subtracted from the users’ loan balance, or where no loan is due allocated to the user as claimable rewards. These can be claimed by the user at any time. These changes are all tracked in the borrow asset currency (e.g. USDC). #### Possible adjustments In order to remove any incentives for users to not contribute throughout the whole harvest period any rewards meeting the following criteria are allocated to the vault reserve: * Rewards from users who’s loan-to-value is higher than the target threshold at the time of harvest * Rewards accrued by users before their last interaction with the vault in this harvest period For the avoidance of doubt, interest still accrues on the users’ original position until they have been committed. Therefore it may be beneficial for a user to directly commit their position by calling the commit function directly. {% hint style="info" %} **Why does the users original debt still accrue interest?** Of the net amount recognised during a harvest we don't know what percentage will be used to: 1. reduce user loans → with implications for debt interest on user positions 2. as claimableEarnings for users without a loan → no implications on debt interest for the user positions As such without committing everyone after each harvest, we don't know how much debt that accumulates each harvest should be covered by individual users or the vault. {% endhint %} # How do we determine which Yield Farms to use? The users who have supplied assets into the vault determine which yield farming strategy the vault should use. This is achieved through Yield Allocation Proposals, where each successful proposal will go through the following life-cycle: * Preparation: preparing the yield allocation proposal * Submission: users that hold supply tokens can submit proposals on Snapshot * Voting: users that hold supply tokens can vote on these proposals on Snapshot * Build: creation of changes needed to execute a proposal * Executing: any successfully approved proposal will be executed We will go over each stage in more detail here. ## Preparation In order to be executed, each successful proposal therefore needs to have: * Risk assessment: an assessment of the risks associated with the allocation proposal * Yield projection: a projection of yield that can be generated if the allocation proposal is executed * Optional: with a view of speeding up the build stage the following may be provided also: * Smart contract changes: changes to smart contracts required to implement the proposal * Configuration changes: changes to the configuration required ## Submission Once the proposal has been prepared, any users with enough supply tokens can submit proposals to change the allocation of yield farming funds. All relevant information should be included in the proposal to enable informed voting. {% hint style="info" %} Number of supply tokens needed to submit a snapshot proposal = 1 token {% endhint %} {% hint style="info" %} The proposals are located here: **wstethUsdc\_v1**: **wstethUsdc\_v2**: **cbbtcUsdc\_v2**: {% endhint %} ## Voting All users with supply tokens can vote on Yield Allocation Proposals, where the following parameters are applicable to proposals. | Quorum | Minimum percentage of votes cast on a proposal before it is valid and can be executed | 1% | | ------------- | ------------------------------------------------------------------------------------- | ---------- | | Voting period | Minimum duration during which a proposal can be voted on | 24 hours\* | \*Two exceptions: * in the event of extreme market conditions we reserve the right to reduce the time period which Supply Token holders have in which they can vote on an Allocation Proposals * if the holders of a sufficient number of votes vote in favour of an Allocation Proposal option, such that it is not possible for other vote holders to outvote those in favour of that option, the Allocation Proposal shall be deemed passed. ## Build There are two categories of changes; each will require a different level of effort at this stage: | Config | Development | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |

Config type proposals are proposals that can be executed with configuration changes only. As such they will typically only require:


  • Detailed configuration changes
|

Development proposals require further development before they can be executed. As such they will typically require:


  • New or updates to smart contracts
  • Detailed configuration changes
  • Smart contract security audits
| At this stage Altitude Protocol Inc. will lead the build process for the proposal and prepare it for execution. ## Execution Once a proposal has been approved and built, it will be executed by Altitude Protocol Inc, but only if the following conditions are met: | Expired |

No more than 1 working day has passed since the proposal was approved.


Note: due to the build time required it is likely that all ‘development’ proposals will expire before they can be executed. In these cases a new ‘config’ proposal will be required to be passed once the build stage is complete.

| | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Superseded | There are no new proposals that have superseded this proposal (for example if approval a new proposal was submitted and approved) | | Assessment(s) invalidated | Information provided in the Risk and or Yield Assessment has subsequently been invalidated | | Extreme market conditions | The market isn’t subject to extreme market conditions at time of execution | In case a proposal doesn’t meet these criteria it may be required to submit a refreshed proposal for execution. \ \

# How will Altitude work at times of high volatility? During periods of high volatility we expect to see a number of different effects in the market. **Increased liquidations** As the value of collateral decreases it is expected to see more user positions becoming undercollateralized. Similar to other lending protocols, Altitude has a process by which loans can be liquidated. The liquidation threshold is configured per vault and can be found on [app.altitude.fi](https://app.altitude.fi). For avoidance of doubt: the lender's liquidation specs are not relevant for the user, as Altitude's smart contracts govern the liquidation process. The lender liquidation mechanism & threshold are only relevant for the vault as a whole. These liquidations can be triggered by external liquidators, but in addition to this, Altitude is running this process itself as well. **Increased rebalancing** With frequent changes in prices, Altitudes’ rebalancing process will be triggered more frequently. Typically the rebalancing activity is triggered by bots that run on the Gelato network, it is anticipated that this will continue to work even in times of high volatility. As an extra safety mechanism, Altitude can trigger an urgent rebalance, this will overpay on gas to ensure the transaction is executed promptly. Triggers for this urgent rebalance are when Altitudes’ health factor: * is out of bounds for n-blocks or more * reaches a predefined minimum (our emergency minimum) With this mechanism Altitude has a safety net for high volatility but also any possible issues with the Gelato network. **Disabling Farming** In extreme cases where the market is so volatile that it is not possible to foresee how various farming strategies will perform, Altitude can also enter into a mode where the vault is no longer farming. To limit Altitudes’ exposure to farm losses, when operating in this mode, all funds from farming are withdrawn, and Altitude's loan is repaid. Disabling farming is triggered manually. # How do my rewards change when I interact with the vault? When you change your collateral position (deposit or withdraw), your pending harvest earnings reset. This ensures fairness: rewards are calculated based on how long your assets have been active during each harvest period. Everyone earns proportionally to their contribution. When you borrow more, your pending earnings don't fully reset, but your next harvest will be smaller since you've left less capital available for yield generation. The Pending Harvest rewards that the user will no longer receive are allocated to the vault reserve. ALTI token rewards work differently. These are earned by block based on your collateral amount, so borrowing and repaying don't affect them. # Lender Determination Process The lender determination process is the process through which Altitude switches between different lending protocols. We cover how this process works and how individual supply token holders can influence this process.
# How do we determine which Lender to use? The users who have supplied assets into the vault determine which lending strategy the vault should use. This is achieved through Lender Determination Proposals, where each successful proposal will go through the following life-cycle: * Preparation: preparing the lender determination proposal * Submission: users that hold supply tokens can submit proposals on Snapshot * Voting: users that hold supply tokens can vote on these proposals on Snapshot * Build: creation of changes needed to execute a proposal * Executing: any successfully approved proposal will be executed We will go over each stage in more detail here. ## Preparation In order to be executed, each successful proposal therefore needs to have: * A list of all available lending strategies * The current interest rate for each lending strategy * Optional: with a view of speeding up the build stage the following may be provided also: * Smart contract changes: changes to smart contracts required to implement the proposal * Configuration changes: changes to the configuration required ## Submission Once the proposal has been prepared, any users with enough supply tokens can submit proposals to change the allocation of yield farming funds. All relevant information should be included in the proposal to enable informed voting. {% hint style="info" %} Number of supply tokens needed to submit a snapshot proposal = 1 token {% endhint %} ## Voting All users with supply tokens can vote on Yield Allocation Proposals, where the following parameters are applicable to proposals. | Quorum | Minimum percentage of votes cast on a proposal before it is valid and can be executed | 1% | | ------------- | ------------------------------------------------------------------------------------- | ---------- | | Voting period | Minimum duration during which a proposal can be voted on | 24 hours\* | \*Two exceptions: * in the event of extreme market conditions we reserve the right to reduce the time period which Supply Token holders have in which they can vote on an Allocation Proposals * if the holders of a sufficient number of votes vote in favour of an Allocation Proposal option, such that it is not possible for other vote holders to outvote those in favour of that option, the Allocation Proposal shall be deemed passed. ## Build There are two categories of changes; each will require a different level of effort at this stage: | Config | Development | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |

Config type proposals are proposals that can be executed with configuration changes only. As such they will typically only require:


  • Detailed configuration changes
|

Development proposals require further development before they can be executed. As such they will typically require:


  • New or updates to smart contracts
  • Detailed configuration changes
  • Smart contract security audits
| At this stage Altitude Protocol Inc. will lead the build process for the proposal and prepare it for execution. ## Execution Once a proposal has been approved and built, it will be executed by Altitude Protocol Inc, but only if the following conditions are met: | Expired |

No more than 1 working day has passed since the proposal was approved.


Note: due to the build time required it is likely that all ‘development’ proposals will expire before they can be executed. In these cases a new ‘config’ proposal will be required to be passed once the build stage is complete.

| | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Superseded | There are no new proposals that have superseded this proposal (for example if approval a new proposal was submitted and approved) | | Assessment(s) invalidated | Information provided in the Risk and or Yield Assessment has subsequently been invalidated | | Extreme market conditions | The market isn’t subject to extreme market conditions at time of execution | In case a proposal doesn’t meet these criteria it may be required to submit a refreshed proposal for execution. \ \

# The ALTI Token **Utility & Staking** The ALTI token will be the [Altitude.fi](https://www.altitude.fi/) protocol's governance token. The governance system will use a weighted voting system in which the amount of ALTI tokens held determines voting power. Both vested and unvested tokens will have voting power. ALTI holders will be able to vote on changes to the protocol, including: * Changing the performance fee * Deploying new yield farm strategies * Deploying new lending strategies **Non Transferability** The ALTI token will be deployed as non-transferable. **Supply Information** The ALTI token will be an ERC20 utility token. The supply of ALTI is capped at 1,000,000,000 (1 billion). The ALTI token will be deployed by Altitude Labs Limited. The address will be published here after the token has been deployed. **Current Distribution**

ALTI token allocation per May 2025

As of May 2025, the ALTI allocation is as follows: * Ecosystem & Community: 42.6% * Airdrops, community raise, community grants, partner incentives, ecosystem expansion, staking rewards. * Altitude Foundation: 5.0% * Token allocation to be used for the growth & advancement of the protocol. This will not go to the team. * Team & advisors: 26.4% (at least 6 months lockup, at least 30 months linear vesting) * Pre-seed investors: 11.4% (6 months lockup, then 30 months linear vesting) * Seed investors: 10.6% (6 months lockup, then 30 months linear vesting)
# ALTI rewards program ### **How do I join the program and what are the entry requirements?** To start accumulating ALTI, all you need to do is deposit assets (cbBTC and/or wstETH) into one of our vaults. ### Earn more by borrowing When the assets (cbBTC & wstETH) are deposited, you can borrow USDC. Altitude’s offers a unique borrowing experience, where the generated yield is used to pay the loan back over time To incentivize depositors to test out this borrowing mechanism, Altitude provides a 20% boost on the public incentives for users that borrow with a loan-to-value ratio of 5% - 25%. This additional incentive is attributed on a daily basis to users that, on that day, have a loan-to-value ratio of between 5% and 25%. Example: If the public incentives are 15% APR from ALTI incentives and if you have a loan with a loan-to-value of between 5% and 25%, you will get an additional 3%, resulting in an 18% APR from ALTI incentives. Tip: if you want to maximize your incentives and not have to worry about price fluctuations, borrow at 10% loan-to-value. This means that when the value of your collateral doubles or halves, you will still earn the maximum amount without having to adjust your position. ### **Will I be able to see how many ALTI tokens I have accumulated?** Yes, you can see how many ALTI tokens you’ve accumulated via the user interface at app.altitude.fi ### **How often are my rewards updated?** We currently run the Token allocator bot once a day and they allocate tokens according to the running campaign rules. ### **How are the tokens allocated?** Participants of the program are gaining tokens on a per-block basis. There are roughly 7,200 blocks in a day. Example: if 40,000 tokens are allocated per day, that's roughly 5.55 ALTI tokens per block. The ALTI tokens will be allocated across all participants per block, issued to each participant as a percentage of the total pool. If you withdraw your deposit, you will accumulate tokens up until the last full block you had an active stake. *** *Disclaimer: This Early Rewards Program is not directed at retail clients, it is directed only at sophisticated investors. Dealing in cryptoassets is high risk, and all capital used to participate is at risk of being lost.* *The Early Rewards Program is not available to persons in the USA, China, or other restricted territories.* *In the UK, the Early Rewards Program is directed only at persons who fall within an exemption to the restriction on financial promotions as set out in the Financial Services and Markets Act 2000 (Financial Promotion) Order 2005, such as investment professionals (Article 19); high net worth companies, unincorporated associations etc (Article 49); and sophisticated investors (Article 50).* # Team Milestones Since we started working on Altitude in 2021, we have *never stopped* building. Some of our most notable milestones include: **2022** * Closed our first funding round of $2.1 million. Read the full announcement[ here](https://news.bitcoin.com/altitude-has-secured-a-2%E2%80%A41m-funding-round/). * Launched the first version of our smart contracts (ETH-USDC vault) on Mainnet for testing purposes. **2023** * [Secured a $15k grant](https://x.com/AaveGrants/status/1709564435092877315) from Aave to help fund the integration of[ Altitude.fi](http://altitude.fi) into their ecosystem, along with a second security audit (completed). * Built integrations with Compound v3 and Aave v3, and support for wstETH. * Addressed learnings from our deployment of the contracts on Mainnet, including: * Making transaction manager for bots more robust; * Development of a shared SDK for off-chain components (bots and dashboards); and * Logging infrastructure. * Completed the first security Audit of[ Altitude.fi](http://altitude.fi)’s smart contracts with[ Omega](https://teamomega.eth.limo/). * Built the user interface for the first[ Vault](https://app.altitude.fi/) (wstETH-USDC). * [Whitelist](https://x.com/AltitudeFi_/status/1737848326442348633) for the Closed Beta was launched to allow third parties to deposit into the Vault. **2024** * Announced our second funding round of $4 million. Read the full announcement[ here](https://x.com/AltitudeFi_/status/1744674260449206778). * Completed a second security Audit of[ Altitude.fi](http://altitude.fi)’s smart contracts with[ Oxorio](https://x.com/AltitudeFi_/status/1820819083937403133). * Launched Closed Beta to allow the community to begin deposit into the Vault while testing its user interface. * Officially launched our first community Rewards Program. **2025** * Completed the security audit of Parallel Farming with [Omega](https://github.com/OmegaAudits/audits/blob/main/202501-Altitude-parallel-farming.pdf). * Deployed the new cbBTC vault for testing purposes * [Partnered with Hypernative](https://www.altitude.fi/post/altitude-partners-with-hypernative) for real time threat monitoring * Public launch of the cbBTC and wstETH vault * Achieved a total of $29M in deposits # Backers We are backed by some of the most respected names in Web3. In January 2024, we announced a $4 million investment from Tioga Capital, New Form Capital, GSR, G1, UDHC, Flow Ventures, Owl Ventures, Soft Holdings and Metavision alongside prominent angel investors, such as Marc Zeller of Aave. This follows us closing a round of $2.1M in pre-seed funding from a group of over 50 strategic Web3 founders and builders in 2022, including (in alphabetical order): Ahmed Al-Balaghi and Aniket Jindal (Biconomy), Ben Lakoff (Charged Particles), Ben Jones (Nuri), Benjamin Fielding and Harry Grieve (Gensyn), Danish Chaudhry (Paper Ventures), Diego Lijtmaer (Rumi Finance), Facu Ameal (Yearn Finance), Gavin Birch, James Parillo (Figment), Georgi Spasov, Nick Todorov (LimeChain), Graham Rodford (Archax), Ivo Georgiev (Ambire Wallet), Jan-Philip Grabs, Karl-Martin Ahrend (Web3 Studios), Kristaps Vaivods (Vorto Gaming), Luka Sucic, Valentin Mihov, Captain Nemo (Daedalus Collective), Marco Cora (zkSync), Mark Borsten, Tommy Quite (Merit Circle), Matt Aaron (Uniwhales), Nick Tong (Perpetual Protocol, Daedalus Collective), Nicolas Hourcard (QuestDB), Odera Ume-Ezeoke (Limbic Labs), Philip Gasslander, Dominik Thalmann, Kubi Mensah, Fabrizio Marincola (Gattaca), Ramsey Khoury (Vega Protocol), Raphaël Mazet (SimpleFi), Rupert Barksfield (Amulet), Sarthak Jain (Binance), Tayler Ward (Barnbridge, Universe XYZ, D64), Yoann Turpin (Wintermute). And a number of prominent angels in the Web3 space: Batuhan Dasgin, Benedikt Schulz, Dermot O’Riordan, Evgeny Gokhberg, Fabian Wetekamp, Georgi Georgiev, Kay Meyer, Lyuben Belov, Winslow Strong, Xin Wang and many others. For more information, read the full announcement[ here](https://x.com/AltitudeFi_/status/1744674260449206778). # FAQ ## Getting Started ### What is Altitude? Altitude is a DeFi lending protocol that lets you borrow USDC against your BTC or ETH without selling. While your loan is open, Altitude optimizes your borrow rate and generates yield with your idle capital. That yield automatically pays down your loan over time, potentially to zero. Built on established protocols like Aave and Morpho, Altitude handles the complexity so you don't have to. One deposit, one dashboard, and your capital works while you wait. ### How do I use Altitude? 1. Connect your wallet (MetaMask, Rabby, or other supported wallets) 2. Choose a vault based on your collateral type (e.g., wstETH/USDC or cbBTC/USDC) 3. Deposit your collateral 4. Borrow USDC against it 5. Your collateral immediately starts earning yield that reduces your loan When you're ready to exit, repay any remaining balance and withdraw your collateral. ### How much should I borrow? If you don't plan to monitor your loan regularly, borrow at a low loan-to-value due to the volatility of crypto assets. BTC and ETH have seen days where they dropped 20-30%. Starting with a lower loan-to-value gives you more buffer against price swings. ### Can I deposit and withdraw freely? Yes. There are no lock-ups and withdrawals are instant. For security purposes, vaults have deposit caps and a rate limiter that restricts outflows to roughly 10% of total deposits per 24 hours. This limits the impact of any potential exploit. Withdrawal limits are revised periodically. ## How it works ### How does my loan pay itself down? When you borrow less than the maximum allowed, you have unused borrowing power. Altitude borrows up to a target threshold on your behalf and deploys that capital into yield-generating strategies. For example: if the target threshold is 60% and you borrow at 20% loan-to-value, Altitude borrows an additional 40% on your behalf to generate yield. That yield is harvested regularly and automatically applied to reduce your loan balance. You can check the current target threshold on the Transparency page in the app. ### Where does Altitude borrow from and generate yield? We only integrate with protocols after they're battle-tested. Current integrations include: * For lending: Aave and Morpho * For yield: Pendle, Curve, Morpho Earn, and Ethena To see exactly where your assets are at any point, check the Transparency page in the app. ### Why use Altitude instead of doing this myself? You can do this yourself. The founders of Altitude used to do exactly this manually with their own funds. But doing it yourself means: * Managing liquidation risk manually. Borrowing at high LTV is risky without automated rebalancing. If the market drops 20-30% in a day and you're not watching, you get liquidated. Altitude runs multiple bots concurrently to keep vault health stable. * Staying informed on yield opportunities. To maximize returns, you need to constantly research where the best risk-adjusted yields are. Altitude does this for you. * Paying gas fees. Moving funds around on mainnet gets expensive. Altitude covers gas fees for rebalancing and yield harvesting from its revenue. ### What happens if my collateral value drops? Like any lending protocol, if your loan-to-value ratio rises above the liquidation threshold, your position may be liquidated. During liquidation, a portion of your collateral is sold to repay your debt, and a liquidation penalty applies. Altitude's rebalancing bots help maintain healthy vault-level positions, but you're still responsible for monitoring your own LTV. If your collateral drops significantly, consider adding more or repaying part of your loan. Altitude uses Chainlink oracles to determine collateral values. ## Fees and Rewards ### What fees does Altitude charge? Altitude only charges on the upside it generates for you. There are no deposit fees, withdrawal fees, or management fees. On the additional yield Altitude generates, there's a performance fee. You can check the exact percentage on the Transparency page in the app (typically 25%). For example: if funds are borrowed at 5% and deployed at 10%, that's a 5% yield delta. Altitude takes 25% of that delta. You keep the remaining 75%, which goes toward paying down your loan. ### How do ALTI token rewards work? ALTI rewards are earned by block based on the amount of collateral you've deposited. Borrowing and repaying don't affect these rewards. When you deposit more or withdraw, your rewards adjust going forward (not retroactively). You can read more about [The ALTI Token](/general/the-alti-token) and [ALTI rewards program](/general/alti-rewards-program). ## Security and Trust ### How secure is Altitude? Altitude employs multiple security measures: * Audited smart contracts. Two independent audit firms (Team Omega and Oxorio) have audited the protocol. See our Audits page for reports. * Rate limiting. A rate limiter controls how much can be extracted from the protocol at any time, limiting the impact of potential exploits. * Real-time threat monitoring. Hypernative's monitoring system detects suspicious activity and can trigger automated responses to protect funds. * Battle-tested foundations. Altitude is built on established protocols like Aave and Morpho with billions in TVL. That said, DeFi carries inherent risks. Your assets can be lost due to bugs, hacks, exploits, oracle failures, or market conditions. Only deposit what you can afford to lose. See our [Risks](/resources/risks) page for full details. ### Who is behind Altitude? Altitude is operated by Altitude Protocol Inc (Panama), developed by Altitude Labs and Elevation Labs. The founding team is publicly identified: * Tobias van Amstel (Founder/CEO) * Ronald van Spronsen (Founder/CTO) * Ivailo Jordanov (Founder/Advisor) The protocol is backed by Tioga Capital, New Form Capital, GSR, and prominent DeFi angels including Marc Zeller of Aave. We've also received a grant from Aave to support ecosystem integration. We've been building since 2021. For contact details, see our Contacts page. ### Who decides which yield strategies are used? Strategy decisions are governed through Allocation Proposals, which require approval from supply token holders. The team cannot unilaterally change which lenders or yield farms are used. See our [Yield Generation Process](/general/yield-generation-process) page for details. ## Technical Details ### Which wallets are supported? Altitude works with wallets you already trust, including MetaMask and Rabby. ### Why is Altitude only on Ethereum? Ethereum hosts the deepest liquidity for DeFi lending and yield generation. This gives Altitude access to competitive rates and the broadest range of yield strategies. # Lenders This page lists the active integrations per vault. Altitude [Optimizing Borrowing Rates](/general/protocol-overview/optimizing-borrowing-rates) for its users, to support this we have built integrations with the following protocols to finance debt:
LogoProtocolLink
Aaveaave.com
Morphomorpho.org
To see which protocols the vaults are currently generating yield from, please check [app.altitude.fi](https://app.altitude.fi). ## Risks In order to understand the risks associated with each integration please research the external protocol. To understand the risks associated with Altitude please see [Risks](/resources/risks). ## Allocation Proposals We may change where we finance debt. Please keep an eye on [Allocation Proposals](/smart-contracts/allocation-proposals) to be aware of any changes. # Yield generation In order to [Actively Managing Idle Capital](/general/protocol-overview/actively-managing-idle-capital) for its users, Altitude has built integrations with the following yield generation protocols:
LogoProtocolLink
Aaveaave.com
Morphomorpho.org
Curvecurve.finance
Convexconvexfinance.com
Pendlependle.finance
To see which protocols the vaults are currently generating yield from, please check [app.altitude.fi](https://app.altitude.fi). ## Risks In order to understand the risks associated with each integration please research the external protocol. To understand the risks associated with Altitude please see [Risks](/resources/risks). ## Allocation Proposals We may change where we finance debt. Please keep an eye on [Allocation Proposals](/smart-contracts/allocation-proposals) to be aware of any changes. # Decentralized Exchanges Altitude has built integrations with the following de-centralized exchanges to swap tokens:
LogoProtocolLink
Uniswap V3uniswap.com
Curvecurve.finance
To see which protocols the vaults are currently generating yield from, please check [app.altitude.fi](https://app.altitude.fi). ## Risks In order to understand the risks associated with each integration please research the external protocol. To understand the risks associated with Altitude please see [Risks](/resources/risks). # What is the architecture? Each supply/borrow currency pair is managed in a single vault, for example a wstETH-USDC vault, where a user can supply wstETH and borrow USDC. Vaults facilitate a few key functions, including: * **User actions:** Allowing the users to interact with the vault through 'deposit', 'borrow', 'repay', 'withdraw' and 'claimRewards' actions * **Lender Strategies:** deploying user assets into the lenders where the best rates can be achieved * **Farm Strategies:** deploying previously dormant capital (active capital) to earn interest on the users behalf * **Rebalancing:** ensuring the vault position is always healthy by borrowing and repaying lenders when needed * **Harvesting**: recognising earnings from the Farm Optimisations and enabling distribution to users * **Committing:** updating user balances to recognise their latest position, including earnings from the farm strategy * **Liquidations:** enabling user funds to be liquidated when the users position becomes unhealthy * **Tokenization:** tokenizing user supply and debt positions # Vaults & Contracts ## Vaults
NameDeposit AssetBorrow AssetCode versionPublic/ PrivateStatus
cbBTC-USDC v2cbBTCUSDCv2PublicLive
wstETH-USDC v2wstETHUSDCv2PublicLive
wstETH-USDC v1wstETHUSDCv1PrivateYield Generation Paused
## Source code v2 ## Contracts cbBTC**-USDC v2**
NameAddressLink
Registry0x8C66DFC114db9910d960F394fFB031893eF12Ba8Etherscan
Vault Core0x550F8a1FFC921b9179267F9e7909FC68CE496A6bEtherscan
Ingres Control0xbdE7B92812760F91464bD46793722454fFEC7f95Etherscan
Supply Token0x2Ddd6d576615E6AFa823adeDDe8DC67198333169Etherscan
Debt Token0xDF612bf20C2A68730cEDC5056a1F1A90c6827e66Etherscan
Tokens Factory0x3C456b6fA3872e5C77eB77a84AcC7cc39D7a11f9Etherscan
Dispatcher0x45F08c3Bf6Ca6f84875225dBe0e6F4b6f6578932Etherscan
Rebalance Incentives0x8f18b32a89Ddf6F89bf972d7F8203BacB8Dc4D52Etherscan
## Contracts **wstETH-USDC v2**
NameAddressLink
Registry0x8C66DFC114db9910d960F394fFB031893eF12Ba8Etherscan
Vault Core0xaf6062222d00Ac63477aD084Ebd22a7821E5EE8dEtherscan
Ingress Control0xc2E2F4CB58c4DcCF21A8aa47529B09c39C029e14Etherscan
Supply Token0x5c58dffc753ba61e07a73a021f70366ab69c1f06Etherscan
Debt Token0x5717f3f1b566cf2f7113979fcd78d9416f5b0056Etherscan
Tokens Factory0x3C456b6fA3872e5C77eB77a84AcC7cc39D7a11f9Etherscan
Dispatcher0xd812bbC43386275478B3A24DEC4324F5eB97a8FDEtherscan
Rebalance Incentives0x5603578CaD65cA5CcB9E3d1E8C2F346481aE768DEtherscan
## Contracts **wstETH-USDC v1**
NameAddress
Vault Core0x1f7d589e90e4E4FC1B15B3143a5c60F743C759b9Etherscan
Ingress Control0xb4165B2D55fc28A6D259d15d60D07ecAf7B565F2Etherscan
Supply Token0x874566FfA8d837934aE85Db2209839F5Fb4E6b1dEtherscan
Debt Token0xd130a916dDbF1612C2F2FAAb6897210f056Ab29bEtherscan
Tokens Factory0x602d7989e4a6ff52c194457569186200ca4EB15dEtherscan
FarmMode Decision Maker0x4F8048241D148BbdE1Db3C3f1b311eF1e1692936Etherscan
Rebalance Incentives0x84910BDfb667086eB082Cc1ec045b68Ef86eaB58Etherscan
# Audits Audits are essential but not a guarantee. DeFi protocols are interconnected, which can create unforeseen vulnerabilities. We take security seriously, but no protocol can promise zero risk. Deposit only what you can afford to lose. ## Completed Audits * **Team Omega** - Full v2 coverage (incl. Pendle) - completed May 2025 - [**report**](https://github.com/OmegaAudits/audits/blob/main/202505-Altitude.pdf) * **Oxorio** - Full v2 coverage (incl. Pendle) - completed May 2025 - [**report**](https://oxor-io.github.io/public_audits/Altitude/Altitude-v2-Audit-Report.pdf) * **Team Omega** - Parallel farming - completed January 2025 - [**report**](https://github.com/OmegaAudits/audits/blob/main/202501-Altitude-parallel-farming.pdf) * **Team Omega** - Morpho integration - completed August 2024 - [**report**](https://github.com/OmegaAudits/audits/blob/main/202408-Altitude-morpho-integration.pdf) * **Oxorio** - full V1 coverage - completed July 2024 - [**report**](https://oxor-io.github.io/public_audits/Altitude/Altitude-Audit-Report.pdf) * **Team Omega** - full V1 coverage - completed March 2024 - [**report 1**](https://github.com/OmegaAudits/audits/blob/main/202207-Altitude-v1.0.pdf); [**report 2**](https://github.com/OmegaAudits/audits/blob/main/202310-Altitude-v1.1.pdf) # Security Beyond smart contract audits, the Altitude protocol employs a variety of additional security measures. ## Threat monitoring We've implemented Hypernative's real-time threat monitoring system. Hypernative monitors for suspicious activity, potential exploits, and abnormal transaction patterns across the protocol. If a threat is detected, automated responses can pause affected functions to protect user funds. This provides an additional security layer beyond smart contract audits. For more details, see the announcement: {% embed url="" %} ## Rate limiter The rate limit is a security consideration that can limit the impact of any possible exploits. It controls how much can be extracted from the protocol at any time. It works by setting both: * an amount that can be extracted and * the period this amount can be extracted within The mechanism of the rate limit allows the entire amount to be withdrawn at the beginning of the period and with time passing the amount is increasing linearly.
# Governance ## Upgradability The smart contracts can be upgraded via a multi-sig. This multi-sig requires signatories from multiple individuals, all of whom are known to the team. ## Pausing the protocol Each vault has a 'pause' mode built-in that can be activated by a limited number of addresses. The goal of the pause function is to protect user funds. When in 'pause' mode, users still have a method to keep their loan healthy as required. When the pause mode is activated, it is not possible to deposit or withdraw collateral, borrow, transfer, or claim rewards. It is still possible to do repay your loan. # Oracles The protocol relies on price oracles to make critical decisions about user positions. These oracles come from the lending provider currently integrated with each vault. When the protocol needs to verify if a user action (such as borrowing or withdrawing) is permissible\ or determine if a position should be liquidated it sources real-time price data directly from the oracle that the active lender is using. This ensures consistency between how assets are valued for lending and how they're evaluated for protocol safety measures. You can always verify which lending provider (and consequently which oracle) is active for any vault by viewing the vault details on Altitude.fi. This information helps you understand the specific price feed determining your position's health. In addition to using price oracles to determine the health of positions, we also use Oracles when swapping tokens on-chain. For this we use Chainlink price feeds, or when not available a Time Weighted Average Price (TWAP) from Uniswap. # Allocation Proposals Allocation of funds both where we finance debt and generate yield is managed through allocation proposals. Each vault has its own Snapshot page for transparency, you can find these here:
VaultSnapshot Page
cbbtcUsdc_v2https://snapshot.box/#/s:allocation-cbbtc-usdc-v2.altitudefi.eth
wstethUsdc_v2https://snapshot.box/#/s:allocation-wsteth-usdc-v2.altitudefi.eth
wstethUsdc_v1https://snapshot.box/#/s:allocation-wsteth-usdc.altitudefi.eth
# Risks We believe informed users make better decisions. DeFi carries real risks, and you should understand them before depositing. DeFi is risky. You could lose some or all of your funds. **General economic risks** Please be aware that the value of Cryptoassets and Tokens can fall as well as rise. If you deal in Cryptoassets or Tokens other otherwise use our Services, you may lose value, and you may lose the full value of your participation. The value of Cryptoassets and Tokens depend on fluctuations in the financial markets, or other economic factors, which are outside our control. The past performance of a Cryptoassets and Tokens is not a guide to the future performance. **Volatility risk** Cryptoassets and Tokens are subject to significant price volatility. The prices of cryptoassets generally have historically been subject to dramatic price fluctuations and are highly volatile. A range of factors may influence the market price, if any, of Cryptoassets and Tokens, including, but not limited to: (i) the ability (if any) of Cryptoassets and Tokens to trade on a secondary market; (ii) global supply and demand (iii) general expectations with respect to the rate of inflation, interest rates and exchange rates; (iv) changes in the software, software requirements or hardware requirements underlying Cryptoassets and Tokens; (v) changes in the rights, obligations, incentives, or rewards for holders of Cryptoassets and Tokens;(vii) interruptions in service from or failures of exchanges on which Cryptoassets and Tokens are traded; (viii) investment and trading activities of large purchasers, including private and registered funds, that may directly or indirectly invest in Cryptoassets or Tokens; (ix) monetary policies of governments, trade restrictions, currency devaluations and revaluations; (x) regulatory measures, if any, that affect the use of Cryptoassets and Tokens and changes in Applicable Law; (xi) global or regional political, economic or financial events and situations; and (x) expectations among participants that the value of a particular Cryptoasset or Tokens or cryptoassets generally will soon change. A decrease in the price of a single cryptoasset may cause volatility in the entire cryptoasset industry and may affect the Cryptoassets and Tokens you deal in our Services. Volatility in the price of Cryptoassets and Tokens may result in significant loss over a short period of time. **Risks in relation to third parties** Whilst our Services enable you to access the services of third parties, such as Third Party Lenders and Yield Farms, the services and products provided by such third parties are subject to their own particular risks. We may not have done any due diligence on the third parties you may access via our Services, and for example a third party may be selected as a result of an Allocation Proposal submitted by a Supply Token holder and not by us. In using our Services, you understand that we are not responsible for the risks of using the products and services provided by third parties, and it is your responsibility to ensure that you understand and accept them as relevant to your use of our Services, including by conducting your own appropriate due diligence. **Risks in relation to the Yield Generation Process and Vaults** Once a Vault and Yield Generation Process has been set up, we do not exercise any discretion in relation to its operation. As such, absent an approved Allocation Proposal, we are unable to adapt an existing Vault or Yield Generation Process to take account of market changes or issues that arise. The passing of an Allocation Proposal may take time, and we are not responsible for any loss caused by any delay as a consequence. Furthermore, Supply Token holders suggesting an Allocation Proposal have not been vetted by us and may lack experience or competence. In any event, if an Allocation Proposal is passed, we will generally be required to pass it and so are not responsible for any loss, or failure to make a gain, as a result of implementing any Allocation Proposal. **Risk of losing access to Cryptoassets and Tokens due to loss of private key(s)** A private key, or a combination of private keys, is necessary to control and dispose of Cryptoassets and Tokens. Accordingly, loss of requisite private key(s) associated with your Wallet or smart contract storing Cryptoassets and Tokens will result in loss of them. Moreover, any third party that gains access to such private key(s), including by gaining access to login credentials of a hosted wallet service you use, may be able to misappropriate your Cryptoassets and Tokens. You, and not we, are responsible for safekeeping your private key(s). **Risk of issues with your Wallet** You are responsible for ensuring that your Wallet is compatible with our Services and Tokens. Any errors or malfunctions caused by or otherwise related to your Wallet, including your failure to properly maintain or use such Wallet, may also result in the loss of your Cryptoassets and Tokens. It is your, and not our, responsibility to obtain, maintain and secure your Wallet, which must be compatible with holding the Cryptoassets and Tokens you deal in. **Regulatory risks** Regulation of Cryptoassets, Tokens and the use of blockchain technologies generally is currently still being developed and likely to rapidly evolve. Regulation varies significantly between different jurisdictions and is subject to significant uncertainty. Regulators may in the future adopt laws, regulations, guidance or other actions that may severely and adversely impact Cryptoassets, Tokens or our Services generally. This could result in a variety of adverse consequences and reduce the value of Cryptoassets and Tokens. It may also limit our ability to operate / provide our Services and Tokens in particular jurisdiction(s). **Risks associated with the blockchain protocol** Because Cryptoassets, Tokens and our Services generally are reliant on blockchain protocols, any malfunction, breakdown or abandonment of the blockchain protocol may have a material adverse effect on Cryptoassets, Tokens and our Services generally. Moreover, advances in cryptography, or technical advances, such as the development of quantum computing, could present risks to Cryptoassets, Tokens and our Services generally by rendering ineffective the cryptographic consensus mechanism that underpins the blockchain protocol. **Risk of hacking and software and security weaknesses** Hackers or other malicious groups or organizations may attempt to interfere with Cryptoassets, Tokens and our Services generally in a variety of ways, including malware attacks, denial of service attacks, consensus-based attacks, sybil attacks or smurfing and spoofing. There may also be attacks attempting to overpower the consensus-based mechanism on which the blockchain in built and attacks which interfere with or otherwise cause nodes to malfunction (nodes are computers / hardware devices that help maintain the blockchain). There is an inherent risk that the software and related technologies and theories we use in connection with our Services and Tokens could contain a Virus. A Virus could cause, inter alia, complete loss of Cryptoassets and Tokens. In addition, because Cryptoassets and Tokens may be based on open-source software, there is a risk that someone may intentionally or unintentionally introduce a Virus into the core infrastructure supporting Cryptoassets or Tokens, which could negatively affect their operation and / or value. **Forks and Airdrops** The underlying protocols of Cryptoassets may be subject to substantial changes in their operating rules (called a “forks”), and these may alter the value or function of a Cryptoasset. A fork may result in multiple versions of a Cryptoasset, leading to volatility as one version becomes dominant over another, which may lose its value. There may be distributions made to holders of a particular Cryptoasset, for example of a new variant of a Cryptoasset (called an “airdrop”), and the event of an airdrop may also impact the value of the Cryptoasset(s) affected. # Disclaimer This communication is not directed at retail clients, it is directed only at sophisticated investors. Dealing in crypto assets is high risk, and all capital used to participate is at risk of being lost. Our products are not available to persons in the USA, China, or other restricted territories. In the UK, this communication is directed only at persons who fall within an exemption to the restriction on financial promotions as set out in the Financial Services and Markets Act 2000 (Financial Promotion) Order 2005, such as investment professionals (Article 19); high net worth companies, unincorporated associations etc (Article 49); and sophisticated investors (Article 50). Altitude is built on established protocols like Aave and Morpho and has undergone multiple security audits. However, DeFi carries inherent risks. Smart contract bugs, exploits, oracle failures, or market conditions could result in partial or total loss of funds. Only deposit what you can afford to lose.
# Contacts ## Join our community [Telegram Announcements](https://t.me/altitudefi_announcements) ## Founders Altitude.fi is a protocol developed by Altitude Labs & Elevation Labs. We're a doxxed team and keen to speak with users and partners. | Name | Role | Contacts | | ------------------- | ----------------- | ---------------------------------------------------------------------------------------------------- | | Tobias van Amstel | Founder / CEO | [LinkedIn](https://www.linkedin.com/in/tobiasvanamstel/) \| [Twitter](https://x.com/tobiasvanamstel) | | Ronald van Spronsen | Founder / CTO | [LinkedIn](https://www.linkedin.com/in/rvspronsen/) \| [Twitter](https://x.com/rvspronsen) | | Ivailo Jordanov | Founder / Advisor | [LinkedIn](https://www.linkedin.com/in/ivailo/) \| [Twitter](https://x.com/ivailoj) | For sales/recruiter enquiries, please contact us either via email (). # Bug Reporting Security is fundamental to Altitude. We welcome security researchers and advanced users to examine our systems and responsibly disclose any vulnerabilities you discover. When you help protect our users, we aim to recognise that contribution through public thanks and, where appropriate, a bug bounty reward. If you believe you’ve found a security issue, please review the guidelines below before submitting a report. {% hint style="info" icon="robot" %} Reports that appear to be generated or primarily drafted by an AI/LLM tool without human verification will be closed without response. Submitters who send unverified reports may be permanently excluded from the programme. You are responsible for verifying every claim against the live codebase before submitting. {% endhint %} ## **How to Report** Send all reports to [**security@altitude.fi**](mailto:security@altitude.fi) and include: * A clear **summary** of the issue * Exact **affected contracts or components** (addresses, repos, commit hashes) * The **exact file path, function name, and line number** in the current codebase, include the **commit hash** you reviewed * **Impact analysis** (potential attacker capabilities, affected users, maximum loss) * A **runnable Foundry test.** Pseudocode, diagrams, and hypothetical scenarios without execution evidence are not accepted * Any **potential mitigations** you recommend When performing research: * Do **not** exploit vulnerabilities on mainnet or production * Do **not** access, modify, or exfiltrate other users’ data * Do **not** attempt denial-of-service attacks * Do **not** engage in social engineering of Altitude team members or users If unsure, contact us before taking any risky action. ## **In-Scope Vulnerabilities** We primarily reward findings that could lead to a **loss of funds**, **loss of control**, or **material risk** to Altitude users or the protocol. Some examples; * Logic errors leading to loss, theft, freezing, or mis-accounting of funds * Access control failures or privilege escalation * Unsafe upgrade patterns or incorrect assumptions in integrations * Issues arising from Altitude’s integration with external protocols where the flaw is in Altitude’s logic or assumptions When in doubt, report the issue. If it has real security impact, we will triage it. ## **Out-of-Scope Vulnerabilities** To maintain a high-signal program, the following categories are **explicitly out of scope** and not eligible for bounty rewards. * Duplicates of earlier submissions, including reframing or variations of the same underlying behaviour * Any known issues listed in either the documentation, repository or previous audit reports * Issues requiring deployment from a non-trusted source * Typos, documentation, cosmetic UI issues, visual bugs without security impact * Vulnerabilities that depend on compromising the user before interacting with Altitude * Issues solely arising from third-party protocol bugs, where Altitude behaves according to the documented interface * User-error scenarios involving misuse of contract interfaces * Theoretical attacks requiring unrealistic assumptions, such as: * Economic manipulation beyond plausible conditions * Guaranteed MEV/control of transaction ordering * Compromise of privileged keys or systems we assume secure * Gas optimizations, informational findings or micro-efficiency improvements ## **Rewards & Recognition** Eligible submissions may receive a monetary bounty based on: * **Severity:** impact and likelihood * **Novelty:** not a duplicate or known issue * **Quality:** clarity, reproducibility, and depth of analysis Reports that require significant back-and-forth to establish basic validity, reference incorrect code, or appear to be AI-generated will not be eligible for a reward and may result in exclusion from future participation. With your consent, we may also credit you publicly. All reward decisions are made at the discretion of the Altitude team. ## **Safe Harbour** If you follow this policy in good faith: * We will not pursue legal action for your security research on Altitude * We will treat your report confidentially until a fix is deployed * We will communicate clearly throughout the disclosure process We ask that you respect our users, limit your testing to what is necessary, and avoid causing harm or disruption.