Goal

Identify the problems with using a speculative project token for web3 project user actions. Use Arweave’s $AR token as an example.

Introduction

Enthusiasm for crypto projects drives speculative market activity for project tokens. If tokens are used to pay for project actions (i.e., payment tokens), then the price of project actions increases along with token value. In this way, token speculation levies an implicit cost on web3 product users—ultimately leading to self-enforced limits on product growth.

How should we solve this problem? Alternatives are unsatisfying and require real tradeoffs. The problem is admittedly complicated by the desire to build utility for project tokens.

Web3 user actions

Web3 products are open access and lack permissions. The interfaces are open and composable, and everyone is free to use them. The lack of permissions is a defining characteristic of web3, and sets it apart from its predecessor web2 technologies.

Openness brings many advantages, but leaves the product vulnerable to spam, which at scale can take the product offline making it unusable for everyone.

To prevent spam, users must pay per action or account.

Can I pay for web3 user actions with my credit card?

Web3 project designers choose how users pay for actions and accounts. Fiat currencies are not digitally native, and thus historically have not been viewed as a good choice for denominating web3 actions.

Instead, crypto projects mint digitally native tokens that can be used to pay for actions. We call these tokens, payment tokens.

The tokens in circulation are the monetary base of the project’s ecosystem, and the project effectively takes on the role of monetary authority, just like the U.S. Federal Reserve or the Monetary Authority of Singapore. This is not an easy job.

The big problem with payment tokens: volatility

Volatility represents the annualized standard deviation of returns of an asset relative to a base asset—typically $USD. Volatility represents uncertainty. A highly volatile payment token that is used for product actions introduces uncertainty for product users.

So, we want to minimize the volatility of payment tokens, or choose payment tokens that exhibit low volatility.

For example, the volatility of USD against a basket of major fiat currencies is 0.38%, which is much lower than the volatility of web3 payment tokens against USD:

Selecting a high volatility payment token leads to two unfortunate outcomes for web3 projects:

• Limits medium-to-long-term network adoption

• Uncertainty for developers and users

Limits medium-to-long-term network adoption

As well-intentioned as payment tokens are, the existence of payment tokens provides a way for people around the globe to speculate on web3 projects with minimal friction—tokens are simply data that can be updated at the speed of the internet 24 hours a day, seven days a week, all year long, currently without much regulation.

Speculation exists in all markets, and its existence is healthy for trading volumes (i.e., liquidity). And trading volume is required for the efficient discovery of asset price equilibrium.

But, speculation is one of the primary use cases in web3 to-date, and cycles of excessive speculation are a theme.

Excessive speculation isn’t a feature we want for payment tokens. We can see the impact of excessive market speculation on the Arweave payment token in the charts below.

Arweave is a network of data storage providers that are incentivized by the protocol to make hard disk space available to users.

Figure one:

In the last nine months, the cost to store a few GB of data on Arweave is consistently around 1 $AR.

Figure 2:

But, the price of $AR in comparison to $USD has increased substantially

Figure 3:

The token valuation may be justified, as Arweave usage has also increased

Figure 4:

But, the unsurprising result is concerning: As $AR/$USD rises, so does the cost of storage in $USD terms. When $AR was trading for ~$37 on March 14th, it cost end users ~$40 to store a GB of data.

AWS S3 storage is currently $0.023 per GB per month. The Arweave protocol is designed for users to pay once to store forever, but you would have to live another 145 years to make it economical to store a GB of data on Arweave over S3.

There are real guarantees offered by a decentralized network, like Arweave that AWS cannot offer. However, the economics are currently too imbalanced for decentralized crypto networks to win out over their web2 predecessors.

Internet service provider tokens - thought experiment

It isn’t hard to imagine other real world examples of payment token shortcomings. If a successful ISP launched a speculative project token for customer billing payments, the cost of the provider’s internet service would go up as speculators gobbled up the project tokens during good times. Service cost inflation would act as a self-enforced limitation on service growth, as customers would switch to competitor providers in direct proportion to the ISP’s own success.

Hmm, wouldn’t the price of the web3 service adjust downward in response to token/$USD increases?

We might expect prices to adjust down as the payment token appreciates against fiat. But this is not the case. In fact, prices tend to rise along with the token.

Uncertainty for developers and users

The second unfortunate outcome of payment token volatility is that it introduces uncertainty for product customers. Developers and users want to know their costs with some level of certainty. Anecdotally, in figure 4 above, we can see that $AR/$USD introduces a considerable amount of cost uncertainty. For those holding $USD on January 13th, a GB of data storage cost less than $10. Just two months later in March that same user holding $USD had to pay 4x more for the same GB of data storage.

Token infrastructure

Web3 payment tokens themselves require token infrastructure: if it is a non-native token it requires a contract on a settlement chain with high security guarantees, deep access to liquidity for swapping (onchain/offchain), secure bridging options, and consideration of applicable tax rules on token transfers.

