Block Types

The block types used by the XE block-lattice

XE has twelve 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:

Field

Type

Description

Type

string

Block type identifier: send, receive, mint, genesis, burn, lease, lease_accept, lease_settle, lease_cancel, lease_force_settle, multisig_open, multisig_update

Account

string

Hex-encoded ed25519 public key of the account that owns this block (64 hex chars)

Previous

string

Hash of the previous block on this account's chain; "0" for the first block

Balance

uint64

Account balance for this asset after this block

Timestamp

int64

Unix nanoseconds when the block was created

Asset

string

Asset identifier: "XE" or "XUSD"

Representative

string

Hex public key of this account's voting delegate (empty for no delegation)

Hash

string

SHA-256 over the network ID, the canonical binary encoding, and the auxiliary tail (64 hex chars) — see Encoding

Memo

string

Optional clear-text annotation, at most 64 bytes of UTF-8. Allowed on send and burn blocks only; hashed as part of the canonical bytes

Signature

string

Ed25519 signature over the hash bytes (128 hex chars)

PoWNonce

uint64

Anti-spam proof-of-work nonce (excluded from hash computation)

Signatures

array

Multisig signatures array (replaces Signature for multisig accounts)

Keyset

object

Multisig keyset for multisig_open and multisig_update blocks

[!INFO] PoW nonce exclusion The PoWNonce is computed after signing. It is excluded from Hash computation so the signature remains valid regardless of the nonce value. The PoW is validated separately by checking that blake2b(nonce || hashBytes) >= difficulty.

[!NOTE] Hash inputs HashBlock computes sha256(networkID || canonicalBytes || auxBytes). The network ID scopes every block to one network instance. auxBytes is empty for non-lease blocks; for lease, lease_accept, lease_settle, and lease_force_settle it frames the CertificateHash and the (public-key-sorted) Attestations set, so those fields cannot be rewritten in transit while the hash and signature still verify.

Send (send)

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

Type-specific fields

Field

Type

Description

Destination

string

Hex public key of the recipient account

Amount

uint64

Number of tokens to send

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, and must not be the sending account itself.
  • Previous must match the account's current frontier, and Timestamp must not go backwards on the chain.
  • Asset must be "XE" or "XUSD".
  • Memo, if present, must be ≤ 64 bytes of valid UTF-8 with no ASCII control bytes other than tab and newline.

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: 163 bytes and up (90 header + 40 tail + 32 representative + 1 memo-length byte + memo bytes). The memo-length byte is always written, so a missing memo and an empty memo encode identically.

Receive (receive)

Credits the recipient's balance from a pending send.

Type-specific fields

Field

Type

Description

Source

string

Hash of the send block being received

Validation rules

  • Source must reference an existing pending send where Destination matches this block's Account.
  • Balance must equal previousBalance + pendingSend.Amount. On an open-receive (the account's first block, Previous = "0") it must equal the pending amount exactly.
  • Asset must match the pending send's asset.
  • The source must not be a live lease escrow — a lease's pending send is addressed to the provider but can only be resolved by lease_settle, lease_cancel, or lease_force_settle, never by a plain receive.
  • The source send's chain position must not be covered by an unresolved conflict. A receive of a contested send is deferred (retryable) until exactly one sibling wins.

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).

Mint (mint)

Creates new XUSD on an authorized minter's own chain. There is no counterparty and no pending entry — the minter then distributes XUSD by ordinary send → receive.

Type-specific fields

Field

Type

Description

Amount

uint64

XUSD to create, in micro-units

Validation rules

  • Asset must be "XUSD". XE is never mintable — its supply is genesis plus lease emission only.
  • Account must be listed in the sys.minter state-chain config. With no minter configured, every mint is unauthorized.
  • Amount must be > 0; Destination, Source, and Memo must be empty.
  • Balance must equal previousBalance + Amount (or exactly Amount when the mint opens the account with Previous = "0").

Side effects

The minter's XUSD balance increases by Amount.

[!NOTE] Mint replaced the permissionless claim block Earlier revisions of the protocol had a permissionless claim block that let any account self-mint XUSD. It was removed: minting is now restricted to accounts registered under sys.minter, and mint blocks go through the normal AddBlock path, so a mint race is detected and resolved as an ordinary equivocation.

