It’s simple, it’s fast, and we see it as a superior alternative to ERC-4337 for low-fee chains like every Ethereum L2.

TL;DR

• We're building Boop — a minimal standard and implementation for account abstraction that is low latency and simple.

• Boop is a familiar alternative to ERC-4337.

• ERC-4337's design & tooling lead to high-latency transactions.

• ERC-4337 is very complex because of its design choices. This makes fixing the tooling hard as well.

• Boop improves the experience of devs and users for most use cases today (app accounts, wallet accounts) on low-fee networks like every Ethereum L2.

• Boop delivers a massive user and developer experience improvement for more demanding use cases, like fully-onchain games.

• Boop will come with an account extension specification that fixes glaring flaws in ERC-7579 (extension for ERC-4337) and makes it actually possible to write extensions that work with multiple account implementations.

• Our prototype is 3-4 times faster than common ERC-4337 solutions, with more low-hanging fruits to be harvested. HappyChain will eventually feature shreds, which will bring this to <500ms, anywhere on earth.

The goal of account abstraction (AA) is to make user accounts on the blockchain programmable and customizable. Two of the most common goals are gas sponsorship (allowing external entities to pay for the account's fees), and “session keys” or “automatic approvals” — enabling external entities to make some transactions on the account's behalf, in some specific situations.

Today, account abstraction is synonymous with ERC-4337 (”Account Abstraction Using Alt Mempool”). 4337 is a carefully designed standard that enables account abstraction without requiring change to the Ethereum protocol. However, while integrating 4337 into the Happy Wallet, we found that 4337 has significant downsides and limitations, which made it subpar for our use case (fully-onchain games). In particular, as implemented today it is very high-latency and its design is very complex.

4337's design leads to high latency between transaction initiation and transaction inclusion onchain. We currently regularly experience > 6s latency on a chain with 2s blocktime! Most of that is to blame on the tooling around 4337, but even the theoretical minimum time is higher than where we want it to be (see Appendix A for a thorough analysis, including sequence diagrams that shed some light on the situation).

4337 is also very complex, and so is the tooling around it. This makes it hard to jump in and fix issues when we encounter them (which is often). It also makes it hard to “fork” the standard into something more amenable to low latency.

The “4337 complexity” claim has been thrown out a lot on Twitter and other online forums, but it is generally unsubstantiated. Why is it complex? Is this complexity essential (does it buy us something) or accidental? What design goals or design choice create the complexity?

We have buried ourselves in the 4337 trenches, and we have answers! Keep reading to find out.

Our understanding of the design space led to the decision to create a new standard (and all the tools) around it. It's called Boop 👉🐈

Boop follows the general 4337 architecture (there is an entrypoint, accounts, paymaster, and an entity that relays transactions to the chain). However, it differs significantly in the details. We'll walk over the design in this article as well.

Table of Contents

• ERC-4337 design trade-offs

• Boop design trade-offs

• How Boop works ← skip here if you just want to see what we built

ERC-4337 design trade-offs

The 4337 design goal

ERC-4337 is designed with interoperability in mind. You have roughly four players in the system: bundlers, account implementation, paymasters, and end users. The fragile equilibrium that 4337 tries to solve for is that any combination of those can interact, and that nobody gets shafted by the other parties in the process.

Additionally, 4337 maximally optimizes for gas consumption whenever possible (but note that AA transactions aka user operations or “userOps” still incur significant gas overhead). This is because its first customer is the Ethereum blockchain itself, where gas is expensive.

This is a worthy goal, and if you accept these constraints, then I think 4337 is an excellent design. But as stated earlier, this comes at the cost of high latency and significant complexity.

We believe that for most use cases today (including our gaming use case, which is of course our north star), better trade-offs are possible.

Alt mempool & bundling considered harmful

The alternative mempool is part of the title of the EIP, and drives a lot of the downsides of 4337.

Why an alt mempool?

1. Interoperability: any userOp sent by a user with its selection of account and paymaster could be serviced by any bundler.

2. Gas efficiency: In 4337, the relayer that disburses the transaction fees (to be refunded by the sender or by a paymaster) is called “bundler”. This is because they bundle multiple userOps together to lower the gas fee per userOp, by distributing the 21k gas EVM transaction base cost, as well as the cost to load many AA contracts (EntryPoint, paymasters, staking…) amongst all userOps.

That comes at a cost:

1. Latency: 4337 calls for all bundlers to simulate transactions when they enter the mempool, and then to simulate the bundles before submitting. If any userOp fails, the bundler must remove it, and retry the simulation. In the worst case, a bundle may have to be simulated many times. These are not simple simulations either — they need to leverage tracing to verify complex validity properties for every userOp. But the worst part of the latency here actually comes from having to wait for other userOps to arrive before your userOp can be submitted.

2. Complexity: A bundler is vulnerable to both offchain griefing (just like any other web service, people can spam him with busywork), and onchain griefing: a userOp could simulate just fine but then revert onchain, leading to a loss of the gas fees incurred by the bundler. 4337 (and its companion ERC-7562) try hard to protect against it with a slew of validation rules.

   We took a hard look at this — the ERC-4337 design is sound but cannot prevent all forms of griefing. However, it successfully makes what griefing can be done economically stupid.

   However, in a high-throughput/low-fee environment, most of the rules are unnecessary. Instead the bulk of the protection is carried by the “staking” mechanism where account factories and paymasters have locked some capital for a certain duration. This mechanism could live outside of the core protocol, at the discretion of the bundlers — which is our chosen approach in Boop. See Appendix B for an in-depth analysis.

Why have an alt mempool at all? Blockchains already have perfectly functional mempools. It's only required because of bundling and its gas efficiency gains. But on L2 chains, where gas is much less of a concern, you could just do away with it entirely, and relay a single userOp at a time.

“Censorship resistance” is sometimes an argument for the mempool, but it's a strawman when any honest actor can spin up a bundler and end censorship. If the tools were a little bit more mature, it would also be easy for an end-user to do this directly.

The 4337 mempool is seemingly live on some mainnets, but you'd be hard-pressed to find details on it besides some announcement posts. I do think it's fair to say that it's mostly unused today.

And that's because…

You don't need that much trustlessness

Today, users of account abstraction are mostly apps that want to provide gas sponsorship for their users, in a dedicated app account.

But the truth is that if you have the technical capability to run a paymaster service, you can also run a bundler. In practice, apps look for a one-stop-shop solution that can provide the bundler and the paymaster, and deploy smart accounts on behalf of users. This is the business model of Pimlico, Biconomy, and many many others. This means the bundler, account and paymaster can trust each other!

This is only the first stage of account abstraction. Another use case is wallets that want to relay transactions for their users. This includes HappyChain, Ambire, and Candide. These will usually impose usage of their own accounts (it's actually hard to make things work across accounts, more on this shortly). Multi-paymaster support is desirable, but it's usually easy to have a whitelisting process for those, or to use staking to minimize the downside (as ultimately 4337 does as well).

Ultimately trustlessness sits at the wrong level of the stack in 4337. It is best implemented on top of the base protocol, as a set of measures that the bundler will take to avoid griefing. These are necessarily heuristic in nature (i.e. 100% protection is impossible), and can always be downgraded to whitelisting in most cases. Doing so allows removing a lot of tedious logic from the contracts, and simplifies the implementation of simple trustful bundlers (covering today's use cases).

The only reason trustlessness is embedded so deeply in 4337 is because you need it to make the alt mempool work.

Native AA

4337 was designed as not requiring protocol changes. Now the long-term vision is to have protocol-level AA in Ethereum, as in fact some blockchains already have.

One direction being explored is to enshrine 4337 at the protocol level (RIP-7560). I have spent less time thinking about this, but at first glance it looks like a terrible idea, enshrining many 4337 concepts when they are no longer required. Bundling is perhaps the best example: if you work at the protocol level, you can eliminate the gas overhead, and thus bundling is no longer required (you still need a relayer to pay the fees prior to a refund, though this role can be easily fulfilled by the user himself or by the paymaster).

Balance fragmentation

One of the tools in the arsenal of 4337 to combat griefing is staking. Staking serves two roles:

1. Fees refunded to bundlers are not sent directly, but instead deducted from a staking balance. Stake withdrawal is on a timelock, which prevents accounts and paymaster from withdrawing payment at the last second.

2. Bundlers can require a minimum amount staked and a minimum staking time before trusting accounts, paymaster, and account factories. This prevents griefing from constantly redeploying these contracts to sybil attack a bundler.

We think (2) makes a lot of sense — and should most likely be implemented on top of the core protocol as a mechanism for bundlers to protect themselves, but (1) is unacceptable for accounts.

One of our motivations in the design of the Happy Wallet was to avoid the existing fragmentation where each app would get its own account, with significant difficulties in managing these and moving funds across them. Staking for payment reintroduces this, where you now need to explicitly top up a separate “gas tank” to make transactions directly.

Granted, this is not much of a concern for HappyChain where we expect sponsorship, including from HappyChain directly to cover most user actions. But as we conceive of Boop as a much more broadly applicable standard, this seems like a retrograde step in user experience.

Specification uncertainty

While we consider ERC-4337 to be well-designed, we can't say the same about ERC-7579, which standardizes 4337 account extensions. These extensions enable to change how the account validates or executes userOps, change the operation of their fallback functions, and define hooks.

We're sure the authors had the best intentions in leaving the spec open-ended, but the end result is that it is incomplete, and extensions in the wild can be incompatible.

7579 only specifies how the modules are installed, uninstalled, and detected. It does not however say anything about how the modules are used or triggered, nor the interface that the modules should adopt!

Let's consider the most relevant example: defining a validator extension that can support automatic approvals (session keys). These are scoped to very precise circumstances, and cannot be used to validate all userOps. The userOp must then indicate it wishes to use the custom validator. This is not standardized, so some implementations encode the validator address in the nonce, while some append it to the signature field.

Consider now an extension that needs access to extra data to perform its duties. 4337 provides no extension field for this purpose and the data must thus be encoded … somewhere. Usually in the signature or calldata fields. Since 7579 does not specify module interfaces, it is up to the contract to know how its extensions work, what data they expect, and how to transmit that to them.

The end result of this is that extensions end up being account-specific, conforming to the interface expected and supported by a specific account implementation.

This is in complete contradiction with the rationale for using ERC-7579 (now the dominant standard) over the superior (imho) ERC-6900 (though the previous link has some fair concerns about 6900 too):

ERC-7579 is a minimal interface that solves one problem only: modules should be compatible across smart accounts.

(We'll also point out the irony of ZeroDev pushing for ERC-7579 and compatibility, when their SDK does not actually enable using 7579 directly, but instead forces you to use their own unstandardized & cumbersome custom layer built on top of 7579. Oops.)

Boop has a much better solution here, which properly specifies the behaviour and interface of extensions while being … simple. It also makes it simple to pass data for various extensions in a non-conflicted way by having an extraData field structured like a dictionary (addressing some of the concerns about ERC-6900).

Besides extensions, 4337 also has a few specification fails that we correct. For instance, the destination of the call made by a user operation is not explicitly specified, and is traditionally encoded in the calldata field — but this is not standard and can thus not be strictly relied on.

Boop design trade-offs

I hope to have convinced you that 4337 has issues, at least for specific use cases. If you want to do DeFi on Ethereum with a smart account, it might still be a very good solution! Though in my opinion, this is not the exciting future that account abstraction unlocks.

Let's now have a look at what Boop does differently.

HappyChain is an L2 chain for fully-onchain games. Gaming transactions require extremely low latency. There are a lot of parts in making that happen, but a crucial first step in the design is making sure the transactions hit the sequencer as fast as possible. This is the main reason 4337 did not work for us.

In brief, our design goals are:

• Low latency between transaction initiation and transaction inclusion

• Simplicity in the design, especially keeping the core protocol minimal

• Hackability / forkability

To achieve these, we are willing to make some concessions:

• The core protocol will only have very minimal protections against griefing, requiring either trust or protection at a higher level (e.g. with staking).

• Get rid of bundling, meaning a loss of gas efficiency. HappyChain will be a superscale chain, leveraging technology from RiseChain and Celestia. Since we control the nodes, we have the ability to play with gas policies, as well as the option to enshrine account abstraction at the chain level down the line.

Let's expand on some of these points.

We don't care about trustlessness so much — HappyChain will impose its own (customizable!) accounts and will run its own submitter (our relayer, like a bundler without the bundling). We have our own paymaster contract that we trust, and we will introduce a mechanism to trust third-party paymasters. The two most promising mechanisms here are staking (just like 4337) and paymasters deployed from a trusted source — we want to offer a framework to easily and automatically deploy paymasters with customizable policies, and deploy them on behalf of projects, ensuring us that the paymaster is safe by construction.

We care about simplicity — because we're writing software and have to maintain it. We want to push as much as possible outside of the core protocol. This includes griefing prevention and the ability to trust random third parties.

We also want to optimize for hacking. Because we don't do bundling, there is no need for everyone to use the same EntryPoint contract (accounts can be set up to support multiple entry points). Want to customize something? Fork the code and off to the races! So keeping the code simple and understandable is a major design goal.

Note that while trustlessness is optional (but achievable), Boop does enable compatibility to all spec-compliant implementations. This is a notable improvement in the case of account extensions.

How Boop works

Despite its simplicity, Boop affords a good deal of flexibility. Let's explore some typical flows.

Paying Submitter

Let's start with a simple example where a user wants to send a transaction, paid for by the submitter. This is the flow implemented in v1 of the Happy Wallet for transactions sponsored by HappyChain.

The user (or in reality, the wallet) will call a single method (boop_execute) on the submitter.

No other calls, not even blockchain RPC calls, are required!

The submitter then simulates the transaction to get the gas limits, and queries the chain for the proper gas price. It then submits the transaction onchain to the entry point contract.

This magic works because we allow the user to sign a boop without gas values whenever he is not the fee payer (the submitter or the paymaster contract (see later) can validate the gas values).

Gas estimation is worth a digression. Just like 4337, Boop needs more than just the gas limit of the submitter transaction. It also needs a gas limit for the call made by the account. We can either trust or monitor accounts & paymaster, so we don't require gas limits for them as 4337 does, but the called contract could be anything, and thus we need a gas limit for protection there. To estimate those two limits, the submitters make an eth_call to simulate the submit run, but specifies 0x0...0 as the sender. This turns the entrypoint, account, and paymaster into simulation mode, adopting relaxed validation rules. The call returns a struct that not only includes the estimated gas values, but also data to help debug failures, like a code indicating the cause of failure (validation? execution? payment? unexpected revert?) and the revert data if applicable.

(This compared favorably with ERC-4337 which requires a completely different code path for gas estimations.)

The boop is packed in a super simple format (basically just concatenating the fields), which leads to > 200 bytes of data savings (yes, Solidity's ABI encoding really sucks). The size of the fixed-size part of a boop's data is also around 200 bytes, which means that this makes gas token transfers 50% smaller! It is then decoded once at the start into an easy-to-manipulate struct.

The entry point logic is a straightforward affair, which decodes the boop, calls validate on the account, and if that succeeds, execute. Since the submitter is the payer, no need for refunds.

For comparison, let's see how ERC-4337 handles the same scenario:

The chart clearly illustrates Boop's advantages in simplicity and latency: one roundtrip originating from the user for Boop vs 5 for 4337, and 3 roundtrips originating from the bundler for Boop vs at least 4 for 4337.

Multiple notes to be made regarding the comparison (feel free to skip if you don't care about technicalities):

• We didn't include the account deployment pathways, as Boop leaves account deployment outside of the core spec (if account deployment at the time of the first boop is desired, that can be achieved with a multicall, or a preceding call from the submitter).

• In both cases (Boop & 4337), the entry point checks the payment, which is not represented in either diagram.

• Paymaster service capabilities are standardized in ERC-7677.

• In theory, it is possible to skip the paymaster service and rely purely on the onchain paymaster as Boop does. In practice, all service providers today route sponsorship requests through their paymaster service. 4337 service providers do not provide a combined endpoint that performs sponsorship and submission at the same time (which is what Boop's paying submitter does, and without incurring any onchain gas overhead).

• The call to pm_getPaymasterStubData could be skipped, but only if the format of the paymasterData is known and the stub data is made such that an overestimation of the submitter fee will be provided. In practice, this is not done in any SDK or frontend library.

External Paymasters

What about third-party paymasters? Here's the new flow with the difference highlighted in blue.

The difference is trivial: after execution, the entry points calls payout on the paymaster contract with the boop (which can optionally include paymaster-specific data), and the actual amount of gas spent. The paymaster contract validates that it is willing to pay for the Boop and that the requested payment (consumed gas + submitter fee) is reasonable, then transfers the payment to the entry point. The entry point then validates that the payment has been made, then returns (or reverts if not).

Self (account) payment

What if the account wants to pay itself? It's trivial: the account just needs to implement the paymaster interface and specify itself as the paymaster!

There is one snag though: in this case, the Boop spec enforces that the user must sign over the gas values. This is because we expect account payment logic to be very simple — basically just a transfer: the entry point is trusted and so we know the boop passed validation. But if we don't sign the gas values, the submitter (which is to say, anyone) could steal funds from the account by asking a massive submitter fee, or they could be griefed by applications consuming an undue amount of gas. Paymaster will generally either target a specific use case or have bespoke accounting logic, but accounts are much more open-ended.

Boops in the wild

Besides purely submitting transactions (or boops in this case), the infrastructure and ecosystem also matter. By nature of being very lightweight, boops are easy to work with.

Here's a breakdown of the structure of a Boop (fields have been re-ordered for logical grouping):

struct Boop {
    address account;        // sender
    address dest;           // destination of target call
    uint256 value;          // gas tokens in wei to transfer to dest
    bytes callData;         // calldata for target call
    uint192 nonceTrack;     // nonce namespace (enables parallel tx tracks)
    uint64 nonceValue;      // nonce within track

    // Gas and Fees
    uint32 gasLimit;        // for submitter tx
    uint32 executeGasLimit; // for IHappyAccount.execute
    uint256 maxFeePerGas;   // wei max fee (basefee + tip)
    int256 submitterFee;    // flat wei submitter fee

    // Payment and Validation
    bytes validatorData;    // validation-specific data (e.g. signature)
    address paymaster;      // fee payer (IHappyPaymaster
                            // or 0x0 for submitter
    bytes paymasterData;    // paymaster-specific data
    bytes extraData;        // for extensions
}

The submitter allows monitoring boop status, exposing the following endpoints (in addition to the previously discussed boop_execute and boop_estimateGas):

• boop_submit(boop) — equivalent to submitting a transaction, but not waiting for the receipt

• boop_receipt(hash, timeout) — waits for the receipt then returns it, a timeout can be passed, which allows this function to be used for polling if set to 0

• boop_state(hash) — returns the current state of a boop (e.g. included — along with the receipt, failed — along with the failure reason, submitted to the chain, pending processing, …).

• boop_pending(address) — returns all pending boops (not yet included onchain) that the submitter is tracking.

• boop_cancel(hash) — cancels the given boop if it has not yet been submitted onchain.

What about explorer support? The good news is that by default the information you get from a submitter transaction is almost as good as the information you get about an userOp on BlockScout, which is the most widely used interface for this today!The only missing piece of data is the boop sender, but it will be surfaced via the Boop event that logs the entirety of the Boop data structure. And unlike 4337, you’ll see the target of the call too!

Things could definitely improve there, but by making zero effort, we're pretty much as good as the 4337 state-of-the-art!

In general, Boops are easy to work with programmatically — you can filter transactions via the Boop event then decode the packed Boop passed to the event using our libraries.

Account Extensions

Boop's extension story is extremely simple. We’ll focus on validator extensions, but execution extensions follow the same pattern.

An account supporting extensions implements the following interface:

interface IExtendedAccount {
    enum ExtensionType {
        Validator,
        Executor
    }

    // Reverts if the extension is already present.
    function addExtension(address ext, ExtensionType type) external;

    // Reverts if the validator is not present.
    function removeExtension(address ext, ExtensionType type) external;

    function hasExtension(address ext, ExtensionType type) 
        external returns (bool);
}

And the validators must implement the following interface:

interface ICustomBoopValidator {
    // Same interface as IBoopAccount.validate
    function validate(Boop memory boop) external returns(bytes4);
}

To signal that a custom validator is used, the account must parse the extraData field. This field is structured as a packed list of (key, length, value) triplets, where both the key and the length are encoded on three bytes. We supply a library function to easily extract the value of a given key.

The key 1 is reserved for custom validator addresses, and if present, the account must delegate its validation to the custom validator.

If you want to compose validators (e.g. require multiple validators to assent, or require a single or even a quorum of validators to assent), this can be implemented as a custom composition validator.

Furthermore, accounts are allowed to inline common validators (which we'll do for session keys), as long as the spec is respected, with the exception that these validators are not required to be uninstallable.

That's pretty much the whole validator extension spec!(Okay, there are also events emitted on install/uninstall.)

What about EIP-7702?

There's a misleading narrative out there that somehow 7702 changes things with respect to account abstraction standards. It doesn't.

The only thing EIP-7702 does is it lets EOA become contracts (potentially temporarily). The main use case is to let them become smart accounts, which is great!

Both ERC-4337 and Boop are fully compatible with EIP-7702.

It's only the start

We'll release the Boop spec and open-source code soon (hopefully within two weeks). If you want an early sneak peek, my DMs are open.

The code is vastly simpler than 4337's. For instance, the entry point contract is only ~300 lines of code, all in a single easy-to-parse function, including interface documentation & the simulation code path vs > 1000 lines for the 4337 entry point, which includes neither and depends on many helpers.

Boop is only the start of the latency battle. While our initial testnet will have 2s block time, our subsequent testnet will integrate the tech from Rise Labs and enable shreds — ultra-fast (< 10ms) per-transaction confirmations. Waiting for blocks no longer required!

We'll also make an indexer available that listens to sequencer-emitted shreds. In a game context, this means every player can learn of other players’ actions right after the sequencer confirms it. If the sequencer, submitter, and indexer are colocated in the same data center, this brings to quasi-parity with web2 gaming latency!

Besides this, we also want to build better simulation capabilities. In games, the success of a transaction often depends on the preceding transactions by the same player and other players in the same game. The inability to simulate transactions in that context can cause the simulation to fail (or to report an inaccurate gas limit), which can cause “pipeline stalls” where we have to wait for the preceding transactions to be included on-chain to be able to properly simulate the next one. This is an issue if we want to enable games where a user can submit many transactions over a few seconds!

As always, our goal remains the same: make builders’ lives easier. Just submit the transaction and don't worry about it! 🤠

The Scene

I’m writing this two months after the Devcon 2024 conference, and the fully onchain gaming space is in turmoil. With a few notable exceptions, the first generation of games is struggling to achieve traction, and the patients lack conviction in their own remedies.

Like any good doctor, I have a diagnosis, and a cure.

But today, I'm taking a step back to explain why onchain gaming is more deeply transformative than most understand.

Praise to the Greats

The onchain gaming space is permeated with creative thinking. We've been told of autonomous worlds, hyperstructures, onchain realities, worlding, composable engineering, and more, and we have been inspired to build.

But a lot of this sounds a bit too abstract to me. I understand the dream, but it's hard to imagine what the end state looks like.

This is natural: when you are describing an uncharted future teeming with possibilities, it's hard to draw a clear map.

I'm going to describe the fundamental transformation that onchain games can bring about. I hope it illuminates all of the above ideas.

Creation, and those too swamped to seek it

The creative act is one of life's most intense joy, and one of its foremost purveyor of meaning. This much is obvious to anyone that has created anything of consequence, even if only personal consequence.

It is a tragedy that some people do not get to experience this, or only ever catch glimpses of it.

One of my fondest teenage memories is when I spend a whole day and the better part of the night trying to set up a World of Warcraft private server, along with one of my best friends. The challenge was just at the right level for us: we didn't now how to code, but we were tinkerers. And so over the course of the day we chipped away at the problem, fixing build system issues, missing DLLs, making sure assets were in the right format and in the right location.

At the end of that fateful night, we were able to log into our very own world. We prompty gave ourselves 10x speed and the power of flight, zoomed over the world to survey our creation, and we saw that it was good.

We didn't create very much. But it did feel magical, and the moment captured the joy of creation: you struggle and then you are rewarded by enjoying something that you made (or in this case, made happen). The feeling would recur many times over the years, and it still is the thrill I seek to this day.

There is something extra special about creating a world, as well as any interactive experience that other people can engage with.

I want to democratize this feeling. The memory highlights that you don't need 10 years of programming practice to experience it.

Some of us have the skill to build games from scratch, but not the time. And people without the skill most likely don't have the time to embark onto a years-long learning journey.

They shouldn't, and don't need to.

But how, you ask?

UGC rules everything around me, FOCG, get the money

User-generated content (UGC) is one of these boogeymen often used while pitching games, but few people understand how powerful it truly is.

Let's look at the top 10 video games by MAU:

1. Roblox

2. Minecraft

3. Fortnite

4. The Sims 4

5. Counter-Strike (2 & GO)

6. Call of Duty (Modern Warfare II/III/Warzone/Black Ops 6)

7. League of Legends

8. Valorant

9. Grand Theft Auto V

10. Rocket League

Roblox and Minecraft basically thrive on UGC — it is what drives their enduring success. The same goes for The Sims, which has players create houses and characters, and share them.

Four other games in this list (Fortnite, Counter-Strike, League of Legends and Valorant) are refinement of genres that started as mods of other games. [1]

Without the ability to easily mod games and create user-generated content, the most popular gaming experiences available today wouldn't exist or persist.

Even if you believe the genres would have eventually emerged, there is no doubt that modability sped up their adoption. And for every mod that made it big, there are 100 great gaming experiences that didn't crack the top 100. Many of those would never have existed if modding didn't make them easy to build.

This is my thesis for fully onchain games (FOCG): By empowering people to create new gaming experiences, you unlock previously untapped creative powers.

This multiplies the opportunities for breakout success, keeps gamers engaged, and offers a diversity of experiences that cater a broader player base.

Everybody benefits: the developers of the original game, as mods drive adoption & sales, the modders (who can create something that couldn't otherwise, and can profit themselves), and most of all the players, who are served with more and better gameplay options.

Most importantly, this world is exciting. There is always something new, games keeps improving, changing and never gets stale.

[1] The original Counter-Strike is a Half Life mod; Valorant is strongly inspired by Counter-Strike; League of Legends is a MOBA, a genre that started with DotA, a Warcraft 3 custom map; Fornite is a Battle Royale, a genre that got started with PlayerUnknown's Battle Royale, an ARMA 3 mod.

Hooked on creating

UGC help foster creation by being vastly easier to build.

It took 4 years and more a team of around 30 people to make Warcraft 3. Defense of the Ancients (DotA), its most successful mod, took one guy only a few months. The mod was open-sourced 6 months later, and many alternative versions were subsequently made. The seminal “DotA Allstars” — which combines the best ideas for all these forks — comes out 8 months later. The map (and its updates) end up being played by millions of players around the world. Its successors (DotA2 and League of Legends) are played by more than one hundred million players every month.

The most famous video game map of all times (de_dust2) was made by a 16 year old in his bedroom. And these stories are by no mean unique.

UGC also provides a neat pathway into more and more daring forms of creation.

The very best games offer a gamut of creation options, from simple to very ambitious, and each successful step can naturally lead you into the next:

• tweak a few things in the game (balance it better)

• add custom units, objects, cards

• create your own map, using existing tools and assets

• modify an existing mod

• create your own map, with custom texture and scripts

• create your own mod

• create your own modding tools

At their best, UGC gamifies the act of game making itself.

Why onchain?

If traditional games are able to tap into UGC and mods, why should we build onchain?

Many reasons:

1. Onchain games enable monetizing open-source games, via network effects (e.g. match-making), a preference for the “real asset” (e.g. why NFT collections have value when everyone can copy them at zero cost), and incentives (possibility to extract real value from the game).

2. The game being open-source makes modding & UGC a lot easier.

3. Smart contracts are a perfect platform for extensibility: it's the original use cases, and there is broad knowledge on how this can be done. There is clean separation between the frontend and the backend.

4. Easier devex: deploying to a blockchain means less time spent on devops.

5. Tokens are awesome

   • They can incentivize UGC and mods. This can be done in traditional games too, it's just a lot easier on the blockchain.

   • They can be used for user acquisition, by giving out the game's currency and/or ownership, instead of spending on ads.

   • They create an easier path to funding, especially crowdfunding.

6. Everlasting games: open-source + deploying onchain means the game developers cannot kill it even if they wanted to.

7. Provable fairness: no ability for game developers & operators to cheat. This has been a real issue when value is at play, from poker site scandals to rogue MMO game masters. Operators also don't custody user assets and funds.

8. Massively (soon!) multiplayer by default, without incurring extra complexity to developers.

It's not perfect yet — building onchain still adds a lot of friction to the game making process.

We think the benefits already outweigh the costs, and it's only going to get better.

Improving this is one of HappyChain's missions! (And we are not alone).

In conclusion,

Let there be games.

Happy what now?

HappyChain is an Ethereum layer 2 blockchain that brings free-to-play and zero-friction onboarding onchain.

On HappyChain, you can start playing games in seconds, not hours. There is no wallet to install, and no gas fees to pay: you can log in with your social accounts and play straight away. Even your mom can do it.

We push this even further with universal happy income: every day players can earn some $HAPPY tokens which lets them try out real-value games without spending a dime. Free-to-play? Try free-to-pay-to-play!

For builders, HappyChain aims to be the ultimate onboarding and distribution channel — the easiest way to get players to try your games, bar none.

Free-to-play is the major player acquisition funnel in Web2 — it's crazy it doesn't exist in Web3. Asking users to pay $50 to try a game is absurd. We're here to fix that, and bring in the Web2 users while we're at it.

Additionally, HappyChain provides a best-in-class experience for building innovative games and social apps. Here are only a few of the features on our roadmap:

• Synchronous randomness: Math.random() in Solidity, not only request-response schemes that incur latency

• Private information support: avoid issues with commit-reveal schemes when the committer fails to reveal

• Event and state-based automation, but with a buttery smooth onchain UX

• Anti-sybil technology: grant extra benefits and target airdrops at verified players

• First-class support for offchain compute and zero-knowledge primitives

On the stack side, HappyChain will use the OP stack an use Celestia for data availability. These are two of the most legitimate infra projects in the space, and we're glad to be building on the shoulders of giants.

Working with them enables us to be decentralized and secure from day one. Thanks to our partner Caldera, we will also benefit from rock-solid battle-tested infrastructure.

Now you know what HappyChain is building. But why did we decide to build it?

HappyChain was born from a conversation that I (Norswap) had with Mr. Small of Small Brain Games fame at Komorebi's hacker house in Denver. Small came up with the name as a joke but at some point we wondered: what would we like to see in a gaming chain?

We liked our answers to that question, and HappyChain was born that very night. I was to build the chain, while Small would keep focusing on his studio, build initial content for the chain as our first partner, and advise the direction of HappyChain.

Today — three months later — a team has been constituted and we're ready to start cracking and build this out!

But what did we see in this new chain idea that motivated us so?

Many chains, little games — what we unlock

It seems like these days not a week passes without a new L2 being announced. And many of these L2s seem very interested in going after the onchain gaming market. Why do we feel we need to throw ourselves into this mad rumble?

It's very simple: nobody else is solving the right problems. There is too much infra and not enough content, too many solutions in search of a problem. We want to focus on real problems that builders are having, right now.

Instead of reinventing the whole stack and locking users into new unproven technical solutions, we take what works, and solve one problem at a time. Builders want solutions to problems, not new paradigms.

So let's focus on problem number 1.

The fundamental problem of onchain gaming is distribution: it's too hard to play the games we have — many of which are pretty fun.

The technology to solve these problems exists: we have social login providers and gas sponsorship infrastructure. But in isolation, these are not enough.

These technologies need to be integrated into a coherent whole, and the right level to integrate them is the chain level.

Let's consider what a non-crypto-native user has to go through to play a social-login game on an L2:

1. Install a wallet like Metamask (Are there instructions on how to do this?)

2. Secure your seed phrase (What is this? Why does it matter?)

3. Open a CEX account

4. Wire money to the CEX account

5. Swap for the chain's gas token (What is gas? What is the gas token?)

6. Withdraw the gas token to the chain

   1. If the chain isn't supported, withdraw to another chain — don't forget the gas token!

   2. … and find a bridge from that chain to your target chain.

7. Transfer the token to your game wallet (Don't forget to keep a little on the chain so you can withdraw!)

8. Play

How many users are able and willing to do that?(Don't answer, it's a rhetorical question.)

On HappyChain, the experience looks like this:

1. Sign up with your social account

2. Play

3. (optional) Use built-in fiat onramps or our canonical bridging hub to easily make in-game purchases… or claim your universal happy token to start playing real-value games, for free.

We believe this will unlock a flourishing of new fun games and experiments for anyone to play and build upon. The new technical affordances we make available to onchain game builders will further help towards this goal.

A different path, a different culture

We don't claim that zero-friction onboarding is a novel idea. We're not revolutionizing gaming or onchain social — we just want to bring fun experiences online and onchain: safe, trustless, and easy to use.

Compared to other offerings, we embrace permissionlessness and experimentation.

HappyChain is a place for everyone: we welcome both big-budget studios and independent builders trying to create something new. We endeavor to make HappyChain a hotbed for experimentation.

We're very excited about the new experiences made possible by the blockchain, and in particular by fully-onchain games — these open-source cannot be killed and can be forked, but still offer a clear path to monetization for their creators. They also make it much easier to enable user-generated content.

HappyChain is entirely permissionless, and so is integrating our wallet SDK. User-centric gas sponsorship can go towards any project, with additional gas sponsorship for our partners. We don't gatekeep the experience: any project can easily set up their own gas sponsorship.

…

But honestly, HappyChain is about so much more than that. I don't think I could have put it better than Mr Small, who contributed this to the original pitch for HappyChain:

HappyChain is an unserious light chain, with engaging content.

Our focus is on fun lighthearted experiences.

This is meaningfully different from existing chains.

DeFi-focused chains are about making money with yield farming and speculation, whether the tone is sober (e.g., Arbitrum) or degenerate (e.g., BeraChain). On HappyChain, making money is only a second-order consideration.

Existing gaming chains try to cater to serious gamers with ambitious games. While we see value in this, we believe the first step should be to focus on casual bite-sized gaming experiences and social interactions.

Finally, HappyChain will have its own unique, exclusive, and engaging content. This sets it apart from a score of copycat chains that only feature clones of popular DeFi apps and are glorified playgrounds for airdrop farmers.

Existing chains are dark, neon green, and hyper-technological.

HappyChain is light, fluffy, pastel, and humane.

And finally, I'll add this: we take the mission seriously, but we don't take ourselves too seriously. And we'll always give it to you straight.

Our biggest upside is on the corner of your mouth 🤠✌️

… wait, there's more!

This article is quite long already, but I could talk your ears off about what we have planned for HappyChain.

Stay tuned for more information about our vision for HappyChain, including:

• Information about the various features we have planned, as we build them out

• Our marketing plans, to turn HappyChain into an unstoppable distribution machine that not only helps you onboard your users, but also helps you find them in the first place

• Our plans for the utility of the $HAPPY token — it's the gas token of the chain, but there is so much more

• Our plans to distribute $HAPPY to the public (all I can say is “no bullshit”)

• Our initial perpetual airdrop mechanism (not going to lie, it's pretty dumb)

• In-depth explainers about our technology

• Spotlights on our gaming partners

• Stories from the front, and about our journey so far

You can follow us here on Mirror, on X / Twitter, and on Farcaster, or subscribe to this mailing list.

Until next time,

Stay Happy my friends 🤠