Solving Fungible Token Coloring — A Nerds Version

This document elucidates our design journey for Project ColorTrace, outlining the progression of our concepts and the formalization of the problem. Its purpose is not to serve as a technical reference. The complete technical accuracy of this document is not explicitly assured (refer to the whitepapers ColorTrace, ColorFloat) and it is primarily meant to communicate high-level ideas and the design space exploration.

Security is paramount at LayerZero Labs and we are unwavering in our commitment to finding the most practical, elegant, and secure designs for every protocol we develop. The following provides a largely chronological overview of our design exploration, offering insights into various details of ColorTrace that were omitted from the paper for the sake of brevity.

Defining the problem

Before we begin, we would like to briefly introduce the problem as we define it.

We define the token coloring problem to be the problem of (1) tracking which minter minted a token for fair burning, and (2) tracking the attribution of how many colored tokens have been minted by a given minter (i.e., a minter’s mint) in proportion to the global supply of tokens. The mint is stored on a primary chain, which can be thought of as a snapshot of the instantaneous circulation across all of the chains, including the primary and a collection of secondary chains. For literary purposes, we refer to the unique ID of a minter as its color, and refer to these colors using color names such as red, green, and blue. These colors will invariably be numeric identifiers in practice.

The most impactful part of this problem is the color tracking for fair token burning: if a user redeems a token, how do we identify which minter originally minted it? This problem seems incredibly simple at first glance, but is actually the well known and difficult Colored Coins problem. Applying the Colored Coins protocol to this problem would result in O(N) storage and O(N) compute for a system of N minters, and thus runs into scaling problems on blockchain. We not only present an O(1) solution to this problem, but also design a practical O(1) mechanism to allow crosschain transfers as well.

The two operations demanding meticulous implementation are transfer and remint. Transfer, a straightforward operation, entails sending tokens from one wallet to another within and between blockchains. Both operations are inherently O(N), and we present the first solution (lossy coloring) to the token coloring problem. Lossy coloring serves as the basis for the four algorithms we designed to solve token coloring: ColorFloat, ColorTrace, rho, and ColorAge. All four of these algorithms are complete and pareto-optimal and we believe that there is potential for all four algorithms to be used in future Web3 ecosystems. However, the Verified USD Foundation deemed ColorTrace to have the most desirable properties for USDV in particular.

On top of this, there are several intricacies of crosschain transfers caused by the asynchrony between source debit and destination credit that we also solve in order to design a complete omnichain solution.

Remint is more specific to the token coloring problem. Synchronously updating the mint across a network of multiple independent blockchains is impractical due to the prohibitive cost of crosschain messaging. Consequently, it becomes necessary to allow minters to make the decision of when changes in their color’s circulation are synchronized to the vault on the primary chain. The primary challenge of the remint operation is two-fold: firstly, the economic infeasibility of reminting every time the mint is updated, and secondly, the absence of ordering between remint requests due to the asynchrony inherent in the underlying crosschain network.

Laying the foundation: ColorFloat

In our initial approach, we introduced the concept of a float token, which can be conceptualized as a colored token that has been transformed into a colorless token (refer to the whitepaper for further details). These colorless tokens, in turn, are fungible and can coexist in the same balance as any other colored token. Each wallet is permitted to hold tokens of one color (lossy coloring) along with a quantity of float tokens. This allows for lossless encoding of one color, while the remainder is lossily encoded as float tokens. Beautiful in simplicity, lossy coloring is the baseline solution to the token coloring problem that we use as a foundation for both ColorFloat and all subsequent solutions.

In this algorithm, when blue tokens are sent to a wallet with a green balance, these blue tokens (or green tokens) can be encapsulated into float tokens before being amalgamated with the colored balance. Each token contract maintains a record of the number of tokens of each color that have been wrapped into float (referred to as the deficit list). Float tokens can be unwrapped into colors up to the deficit stored in the deficit list. This mechanism facilitates O(1) local transfers, although reminting and crosschain transfers become intricate.

