The Good Tech Companies - How To Make Cross-Chain Tokens Fungible Again: Part I

Episode Date: January 14, 2025

This story was originally published on HackerNoon at: https://hackernoon.com/how-to-make-cross-chain-tokens-fungible-again-part-i. This two-part report explores ERC-7281: a new proposal to make cross-chain tokens fungible. Check more stories related to tech-stories at: https://hackernoon.com/c/tech-stories. You can also check exclusive content about #ethereum-interoperability, #erc-20-tokens, #ethereum-ux, #ethereum-bridges, #blockchain-bridges, #ethereum-rollups, #2077-research, #good-company, and more. This story was written by: @2077research. Learn more about this writer by checking @2077research's about page, and for more stories, please visit hackernoon.com. The article examines the challenges of cross-chain token fungibility, focusing on issues like fragmentation and the problem of receiving non-fungible ERC-20 tokens during bridging. It explores existing approaches to cross-chain asset fungibility, analyzing their effectiveness and limitations, as well as bridging mechanisms like lock-and-mint, burn-and-mint, atomic swaps, and intent bridging. Additionally, the article highlights the potential of XERC-20 to solve these issues by introducing a unified framework that ensures fungibility for bridged ERC-20 tokens.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. How to make cross-chain tokens fungible again. Part 1 by 2077 Research. Hashtag introduction The modular maxis say the future of crypto is a million, or more, interconnected domains and users hopping between blockchains like Alice Traipsing through Wonderland. Why stick with one chain if you can access cutting-edge tech, novel applications, moonshot returns on st cutting-edge tech, novel applications, moonshot returns on staking, liquidity provision, high performance, and ultra-low transaction fees on other blockchains? But moving between blockchains is much more complicated than

Alice's trip through Wonderland, primarily due to limitations inherent in current approachesto blockchain interoperability, e.g. cross-chain bridges. In particular, cross-chain bridges today are either insecure, $2.5b plus lost in bridge hacks, slow, expensive, or limited in functionality, or display a mix of properties from the list. Other issues plaguing the bridging industry are more subtle but still enough to turn the modular maxis dream of a multi-chain ecosystem into a nightmare for users and developers. An example of this is how fungible tokens, like ERC-20s, become non-fungible when bridged to different chains via various cross-chain protocols hence hurting its features as a transferable asset. In this article, we will

explore a solution that seeks to preserve token fungibility across chains regardless of where a token's origin contract exists. ERC-7281. Sovereign Bridge Tokens. ERC-7281 extends ERC-20, the de facto standard for creating fungible tokens in Ethereum, to enable the minting and burning of canonical representations OF ERC-20 tokens on remote domains by multiple bridges approved by token issuers. This ensures that users bridging an ERC-20 token receive fungible versions of the token at the destination, i.e. two tokens can be exchanged one-to-one, even when tokens are sent cross-chain via different routes, bridges. Importantly, protocols that adopt ERC-7281 maintain control of bridged tokens unlike the status quo where the bridge controls a bridged token and can rate-limit minting operations

to reduce exposure in the event of a bridge failure. Let's use USDC as an example of infungibility among in theory identical ERC20 tokens across different chains. In Ethereum Layer 2, L2, networks, such as Arbitrum, Base, Optimism, it's common to use the canonical bridge to move popular ERC-20 tokens from the Ethereum L1 to these chains. These versions of L1 originating L2 tokens are commonly called just bridged, insert token name. In the case of USDC, the common symbols are USDC, E, USDC, B, and so on. Over time, Circle expands its USDC deployments to other chains, including L2s, where USDC is already live via the canonical bridge.

Even though these two tokens are minted by the same entity and have the same price they're technically different infungible tokens thus are not interoperable while native usdc can be bridged via circle cctp bridge the bridged usdc can only be bridged back to the l1 via the canonical bridge erc7281 fixes this by introducing an ERC-20 extension where the deployers of the token can assign and parametrize different sources of bridging for it. In the example above, Circle could deploy a universal USDC token on all L2s, where the canonical bridges E, G, Circle Mint, Circle CCTP, and other approved bridges are all assigned as capable of minting the tokens

according to their logic. To minimize the risks of minters getting hacked, the deployer can limit how many tokens each minter can mint and burn in the specific time period, with more reliable bridges, such as the canonical L2-1, having higher limits, and bridges with centralized consensus having lower ones. While ERC-7281 isn't the first attempt at creating fungible cross-chain tokens, it fixes problems associated with previous proposals, such as vendor lock-in, loss of sovereignty for token issuers, high costs of bootstrapping liquidity for bridge tokens, infrastructure overhead, and increased exposure to bridge failures. This two-part report

will examine the rationale for introducing a sovereign bridge token standard and provide a comprehensive overview of THERC-7281, also known as XERC-20, specification. We'll also discuss the positive benefits and potential drawbacks of implementing ERC-7281 for users, developers, infrastructure providers, and other actors in the Ethereum ecosystem. A refresher on blockchain bridges. Before diving into the problem of non-fungible bridged tokens, it helps to understand why bridged tokens exist in the first place. This, in turn, requires understanding the motivation for an operation of blockchain bridges, since bridge operators are the ones responsible for creating bridged token versions. A bridge is a mechanism for transferring information

