Payments on Rholo
R-Cash
A permissionless multi-currency account and cross-border payments network on Rholo: hold, receive, convert, and pay in the user’s own currency, with liquidity providers rather than correspondent banks earning the spread.
- What
- A permissionless account and payments rail: one non-custodial balance per currency, a direct mesh of FX pools between currencies, and a transfer contract with memo, claim, expiry, refund, and one terminal state. Liquidity providers earn the spread; there is no router and no mandatory USD hop.
- Why
- Payments is not a trading venue. It is a high-volume, multi-tenant, long-running operation: many small transfers, many currencies, narrow delegated authority, and workflows that outlive a block. A single global ledger makes unrelated tenants contend for one state; an approval-based token puts a global
transferFromsurface in front of every balance; concurrency becomes a scheduler problem. R-Cash places each currency, market, and transfer lane in its own contract and composes them by capability, on a node designed to shard horizontally. That is the architecture consumer payments needed and did not get. - The combination
- Rholo’s native capabilities on a shardable node, composed into per-currency issuer clusters, one FX pool per market, a transfer book with terminal states, and a 2-of-3 governor with per-domain nonces and a timelock.
The gap
The first public-chain applications settled trading. A trading venue is one market, one order book, and a small number of large participants. A payments network is many currencies, many tenants, many small flows, and a regulatory boundary around every corridor. The design that suits a venue — one global state, one approval surface, one execution queue — becomes contention and coupling when applied to consumer payments. A design optimised for a venue is not a design for a utility.
The gap is architectural. A consumer account needs authority that can be delegated narrowly and revoked. A transfer needs exactly-once semantics and a terminal state. A currency needs its own issuance and risk controls. A market needs independent liquidity. A corridor needs to fail without stopping the rest. Each is a boundary. A single-ledger, account-and-approval design cannot express those boundaries without rebuilding them off-chain.
The primitives existed; the composition did not. R-Cash is the case study for the alternative: a permissionless multi-currency account and cross-border payments network on Rholo. The loop is hold, receive, convert, pay, get paid. Liquidity providers, not correspondent banks, earn the FX spread. The aim is narrower than a bank and larger than an app: a direct, non-custodial balance in the user’s own currency, and a settlement layer other businesses can depend on. Invoicing, payroll, logistics, accounting, and letters of credit live in other repositories. R-Cash is the base layer.
The product
The product is an account with a payment rail attached, not a wallet with a swap button.
- Account. Each key controls its own ERTP purses. Transfers are owner-gated operations recorded against an
opIdledger. There is no globalapproveortransferFromsurface. - FX mesh. Every market is an FxPool with a LiquidityLock. Pairs are direct; there is no router and no mandatory USD hop. Pricing is oracle-anchored with spread and skew. Liquidity providers earn the spread.
- Payment. TransferBook and TransferContract measure the send, carry a memo and
opId, and support claim, expiry, and refund, with exactly one terminal state. Claim links reach a recipient who does not yet have a wallet. - Boundary. R-Cash is the on-chain payments core of a Wise-shaped product. Fiat ramps, cards, custody, and the surrounding business software are off-chain or in other repositories.
The account is the unit of authority; the pool is the unit of liquidity; the transfer is the unit of settlement. Those three boundaries let the system grow by addition rather than by re-architecture.
Architecture
Each cluster owns one kind of state and exposes capabilities rather than an admin API.
- Per-currency issuer cluster. Stablecoin, CollateralCustody, RiskParameters, VaultBook, LiquidationEngine, SurplusBuffer, SavingsPool, and PegStabilityModule deploy in one signed transaction, because mint, burn, and settlement capabilities cannot cross a deploy boundary. Collateral is native REV: no wrapped token, bridge, or redemption queue.
- FX market cluster. FxPool and LiquidityLock per market: oracle-anchored pricing, LP tokens, spread and skew, and a one-shot seed lock.
- OracleHub. Three allowlisted reporters, median, freshness and spread checks, and a signed policy.
- Transfer lane. TransferBook and TransferContract: measured send, memo and
opId, claim, expiry, refund, and one terminal state. - Root and governance. Registries, directories, and ListingViews; a 2-of-3 secp256k1 governor with per-domain nonces and a 100-block timelock. Emergency pause and market status are immediate.
- Platform fit. Deploys are atomic with rollback. The deploy term is capped at 65,536 bytes, parser depth at 128, and a deploy lives for 50 blocks; the contracts are sized to those limits.
Composition protocols P1–P6 specify how the clusters interact, so a failed conversion does not strand a transfer and a paused market does not pause a currency.
Why the calculus matters here
The calculus matters because the product needs its properties, not because formalism is a virtue in itself. Each row is a payment requirement first and a language property second.
| Requirement | Rholo and Rholang supply | R-Cash uses it for |
|---|---|---|
| Authority | Unforgeable new names; bundles as read/write facets; forwarders and revocation; no ambient authority. | Owner-gated purses; per-domain governor authority; mint and settlement capabilities that cannot cross a deploy boundary. |
| Exactly-once payment | Linear-cell discipline; one-shot consumption; capability-provenance rules C1–C3. | Transfer claim and refund; one terminal state; no double claim. |
| Collateral and solvency | Compositional state; capability-scoped mint and burn; conservation checked over the model. | Issuer cluster deployed atomically; vault, liquidation, and surplus buffer composed per currency. |
| Failure atomicity | Atomic deploys with rollback; concurrent composition. | A conversion or claim either completes or leaves no partial state. |
| Concurrency and scale | Process composition; shard routing and cross-shard invocation; no global execution queue. | One currency or market per cluster; capacity added per market, not by serialising every payment. |
| Verification | Lean transition relation and arithmetic; TLA+ models; tests. | S1–S12 invariants, five TLA+ models, and an axiom audit; traceability plus tests link model to code. |
The calculus record and its formal checks are linked in Section 6.
SaaS-shaped operations
A payments product is operated like SaaS even when it is not sold like SaaS. The same list applies to any dapp that grows from a single action into an offering: accounts, idempotency, request objects, metadata, delegation, change control, isolation, and workflows that outlive a block. R-Cash makes those operations first-class contract boundaries.
| SaaS operation | Mechanism in R-Cash | Contract boundary |
|---|---|---|
| Accounts and entitlements | Per-key account; owner-gated purses; capability facets. | A tenant receives authority, not a row in an admin database. |
| Idempotency | opId ledger; one terminal state per transfer. | A retry does not double-pay. |
| Payment requests | TransferContract with memo, claim, expiry, refund. | A claim link is a capability, not a hosted checkout session. |
| Wallet-less recipient | Native-REV stipend in the same deploy as the transfer. | A recipient can claim without holding gas. |
| Delegation | Bundles, forwarders, and revocation. | An operator acts through a narrow facet, not the user’s key. |
| Change control | 2-of-3 governor, per-domain nonces, 100-block timelock; immediate pause. | Parameter changes are delayed; safety stops are not. |
| Tenant isolation | Per-currency and per-market clusters on a shardable node. | One market’s congestion does not serialise every payment. |
| Long-running workflows | Claims with expiry and refund; contract state persists across deploys. | A payment can outlive a block without ambiguous state. |
| Settlement record | Registries, directories, and ListingViews. | On-chain balances and transfer states are queryable without an off-chain ledger. |
None of these is payments-specific. They are the operations a dapp needs when it grows from a single action into an offering; R-Cash is an early worked example.
Evidence and provenance
R-Cash is built on Rholo and written in Rholang. The code through d5d613b was Apache-2.0; the repository is now AGPL-3.0-only, and the earlier grants are not revoked. One contributor wrote the contracts, tooling, specification, and models.
The specification is 929 lines: v0.5, dated 27 October 2026, with 221 requirement rows, 206 MUST rows, and 19 areas. The component catalogue holds 40 components. The calculus record defines 8 laws (L1–L8), 7 non-laws (N1–N7), 18 safety rules (S1–S18), 8 well-formedness rules (WF1–WF8), 6 composition protocols (P1–P6), and 3 capability-provenance rules (C1–C3).
The formal chain has three links. Lean 4 project rholphin, without Mathlib, models the transition relation, arithmetic, and linear-cell discipline; it proves S1–S12 and rejects six linear-cell defect shapes (D1–D6). Its axiom audit rejects sorry, admit, native_decide, and project-local axioms. Five TLA+ models — CellLinearity, TransferExclusivity, PoolConservation, CapabilityProvenance, and AdminNonce — are checked with TLC over deliberately small bounded domains. tools/check_captures.py rejects capabilities in replies, stored maps, bundles, and attestations.
| Measure | Value | Source |
|---|---|---|
| Behavioural suites | 13/13 plus CLI demo, fixed-node devnet, 27 October 2026 | Testing record |
| Specification | 929 lines; 221 requirements, 206 MUST, 19 areas | docs/SPEC.md |
| Components | 40 catalogued | Component catalogue |
| Calculus record | L1–L8, N1–N7, S1–S18, WF1–WF8, P1–P6, C1–C3 | docs/spec/00-CALCULUS.md |
| Lean 4 | S1–S12; rejects D1–D6; axiom audit | spec/lean |
| TLA+ | 5 models; TLC over bounded domains | spec/tla |
| Capture checks | Replies, stored maps, bundles, attestations | tools/check_captures.py |
Sources: repository, specification, and models, as of 3 November 2026. The 13/13 result is the recorded fixed-node devnet run on 27 October 2026; the mesh and external-asset suites were added later and are not part of that count. Counts drift; the linked artifact is authoritative.
Limits
- Maturity. v0.5, devnet-only prototype. No fiat custody or real value on chain, no external audit, no mainnet; Rholo is pre-testnet.
- Oracle committee. Three allowlisted reporters, median and freshness checks. Two compromised reporters can produce a wrong price; the design reduces that risk but does not remove it.
- Collateral. Native REV only. Volatility can create bad debt; the surplus buffer is the only backstop.
- Ramps. Fiat on- and off-ramps are off-chain and unbonded. R-Cash does not custody fiat and cannot enforce an off-chain leg.
- Claim secrets. A claim is bearer authority. Whoever holds the secret can claim it; there is no identity check.
- Scale. Horizontal scale-out is inherited from Rholo’s design, not a benchmark result for R-Cash. The public testnet was rebuilt on 29 October 2026; the 28 October campaign was blocked by operator resource admission and a full campaign has not been re-run.
- Verification boundary. Lean models the transition relation, arithmetic, and linear-cell discipline. It does not formalise Rholang syntax, the node scheduler, or phlo; the link to deployed code is traceability plus tests, not extraction. The HAZOP of shared channels is a design review, not a proof.