Lovely Little Gas Protocol & Finalized Staking v2

Lovely Little Gas Protocol

Gas Protocol and how it fits into Staking v2 for Manifold

Lovely Little Gas Protocol is an implementation of a game mechanism for meta transaction submissions. Our implementation follows the smart contract wallet (SCW) design pattern with support for out-of-order transaction submission and EIP 4337 ('Account Abstraction via Private Mempool). This design enables customizing the retrieval of the contract tokens, which, for the LovelyLittleGasProtocol, is done only through 3 functions:

  • Execute
  • Exhaust
  • Recoup

Note: This is why its called the Lovely Little Gas Protocol - the protocol is intended to be small and permissionless.

Additionally, this design enables decoupling the transaction issuer (i.e., the party that pays the transaction fees) from the transaction signer (the party that creates the transaction). This, in turn, enables having one party, Seller, use his gas allocation (or pay the transaction fees) to confirm a transaction by the other party Buyer, using so-called meta transactions

The implementation is compatible with EIP1559 since txPayload is a meta transaction, and the transaction by Seller that invokes Execute is the one that pays the required BASEFEE[1].

The protocol operates in three phases

Setup Phase

At the setup phase, the gas-purchasing user (the Buyer) sets the contract parameters, namely:

  • The target confirmation interval (Note, this is configured by us as to not exceed 2 epochs worth of slots)
  • The required gas.
  • Payment details.

Buyer also locks the payment upfront, and then the gas-selling block builder (the Seller) can accept the contract by depositing a collateral of his own. At this point, Buyer does not commit to a future transaction.

Target Execution Phase

At the target execution phase, Buyer publishes a (zero fee) transaction of his choice, which Seller can then confirm through a designated Execute function. LLGP verifies the provided transaction was indeed created by Buyer, and if it executes successfully, it sends the funds to Seller.

Operant Phase

But what happens if Buyer publish a transaction that exceeds the agreed-upon gas amount, or a transaction that fails, or maybe does not even publish a transaction at all? For that, there exists an alternative function, exhaust, that enables Seller to extract the funds without any cooperation from Buyer. However, to prevent Seller abusing this function, its invocation spends gas equal to the agreed-upon amount through repeated null operations. This construction results with the Execute function being preferred in case Buyer abides by the contract, while protecting Seller if not.


The Buyer also deposits the token payment for the future transaction confirmation. This token payment enables ‘gasless’ transactions, a way of paying for transactions that abstracts away the need for ETH by the end user (the Buyer in our example).

Take note, ETH is still used behind the scenes for ‘gasless’ transactions!

Following its initiation, the contract starts an acceptance block countdown, during which a Seller can accept it using a transaction. Additionally, accepting the contract requires Seller to deposit tokens as a collateral matching the collateral parameter. This is handled by the Staking Vault: Stakers of FOLD underwrite the risk of counterparty default and thereby earn fees from doing so. This risk-underwriting enables the system to process and handle capacity based off a measured net asset value of the total vault less 20%. The seller is marked as an authorized Relay address, enabling other relays to potentially put up collateral and participate in this system.

The collateral is ‘returned’ conditioned on Seller further interacting with the contract. Either if Seller accepted the contract, or if the acceptance countdown is completed, the contract accepts no further interactions until the exec phase. Returned means in our context ‘available unused vault balance’, meaning it is no longer counting towards the vault’s currently in use collateral.

Towards or even during the exec phase, Buyer can publish txPayload. This allows Seller to Execute it, executing txPayload, and getting the payment and collateral tokens from the contract. This is the main functionality of LovelyLittleGasProtocol – enabling Seller to execute a transaction provided by Buyer. Alternatively, Seller can exhaust the contract, consuming the hedged gas on null operations, and then receiving its tokens. The motivation for this functionality is to enable Seller to claim the tokens, regardless if Buyer provides a transaction or not; this protects Seller from a faulty or malicious Buyer. However, the naive solution of letting Seller report Buyer as faulty is not sufficient: It allows a Seller to falsely accuse a correct Buyer, getting the contract tokens without providing the confirmation service. By making Seller waste equivalent gas, we remove his incentive to do so. If Seller has not accepted the contract, then Buyer can recoup the contract tokens using a transaction.[2]


There are two primary interfaces to interact with, an end-user interface and a protocol interface. The protocol interface is described in the following post, with additional details including a new ethereum transaction type and information concerning the Gas Pricing Oracle for LLGP.

Staking V2

We can see that in this system, LLGP, that FOLD is used in a pro rata form to provide an incentive compatible mechanism for honest reporting from the Manifold Relay. Staked FOLD earns fees for all transactions using LLGP, furthermore, protocols can supply their token to provide for additional subsidy payments, etc. Staked FOLD primary risk is in operating an honest relay, so long as the relay operator is honest the collateral is not at risk of liquidation.


UI/UX Appeal for this system means that we eliminate the existing gas pricing controls, and replace them with two values: a ‘gas price’ and a ‘gas slippage%’ value. There is no ‘low, normal, fast’ verbs/controls, all transactions are priced to be included within the next < 8 blocks at most.

The Gas Pricing Oracle will provide a ‘network congestion ratio’ for mempool pending transactions as a way to provide back pressure information back to DApps and by extension their users.

This system does not require per se validators to participate directly. Those that are using the relay are already participating. However, having an enforcement mechanism (or lackthereof) provides counter-party risk, which is the reason for using FOLD for underwriting said risk.

Conditional Slashing Mechanisms like Eigenlayer would help enforce a greater and more expressive predicates w.r.t. additional functionality expanding beyond the user initiated transaction scope detailed here.

Citations (non exhaustive)

  1. Chung, Hao and Elaine Shi. “Foundations of Transaction Fee Mechanism Design.” ArXiv abs/2111.03151 (2021) ↩︎

  2. Liu, Yulin, Yuxuan Lu, Kartik Nayak, Fan Zhang, Luyao Zhang and Yinhong Zhao. “Empirical Analysis of EIP-1559: Transaction Fees, Waiting Times, and Consensus Security.” Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (2022) ↩︎


Join our Twitter Space on LLGP tomorrow and drop your questions here!

Very interesting…got some questions and related thoughts/suggestions below.

How much does your meta-transaction protocol deviate from the EIP-4337 spec, if at all?

Is Manifold going to run its own bundlers?

How do the block builder and “futures contract” buyer know how to settle on a forward price for gwei?

2 epochs - are there limits to how far out you can write these contracts? I suspect the further out you go, the more subject to gas market manipulation risk as well as uncertainty over how to price the contract?

does this design initially (or maybe forever) require some amount of permissioning on the part of both buyers and sellers? Or are there reasons why you think this is DDOS-resistant? Looks like the “exhaust” feature could at the very least prevent some forms of builder (aka “seller”) abuse

Could you structure this as a perp eventually + have free floating funding rates? For end users who may want to be perpetually hedged on gwei and don’t want to manage constantly rolling maturities for futures.

this is UserOperation and handleOps correct?

Feels like the gas oracle piece is critical here…eager to see what you land on there

So the FOLD token is going to function effectively like the MKR (maybe also NXM?) token as an “issuance backstop”? Key difference is staking vs. non-staking I guess

1 Like