Binary encoding

Type byte: 0x0D. Tail: amount(8). Total canonical size: 130 bytes (90 header + 8 tail + 32 representative).

Burn (burn)

Permanently destroys XE from the issuing account's balance. There is no destination, no pending entry, and no counterpart.

Type-specific fields

Field

Type

Description

Amount

uint64

XE to destroy, in micro-units

Validation rules

  • Asset must be "XE". Burning XUSD is not supported.
  • Amount must be > 0 and must not exceed the account's XE balance.
  • Destination and Source must be empty.
  • Balance must equal previousBalance - Amount.
  • Memo, if present, follows the same 64-byte UTF-8 rules as on a send.

Side effects

The XE is removed from circulation. Nothing is credited anywhere.

Binary encoding

Type byte: 0x0B. Tail: amount(8). Total canonical size: 131 bytes and up (90 header + 8 tail + 32 representative + 1 memo-length byte + memo bytes).

Genesis (genesis)

The first block of the ledger. It mints the initial XE supply to the treasury account and, optionally, pins the network's lease timing.

Type-specific fields

None beyond the common fields, plus the optional genesis-only lease-timing fields (lease_min_duration_secs, lease_settle_grace_ns, lease_force_settle_gap_ns, lease_escrow_expiry_ns, lease_archive_gap_ns, max_attestation_skew_ns).

Validation rules

  • The ledger must be empty — genesis is only valid as the very first block.
  • The block must match the binary's embedded genesis hash exactly.
  • Previous must be "0", Timestamp must be 0, and Asset must be "XE".
  • Balance must equal the genesis supply: 42,000,000 XE (42_000_000 × 10^6 micro-XE).
  • Representative, if set, must be a 64-hex-character public key. It seeds the treasury's delegation so vote weight exists from block 0.

Side effects

The treasury account is opened with the full genesis supply. Any lease-timing fields present are applied as this network's timing values; fields left at zero fall back to the production defaults.

[!INFO] Lease timing is pinned at genesis A network can override the lease timing constants in its genesis block, so a compressed test network is a different genesis rather than a different binary. A genesis with no timing fields encodes byte-identically to one from before the feature existed. Read the live values from GET /node rather than assuming the defaults.

Binary encoding

Type byte: 0x07. No type-specific tail. Total canonical size: 122 bytes (90 header + 32 representative), or 170 bytes when the 48-byte lease-timing tail is present.

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

Field

Type

Description

Destination

string

Hex public key of the provider account

Amount

uint64

Total XUSD cost of the lease

VCPUs

uint64

Number of virtual CPUs requested

MemoryMB

uint64

Memory in megabytes

DiskGB

uint64

Disk in gigabytes

Duration

uint64

Lease duration in seconds

AccessPubKey

string

Optional 32-byte hex ed25519 public key used to authenticate access to the leased VM

CertificateHash

string

Hash of the provider's performance certificate, which locks in the price multiplier at offer time (required)

Validation rules

  • Asset must be "XUSD".
  • Destination must be set and must not be the leasing account itself.
  • At least one of VCPUs, MemoryMB, DiskGB must be > 0.
  • Duration must be between the network's minimum lease duration (production default 60 seconds) and 31,536,000 seconds (365 days).
  • CertificateHash must reference a certificate that belongs to Destination and has not expired as of the block's timestamp.
  • Amount must match the LeaseCost() formula, evaluated with that certificate's price multiplier (see Cost Model).
  • Sender must have sufficient XUSD balance: previousBalance - Amount = Balance.

Side effects

Creates a pending send (like a regular send) with the XUSD amount directed at the provider — the lease escrow — and records a Lease in the created state. The lease is not active until the provider creates a lease_accept block. The escrow is not a normal receivable: it is burned at settle, or refunded by lease_cancel / lease_force_settle.

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

Field

Type

Description

Source

string

Hash of the consumer's lease block

Amount

uint64

XUSD stake amount, ⌈cost / 5⌉ (minimum 1 micro-XUSD)

CertificateHash

string

Must be the same certificate the consumer referenced on the lease block

LockedR

