Related work

Tally is not a new idea — it is the newest attempt at a twenty-year-old one. Peer-to-peer IOUs routed over a graph of trust limits have been designed, funded and shipped several times. Almost all of those attempts reached for a blockchain. Tally does not, and this page is where that choice is argued against the record.

The root: Ripple (2004)

Ryan Fugger's RipplePay is the origin of the whole family. Its claim: money is already just mutual credit between people who trust each other, so a payment to a stranger is a series of IOUs passed along a path of friends — exactly the model in Purpose. It is an ordinary GPL-licensed web server with one shared database — still running, renamed Rumplepay in 2020 — and never grew a user base large enough for routing to matter. Everything below is a descendants and variations of the idea.

Open, decentralised descendants

Trustlines Network

The most complete engineering of Tally's exact model, and the most useful one to read. Credit lines live in a CurrencyNetwork smart contract — one per denomination — which stores, for every pair, two directional credit limits plus a signed balance. That is Tally's trust limit and tally, in public contract storage. A multi-hop payment is a single on-chain transaction that walks the path and moves every intermediate balance at once, so atomicity is free. Users are identity contracts, letting a delegate pay gas on their behalf (meta-transactions), and an off-chain relay server indexes the chain into a cached graph and runs Dijkstra over it to find paths.

Trustlines built its own Proof-of-Stake Ethereum sidechain (TLBC, live November 2019), then sunset it in December 2022 and moved the protocol to Gnosis Chain, having concluded that running a validator set was not worth it. The protocol repositories have had no commits since then, and the documentation, developer and blog domains no longer resolve.

The lesson Tally takes: on-chain state buys atomic multi-hop routing and a graph you can actually search — and costs you a fully public trust graph, gas per payment, a token, and validators to maintain. The graph being public is not a side effect; it is what makes the pathfinding possible.

Circles

Live on Gnosis Chain and actively developed — the only project in this space with current momentum. Issuance differs fundamentally: instead of bilateral credit, every person continuously mints their own personal token (a UBI), and a trust graph decides whose tokens you will accept. Paying a stranger means swapping along a transitive chain of trusted currencies until you hold one the recipient accepts — the same routing problem as a routed payment, reached from the opposite direction. Worth watching for its pathfinder and its group currencies, not for its money model.

fiatjaf/trustlines

A short protocol sketch, notable because it takes Tally's constraint seriously: mutual credit with no chain to write to. It moves value with conditional IOUs (PREPARE / OK, borrowed from Interledger) and uses Bitcoin block heights purely as an uncensorable clock for timeouts — never publishing a transaction, never paying a fee. Unfinished, but it is the closest published thinking to the commit problem Tally has to solve, and comes from the author of Nostr, whose keys Tally already uses.

Holochain mutual credit

Agent-centric rather than chain-centric: each participant keeps their own hash chain, and a transaction is an entry countersigned by both parties and committed to both chains. There is no global ledger and no consensus — validity is local and checkable. Architecturally this is the closest relative to Tally's ledger and authorship proofs, and the best prior art for "how do you validate without consensus". Still largely experimental.

Credit Commons, CES and Community Forge

The non-blockchain branch, and the one with real users. The Credit Commons Protocol nests independent community ledgers into federations that clear against each other in any agreed unit, with no central issuer. Its GPL reference implementation runs the Community Exchange System and Community Forge — on the order of twenty thousand accounts, with inter-network clearing operating since 2011. Trust is organisational (you trust the group's bookkeeping) rather than personal, so it scales differently from Tally, but it demonstrates the point that the blockchain layer was never the hard part.

Adjacent: Interledger and Lightning

Not IOU systems, but they solved the two problems Tally has left open. Interledger (ILP) moves value across a chain of independent, mutually-trusting hops using prepare/fulfil/reject packets; Lightning does the same over payment channels, with onion-routed paths so no intermediary learns the full route. Both are the literature to read before designing routed payments — see TIPs.

Centralised and closed systems

Sikoba is the near-twin of Tally's feature list — credit lines, credit conversion through intermediaries (where you keep exposure only to the person you chose to trust), and clearing of circular debts, which is Tally's circular cancellation under another name. Despite the blockchain branding it is a conventional server product: Crystal and PostgreSQL behind a REST API, with a permissioned validator set (Babble) and Ethereum only ever proposed as a notary. It is closed source, its 2017 token sale underdelivered, the 2020 beta and the Luxembourg e-Beki pilot did not lead anywhere visible, and the app host no longer resolves. Its "clearing nodes" design only works because one operator sees the whole graph — the design Tally's privacy model rules out.

Cyclos is the mature commercial engine for LETS, timebanks and barter circuits — hundreds of live deployments, each a hosted database. Grassroots Economics (Sarafu, Kenya) is open and on-chain but issues pooled community vouchers, not bilateral IOUs, and is the strongest evidence in the field that field deployment matters more than the ledger technology. Splitwise, Tricount and Settle Up are the ones people actually use: bilateral tallies with good UX and no transferability at all. They are Tally's competition for the first screen, not for the protocol.

Where Tally differs

No chain at all. Not a private chain, not a sidechain, not an L2 — no shared ledger of any kind. Every record lives in the two (or few) devices it concerns, as an append-only ledger of signed durable records exchanged over WebRTC. There is no gas, no token, no validator set, no indexer, no global graph to publish, and nothing to keep running once two people have the app. Every project above except the Credit Commons family needed infrastructure that someone had to fund indefinitely; most of them stopped when that funding did.

A transaction is just a signed promise. On Trustlines a credit line is an on-chain object that both parties must open before value can move; on XRPL and Stellar the receiver must explicitly create a trustline before they can be paid at all. In Tally the record is the promise: an IOU is a Schnorr-signed statement that stands on its own and is simply appended to both ledgers. The trust limit is a number you keep about someone else — headroom for deciding what you are willing to accept, and later for routing — not a precondition either side has to accept before the first payment. Nothing has to be created, funded or activated first, which is why onboarding a friend is a QR code and no transaction.

Privacy is bilateral by construction. Sync only ever offers a peer the slice of the ledger that is between the two of you; third-party entries are never forwarded (see Ledger spec and Security). Trustlines' entire trust graph is readable by anyone with an RPC endpoint. This is the sharpest difference in the family, and the source of the open problems below.

Open problems this lineage leaves us

Routed payments are not implemented, and the two obstacles are exactly the ones every project above had to answer:

• Routing without a global graph. Trustlines and Circles run a shortest-path search over a graph the chain publishes for them. Tally has no such graph and does not want one, so a route has to be discovered by asking friends — probing, gossip, or source-routing over a locally-known neighbourhood, as Lightning does.
• The decentralised commit problem. A routed payment must be all-or-nothing: no intermediary may end up having paid out without being paid in. On-chain systems get this from a single transaction. Without consensus it needs either a signature from every participant before any leg counts, or conditional IOUs with timeouts in the ILP/HTLC style.

Both belong in a TIP before any code, alongside TIP-002, which solves the easier neighbouring problem of unwinding a loop that already exists.

Links

• Trustlines — contracts, relay, docs mirror
• Circles — circles-contracts-v2, v2 announcement
• fiatjaf/trustlines
• Holochain on mutual credit
• Credit Commons Protocol, CES
• Sikoba — technology, FAQ
• Cyclos, Open Credit Network