ColorFloat exhibits several properties that may render it more advantageous than ColorTrace in certain applications. Primarily, the float token provides a distinct delineation in the attribution of tokens within a specific balance. This characteristic could prove valuable in a system that employs intricate (re)coloring rules to effectively encode domain-specific knowledge concerning the historical movement of a token. For instance, it could be useful in scenarios involving global color priority or determining whether a token has interacted with a specific application in the past.

Another advantageous characteristic of ColorFloat is that wallet balances can contain an arbitrary number (K) of colored balances in conjunction with a float token balance. As K approaches infinity, the algorithm approaches losslessness; this flexibility in controlling the degree of losslessness is a characteristic that is not particularly useful for USDV, but could be incredibly powerful in other applications.

Reminting entails the process of unwrapping float tokens into the minter’s designated color. This approach provides some limitations on minter behavior in that they can only remint at the time they are holding float tokens. For USDV in particular, the Verified USD Foundation deemed it a better minter experience to allow minters to accrue remint potential over time and remint large batches of tokens without having to hold all of them at once.

Concerning the first point, minters who generate a substantial volume of token movement but maintain a relatively small quantity of tokens at any given time are compelled to remint frequently. This scenario diminishes their capital efficiency, as the reduced ability to amortize transaction costs (including crosschain messaging) becomes a significant factor.

Expanding on the second point, minters face challenges in “protecting” their mint by simply holding a certain quantity of tokens. To prevent their mint from dropping below a specific threshold, minters must hold tokens of their own color. However, holding float tokens, despite having the same intrinsic value as a colored token, does not immediately contribute to reducing one’s deficit. This inherent contradiction in the nature of float tokens hints at a more fundamental shortcoming of the float token model — the fungible colored token, within this design, is not fully fungible from the minter’s perspective. This property, while unimportant in many applications, turned out to be somewhat important for USDV.

Crosschain transfers encounter similar limitations, as it is unsafe to transfer float tokens as-is between blockchains. Float tokens must be transferred along with a corresponding quantity of deficits, essentially necessitating the unwrapping of all float tokens before their transfer. This gives rise to two issues: nondeterministic gas and artificial transfer caps.

In this paradigm, the gas cost of sending tokens from chain A to chain B becomes nondeterministic. In the best case, 10 float tokens may be unwrapped into 1 color, while in the worst case, they may unwrap into 10 colors. This unpredictability in gas cost is arguably more problematic than the issues with reminting, as it directly impacts the user experience.

Additionally, constraints on crosschain message packet size impose a limit on the maximum number of colors that can be transferred crosschain. Consequently, the success of a transfer of, for instance, 1 million tokens from chain A to chain B is partially contingent on luck. In a fortunate scenario, the tokens may unwrap into a single color, enabling a successful transfer. However, in an unfortunate situation where the maximum number of colors per packet is, for example, 100, the transfer might be constrained to only 100 tokens. This not only adversely affects the user experience but can also severely curtail composability, as the number of transactions required to send tokens crosschain becomes practically unbounded.

Local and Global Mint

In an effort to address the lack of fungibility in the float token model, our subsequent evolution of the algorithm involved shifting the float token from a per-wallet quantity to a per-token contract quantity. We embraced a design where implicit float token wrapping and unwrapping are aggregated for minters to handle asynchronously. This adjustment not only improves the user experience but also offers a more efficient and streamlined approach for minters in the context of USDV. In essence, we increased the lossiness of the system in a way we deemed would provide a better user and minter experience. Taking the leap of faith to accept increased lossiness was one of the most important parts of this project, as it helped us broaden our vision of the problem as a whole and more fully explore the design space.

Each token contract stores two quantities: localMint and globalMint (referred to as colored and minted in the code). LocalMint is the instantaneous circulation of a given color within the local blockchain, and globalMint is the last value that was synchronized from the local chain to the primary chain vault.

