O Coin has one job: to be money people actually use.
Not a store of value. Not a bet.
A transactional currency for every country, with its reference value tied to something universal: the local price of one liter of potable water.
The blockchain measures water prices and observed exchange rates. It then publishes the reference rate for each O currency.
Nobody is forced to follow it.
People, businesses and governments remain free to exchange O at another rate. But that choice has an economic consequence. When a currency moves away from its water-price reference, the protocol creates value for participants who continue to respect the stable rates.
Those who move away from the reference are not fined. Their coins are not confiscated. They simply enrich, through relative dilution, the people and currencies that remain aligned.
The offender's sanction becomes the reward of the offended.
That is the stabilization principle behind O. An incentive. Not an order.
We have started writing the code as an open-source Bitcoin Core fork. It expresses the intended flow: measurement, publication of reference rates, issuance, distribution and settlement.
It is still a prototype.
Several consensus and monetary paths must be completed and tested across independent nodes. And even after they are correct, the code in its current form cannot carry the volume required by a global transactional currency.
That is the challenge in this article.
To solve it, we first need to understand why Bitcoin was built slow on purpose.
Proof of Work Was a Security Decision
Bitcoin did not optimize for speed. It optimized for survival.
Rewind to 2009.
A new network. Few participants. Little computing power securing it. In that state, the system was vulnerable. Anyone able to control most of the mining power could attempt to rewrite recent history: the famous 51% attack.
Bitcoin needed more independent miners and nodes. More hash power. Wider distribution. A network that became harder to overpower as it grew.
Security could not be added later. Without it, there would be nothing worth scaling.
Satoshi also worried about denial-of-service attacks. A public monetary network has to assume that attackers will flood it, exploit it and look for every cheap way to make validation expensive. As the value secured by the network grows, the incentive to attack grows with it.
Proof of Work answers that threat with accumulated computational cost.
Each block references the previous one. Rewriting a confirmed transaction requires rebuilding the work after that point while the honest chain continues moving forward. If the attacker controls less hash power than the honest network, the probability of catching up falls rapidly with every additional confirmation.
- One confirmation provides limited protection.
- More confirmations add more accumulated work.
- The honest chain keeps extending while the attacker tries to catch it.
- Finality is probabilistic, not instant.
The chain is sequential by design.
Performance was the trade-off. In 2009, nobody knew whether Bitcoin would attract ten users, ten thousand or hundreds of millions. Choosing security first was rational.
It worked.
But O is designed for a different use case: daily transactions at global scale.
The Real Technical Constraints
The famous Bitcoin parameters are not arbitrary.
Propagation time
When a miner finds a block, that block must travel across the network. Other miners need to receive and validate it before building the next block.
If blocks arrive too quickly, competing blocks appear before the network converges on one tip. One branch eventually loses. Its work is discarded.
Frequent competing blocks create several problems:
- wasted mining work;
- more reorganizations;
- weaker effective security;
- an advantage for large miners with faster private connections;
- pressure toward centralization.
Bitcoin's ten-minute target leaves a wide margin between global propagation time and the next expected block.
Block size
Larger blocks carry more transactions, but every full node must download, validate and store them.
The trade-off is direct:
- larger blocks require more bandwidth;
- more transactions require more CPU;
- a larger chain requires more storage;
- a larger active state requires more memory and faster databases;
- higher hardware costs reduce the number of people who can validate independently.
A payment system can always gain throughput by buying larger machines and concentrating validation in a few data centers.
That is not the difficult part.
The difficult part is gaining throughput without turning an open network into a private database operated by a small group.
Bitcoin's base layer therefore processes only a handful of transactions per second. That is not enough for O, but simply shortening the block interval or multiplying block size would exchange one problem for another.
O should not make Layer 1 carry every cup of coffee.
How Big Is the Target?
A global transactional currency must handle more than yearly averages.
Paydays, holidays, emergencies and large public distributions create peaks. Capacity also needs room for growth.
Today's global payment system already processes enormous volume:
- more than a trillion non-cash transactions per year;
- hundreds of billions of transactions across the largest card networks;
- cash transactions that are still outside those digital totals;
- cross-border payments that pass through several intermediaries;
- future digital payments from populations still poorly served today.
At trillion-transaction scale, the average alone reaches tens of thousands of transactions per second. Peak demand is higher.
O also has its own requirements:
- daily payments in every participating country;
- many O currencies inside the same wallet;
- atomic conversion between currencies;
- distributions to very large recipient sets;
- low-cost access from mobile devices;
- capacity for future growth.
Hundreds of thousands of transactions per second, potentially approaching one million at peak, should be treated as an engineering headroom target, not as a performance claim.
We have not demonstrated that capacity.
The point is the size of the gap.
Bitcoin Layer 1 is measured in single-digit transactions per second. O's long-term target may be five or six orders of magnitude higher. No safe change to block time or block size closes that gap alone.
The architecture needs another layer.
The Architecture Chosen for O
The solution is not 142 independent blockchains.
That would divide security, operations and liquidity. A payment from O_EUR to O_USD would become a bridge operation between two networks, with two finality rules and two places where the transaction could fail.
O instead needs one canonical settlement layer and one shared payment state.
Layer 1: security, monetary policy and final settlement
Layer 1 remains conservative.
It records the rules and events that must be globally agreed:
- currency definitions;
- water-price and exchange-rate measurements;
- reference rates;
- authorized issuance and distributions;
- deposits and withdrawals;
- identity-provider commitments;
- payment-layer state commitments.
O's monetary policy is intentionally slower than retail payments. Water-price averages, exchange-rate observations and stabilization decisions do not need to change several times per second.
They need to be reproducible and secure.
Layer 2: shared multi-currency payment execution
Retail payments happen in a separate, account-based payment state.
Transactions are ordered in batches. Independent nodes replay the same bytes and calculate the same resulting state. Batch commitments settle periodically to Layer 1.
One shared state matters because O is multi-currency by design.
A wallet may hold O_USD, O_EUR, O_JPY and many others. A customer may pay in one currency while a merchant receives another. The debit, conversion and credit must happen as one operation.
Either every leg succeeds, or none does.
Atomic FX is not an optional feature for O. It is part of being a global transactional currency.
A shared execution domain can perform that operation in one state transition. Separate chains or separate currency channels would add bridges, routing failures and fragmented liquidity.
Payment channels remain useful
Lightning-style channels are proven tools from Bitcoin's lineage. They can work well for repeated payments, private bilateral activity and specialized high-frequency routes.
But channels require liquidity management. Recipients need inbound capacity. Users may need monitoring or watchtower services. Applying that model as the only payment network across every O currency would make global access and large distributions harder.
Channels can sit on top later.
They are not the foundation.
Trust must be stated honestly
The first payment-layer prototype may use one sequencer. A later version may use a committee.
That is acceptable for testing without real value, but a committee signature alone does not prove that every state transition is valid. Production requires stronger enforcement: complete fraud proofs or validity proofs, enforceable withdrawals, and a real data-availability design.
The project should earn each security claim with code and tests.
Correctness Comes Before Throughput
A fast system that disagrees with itself is not a payment system.
Before optimizing for global volume, O must prove that independent nodes reach the same monetary result.
That work includes:
- deterministic stabilization decisions;
- fixed-point arithmetic instead of consensus-critical floating point;
- durable monetary state that survives restart;
- correct rollback during chain reorganizations;
- a real multi-currency asset representation;
- canonical transaction hashes that include every currency amount;
- conservation tests for each currency;
- adversarial multi-node testing.
This does not change the stabilization philosophy.
The blockchain still publishes the reference rate. Participants still choose whether to follow it. The protocol still rewards alignment rather than imposing a price by force.
The implementation must simply ensure that every honest node measures the same deviation, authorizes the same incentive and records the same result.
Only then does high throughput become meaningful.
Not Impossible — Just Unfinished
O's scaling problem is real.
So is the work required before scaling.
The economic idea is defined: use transparent reference rates and incentives so that moving away from stability transfers relative value toward those who preserve it.
The engineering path is also becoming clear:
- make Layer 1 monetary logic deterministic and reorganizable;
- finish the multi-currency settlement representation;
- build a shared deterministic payment executor;
- add atomic FX;
- publish and replay batch data;
- prove withdrawals and state transitions;
- benchmark the complete system under realistic failures;
- partition execution only when measurements show it is necessary.
No marketing TPS.
No claim that a prototype already carries the world.
A direction. A codebase. A list of hard problems that can be tested one by one.
If you work on consensus, payment layers, data availability, zero-knowledge proofs, foreign exchange, distributed systems or monetary simulations, challenge the design.
Clone the repository. Break the assumptions. Build a failing test. Propose a better rule.
That is why the project is open source.
The Numbers Behind This Article
- Bitcoin base-layer throughput: approximately 7 transactions per second, depending on transaction size and block composition (Bitcoin scalability literature; e.g. IACR ePrint 2019/416).
- Bitcoin block target: approximately 10 minutes, with difficulty adjusted to preserve that average under changing hash power (Bitcoin protocol).
- Global non-cash transactions: approximately 1.4 trillion in 2023, projected by Capgemini to reach about 3.5 trillion by 2029. At 1.4 trillion per year, the simple average is about 44,000 transactions per second.
- Visa: approximately 234 billion processed transactions in fiscal 2024, or about 639 million per day (Visa Fiscal 2024 reporting). Visa has cited capacity above 65,000 transaction messages per second.
- Capacity target: hundreds of thousands to roughly one million TPS is an exploratory peak/headroom target for O, not a measured result or a promise.
- Layer 2: throughput depends on transaction format, signatures, data availability, durable storage, hardware, network topology and failure model. O will publish those conditions with any future benchmark.
O International is a nonprofit (association loi 1901). Code is open-source (MIT) on GitHub. Nothing here is for sale — a research/social-good project. Learn more: https://o.international