between blockchains. Besides purely monetary information, bridges can pass any useful information such as token rates and smart contract state on other chains. However, transferring assets, tokens, from one chain to another is the most common use case for users interacting with a bridge today. Approaches to facilitating cross-chain asset transfers vary, but token bridging workflows usually follow one of three high-level patterns. Lock and mint bridges A user wants to bridge a token from its native or home chain, where it was initially issued, to another chain. The two blockchains aren't interoperable as each chain implements different architectures and protocol designs, which prevents

the user from transferring tokens directly from a wallet address on chain A to a wallet address on chain B. The bridge operator escrows tokens deposited by the user on the origin chain in a smart contract and creates a wrapped representation of the native token via a token contract deployed at the target chain when the user wishes to bridge in the reverse direction destination chain right pointing arrow origin chain they return the wrapped tokens to the bridge on the destination chain which verifies this according to the logic in the bridge e g zk proofs are an external quorum and releases the original tokens from escrow on the home chain. Backslash dot burn and mint bridges instead of locking tokens in escrow.

This approach burns, destroys the tokens on the source chain. The bridge then mints an equivalent amount on the destination chain. For the reverse trip, the bridge tokens are burned on the destination chain before new tokens are minted on the source chain. This the reverse trip, the bridged tokens are burned on the destination chain before new tokens are minted on the source chain. This maintains the total token supply while enabling cross-chain transfers. Atomic swaps this approach directly exchanges assets on the source chain for assets on the destination chain with another party. Atomic swaps work via mutually locking funds with the same secret value to unlock them, which means that if on any side the secret was revealed, it can also be revealed on the other. This gives the swaps the atomicity property. Atomicity means that the swap either completes

fully, on both sides, or not at all, preventing fraud or partial, failed transfers. The first approach, lock and mint, is currently the most common. The equivalency in value between a native token and its corresponding wrapped representation minted by a bridge is what allows users to transfer assets cross-chain and USEA token on a separate chain from where it was initially issued. However, new designs, such as intent-based bridging, have become quite popular. Intents allow users to express desired outcomes for transactions, swap 100 USDC for 100 DAI, instead of outlining specific steps for achieving outcomes. Intents have emerged as a powerful UX unlock as they greatly simplify the on-chain

experience for people and make crypto easier to use, particularly when paired with chain abstraction solutions. Cross-chain intents allow users to transfer tokens between chains without worrying about the underlying complexity of bridging. In intent-based bridges, users deposit funds on the source chain and specify their desired outcome on the destination chain, their intent. Specialized operators called fillers or solvers can fulfill this intent by sending the requested tokens to the user on the destination chain in advance. The operators then prove the transfer occurred to claim the locked funds on the source chain as reimbursement. Some intent-based bridges leverage lock and mint mechanisms under the hood. In this case, the bridge mints wrapped tokens that are sent either to the filler

who fulfilled the user's intent or directly to the user if no filler stepped in. While intent-based bridges add an extra layer of efficiency through their solver network, they still fundamentally rely on the same principles as traditional lock and mint bridges. We can think of each wrapped token, whether created through traditional or intent-based bridging, as an IOU from the bridge operator promising to release on amount of the underlying token from the escrow contract. The value of these wrapped assets directly correlates with the bridge operator's perceived capacity to process requests from holders to withdraw native tokens escrowed on the token's home chain. The bridge authorized to lock the underlying tokens on the source chain and mint their wrapped representations on the destination chain ensures that the token's total supply

remains constant. For one unit of the underlying token, exactly one unit of the corresponding wrapped token is minted, and vice versa. If an application accepts a wrapped token as a medium of exchange or uses wrapped assets as currency, the application's developers and users trust the bridge provider to secure the real assets backing the wrapped token. Why do we need bridges? The ability to transact with a synthetic version of an asset on a remote chain, enabled by bridges creating representations of the asset, is a powerful feature and allows developers and users alike to utilize the benefits of cross-chain interoperability. Some of these benefits include access to more liquidity, exposure to new users, and flexibility for users, who can interact with favorite apps from different chains without friction. To better understand how this works in practice and why it matters for both developers

and users, let's examine a concrete example using a fictional decentralized exchange called BobDEX. This example will demonstrate how wrapped tokens enable cross-chain expansion while highlighting both the benefits and potential complications that can arise. BobDEX is an automated market maker, AMM. Exchange that Bob created on Ethereum to enable trustless swaps between different assets. BobDEX has a native token, $BOB, which doubles as a governance token and an LP reward token. In the latter case, BobDEX issues Bob tokens to liquidity providers, entitling users supplying liquidity to a pool to a percentage of fees paid by DEX users swapping assets deposited in the pool.

BobDEX's market share has grown significantly, but Ethereum L1's limitations shinder further growth. For example, some users don't want to use BobDEX on Ethereum due to high gas fees and transaction delays. Similarly, other users wish exposure to the price of $Bob tokens without having to hold native $Bob tokens on Ethereum. To solve the problem, Bob deploys a version of Bob DEX on Arbitrum, a low-fee, high-throughput layer 2, L2, rollup, and deploys a wrapped version of the Bob token, WBOB, on L2 via the Arbitrum Ethereum bridge. Bob DEX on Arbitrum is identical to BobDEX on Ethereum, except it uses WBOB, not native Bob tokens, for LP rewards and governance.

