Triple-Entry Accounting, Anchored to Verified Identity
Double-entry bookkeeping has served commerce for 600 years — and costs $36 trillion a year in fraud, reconciliation failures, and audit disputes. SOS adds a cryptographically signed third entry anchored to ZK-verified identity on Base L2.
Architecture
What the Third Entry Does
The Shared Third Entry
Every transaction produces three records: debit (payer), credit (payee), and a shared TEA receipt anchored to Base L2. The receipt is cryptographically signed — neither party can unilaterally alter it.
Identity-Anchored by Design
The TEA receipt links the hashed SIDs of both parties — ZK-verified identities that prove KYC without exposing PII. Blockchain payments have always lacked identity context. SOS provides the missing layer.
FATF Travel Rule, Automated
FATF Recommendations 16 and 20 require identity information to accompany cross-border transfers. SOS satisfies both requirements at the protocol layer — no manual compliance reporting after the fact.
THE $36 TRILLION PROBLEM
Two Parties. Two Ledgers. Zero Shared Truth.
Double-entry accounting asks each counterparty to independently record the same transaction. The result: permanent reconciliation overhead, audit disputes, and a $36 trillion annual fraud surface that grows with every new cross-border payment corridor.
Traditional Double-Entry Approach
- Payer records a debit. Payee records a credit. No shared record exists — two independent ledgers, one transaction.
- Reconciliation requires manual matching across counterparty systems — expensive, slow, and error-prone at scale.
- Cross-border payments add correspondent banking layers, each with independent reconciliation and FATF reporting obligations.
- FATF Travel Rule compliance is bolted on post-transaction, adding regulatory overhead without improving accuracy.
The SOS Triple-Entry Layer
1. Shared Cryptographic Receipt
Both parties sign the third entry. Neither can dispute it unilaterally. Every cross-border transfer has a single, immutable source of truth.
2. ZK Identity Anchoring
The third entry links hashed SIDs — not names or account numbers. FATF identity requirements are satisfied without storing PII at the settlement layer.
3. On-Chain Immutability
The TEA receipt hash is anchored to Base L2. It cannot be altered retroactively, making audit trails mathematically provable — not bureaucratically asserted.
Result: One Source of Truth
Both parties, regulators, and auditors reference the same immutable receipt. Reconciliation overhead approaches zero. FATF compliance is automatic at the protocol level.
Data Model · Base L2
One Transaction. Three Entries.
Traditional ledger · payer only
Traditional ledger · payee only
Base L2 · FATF Rec 16/20 · immutable
Beyond Accounting · The Regulatory Frontier
TEA Is Not Just for Bookkeeping
Triple Entry Accounting is the compliance infrastructure for the next era of regulation — from UBI disbursement to AI governance.
The Thesis
TEA will better fight crime, improve economic efficiency, ensure that UBI systems can work, and ensure that all agreements or laws to regulate the technological advances in progress — especially AI — can actually be tracked and enforced in real time.
UBI systems need TEA to avoid becoming a bonanza for the fraudsters. New laws being developed for AI systems and data centres, such as the Australian Government's planned national standards on AI, will need TEA to allow automated, real-time management and enforcement.
Why TEA · Beyond Bookkeeping
Crime
Real-time fraud detection at the protocol layer
Efficiency
Automated reconciliation, no manual audit
UBI
Identity-verified disbursement, no fraud bonanza
AI Regulation
Enforceable standards for AI systems & data centres
See It Work in 60 Seconds
The TEA sandbox simulates a cross-border USDC settlement between two ZK-verified identities — eIDAS France to MOSIP Global South. Watch the TEA receipt mint in real time.
No credit card required.
Free to get started.