Token infrastructure designs determine the level of friction placed on developers and users when swapping in/out of the project’s payment token for project use. If a project introduces a payment token without well-developed token infrastructure, unnecessary frictions will inevitably sap product growth.

Protocol infrastructure provider preferences

The majority of protocol infrastructure providers are professional operators that work across many open protocols. They are interested in earning project tokens from protocol rewards for their service. They also earn fee income from user payments for product actions. If both rewards and payments are denominated in project tokens, their income will be highly unpredictable. Provider income can be made more predictable by denominating user payment in a low volatility token.

Exchange rate risks

The majority of rollup chains are operated by project teams. These teams pay the operational costs of the rollup on behalf of users and developers. The biggest costs are consensus and data availability fees paid to the settlement chain and the data availability chain. The denomination of these costs may be different from the denomination of fees collected from user payments. This currency mismatch introduces uncertainty for operators—there can be no guarantee the amount of fees collected at user payment time will be sufficient to pay for rollup operating costs, as the relationship between the two different currencies is continuously changing.

Why do teams choose to use a payment token?

Early web3 projects, such as Arweave thought of their ecosystem as an independent economy with its own monetary system.

The main benefits of an independent monetary system are (1) monetary premium, and (2) token supply control.

Monetary premium

In finance, an asset is valued at a premium when it is trading above its intrinsic value. A monetary premium refers to money-like assets that are valued at a premium to their intrinsic value. Fiat money is a typical example—society swaps time, energy, and goods for fiat money, despite the money instrument not being redeemable for anything from the authority that issued it.

In web3, monetary premiums can drive token prices above their intrinsic value, which means project treasuries have more money to spend on the project.

But, there is a real cost for project development companies to build sufficient token liquidity necessary for monetary premium. Market makers (LPs and professional traders) need compensation to form and contribute to a liquid market. To start, this must be paid by the project in the form of incentives for DEX liquidity providers, contracts with professional traders, and contracts with CEX for token listing. Sustaining monetary premium requires the broader social layer to coordinate around the use of the token as the standard medium of exchange.

Supply control

Supply control means the team can mint payment tokens for developer integrations or users to make the service free for some period of time. However, token incentives for adoption are unsustainable, and likely bad monetary policy given the ruthlessness of token farmers.

All costs can be passed on to the end user, but the objective should be to remove frictions for users, not introduce more friction in order to support token values.

Web3 user action problems

There are many problems we must solve for web3 user action payments that are aside from the problems introduced by project payment tokens.

As web3 product designers, we should try to address these problems and simplify user experience in order to drive value to our products. We often do the opposite—favoring token utility designs that drive value to the token instead of the product.

Alternatives to project payment tokens

Designers that choose to use the project’s token as the payment token are stating: I can do better than available stablecoins and existing internet native currencies, such as $DAI and $ETH. This is ambitious, and detracts from other product priorities. Building internet native money standards that support—rather than hinder—product growth requires significant investment in both monetary policy and token infrastructure.

So, what options exist for web3 product designers?

Stablecoins

A low volatility asset like $USD (and other fiat currencies) stablecoins can be a good choice for payment tokens. Stablecoins, although not without risk, are the only tokens unaffected by web3 project speculation cycles.

This is the path chosen by Gnosis Chain, which uses bridged $DAI ($xDAI) as the chain’s payment token.

Stablecoin risks - intermediary risk and smart contract risk

Some stablecoins, like $USDT and $USDC require a trusted intermediary, which issues stablecoins for user collateral deposits. Stablecoin intermediaries invest the deposited user collateral in order to earn a yield on the deposits for themselves. All yield opportunities require risk. As in most financial intermediary cases, the users directly bear the full extent of the risk. The only risk insurance available to users would be on fiat collateral held in insured bank accounts, which is minimal.

Permissionless stablecoins, such as $DAI do not require a centralized intermediary. Instead, a smart contract protocol on Ethereum acts as a monetary authority issuing $DAI loans on collateral placed into smart contract vaults. A large portion of the collateral requires an intermediary, and some of these risks are transferred to $DAI holders.

Largely disintermediated stablecoins, like $DAI are also not without risk. Smart contract bugs can lead to a loss of collateral and an equivalent loss of value for the stablecoin.

Stablecoins are a good option for denominating user actions, since the monetary policy is set by global monetary authorities with demonstrated experience in maintaining price stability. Monetary policy is a globally researched problem, the history of which spans centuries. It needs constant debate and maintenance, as the primary goal of any monetary policy is to provide the appropriate level of liquidity to the evolving economy while keeping prices in check. Like many things in nature, economies are cyclical. Monetary policy must be constantly updated to follow the market’s nature.

Stablecoins also have strong token infrastructure and are widely used as a medium of exchange. However, intermediary risk and smart contract risk must be considered.

Designers that choose a stablecoin as the monetary base for their project are stating: global monetary authority policy setting is more sound than the monetary policies of existing internet native money or my own.

Use an existing internet native money standard

