The crypto Industry attracts a particular type of person. Gaining a solid understanding of an advisor’s motivations is very difficult. I’m going to broadly label the groups of people that have historically operated in this industry into two cohorts. 

Cohort 1: 

A portion of the industry believes, as I do, that neutral blockchain ledgers, and other cryptographically/economically secured technology, can fundamentally reduce risk in our financial system. Some small portion of this cohort can cut through their ideals and execute to deliver useful technology, today. The majority of this cohort gets lost in their ideal to decentralize everything that they fail to deliver useful tech–I’ve certainly made this mistake. 

Cohort 2:

The rest of this industry is nihilistic, hyper promotional, and predatorial. I’m not going to describe this group further. But, the reason this cohort exists comes down to three primary reasons:

• short term token incentives

• the code is open source, and easily forkable

• there is little adoption outside of speculative use cases (this is changing)

Of course, with the adoption of stablecoins there is an emerging, third cohort. Fintech businesses that want to offer their customers low cost payment solutions, or gain some efficiencies in internal business operations settlement. 

You don’t understand this technology deeply enough, and you certainly do not understand crypto culture deeply enough in order to pass sensible legislation/regulations, today. There are many competing voices.

But, there are pockets of understanding...

I think the authors of GENIUS do a wonderful job of tailoring regulatory requirements for blockchain projects that are at different stages of maturity.

Listen to whoever is advising this legislation. 

Here are a few industry leaders, other than Vitalik, I think you should listen to:

• Miles Jennings at a16z

• Tim Roughgarden at a16z

• Gabriel Shapiro at MetaLex

• Hasu at Flashbots/Lido

These individuals have a strong grasp of the technology, and I’ve found them to be well-rounded, intellectually honest, and generally without bias, or sympathy towards the business ventures of cohort 2. Most importantly, I’ve watched them operate through a few cycles.

You can get a good sense for someone’s intentions when prices are down.

Blockchain regulation is awkward

Most regulations were built to protect people from the mistakes and fraud of management. Painful experience has taught us that users are vulnerable to errors in leadership's decision-making—a fact most visible in finance, where the impact of human fallibility is easily quantified and quickly felt.

The vision of an open blockchain like Ethereum is to offer a verifiable asset ledger that doesn't require a trusted manager. So, how do we regulate something that isn't managed by a central authority?

We use a principles-based approach focused on the risks with the highest combined likelihood and impact. For a blockchain ledger, the risk at the top of the list is centralized control. With ultimate control, an actor can unilaterally:
- Introduce malicious or buggy software that causes lost or stolen funds
- Confiscate user funds
- Block certain user actions, like transferring funds

Incentives drive everything

How do we discourage centralized control to mitigate these risks? We fundamentally rethink our regulatory frameworks.

Instead of crafting rules that place limitations on centralized decision-makers, we craft incentives for them to give up their power. You want to start a perpetuals DEX with four network validators controlled by the same entity, operating out of a single country? Ok, then you have to submit to a highly scrutinized audit and reporting framework if you want to serve U.S. customers. That "tax" gradually declines as the network onboards independent operators across the globe. You can read more about incentivizing decentralization here.

We want to incentivize blockchain managers to give up control. We want power over the network (i.e., the ledger) to be decentralized. Giving up control of something valuable goes against human nature. It will not be easy, and it will take incredible will power from regulators and industry leaders to promote decentralization.

Conclusion

If we craft rules and regulations around the guiding principle of decentralization, the downstream risks caused by human fallibility fall away. Credibly decentralized, open blockchains offer us an opportunity to shift from the necessity of rules-based regulation to principles-based regulation, which will save time and money, and offer new growth opportunities for the global financial sector.

Open vs. closed blockchains

In an open blockchain network, anyone can help operate the network and maintain the asset ledger, without permission. Julia in Iowa can use her home computer to validate the ledger, but she is not the owner of the ledger in the way Wells Fargo owns its ledger. The leading example is Ethereum, where you can see the global community of people and businesses that maintain the ledger here.