The difference in application tokens doesn't make a difference from the perspective of users. providers interacting with Bob DEX on Arbitrum. Since WBOB tokens are backed by actual Bob tokens held in the Arbitrum Ethereum bridge, WBOB token holders can easily swap for native Bob ERC-20 tokens on Ethereum by interacting with the bridge contract. The situation is a win-win for Bob and users. 1. Bob can attract more users, especially users who want low gas fees and fast transaction confirmations when trading on Bob DEX. 2. LPs can earn rewards from supplying liquidity to Bob DEX without dealing with Ethereum's high gas costs and long confirmation times. 3. Hodlers can buy WBOB tokens on the market to profit from changes in the price of Bob tokens without interacting

with the Bob ERC-20 contract on Ethereum. The benefits of bridging also extend to enhancing composable innovation and unlocking new use cases that leverage the liquidity of a bridged token. For instance, Alice can create a lending protocol called Alice Lend on Arbitrum that accepts WBOB as collateral from borrowers to expand the utility of WBOB and create a new market for lending and borrowing. Lenders supplying liquidity to Alice Lend are certain of receiving deposits. If AUSER defaults on a loan, Alice Lend automatically auctions WBOB tokens deposited as collateral to reimburse lenders. In this case, buyers of liquidated WBOB collateral assume the role of LPs on BobDEX

and have the same guarantee that WBOB tokens can be exchanged one-to-one for original Bob tokens. Cross-chain bridging in its current form has provided a workable solution tonesharing interoperability between previously siloed Ethereum L2s and facilitating novel applications, e.g. cross-chain lending and cross-chain DEXs. But the bridging ecosystem is currently grappling with limitations that enter further growth, such as the non-fungibility of cross-chain tokens. We'll explore this problem in detail subsequently. Why do bridged tokens become non-fungible? The lock and mint bridging workflow described previously looks simple on paperbit, in reality, requires a lot of engineering and mechanism design effort to work correctly.

The first challenge is ensuring that wrapped versions of a bridged token are always backed by native tokens locked on the source chain. If an attacker mints representations of a token at a remote chain without depositing native tokens at the source chain, it can render the bridge insolvent by swapping, fraudulently minted, wrapped tokensiting native tokens at the source chain, it can render the bridge insolvent by swapping fraudulently minted wrapped tokens with native tokens on the home chain and preventing legitimate users who deposited in the bridge contract before minting wrapped tokens from withdrawing deposits. The second challenge is more nuanced and derives from the nature of bridged tokens. Two representations of a token minted by bridge providers at the same remote chain cannot be exchanged one-to-one for another. We can use another example of two users trying to exchange tokens bridged through different

routes to illustrate this aspect of the problem associated with moving tokens across chains. Alice bridges USDC from Ethereum to Arbitrum via the canonical Arbitrum bridge and receives 200 USDC E on Arbitrum, while Bob bridges USDC to Arbitrum via Axelar and receives 200 AXL USDC on Arbitrum. Alice and Bob enter an agreement for Alice to send 200 USDC to Bob, in exchange for 200 USDT, so that Bob can withdraw 400 USDC to Ethereum. Bob tries to withdraw 400 USDC via AXL USDC and only receives 200 USDC, along with a message explaining that the bridge only has 200 USDC it can give Bob. Bob is confused as the wrapped ERC-20 tokens are supposed to be fungible and shouldn't exhibit disparities that prevent anyone from exchanging erc 20 tokens one-to-one on any application bob learns a hard lesson about

cross-chain bridging fungible erc 20 token doesn't always mean you can exchange this token one-to-one with other erc 20 tokens across applications bob's attempt to do risky business with Alice, risky since Alice may not return the tokens, goes spectacularly wrong. Why can't Bob withdraw 400 USDC if he and Alice received wrapped versions of the same underlying asset on the destination chain? You'll recall we mentioned THAT tokens issued on different chains are incompatible, so the representation of a native token issued on a non-native chain is an IOU from the bridge promising to pay back an amount of the native tokens, depending on how much is left, when the user wishes to bridge back to the token's native chain. The value of every bridged token is

thus tied to the bridge provider responsible for holding deposits on the home chain and minting representations on the destination chain. Bob's bridge provider can only pay Bob 200 USDC as that is the amount it has funds to cover from its deposit. Alice's 200 USDC cannot be withdrawn through Bob's bridge provider as it never received the deposit or issued an IOU to Alice. Alice must withdraw her locked USDC from the Arbitrum on Ethereum and bridge through Bob's provider before Bob can access the remaining tokens. Bob and Alice's dilemma points to a problem with bridging between domains where multiple non-fungible representations of an underlying asset are minted by competing bridge