$ETH is becoming a likely social standard for internet native money. Ethereum has proved it can both curate world class research and deliver seamless upgrades. The Ethereum research community, shepherded by the Ethereum Foundation Robust Incentives Group has continually pushed the industry forward, leading to an incredible amount of value accrual in the ecosystem and the ubiquity of $ETH across blockchain ecosystems.

$ETH is a good choice for denominating user actions. This is especially true on rollup chains that settle to Ethereum—since the rollup costs are also denominated in $ETH. There is no disagreement that $ETH token infrastructure is the most well developed among internet native currencies, and it is widely used as a medium of exchange.

Designers that choose $ETH as the monetary base for their project are stating: Ethereum monetary policy is more sound than global monetary authorities or my own.

Conclusion

This blog delves into the intricacies of web3 user actions and the necessity of fees within permissionless web3 projects. By introducing digitally native payment tokens, web3 projects aim to streamline transactions and minimize reliance on traditional financial infrastructure. However, the adoption of speculative, high-volatility payment tokens poses challenges, such as limiting network adoption and fostering uncertainty among developers and users. Moreover, the burden of payment token volatility falls on infrastructure providers, developers, and users alike. Considering the significant investment of time and resources required to navigate these challenges, exploring alternatives like stablecoins or adopting existing internet-native money standards may offer more sustainable paths forward for product designers.

Objective

I’m interested in exploring the rollup design space--in particular the problems rollup operators are encountering. The goal of this blog post is to maintain an ongoing list of these problems, along with ideas for potential solutions.

Context

The rollup operator is the rollup sequencer, prover (if ZK), and full nodes, collectively. A single rollup can have multiple operators.

By design rollups outsource consensus to Ethereum. The rollup operator has no ability of its own to get consensus on the validity of updated chain state.

Rollups have operational costs. Some costs are fixed. Some costs are variable and scale along with tx volume. An example of a variable cost is consensus fees paid to Ethereum.

The operator collects fees from individual rollup user transactions, and uses the funds to pay for total operating costs.

Users can pay priority fees to get better service from the rollup.

Rollup operators cannot easily steal user funds. This, as well as competition, may lessen credible neutrality requirements.

Rollup operating costs

Fixed

• Server/infrastructure costs

• Salaries

Variable

• Transaction commitment costs

• Data availability costs

• Proof generation costs (if ZK rollup)

Problems

Timing mismatches

There is a timing mismatch between when the operator collects fees from individual user transactions and when the chain operator pays operation costs

Problem validation:

Rollup transaction fees are in part determined by estimating future prices of variable operating costs at transaction time. Estimated prices may be materially different than actual prices. Any divergence between actuals and estimates is a cost to the operator.

Potential solutions:

• Fee estimation

• Forward contracts on Ethereum blockspace

Currency mismatch

Operation cost denomination may be different from the denomination of fees collected from user transactions.

Problem validation:

If a currency mismatch exists between fees and operating costs, then there can be no guarantee the amount of fees collected at transaction time will be sufficient to pay for operating costs, as the relationship between two different currencies is continuously changing.

Spam

In order to remain credibly neutral, the rollup operator offers publicly available interfaces that do not require permissions. A public interface exposes the chain to potential DoS attacks.

Problem validation:

Without a permission policy, it is trivially easy for an attacker to flood the chain with garbage transactions that eventually overwhelm the full nodes. The network will become unusable. This can happen even with ill defined transaction fee mechanisms.

Solution:

This problem is solved by the chain’s transaction fee mechanism. Also, the sequencer can help filter out garbage transactions; although this is not necessary for the chain to function properly.

A single network transaction fee curve

All accounts transact on the same fee curve. Spam accounts live on the same fee curve as a casual user who is using DeFi products to manage their finances.

Problem validation:

In order to protect the chain from sybil attackers, we cannot distinguish between the variety of user profiles. Thus, blockchain transaction fee mechanisms ignore user willingness and propensity to pay. This may disadvantage casual users, and benefit professional users.

Potential solution:

https://github.com/trebor-yatska/sequencer-economics/tree/main

Note, real problems around sybil must be solved for outbox base fees to be viable.

Questions

• What cost premiums would rollup operators pay to know their costs at tx time?

• Can operational costs be better estimated at tx time?

• How detailed is rollup operator cost accounting?

  • What are the monthly and quarterly operational earnings of rollup operators?

• Do rollup operators need to charge at cost for every user tx?

• What information do sequencer’s know about the users that are sending txs to its endpoint?

  • They know IP address and wallet address of the user

• What transaction fee mechanism modifications would provide more user and developer benefit while maintaining the chain’s proper functioning and credibly neutrality?

In this blog, I attempt to untangle a simpler model for open protocol token economies. I do this by exploring the needs, stakeholders, objectives, and risks of open protocols.

What is an open protocol?

Using attributes to define an open protocol, we can say it has: (1) a roadmap that is ostensibly set by a community of developers; (2) developers that contribute code, tools, and applications without asking for permission; and, (3) a leadership team that is accountable to community stakeholders.

Examples of open protocols are Linux, Python, MLS, Ethereum, and ENS. Technically, Linux and Python are open source software standards; however, the coordination requirements are similar to open protocols.

