Launch a native asset

Seedbed is IceRoot’s native asset creation and distribution platform. It creates a standardized ledger asset with a fixed supply and distributes it, without deploying a token contract. Its interface runs outside consensus; on chain, a Seedbed asset uses the same operations as every other native asset.

This guide follows the draft protocol, which describes the intended mainnet. Check steps, fees, and interfaces against an actual release before relying on them.

Decide what is fixed

Some choices can never change after creation. Settle them before you create the asset.

Field	Rule	Can change later
Name	1 to 32 bytes of text without control characters	Never
Symbol	1 to 12 characters from A to Z and 0 to 9	Never
Decimals	0 to 18	Never
Supply	Created once, in full, and credited to the creating account	Never
Metadata URI	At most 256 bytes, beginning with https:// or ipfs://	Together with the content hash, by the asset authority
Content hash	The SHA-256 hash of the hosted metadata document	Together with the URI

There is no rename operation. Consensus neither reserves nor deduplicates symbols, so another asset can use the same name and symbol as yours. Your asset’s identity is its AssetID.

Size the supply

Every native asset has a fixed supply set at creation. There is no minting, no cap to raise, and no key that could create further units. If you may need units later, choose one of these approaches:

• Keep a reserve. Hold part of the supply at creation and release it publicly, for example on a schedule of time-locked transfers.
• Create a new asset. Launch a separate asset with its own AssetID when you need one.

Amounts are counted in base units. With d decimals, one base unit is 10^-d of a whole unit, and every amount must fit in an unsigned 128-bit integer, about 3.4 × 10^38 base units.

Choose who holds each authority

Each asset has two roles:

• Asset authority: replaces the metadata URI and content hash, always together.
• Migration authority: controls the asset’s allow-list of exit destinations and its two lifecycle flags: whether new inbound migration lists are accepted, and whether migrate-out is open.

Neither role can debit, move, or freeze any holder’s units, create units, or change provenance. Both roles default to the creator, and one account may hold both.

Each role can be held by a single-key account or by a native multisig account. An M-of-N multisig with M = 1 lets any of several addresses act. A role moves in two steps: the current holder proposes a new holder, and the proposed account accepts. Until then, the current holder can cancel.

Renouncing a role is permanent. Renouncing the asset authority freezes the metadata. Renouncing the migration authority freezes the asset’s exit destinations and lifecycle flags where they are, so an asset with no exits configured can never open one. Keep the migration authority if you may ever want the asset to move to another chain.

Prepare the metadata document

Your website, description, logo, and contact details live in a hosted metadata document. The asset record stores its URI and its content hash.

Wallets show these issuer claims when the document’s hash matches the recorded content hash, and label them as provided by the issuer. The hash makes the document tamper-evident. If hosting fails, the claims become unavailable, while the asset’s on-chain fields are unaffected.

Create the asset

1. Fund the creating account. Every transaction pays its fee in ROOT, and asset creation carries a surcharge. The surcharge value is not yet fixed.
2. Enter the asset in Seedbed. Provide the name, symbol, decimals, supply, metadata URI and content hash, and the holder of each authority.
3. Review and sign. The creating account signs ASSET_CREATE and receives the whole supply.
4. Wait for finality. A transaction counts once its block is final. The draft’s earliest finalization is 71 blocks, about 9.5 minutes, after the block is produced.
5. Record the AssetID. It is computed from the network, the creating address, and the nonce of the ASSET_CREATE transaction, so every node derives the same value.
6. Announce it. Publish the AssetID on your own channels, such as your website and repository. Wallets, exchanges, and the verified-asset list rely on what you announce.

Distribute the supply

• Transfers. One transfer pays 1 to 256 recipients in one asset, with one memo for the whole transaction.
• Vesting. A time-locked transfer places units in one or more entries, one per tranche, each claimable by its recipient after its unlock time. Unlock times are slot times, the slot number × 8 seconds from genesis, so each tranche unlocks on its calendar date whatever slots are missed.
• Claims. Nothing unlocks automatically. After an entry’s unlock time, anyone may submit its claim, and the units always go to the entry’s recipient.
• No revocation. No one can revoke a time-locked entry, the sender included. Plan schedules before you sign them.
• Reserve releases. An issuer that kept a reserve releases it publicly the same way, with time-locked transfers.

Each time-locked entry pays a surcharge and must hold a minimum amount; these values are not yet fixed. Locked units carry no vote weight, and every node’s supply check counts them until they are claimed.

Recipients need ROOT to move the asset later, because every transaction pays its fee in ROOT. Issuers may include a small amount of ROOT in their distributions; this is a practice, not a protocol rule. A fee grant from the Ecosystem campaigns pool can cover registration surcharges, names, and small ROOT amounts for holders.

Launchpads

A planned launchpad distribution kit, which runs off-chain, is designed to turn allocation lists into multi-recipient transfer batches with a public proof of distribution. It sets up vesting with time-locked transfers and binds claims: a buyer signs with an Ethereum or Solana wallet to name an IceRoot address. It changes no consensus rule. The kit accepts a claim proved with a classical key, such as a buyer’s Ethereum or Solana signature or a claim in an issuer’s distribution from an archived snapshot of another chain, only up to a cut-off that the issuer declares in advance, for the same reason that a classical source network has one (see Migrations and continuity).

After launch

• Holders. Holders transfer, swap, and burn their own units, and can lock units for swaps with other chains. No lifecycle flag freezes transfers, and any asset can be received by any address.
• Supply. The issued amount never changes after creation. Burns and exits are counted separately, as burned and as migrated out, and every node checks supply conservation for every asset after every block. Wallets and the explorer show every native asset as fixed supply.
• Metadata. The asset authority can replace the URI and content hash together. The name, symbol, and decimals stay as created.

If IceRoot meets your project’s needs, nothing more is required. If you plan to move to your own chain later, read Launch before your mainnet before you create the asset.

Native assets → · Launch before your mainnet →