In contrast to the previous approach of wrapping colored tokens into float tokens held in individual wallets, the refined strategy involves directly recoloring colored tokens during transfers. In this model, each wallet holds tokens of precisely one color. The recolorings are encoded as changes in localMint, with the variance between localMint and globalMint signifying either a deficit, subject to slashing during reminting, or a surplus, available for reminting against an opposing and equivalent magnitude of deficits. This adjustment streamlines the process, making it more direct and efficient.

This solves the problems with reminting, as surpluses can be globally accumulated over an unbounded period of time before the minter synchronizes them to the vault, and a minter holding a certain quantity of tokens guarantees that colored will never fall below that quantity. This limits the magnitude of the deficit on the local chain.

This solution effectively addresses the challenges associated with reminting. Surpluses can be globally accumulated over an unbounded period of time before the minter synchronizes them to the vault. Moreover, a minter holding a specific quantity of minted tokens ensures that the globalMint will never fall below that quantity, thereby limiting the magnitude of the deficit on the local chain. Consequently, the local and global mint model represents our first fully minter-fungible solution to the fungible token coloring problem.

DeltaZero

Continuing our exploration of colored and minted tokens, we came to the realization that, in practice, the only necessary bookkeeping for secure recolorings and crosschain transfers is the per-color difference between localMint and globalMint, referred to as delta. Theoretically, tracking per-color delta along with a mechanism to observe the sum of all deltas in a chain can establish a mathematically sound system for crosschain token coloring. However, it is typically preferable to store at least colored or minted to enable minters to swiftly determine the circulation of their tokens on each blockchain.

Pain point: deficit list

All the previously discussed models share a critical limitation: the deficit list. Maintaining this list not only incurs a substantial gas cost but, more significantly, leads to an unpredictable gas cost per token transaction. In fortunate scenarios, crosschain transfers may involve storing one positive delta and one negative delta. However, in the worst case, crosschain transfers could result in storing one positive delta alongside hundreds or even thousands of negative deltas (though in practice the probability of this is close to zero). To exacerbate matters, the packet size limit imposes a nondeterministic upper bound on the number of tokens that can be sent from one blockchain to another. This unpredictability in user experience can be characterized, to put it politely, as suboptimal.

We burned many hours and weekends musing over how to optimize or eliminate the deficit list, and the potential security surfaces that are introduced. We eventually came to the consensus that the user experience cannot be compromised under any circumstances, which meant that whatever solution we came up with should provide well-defined, simple semantics with at least a predictable upper bound on transaction gas consumption as a function of the number of tokens.

Eliminating the deficit list introduces a significant challenge as the system is no longer easily composable without it. While it might be straightforward to address this issue by requiring offchain input for choosing or optimizing deficits to balance the transfer, purely onchain applications that integrate with USDV cannot rely on this interface. The need for maintaining composability poses a nuanced challenge in the design considerations.

Our next thought was that we could somehow optimize the deficit list to limit the gas to a reasonable degree. Many ideas floated around, such as allowing pseudorandom seeding into a random point on the deficit list, a “tiered” sorting model of ordered unsorted buckets, and just maintaining the top N largest deficits.

However, we were not yet convinced that there was no way to provide a consistent, hard bound on the variance in user-facing gas consumption. Our solution at this point was essentially complete, but we did not move on until we are convinced the solution is both complete and there exists no better solution. Consequently, our focus shifted towards identifying a bookkeeping mechanism that provides tighter bounds on cost and storage for crosschain transfers.

DeltaTheta, DeltaSigma, Debt, and ColorTrace

The final idea we eventually settled on for this bookkeeping mechanism was DeltaTheta; our Chief Architect and our CTO independently came to the same solution, with the former calling it ΔΣ and the latter calling it Debt. The final naming was a point of contention, and we eventually settled on DeltaTheta (Δθ).

DeltaTheta can be conceptualized as the per-chain global aggregation of float, or as a sort of “uncolored crosschain delta”. When a surplus is transferred from chain A to chain B, that surplus is replaced by an equivalent increase of DeltaTheta on the source chain, and balanced by an equal magnitude negative change in DeltaTheta on the destination chain. Thus, we sort of “cheat” by punting the problem of matching surpluses to deficits down the line to what we call the synchronization layer.