providers. The other one problem with different ERC-20 representations of the same asset is that they can't be traded in a single liquidity pool. Using the previous example, if we have AXL USDC and USDC E on the chain and want to swap them into ETH and vice versa, we must deploy two liquidity pools, ETH, AXL USDC and ETH, USDC E. This leads to a so-called liquidity fragmentation, probum, a situation where the trading pools have smaller liquidity than they could otherwise have because there are multiple pools that suit essentially the same trading pair. The solution is to have a single, canonical, version of a token circulating on the destination chain so that Bob and Alice can exchange tokens without each person withdrawing from the bridge at the source chain. Having a canonical token per chain also benefits developers,

as users can quickly move between ecosystems without dealing with issues around token liquidity. So, how do we go about implementing canonical versions of a token on each chain it expects to be used on and transferred between? The next section explains some of the popular approaches to creating canonical tokens on multiple chains. Implementing canonical tokens across different chains. Creating a canonical token per chain is not straightforward, and multiple options exist with varying trade-offs and advantages. When creating a canonical token per chain, we usually need to think about who to trust about the existence of IOUs backing the value of a particular token.

Suppose you are the creator of a token and you want it to be usable and transferable across different chains without running into issues around fungibility. You have four options. 1. Mint canonical tokens via canonical roll-up sidechain bridges. 2. Mint canonical tokens via a third-party bridge provider. 3. Mint canonical tokens via a token issuer bridge. 4. Direct multi-chain issuance with atomic swaps. The first three options rely on various bridging mechanisms to facilitate cross-chain movement of tokens. However, as a token creator, you can also choose Edo bypass bridging entirely by issuing the token natively on each supported chain. Under this approach,

rather than relying on wrapped tokens or bridge infrastructure, you maintain separate but coordinated token deployments across chains, with atomic swaps enabling trustless exchange between chains. This approach requires sophisticated infrastructure to maintain liquidity across chains and facilitate atomic swaps, however. The complexity of managing multiple native deployments has historically limited this approach to larger protocols with substantial technical resources. 1. Mint canonical tokens via canonical rollup, sidechain bridge If a chain has a canonical, enshrined, bridge, you can assign the right to mint representations of your protocol's token for users who want to bridge from the native chain.

Transactions routed through the chain's canonical bridge, deposits and withdrawals, are typically validated by the chain's validator set, which provides stronger guarantees that deposits on the home chain credibly back all minted representations. Although the canonical bridge is minting the canonical representation of a token, other representations will still exist. This happens simply because canonical bridges often have limitations that prevent them from offering users the best experience. For example, bridging from arbitrum optimism to Ethereum via the rollups canonical bridge incurs a 7-day delay as transactions must be validated by verifiers and possibly

disputed by a fraud-proof, if invalid, before the roll-up settlement layer, Ethereum, settles a transaction batch. Roll-up users who want quicker exits must use other bridge providers who can assume ownership of pending roll-up exits and provide upfront liquidity on the user's desired target chain. When such bridges use the traditional lock and mint model, we end up with multiple wrapped representations of a token issued by different protocols and face the same problems described previously. Sidechains with independent validator sets have lower latency as withdrawals are executed once the sidechain's consensus protocol confirms a block containing a withdrawal transaction. The Polygon POS bridge is an example of a canonical bridge connecting a sidechain to different domains, including Ethereum rollups and Ethereum mainnet. Note, we refer to the original Polygon POS chain,

not the planned Validium chain that will use Ethereum for settlement. Polygon will become an L2 once the switch from a sidechain secured by external validators to a Validium secured by Ethereum consensus is complete. However, sidechain bridges also share a weakness with rollup canonical bridges. Users can only bridge between a pair of connected chains. They cannot bridge two-throw blockchains using the canonical bridge. For example, you cannot bridge from Arbitrum to Optimism today using the Arbitrum bridge or bridge from Polygonto Avalanche via the Polygon POS bridge. 1. Mint canonical tokens using liquidity bridges relying on a rollups native bridge for moving canonical tokens comes with several issues, such as poor liquidity and delays on asset movement.

Protocols work around this issue by working with liquidity bridges to facilitate speedy withdrawals and low-latency bridging. Under this arrangement, approved liquidity bridges a. Mint wrapped representations of a protocol's token on the source chain. b. Swap wrapped tokens for the canonical representation at the destination via a protocol-owned liquidity pool. The canonical representation of the token on the destination chain is usually the version minted by the canonical sidechain, rollup bridge, although exceptions exist, as we'll see later. For example, the canonical version of USDT on Optimism is OPUSDT minted by the Optimism bridge. Each liquidity bridge functions like a DEX with an automated market maker, AMM, to execute swaps between pairs of assets deposited in different liquidity pools. To incentivize

liquidity provision, AMM pools share a portion of swap fees to holders who lock up canonical tokens in the pool contracts. This is similar to Uniswap's model, the only noticeable difference is that asset pairs are usually the liquidity bridges representation of a token against the canonical representation. For example, a user that bridges USDT to Optimism via HOP will have to swap HUSDT on Optimism via the HUSDT, OPUSDT pool. The workflow for bridging via liquidity bridge will look like this. Lock native tokens on source chain. Mint bridge representation of native token on target chain. Swap bridged representation with canonical representation on target chain via AMM pool. Send canonical tokens to the user. This process is

