01
Authorisation
The wallet signs a network-bound instruction covering inputs, recipient, value, fee, deadlines and execution plan. A valid signature is necessary but does not alone settle the payment.
TECHNICAL DOCUMENTATION
Follow the proof.
Verify the state.
The protocol separates payment authorisation, execution, consensus and client verification. Each boundary has explicit evidence and acceptance rules.
Product documentation · Edition 1 ·
ARCHITECTURE
Four boundaries to verify.
02
Execution
The state machine checks spendability, reservations, assigned work and receipts. Integer accounting preserves value across outputs, escrow, stake and fees.
03
Consensus
CometBFT certifies the ordered history with more than two thirds of voting weight. Ten equally weighted seats require at least seven signatures.
04
Checkpoint & continuation
A checkpoint binds the network, policy, height, block hash and state snapshot. Its separate signer threshold bootstraps verification of subsequent consensus history.
CLIENT VERIFICATION
One authenticated path.
- 01
Authenticate the starting configuration
Pin the network genesis and policy root from an authenticated distribution. A checksum verifies integrity relative to that distribution; it does not independently establish its publisher.
- 02
Verify checkpoint authority
Validate the signer set, threshold, policy version, issuance time and expiry. The four-role checkpoint profile requires three signatures; this does not replace the validator quorum.
- 03
Verify the continuation
Check signed headers, validator-set transitions and consecutive links. Retained newer history must remain on the accepted path. More RPC responses cannot override contradictory authenticated history.
- 04
Verify the state commitment
Match the snapshot to the certified application hash. CometBFT appHash at block H commits the application state at H−1. Advance the stored verified position only after successful checks.
PAYMENT STATE MACHINE
Reserve. Settle or expire.
| Transition | Required checks | Result |
|---|---|---|
| RESERVE | Signed intent, network and policy binding, available inputs, fee, deadlines and valid work plan. | Inputs are committed to a unique payment identifier. |
| FINALIZE | Matching reservation and sufficient valid assigned-work receipts before its terminal boundary. | Recipient outputs and fee accounting are created once. |
| EXPIRE | The reservation is still open and the protocol deadline has passed. | Reserved value is returned according to the signed expiry-fee rule. |
Settlement and expiry are mutually exclusive. Retrying a terminal request cannot produce a second payment. Reserved collateral cannot back simultaneous obligations beyond its permitted exposure.
Deterministic accounting and time
Use integer amounts and specified rounding. The conservation identity is outputs + escrow + stake + fees = supply. Payment deadlines in the checkpoint state machine use its logical money height; do not treat that counter as wall-clock seconds. Policy validity uses UTC timestamps.
Freshness and a long absence
A client checks retained history in bounded batches and persists verified progress. Spendability requires a fresh authenticated endpoint and matching state, not just a successful connection. Recovery needs sources retaining the intervening headers and validator sets.
INTEGRATION BOUNDARIES
Keep the wallet local.
The packaged wallet is bound to loopback. Its HTTP interface is a local application interface, not a public merchant or custodial API. Host and origin checks and the process-local X-DueByte-Token session header protect wallet actions. Never publish the wallet port.
| Local operation | Purpose |
|---|---|
| GET /status | Lock state, verification time, balances and payment records. |
| GET /backup | Export the encrypted wallet after unlocking. |
| POST /create · /unlock · /lock | Manage the local wallet session. |
| POST /restore | Import a compatible encrypted wallet and its password. |
| POST /send · /refresh | Submit a payment instruction or refresh verified state. |
Automations must preserve the same authorisation and verification boundaries. Never place a wallet password, backup or session token in a URL, third-party script, business profile or public log.
Release and source selection
Match integration code to the release tag and bundled network profile. Use the release record for package provenance. A product document does not alter the wire format, accepted genesis or signed policy.
GLOSSARY
Read the evidence precisely.
| Term | Meaning |
|---|---|
| Checkpoint | A threshold-signed reference to network history and application state. |
| Quorum | The required signing weight within an authorised set, not a poll of reachable devices. |
| Reservation | A commitment of inputs to one payment while its execution is unresolved. |
| Finality | The accepted terminal outcome under the consensus rules and their trust assumptions. |
| Operator | The person or organisation responsible for a node or assigned service. |
| Control group | Operators or keys subject to common control; separate keys do not prove independence. |
| Evidence | Checkable records supporting a conclusion, distinct from the authority to decide it. |