Gas fee abstraction examples

Requiring end-users of a system to maintain balances of various gas tokens such as ETH or MATIC or other native L1 coins to interact with dApps and other blockchain usage is very often a major blocker for many projects, especially where the end-users are not already crypto users. There are already some implementations of gas fee abstraction and substitution implemented at L1 level, but they come with some significant tradeoffs such as increased gas consumption and spam related problems. The Coinweb protocol has a structurally different execution model that allows for atomic gas-fee abstraction at both the protocol and application level and across different blockchains, wallets and dApp ecosystems. Applying gas-fee abstraction across a wider range of the blockchain ecosystem will further lower the barrier of entry for non-tech-savvy users and likely increase the overall adoption of the technology. For individual projects, it will ease the composability of other dApps allowing users to interact with a larger set of applications within specific projects uniform user experience.

1. Using CWEB to abstract away L1 native fees for writing Coinweb transactions into underlying blockchains.

2. Abstract away CWEB for Coinweb L2 operations by using L2 token - L2 CWEB DEX (bonding curve, liquidity pools).

3. Abstract away L1 fees and CWEB for L1 native transactions for Coinweb enabled L1 tokens by using L1 - Coinweb L2 DEX to exchange L1 token for CWEB.

   1. For each covered token spec API (i.e ERC20, ERC721, ERC1155 ..etc) method (transfer,approved, burn...) will have equivalent methods that the user will be able to use without costing him native l1 fees; while using Coinweb enabled software the equivalent methods will look the same as the spec methods.

   2. While using Coinweb enabled software, on Coinweb enabled L1 tokens, it will be possible to use Uniswap (and Uniswap compatible) smartcontract without using native l1 gas. It will NOT be possible to use it without native l1 gas when using Uniswap frontend.

   3. It will be possible to use any contract using well-defined gas-less standards like ERC2771

   4. It will be possible to construct a (Gnosis) Safe-like contract for a user and power any external action by this Safe without using L1 gas.

4. Abstract away L1 fees and CWEB for L1 native transactions for non-Coinweb enabled L1 tokens by using L1 - Coinweb L2 dex to exchange L1 token for CWEB.

Terminology around wrapping

The term wrapping is used in several different contexts, below is a clarification for this document

Common usage of the term wrapped coins or tokens:

Typically a wrapped coin is a representation of a coin or token from one chain that can be used on a different chain. The best example of this is probably Wrapped Bitcoin that is an ERC20 token on the Ethereum blockchain, where one Wrapped Bitcoin (WBTC) on the Ethereum chain represents one native Bitcoin on the Bitcoin chain. There are several ways that the wrapping mechanism can work. It can be done using bridges and smart contracts, or it can be done more manually. In the case of WBTC it works as follows: The WBTC ecosystem consists of custodians, merchants and customers. Merchants buy and sell Bitcoin and WBTC between Custodians and customers. The custodians hold native Bitcoin in custody and also mint and burn WBTC according to the amount of native Bitcoin they hold in custody. The following processes happen when customers buy or sell WBTC (or something similar)

WBTC wrapping example

Customer wants to buy WBTC with native Bitcoin:

1. The customer requests to buy WBTC from a merchant and includes their Ethereum address in the request
2. The merchant verifies the customer and sends them a Bitcoin deposit address
3. The customer sends native Bitcoin to the merchant on the Bitcoin blockchain
4. The merchant sends the native Bitcoin to the Custodian and requests that the custodian mints the corresponding amount of WBTC on the Ethereum blockchain
5. !Wrapping happens here! The Custodian receives the Bitcoin on the Bitcoin blockchain and mints an equivalent amount of WBTC on the Ethereum blockchain
6. The merchant receives the newly minted WBTC on the Ethereum blockchain and sends it to the customers Ethereum address on the Ethereum blockchain.

Customer wants to sell WBTC on the Ethereum chain and receive native Bitcoin on the Bitcoin blockchain:

1. The customer requests to sell WBTC to a merchant and includes their Bitcoin address in the request
2. The merchant verifies the customer and gives them an Ethereum deposit address
3. The customer sends WBTC to the merchant on the Ethereum Blockchain
4. The merchant sends the WBTC to the custodian and requests to receive the corresponding amount of native Bitcoin on the Bitcoin blockchain
5. !Unwrapping happens here! The custodian receives the WBTC on the Ethereum blockchain and burns the WBTC
6. The Custodian sends the corresponding amount of native Bitcoin to the merchant on the Bitcoin blockchain
7. The merchant sends the native Bitcoin to the customers wallet

