Intent
What was asked for, by whom, and on whose behalf.
Proof of Record In Development
Every financial operation should produce its own proof.
Proof of Record is a structured artifact produced by execution. It links what was intended, what was authorized, what each provider did, and what the ledger recorded, so anyone reviewing the operation can see how the outcome came about.
Status: In Development
Today, a Proof of Record token is minted for each succeeded settlement outflow, and payment timelines, attempt history and the financial explain endpoint expose execution evidence through the API. The complete execution record described on this page, one artifact linking intent, attempts, ledger entries and outcome, is being built.
Problem
Logs record what systems said. They do not explain what happened.
When an auditor, a partner bank or a customer asks how a payment ended up where it did, the answer is usually spread across application logs, provider dashboards, webhook histories and ledger exports. Someone has to stitch them together, and each system has its own clock, identifiers and idea of the truth.
- Logs are written for debugging and rotate. Financial evidence has to outlive them.
- A provider dashboard shows the provider's view, not what your system decided because of it.
- A ledger entry shows the result, not the attempts, approvals and responses that led to it.
Principle
An audit trail tells you what systems logged. Proof of Record explains how the financial outcome was produced.
| Logs and audit trail | Proof of Record | Ledger | |
|---|---|---|---|
| Answers | What did each system emit? | How was this outcome produced? | What is the financial state now? |
| Scope | Per system, per event | Per financial operation, across systems | Per account, across operations |
| Role | Diagnostics | Evidence | Authoritative state |
Proof of Record does not replace the ledger. The ledger remains the authoritative financial state. Proof of Record explains how that state was reached.
How it works
Produced by execution, not assembled afterwards.
Because the runtime governs each operation from intent to outcome, it can record the evidence as it happens rather than reconstructing it later. Each proof links:
Authorization
Which policy, scope or approval allowed it to proceed.
Execution states
Each state transition the operation went through, in order.
Provider interactions
Requests, responses, timeouts and notifications from external rails.
Wallet effects
How available and reserved balances changed as a result.
Ledger entries
The postings the operation produced in the authoritative ledger.
Timestamps
When each step happened, as observed by the runtime.
Final outcome
The resulting state, or an explicit statement that it is not yet known.
Architecture
Proof is the input to verification.
Proof of Record sits between execution and the decisions that follow it. Verification compares the recorded outcome with what external systems report. When they disagree, or the evidence is incomplete, Resolve starts from the same proof instead of a fresh investigation.
- Execution Governed operation
- Proof of Record Evidence of how it unfolded
- Verify Compared with provider reality
- Resolve When evidence conflicts or is missing
Unknown is recorded as unknown
If a provider never confirmed an outcome, the proof says so. It does not fill gaps with an assumed result. That explicit gap is what lets Resolve decide whether it is safe to act.
Attribution, including software actors
Whether an operation was started by a person, a backend service or an agent, the proof records the actor and the authority it acted under. See Agent Runtime.
Example
A payout that took two attempts.
A seller payout times out at the first provider. The runtime does not retry blindly. Once the first attempt is confirmed as failed, the payout is sent through a second provider and settles. Months later, the seller disputes the timing.
- Intent Seller payout, authorized by policy
- Attempt 1 Provider A timeout
- Confirmed failed Evidence attached
- Attempt 2 Provider B accepted
- Settled Ledger entries linked
The proof shows both attempts, why the second was allowed, when each response arrived, and which ledger entries moved the seller's balance. The answer comes from one record, not from three dashboards.
For developers
Inspect how to integrate it.
The v4 API is described by an OpenAPI contract. Start with the quickstart, then the parts that matter in production: errors, webhooks and the sandbox.
- Quickstart Authenticate, choose an environment, create a payout.
- API reference Representative v4 routes, objects and lifecycle statuses.
- Errors Errors versus unknown outcomes, and when retrying is safe.
- Webhooks Signatures, at-least-once delivery, retries and ordering.
- Sandbox Deterministic test provider, including failure outcomes.
- Integrations Providers, rails and channels in the catalog.
Pick one operation your auditors ask about.
We will show what its Proof of Record would contain and where that evidence lives in your systems today.