Skip to main content
Storage keys below are the ControllerKey and PoolKey variants used on-chain.

Controller instance keys

Singleton protocol wiring and counters. Instance storage shares the contract’s own TTL, so it is renewed whenever the contract is touched.
There is no PoolTemplate key. Pool deployment and upgrade take the Wasm hash as an argument (DeployPool(hash), UpgradePool(hash)); there is no separate template-registration step.

Controller persistent keys

Split into two TTL tiers. Shared keys are protocol-, hub-, and spoke-wide; user keys are per-account.
Account ownership is not controller storage. The account_id is the position NFT’s token_id; the controller calls owner_of(account_id) on the NFT contract for every authority check. Transferring the token transfers the position.
Oracle configuration is not controller storage either. It lives on the price aggregator, keyed by PriceKey::Token(address) or PriceKey::Ref(symbol).

Pool persistent keys

TTL

Contracts renew active keys in-band on every read and write. The tiers: A dormant account is the one case in-band renewal cannot cover, because nothing touches it. renew_account(caller, account_id) extends both the account’s storage keys and the NFT Owner entry, and stays callable while the protocol is paused. The off-chain keeper renews and restores the configured surface:
  • controller, governance, pool, and price-aggregator instances and Wasm code;
  • Spoke(id), SpokeAsset(...), Hub(id);
  • pool Params/State(HubAssetKey);
  • price-aggregator oracle entries;
  • access-control keys.
Archived entries are restorable via RestoreFootprint, not lost. Keeper config keys markets by hub and asset together:
Do not key pool rows by token address alone; pool rows use HubAssetKey, and the same token under two hubs is two independent markets.