Assets¶

XE is a dual-asset network. Two native assets -- XE and XUSD -- coexist on the same block lattice, tracked independently per account.

The two assets¶

XE¶

The primary asset. XE has a single role:

Emission reward. New XE is minted when compute leases are settled. Providers earn XE proportional to the resources they delivered.

XUSD¶

The payment asset for compute. XUSD has two roles:

Lease payment. Consumers pay XUSD to lease compute resources. Providers stake XUSD as collateral when accepting leases.
Voting weight. An account's XUSD balance determines its delegation weight for consensus. When an account delegates to a representative, only XUSD balance is counted.

Asset encoding¶

The asset identifier is stored as an 8-byte field in the block's canonical binary encoding. The value is left-aligned UTF-8, zero-padded to 8 bytes:

Asset	Bytes (hex)
`"XE"`	`58 45 00 00 00 00 00 00`
`"XUSD"`	`58 55 53 44 00 00 00 00`

var assetBytes [8]byte
copy(assetBytes[:], "XE")   // left-aligned, zero-padded

When decoding, trailing zero bytes are trimmed to recover the original string.

Valid assets¶

The validAssets allowlist controls which asset identifiers are accepted:

var validAssets = map[string]bool{
    "XE":   true,
    "XUSD": true,
}

func IsValidAsset(name string) bool {
    return validAssets[name]
}

Any block with an asset identifier not recognized by IsValidAsset is rejected during validation.

Per-account balances¶

Each account maintains independent balances for each asset. An account can hold XE and XUSD simultaneously -- they are tracked in separate balance maps:

Account 0xabc123...
  XE:   500
  XUSD: 1200

The Balance field on a block refers to the balance of the block's Asset after the operation. A send of 100 XE updates the XE balance; the XUSD balance is unaffected.

Asset isolation

Blocks are asset-specific. A send block with Asset: "XE" debits the sender's XE balance. A send block with Asset: "XUSD" debits XUSD. You cannot send XE and XUSD in the same block.

Asset rules by block type¶

Block type	Required asset	Notes
`send`	XE or XUSD	Sender chooses which asset to send
`receive`	Must match the send	Automatically determined by the pending send's asset
`claim`	XUSD	Faucet: mints 100 XUSD (rate limited to once per 24h per account)
`lease`	XUSD	Compute is always paid for in XUSD
`lease_accept`	XUSD	Provider stakes XUSD collateral
`lease_settle`	XE	Emission reward is always XE

Delegation weight¶

Only XUSD contributes to consensus weight. The ledger maintains a delegation map:

account → representative

When calculating voting power, the ledger sums the XUSD balances of all accounts that delegate to a given representative. XE balances are excluded from this calculation.

This separation means:

Compute users who hold XUSD for leases also have governance power.
Providers earn XE through settlements but need XUSD for voting weight.
The faucet distributes XUSD, allowing new participants to gain governance weight.

Lease economics and asset flow¶

The lifecycle of a compute lease shows how both assets flow through the system:

Consumer                    Provider
────────                    ────────
1. lease block
   Asset: XUSD
   Debits: -cost XUSD
                            2. lease_accept block
                               Asset: XUSD
                               Debits: -stake XUSD (cost/5)

   ... lease runs ...

                            3. lease_settle block
                               Asset: XE
                               Credits: +emission XE
                               Side effect: +stake XUSD returned

The consumer pays XUSD. The provider stakes XUSD. At settlement, the provider gets their XUSD stake back and earns new XE. This creates a circular economy: XUSD flows from consumers to the network, and XE flows from the network to providers.

Cost formula¶

Placeholder rates

The rates below are dummy values for development. Final economic parameters are pending design review. See Cost Model.

Lease costs are computed from resource dimensions and duration using milli-XUSD per hour rates:

perHourMilli = vCPUs x 20 + ceil(memoryMB / 1024) x 10 + diskGB x 1
hours        = ceil(duration / 3600)
costMilli    = perHourMilli x hours
cost         = ceil(costMilli / 1000)     // minimum 1

Resource	Rate	Unit
vCPU	20 milli-XUSD	per vCPU per hour
Memory	10 milli-XUSD	per GB per hour
Disk	1 milli-XUSD	per GB per hour

The provider's stake is cost / 5 (min 1). The XE emission at settlement equals the cost.

See Cost Model for the full formula and examples.