The obvious problem with DeltaTheta is that it cannot be used to remint surpluses (whose mint would you slash to remint the surplus?), but at the same time a negative DeltaTheta implies there are more colored surpluses than colored deficits on the local chain. Thus, if DeltaTheta is negative, there exist local surpluses that cannot be reminted due to lack of colored deficit; the job of balancing DeltaTheta across blockchains is delegated to the synchronization layer.

The synchronization layer can be implemented in many different ways, and we’ll focus on presenting the way we ultimately settled on

The first alternative, which we ultimately adopted, involves freely synchronizing positive DeltaTheta with negative colored delta (deficits) between secondary chains. If a blockchain has a positive DeltaTheta, the equivalent magnitude of colored deficit can be transferred to any remote blockchain. This approach operates under the optimistic assumption that DeltaTheta will eventually converge to zero on all blockchains.

While this approach carries some disadvantages, notably the absence of a hard guarantee of system convergence, it is the most practical solution to delta synchronization within the constraints of existing blockchain networks.

Firstly, reminting still takes place directly from secondary blockchains and is susceptible to color fragmentation. In situations where many small deficits cumulatively sum to match a large surplus, packet size limitations can result in a significant cost for reminting. This highlights a potential challenge in terms of efficiency and cost-effectiveness.

Second, the lack of convergence guarantee allows malicious actors to potentially hide their deficits in a packet indefinitely by ping ponging it between two blockchains. Supposing the DeltaTheta on chain 1 is positive K, the attacker can synchronize K of their own color deficit from chain 1 to chain 2 with DeltaTheta=0, then compose the destination chain synchronization transaction with another synchronization back to chain 1. An attacker with sufficient liquidity can identify chains with less liquidity to attack using this ping pong attack and indefinitely hide their deficits.

Third, it is possible to create unremintable remint requests under this synchronization mechanism, as mentioned in the whitepaper. The example from the whitepaper is reproduced below.

If remint R3 is executed before R1, both R1 and R2 are independently un-executable, but cancel each other out. This necessitates a delta pool that allows the accumulation and merging of remint requests without applying them to the vault. The contents of this delta pool are piecewise synchronized with the vault when the state of the vault and delta pool are consistent.

At this point we would like to briefly pause to illustrate the final design of ColorTrace as we implemented it and presented it in the whitepaper, shown in the above figure.

Transfer (TransferSend & TransferReceive), at the top, illustrates the transfer of a surplus of color C from chain Source to chain Destination. The actual tokens are deducted from the source wallet, and the surplus is deducted from the source ΔC. This change in ΔC is balanced by an equal and opposite movement in Δθ on the source chain, maintaining the delta-zero invariant. We then move the tokens, change in ΔC, and change in Δθ from the source chain into the packet. On the destination chain, a similar operation is performed by TransferReceive, removing these values from the packet and crediting (adding) them to the destination token contract. We only illustrate the case where ΔC > 0 on source, as all other cases can simply send tokens without changing ΔC or Δθ.

Sync (SyncSend & SyncReceive) is similar to the Transfer operation, except it does not move actual tokens and the colored delta must be negative.

Recolor simply increases one delta and decreases another by the same amount on the source chain.

Remint (RemintSend & RemintReceive) finds a positive K such that ΔM (the reminting color) is greater than or equal to K and another ΔV (the victim color to be slashed) is greater than or equal to -K. ΔV and ΔM are then reduced in magnitude (converges towards zero) by K.

Delta Pool

Given that the worst-case scenario involves aggregating remint requests in the delta pool, a more elegant design was proposed: directly aggregating all deltas in the delta pool before initiating the reminting process from the delta pool to the vault. This investigation also considered the concept of one-sided (non-deltazero) synchronization, allowing a surplus to be sent to the vault without a matching deficit and vice versa. This refined approach aims to streamline the reminting process and enhance overall system efficiency.