Protocol needs

There are two fundamental needs of an open protocol:

• A way for stakeholders to efficiently set the roadmap (i.e., governance framework)

• Sustainable funding for completing the roadmap (e.g., a token, a business model, or charitable contributions)

Protocol stakeholders

In addition to core protocol developers, principal and agent protocol administrators, who have limited authorization from the community to perform authorized tasks, are necessary to fulfill the protocol roadmap.

• Principals: Protocol oversight leadership that is empowered by the community to select agents and propose high level financial decisions

• Agents: Protocol leaders that are empowered by their principals to make short-term and long-term operating decisions, including nurturing the developer core

• Core developers: The primary developers employed to build core products

Optional

• Top-of-funnel developers: A strong and growing developer ecosystem establishes protocol credibility and occasionally attracts core developers to the project

Principals, agents, and core developers are responsible for execution, while the community dictates roadmap and authorized task selection.

Protocol objectives

Above all, the protocol must deliver value for developers and users.

A protocol must also find sustainable funding for upgrades.

For blockchain protocols, the roadmap can be sustainably funded using a protocol-owned treasury that captures recurring revenue from real business models, such as spam fees, account abstraction bundler earnings, L2 rollup sequencer earnings, chain integration earnings, risk arbitrage, etc., as well as token investment earnings. This last bit makes obvious the need for the community to drive value to the protocol token. Thankfully, coordinating governance of the roadmap is crucial to protocol success, and tokens are a wonderful coordination tool.

Risk mitigation

The protocol must remain permissionless. Client applications will inevitably use the protocol to operate in a way that runs counter to various legal jurisdictions. In order to protect the protocol from unbearable regulatory burden, Miles Jennings at a16z provides a view on a protocol DAO structure that is capable of discarding protocol earnings sourced from client applications failing to follow their local laws. However, this would place a high operational burden on the DAO, and only time will tell if DAOs will achieve this level of sophistication.

Token economy

In web3, a protocol that helps developers solve real user problems should implement a strong business model. The business model allows the protocol to capture recurring revenue for the treasury. This satisfies one of the basic needs of the open protocol, the ability to fund the roadmap, without having to rely on external donors. This is novel for open protocols.

A protocol that is effectively capturing value requires skilled leaders to ensure the protocol can deliver more than an $ETH of value in the future from one $ETH of value captured today. This growth is demanded by the community, and good money and effort should be paid by the community to attract the best leadership possible.

An efficient coordination mechanism is needed for the community to elect protocol leadership. We should expect leader election to be contentious--there is a lot at stake. Protocol tokens are an excellent coordination tool, and in this case should be used to (1) incentivize the community to participate, and (2) represent eligibility to participate.

A starting place for protocol leadership elections using tokens is staked delegation. Community members delegate their vote to a protocol leader on the ballet by staking in the voting contract. Elections can be continuous, as they are in most DAOs today, or a vote can be held every six months.

Conclusion

Blockchain allows for open protocols to implement a business model that can capture enough value to sustain itself into the future. This is a novel feature of open protocols, and demands novel legislation and regulatory oversight. Tokens are a wonderful coordination tool, but fear of regulation has caused us to perform design backflips to ensure these coordination tools are seen as technology instead of shares in a business. This is a losing product strategy. As open protocol designers we should stop designing mechanisms for the sake of the token, and focus on solving problems for developers and users.

Parting thoughts

Growing protocol value is only one mandate for leadership. The open protocol exists to serve the community. Its value capture should be reinvested into the shared mission of the ecosystem. Leadership must be the best representation of the ecosystem’s shared mission and values. After all, a shared and enduring mission and value-set is the sole reason for the open protocol’s existence.

The incentives are misaligned. What are the consequences of this misalignment?

If we don’t demand truly open protocols, what will happen?

• Control of the protocol’s roadmap will reside with a few non-devs (i.e., colloquially known as the “devco”). The devco is likely a small compilation of c-suite BD, Product, and engineering managers, as well as the principal capital providers to whom the c-suite must deliver results

• Protocol users and developers must trust this small group not to save the protocol’s success for themselves

• Protocol users and developers must trust this small group with sensibly navigating the roadmap through difficult times

• Protocol users and developers must trust this small group with avoiding the temptation to gradually erode shared ecosystem welfare in pursuit of the devco’s welfare

Running counter to normal institutional behavior

• Corporate success has been found by aggregating power, influencing the rules of the game, and charging increasing rents. This is why many regulations exist—government is a sometimes effective check on power.

• Our expectations for the devco to build effective governance frameworks is a cognitive error, as giving up control runs counter to normal institutional behavior

Gradual decentralization of control - what we expect to happen

• In the early years, open protocols require centralized control and sufficient funding

• Funding can come from a variety of places—public good funding, private capital funding, etc

• Over time, open protocols are expected to drop their reliance on private funding and become self-sustaining

• Over time, open protocols are expected to develop a resilient and manageable political framework for power struggles to happen, and empower the community to swiftly resolve protocol leadership failures when they occur

