Skip to content
RP1Vaults

Native, donation-resistant vault accounting

Capital,
accounted.

Deterministic shares. Protected deposits. Bounded redemption epochs. RP1 Vaults keeps custody, accounting, settlement, and claims explicit at every step.

Inspect the lifecycle
Native V1Idle assets · Isolated claims · Public invariants

Why RP1 Vaults

A vault should make every unit of custody, every share, and every outstanding claim independently verifiable.

RP1 Vaults is an accounting kernel, not an opaque yield product. V1 is implemented in RP1 chain software with native messages, queries, REST, gRPC, AutoCLI, and TypeScript SDK support. Existing networks require the named vaults-v1 upgrade before those surfaces are active.

Vault lifecycle01/ 04
  1. 01Deposit
  2. 02Account
  3. 03Request redemption
  4. 04Settle and claim
Accounting boundaryBase asset + minimum shares
Current stageDeposit

Deposit

Enter through a measured accounting boundary.

A depositor supplies the vault’s immutable base asset and a minimum acceptable share output. The vault mints deterministic shares only against assets admitted through this path.

Native Cosmos SDK message and query surfaces

Account

Keep donations out of the share price.

Tracked idle assets drive share accounting. Raw transfers to custody are quarantined from price-per-share calculations, while virtual assets and shares reduce first-depositor manipulation.

Enforced by the module once Vaults V1 is active

Request redemption

Queue exits without blocking everyone else.

Users escrow shares into the current bounded epoch with a minimum asset output. Requests remain cancellable before settlement, and stale or zero-output requests refund individually instead of freezing the epoch.

Asynchronous redemption with user-defined protection

Settle and claim

Settle once. Keep every claim isolated.

Anyone may settle an eligible epoch. Assets move atomically into deterministic claim escrow, surviving shares burn, and the next epoch opens. Settled claims remain available even while operations are paused.

Permissionless settlement; claims survive pauses

Accounting invariants

The balances must reconcile from every direction.

Vault safety is expressed as public accounting relationships, not dashboard promises. Custody, claims, shares, and pending redemptions each have a distinct boundary.

BoundaryControlProtocol guaranteeV1 status
CustodyActive assets stay in a deterministic vault accountCustody balance covers tracked idle assetsImplemented
ClaimsSettled assets move to separate deterministic escrowEscrow balance covers reserved claimsImplemented
SharesOne deterministic denom per vaultBank supply equals tracked share supplyImplemented
RedemptionsPending shares remain module-controlledModule balance covers all pending sharesImplemented
Strategy scopeIdle assets only in V1Tracked assets equal tracked idle assetsV1 boundary

V1 deliberately excludes lending, DEX strategies, leverage, arbitrary contracts, cross-chain execution, agent permissions, and automatic block scanning. The module is implemented in current chain software; existing networks require the named vaults-v1 upgrade before it is active. Review RP1 documentation.

Integration paths

Build on a vault boundary you can prove.

Tokenized treasury custodyIMPLEMENTED V1Asynchronous redemption productsIMPLEMENTED V1Typed strategy adapters after reviewFUTURE SCOPE

Start with native idle-asset custody and verify the full lifecycle on RP1. Strategy integrations remain outside V1 and require a separately reviewed, typed adapter boundary before capital can move beyond the vault.