The delta pool boasts several favorable properties, primarily arising from the unidirectional flow of deltas into the pool. This configuration offers stronger convergence guarantees, reduces attack surfaces, and simplifies the minter experience by automating the merging and canceling of deltas in the delta pool. However, this approach does necessitate the involvement of an external entity (e.g., token foundation) to altruistically cover the costs of synchronization to the delta pool on Ethereum. This opens up some potential griefing surfaces, as users may attempt to spuriously create extra synchronization costs. Striking a balance between system integrity and user experience becomes a crucial consideration in this context.

In this form of the delta pool, reminting occurs exclusively using deltas stored in the pool, and both colored surpluses and deficits must be synchronized to the delta pool to facilitate reminting. However, several reasons led to the decision not to adopt this version of the delta pool. First, there is a race condition where a minter synchronizes a deficit to the delta pool, but another minter frontruns the remint transaction to consume the deficit. Secondly, this design relies on the assumption of an actor motivated to pay fees to reduce system entropy (e.g., token foundation) covering the costs to synchronize the deltas to the delta pool. The semantics of this altruistic synchronization are challenging to define, as minters may have different optimization functions for cost versus benefit with synchronization. These considerations underscore the complexity and potential drawbacks associated with this form of the delta pool.

One-sided Synchronization, Donuts, and Rho

The delta pool model opens the opportunity for one-sided synchronization, or non-deltazero synchronization from secondary chains to the delta pool. For example, a minter can synchronize only their own surplus, and depend on some other entity to synchronize a matching quantity of deficits to facilitate reminting. This can theoretically be enhanced by a fee and reward model, where a net-positive (net surplus) synchronization incurs a fee, whereas a net-negative (net deficit) synchronization receives a reward to incentivize both sides of the synchronization.

This introduces a potential issue known as the “donut attack.” Addressing this donut problem marked the final phase of our investigation, ultimately convincing us that our exploration of the design space was comprehensive and concluded.

The donut attack unfolds as follows:

1. The attacker controls two colors, Red and Blue, initially holding K red tokens, and all deltas are zero on chain 1.
2. The attacker recolors Red|K to Blue|K, synchronizes deltaBlue = +K, then transfers Blue|K to chain 2.
3. On chain 2, the attacker recolors Blue|K to Red|K, then transfers Red|K to chain 1.
4. On chain 1, the attacker recolors Red|K to Blue|K, then synchronizes deltaBlue = +K.
5. This cycle repeats indefinitely, creating deltaBlue infinity on the delta pool, deltaBlue minus infinity on chain 2, and deltaRed minus infinity on chain 1.

The donut attack illustrates a perpetual loop that results in unbounded delta values, presenting a significant vulnerability in the system.

This problem does have a proper solution in constant time, but it introduces rather large overheads. Initially, we present this solution in an intuitive but inefficient way, then detail how it can be optimized. The solution involves defining special “lock” and “key” fungible colored tokens generated upon the crosschain transfer of a surplus. Specifically, if K surplus tokens are sent from chain 1 to chain 2, K lock tokens are generated on chain 1, and K key tokens are transferred to chain 2.

When a surplus is synchronized to the delta pool, it is accompanied by any lock tokens present on the local chain up to the amount of the synchronized surplus value. Simultaneously, if a deficit is synchronized, it is accompanied by any key tokens present on the local chain up to the amount of the synchronized deficit value. In the delta pool, lock tokens prevent the reminting of a corresponding surplus, and key tokens correspondingly prevent the slashing of deficits. If lock tokens are present in the delta pool when key tokens are synchronized, or vice versa, an equivalent quantity of lock and key tokens is canceled out. This mechanism provides a way to manage and balance surplus and deficit tokens in the delta pool efficiently.

