Skip to content
Jorvi
Blog

Approach

The settlement page explains how Jorvi works. This explains why it is shaped that way, including the parts that are a trade-off rather than a win.

Recurring payments assume a card on file

Section titled “Recurring payments assume a card on file”

A subscription works because the merchant holds a credential and pulls against it. The customer agrees once and stops thinking about it.

Self-custody removes the credential. The payer holds their own keys, so nothing can be pulled, and every renewal becomes a transfer someone has to remember to make. Subscriptions, payroll, usage billing and autonomous agents all run into the same missing piece: there is no default way to authorize a future payment without handing over control.

An allowance is the obvious answer, and it has a flaw

Section titled “An allowance is the obvious answer, and it has a flaw”

The usual solution is a token approval. The payer approves a spender for some total amount, and the spender draws against it over time.

It works. The flaw is in the shape of the authorization: the amount is a total, and it depletes.

That forces a choice nobody should have to make. Approve a small total and you are back to re-approving constantly, which is the friction you were trying to remove. Approve a large total so you can forget about it, and that entire amount is spendable in a single transaction. There is no per-period ceiling to stop it.

Most of the time nothing goes wrong. The problem is that the ceiling on what can go wrong is set by convenience rather than by intent.

A cap that resets

Section titled “A cap that resets”

Jorvi is built on Solana’s Subscriptions and Allowances program. The payer authorizes a per-period cap: up to a set amount per period, revocable at any time, with the terms set by the payer.

Three properties follow, and none of them are promises we make:

The ceiling is per period, not total. An over-charge is rejected on-chain. The worst case in any period is one period’s cap, no matter what any backend does.

Skipped periods do not accumulate. A dormant authorization does not build up into a large catch-up charge.

The limit is not enforced by us. It lives on-chain. A compromised Jorvi backend still cannot charge a payer more than they approved, because we are not the thing doing the enforcing.

That last point is the reason the architecture is worth the constraints it brings.

What it costs

Section titled “What it costs”

Every design gives something up. Ours gives up these:

A refund needs the merchant to still hold the funds. Because settlement goes straight to the merchant’s wallet and we hold no balance, there is nothing for us to reverse out of. A gateway that pools settlement can claw back from an account it controls; we cannot. Merchants who refund regularly should keep a working balance. This is the direct price of never taking custody, and it is the right trade for most, but it is a real one.

One chain today. The cap works with ordinary token accounts on Solana. Equivalent mechanisms on other chains exist but generally require a smart contract account, so coverage is narrower there. Extending is bounded work, since each chain sits behind one adapter, but Solana is where the primitive reaches the widest set of ordinary wallets.

A cap is a ceiling, not a blank cheque. If a charge legitimately needs to exceed what the payer authorized, it fails. That is the feature working, and it means the ceiling has to be set with real usage in mind.

Where this matters most

Section titled “Where this matters most”

For a person paying a fixed monthly subscription, a cap is a nice property.

When the spender is software, it stops being nice and becomes necessary. An autonomous agent holding a depleting total allowance is one bug, one bad instruction or one hijacked session away from spending all of it, in one transaction, with nothing in the way. A per-period cap bounds that by construction.

It is also the one case where the person setting the limit and the person choosing the tool are the same. That is why agent payments are where we are pointing this first.

Not a novel idea, and that is the point

Section titled “Not a novel idea, and that is the point”

We did not invent per-period authorization. Solana shipped it natively. Coinbase’s Spend Permissions enforce the same idea on Base. ERC-7715 is standardising it for EVM wallets.

Independent groups arriving at the same shape is the strongest signal available that it is the right one. We are not asking anyone to bet on an unproven mechanism. We are building the orchestration layer above one that is becoming standard: the scheduling, the retries, the refunds, the receipts, the webhooks and the developer experience, none of which the chain gives you.

Section titled “Related”