Slippery slopes - what will happen

• The strong ethos of can’t be evil > don’t be evil will slowly erode, as exciting new sufficiently open protocols find PMF and demonstrate user onboarding

• Roadmaps become increasingly controlled by devco leadership

• Devco leadership will favor doing what’s best for their stakeholders—devco stakeholders are not protocol users and developers

• Inevitably, we are left with closed protocols that make roadmap decisions for the benefit of devco stakeholders instead of benefitting the developers and users that bootstrapped the protocol

How can we do better?

• Diversify funding across multiple funding categories, and avoid concentrations within categories

• Create an external oversight committee that can act as a credibly neutral check on devco leadership

• Work with legislators and regulators to craft minimally viable legislation that empowers a government agency with open protocol oversight

• Work closely with developers to understand their preferences for managing protocol roadmap, and build better frameworks from these preferences

Questions

• Given the incentives, can we reasonably expect a traditionally funded protocol to achieve openness?

• Are closed protocols interesting or useful to developers and users?

• Are open protocols sacrosanct; untouchable for traditional funds?

• Should open protocols be protected from concentrated control from their birth?

Since the advent of Bitcoin, crypto economics has proven effective in incentivizing decentralized infrastructure providers to permissionlessly show up and work, and ensuring these providers find it in their best interest to follow protocol. The fediverse, however, is a permissionless network that doesn’t consider crypto economics.

Open Networks

Actors

Open, permissionless networks are made up of decentralized operators. These operators do nothing more than maintain software on connected servers across the globe. Anyone can run a server. Closed, permissioned networks operate similarly, in that there is a global network of connected servers running the same software with one slight difference, which is that all network operators are permissioned by a company or allowlist group, such as Meta’s Instagram or Threads.

Why Tokens?

Open, permissionless networks have two problems: (1) they need operators to show up and work (i.e., run the server, follow protocol, and communicate with other servers), and (2) they are vulnerable to spam, and may be assumed to be under constant threat of attack by adversaries (including those running the servers). These networks need money to pay workers and have controls in place that provide some degree of assurance that spam or attacks will not bring down the system.

Enter the token incentive. Ether, the network token of Ethereum, exists to properly coordinate network actors, which just means incentivizing them with rewards when they follow the protocol, and taking away their Ether when they break protocol. Ether also exists to facilitate an auction for network resources, which makes it difficult for some random entity (malicious or not) to overload the network with messages (i.e., spam).

Tokens, in short, exist to properly coordinate network actors.

Coordination without Tokens

The term federated network is used when describing networks of servers that are free to do what they want, and may communicate with other servers as they please. My early understanding of federated networks, like ActivityPub or the Matrix Specification, is that they provide a communication protocol between clients-servers and servers-servers, actors do not need permission to communicate in the network, and no token exists to coordinate actors.

Open, permissionless networks operating without a token are not my strength (I’m a protocol economist).

The key difference between an open, permissionless network with a token and one without seems to be around expectations for actors to show up and work, and guarantees for protecting against network attacks and spam. In federated networks, actors are assumed to show up and work for some implicit reward—either goodwill or some indirect revenue source—and implementing spam control seems to be on the network actors.

Open Questions

I have many open questions at this point.

Can guarantees for network availability, censorship resistance, and security be made in permissionless networks sans token? These guarantees are commonly available in crypto economically secured permissionless networks. Is a reputation mechanism, without a token, powerful enough to provide some of these guarantees?

How are network attacks mitigated?

How can we be sure professional grade infrastructure will join the network? Will it be sufficiently decentralized?

Maybe the guarantees provided by these networks are only meant for transacting low value information, such as social media (as opposed to money services, such as payments)?

In permissionless networks like Ethereum, it is relatively easy for a user to craft many different simultaneous transactions for submission to the network in a short period of time. If message traffic is heavy enough, individual nodes may become overwhelmed causing the network to slow down and potentially become unusable.

In order to prevent this, Ethereum protects resources (compute, bandwidth, and storage) by limiting the maximum size of each block. In order to value this blockspace, an auction happens every 12 seconds. Users that would like to get a transaction included in a block bid using an ETH unit of measurement called gwei for the amount of compute units required for their transaction. We call these compute units “gas”. Ethereum blocks are limited to 30 million gas, and the value of each block can vary depending on the current demand.

EIP 1559 modified the auction mechanism so that an algorithmically determined base fee is required for each transaction looking to purchase blockspace. This fee is burned. Users requiring priority execution can add a tip for the block producer.

This simple market does a great job of limiting spam transactions, since any user that wants to send many transactions would need to compete with other legitimate users also looking for blockspace.

Calibrating the User Experience

In a permissionless setting, the network must protect itself against spam. Spam prevention mechanisms that require users to bid for scarce resources, such as a blockspace, must be balanced against expectations for user’s willingness to pay. Incorrect assumptions here may result in a spam prevention mechanism that prevents any use at all.

