Transaction kinds

Every transaction has the same envelope and one of 30 kinds. This page lists the kinds, what each does, its coordination class, the sentence wallets show before signing it, and what sends it today. The rules each kind follows are in §5 of the specification.

The envelope

#![allow(unused)]
fn main() {
pub struct Transaction {
    pub sender: AccountId,                  // the account that signs
    pub genesis_policy: Option<AuthPolicy>, // required on the sender's first transaction
    pub inputs: Vec<ObjectRef>,             // owned inputs at exact versions; inputs[0] pays the fee
    pub fee: Amount,                        // in USD
    pub kind: TxKind,                       // what it does (below)
    pub expires_at: Pulse,                  // last Pulse in which it may execute
    pub nonce: u64,                         // makes otherwise identical transactions distinct
}

pub struct SignedTransaction {
    pub tx: Transaction,
    pub auth: Authorization,          // signatures satisfying the authorizing policy, for this chain
    pub batch: Option<BatchMember>,   // for a batch member: its batch and its place in it
}

pub struct BatchMember {
    pub batch: TxBatch,               // what the one authorization signs
    pub index: u64,                   // the member's position
    pub path: Vec<Hash32>,            // its inclusion path to the batch's root
    pub charter: Option<ObjectId>,    // for a keyless sender, its charter
}

pub struct TxBatch {
    pub signer: AccountId,            // the account whose policy the authorization satisfies
    pub size: u64,                    // 1 to 256 members
    pub root: Hash32,                 // RFC 9162 Merkle root over the members' digests
}
}

• The digest is the hash of the Borsh encoding of Transaction. A transaction on its own signs its digest, under a signing context bound to the chain’s configuration. A batch member is signed for once with the rest of its batch: the authorization signs the batch’s message, under a separate batch context, and the member carries its path to the batch’s root. See Batched authorization.
• The authorizing policy is the sender’s own, or, for a keyless subagent, the policy of its nearest keyed ancestor, which must be the batch’s signer.
• A transaction names 1 to 256 distinct inputs. The first is a USD coin that pays the fee (the faucet’s transaction uses its account object instead).
• The minimum fee is base_fee + fee_per_kib × ⌈size / 1024⌉, where size is the encoded body without signatures (0.001 and 0.0001 USD on the devnet). A batch member pays a share of the signature check instead of the whole of it: 800‰ of base_fee is split between the batch’s members, rounded up. On the devnet a small transfer’s floor is 0.0011 USD alone and 0.000304 USD as a member of a batch of 256.
• The coordination class is derived from the kind, never declared. Kinds that touch a contention domain are contended; IssueClaim, RegisterAtom and PostBond are knowledge; AgentPay, Delegate, SpendAllotment and ReturnAllotment are bounded; everything else is owned-linear. See Two-sorted state.

The sentence column shows what sion_cli::describe::sentence renders, with values in angle brackets. Every sentence ends with . Fee <fee> USD; valid until Pulse <expires_at>. For example:

dana signs: Pay 12.5 USD to alice. Fee 0.0012 USD; valid until Pulse 22.

Kinds that no CLI command, HTTP route or MCP tool builds yet (“Rust API only” below) can be built and signed with the Rust API (sion_exec::TxKind) and submitted with POST /v1/transactions.

Money and accounts

Knowledge and assurance

Agent Charters and Escrow Lanes

Agent identities

Markets

Validators

See Validators, staking and epochs.

Pooled stake

See Pooled stake.

Payment streams

See Payment streams.

Memory logs

See Memory for agents and robots.

Task Charters

Results and attestations are claims (IssueClaim, schemas task.result/v1 and task.attestation/v1), issued with sion task submit and sion task attest. See Task Charters.

Storage deals

See Storage deals.

Outcomes

Each transaction ends as Success, Failed or Rejected (Pulses). The CLI prints the outcome as a sentence:

The events and their sentences are listed in Events; the reasons in Error messages.