To formalize and optimize this model further, we introduce a new colored meta-token called rho, where a negative rho corresponds to a key, and a positive rho corresponds to a lock. When synchronizing deltas to the vault, the rho values must be synchronized along with the deltas. During the transfer of K surplus from one chain to another, the source chain’s rho is increased by K, and the destination chain’s rho is decreased by K. This solution provides a mathematically sound mechanism for allowing one-sided synchronization in a way that is resistant to donut attacks. In the case of a donut attack creating an unbounded surplus, that surplus is locked up and unremintable. Another perspective on rho is as a per-color DeltaTheta, facilitating safe one-sided delta synchronization. The Rho model does incur overheads on every operation in exchange for a very marginal increase in system-wide consistency.

ColorTrace is ultimately the solution the Verified USD Foundation chose for USDV, but we still wanted to carefully analyze the weaknesses of ColorTrace and understand the tradeoffs involved in solving these weaknesses. The first weakness is the susceptibility to flash reminting and other timing-based attacks. The second weakness is the complex offchain deltaTheta synchronization logic. Given these challenges, the subsequent question arises: Is there a way to completely eliminate the difference between local and global mint? Can we track the granular, precise history of circulation updates and leverage this information to calculate yield shares? And if so, what desirable properties of ColorTrace do we lose as a result?

ColorAge

An entirely different approach to the aforementioned synchronization models involves making a small compromise on the user experience and decentralizing the vault. In both ColorTrace and the rho model, the worst-case gas overhead for token transfers is updating deltas for recoloring or DeltaTheta, and both of these overheads can be reasonably predicted in a deterministic manner. In the next approach we will talk about, ColorAge, the gas cost variance for transfers is theoretically unbounded (though in practice the vast majority of transfers will have the exact same gas cost), and depend on wall-clock time which is much harder to reason about deterministically.

In ColorAge, we define age as the product of circulation and elapsed time. For instance, if the circulation of a token is 100 and remains unchanged for 10 seconds, the token age is calculated as 100 * 10 = 1000. Age can be accumulated over time. For example, if the circulation is 100 for 10 seconds and then increases to 200 for the next 10 seconds, the total age is computed as 100 * 10 + 200 * 10 = 3000. This age calculation provides a measure of the token’s activity and duration in circulation.

We further define ColorAge, a tuple consisting of age and all other information necessary to calculate age.

Given the ColorAge of a given token, the age of the token over a given period of time can be interpolated from the data stored in the ColorAge struct.

ColorAge is tracked (1) for each color in the system and (2) for the total circulation of tokens within a given blockchain. This tracking allows for a comprehensive understanding of the age dynamics at both the individual color level and the overall token circulation within a specific blockchain.

Time is divided into epochs, with each epoch defined as a system-wide constant span of time. This time can be either local wall clock time or some other logical time construct. Yield distribution takes place on epoch granularity, meaning that yields are distributed from the managing entity to minters at the conclusion of each epoch. This approach provides a structured and predictable schedule for yield distribution, enhancing the system’s transparency and reliability.

Every time tokens are recolored, ColorAge is updated for the source and destination colors. In addition, every time tokens are moved between blockchains, minted, or burned, ColorAge is updated for the relevant colors and total circulation on all blockchains involved. We denote ColorAge for a given color C to be ColorAgeC, and the ColorAge for the local blockchain to be ColorAgeΣ.

For each chain in the network, the invariant is maintained that Σ ColorAgeC = ColorAgeΣ

Each CheckpointRoot is the hash of the ColorAge at a certain point in time concatenated with the previous CheckpointRoot. This creates a chain-like structure where the CheckpointRoot (a compact hash or similar) can be used to validate the authenticity of a given sequence of ColorAges. More formally,

CheckpointRoot 0 (CPR0) = keccak256(abi.encode(ColorAge0, 0)),

CPR1 = keccak256(abi.encode(CPR0, ColorAge1)) and so on and so forth.

This design allows the verification of ColorAge sequences on a remote blockchain while only using one storage slot for CheckpointRoot.

Note that if CheckpointRootT-2 was stored in the vault, the local blockchain would have to send CheckpointRootT, ColorAgeT-1, and ColorAgeT to verifiably recreate the chain all the way to CheckpointRootT.