Wrapping/unwrapping with bridges. The above example of WBTC is a centralised solution. Decentralised solutions are typically implemented as bridges. These bridges work in much as the same way as the merchants and custodians in the WBTC example. But instead of merchants and custodians, the system is made of smart contracts that can lock and mint or burn and mint tokens on the source and destination blockchains. The locking/burning/minting in the smart contracts are controlled by nodes that have to sign for the smart contracts to execute the wrapping and unwrapping. Typically, these nodes have provided staked collateral that is slashed in case they misbehave.

Coinweb's different ways wrapping/unwrapping

• dApp wrappers:

  • These are interfaces that makes it easier for the users to interact with L1-dApps and pay in the dApp token
  • Consists of:
    • Visual elements within the game UI, for example iframes or data fetched from L1 blockchain or API
    • Transaction composer
      • Creates the necessary L1 and or L2 transactions
        • Exchange dApp token for L1 or L2 to pay for gas
        • Exchange the dApp token to the token for payment
        • Send the payment transaction on behalf of the user
    • Interface with Coinweb wallet-lib
    • Interface with third party wallets

• Coinweb wrapped tokens:

  • Can be both L1 tokens wrapped as Coinweb L2 tokens and Coinweb L2 tokens wrapped as L1 tokens (depending on which is defined as the source of truth)
    • For example, if Bitcoin is wrapped as an Coinweb L2 token, Bitcoin would be the source of truth and the Coinweb L2 token would be wrapped Bitcoin
    • If the Coinweb token is issued as the main token for a dApp, it is a blockchain agnostic token and can be wrapped down to various L1 blockchains. In this

Sequence diagrams for the different options

Reference to EIP's Dynamic checks

• Address properties, either include in invoice or query through L2
• Functionality like lightningnetwork with Reactive smart contracts as watchtower
• Does the sender address have L2 tokens?
• Is the receipient willing to pay the fees?
• Fee substitution calculated in L2 smart contract

Example use case Web3 Game

The following use cases can to a certain extent be combined and used simultanously to leverage off existing user bases and Web3 tools while also benefitting from Coinweb platform advantages.

Example 1 shows how a typical user experience without Coinweb improvements is often fractioned between different dApp interfaces and other ecosystem services. This is reducing valuable "screen-time realestate" from many Web3 dApps and games. This is especially critical for the onboarding of new users, that often have to learn to use several different applications to obtain the necessary Game and gas tokens to interact with the game.

Existing Web3 solutions and wallets improved by Coinweb

Coinweb gas-fee abstraction can be used with existing Web3 solutions and be kept invisble to the user. The user need only interact with the game token issued by the Web3 Game application. The game token is seamlessly exchanged for gas tokens and other tokens necessary to interact with other dApps. While still providing significant gas savings, a deeper integration with Coinweb enables a much higher level of gas savings and more advanced game logic. If the Web3 dApp uses proxycontracts, retrofitting these solutions are easier. In some cases, where meta transactions are already supported, retrofitting can potentially be done without changes in the L1 contracts. Example of intergration without gas-abstraction https://li.fi/knowledge-hub/planet-ix-integrates-li-fi-cross-chain-swap-widget/

Improved gas-fee abstraction for L1 dApps using the Coinweb layer L1 - L2 DEX

The below solution shows how gas fee abstraction can improve the user experience for games using existing Web3 wallets and L1-encoded tokens. By using wrappers around popular dApps, the users can interact with these dApps only using the issued token for the specific dApp they are using without leaving the dApps UI. This solution takes advantage of network effects of existing wallet and dApp ecosystem while at the same time using Coinweb high computation capacity to cost-optimise the exchange transactions necessary to abstract away the gas-token usage for the user.

All L1 transactions in the first example are signed by the user and does not require L2 - L1 bridging

Combining gas-fee abstraction with L2-L1 bridges for frictionless experience across different dApps and blockchains

By adding L2 - L1 bridges, the gas fee abstraction model can be expanded to include multiple blockchains.

Coinweb issued L2 tokens and Coinweb wallet

By using Coinweb as the issuing platform for the game token, additional benefits such as compute-intensive and high transaction volume dApps can be implemented while still supporting seamless interaction with existing L1 blockchains and dApps.

What are the advantages of a more integrated wallet solution vs an all purpose Web3 wallet such as Metamask?

Hybrid solutions

Hybrid Web3 dApps would support both Coinweb native interaction as well as traditional Web3 interaction on L1 with common Web3 wallets such as Metamask etc. Interaction level and type could vary between different blockchains and dApps.

Metamask signing Coinweb transactions