uint64

R_effective at accept time, scaled ×1000

LockedPayoutCap

uint64

Hermite payout cap at accept time, scaled ×1000

LockedTWAP

uint64

TWAP at accept time, in milli-USD

Validation rules

  • Asset must be "XUSD".
  • Source must reference a lease block whose Destination is this provider, and whose lease is still in the created state.
  • Amount must equal ⌈leaseCost / 5⌉, minimum 1 micro-XUSD (the stake divisor is 5).
  • Provider must have sufficient XUSD balance: previousBalance - Amount = Balance.
  • Timekeeper attestations are mandatory — sys.timekeepers must be configured and the attestation threshold met. Self-reported timestamps are never accepted.
  • CertificateHash must match the lease block's certificate, belong to this provider, and not be expired at the attested start time.
  • LockedR must be set, and the locked triple must match a state-chain epoch's emission parameters.

Side effects

The lease record moves to the accepted state, recording the stake and the attested start time. The provider's XUSD is locked as stake. The consumer's escrow stays alive — it is not drained here.

Attestations

Lease accept blocks carry Attestations -- signed timestamps from trusted timekeeper nodes. They are attached after the block body is built, so they are not part of the canonical encoding, but they are bound into the block hash through the auxiliary tail together with CertificateHash. Validation checks that the required number of attestations are present and their signatures are valid; the attested median becomes the lease's start time.

type TimekeeperAttestation struct {
    PublicKey string // hex ed25519 pubkey of timekeeper
    Timestamp int64  // unix nanos attested
    Signature string // hex ed25519 sig over sha256(leaseHashBytes || timestampBytes)
}

Binary encoding

Type byte: 0x05. Tail: source(32) + amount(8) + locked_r(8) + locked_payout_cap(8) + locked_twap(8). Total canonical size: 186 bytes (90 header + 64 tail + 32 representative).

Lease Settle (lease_settle)

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

Type-specific fields

Field

Type

Description

Source

string

Hash of the original lease block

Amount

uint64

XE emission reward

Validation rules

  • Asset must be "XE".
  • Source must reference a lease in the accepted state whose provider is this account. A lease still in created defers the settle (retryable) until the accept lands.
  • The lease must have expired: the attested timestamp must be at or past startTime + duration, and no later than expiry + LeaseSettleGrace (production default 1 hour).
  • Timekeeper attestations are mandatory.
  • Amount must equal ⌈cost × R_capped / 1000⌉ (minimum 1 micro-XE), using the emission parameters locked onto the lease at accept time.
  • The consumer's escrow pending send must still exist.

Side effects

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

[!INFO] XE emission Lease settlement is the mechanism by which new XE enters circulation. Providers earn XE proportional to the compute they deliver, creating a link between real-world utility and token emission.

Binary encoding

Type byte: 0x06. Tail: source(32) + amount(8). Total canonical size: 162 bytes (90 header + 40 tail + 32 representative). Unlike lease_accept, a settle carries no locked emission params — it reads them from the lease record.

Lease Cancel (lease_cancel)

The consumer withdraws a lease that no provider has accepted, refunding the escrow.

Type-specific fields

Field

Type

Description

Source

string

Hash of the consumer's own lease block

Validation rules

  • Asset must be "XUSD".
  • Source must reference a lease block created by this same account — only the consumer can cancel.
  • The lease must be in the created state, and its escrow pending send must still exist.
  • Balance must equal previousBalance + leaseCost (the full refund).

Side effects

The escrow pending send is deleted, the full cost is refunded to the consumer, and the lease is marked cancelled.

[!NOTE] Cancel wins over a racing accept If a cancel and an accept race across nodes, the outcome is deterministic: the cancel wins. A node that already applied the provider's accept unwinds it so the cancel proceeds, converging with nodes that saw the cancel first. The exception is a finalized accept — a finalized block legitimately won consensus and is never unwound, so the cancel is rejected instead.

Binary encoding

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

Lease Force Settle (lease_force_settle)

The consumer resolves an accepted lease that the provider never settled. It lives on the consumer's chain, disjoint from the provider's lease_settle.

Type-specific fields

Field

Type

Description

Source

string

Hash of the consumer's own lease block