similar for all liquidity bridges, across, seller, hop, stargate, etc. However, it is usually abstracted away from the end-user, particularly by solvers, fillers, and will feel like a single transaction despite involving many moving parts. When bridging back to the source chain, the user burns the canonical representation or swaps the canonical token with the bridge representation via AMM before burning that representation and providing the proof of burn receipt. Once confirmed, the user can withdraw the native tokens locked at the beginning. Just like the previous operation, the dirty details of moving tokens back to the original chain is hidden from the user and managed by solvers. Liquidity bridging is excellent,

mainly because it fixes the problem of latency in rollup bridging. For example, Hop allows specialized parties known as bonders to attest to the validity of a user's withdrawal transaction on L2 and front the cost of withdrawing from the rollup's L1 bridge. Each bonder runs a full node for the L2 chain and can determine if a user's exit transaction will eventually be confirmed on L1, reducing the risk that a user initiates a fraudulent withdrawal and causes losses for the bonder. Liquidity bridges also enable users to move between more chains, unlike canonical bridges. For example, Hop allows users to bridge between Arbitrum and

Optimism without having to withdraw to Ethereum first. Just like FastL2 right-pointing arrow L1 bridging, FastL2 right-pointing arrow L2 bridging requires bonders to run a full node for the source L2 chain to confirm withdrawals before fronting the cost of minting tokens for AUSR on the destination L2 chain. This enables more composability between rollups and drastically improves the user experience, as users can move tokens across rollups without issues. But liquidity bridging also has downsides that affect the utility of using A-chain's enshrined bridge to mint the canonical representation of a token on ANL2 per leader 1 chain. We discuss downsides of liquidity-based bridging in the next section. Drawbacks of liquidity bridges 1. Slippage

Slippage is a difference in the amount of tokens expected and received when interacting with an AMM. Slippage occurs due to AMM's pricing swaps according to the current liquidity in a pool. The pricing is such that equilibrium is maintained between the pool's balance of each asset in a pair after a swap is complete, which can change between the time a user initiates a trade and the exchange is executed. Low liquidity for bridged assets can also increase slippage. If the pool doesn't have enough liquidity to rebalance one side of the pool, a large trade may shift the price by a large margin and result in users executing swaps at higher prices. Arbitrageurs are expected to help correct disparities between pools trading the same asset but may be discouraged from arbitrage trades involving tokens with low trading activity

value. This also impacts developers building cross-chain applications as they must account for edge cases in which slippage occurs. The user cannot complete a cross-chain operation due to receiving lower amounts of a token on one or more destination chains. Applications like bridge aggregators, who cannot know if a liquidity bridge will have enough liquidity to cover a swap at the destination chain without slippage, work around the problem by specifying a maximum slippage tolerance and using that to inform quotes provided to users. While this prevents transaction reverts, users always lose some percentage of the bridged token, irrespective of the liquidity in a bridge's AMM pools.

2. Liquidity C-O-N-S-T-R-A-I-N-T-S-A Fundamental challenge with liquidity bridges is the absolute requirement for sufficient liquidity on the destination chain. Unlike traditional lock and mint bridges where token minting is backed directly by locked assets, liquidity bridges depend on available tokens in AMM pools to complete cross-chain transfers. When liquidity falls below critical thresholds, the entire bridging mechanism can effectively cease to function. Bridge operations can halt entirely if liquidity drops too low,

preventing users from completing their intended transfers. Users may be forced to split large transfers into smaller transactions to avoid depleting pool liquidity. During periods of high volatility or market stress, liquidity providers may withdraw from pools, precisely when bridge functionality is most needed. The bootstrapping of new token pairs becomes particularly challenging, as significant initial liquidity is required to make the bridge operational. The liquidity requirement creates a circular dependency. Bridges need substantial liquidity to function reliably, but attracting liquidity providers requires demonstrating consistent bridge usage and fee generation. This chicken-and-egg problem

is particularly acute for new or less frequently traded tokens, which may struggle to maintain sufficient liquidity across multiple chains. 3. Misaligned INCENTIVESA Liquidity Bridge is helpful to the extent it can cover swaps from the bridged representation to the canonical token on the destination chain without users incurring excessive slippage. The gas costs of interacting with the bridge also determine a liquidity bridge's value from a user's perspective. Thus, bridge aggregators and project teams, issuing a token, prioritize bridges based on the amount of liquidity and transaction costs. While this ensures users bridging a project's tokens or using a bridge aggregator to send tokens cross-chain have better UX, selecting bridges based on liquidity places bridges

unable to spend on liquidity provider, LP, incentives at a disadvantage. Furthermore, selecting bridges based on pure transaction fees biases the competition in favor of bridges that adopt a centralized approach to reduce operational costs and can charge lower fees on bridging transactions. In both cases, bridges aren't competing on arguably the most important metric, security. Liquidity-based bridges also disfavor long-tail assets with lower TRADINGACTIVITY, making them less likely to attract LPS. Issuers of long-tail tokens, OR new tokens with low bridging volumes, will either have to set up AMMPOOLSAND bootstrap liquidity to cover swaps of native tokens, bridged via ALIQUIDITYBRIDGE, against the canonical representation of the issuer's token OR