In this case, the Web3 dApp frontend would integrate the Coinweb wallet library and use that to compose transactions. These transactions would be signed by Metamask.

Is it possible to show Coinweb L2 token balances in Metamask? Yes

https://ethereum.org/en/developers/apis/json-rpc/#eth_getstorageat

It is possible to create an interface that will make Metamask treat Coinweb as an instance of an Ethereum based blockchain (give it a chain-id)? Support Ethereum compatible JSON API. https://ethereum.org/en/developers/apis/json-rpc/ Yes

Coinweb transactions can be signed using Metamask with this function: eth_signTransaction https://ethereum.org/en/developers/apis/json-rpc/#eth_signtransaction

Coinweb L2 standalone solution (bridgeless)

Required components

This section breaks down the different components that are used in the above solutions. Not all components will be necessary for all solutions

Wrappers for L1 dApps

These are wrappers that can be used for L1-gas fee abstraction and for L2 dApps and tokens to interact with L1 dApps. These wrappers can be implemented to support both Coinweb compatible wallets and existing Web3 Wallets.

Front end

The front end could be implemented as replicas of the L1-dApp frontends incorporated into the Web3 dApp UI, or have custom skins fitting the rest of the UI elements. They could also be iframes, exposing certain elements of the original L1 dApp frontend but with user interaction elements implemented in the wrapper.

• Some dApps such as Opensea already provide API access. Opensea requires that projects apply for an API key. This API key comes with rate limits and some requirements for usage such as linking back to Opensea
• Also Uniswap and Pancakeswap provide a APIs that can be used to fetch elements.

Web3 interface

The Web3 interface would make it possible for existing Web3 wallets to be used to interact with Coinweb dApps, including the Coinweb Wrappers for L1 dApps. It would also enable Coinweb tokens to be added to Web3 wallets such as Metamask. Coinweb would need to implement an interface that supports the necessary function from this RPC API. https://ethereum.org/en/developers/apis/json-rpc/ It also requires an interface that translates between the Coinweb structure and the Ethereum structure. This can be application specific.

Smart contracts can support different interfaces to simulate the Ethereum interface.

Coinweb-Ethereum merged addresses (DAO)

Requires an additional contract like the current ESDCA contract, where both the Coinweb address and the Ethereum address can sign transactions (they are derived from the same pubkey)

L1 funded gas-fee abstraction

The easiest implementation of this is that the wallet app signs two transactions, one to the main destination and one to our broadcaster or an in-between mechanism that will be (at least at some stage) exchanged for L2CWEB to pay for the gas fees. (This could be a simple L1->L2 DEX, where a bidder defines a price for the L1 token in L2 CWEB and releases that to the broadcaster when the L1 tokens have been transferred to the bidders L1 address) We need a mechanism to estimate the actual value of the L1 token vs CWEB, so that the broadcaster can:

1. Calculate the L1 transaction cost for both transactions
2. Add enough margin to account for price fluctation and profit margin
3. Inform the user of the transaction cost nominated in the L1 token

L1 -> L2 DEX

Coinweb optimized L1 contracts

These smart contracts must decouple msg.sender from the signer, so that the signer of the transaction does not have to pay the gas fees. There must be a separate signature check in the L1 smart contracts that checks the signature within the contract. The best approach is to follow the same pattern as the most popular dApps such as Uniswap etc. to remain compatible. There are several EIP's to follow here related to meta transaction and gas fee payments by third parties. These should be optimized without losing compatibility with other L1 dApps. Also, optimisatio for batched transfers etc, to reduce overall gas consumption.

Retrofitting and upgrading

Users change to smart contract addresses - complexity moderate

If the users change their addresses to smart contracts, each user address could allow gas-fee abstraction while the underlying L1 contracts could remain the same. Users could choose if they wanted to continue to use their existing EOA addresses directly or change to the smart-contract addresses. Drawback: Smart contract addresses consume more gas than EOA addresses

Contract migration - complexity high

This would mean a full new deployment of the L1 contract(s). The state from the old contract can be copied to the new contract, but users would have to update the contract addresses in their Web3wallets and all contracts that interacted with the old contract would have to be updated. Also, exchanges would have to change the contract address for the token.

Proxy contracts migration - Complexity low

If the current L1 smart contract is deployed using a proxy contract, the old smart contract logic can simply be replaced by updating the contract address points to. This is using the delegatecall opcode (consumes 700 gas) which can call contracts that are stored in the proxy contract. The proxy solution can also be extended to call different contracts by using function selectors if the dApp smart contract is larger 24k (EVM limit) or for other reasons.