CRYPTO PROCESSING
View integration model Discuss your use case

Platform / Processing core

One API from blockchain activity
to ledger-backed balances.

Create partner-owned users and permanent deposit destinations, credit deposits only after finality, and run withdrawals through explicit money states without exposing the execution layer to your product.

Explore the lifecycle View the money model
  • One default account per user
  • Permanent network destinations
  • Account-wallet balance isolation
ACCOUNT + WALLET / PRODUCT MODEL REFERENCE FLOW
PARTNER ACTION Create external user
DURABLE LOCAL OUTCOME
User
Partner-owned identity
Account
Automatic default
Wallet
After account readiness
  1. User and default account created Same durable local outcome
    CREATED TOGETHER
  2. Account provisioning begins The same account is retained through retries
    PROVISIONING
  3. Account becomes ready Wallet creation can now begin
    READY
  4. Asset wallet and destinations provisioned Each network is usable when its permanent destination is ready
    PER NETWORK
Same objects retained retry does not recreate the account

01 / Explicit lifecycles

Deposits and withdrawals become public at different points.

A deposit becomes public only as a completed product outcome. A withdrawal becomes public when local acceptance and its reservation succeed, before execution begins.

A / INBOUND

Deposit lifecycle

Internal observations may be processed before finality, but they are not public transfers and have no balance effect.

  1. 01
    Destination resolved Permanent destination maps to wallet, account, user, and workspace.
    internal
  2. 02
    Observation deduplicated Repeated or out-of-order facts converge on one outcome.
    internal
  3. 03
    Finality established There is still no public pending balance or transfer.
    no public state
  4. 04
    Product outcome committed Completed transfer, available-balance credit, and Event are recorded together.
    completed
B / OUTBOUND

Withdrawal lifecycle

Every accepted withdrawal starts in processing with its gross amount reserved. Later states determine whether that reservation stays held, is consumed, or is released.

  1. 01
    Locally accepted Minimum, destination, and selected account-wallet balance checks succeed; amount is reserved.
    processing
  2. 02
    Execution accepted The configured execution source accepts submission; reservation stays held.
    submitted
  3. 03
    Operator resolution required Liquidity or execution state cannot be resolved safely; reservation stays held.
    attention_required
  4. 04
    Execution completed The reservation is consumed exactly once and an Event records the outcome.
    completed
  5. 05
    Non-execution confirmed The reservation is released exactly once and an Event records the outcome.
    failed

02 / Ledger-backed balances

Balances are a result, not a mutable number.

Every product balance belongs to one account wallet and economic asset. Available and reserved amounts are derived from balanced journals; execution-source holdings and internal asset movements never silently rewrite them.

Available
Funds that can be considered for a new withdrawal from this account wallet.
Reserved
Funds held for accepted, non-terminal withdrawals from this account wallet.
Total
Available plus reserved, evaluated independently for this account wallet.
ACCOUNT-WALLET BALANCE DEFAULT ACCOUNT / ASSET A
EXAMPLE
Example balance for one account wallet
Asset Available Reserved Total
ASSET A 87,550.00 12,450.00 100,000.00
JOURNAL / EXAMPLE WITHDRAWAL RESERVATION
01 available:asset_a −2,500.00
02 reserved:asset_a +2,500.00
NET MOVEMENT 0.00 ASSET A BALANCED MODEL

03 / Two independent money gates

A balance authorizes spending. Liquidity enables execution.

The selected account wallet and the configured execution source answer different questions. Neither gate grants or replaces the other.

GATE 01 account-wallet entitlement 
SELECTED ACCOUNT WALLET
  amount meets the product minimum
  available covers the gross request

ELIGIBLE
  reserve gross amount
  create withdrawal: processing

INELIGIBLE
  no reservation
  no public withdrawal
LOCAL ACCEPTANCE available → reserved
GATE 02 execution capacity 
CONFIGURED EXECUTION SOURCE
  selected economic asset
  selected network rail
  liquidity assessed asynchronously

SUFFICIENT
  submit → submitted

UNRESOLVED
  attention_required
  reservation remains held

DEFINITIVE FAILURE
  failed → reservation released
INDEPENDENT CHECK never creates entitlement

04 / Product fit and boundary

Built for account-based processing—not a checkout product.

V1 focuses on partner-owned users, permanent deposit destinations, and deposits and withdrawals scoped to an account wallet.

01 / USER MODEL

Your users stay yours

Represent partner-owned users through immutable external identifiers. Each user receives one automatic default account and never logs into this product.

02 / DEPOSIT MODEL

Permanent destinations

Create one wallet per account and economic asset, with reusable permanent destinations on the supported networks in the fixed product catalog.

03 / OPERATING MODEL

Managed processing layer

The product handles transfer state, signed Webhook Deliveries, internal reconciliation, durable exceptions, and controlled operator recovery behind the API.

04 / OUTSIDE V1

Explicit V1 boundary

No checkout, invoices, payment intents, fiat settlement, trading, conversion, compliance screening, or human withdrawal-approval workflow.

Standalone processing model

Evaluate the processing boundary before you build against it.

View integration model Discuss your use case