Product guide · system design
Architecture
The design separates asset custody, swap execution, and portfolio decisions. The vault holds the basket and enforces its rules. Any Ethereum V2 implementation is still pending; this page describes the intended system, not a live Ethereum deployment.
| Component | Location | Purpose |
|---|---|---|
ZapStocksVault | Onchain | Index share token, asset custody, and mint, redeem, and rebalance rules. |
ZapStocksUniV4Router | Onchain | Executes approved swaps through configured Uniswap v4 routes. |
| Portfolio agent | Offchain | Calculates a proposed target allocation and submits a rebalance request when enabled. |
A vault represents one index. It issues the index share token, holds the configured assets, and checks the rules for minting, redemption, and rebalancing. The asset list and key risk limits are intended to be fixed at deployment. Authorized administrative actions should remain limited and must not provide an asset withdrawal path.
When rebalancing is enabled, the vault can use a router to execute approved swaps. Routes and pool settings must be configured for the deployed network. The router is intended to move only the amounts authorized by the vault and return the resulting assets in the same transaction.
A portfolio agent may run offchain, calculate target weights, and submit a rebalance request. Its signing key should receive only the rebalancer permissions specified by the deployed contracts.
- If the agent stops, the vault should continue to support minting and redemption under its contract rules.
- If the agent key is compromised, contract-enforced asset, slippage, turnover, and cooldown limits should constrain its actions.
Price feeds may be used to calculate net asset value and check rebalance limits. Feed addresses, decimals, freshness requirements, and any network-specific checks must be confirmed for Ethereum before deployment. The intended design keeps in-kind redemption independent of price feeds.
Deployment status