Distribution layer

Given the ColorAge tracked locally on each chain, we define three potential distribution models.

1. Distribution occurs in the vault.

1. For a color C and epoch T, yield distribution can occur if (1) ColorAgeC and (2) ColorAgeΣ for a given secondary blockchain B are received on the vault.
2. The minter for color C can receive their entire yield for epoch T only after ColorAgeC and ColorAgeΣ are received at the vault from every blockchain in the network.
3. Alternatively, if ColorAgeC for every color on blockchain B is received at the vault, ColorAgeΣ can be calculated as the sum Σ ColorAgeC, meaning ColorAgeΣ does not necessarily have to be explicitly sent from blockchain B to the vault

2. Distribution occurs on the secondary chains

1. ColorAgeΣ is used to determine the yield distribution from the vault to secondary blockchains. A secondary blockchain’s proportional share of the yield is given to be its ColorAgeΣ divided by the sum of ColorAgeΣ across all secondary blockchains.
2. This model only requires ColorAgeΣ to be synchronized from secondary blockchains to the vault, thus resulting in messaging complexity scaling in proportion to the size of the network rather than the number of minters.
3. Yields are distributed to the local blockchain and stored in a mapping epoch => yield
4. Each minter claims a portion of the yield for a given epoch based on their ColorAge

3. Distribution occurs offchain

1. Distribution can use the checkpointRoot and history of age updates as a sort of proof for minters to provide verifiable attestations to their ColorAge over a given epoch. This ColorAge can then be used to calculate a yield distribution which can occur offchain.
2. Offchain distribution is the most efficient method of distributing yields, and theoretically can be done with zero crosschain messages. However, offchain distribution does require minters to place a degree of trust into the distribution infrastructure and token foundation.

It’s technically possible, but with unclear benefits, to define distribution topologies that combine the above. For example, having multiple vaults, or a tiered/tree structured vault where yields trickle down from a set of root nodes towards the leaf nodes.

ColorAge has several advantages over ColorTrace, but also comes with several drawbacks. ColorAge simplifies the consistency model by removing almost all asynchrony from safety-critical operations (i.e., no delta, delta synchronization, reminting), and provides second-granularity tracking of attribution changes, eliminates remint-based timing attacks (flash loan, etc.). Unfortunately, ColorAge does have some drawbacks, which we address below.

The first drawback is the nondeterministic and potentially incredibly expensive transfer cost. If a color has not been recolored for many epochs and no entity has run a manual checkpoint of the ColorAge, the first recoloring or crosschain transfer will have to calculate and store many checkpoints. This can be fixed by making epochs very long and the token foundation actively running checkpoints. There are also options to reduce the fidelity of tracking in exchange for reduced nondeterminism, but the problem is impossible to completely eliminate.

Another disadvantage is that non-centralized distribution can be inconvenient for minters, as yield will be fragmented across every chain in the network. However, centralized distribution also has the disadvantage that at least one crosschain message per epoch is required to collect yield (in ColorTrace, this is zero if no reminting happens).

Finally, ColorAge makes it difficult to incentivize minting at the protocol level. Tokens are never burned or reminted, so there is no way to set or collect a reminting fee. This may be possible to incentivize externally to the protocol, but someone would be paying out-of-pocket for these incentives. Without these incentives, however, it becomes a zero-sum game where existing minters fight for a fixed pool of yield, as there is no incentive to introduce new mint into a system where other minters can so easily steal yield share.

Our final conclusion

The safety difference between rho and DeltaTheta is minimal in practice. Consequently, the decision was made to settle on using the DeltaTheta model with a small, infrequently-used delta pool, as mentioned in our whitepaper. This approach strikes a balance between mathematical completeness and practical usability.