WORKWITHBRIDGE operators to increase financial incentives for LPS to supply LIQUIDITYFOR that asset. 4. Poor bridging UX liquidity bridges are an improvement on canonical bridges but aren't without X issues as well. besides enduring slippage on cross-chain swaps users may be unable to complete a bridging transaction immediately on the destination chain because the bridge doesn't have enough pool liquidity to cover trade with the canonical token on the destination chain bridges cannot know how much liquidity for an asset pair will exist by the time a user's message to swap tokens reach s destination chain so this edge case is mostly unavoidable users have two choices in this situation both suboptimal wait until the bridge

has enough liquidity to complete the swap and withdraw canonical tokens this is suboptimal because of the delay endured in bridging transactions and because a user cannot know if they'll receive the same amount of tokens quoted initially since pool liquidity can change arbitrarily in very short periods. Receive the bridge's proprietary token representation E.G.H.USDT for Hop Bridge. This is suboptimal as most applications will prefer to integrate with the canonical representation of a native token E.G.H.USDT minted by the Optimism Bridge and may not accept the user's wrapped asset. 2. Mint canonical tokens via a canonical third-party BRIDGEA multi-chain DAP can work around the issue of non-fungible bridge tokens by selecting a single bridge to mint canonical representations of the DAP's token on every chain where the DAP is deployed. As with canonical

bridges minting approved representations of a project's token, this approach requires mapping tokens minted on remote chains to the token contract deployed on the project's home chain, ensuring the token supply remains the same globally. The bridge provider must track the minting and burning of a token and ensure minting and burning operations stay in sync with the token supply on the home chain. Using a single bridge provider offers more flexibility for project teams, especially as third-party bridges are incentivized to support bridging between a broader range of ecosystems compared to canonical bridges that only connect to at most one chain. If a bridge exists on all chains where an application IS deployed, users can quickly move cross-chain without needing to withdraw back to the home chain. A bridge provider only has to ensure that the

tokens minted on destination chain A are burned before a user mints tokens on destination chain banned canonical tokens on chain B are re-mapped to the token on the home chain. The problem of non-fungible bridged tokens is also eliminated. Provided users bridge through the approved bridge provider, they can always exchange them one-to-one with other bridged tokens. This approach further fixes the problems of liquidity-based bridging in the canonical bridge model. Users don't suffer slippage on bridge transactions as the bridge provider doesn't have to convert its representation against a canonical representation via an AMM. The bridge provider's

token is the canonical representation of the bridged token on every domain. The value of these representations is pegged to the value of tokens locked by the bridge provider on the token's chain. Users suffer little to no delays on bridging as the bridge provider can mint wrap representations on the destination chain immediately after the mint message arrives at the destination. Developers can outsource managing multi-chain token deployments to bridge operators without worrying about bootstrapping AMM liquidity or liquidity provision incentive programs. Some examples of single bridge provider tokens in the wild include Layer Zero Somnichain Fungible Token, OFF, Axelers Interchain Token Service, ITS, Sellers Asset, and Multichains Any Asset. All examples are essentially proprietary tokens

and are incompatible with the representations of the same token sent via a different bridge provider. This subtle detail highlights some issues with this approach to handling bridge tokens. Namely the following, vendor lock-in-in. Loss of sovereignty. High exposure to bridge failures. Loss of tokens custom features on the target chains. Being limited to vendors supported chains. Inability to maintain the same token address on all desired chains, which may hurt user security or pose them vulnerable to phishing. Drawbacks of using canonical third-party bridges 1. Vendor lock IN Selecting a single bridge provider to mint canonical representations on one or more chains

exposes developers to the risk of vendor lock-in. As each bridge provider mints a proprietary representation compatible with only ITS infrastructure and integrated ecosystem projects, the single bridge provider model effectively locks a token issuer to a specific bridging service without the option to switch to another bridge in the future. It is possible to switch bridge providers, but the switching costs are high enough to discourage most projects from going this route. To give a rough idea, suppose a developer, whom we'll call Bob, has issued a token, Bob token, on Ethereum and chooses layer 0 off to mint canonical versions of Bob token on Optimism, Arbitrum, and Base. Bob token has a fixed supply of 1 million

tokens and bridged tokens minted via layer 0 account for 50% of the total supply of Bob tokens in circulation. The business arrangement smoothly proceeds until Bob decides users are better off bridging Bob tokens via competing bridge service, e.g. Axelar. However, Bob cannot simply up and say, I'm switching to Axelar it's to mint canonical representations of Bob token on Optimism, Base, and Arbitrum. Since off tokens and its tokens are incompatible, Bob risks creating headaches for both old users and new users as two Bob tokens potentially are not fungible, reintroducing the problem we described earlier. Moreover, applications integrated with Layer 0's version of Bob token cannot accept Axelers' version of Bob token as a substitute, which fragments liquidity for

Bob token on various chains where competing representations of Bob token co-exist. To make the transition possible, Bob needs to convince users to unwrap wrap representations of Bob token minted through layer 0 by sending a transaction that burns bridged off tokens and unlocks Bob tokens on Ethereum. Users can now switch to the new canonical representation of Bob token by locking tokens with Axelar on Ethereum and receiving canonical Bob tokens mapped to the token contract supply on Ethereum on the destination chain. This is both cost-intensive and incurs massive coordination and operational overhead for DAO project management teams, so sticking to the chosen provider is usually the safest option.