This stands in contrast to closed blockchains. We also refer to them as permissioned blockchains, where a single entity or a set of close business associates have exclusive permission to maintain the asset ledger. The GS DAP network is a recent example. Permissioned, distributed networks for maintaining asset ledgers have been around since the 1980s. The real benefit of a blockchain asset ledger is that anyone can help operate the asset ledger, and thereby ensure for themselves its integrity. If you stop and think about that, what it really provides is trust. More aptly, the ability to not have to trust. Let's restate the primary user offering of open blockchain networks as "a verifiable asset ledger that doesn't require a trusted operator."

Reconciling openness and capitalism: trust building

You might think, "But capitalism was built on trust!" True. But we also suffer bad outcomes when we trust the wrong entity, and we often lose freedom—the freedom to change our asset ledgers how, when, and with whom we want. It takes only a short thought experiment to understand how a Wells Fargo banking application that uses an open blockchain asset ledger drastically changes their total addressable market. This is a big opportunity.

Conclusion

Let's wrap this post with a teaser into how open blockchain networks work, and why nuances in design can make a very big difference. The most important blockchain first principle is that blockchains are multidisciplinary. This just means that in order to function well, open blockchains necessarily must combine principles from distributed computing, cryptography, governance, and economics. The last two components do not get enough attention in public policy making discussions today.

If you made it this far, you must be writing rule making following the passage of GENIUS. If so, I would love to discuss risk frameworks and how we can promote the healthy adoption of open blockchain networks.

In most cases this will be determined by the robustness of the chain's transaction fee mechanism and the diversity of the software implementation (we refer to the latter as client diversity). Is downtime acceptable? If a blockchain network goes down, how do we agree on the correct version of the ledger to start with when we 'reboot' the network? In the event of open, permissionless ledger downtime, there are few options we can fallback on from the centralized ledger downtime playbook.

Onchain contract security

What development standards should we hold permitted issuers to? What standards should we maintain for partners who integrate the issuer's technology, and vice-versa? What happens to reserve assets when there is a significant loss of onchain customer funds due to a security lapse? Let's say a notorious hacking group gains access to an onchain application holding a significant amount of customer stablecoins. The issuer can (and might be required by law to) freeze the stablecoins. What happens to the reserve assets?

Legal

Which banking laws must permitted issuers enforce, and whom do they enforce them on? What is the definition of the permitted issuer's 'customers', and what rights do those customers have? For example, can the issuer revoke a customer's onchain USD as they please? Or, does it require a justifiable cause? What if the customer is not an American citizen?

Reserve Management and onchain risk

Why shouldn't the issuer be allowed to invest customer funds within the rules set forth in current banking regulations?

How about onchain funds? Section 10, Custody of Payment Stablecoin Reserve and Collateral presumably prevents onchain funds from being commingled or managed by the issuer. However, what if depositors agree to commingling funds for investment purposes? Consider the below scenario:

A group of wealthy people obtain a stablecoin issuer license from the relevant authority. The members funds are used to purchase allowed reserve assets, like treasury bills. The members all agree to allow for their stablecoin funds to be commingled onchain. The credit union mints stablecoins on Ethereum to an omnibus smart contract account that is capable of maintaining proper customer accounting, but whose stablecoins in the contract are collectively held. Importantly, the credit union’s own funds are not placed in the contract account. The credit union deposits the smart contract's stablecoin balance in Aave as collateral, and earns yield. The credit union then keeps the yield from reserve assets and from Aave. They pay members substantial dividends throughout the year from the credit union earnings.

What have they accomplished? They have managed to earn offchain risk free rate + onchain risk free rate, assuming Aave is as close as we can get to onchain-contract-based risk free rates.

Conclusion

The objective of current stablecoin legislation appears to be to clearly define regulatory responsibility, and the acceptable asset/liability risk profile of reserve assets. That seems like the natural place to start if your body of knowledge/experience is traditional banking. But, the focus of the current bill is likely disregarding some key risk areas.

The GENIUS bill is a good start. We need strong partnership between the regulatory agencies, their staff, the private sector, and the open source/research communities these technologies are born out of, so that we can quickly iterate the rules/laws that govern stablecoin activity in the U.S.

This point led me down a brief thought experiment that helped me explore the role regulation plays in this new technical architecture for global financial services. Some of the big questions on my mind were: Does a company building financial services on blockchain need customer deposit insurance? What good is a banking charter, when the blockchain is permissionless? 

User deposit insurance