In this post, we take a closer look at how Biconomy’s Gasless product can leverage fixed price transactions to provide a better UX for dApp developers today.

Biconomy SDK and the Gasless UX

The example cited in our previous post describes a user having the ability to wake up on a Saturday morning and purchase a bundle of transactions at that day’s Gwei price. In theory, a protocol specialized in financial risk management can harness gas forward markets to fully accept any and all gas price risk from normal web3 users on any given day, and immediately construct a perfect hedge so as to completely offset the risk taken. This financial risk manager could develop a user facing wallet plug-in that offers users the ability to purchase a fixed gas budget at a fixed price (”fixed price transactions subscriptions”) that they would then be free to spend over the subscription window.

This kind of solution would require an end-user interface with Biconomy’s gas tanks, which is not currently something we offer. However, similar to offering end users fixed price transaction subscriptions directly, we could instead allow dApps to purchase gas budgets for their end-users (or their own DevOps) at a fixed price.

Gasless ELI5

If you are not familiar with Biconomy’s Gasless Product, here is a quick explainer. Decentralized applications load gas tokens into a non-custodial gas tank and then relay user transactions through Biconomy’s relay infrastructure, which is capable of reimbursing itself through the dApp’s gas tanks. This setup allows the dApp’s users to interact with the dApp gas free.

Gasless UX Tradeoff

In the current gasless integration, dApps make a tradeoff between controlling the cost of subsidizing user gas fees and guaranteeing a number of gasless transactions for their users. Gas price volatility forces the dApp to choose how they optimize. If a dApp were to control for cost, then user experience may suffer as the number of gasless transactions possible might be less than communicated to their users as gas prices rise. Alternatively, if a dApp were to control for the number of transactions, the cost may become burdensome as gas prices rise.

Gasless UX Improvement

To help solve the Gasless UX tradeoff, Biconomy is proposing a transaction subscription agreement. Here, a dApp would be able purchase a 30-day subscription for a specified number of gas units at a fixed (gwei) price. This allows the dApp to know their monthly gas fee subsidy expenses in advance, while guaranteeing their users a certain number of transactions.

By offering dApps the ability to lock in user subsidies at a known upfront cost, Biconomy can make gas subsidy costs predictable for dApps. We think this is a nice UX improvement.

Example - Alice

Alice wants to onboard users to her shopping adventure game, and her target market is non crypto-native. By integrating Gasless, Alice can abstract away her user’s interaction with the network, which allows her users to focus on building out their digital wardrobe instead of having to constantly source gas tokens.

Alice wants to know in advance how much she will spend on gas subsidies each month. For this, she works with Biconomy to purchase a transaction subscription agreement.

Biconomy works with Alice to study her expected user base and the smart contract methods her shopping game will call. Biconomy and Alice estimate her smart contracts burn ~70k gas units/method call, and her users will make ~10.3k method calls per month. Thus, Alice will need to subsidize approximately 721MM gas units over the course of the first month. Using the previous 6500 blocks average gas price of 24 gwei, Alice would need approximately 17.3 ETH to cover her user’s gas costs for the next month. Alice signs up for a transaction subscription with Biconomy for 721MM gas units over the thirty days at a cost of 17.3 ETH. Biconomy guarantees Alice 721MM gas over the thirty days ensuring an optimal user experience, and Alice is satisfied knowing she will spend no more than 17.3 ETH for the next thirty days on subsidizing user gas, at an average cost of about 0.002 ETH per user transaction.

Example - Bob

Bob recently launched a new rollup chain to Ethereum. Bob’s optimistic fraud proof architecture allows users to cheaply transact off-chain with the guarantee that their assets are properly accounted for. In Bob’s set up, the off-chain transaction call data is compressed and sent in batches to a smart contract on Ethereum that represents the canonical state of the rollup. Bob employs an Ethereum relayer node that pays gas fees and submits changes to the smart contract to the Ethereum network. Bob’s rollup collects an estimated Ethereum gas fee from each rollup transactions and uses the collective funds to reimburse the relayer node. Bob recognizes overtime that estimating Ethereum gas fees, even a few minutes out, can be a difficult task.

Bob would like to know ahead of time how much he’s going to pay in Ethereum gas fees so that he can more accurately price his rollup transactions.

Bob works with Biconomy to estimate the monthly Ethereum gas spent writing off-chain call data to the network. Although a rough estimate, they determine that Bob will need to spend roughly 1.3MM gas per batch or roughly 6.2B gas per month writing call data to Ethereum. Using the previous 6500 blocks average gas price of 24 Gwei, Bob would need approximately 149 ETH to cover Ethereum gas costs for the next month. Bob signs up for a transaction subscription with Biconomy for 6.2B gas units over the thirty days at a cost of 149 ETH. Biconomy guarantees Bob 6.2B gas over the thirty days ensuring rollup transactions are priced in a predictable manner, and Bob is satisfied knowing his rollup users will spend no more than 149 ETH for the next thirty days, regardless of how volatile the Ethereum gas market is.

“Web3 is here, but it remains half cooked!”

