RAMOS

Random Automated Market Operations Support (RAMOS)

As of November 20th, 2024, the upper policy bound of the RAMOS trading range has been removed to allow organic market discovery during the pending launch of Spice Bazaar

RAMOS is an AMO liquidity manager contract that allows the Temple Protocol to both stabilise the trading range of the TEMPLE token and index the token price to the stable backing for each token.

The RAMOS smart contract is deployed to manage the Protocol owned Liquidity (PoL) which consists of a 50/50 TEMPLE/DAI LP on Balancer. RAMOS contract functions are called by bots via our off-chain automation infrastructure.

RAMOS has 3 primary functions:

• Support the TEMPLE price when it trades below the TPI

• Recapitalise the treasury when TEMPLE trades at an "excessive" premium over the TPI

• Stake and farm the LP token on the underlying DEX to maximise gauge rewards

RAMOS will be active whenever the token price falls below the Treasury Price Index (TPI). However, the TPI is not a hard floor and at times TEMPLE will trade at a discount or a premium to the TPI. Similarly, RAMOS may also be active when the policy-prescribed upper bound of TEMPLE is reached.

RAMOS is a Treasury management tool that can be used to automate and regulate exposure to any asset not just TEMPLE

Probability Heat Map for How RAMOS Determines When to Rebalance

When spot price is more than 1% below TPI

• RAMOS will periodically rebalance and single-asset withdraw TEMPLE liquidity from the LP and burn the tokens to raise the TEMPLE price in the Balancer pool.

When spot price is more than 3% below TPI

• RAMOS will always trigger a rebalance and single-asset withdraw TEMPLE liquidity from the LP and burn the tokens to raise the TEMPLE price in the Balancer pool.

When spot price is more than 3% above TPI

• RAMOS will single-asset deposit TEMPLE into the LP to recapitalize the pool. Alternatively, RAMOS may single-asset withdraw stables as a de facto bonding system to recapitalise the Treasury during periods of strong demand.

Furthermore, RAMOS was designed to take advantage of volatility in a way that is less susceptible to MEV attacks and front-running that can confound other AMO systems:

• Randomized Timing: RAMOS does not rebalance on a fixed schedule. There is a randomisation logic which will be applied to see if and how large of a rebalance should occur. At current settings, a rebalance will be triggered 2–3 times per day on average. If the TEMPLE price falls too far below the policy bound, a rebalance will be triggered automatically to protect the TPI.

• Randomized Rebalance to Raise the Price: The number of Balancer Pool Tokens (BPT) that RAMOS will use to rebalance the liquidity pool is also randomised. RAMOS will calculate the number of BPT tokens required to fully close the gap between current price and TPI and check the price impact of the operation. Then it will extract anywhere between 50%-100% of that number to single-asset withdraw tokens.

• Randomized Rebalance to Recapitalise the Pool: When spot price trades above TPI, RAMOS will close anywhere from 1% to 10% of the gap between the current price and TPI per rebalance event by depositing more TEMPLE tokens to recapitalise the pool.

Any Rebalances to the downside are designed to be extremely mild to allow TEMPLE to trade at a premium to the TPI.