Block Types

XE has eight block types. Every block shares a set of common fields; each type adds its own type-specific fields.

#Common fields

All blocks carry these fields:

#Send (send)

Debits the sender's balance and creates a pending send for the recipient.

#Type-specific fields

#Validation rules

• Amount must be > 0.
• Sender must have sufficient balance: previousBalance - Amount = Balance.
• Destination must be a valid 32-byte hex-encoded public key.
• Asset must be "XE" or "XUSD".

#Side effects

On successful validation, a PendingSend record is created:

PendingSend{    SendHash:    block.Hash,    Source:      block.Account,    Destination: block.Destination,    Amount:      block.Amount,    Asset:       block.Asset,}

This pending send persists until the recipient creates a matching receive block.

#Binary encoding

Type byte: 0x01. Tail: destination(32) + amount(8). Total canonical size: 162 bytes (90 header + 40 tail + 32 representative).

#Receive (receive)

Credits the recipient's balance from a pending send.

#Type-specific fields

#Validation rules

• Source must reference an existing pending send where Destination matches this block's Account.
• Balance must equal previousBalance + pendingSend.Amount.
• Asset must match the pending send's asset.

#Side effects

The pending send referenced by Source is deleted. The recipient's balance increases by the send amount.

#Binary encoding

Type byte: 0x02. Tail: source(32). Total canonical size: 154 bytes (90 header + 32 tail + 32 representative).

#Claim (claim)

Mints 100 XUSD via the testnet faucet.

#Type-specific fields

None. Claim blocks have no type-specific fields.

#Validation rules

• Balance must equal previousBalance + 100 (FaucetClaimAmount).
• Asset must be "XUSD" (XE claims are rejected).
• Rate limited: one claim per account per 24 hours.

#Side effects

The account's XUSD balance increases by 100.

#Binary encoding

Type byte: 0x03. No tail. Total canonical size: 122 bytes (90 header + 32 representative).

#Lease (lease)

Debits XUSD from the consumer to request a compute lease. This is the consumer's side of a lease transaction.

#Type-specific fields

#Validation rules

• Asset must be "XUSD".
• Amount must match the LeaseCost() formula (see Cost Model).
• Sender must have sufficient XUSD balance: previousBalance - Amount = Balance.
• Duration must be between 60 seconds and 31,536,000 seconds (365 days).
• VCPUs, MemoryMB, and DiskGB must each be > 0.

#Side effects

Creates a pending send (like a regular send) with the XUSD amount directed at the provider. The lease is not active until the provider creates a lease_accept block.

#Binary encoding

Type byte: 0x04. Tail: destination(32) + amount(8) + vcpus(8) + memory_mb(8) + disk_gb(8) + duration(8) + access_pub_key(32). Total canonical size: 226 bytes (90 header + 104 tail + 32 representative).

#Lease Accept (lease_accept)

The provider accepts a lease, staking XUSD as collateral. This activates the lease.

#Type-specific fields

#Validation rules

• Asset must be "XUSD".
• Source must reference a valid, unaccepted lease block.
• Amount must equal leaseCost / 5 (the stake divisor is 5).
• Provider must have sufficient XUSD balance: previousBalance - Amount = Balance.
• Requires timekeeper attestations if the state chain has sys.timekeepers configured.

#Side effects

A Lease record is created tracking the consumer, provider, resources, cost, stake, and start time. The provider's XUSD is locked as stake.

#Attestations

Lease accept blocks carry Attestations -- signed timestamps from trusted timekeeper nodes. These are not included in the block hash (they are attached after signing). Validation checks that the required number of attestations are present and their signatures are valid.

1type TimekeeperAttestation struct {2    PublicKey string // hex ed25519 pubkey of timekeeper3    Timestamp int64  // unix nanos attested4    Signature string // hex ed25519 sig over sha256(leaseHashBytes || timestampBytes)5}

#Binary encoding

Type byte: 0x05. Tail: source(32) + amount(8). Total canonical size: 162 bytes (90 header + 40 tail + 32 representative).

#Lease Settle (lease_settle)

Settles an expired lease and emits XE as a reward to the provider.

#Type-specific fields

#Validation rules

• Asset must be "XE".
• Source must reference an active (non-settled) lease.
• The lease must have expired (current time > start time + duration).
• Amount must match the emission formula based on the lease cost.
• Requires timekeeper attestations if configured.

#Side effects

• The lease is marked as settled.
• The provider's XUSD stake is returned (added back to their XUSD balance).
• XE is emitted to the provider's account (Balance = previousXEBalance + Amount).

#Binary encoding

Type byte: 0x06. Tail: source(32) + amount(8). Total canonical size: 162 bytes (90 header + 40 tail + 32 representative).

#Multisig Open (multisig_open)

Opens a new multisig account with a hash-derived address.

#Type-specific fields

#Validation rules

• account must equal sha256(canonical(keyset)) — the address is derived from the keyset.
• keyset.threshold >= 1 and <= len(keys), no duplicate keys.
• Block must have threshold valid signatures from keyset members.
• Account must not already exist.
• Balance must be 0.

#Binary encoding

Type byte: 0x08. Tail: canonical_keyset(threshold_u32_be + num_keys_u32_be + sorted_keys_32_each). Canonical size varies with key count.

#Multisig Update (multisig_update)

Rotates the keyset on an existing multisig account.

#Type-specific fields

#Validation rules

• Account must be an existing multisig account.
• Signed by the current keyset's threshold.
• Balance must be unchanged.
• The account address does NOT change (derived from original keyset).

#Binary encoding

Type byte: 0x09. Same tail format as multisig_open.

#Summary table

#Block lifecycle

  Creator                   Network                     Recipient  ───────                   ───────                     ─────────  1. Build block fields  2. MarshalBlockCanonical()  3. SHA-256 → Hash  4. ed25519.Sign(hash) → Signature  5. ComputePoW(hash) → PoWNonce  6. Broadcast via gossip ──────►                            7. VerifyBlock (hash + sig)                            8. ValidatePoW (nonce)                            9. Ledger validation                           10. Add to account chain                           11. Rebroadcast ─────────────►                                                        12. (for sends) appears as PendingSend                                                        13. (recipient creates receive block)