Bounce leveraged tokens are permissionless ERC-20s on HyperEVM that give holders leveraged exposure to an underlying asset. They are the simplest way for users to get leveraged exposure, with no need to manage margin or face liquidation risk. Powered by the liquidity and asset breadth of Hyperliquid.
All user funds and token logic live on-chain: the Bounce leveraged tokens are implemented as deployed smart contracts that make up the vast majority of the codebase and core business logic. A lightweight rebalancing system operates alongside the contracts to trigger routine operations: bridging USDC between HyperEVM and HyperCore, and rebalancing the leveraged tokens to keep them at their target leverage. It acts only through restricted API wallets and at no point can it transfer or withdraw user funds. This post is an overview of how that system is designed, and the measures in place to keep it highly available and resilient.
System Overview
The rebalancing system is hosted across several zones with an active-active setup that allows for instant fallbacks for outages. Communication between services is done through an event bus, so restarts and fallbacks can recover by replaying retained events. Each service only has permissioned access to the things that a specific service needs, limiting the scope of impact for unauthorized access.
A staging environment exists which is a full replica of the production system, allowing new leveraged tokens to be safely tested end-to-end before they go live. All infrastructure is provisioned via an infrastructure as code pattern, so the entire system is version-controlled, reviewable, and auditable.
Management for each asset (e.g. SOL, ETH) is a separate deployed service, and each leveraged token (e.g. ETH 2x Long, BTC 5x Short) is a separate workflow. Separating these horizontally allows for better parallelization for scale, and better security by limiting how far an issue in one token or asset can spread.
Management of funds is done either directly through the leveraged tokens on-chain precompiles, or via the Hyperliquid Agent Wallet feature. Both of them don't support the withdrawal and transfer of funds, so the design makes it impossible for even a compromised system to move funds outside the token. There are several code level safety checks that run before any action, validating things like: transaction size, rate limits, limit order prices, etc.
The system runs reactively, listening to events such as mints, redeems or price movement. This makes the system very fast in responding to anything, averaging sub-second response times from the moment an event is emitted. A time based safety net also exists, that observes the system state every few seconds to identify any issues and trigger the appropriate action as a fallback. Orders are always placed as IoC limit orders, minimizing unexpected price impact and lingering orders.
Third party dependencies are kept to a minimum, and canonical sources are always favored such as the official Hyperliquid API. For any critical dependency, we add as many fallbacks as is practical so a single provider outage never stalls the system.
Core Design Principles
High Availability
The rebalancing system adopts a micro-service architecture with each service working on a dedicated responsibility. Each function is independently deployable so failure is isolated to one service rather than cascading system-wide. The system is designed with leader election in mind, so extra replicas in separate zones can be provisioned and instant flip-over during a zone outage can happen within seconds. Replicas are deployed in an active-active manner across different zones, and only the elected leader acts, which prevents double-execution of a rebalance or a redemption.
Resilience and Recovery
Services do not call each other directly but instead communicate through an event bus, so producers and consumers are decoupled. Because events are retained for a configurable period the system can recover by reprocessing from an earlier point. State shared between processes and replicas is kept in a low-latency in-memory store, while durable state is stored in a separate managed database, so a new leader can pick up the work a previous leader left, and an individual process failure only degrades the system during recovery rather than stopping it.
Least-Privilege Security
Security is designed around least privilege. Each service instance runs with its own identity bound to a minimal-permission cloud service account, and secrets are synced per service on a need-to-know basis, so a compromised process exposes only that service's secrets rather than the whole system. The cluster is private, with nodes that have no external IP and managed services reached over private endpoints, and operational access is tunneled in rather than exposed on the public internet.
Infrastructure as Code
The system is also designed with auditability in mind: the entire infrastructure is defined declaratively, and configuration is checked into the repository, so both deployed resources and external infrastructure are version-controlled and auditable, and the running system can always be verified against its source-of-truth definition.
Safety and Resilience
Custody of Funds
The foremost risk is funds leaving a token's account, and it is designed out structurally: all work is expressed as moving funds along a single chain of the token's own locations and never outside them: the on-chain contract, idle spot USDC, and the margin backing the position.
This is not merely a convention. Per Hyperliquid's API documentation, API wallets (agent wallets) can perform actions on behalf of an account "without having withdrawal permissions." External transfers and withdrawals are user-signed action types an agent key cannot authorize, so the rebalancing system is simply incapable of moving value to an outside address.
Pre-Trade Safety Checks
To ensure safe execution, safety checks across three dimensions are added into the system: price, notional and time. Notable examples are as follows:
- Price collar: Order with limit price too far from the current market price is rejected.
- Notional cap: Order whose notional is too large relative to market notional is rejected.
- Max size: an order with size exceeding a configured amount is capped.
- Rate limit: an order firing faster than the configured rate is rejected.
These checks are expressed as a set of independent rules so it is more testable and easier to reason about. Each rule acts as a circuit breaker: it softens an action that is only mildly out of bounds, or aborts it entirely when a safety bound would be breached. Rather than forcing through an action that would breach a safety bound, the system stands down and re-evaluates on the next trigger, which is never more than a few seconds away. A dangerous action is never forced through, and a needed one is only briefly deferred, never abandoned.
Order Management
Execution that is not properly bounded carries risk: a naive market order can fill at an arbitrarily bad price, and a resting limit order can sit in the book and fill later at a price no longer intended. To keep every adjustment predictable, each one is placed as an immediate-or-cancel (IoC) limit order priced within a slippage bound. It matches resting liquidity up to that limit and cancels the rest, so nothing lingers in the order book and nothing worse than the set bound is ever filled. Price impact is bounded by construction, and the execution bounds of each adjustment are known before it is sent.
Step Minimisation
The number of steps taken to reach a target is also kept to a minimum, since every extra step is another chance for the position to drift before the target is reached. A leverage reduction, for instance, is achieved by adding margin only, rather than closing and reopening.
Fault Isolation and Recovery
Token Isolation
Working on all tokens concurrently in shared state would invite race conditions and let one token's failure spill over into another's, so the code is structured around token isolation: every token is processed on its own workflow, fed by an event processor that dispatches to it. A slow or stuck token therefore does not stall processing of the others. Similarly, all assets are split up into separate services, to further minimise cross token impact, and to facilitate clean horizontal scaling.
Time Trigger Safety Net
A periodic timer event acts as a safety net against a token drifting off target unnoticed. Should a trigger ever be missed or dropped, the next timer tick re-derives the token's state from scratch and brings it back on target, so the system is self-correcting rather than solely dependent on incoming triggers.
Dependencies
Since every third-party RPC, API, or tool is another failure point and trust boundary, external dependencies are deliberately kept few. If a dependency is needed, a canonical provider is preferred, such as the official Hyperliquid API and its official price sources, rather than a re-hosted or derived intermediary, so behavior matches the source of truth and there is one less party to trust.
When a dependency is critical and the canonical source is limiting, redundancy is added. For example, the official Hyperliquid RPC endpoint carries a tight rate limit, so three independent RPC endpoints are used alongside it, spreading load and ensuring no single provider outage or throttle stalls on-chain reads.
Alerting and Monitoring
The monitoring is designed around the principle that a failure should surface regardless of the system's own ability to report it. Two layers of alerting are in place.
The first layer is self-reporting. A dedicated alerting service consumes the error stream off the event bus, which goes through a classifier that filters out noise, and pushes any important alerts straight to the team. This is fast and reactive, as it is the system raising its own problems, but for that reason it depends on the system being alive to raise them.
The second layer covers exactly that gap. An independent second system monitors state directly from on-chain and canonical sources only, with no dependency on the rebalancing system itself. It asserts properties a healthy token should hold, like a positive exchange rate, unstuck bridging and redemptions, gas balances above threshold, etc.
Both systems have health probes in place, so they auto-heal routine failures on their own, and the team stays notified for all important matters.
That is the system behind every Bounce leveraged token: designed so routine operations keep running, failures stay contained, and funds never leave the token's own chain of accounts.