However, this leaves developers like Bob in a problematic position as vendor lock-in makes it impossible to switch if a bridge provider fails to uphold the terms of the agreement, has a limited feature suite, lacks expansive ecosystem integrations, offers poor UX, etc. It also provides bridges with near-infinite leverage. The bridge provider can do arbitrary things like rate limit users bridging Bob tokens without clear reasons, raise bridging fees, or even censor bridging operations. Bob's hands are tied in this case, as making a clean break from a faulty canonical third-party bridge is as complex as staying in the business relationship. 2. Loss of sovereignty for protocols

The concluding part of the previous section on vendor lock-in highlights another issue with using a canonical third-party bridge token issuers trade off control of canonical bridged tokens in exchange for greater convenience and ux improvements to use the previous example bob token on ethereum is entirely within bob's control as he controls the underlying erc20 token contract but bob token on optimismrum, and Base are controlled by Layer 0, which owns the off-contract that issues canonical representations of Bob token on those blockchains. While Bob might expect Layer 0 to align canonical representations with the original design of the native token, this may not always be the case. In worst-case scenarios, the behavior of Bob token on Ethereum may diverge

significantly from that of Bob token on Optimism because the bridge provider implements a radically different version of the token contract, creating problems for the protocol's users. This problem may also be exacerbated by principal-agent dynamics where the goals and interests of a protocol and the bridge provider diverge. 3. High exposure to bridge failures in the first approach, where tokens are bridged cross-chain through each chain's canonical bridge, the risk to the token issuer from an exploit affecting one bridge is contained to that bridge. For example, suppose a hacker manages to calm promise one liquidity bridge and mint infinite amounts of a wrapped token without depositing collateral. In that case, it can only withdraw up to the maximum liquidity available for the wrapped asset in liquidity

pools, e.g. Minting CUSDT on Optimism right-pointing arrow swap CUSDT for canonical OPUSDT right-pointing arrow withdraw OPUSDT to Ethereum via fast bridge right-pointing arrow exchange for native USDT on Ethereum. In the right-pointing arrow exchange for native USDT on Ethereum. In the third-party canonical bridge model, the risk to a token issuer from an exploit affecting the partner bridge is equivalent to the total amount of tokens an attacker mints on remote chains where the affected bridge has a deployment. This is possible because every canonical representation on all chains can be exchanged one- one for canonical tokens issued on other chains. Suppose an attacker compromises a third-party bridge on chain B and mints 1000 tokens, where the token is issued initially on chain A, without depositing collateral.

The attacker's tokens on chain B aren't mapped to the home chain contract, so it cannot withdraw from chain A still, it can bridge to Chain can exchange 1000 Chain B tokens for 1000 Chain C tokens. Remember, each cross-chain token is compatible and fungible as they originate from the Sainbridge service. The Chain C tokens are mapped to the home chain contract as they were legitimately minted by users that locked tokens on Chain A. The token's home chain. Allowing the attacker to burn tokens on chain C and withdraw native tokens on chain A and potentially complete the itinerary by exchanging the tokens via a CEX or fiat offramp. 4. Loss of custom token features

When using a canonical third-party bridge, token issuers often lose the ability to implement custom features or token behaviors that exist in their original deployment. This happens because bridge providers tend to use STANDA RDI ZEDERC 20 implementation contracts that may not support specialized functionality present in the original token implementation. Common token features like vote delegation, ZK, rebasing mechanisms, Steth, USDM, fee on transfer capabilities, meancoins, blacklisting and whitelisting functions, USDT, USDC, possible transfers, and special minting rules or permissions are often stripped away when tokens are bridged through a third-party provider, as the bridged version will typically use a basic ERC-20 implementation. This loss of functionality

creates inconsistencies in how the token operates across different chains and can potentially break integrations that depend on these custom features. The standardization of bridged tokens, while simpler from the bridge provider's perspective, effectively reduces the token's capabilities and can hamper the issuer's ability to maintain consistent token behavior across the entire multi-chain ecosystem of their application. Such issues can make cross-chain expansions a nightmare for developers and represent an obstacle to realizing the dream of apps living on multiple chains. 5. Limited supported chains token issuers become dependent on their chosen bridge provider's network coverage and expansion plans. If the bridge provider doesn't support a particular blockchain network that the token issuer wants to expand to, they face two

suboptimal choices. Wait for the bridge provider to add support for the desired chain, which may take a long time or never happen due to high costs of integration, e.g. zkSync error's EVM inequivalence that has led many dApps to never deploy on it. Use a different bridge provider for that specific chain, which reintroduces the problem of non-fungible tokens and liquidity fragmentation. This limitation can significantly impact a protocol's growth strategy and ability to reach new users on emerging chains. Bridge providers may prioritize supporting popular chains while neglecting

smaller or newer networks that could be strategically important for the token issuer. 6. Inconsistent cross-chain token token addresses Third-party bridge providers may deploy bridge tokens with different addresses on each chain due to peculiarities of their tech stack. For example, no support for CREATE2. Lack of address consistency, in turn, creates many UX problems. Security risks. Users must verify different token addresses on each chain, increasing the risk of interacting with fraudulent tokens. Integration complexity. Developers must maintain lists of valid token addresses for each network. Increased phishing risk. Bad actors