Validation rules

  • Asset must be "XUSD".
  • Source must reference a lease block created by this same account — only the consumer can force-settle.
  • The lease must be in the accepted state, and its escrow must still exist.
  • Timekeeper attestations are mandatory, and the attested median must be at or past expiry + LeaseSettleGrace + LeaseForceSettleGap — 1h25m after expiry on production timing.
  • The attested median must be before expiry + LeaseEscrowExpiry (production default 365 days). Past that the refund window has closed and the escrow is considered burnt.
  • Balance must equal previousBalance + leaseCost.

Side effects

The consumer's full cost is refunded from the escrow, the provider's stake is burned (not returned, unlike lease_settle), and the lease is marked unfulfilled. No XE is emitted.

[!INFO] Disjoint windows LeaseForceSettleGap must exceed twice the maximum attestation skew, so no single real timestamp — even shifted by the maximum skew on each side — can satisfy both the provider's settle window and the consumer's force-settle window. The genesis validator enforces this bound on any genesis-pinned value.

Binary encoding

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

Multisig Open (multisig_open)

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

Type-specific fields

Field

Type

Description

Keyset

object

{keys: [pubkey1, pubkey2, ...], threshold: N}

Signatures

array

[{public_key, signature}, ...] — must have threshold valid signatures

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 is 130 + 32 × numKeys bytes (90 header + 8 keyset header + 32 per key + 32 representative).

Multisig Update (multisig_update)

Rotates the keyset on an existing multisig account.

Type-specific fields

Field

Type

Description

Keyset

object

New keyset {keys: [...], threshold: N}

Signatures

array

Must have threshold valid signatures from the current (old) keyset

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

Type

Byte

Asset

Debits

Credits

Creates pending

Canonical size

send

0x01

XE or XUSD

sender

--

yes

163+ bytes

receive

0x02

XE or XUSD

--

recipient

consumes pending

154 bytes

lease

0x04

XUSD

consumer

--

yes (escrow)

226 bytes

lease_accept

0x05

XUSD

provider (stake)

--

lease → accepted

186 bytes

lease_settle

0x06

XE

--

provider (emission + stake back)

burns escrow, settles lease

162 bytes

genesis

0x07

XE

--

treasury (genesis supply)

--

122 or 170 bytes

multisig_open

0x08

XE or XUSD

--

--

registers keyset

130 + 32×keys

multisig_update

0x09

XE or XUSD

--

--

rotates keyset

130 + 32×keys

lease_cancel

0x0A

XUSD

--

consumer (refund)

refunds escrow, cancels lease

154 bytes

burn

0x0B

XE

burner

--

--

131+ bytes

lease_force_settle

0x0C

XUSD

provider (stake burned)

consumer (refund)

refunds escrow, unfulfils lease

154 bytes

mint

0x0D

XUSD

--

minter

--

130 bytes

Block lifecycle

  Creator                   Network                     Recipient
  ───────                   ───────                     ─────────
  1. Build block fields
  2. MarshalBlockCanonical()
  3. HashBlock() → 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)
Common fieldsSend (send)Type-specific fieldsValidation rulesSide effectsBinary encodingReceive (receive)Type-specific fieldsValidation rulesSide effectsBinary encodingMint (mint)Type-specific fieldsValidation rulesSide effectsBinary encodingBurn (burn)Type-specific fieldsValidation rulesSide effectsBinary encodingGenesis (genesis)Type-specific fieldsValidation rulesSide effectsBinary encodingLease (lease)Type-specific fieldsValidation rulesSide effectsBinary encodingLease Accept (lease_accept)Type-specific fieldsValidation rulesSide effectsAttestationsBinary encodingLease Settle (lease_settle)Type-specific fieldsValidation rulesSide effectsBinary encodingLease Cancel (lease_cancel)Type-specific fieldsValidation rulesSide effectsBinary encodingLease Force Settle (lease_force_settle)Type-specific fieldsValidation rulesSide effectsBinary encodingMultisig Open (multisig_open)Type-specific fieldsValidation rulesBinary encodingMultisig Update (multisig_update)Type-specific fieldsValidation rulesBinary encodingSummary tableBlock lifecycle