ColorAge, on the other hand, appears at first glance to be a very practical and efficient solution that competes with ColorTrace. However, ColorAge has a fatal weakness in that minting new tokens is not incentivized; this property by itself prevents any stablecoin from gaining traction. ColorTrace provides a knob to tune and control the relative advantage of TVL (Total Value Locked) vs. volume/throughput: remint fees. Setting a remint fee of 0 would yield financial characteristics nearly identical to ColorAge, whereas setting a remint fee of 100% would direct all the financial incentive purely to freshly minted tokens. ColorAge can be viewed as a gas-efficient protocol to implement the financial characteristics of ColorTrace with no remint fees, but loses all flexibility in exchange. This nuanced approach allows for flexibility in adjusting the protocol’s behavior based on the desired balance between freshly minted tokens, TVL, and transaction volume.

We hypothesize that a remint fee that is greater than zero, but not excessively high, creates the best ecosystem for DeFi applications, and thus chose not to commit to the zero remint fee model unless we find evidence that our hypothesis is false. We find it highly unlikely that any stablecoin ecosystem can grow without minting incentives, and thus believe ColorAge may be better suited to different applications and ecosystems.

Other theoretical “attacks”

One theoretical “attack” that we did not delve into in the whitepaper is known as the deficit sponge. In this scenario, the adversary has control over two colors, Red and Blue. The attack commences with holdings and surplus of Blue|K tokens on the home chain.

The assailant executes this strategy by transferring the surplus to a targeted chain, changing its color to Red, and subsequently reissuing the surplus against a different color that currently exhibits a deficit on the chosen chain. The attacker then transmits the Red|K tokens back to the home chain, converts them to Blue|K, and repeats this process for each chain in the network, potentially up to once per chain. As a consequence of this attack, in a network consisting of N chains, the adversary utilizes K tokens to accumulate N * K mint with a deficit of (N-1) * K on the home chain. Conceivably, the deficit on the home chain can be concealed using the fugitive deficit attack.

We don’t consider the deficit sponge to be a real attack because the reward earned does not justify the risk. The deficit of (N-1) * K on the home chain can easily be slashed by any verified minter, and in all realistic scenarios it will be slashed long before the “attacker” can recoup the reminting fees. Thus, the deficit sponge is just a fancy way to pay extra fees to your “victims”, or put differently a way to attack yourself. Unfortunately, we do not have much sympathy for malicious parties and do not build any protocol-level protections against self-destruction via deficit sponge.

The ColorTrace whitepaper doesn’t delve into the decentralization of delta synchronization. While theoretically possible, achieving decentralization would demand meticulous management of pricing and a well-defined framework of risks and rewards. The ultimate goal is to incentivize individuals for converging DeltaTheta towards zero on the destination chain during synchronization, without imposing penalties for causing DeltaTheta divergence.

In theory, a reward could be provided on the destination chain if DeltaTheta converges as a result of a synchronization operation. However, the pricing for this reward needs to be carefully calibrated — it should be greater than the fee for a single crosschain message but less than the fee for two crosschain messages. This nuanced approach is crucial. If the reward matches the cost of two crosschain messages, there’s a risk that network operators might be incentivized to intentionally create divergence using a crosschain transaction, followed by synchronization to resolve that divergence. This could enable them to pocket network fees at the expense of the token foundation.

Given these considerations, the Verified USD Foundation decided to implement non-incentivized delta synchronization in version 1 of USDV. Any move towards decentralization in this aspect would necessitate a thorough threat analysis to carefully assess the potential risks and devise appropriate safeguards before implementation.

Conclusion

Thank you for making it to the end of this long and very technical post. Ultimately, the message we wanted to get across is that we here at LayerZero spend an incredible amount of time and effort to exhaustively explore the design space of every problem we solve, and token coloring is no exception. We started with ColorFloat, and broke the problem down into layers until we were unable to further subdivide. We enumerated the polar extremes of the design space of each layer, considered the spectrum of designs between these extremes, and came up with ColorTrace, ColorAge, and ColorFloat. After we convinced ourselves that the design space was fully explored, we carefully chose the one that would provide the most positive impact to the Web3 space, and released it to the world.

Written by Thomas Kim, Isaac Zhang and Ryan Zarick and brought to you by the LayerZero engineering team.