> For the complete documentation index, see [llms.txt](https://docs.renzofinance.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.renzofinance.com/products/architecture.md).
# Architecture
A scoped trading key runs and defends this trade on a schedule. The user deposits once and then steps in only for actions that move money out of the account or change its risk mode.
### System overview
The system is made of a web app with wallet sign-in, an accounts record, a trading backend that opens and closes the delta-neutral position, a scheduled keeper that watches and repairs it, on-chain execution through the trading key, guards, an event and audit stream, and a withdrawal path.
Deposits are currently supported on HyperCore, either through direct funding from another wallet or through an external bridge.
### Trust model
During a one-time setup the user signs in, deposits funds, and approves a scoped trading key that lasts 90 days. That approval is the signature that matters, because it sets what the allowlist for the duration of the key.
The trading key can place and close orders, rebalance and re-hedge, and add margin to defend the position. It cannot move funds out of the account. Withdrawals are signed by the user: an EOA moves its own funds, and a Safe executes the transfer itself. Changes to the account's margin mode ride a separate user ceremony.
The practical result is that the widest range of action available to a malfunctioning key is trading and adding margin within the delta-neutral mandate. It cannot withdraw, and it cannot raise the account's risk.
### Automation loop
While a position is open, a scheduled keeper runs it. The keeper runs as two lanes on different clocks. A protection lane runs every few minutes, because a price move is a now problem, and carries the hedge and liquidation guards. A yield lane runs hourly, because funding moves over hours, and carries the carry guard. A separate daily lane watches key expiry.
Every pass begins by reading the trading key. A revoked or expired key stops the pass there, which makes revocation the off lever: nothing further triggers once the key is gone. Otherwise the pass reads the live position, evaluates the guards, and for a guard set to act on its own, signs the repair with the trading key and settles it on HyperCore. The keeper is otherwise always armed.
### Authorization
Before a repair is signed, the backend gates it. It checks, in order, that the key is present and not revoked, that the key has not expired, and that the action is in the trading key's scope. A revoked or missing key stops the repair. An expired key stops it and flags the key for renewal. Trades and margin top-ups fall inside that scope, so the trading key signs them itself and the user is never prompted. A withdrawal or a margin-mode change falls outside it and routes to the user to sign.
The authorization gate and the risk layer are separate concerns. The risk layer decides what the position needs. The gate decides whether the key is allowed to do it. An auto-act repair still passes the scope check, and anything out of scope becomes a request for the user to sign.
### Risk protection layer
Two inputs feed the engine: **the live position**, for price, funding, and the state of both legs, **and a single risk preset** that sets the capital split and the guard thresholds together. The engine runs three guards. Each is always detecting, and the user chooses only the response for each, either to act automatically or to leave it for manual adjustment. Revoking the trading key, or letting it expire, sits above all of it.
#### Hedge guard
Runs every 10 minutes. The hedge guard watches for net delta beyond a small floor, meaning spot that is no longer matched by a short. Auto deleveraging, a perp liquidation, and a manual close all look the same from the outside, so the guard watches the shape of the position rather than the cause. This matters most during a crash, when the short is what protects the user. Its repairs are re-hedge, or sell and exit.
#### **Yield guard**
Runs hourly. The yield guard triggers when funding has been net negative across a two-day window. Netting across the window is what keeps it steady: an hour or two of negative funding inside an otherwise positive stretch does not count, so a brief drag does not churn the position. Its repair is to exit.
#### Safety buffer
Runs every 10 minutes. The safety buffer acts when the distance to liquidation crosses a trigger and restores it to a higher target (which is whatever current preset of the user 2x, 3x etc) using a pair of values so it does not fire on every tick. Its repair is margin first. The perp carries its own margin, so a rally can threaten the short while the pair's value is flat, and adding margin moves the liquidation price away without touching either leg.
It tops the margin up from the account's spare USDC whenever there is any, which costs no fees, places no orders, and keeps the funding income intact. Only when there is no spare does it close the precise slice whose proceeds fund the top-up, and add that cash as margin. Selling both legs to raise cash does not rebuild the margin under the short, so the guard adds margin instead.
### Capital split and other default mechanics
The capital split is the primary dial in this model. A larger share in spot earns more funding but leaves less margin under the short, so liquidation arrives on a smaller rally. The preset sets that split and the guard thresholds together, so a few coherent presets stand in for several interacting numbers.
Mechanics like slippage handling, the minimum net-exposure floor, and execution details are internal defaults. Accrued funding lands as USDC in the perp account.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.renzofinance.com/products/architecture.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