-source

The web3 user experience is wrought with challenges for even the most well-versed blockchain degen. Blockchain gas markets are one example. Blockspace is preciously limited, and its value is determined through typical market structures. These markets allow price to fluctuate along with supply and demand, setting off a never ending roller-coaster for those looking to execute basic transactions. To date, web3 has accepted variable transaction costs as an inherent part of blockchain technology. But, Biconomy is in the business of examining typical web3 user experiences and understanding where frictions can be removed. In this blog, we introduce the concept of fixed price transaction subscriptions and a high level overview of how we will offer them to our partners using the Biconomy relayer network and gas price forward commitments.

The Ethereum Gas Market

Gas in Ethereum is simply a framework for valuing a scarce computational resource. The Ethereum gas framework can be a bit tricky to understand because there are two core components, as well as a third financial component that is often a source of confusion. The two core components are (1) gas units and (2) gas prices. Gas units are a measure of the computational resources required to perform particular functions in the EVM. Gas price (measured in Gwei) is what someone must pay in order to have functions executed. It is obvious, but worth noting that gas units are dependent upon the complexity of the code needing executed and gas price is determined by the supply of resources available to execute that code (i.e., blockspace) and the competing demand for it. The third component, often leading to confusion, is the price of Ether (ETH). As Ether is required to execute code within the EVM, one must acquire ETH to use Ethereum. ETH as a financial asset is volatile, where the price is determined by market factors. This price volatility is injected into the Ethereum gas framework. To recap, there are two sources of volatility in the Ethereum gas framework: (1) ETH market price volatility, and (2) Gas Price volatility.

Previously, Ethereum used a first price auction where users submitted gas price bids to have their transactions included in the next block. Gas price was entirely defined by the user and their perception of immediate blockspace supply/demand. This changed with the introduction of EIP 1559.

EIP 1559

The infamous protocol improvement came to life at block 12,965,000 (August 2021) as part of the London network upgrade. The EIP introduced a base fee and a miner tip fee (aka, priority fee), where the base fee is set by the protocol and is a function of gas used/targeted in the parent block, and the priority fee is bid by the user—typically through their wallet provider. These changes are meant to lower gas price volatility leading to a more predictable user experience. Another important aspect of the EIP is that base fees are burned by the protocol.

Ethereum Gas Framework from a user perspective

It’s not a surprise Ethereum users have had a rough time with gas prices.

Gas prices have spiked as demand for Ethereum block space has surged.

Users are often times confronted with the need to get a transaction completed on a Thursday, but speculate that if they get up early on Sunday morning they can catch a low bid.

The data indicates this user mindset isn’t actually true. Over the last 90 days, it is almost two times more expensive to execute a transaction on Sunday as it is to execute on a Saturday. In fact, over the same time period, transactions performed on a Sunday are roughly 3 percent more expensive on average than transactions performed on Thursday.

Improving the User Experience

Biconomy is a pioneer in Ethereum and EVM compatible L1 meta transactions. Meta transactions allow Ethereum users to transact with a zero balance account by passing transactions to a third party—Biconomy—to pay transaction gas fees. Biconomy enables this at scale by providing a non-custodial and gas-efficient relayer infrastructure network. Under the hood, Biconomy can be thought of as a gas storage provider. Biconomy helps partner dApps load large amounts of gas (in the form of ETH) into general purpose gas tanks to be used at a future date. This relayer infrastructure allows Biconomy to abstract away user pain points, such as having to acquire native gas tokens across chains in order to transact, or as we will discuss here, potentially eliminating exposure to volatile gas prices.

Fixed Price Transactions and Financial Markets

First, let’s define a forward commitment as a term that encompasses forwards, futures, and swaps. Think of each as a financial primitive that was created to solve business needs that typically involve cash flow or interest rate mismatches. A simple example could be a mining company that harvests precious metals from an established mine. They have somewhat predictable precious metal yields, but the price buyers are willing to pay for those precious metals varies based on market conditions. The mining company could simply leave their future revenue susceptible to the market, or they could engage with a counterparty to sell their yields at a fixed price at some known date in the future. The forward commitment in this example is the financial contract the mining company entered into with the counterparty. So, how can Biconomy use such a forward commitment to enable fixed price transactions (technically, fixed price per user operation)? Let’s see how this works for Bob.

• Bob estimates he will need 100 transactions over the next thirty days at an average gas per transaction of 21,000. Bob needs to purchase 2,100,000 gas for the thirty days.

• Current gas prices are 110 gwei—100 gwei base fee and 10 priority fee. Biconomy expects Bob’s thirty day gas costs to be 231,000,000 gwei (0.231 ETH).

• Biconomy writes up a contract to sell 2.1MM units of gas to Bob for consumption within a thirty day period for a fixed price of 0.231 ETH.

• Biconomy executes the contract with Bob, receives the 0.231 ETH, and loads it to Bob’s gas tank.

• Biconomy will consume 2.1MM gas units on behalf of Bob over the next thirty days, with a variable marginal gas cost.