can more easily trick users with fake tokens since there's no consistent address to check against. These drawbacks, combined with the previously discussed issues of vendor lock-in, loss of sovereignty, and high exposure to bridge failures, highlight the significant limitations of relying on canonical third-party bridges for cross-chain token deployments. This understanding helps set the stage for why alternative solutions like ERC-7281 are needed to address these challenges in a more comprehensive way. 3. Mint canonical tokens via token issuer bridge IF a developer wants to maintain maximum control of cross-chain deployments of APROJECTx token, it can manage the issuance of canonical representations of the token on remote chains. This is described as trust the token issuer, as the value of every bridged representation of the token is tied to

tokens locked on the token's home chain by the protocol responsible for issuing the original version of the token on the source chain. For that approach to work, the token issuer must set up infrastructure to manage the minting and burning of. For that approach to work, the token issuer must set up infrastructure to manage the minting and burning of bridged tokens cross-chain, while ensuring global supply remains in sync via canonical mapping. Notable examples of canonical representations of a token issued by the token creator are MakerDeo's Teleport in Circles cross-chain transfer protocol, CCTP. Teleport allows users to move canonical DAI between Ethereum and various Ethereum rollups via fast path and slow path operations.

DAI is burned on one chain and minted on the target chain. CCTP functions similarly and enables cross-chain transfers of native USDC, issued by Circle, via a burn and mint mechanism. In both cases, the token issuer controls the minting and burning of canonical representations of a token. This approach offers complete control of bridged tokens for protocols, and it fixes the problem of non-fungible representations of the same token in the most effective way possible. Only one canonical version of the token, minted by the issuer at the destination chain, exists, which ensures users have the same experience using a token on every ecosystem the token issuer supports. With this approach, applications also benefit from the elimination

of liquidity fragmentation caused by unofficial, bridged representations of a protocol token floating in the same ecosystem. Developers can also build more robust cross-chain applications, e.g. cross-chain swaps and cross-chain lending, as canonical token issuer bridges allow for capital-efficient, seamless, and secure movement of tokens between chains. The downside to canonical token issuer bridges, however, is that this model is only feasible for projects with enough capital to cover the overhead of deploying a token cross-chain and maintaining infrastructure, oracles, keepers, etc., required to perform cross-chain minting and burning. This also has the somewhat undesirable effect of tightly coupling the security of bridged assets with the protocol's security model.

This relationship, between bridged versions of a protocol's tokens and the protocol's security is amicable since the safety of native tokens backing canonical representations already depends on the protocol's security so users and external developers aren't taking on new trust assumptions. This is especially true of stablecoin bridges operated by issuers like Circle and Maker. Now Sky users already trust stablecoin issuers to have enough assets to cover redemption of stablecoins for fiat currencies, so trusting the security of a stablecoin bridge isn't difficult. But it also represents a central point of failure, if the token issuer's bridge infrastructure is compromised, the value of all

canonical representations circulating in the multi-chain ecosystem is in jeopardy. This also implies that only centralized custodians, e.g. Circle in the case of USDC, can implement this model of issuing canonical bridged tokens. Final thoughts. As shown in this report, cross-chain asset fungibility is an important part of overlap interoperability with implications for the experience of moving between different chains. The ability of tokens to remain fungible when bridged to remote chains also impacts the developer experience as certain use cases depend on this feature. Different solutions have been proposed to solve the problem of infungible cross-chain tokens, many of which we've covered in this report. This includes minting canonical tokens via native,

enshrined, bridges, using a dedicated third-party bridge to mint canonical tokens across multiple chains, and using a protocol-owned bridge to facilitate movement of tokens and preserve fungibility. While these approaches solve specific problems, they fail to address all issues and using them to enable cross-chain asset fungibility requires some undesirable trade-offs. Can we find a better approach? The answer is yes. ERC-7281 is a new approach to cross-chain asset fungibility that mitigates trade-offs associated with existing approaches. Also known as XERC-20, ERC-7281 enables protocols to efficiently deploy canonical tokens on multiple chains without

trading off security, sovereignty, or user experience. ERC7281's unique design allows multiple, whitelisted, bridges to mint Canonical versions of a protocol's tokens on every supported chain while allowing protocol developers to dynamically adjust minting limits on a per-bridge basis. This feature solves many of the problems associated with historical proposals for multi-chain canonical tokens, including liquidity fragmentation, incentive alignment, UX concerns, bridge security risks, customizability of cross-chain tokens, and more. The next and final part of our two-part report on cross-chain asset fungibility will cover ERC 7281 in detail and explore how the XERC20 token standard can benefit developers and users.

We'll compare ERC7281 to other designs for multi-chain canonical tokens, explore XERC20's approach to multi-chain canonical tokens, and highlight considerations for protocols and developers looking to build on the standard. Stay tuned. Tip authors note. A version of this article was originally published here. Thank you for listening to this Hackernoon story, read by Artificial Intelligence. Visit hackernoon.com to read, write, learn and publish.