Transaction model · preview
PREVIEWOne transaction object. Many legs. One receipt.
Every Loadit capability — Load, Send, Connect, Convert, Receive, Cash Out, Loadit One — is the same object with a different type. This is what we would tell a team of engineers to build, published early so partners can review the shape before access opens.
One object
A transaction records the source value, the amount, the desired output or outputs, the destination or destinations, the fees, the partner route HQ selected, and the state. The customer or partner never buys “orchestration” — they state an outcome, and this object carries it end to end.
{
"id": "txn_…",
"type": "load", // load | send | convert | receive | cash_out | connect | spend
"source": { "kind": "cash", "currency": "USD", "amount": 500 },
"outputs": [ // one leg, or many
{ "asset": "USDC", "amount_usd": 200, "destination": "wallet:…" },
{ "asset": "BTC", "amount_usd": 125, "destination": "wallet:…" },
{ "asset": "ETH", "amount_usd": 100, "destination": "wallet:…" },
{ "asset": "SOL", "amount_usd": 75, "destination": "wallet:…" }
],
"constraints": { "max_fee_usd": 12, "prefer": "auto" },
"quote": { "total_usd": 508.75, "fees": [ … ], "expires_at": "…" },
"plan": { "engine": "HQ", "legs": [ … ], "conversions": [ … ] },
"state": "quoted" // quoted → funded → converting → paying_out → settled
}Parent and child legs
One $500 load can contain four output legs and still feel like one customer transaction. The parent holds the intent, the quote, and the overall state; each child leg holds its own partner, rail, conversion, fee, and state. The partner sees one identifier and one status feed. The ledger sees every leg.
| Level | Holds | State |
|---|---|---|
| parent | intent · quote · funding event · overall state · receipt | quoted → funded → in_progress → settled | partially_settled | resolved |
| leg | output · destination · partner · rail · conversion · fee · idempotency key | planned → executing → settled | failed → rerouted | refunded |
Types
| type | Source → outputs | Phase |
|---|---|---|
| load | cash or card funding event → one or many supported digital assets | 1 |
| send | what the sender holds → what the recipient wants (asset or currency may differ) | 2 |
| spend | supported fiat or crypto, possibly several eligible sources → one merchant-facing card settlement (Loadit One) | 3 |
| convert | value already held → one or many supported assets or currencies | 4 |
| receive | a standing rule: how incoming value arrives and is allocated | 4 |
| connect | a source on one supported platform → a destination on another | 5 |
| cash_out | supported digital value → an eligible cash or fiat exit | 6 |
Capability registry
Exactly which funding methods, assets, networks, partners, and destinations are live right now — machine readable, so a partner's product only offers what HQ can actually route today. Statuses on this site are drawn from the same idea: nothing is shown as available that the registry would not return.
{
"funding": { "cash": "in_build", "debit_card": "in_build", "bank_transfer": "in_build" },
"assets": ["USDC", "USDT", "BTC", "ETH", "SOL", "XRP"],
"networks": ["solana", "base", "ethereum", "polygon", "xrpl", "lightning", "stellar"],
"capabilities": { "load": "in_build", "multi_asset_load": "planned", "send": "planned", "spend": "planned",
"convert": "planned", "receive": "planned", "connect": "planned", "cash_out": "planned" }
}Quote before funding
The quote engine shows the total cost and the estimated amount of every output before anything is funded. A quote carries a time-to-live. The customer funds once, against the quote, and HQ executes the plan that was quoted — or re-plans within the disclosed rules if the world changed in between.
Partial failure
Every output leg must be completed, retried or rerouted where permitted, or resolved and refunded according to disclosed rules. There is no state in which a leg silently disappears. When a pipe fails mid-flight the payment is parked, the remaining legs are re-scored, and a new route is locked under the same identifier.
Idempotency
Every money-moving side effect carries a deterministic idempotency key derived from the transaction and the leg. Retries and reroutes can never double-execute. A double payout is impossible by construction, not by policy.
Reconciliation and receipt
Partners execute; Loadit verifies. Each leg's reported result is reconciled against the plan, and one receipt shows every output and every disclosed fee. Your ledger can reconcile it without knowing which rail carried the value.
The money map
Every live route must answer these ten questions in writing. Partners receive the answers for their corridor.
- 01Who has or controls the value before funding?
- 02Who accepts or authorizes the funding source?
- 03Who is custodian, if anyone?
- 04Who performs each conversion?
- 05Which rail or network moves each leg?
- 06Who bears fraud, chargeback, or settlement risk?
- 07What partner and network fees are charged?
- 08What Loadit fee, revenue share, API, or card-program economics apply?
- 09What exact output does the customer or merchant receive?
- 10What happens if one leg fails?