• Biconomy will need to purchase protection for gas price volatility over the next thirty days. This protection can be in the form of a contract with an intermediary that grants Biconomy consensus fees earned for 2.1MM gas units of block space production.

• For example, Biconomy would enter into a contract with the Intermediary at a price of roughly 0.231 ETH (paid in stablecoins), and gain access to the variable consensus fees earned for the 2.1MM gas units of block production over the thirty days.

• The intermediary executes a swap with consensus producers thereby gaining the right to consensus fees generated for 2.1MM gas units of block production over the thirty days. The consensus producer gets a fixed amount of money (~0.231 ETH paid in stablecoins).

Figure 1 below, offers a simple diagram of how Biconomy is working to abstract away gas price volatility for the user.

DeFi Primitives

In the above steps, we can see there is an “intermediary” facilitating the transaction between Biconomy and the block producer. A crypto-native solution would involve a decentralized futures/swap market with deep liquidity where Biconomy could purchase index-priced contracts that settle in cash based on fluctuations in spot gas price vs contract price. This market would align more closely with the Ethereum ethos of disintermediation, which we whole heartedly believe in at Biconomy.

However, the reality is we as an industry haven’t yet built a forward commitment primitive—or a market for this primitive to trade in. Some exciting new projects like Alkimiya (https://alkimiya.io/) and Oiler (https://t.co/GGyoSR6Xoq), and earlier attempts, such as Uma’s uGAS token (https://medium.com/uma-project/ulabs-gas-futures-token-9f51682778dd) have put forth working models for how gas price forward commitments or options might work. However, these markets have not yet garnered enough liquidity to bootstrap a healthy blockchain gas market. There is much work yet still to be done here.

Gas Markets

While this critical piece of infrastructure is being developed, Biconomy is actively working with consensus producers on hedging strategies. If you are actively building in this space and would like to build together, please reach out to us (see contacts below).

EIP-1559 Blocker

If you have made it this far, then you are probably one of the five people on the planet working on blockchain gas markets (ok, maybe more than five). Also, if you have made it this far and are nodding your head saying “yes, this makes sense”, then you would be somewhat at odds with the mechanics of EIP 1559. The chart below shows the split between Ethereum base fees and priority fees over the last 15 days.

Priority fees are in orange and represent ~10 percent of variable fees over the last 15 days (the chart looks the same over a longer time horizon—priority fees make up roughly 10 percent of variable gas costs. Base fees paid by the user are burned by the protocol.

Biconomy’s job, as a participant in gas markets, is to offer an optimal user experience through features such as fixed price transactions. As discussed above, one option for doing this is by accepting price risk from the user, and hedging that price risk on the back-end so that Biconomy doesn’t get rekt. As you can see in figure one above, the way to hedge gas price risk is to purchase variable block production fees from producers such that Biconomy’s variable costs are offset with commensurate variable income. Unfortunately, 90% of user variable costs are burned and not received by producers. The mechanism introduced by EIP 1559 creates a natural shortfall in cash flow for Ethereum users looking to swap their variable costs for fixed costs. ETH block rewards passed along to the user would mitigate ETH price risk, but are no substitute for gas price volatility. Conceptually this cash flow mismatch seems like a deal breaker; however, as long as an oracle exists to prove the gas price index (both Alkimiya and Uma have built their forward product around a gas price index), and enough speculators participate on both sides of the market, a gas futures market in the EIP 1559 world is possible.

Although improved user experience was the intent of EIP 1559, the burn mechanism presents an obstacle for properly functioning gas forward markets that may allow for a more optimal user experience.

ERC 4337 and Biconomy as a Bundler Service

The limitations of EIP 1559 style gas markets cuts even deeper with account abstraction proposals like ERC 4337 on the roadmap. The ERC bakes in a natural place for Biconomy’s relayer services and provides the setup for leveraging financial engineering to provide a more optimal user experience. In the diagram below, Biconomy would provide services, such as fixed price transaction bundles and the ability to pay gas fees in ERC 20 tokens (Biconomy’s Forward product) as a “Bundler”. In the 4337 blog post, Vitalik notes a potential benefit is the ability to sponsor transactions through the use of a paymaster. These paymasters resemble Biconomy’s current Gasless infrastructure, which would make the below transaction model well-positioned for facilitating fixed price transaction subscriptions that leverage gas price forward commitments.

Conclusion

We believe fixed price transactions will provide a decidedly better user experience than variable price transactions. Much of the financial infrastructure required for fixed price transactions does not yet exist. Biconomy is working to bootstrap a forward gas market as a natural buyer of gas forwards. We are actively looking for partners to help develop these primitives.

Future blog posts will describe the product in greater detail, as well as provide an update on our progress towards facilitating the development of gas forward markets.

Biconomy is building critical tooling for web3. Although Ethereum was the focus of this article, Biconomy’s relayer network is live across ten different EVM compatible chains. If you are a web3 wallet or dApp and are interested in fixed price transaction subscriptions, get in touch with us on telegram or discord.