Platform architecture

This is the public end-to-end view of ChatterPay B2B. It describes the supported model; the Roadmap describes what is available today.

The architecture is documented as one page per area. Start here for the whole picture, then follow whichever part you need:

• Design principles — the seven rules the rest of the design follows.
• Identity, users and wallets — tenants, users, one logical wallet, one account per network.
• Recipient resolution — how a phone number becomes an address.
• Operations, quotes and states — the durable record of a financial action and every state it can report.
• Events, ledger and reconciliation — how a change becomes an event, a ledger entry and a verified fact.
• Control Plane and capability manifests — the versioned configuration an operation runs under.
• Observability, audit and recovery — the five records kept apart, and how the system is brought back.
• Reference deployment topology — where each component runs in a Partner's own cloud.
• Who is responsible for what — the split between the Partner and ChatterPay.

End-to-end view

flowchart LR
    U[Partner user] -->|1| CH[Channel]
    CH -->|2| PI[Partner integration]
    PI -->|3| API[B2B API]
    API -->|4| CP[Control Plane]
    API -->|5| DP[Data Plane]
    DP -->|6| ID[Identity / WalletProfile]
    DP -->|7| OP[Operation Orchestrator]
    OP -->|8| Q[Quotes / fees / limits]
    OP -->|9| SG[SigningProvider]
    OP -->|10| ER[Execution Router]
    OP -->|11| L[Ledger]
    OP -->|12| EV[Outbox / events]
    ER --> EVM[EVM]
    ER --> BTC[Bitcoin]
    ER --> ADA[Cardano]
    ER --> SOL[Solana]
    ER --> TRX[Tron]
    EV -->|13| O[Observers]
    EV -->|13| R[Reconciler]
    EV -->|14| WH[Webhook Dispatcher]
    DP --> DB[(PostgreSQL)]

What each step does

1. Partner user → Channel. A person acts from wherever the Partner put the product: the Partner's own application, WhatsApp, or another enabled channel. The channel collects the intent and shows the quote; it holds no financial rule of its own.
2. Channel → Partner integration. The Partner's backend turns that intent into an API call, authenticated with its own credentials.
3. Partner integration → B2B API. The public contract. The API authenticates the caller, derives the tenant from the credential, and validates the request.
4. API → Control Plane. Before anything executes, the API reads which networks, assets, contracts, limits and policies are enabled for that tenant, and under which manifest version.
5. API → Data Plane. The part that actually moves money, always scoped to one tenant.
6. Identity / WalletProfile. Resolves who the user is and which account on which network will send or receive.
7. Operation Orchestrator. Persists the Operation and drives it through its steps. This is what makes the flow survive a restart.
8. Quotes, fees and limits. Prices the operation and checks it against the tenant's limits before authorizing anything.
9. SigningProvider. Requests the signature from the Partner Signer Gateway. The API sends a digest and a key reference, and receives a signature.
10. Execution Router. Chooses the adapter for the network the operation settles on. Each family keeps its own transaction model behind this boundary.
11. Ledger. Records the internal financial impact as append-only entries.
12. Outbox / events. Writes the event in the same database transaction as the change that caused it, so no state change can exist without its event.
13. Observers and Reconciler. Watch the chain and confirm that what settled matches what was recorded.
14. Webhook Dispatcher. Delivers the signed event to the Partner.

Control Plane and Data Plane

The Control Plane manages versioned configuration: tenants, networks, assets, providers, fees, limits and capability manifests.

The Data Plane executes financial operations against an approved configuration version. The separation is what lets configuration change without a deployment, and what lets an audit reconstruct the exact configuration an old operation ran under.

The Channel step covers both Partner-app-first and WhatsApp-first entry points; see Partner integration for how each one authorizes and confirms an operation.

Native blockchain families

EVM uses EIP-7702 accounts and can execute directly or through ERC-4337. Bitcoin uses UTXOs and PSBT-style signing. Cardano uses EUTXO, native addresses and keys, and multi-asset transaction rules. Solana uses program-owned accounts, a separate account per token, and transactions that are only valid for a short window after the blockhash they carry. Tron is account-based on the same signature curve as EVM, but with base58 addresses and bandwidth and energy accounting instead of a single gas price.

LI.FI is a route provider the platform uses to move value between these families.

Signing boundary

Initial baseline The partner_managed signing model uses one high-entropy master key per deployment behind the Partner Signer Gateway, kept in a protected secret store that only the gateway can read. The B2B API receives only versioned keyReference values, public addresses and signatures — never the master key itself.

Hardening options Independent per-wallet keys, non-exportable KMS or HSM keys, MPC and user-controlled custody all remain compatible behind the same SigningProvider boundary. See Security and signing.