Support off-chain micropayments

Current fee payment systems in rollups have deviated from how L1s traditionally operated with the user setting and paying for the gas for that service. RAAS (Rollup-as-a-service) providers instead have monthly subscriptions that the developers are responsible for paying not the actual users of the service themselves. RAAS appears as a temporary solution for what is still an immature framework. It is quasi-monolithic in design, doing everything but the DA itself. Thus it’s not as robust as a fully trust minimised modular system.

Base rollups could be considered the closest frameworks to what we’re looking for but it’s inefficient to require the entire network to execute pay for blob transactions for just 250 bytes of data (a typical transaction size). Right now, 250 bytes would require 2,000 gas, but there’s also another 70,000 gas in overhead (signature verification etc.). It becomes cheaper if Celestia supports permissionless batching (or sequencing). But how do these payment systems look like. Celestia has an opportunity to dictate these systems by supporting some form of off-chain micropayments whereby Celestia (and TIA) is used to settle (and I mean the financial term) small, out of band payments for services such as: sequencing, batching, proving, executing etc… allowing for a plethora of permissionless systems.

I propose a new sdk module that supports the following flow. For the example I am talking about an interaction with a rollup user, say for an orderbook, and an aggregator that batches and submits blobs on Celestia.

  1. Rollup user initiates a cheque account with the aggregator whereby the user decides a value to be locked up. In this example we pick a value of 10 TIA. It could have on chain state that looks as follows (naive solution):

    type State struct {
        owner sdk.AccAddress
        recipient sdk.AccAddress
        lockedUp uint64
        nonce uint32
  2. Rollup user submits a trade transaction to the aggregator to be published on Celestia. As well as the data itself, the submitter includes a cheque. This is a signed over message for the amount to submit the transaction, perhaps 100 utia (a really small amount). Note in this example, the transaction is prepaid. If it were to be postpaid the rollup user would provide the cheque only after they had proved inclusion of the blob.

  3. As well as validating the rest, the aggregator searches for a cheque account under the users address and their address, checks that the locked amount is sufficient and accepts the payment.

  4. The next time the rollup user submits a trade, they append to the previous value. If they wanted to pay 50 utia, then they would sign over 150 utia.

  5. When it makes sense, the aggregator can cash in the cheque. They will receive the funds from the locked account. They can continue to use it and accept messages so long as they see sufficient funds locked.

  6. If the user wants to withdraw the funds from their locked account, similar to staking, they wait three weeks. In that time, if there is outstanding cheques, it’s up to the creditor to redeem them.

The example here uses the term “aggregator” but theoretically any service provider building with Celestia could be used. A RAAS provider could offer a contract whereby the users pay (instead of developers) for both the inclusion, the sequencing and the execution all together.

I haven’t spent much time yet in the solution space but I have a hunch that this could be combined with the existing staking component to have less on-chain state.


Great post. I have long thought that some kind of native support for tx aggregation on Celestia would be a cool feature to enable based rollups at scale but wasn’t sure how one could implement it. This seems like a viable route.

Question: would it be possible to implement something like this using zk accounts when they are live? Or does this need to be natively integrated into the state machine for some reason?

1 Like

Based on my limited understanding I think it would be feasible with zk accounts (a rollup could be viewed as an off-chain payments system which could be eventually settled on Celestia) but my instinct is that it will always be far more costly to prove than verifying a signature (for when the service provider cashes in their cheque). In addition, I think were still quite far off from working, battle tested zk accounts.


Good point re-cheaper to verify sigs than a proof + the cost of proof generation. Though perhaps at sufficient scale the tradeoff of batching all these signatures into a single proof would make sense.

Also good point that zk accounts is further off and more difficult to implement than the proposal above. Though maybe it’s worth waiting depending on how urgent the user need is and the tradeoff of how much this would add to the state machine complexity and state at the L1.

1 Like

Great post! This cheque account reminds me of one aspect of Vryx.

Each user bonds the gas in your case cheque to be able to spend it on transactions. This works using Account Fraud Proofs. In Vryxs design, the user cannot withdraw the bond.

"as builders rely on the locked nature of these funds (and a delayed view of them during replication) to justify their inclusion of transactions before they know they will be compensated for such work. "

TL;DR You can include transactions without having to execute them.

A similar approach could be taken by bonding some funds to a namespace and validators claiming the fees later but including blobs into the namespace in some serialized way.

Maybe this can be done for ALL blob submissions so we can always include transactions without executing them.

Why this approach might be flawed is that it might not align incentives with the protocol. The most logical thing a user can do should be to submit it through the protocol. If the user relies on off-chain payments we created a market for off-chain agreements, which could mess with the fee market itself.


But the denomination remains in TIA which should hold incentive alignment. I think it only becomes problematic if these off-chain payments are in other denominations.

Probably but if we’re talking about 2000 gas for a 250 byte transaction which is 100 utia at a 0.02 gas price, it could take 1000’s of transactions by a single user before it justifies the proving costs and execution costs to settle those payments (i.e. have the service provider actually compensated for the service they have provided that user). As I mentioned above, it’s still unclear to me about how zk accounts plays out and while I’m hopeful I am wary of people treating this as a magic bullet.

Yeah there’s an element of waiting to see how builders choose to configure their networks and systems on top of Celestia but I think there’s also a good element of leading the design space such that we can converge on optimal designs sooner. Having such a large potential solution space is often more damming for users who get overwhelmed with all these options and the various tradeoffs that come with each.


Locking funds in a cheque account sounds functionally equivalent to a user bridging funds to a sequencer.

1 Like

Yes, thinking about supporting sequencers was largely the genesis of the idea. There are however distinctions:

  • This way means your assets don’t have to be under custody of the sequencer which is likely not as secure as the DA layer.
  • The locked funds can be staked meaning that they still are revenue generating (whereas funds locked in a bridge are not)

An alternative could be to make PFB transactions as cheap/efficient as possible. This includes reducing the required transactions bytes, improving how much state access you need to access and therefore reducing the resulting amount of gas needed. Looking at this graph there could be improvements made in the sdk before introducing another accounting system.

In my opinion, we are comparing magic numbers to magic numbers, and the gas calculation has to be overhauled anyway, as currently, the numbers are based on vibes or tests by Dev from a couple of years ago.

There will always be an overhead of posting just one share, which can be amortized across bigger blobs. But there could be a blob size that will be too large for the network and should be disincentivized. Maybe HUGE blobs could subsidize smaller blobs. And the most optimal PFB cost per byte cost would be the one that we want the most of in the network. Who would post HUGE blobs anyway? L2s that want to save on settlement costs on Ethereum, which might be magnitudes bigger than the increased cost that they would have to pay for bigger blobs.

I agree with this direction and I do think that much of the gas calculation are estimated numbers (In your graph, signature verification is only 1.5% of the gas). A lot of it doesn’t take into consideration caching, nor the fact that some transactions can be validated 3 or more times (CheckTx, ReCheckTx, PrepareProposal, DeliverTx) which we could reduce the amount of state access on.

I think regardless of the improvements we make there, aggregating these micro payments off-chain is still going to be cheaper