Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.superform.xyz/llms.txt

Use this file to discover all available pages before exploring further.

The Create Vault flow (/vaults/create) deploys a new SuperVault and captures the metadata needed to list it in the Superform catalog. Creation is intentionally split into two phases:
  1. Editable configuration before anything is signed.
  2. Operational setup after the vault exists onchain.
Treat creation as the start of launch readiness: finish upkeep, authorization, yield-source, strategy, and catalog setup before routing depositor flows.

​
Before You Start

You need:
  • A wallet with registry-maintainer access to SuperformOS.
  • The underlying token available in the token registry, or enough metadata to register it.
  • An approved provider record for the vault’s listing metadata.
  • The primary manager wallet that will own vault-level controls.
  • Fee recipient and fee parameters.

​
Editable Wizard Steps

The wizard has four editable steps. You can move back through these steps until you enter the transaction phase.

​
1. Basic Information

Basic Information combines the old chain, asset, identity, and listing screens into one step. Configure:
  • Chain — the deployment network. This is permanent after deployment.
  • Provider — the approved managed provider associated with the vault.
  • Underlying asset — the token users deposit into the vault. You can select a registered token or register a custom token.
  • Listing metadata — friendly name, description, category, and provider IDs used by the catalog/listing layer.
  • Onchain identity — name and symbol. By default these are computed from provider + asset, with an optional manual override.
The onchain vault name and symbol are protocol identity. The friendly name, category, provider IDs, and description are listing metadata used by Superform distribution surfaces.

​
2. Managers

Set the primary manager and optional secondary managers.
  • The primary manager owns vault settings, user management, session keys, and emergency authority.
  • Secondary managers can operate the vault but cannot replace the primary manager or change primary-only settings.
For production vaults, use a hardware-backed wallet or multisig as the primary manager.

​
3. Fees

Configure:
  • Performance fee.
  • Management fee.
  • Fee recipient.
  • PPS timing parameters.
  • Optional redeem timelock.
Fee bounds and protocol constraints are read from protocol configuration. The dashboard prepares valid calldata; your wallet signs the resulting transaction.

​
4. Review

Review everything before entering the transaction phase:
  • Chain and underlying asset.
  • Provider and listing metadata.
  • Onchain name and symbol.
  • Managers.
  • Fees and timing parameters.
After this point, the wizard moves into signing and indexing.

​
Transaction and Indexing Phases

​
Sign the Creation Transaction

The dashboard calls Erebor to prepare calldata: 
POST /api/v1/vaults/create/prepare
Your wallet signs and submits the transaction onchain. Erebor does not execute the transaction for you.

​
Confirm and Index

After the transaction is broadcast, the dashboard confirms the hash: 
POST /api/v1/vaults/create/confirm
Erebor creates an indexing job and the UI polls: 
GET /api/v1/vaults/create/jobs/{job_id}
Statuses are pending, running, completed, or failed. During indexing, the dashboard also submits the listing metadata to the catalog layer when the vault address is resolved. If catalog submission fails, the vault can still exist onchain; complete listing from the distribution/listing flow.
409 Conflict on confirm means a creation job already exists for that transaction hash. Check the existing job before retrying.

​
Post-Create Setup

Once the vault is indexed, complete the launch checklist:
  1. Vault exists onchain and appears in dashboard data.
  2. Upkeep is funded so the vault becomes active and discoverable.
  3. Hooks are configured in the active merkle root config.
  4. Yield sources are whitelisted and paired with oracles.
  5. At least one strategy exists for the vault.
  6. The vault is listed and available in the Superform catalog.
See Setup Checklist for the canonical readiness flow.

​
API Reference

EndpointMethodDescription
/api/v1/registry/token-assetsGETBrowse registered token assets
/api/v1/registry/token-assetsPUTRegister or upsert a custom token
/api/v1/vaults/create/preparePOSTPrepare creation calldata
/api/v1/vaults/create/confirmPOSTConfirm creation transaction hash
/api/v1/vaults/create/jobs/{id}GETPoll indexing job status

​
PrepareCreateVaultRequest

{
  "chain_id": 8453,
  "asset": "0xUSDC...",
  "name": "Provider USDC SuperVault",
  "symbol": "proUSDC",
  "main_manager": "0xPrimaryManager...",
  "secondary_managers": [],
  "min_update_interval": 3600,
  "max_staleness": 86400,
  "fee_config": {
    "performance_fee_bps": 1000,
    "management_fee_bps": 200,
    "recipient": "0xFeeRecipient..."
  }
}

​
ConfirmCreateVaultRequest

{
  "tx_hash": "0xabc...",
  "chain_id": 8453,
  "vault_config": {
    "redeem_timelock_seconds": 0
  }
}