In traditional banking, deposit insurance is an industry-provided guarantee of user money that has been given to a “charter-holding” company for safekeeping. In the U.S., that guarantee is backstopped by the U.S. Treasury. The insurance hinges on the charter holder’s willingness and perceived ability to submit to U.S. banking laws and regulations; their ability to operate in a safe and sound manner. 

In simpler terms, users give money to a company that has been granted industry-provided user insurance. In order to continue to qualify for the insurance, the company must follow specific guidelines for ensuring user money is properly accounted for (i.e., their ledger has integrity), and the company can only engage in permitted business strategies in their pursuit of making money for their shareholders. 

A new paradigm

Let’s imagine for a moment that the U.S. government provided a centrally managed ledger, and companies could build financial services on top of the ledger. The company has to pay a small per transaction fee to the U.S. government for all customer banking activities that update the ledger. Acquired customer balances would be attributable to the company, and the company can form business models on top of the ledger, so long as they adhere to banking laws and regulations. 

This model has the advantage of providing customers ownership over their account and account data. The customer can choose to engage directly with the U.S. government ledger, or use the services provided by companies building on top of the ledger. The customer has the choice. 

In the above model, would bank customers require deposit insurance? Would we still require banking laws and regulations? Yes to both. 

The role of a ledger vs. the role of a company

The company is still allowed to make poor decisions with the acquired user funds. The only thing that has changed is the company is no longer responsible for maintaining the ledger. So the risk of the ledger going offline or becoming corrupted has passed to the U.S. government. We trust the U.S. government has a shared interest in the prosperity of the financial services built upon its ledger, and therefore to maintain the ledger with integrity, and keep it online. In other words, the independent companies building on top of the ledger must feel that the U.S. government is a neutral third party who will not favor one company over another, and will not try to alter the ledger to steal funds. Importantly, their perception of the U.S. government’s neutrality must be backed by evidence and strong beliefs–-the claim must be credible. 

This model fails, of course, because nobody believes the U.S. government would be a credibly neutral ledger provider. 

The usefulness of blockchain consensus tech

If you believe, as I do, that the Ethereum ledger is credibly neutral, then we can replace the U.S. government in the above model with Ethereum. Is this fundamentally better than private companies offering their own siloed ledgers? I believe it is. First, Ethereum as a ledger provider has experienced zero downtime in its 10 years of operation. Second, as previously mentioned, users gain more control over their data, as the user has the choice to host their own account on their mobile device and interact directly with the ledger, or they can let a company manage their account for them.  The customer gets to choose.

In a world where Ethereum provides the ledger, financial services companies are still vital for consumer and institutional services. Most users will not choose to self-manage their account (i.e., they will need cryptographic key custody/safekeeping services), and sophisticated, well managed undercollateralized lending remains necessary for a healthy economy. 

Why Ethereum?

The subject of why I think the Ethereum ledger is neutral, and other blockchain ledgers are less neutral is the subject of another thread. Stay tuned.

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

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.

This blog explores:

• Why web3 user actions require fees

• The introduction of payment tokens

• Problems with payment tokens

• Alternatives to project payment tokens

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.

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.

Permissionless technology requires a payment for user actions in order to protect itself. Instead of using analog financial infrastructure for these payments, web3 projects introduce a digitally native payment token.

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

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.

Payment tokens act as a self-regulator on project growth, as the cost of project actions is driven up by market speculators betting on future project 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.

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.

Payment token volatility is entirely born by infrastructure providers, application developers, and users in the form of uncertainty

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.

The short-term benefits of successful payment tokens likely do not outweigh the time and money investment required by the development team to make the payment token successful over the medium-to-long-term

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.

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?

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.

$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.

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.

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.

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.

Fixed

• Server/infrastructure costs

• Salaries

Variable

• Transaction commitment costs

• Data availability costs

• Proof generation costs (if ZK rollup)

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

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.

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.

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.

• 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.

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.

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)

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.

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.

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.

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.

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.

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?

• 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

• 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

• 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

• 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

• 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

• 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?

Network Spam

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.

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.

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.

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.

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.

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.

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.

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.

Biconomy’s Mission to Onboard the Billions

“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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

Biconomy’s Mission to Onboard the Billions

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

@AdityaKhanduri, 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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.