Skip to main content

The Finance Computer

Financial software has learned to decide, to price and to authorise on its own. Delivery has not. Between "this payment should happen" and "this payment settled" there is still a step that quietly assumes somebody's wallet holds enough of the chain's native token.

CoRelayer is that step, made explicit and made buyable.

Where this sits​

Above the ledger, below everything that uses it. The chain settles; wallets and applications decide; in between, something has to get a signed transaction into a block and pay for the privilege. Today that job is done implicitly, by whoever happened to fund a wallet, and it fails in the way implicit jobs fail: silently, at the worst moment, with nobody owning it.

Making it a layer rather than an assumption means it can be priced (Relay Units), bought (a plan in USDC), measured (per-transaction latency) and verified (the relayer registry and the purchase rules are on chain).

Four directions, one problem​

Person to personA payment app where the recipient has never held the chain's native token, and the sender should not have to explain why they must.
Person to machinePaying a metered service — an API, a model, a device — where the charge is small and a separate gas balance would cost more than the charge.
Machine to personPayouts, refunds and settlements issued by software on a schedule, which must not stop because an operational wallet ran dry overnight.
Machine to machineTwo agents settling continuously. Neither has a human to top up a balance, and neither should hold the other's token.

The last one is where the gap is widest, and it is the one that grows fastest.

Why autonomous software cannot operate a gas balance​

Not because it is technically impossible. Because it is operationally unreasonable:

  • A gas balance is an operational account. It needs monitoring, alerting and someone on call.
  • Autonomous software cannot open an exchange account to buy the native token.
  • The amount needed moves with the token price, so a fixed float is either wasteful or fragile.
  • A fleet of agents multiplies the problem by the number of keys.
  • A balance held for gas is a balance exposed to key compromise for no revenue.
  • Accounting cannot allocate a shared gas wallet to individual actions.
  • Treasury policy rarely allows a volatile asset to sit in a hot operational key.
  • A stopped agent is discovered late, because "out of gas" looks exactly like "nothing to do".

A monthly USDC plan replaces every one of those with a line item.

Why a fleet, and not one sponsoring wallet​

Two reasons, and both are structural rather than a matter of scale.

Shards. The fee payer of a relayed transaction has to be in the sender's shard. One wallet cannot serve every sender; a set with coverage in each shard can. (Shards and routing)

Exposure. Every transaction in flight reserves its worst-case fee against the relayer that will pay it. One wallet is one balance and one point of failure. Several per shard means a relayer can be drained without the shard stopping — and means a compromise costs the float of a few wallets rather than everything. (Relayers)

An operated fleet today, an open cooperative tomorrow​

Five phases, numbered 0 to 4, in order and without dates — a date we cannot keep is a claim we cannot support. They are the same five on co-relayer.com/finance-computer.

PhaseWhat it meansIt ends when
0. Foundation (current)An operated fleet in every shard, prices set in the contract, and plans an agent can buy on its own.Latency is measured and published for every shard.
1. Policy and fleetsSub-accounts per sender, value limits and usage Merkle proofs.Fleets can split one plan across teams with their own limits.
2. Latency classes and SLAsPublished objectives become contractual SLAs with credits, with more dedicated relayers in more regions.90 days of measured p50, p95 and p99 per class and shard exist.
3. Open cooperativeThird-party operators run relayers under the same on-chain rules and the same measured standards.At least three independent operators serve production traffic, and a governance document exists.
4. Beyond mainnetOne fleet per sovereign chain, gas stations that take payment on one chain and sponsor on MultiversX, and CoRelayer as the default relayer behind x402 facilitators and MCP servers.The sovereign-chain documentation is complete and the first sovereign customer runs on it.

The word cooperative in "Cooperative Relayer Infrastructure for Autonomous Transactions" is phase 3.

What makes phase 3 credible rather than aspirational is that the contract was built for it: relayers are registry entries with states, weights and an operator identity, and the rules they work under are in the contract, not in a spreadsheet. Nothing has to be redesigned to let somebody else run a relayer — only permitted.

What we do not do​

The boundary matters as much as the offer:

Not this
CustodyWe never hold your tokens and cannot move them.
A walletBring your own keys. We never see a private key of yours.
A bridge or an exchangeThe only swap in the system converts our revenue into the EGLD that pays fees.
A chainWe deliver transactions to MultiversX. We are not building a ledger.
Making an invalid transaction validEvery protocol rule still applies.
A settlement guaranteeWe deliver; the network decides. What we guarantee is that a failure to deliver is visible and never ambiguous.

Where to read the concrete version​

This page is the argument. The mechanism is documented, not sketched:

On this page