Skip to content

Fullcount Devlog #4: Custom account abstraction?!

Fullcount Devlog

Fullcount will launch with account abstraction. We will pay all the gas for our players during the first season of Nova League. We intend to pay all the gas required to onboard new players to our game as long as our company exists.

But we aren’t using ERC-4337 account abstraction. We do not believe it suits our purposes. We are building our own account abstraction mechanism. This devlog explains our reasoning.

There is a lot of excitement in the air about how account abstraction is going to usher the next billion users onto web3. “Account abstraction” in this context means ERC-4337. And ERC-4337 is amazing. It’s amazing because it improves privacy. It’s amazing because it’s censorship resistant. If you need privacy or protection from censorship, you should definitely opt into ERC-4337 account abstraction. As a user.

But if you are creating a fully on-chain game, and if your only goals are:

    1. to make it easier for players to play the game by providing gas for their transactions
    2. to not kill your players with a thousand confirmation windows

avoid that kool-aid!

Web3 game economies are real economies. And the infrastructure that a web3 game runs on imposes a tax on that economy. If we consider the total amount of money spent to play a fully on-chain game, the total value spent can be decomposed into the amount of value put into the game itself and the amount of value put into the protocol (Figure 1).

Note that the amount money spent doesn’t refer simply to the amount of money spent by players. Rather, it refers to the total amount of money spent by anyone to execute transactions related to the fully on-chain game, including money spent by game developers to sponsor gas on behalf of their players.

Figure 1. Game value vs. protocol value

We are building fully on-chain games because we believe that permissionless digital games can be more engaging, entertaining, and meaningful than permissioned ones. But we still hate taxes. They are costs to the collective game economy. Our objective when it comes to infrastructure is to offer a truly permissionless gaming experience at the minimal protocol_value/total_value “taxation” rate.

Permissionlessness in this context is equivalent neither to privacy nor to censorship resistance. It simply means that the game does not admit any privileged parties. Our infrastructure goal of minimizing protocol_value/total_value implies that we shouldn’t use a protocol that offers privacy and censorship resistance as its primary benefits – benefits which are technically much more difficult to achieve than mere gas sponsorship.

In gas costs alone, the cost of using a smart contract account as part of ERC-4337 incurs a higher protocol_value. Stackup’s article How Expensive Are ERC-4337 Gas Fees? offers an estimate of how much additional gas fees are incurred from being forced to use a smart contract account (with the reference account implementations). But this doesn’t account for the fees charged by ERC-4337 infrastructure operators.

ERC-4337 infrastructure fees are being subsidized heavily by grants right now, so it is difficult to get a sense of what these fees will look like in the long term if ERC-4337 account abstractions remain a standard. Operators are experimenting with pricing models based on monthly active accounts (“monthly active wallets”).

As a game which wants to pay gas for its players – especially the new ones – it feels like under the current model we would end up paying for on-chain execution plus a fee equivalent to what we would pay an external authentication service like Auth0 or AWS Cognito if we used such a service.

For game developers who are comfortable using such external authentication services, it is a good decision to use account abstraction offerings like those of thirdweb.

At Moonstream, we prefer not to cede user data to external parties. Especially not authentication. We run our own authentication service. This general attitude also defined our approach to account abstraction. We are creating a custom account abstraction for Fullcount. It is called FullcountPlayer, and it looks like this (Figure 2):

Figure 2. The FullcountPlayer account system. Not pictured: The super hardcore users who prefer to communicate directly with the Fullcount smart contract.

There are three main differences here from ERC-4337 style account abstraction:

    1. In ERC-4337 account abstraction, each user gets a separate smart contract account – possibly even multiple distinct smart contract accounts. In FullcountPlayer, there is a single multi-tenant smart contract that performs game actions for all users of the system.
    2. ERC-4337 is censorship resistant. FullcountPlayer is not. Experience has taught us that most players do not care. Fullcount, the game, is totally permissionless. This makes the game censorship resistant. Nothing stops ERC-4337 accounts from playing our game. We just won’t be paying for their execution.
    3. Players who choose to use our account system are using infrastructure that was custom built for our g. Players who chose to use ERC-4337 accounts are using general-purpose infrastructure which was built by a large community of developers and funded generously by many blockchain foundations.

One of the things we have learned from our past 2.5 years of operation is that it is much less stressful to operate an account system that uses upgradable contracts. The FullcountPlayer contract is an EIP-2535 Diamond proxy contract. It supports the use of Beer League Ballers, the freely mintable NFT collection we are launching for players who want to play our game without putting any of their regular accounts and NFTs at risk. It also supports the management of any other NFT that a player would like to play the game with. It contains batch methods which allow us to cut down on the costs of execution. Because the contract is upgradable, we can continue to optimize the on-chain behavior of our account system even after it goes live without having to fork it.

One consideration that went into our decision to build our own account system was whether we could ensure fairness for two players who were both using this system to play against each other. Fortunately, Fullcount is a game in which the order in which players make their moves does not affect the outcome. The only asymmetry is that the player who reveals second on each pitch pays more gas because their reveal is actually resolving game mechanics. This means that it is actually better for players to play each other using our account system, even if we do start charging them a subscription fee for sustained use of the system. It amortizes the cost of the second reveal over both players.

If the order of moves did matter to game outcomes, and if players were meant to act frequently, it is possible we would have come to a different decision about building it ourselves. It would certainly have been an even larger responsibility than it already is.

We will bring our account system live over the next two weeks, and it will be usable on Arbitrum Sepolia testnet prior to the launch of Fullcount’s Nova League in March. If you are interested in trying it out, we would appreciate your feedback. Please drop us a message.

We’d like to thank Matt Van from Proof of Play and Ronan Sandford from Etherplay for very helpful discussions regarding account systems.