Wallet Features

Detailed reference for the wallet section of the node's embedded web UI.

The wallet section spans three pages, plus two that are revealed only when the active account qualifies:

Setup flow

A browser with no vault is offered two options.

Create wallet

1. A random 32-byte seed is generated via crypto.getRandomValues
2. The user chooses an optional name and a passphrase (minimum 8 characters)
3. The seed is displayed once behind an "I have saved my seed securely" confirmation
4. The seed is encrypted and stored in localStorage
5. The wallet unlocks

Import wallet

1. The user pastes a 64-character hex seed
2. The user sets a passphrase
3. The seed is validated, encrypted, and stored

[!TIP] Tip xe wallet create writes a 64-character hex seed to ~/.xe/wallet.seed (override with XE_WALLET). That seed can be pasted straight into the wallet's import form -- both sides derive the same ed25519 key from it.

Migration

If the browser holds an unencrypted seed from an older wallet version, a migration form appears instead: choosing a passphrase encrypts the seed into the vault and removes the plaintext copy.

Overview page

The main page after unlocking.

Wallet switcher

Pills for each wallet in the vault, plus + add, manage, lock and remove. Locking forgets the cached passphrase for the session.

Wallet and balances

• Full account address, with a link through to the explorer's account page
• Last block (the account's frontier)
• Per-asset total and spendable balances

Spendable is the finalized portion of the balance. Unfinalized inflows are still reversible, so they are excluded from what the wallet will let you spend.

Faucet

A request faucet button appears only when the node's UI handler is configured with a faucet target, which xe node does not set -- so it is hidden on a stock node. When present it requests a testnet XUSD grant that arrives as a pending receive.

[!WARNING] Testnet only The faucet is a testnet facility, and the faucet service is not yet deployed. Do not plan a funding flow around it.

Pending receives

Each pending send addressed to the account is listed with time, asset, amount, sender and send-block hash, plus a receive button. Receiving is explicit and per-item -- the wallet does not auto-receive.

Send form

Submitting a send:

1. Check the amount against the spendable balance
2. Byte-count the memo (the input's maxlength counts characters, not bytes)
3. Build the canonical send bytes from the account's frontier and current balance
4. Hash with the network ID prefix, sign with Web Crypto Ed25519
5. Solve Blake2b proof of work in the browser
6. POST /blocks/send

Receiving follows the same path against POST /blocks/receive. These are the only two block types the wallet builds; leases, burns, mints and multisig operations are not exposed here.

History and activity

History shows the tail of the account chain -- time, type, asset, amount, balance, hash. Activity is a local log of what this browser did (signing, submission, successes and failures) and can be cleared.

Reveal seed

Re-entering the passphrase decrypts and displays the active wallet's seed, with copy and hide controls.

Manage wallets (/wallet/wallets/)

[!WARNING] Removing a wallet is local and final The vault is the only copy in the browser. Removing an entry deletes the encrypted seed; without the seed written down elsewhere, the account is unrecoverable.

Chat (/chat/)

Peer-to-peer messaging between XE accounts.

Identity and registration

The page registers the active account in the node's account directory (POST /directory/register) so peers can find a node that will relay to it.

Reading requires an ownership proof

Reading an account's history or event stream requires proving ownership of that account: the page fetches a single-use challenge from GET /chat/auth/challenge, signs SHA-256(domain || challenge) with the account key, and passes account, challenge and signature as query parameters -- as parameters rather than headers, so the same proof works for EventSource. Each challenge is consumed once, so a fresh one is fetched per request.

Messaging

• Contact list of recent conversations
• Conversation view, messages coloured by direction
• Live updates over Server-Sent Events (GET /chat/events)
• Sending posts a signed envelope to POST /chat/send

Every message is an envelope whose ID is a hash over the sender, recipient, message and timestamp; the sender signs that ID and solves a cheap anti-spam proof of work over the same bytes. See Cryptography.

Provider dashboard (/provider/)

Revealed when one of the vault's addresses appears in GET /providers.

• Identity -- the provider account
• Capacity and utilisation -- advertised vCPU, memory and disk against what is in use
• Active leases -- leases currently running against this provider
• Past leases -- completed leases

DAO governance (/dao/)

Revealed when one of the vault's addresses is in the state chain keyset.

• State chain -- current tip and recent blocks
• Draft block -- add SET key value / DELETE key operations and preview the operation list
• Hash -- the canonical hash of the drafted block
• Signatures -- sign the hash with the active wallet, and track signatures against the threshold
• Import signature -- paste signatures collected from other members
• Submit -- once the threshold is met, submit the block to the network

See also

• Wallet Overview -- architecture and how the UI is served
• Wallet Security -- encryption and session handling
• Cryptography -- signing primitives
• Proof of Work -- client-side PoW details
• Compute Leasing -- lease lifecycle
• State Chain -- DAO governance model