ColorTrace: Fungible token coloring and attribution

Ryan Zarick1 Bryan Pellegrino Isaac Zhang1 Thomas Kim Caleb Banister
LayerZero Labs Ltd.

Abstract Fungible token coloring covers the majority of the

Colored Coins problem [1, 3], with the exception of
We formally define the fungible token coloring problem singleton metadata attributes which have already been
of attributing (coloring) fungible tokens to originating solved by NFTs [2]. Applying the Colored Coins pro-
entities (minters), and present, to our knowledge, the tocol to the fungible token coloring problem would loss-
first practical onchain algorithm to solve it. Tracking at- lessly map tokens to minters in every wallet, which is
tribution of colored tokens losslessly using existing ap- impractical due to two fundamental computational con-
proaches such as the Colored Coins protocol is computa- straints: onchain storage and compute cost. Even within
tionally intractable due to the per-wallet storage require- a single blockchain, it is prohibitively expensive to loss-
ments growing in proportion to the number of minters. lessly maintain the per-minter attribution for every wal-
Our first contribution is an elegant solution to the single- let balance. A system of N minters would result in O(N)
chain token coloring problem, where colored tokens are storage complexity per wallet and O(N) computational
atomically burned and minted to ensure each wallet only complexity to iterate over both the sender and receiver
contains tokens of a single color. Our second contri- wallets every time tokens are transferred. Therefore, any
bution is an extension to this single-chain token color- practical token coloring algorithm must be lossy.
ing algorithm to allow safe and efficient crosschain to-
Our algorithm, ColorTrace, is the first to solve the fun-
ken transfers. We present ColorTrace, an onchain algo-
gible token coloring problem in O(1) storage complexity.
rithm to achieve globally consistent, economically feasi-
This is achieved by requiring all transfers to recolor to-
ble, fungible token coloring.
kens such that the receiver wallet balance and sent tokens
are of the same color. In addition to solving the fungi-
ble token coloring problem in a single-chain context, we
1 Introduction
solve the additional economic and safety challenges to
extend ColorTrace to support provably-safe crosschain
Current decentralized finance (DeFi) applications often
token transfers. The safety of crosschain transactions is
rely on fungible tokens (e.g., stablecoins) to provide an
guaranteed by the delta-zero invariant, a single invariant
easy-to-use, reliable, and trustworthy payment mecha-
which we use to formally prove the safety and validity of
nism. However, there exists a key deficiency with current
ColorTrace’s crosschain recoloring methods.
fungible tokens: once they are issued (minted), there is
no practical onchain algorithm to keep track of the entity Crosschain token coloring opens new opportunities in
(minter) that minted them. This makes it impossible to the Web3 ecosystem, and this paper focuses on one ob-
(1) track the origin of each token as they are transferred vious and powerful example: the collateral-based stable-
and redeemed, and (2) proportionally reward minters for coin. Under the current paradigm, stablecoins are issued
minting tokens. We formalize this dilemma as the fun- in exchange for collateral, and the collateral is used to
gible token coloring problem of “coloring” fungible to- purchase yield-bearing assets. Many minters (e.g., appli-
kens to associate each token to the entity that originally cations) generate demand for these stablecoins by pro-
minted it, and present a novel algorithm to solve this viding services for users, yet the token issuer is unable to
problem. proportionally reward minters due to the lack of a mecha-
nism to track the color of each fungible token. Token col-
1 Inventors at LayerZero Labs Ltd. oring enables the issuer to proportionally share yield with
Copyright © 2023 LayerZero Labs Ltd. All rights reserved. minters based on their quantified contribution to overall

1
 Alice Bob Attribution Wallet the underlying token is transferred between users. The
mint 20 mint 10 Alice: 20 Alice: 20 fungible token coloring problem specifically deals with
Bob: 10 Bob: 10 the tracking of color metadata, where multiple tokens
send 10 → receive 10 Alice: 20 Alice: 10 can be tagged with the same color, and tokens of a given
Bob: 10 Bob: 20 color are aggregated into a single quantity. However, the
redeem 10 ??? fungible token coloring problem does not cover use cases
requiring singleton attributes, as such applications would
Figure 1: Fair redemption requires token coloring. better be served by existing solutions such as NFTs [2].
A globally unique vault, deployed on the designated
primary chain, tracks and updates the mint of each color,
demand for the stablecoin. which represents the sum of circulation for a given color
Without a fungible token coloring algorithm, it is im- across all chains. This mint can be used to calculate the
possible to track minter attribution for proportional yield contribution of a given color to the global demand across
sharing as we demonstrate in Figure 1. In this example, all blockchains, which can, in turn, be used by the token
Alice and Bob mint 20 tokens and 10 tokens respectively. foundation to fairly distribute yields. After a token is
Alice then sells 10 tokens to Bob, where they are mixed minted at the vault, it is transferred to the minter’s wallet
with his existing holdings. Bob tries to redeem 10 tokens, on the primary chain, from where it can be transferred to
but the fungibility of the tokens makes it impossible to other chains or wallets.
decide which minter(s) to deduct attribution from. As mentioned in Section 1, it is prohibitively expen-
The remainder of this paper is structured as follows: sive to update mint on the vault every time a token is
Section 2 formally defines the fungible token coloring recolored on a chain other than the primary chain. This
problem, Section 3 details the required security proper- necessitates relaxing the synchrony requirement between
ties of ColorTrace, Section 4 presents the algorithmic mint and circulation, and handling the resulting diver-
foundation of our solution, Section 5 discusses Color- gence in an efficiently, provably safe manner. Color-
Trace’s countermeasures against various attack surfaces. Trace achieves this by tracking the delta (∆) between
the current circulation and the last synchronized mint
2 Fungible token coloring (localMint), and allowing minters to remint any posi-
tive delta to close the gap between the circulation and
In this section, we formalize the fungible token coloring localMint. As we demonstrate in this paper, each token
problem and related terminology. contract must store ∆C for every color, but does not need
The colored token is the underlying token that is to explicitly track localMintC or circulationC . How-
tracked by ColorTrace, and is governed by a token con- ever, we expect most implementations of our algorithm
tract deployed on every chain. Minters generate demand to store localMintC or circulationC for better minter and
for users to transact in colored tokens, with each minter user experience (e.g., circulation observability).
assigned a dedicated color (i.e., an ID) that uniquely Finally, the fungible token coloring problem requires
identifies it across all blockchains. Every colored to- the colored token to be fungible from the perspective of
ken is mapped to exactly one color, and this mapping the end-users, but not necessarily the minters. Color-
is tracked by the token contract. We refer to the total Trace implements full fungibility in all user-facing and
number of tokens of a color within a given chain as the minter-facing operations, but other solutions, such as our
local circulation, and the circulation of tokens across all recently published ColorFloat algorithm [5], may re-
blockchains as the global circulation. User wallet bal- quire minters to be conscious of the color of the tokens
ances are represented as a tuple of color and quantity, they hold.
with the balance of a user holding holdinguser tokens of
color coloruser notated as coloruser |holdinguser (e.g., B|H 3 Consistency and security
for H number of Blue tokens).
The fungible token coloring problem is the challenge In this section, we formalize the security properties
of associating (coloring) each token with a specific color, of ColorTrace and present the invariants we use to
tracking the color of each colored token as they move be- reason about the safety of ColorTrace transactions.
tween wallets, and maintaining a consistent record of the All ColorTrace operations involve one or more of
proportion of global circulation of each color to the to- three independently-consistent transaction contexts (do-
tal global circulation of all colored tokens. Many aspects mains): the vault, chain, and packet. The vault is re-
of the fungible token coloring problem correspond to the sponsible for (1) safely linking underlying assets to col-
Colored Coins problem, such as the association of meta- ored tokens and (2) tracking global per-color circulation.
data to fungible tokens and the tracking of metadata as The chain (sometimes referred to as local chain), is any

2
blockchain in the network that executes token operations. eventually be applied (executed) to the state of the target
Finally, the packet is a special domain that participates domain. While delivery is largely governed by the net-
in two transactions–one on the source chain, and another work, execution is less trivial as asynchrony can result in
on the destination chain. After tokens and metadata are situations where certain actions cannot be executed im-
written into the packet on the source chain, the packet do- mediately after the destination domain receives the cor-
main is made accessible to the destination chain by trans- responding packet (see Section 4.2.1).
mitting its contents using a crosschain messaging proto-
Mint-holding preservation requires that operations
col. To avoid confusion, we refer to the packet domain
never reduce a minter’s mint below the number of minted
as packet, and the crosschain messaging protocol packet
tokens they hold. This property is what guarantees fungi-
as crosschain packet. Operations that involve multiple
bility for minter-facing operations; without mint-holding
blockchains communicate via the packet, but crosschain
preservation, minters must take explicit steps to hold to-
packet delivery is assumed to be asynchronous.
kens of their own color to preserve their mint. However,
We continue to define four properties that guarantee
as we mentioned in Section 1, the colored token is not re-
the safety and fairness of all ColorTrace operations, and
quired to be fungible for all minter-facing operations, so
formalize the invariants we leverage to reason about the
this fairness property is not a hard requirement for all so-
fulfillment of these properties.
lutions to the fungible token coloring problem. Detailed
Asset-circulation equivalence ensures that no operation further in Section 4.2.1, this property is guaranteed by
changes the total number of tokens in circulation with- the delta-influence invariant which states that operations
out a corresponding change in the holdings of underly- may only change the sign of ∆C if actual tokens are re-
ing assets. The vault is assumed to correctly enforce the colored or transferred, and no operation may increase the
creation and destruction of tokens in exchange for under- magnitude of ∆C by more than the number of tokens of
lying assets, and as such any transaction that changes the color C the initiator of the operation holds.
global supply of tokens assets must originate from within
the vault. Thus, we enforce asset-circulation equivalence
through the global supply invariant, which states that any 4 Design
operations that increase or decrease the aggregate global
supply of tokens must be fully contained within the vault. To simplify the consistency model, we assume the set of
The global supply invariant is composable, meaning a se- minters is synchronized across all chains. This can be
quence of operations will fulfill the global supply invari- implemented in several different ways, such as onboard-
ant if each operation individually preserves the global ing minters at the vault before accepting any transactions.
supply invariant. Each token contract must store ∆C for every color C
(colored delta) along with a value ∆θ (Section 4.1.3) that
Conservation of error states that any divergence be- tracks ∆ imbalances between different blockchains; all
tween the circulation of each color and the mint recorded ∆, including ∆θ , are initially zero as there is no differ-
at the vault is accurately propagated across every opera- ence between localMint and circulation, nor are there
tion. When combined with asset-circulation equivalence, any ∆ imbalances between blockchains until tokens are
this guarantees the net error in the system to always be recolored or transferred. We refer to a positive ∆C as a
zero. This safety property is the most important, and we surplus–meaning more tokens of that color are in circu-
formalize it as the delta-zero invariant: ∑ ∆ = 0 for ev- lation than are accounted for by the vault–and a negative
ery element of the power set of all domains in the net- ∆C as a deficit. If ∆ never changes, the system is trivially
work. More informally, there should be no domain in the consistent as there is no divergence between the state of
system that violates the delta-zero invariant, and by ex- the vault and the global circulation.
tension no combination of domains in the system should
We define six token contract methods–RemintSend,
have a nonzero sum of deltas.
Recolor, TransferSend, TransferReceive, SyncSend, and
Eventual finality states that every action taken by a user SyncReceive–and three vault methods: Mint, Redeem,
or minter will eventually be reflected in the state of the and RemintReceive. Furthermore, we categorize Re-
relevant token contract(s) or vault. For operations that color, TransferSend, TransferReceive, Mint, and Redeem
affect only a single blockchain, eventual finality is triv- as the coloring layer, and the remaining methods as the
ially fulfilled as the entire operation is committed in a synchronization layer. The safety properties of the col-
single local transaction. This property has two aspects– oring and synchronization layers are isolated, and any
guaranteed delivery and guaranteed execution. Opera- synchronization layer can be interchanged with the de-
tions that involve multiple blockchains rely on lossless, sign we present in this paper provided it implements
only-once delivery of crosschain messages for eventual Remint (Section 4.2.1) while fulfilling all security prop-
finality. Furthermore, the effects of the operation must erties (Section 3). The remainder of this section details

3
 1: procedure M INT(C, q) change other than the sender and receiver colors on the
2: mintC ← mintC + q local chain, the net change in the sum of all ∆ is zero,
preserving the delta-zero invariant and by extension ful-
1: procedure R EDEEM(C, q) filling conservation of error. The quantity of tokens does
2: mintC ← mintC − q not change and the recoloring operation is atomic, ful-
filling asset-circulation equivalence and eventual finality
Figure 2: Mint and Redeem respectively increase or de-
respectively.
crease the mint of color C (mintC ) at the vault.
The initiator of the recolor operation is limited to re-
coloring up to the quantity of tokens they hold, imply-
the implementation and safety properties of each method. ing that mint-holding is preserved as tokens held by a
minter cannot be recolored unless the minter themselves
recolor it. Put more formally, if the minter is holding
4.1 Coloring layer localMint tokens and a different recoloring initiator is
holding K tokens of the same color, by definition the
The coloring layer is the layer that governs the color-
circulation must be at least localMint + K. The caller
ing and recoloring of colored tokens, and encompasses
can only induce a change in circulation by up to magni-
the user-facing methods of ColorTrace. To provide the
tude K, bounding the final resulting circulation such that
best user experience, the coloring layer is designed to
circulation ≥ localMint = holdingminter .
use minimal, deterministic per-transaction gas at the ex-
pense of creating divergence that must be reconciled by
the synchronization layer. 4.1.3 Transfer
In this section, we present the token transfer algorithm in
4.1.1 Mint and redeem the context of a crosschain transfer although the safety
properties are identical for crosschain and single-chain
Minting issues tokens based on some value input, for ex-
transfers. The crosschain transfer operation is com-
ample one US dollar (USD) in exchange for one colored
posed of separate send and receive transactions, whereas
token. Redeeming is the opposite of minting, burning
a single-chain transfer would simply combine these two
tokens at the vault to represent the release or expiry of
operations into the same local transaction. Transfers
the underlying value (e.g., transfer 1 USD to a bank ac-
between blockchains involve messaging asynchrony be-
count). Both minting and redeeming can only occur in a
tween the debit from the sender’s balance and the credit
local context on the primary chain, thus achieving instant
to the receiver’s balance, significantly complicating the
finality and by extension eventual finality. Minting and
consistency (safety) model.
redemption directly change mint at the vault, and cor-
respondingly increases the balance of the minter’s wal- TransferSend is the source transaction of the crosschain
let on the primary chain–neither of these operations af- transfer, and moves q tokens of color C from the source
fect ∆, and thus trivially satisfy the delta-zero and delta- chain into the packet. Crosschain transfers must be delta-
influence invariants. Finally, as both minting and re- zero on both the source and destination chains. When
deeming occur in the vault, asset-circulation equivalence transferring tokens of a color C, the delta-zero invari-
is assumed to be fulfilled by the vault implementation. ant is trivial to guarantee when ∆C ≤ 0 and difficult
when ∆C > 0. The reason for this is not immediately
4.1.2 Recolor apparent, but consider the case where ∆C ≤ 0; the to-
kens can be transferred directly without changing ∆C , as
To achieve O(1) storage complexity transfers, Color- conceptually, circulationC and localMintC are reduced
Trace enforces that all transfers be conducted in a single by the same amount. The fact that the user is holding
color. However, this potentially introduces some diver- K tokens guarantees that circulationC ≥ K, and because
gence (increase in magnitude of ∆) when tracking circu- circulationC = localMintC + ∆C ≤ localMintC , the user
lation across transfers. If the sender and receiver of a can safely infer that K ≤ circulationC ≤ localMintC .
token transfer have different colored balances, one of the However, crosschain transfers when ∆C > 0 are less
balances must be recolored to match the other. While we straightforward, as the user cannot guarantee the local
assume in the scenario, for simplicity, that the sent quan- availability of minted tokens to back the entire trans-
tity is recolored to the receiver’s color, any policy can ferred balance. The key insight that makes crosschain
be implemented for choosing which balance to recolor, transfers efficient in ColorTrace is our use of ∆θ (delta
and the specific policy used is orthogonal to ColorTrace. theta), a bookkeeping mechanism to track the flow of
When CS |Q is recolored to CR |Q, ∆CS is decreased by (fungible) surpluses between chains. When a surplus
Q and ∆CR is increased by Q. Because no other deltas flows out from a chain, it is matched by an increase in

4
 1: procedure T RANSFER S END(C, q) chain and adds them to the packet. Conservation of er-
2: if q > ∆C > 0 then ror and mint-holding are met as ∆θ and/or ∆C change by
3: Revert some quantity that is bounded by the number of trans-
4: holdingCuser ← holdingCuser − q ferred tokens. Importantly, both the source chain and
5: if ∆C > 0 then packet meet the delta-zero invariant. Finality is instant
6: surplus ← min(q, ∆C ) as there exists no condition that would prevent the trans-
7: else fer of held tokens from the source chain into the packet.
8: surplus ← 0
9: ∆C ← ∆C − surplus TransferReceive is the destination transaction of the
10: ∆θ ← ∆θ + surplus crosschain transfer, moving q tokens of color C from the
11: holdingCpkt ← holdingCpkt + q packet into the destination chain along with any ∆θ and
12: ∆C pkt ← surplus ∆C necessary to preserve the delta-zero invariant. Asset-
13: ∆θ pkt ← −1 × surplus circulation is met as tokens are simply moved from the
packet into the destination chain and these tokens can
1: procedure T RANSFER R ECEIVE(pkt) be assumed to have safely originated from the source
2: holdingCpkt ← holdingCpkt − q chain by composability of the global supply invariant.
3: ∆C pkt ← surplus The delta-zero nature of the packet guarantees the delta-
4: ∆θ pkt ← −1 × surplus zero invariant upon delivery to the destination chain;
5: holdingCdst ← holdingCdst + q this ensures unconditional applicability of the packet to
6: ∆Cdst ← ∆Cdst + ∆C pkt the destination chain (eventual finality). The deltas on
7: ∆θdst ← ∆θdst + ∆θ pkt the destination chain only change by the corresponding
deltas stored in the packet, transitively fulfilling the mint-
Figure 3: TransferSend moves q tokens from color C into holding and error-conservation properties.
the packet, and TransferReceive correspondingly moves
it from the packet into the destination token contract.
4.2 Synchronization layer
We continue by describing the design of the synchroniza-
∆θ , and when a surplus flows into a chain it is matched tion layer. In this paper, we focus on presenting one spe-
by a decrease in ∆θ . This ∆θ facilitates constant space cific configuration of the synchronization layer that al-
crosschain transfers while maintaining the delta-zero in- lows crosschain reminting and omnidirectional synchro-
variant on the local chain (∑C̸=θ ∆C + ∆θ = 0). In the nization. More concretely, RemintSend can be called on
remainder of this paper, we refer to non-∆θ deltas as col- a secondary chain that is different from the primary chain
ored, in contrast to ∆θ which can be thought of as an where RemintReceive is invoked. Likewise, synchro-
uncolored delta. nization can send deltas between any two blockchains.
∆θ can continue to grow in magnitude if left alone, This design was chosen for its optimality within the eco-
and a large negative ∆θ on a chain implies many local nomic constraints of currently existing blockchains, but
colored surpluses cannot be reminted due to insufficient it is not the only viable design for the synchronization
local colored deficits. We reconcile these imbalances layer. It is possible to limit source and destination se-
through ∆θ synchronization (Section 4.2.2), an opera- mantics for reminting and ∆θ synchronization to rede-
tion that combines a positive ∆θ with an equal amount of fine the algorithm with different attack surfaces and user
negative colored ∆ (deficit) and transfers it to a different experience.
chain with a negative ∆θ . Importantly, ∆θ makes it sim-
ple to guarantee source chain convergence upon ∆θ syn-
4.2.1 Remint
chronization by blocking synchronizations that would in-
crease the magnitude of ∆θ on the source chain. Reminting is the mechanism by which minters (M) cap-
There are exactly two cases when invoking Trans- ture the value of additional gained circulation (∆M > 0)
ferSend, either ∆C ≤ 0 or ∆C > 0 ∧ q ≤ ∆C ; all other cases in their mint, simultaneously penalizing other “victim”
are explicitly prohibited by Figure 3 TransferSend line 2. minters (V) who have lost circulation (∆V < 0). To
In the first case, tokens are sent directly without chang- remint, a portion (q) of the positive ∆M (surplus) for color
ing ∆C or ∆θ . In the second case, the surplus is sent from M is matched with a victim color V that has a sufficiently
the source chain to the destination chain with a change in negative ∆V (deficit) such that ∆M − q ≥ 0 ∧ ∆V + q ≤ 0.
∆θ to compensate for the surplus outflow. The surplus is added to the mint of the corresponding
TransferSend never violates asset-circulation equiva- color, and the deficit is accordingly redeemed in the same
lence as it atomically removes q tokens from the source crosschain transaction with instant guaranteed finality.

5
 Action walletsrc ∆θsrc ∆src wallet pkt ∆θ pkt ∆ pkt walletdst ∆θdst ∆dst
Initial B|100 ∆B 0
Recolor B|100 R|100 ∆R 100
to R|100 ∆B -100
TransferSend R|0 100 ∆R 0 R|100 -100 ∆R 100
(R|100) ∆B -100
TransferReceive R|0 100 ∆R 0 R|100 -100 ∆R 100
(R|100) ∆B -100
SyncSend R|0 0 ∆R 0 100 ∆B -100 R|100 -100 ∆R 100
(∆θ = 100) ∆B 0
SyncReceive() R|0 0 ∆R 0 R|100 0 ∆R 100
∆B 0 ∆B -100
RemintSend R|0 0 ∆R 0 ∆R 100 R|100 0 ∆R 0
(∆R 100, [∆B -100]) ∆B 0 ∆B -100 ∆B 0

Figure 4: ColorTrace uses ∆θ to facilitate constant space, delta-zero transfers. Nonzero ∆θ must eventually be balanced
(via syncSend and SyncReceive) to enable all minters to fully capture their remint potential.

1: procedure R EMINT S END(M,V, q) surplus (i.e., non-minted tokens), implying that holding
2: if q > 0 ∧ ∆M − q ≥ 0 ∧ ∆V + q ≤ 0 then minted tokens does not guarantee collection of yield.
3: ∆M ← ∆M − q
4: ∆M pkt ← q RemintSend debits the surplus from ∆M to transfer it
5: ∆V ← ∆V + q into the packet, then credits the corresponding deficit
6: ∆V pkt ← −q to ∆V to transfer it into the packet. Note that neither
M nor V is allowed to be θ . The surplus and deficits
1: procedure R EMINT R ECEIVE(pkt) can no longer be leveraged in any manner once they
2: if mintV + ∆V pkt ≥ 0 then have been moved to the packet domain, as these spe-
3: mintM ← mintM + ∆M pkt cific delta values are permanently eliminated after be-
4: mintV ← mintV + ∆V pkt ing moved into the vault. No tokens are actually burned,
minted, nor moved in RemintSend (this occurs in Rem-
Figure 5: RemintSend sends a request to remint a sur- intReceive), trivially fulfilling asset-circulation equiva-
plus of q for color M (minter) using an equivalent deficit lence. The remint of the surplus and slashing of the
from color V (victim) as collateral. RemintReceive ap- deficit is reflected instantly on the source chain with the
plies this request to the vault. implicit assumption that the remint request will eventu-
ally be applied to the vault.
The delta-zero invariant is fulfilled by definition as no
Multiple remints can be composed as the remint oper-
additional divergence (increase in magnitude of ∆) is in-
ation itself is commutative, allowing many remint oper-
troduced and the RemintSend packet must include a sur-
ations to be encoded into the same packet for efficiency.
plus and a corresponding deficit. RemintSend explicitly
A negative ∆θ cannot be used as the counterparty to a
prevents the change of any ∆C from negative to positive
surplus, so it is possible for a surplus to be un-remintable
or vice-versa; this property is crucial in preserving mint-
if ∆θ < 0, which we address using ∆θ -synchronization
holding as allowing a non-positive ∆ to increase past 0 is
(Section 4.2.2).
congruent to converting localMint to surplus.
Preserving the mint-holding guarantee requires Rem-
intSend to never induce ∆M to become negative nor ∆V RemintReceive debits the surplus from the packet con-
to become positive. Consider the case where the minter’s text and credits it to the mint on the vault. In the same
holding is equal to localMintV + ∆V = circulationV and transaction, the deficit is similarly transferred from the
∆V + q > 0. A remint request that disregards this con- packet domain into the vault (the packet is implicitly dis-
dition would reduce localMintV by q + ∆V , resulting carded rather than explicitly zeroed out) where it is added
in a final value of localMintV of localMintV − q < to the mint. The delta-zero packet transitively guaran-
localMintV + ∆V , which in turn violates mint-holding tees the delta-zero invariant on the destination chain, as
preservation as localMintV − q < circulationV . Concep- the entire contents of the packet are moved into the des-
tually, a hypothetical single entity holding circulationV tination token contract. No tokens are moved, minted,
minted tokens could have a subset of them converted to or redeemed, thus trivially fulfilling the global supply in-

6
variant. 1: procedure S YNC S END(C, q)
However, due to the asynchronous nature of packet 2: if q > 0 ∧ ∆C + q ≤ 0 ∧ ∆θ − q ≥ 0 then
transmission, it is possible, in rare cases, for the system 3: ∆C ← ∆C + q
to reach a situation where a remint packet cannot be ap- 4: ∆C pkt ← −q
plied to the vault without reducing one of the mints below 5: ∆θ ← ∆θ − q
zero. There are two solutions to this problem–the first is 6: ∆θ pkt ← q
to use a vector clock to enforce gapless happens-before
execution of remint requests. The second is to aggregate 1: procedure S YNC R ECEIVE(pkt)
the un-executable remint requests into a shared pool to 2: ∆C ← ∆C + ∆C pkt
be applied after the aggregated remints result in a consis- 3: ∆θ ← ∆θ + ∆θ pkt
tent state on the vault, but due to the network overhead
of vector clocks, we opt to use this second solution. An Figure 6: SyncSend moves q deficit from color C into the
example of the above scenario is as follows: packet, and SyncReceive correspondingly moves it from
the packet into the destination token contract state.
1. Initially, mintB = 100, mintG = 0, mintR = 0
2. Recolor B|100 to G|100 At a high level, ∆θ synchronization can be thought
3. Remint ∆G 100 against ∆B -100 (remint R1) of as a separate abstraction layer to the main recolor-
ing propagation layer. For example, it is feasible to al-
4. Recolor G|100 to B|100
low direct synchronization of ∆θ and colored ∆ to the
5. Remint ∆B 100 against ∆G -100 (remint R2) remint pool instead of between secondary chains, though
6. Recolor B|100 to R|100 we opted for the latter option for economic reasons.
7. Remint ∆R 100 against ∆B -100 (remint R3) SyncSend transfers d tokens worth of deficit from a color
C from a source chain with a negative ∆θ into the packet
Due to crosschain network asynchrony, it is not guaran- such that d ≤ ∆θ ∧ d ≤ |∆C |. Because SyncSend is the
teed that R1 will be delivered to the vault before R2, but source transaction it achieves instant finality. By requir-
R2 cannot be applied to the vault before R1 due to the ing ∆θ > 0 (Figure 6 SyncSend line 2), and only per-
initial state mintG = 0 and R2 requiring mintG ≥ 100. In mitting colored deficits to be synchronized, ColorTrace
addition, if R3 is delivered and executed before R1 and guarantees source chain convergence where ∆θ always
R2, neither R1 nor R2 can ever be executed because ex- approaches zero as a result of SyncSend. The delta-zero
ecuting R3 results in mintG = 0 and mintB = 0, necessi- invariant is fulfilled as ∆C + d + ∆θ − d = ∆C + ∆θ = 0,
tating the remint pool. guaranteeing that both the source chain and packet do-
An alternative design to the remint operation of the mains are delta-zero. No tokens are moved nor recolored
synchronization layer is to remove the ability to remint in SyncSend, trivially fulfilling the global supply invari-
directly from secondary chains, and instead require ant. SyncSend explicitly forbids the increase in magni-
minters to directly remint deltas from the remint pool. tude or change in sign of any ∆C (Figure 6 SyncSend
Reminting becomes a two-step operation under this de- line 2) to fulfill the delta-influence invariant. For simplic-
sign, with the first step synchronizing deltas to the remint ity, we define SyncSend and SyncReceive in the context
pool, and the second step atomically applying a delta- of a single deficit taken from a single color, but because
zero remint request to the vault. the delta-zero invariant is commutative a single packet
may contain many composed SyncSend requests.
4.2.2 ∆θ synchronization
SyncReceive accepts the delta-zero payload from a
As mentioned in Section 4.2.1, ∆θ cannot be used as the SyncSend packet and applies it to the local token con-
counterparty for reminting, necessitating some mecha- tract, increasing ∆θ by d and increasing the deficit of
nism to balance nonzero ∆θ s to ensure sufficient col- ∆C by d. SyncSend guarantees the delta-zero and delta-
ored deficits are available on the local chain to facilitate influence invariants in the packet domain, so atomically
reminting of surpluses. ∆θ synchronization is used to moving this set of deficits and ∆θ from the packet to
move colored deficits from chains that have more colored the destination chain domain transitively maintains the
deficit than surplus to chains that have more surplus than delta-zero and delta-influence invariants on the destina-
colored deficit. Without synchronization, it is possible tion chain. No tokens are moved or recolored in SyncRe-
for surpluses to be un-remintable due to lack of colored ceive, trivially fulfilling the global supply invariant. The
deficit on the local chain; ∆θ is an indicator of which packet payload is unconditionally applied to the destina-
chains have a net colored deficit (∆θ > 0), and which tion chain state, so finality is guaranteed so long as the
have a net colored surplus (∆θ < 0). packet is delivered by the network.

7
 Source Destination outflow. The application owner (minter) can then wait an
TransferSend TransferReceive
arbitrary amount of time for an arbitrarily large surplus
Transfer Packet
Wallet C H Wallet C H
to accumulate before reminting. This allows minters to
Src Dst
Wallet C H optimize price:benefit ratio on remint fees and capture
Pkt
∆ ∆ ∆ ∆
CSrc CPkt CDst CPkt
∆
CPkt
∆
θ Pkt
0 yield proportional to their contribution to the ecosystem.
∆ ∆ ∆ ∆
θ Src θ Pkt θ Dst θ Pkt

SyncSend SyncReceive
Sync Packet 5.1 Attack surfaces and countermeasures
∆ ∆ ∆ ∆
DSrc DPkt DDst DPkt
∆ ∆ 0
DPkt θ Pkt Note that it is possible–in ColorTrace–to violate all in-
∆ ∆ ∆ ∆
θ Src θ Pkt θ Dst θ Pkt
variants if any of the participating blockchains is com-
Recolor
promised or malicious. A malicious or faulty network
∆ H
R can also potentially violate the global supply invariant,
∆
S
H
Remint Packet Vault one such example being the loss of network liveness re-
RemintSend ∆ K RemintReceive
sulting in the indefinite lockup of tokens or deltas in a
M Pkt

∆ K ∆ K Mint ∆
packet. These issues can be solved by using a permis-
V Src VPkt M M Pkt
sionless, lossless network such as LayerZero [4], but the
∆ K ∆ ∆ 0 Mint ∆
M Src M Pkt VPkt V VPkt
choice of network is orthogonal to this paper.
One potential attack vector is what we term flash rem-
Figure 7: Positive values are notated in green and nega- inting. A minter can gain a disproportionate distribution
tive values in red. The transfer example sends tokens of by acquiring a surplus for a very short period of time via
a surplus color from the source chain to the destination a flash loan and reminting that surplus. This can be miti-
chain. The synchronization example illustrates synchro- gated through a combination of timelocks and reminting
nizing a colored deficit and positive ∆θ . The reminting fees. First, we enforce that tokens added to a surplus
example demonstrates reminting an M-colored surplus or deficit can only be reminted or slashed respectively
collateralized against a V-colored deficit. after a timelock has expired (e.g., 1 block). Second, we
tune the reminting fees to be high enough that minters are
not incentivized to remint unless they are confident their
An alternative way to design the ∆θ synchronization mint will not be redeemed for at least a certain number of
layer is to restrict the synchronization of deltas to be distribution periods. This is not expected to be the case
unidirectional to the remint pool on the primary chain. for flash reminters, as their reminted surplus is likely to
Under this design, it is unnecessary to guarantee source quickly decay into a deficit.
chain convergence on SyncSend and divergence or im- Another potential attack vector is what we call the
balance can be directly handled in the remint pool. fugitive deficit attack. Theoretically, an entity can con-
solidate their deficits along with a corresponding ∆θ on a
5 Discussion single chain, then SyncSend their deficit upon observing
in the mempool a remint request that uses their color’s
The full architecture of ColorTrace is outlined in Fig- deficit as a counterparty. This prevents the aforemen-
ure 7, which illustrates the crosschain transfer of a sur- tioned remint request from slashing the attacker’s deficit
plus, ∆θ synchronization, local recoloring, and reminting and can cause grief due to failed remint requests. This
in a system of two secondary chains (source and destina- attack requires the entity to hold a significant amount of
tion), the vault, and three packets. assets to prevent ∆θ on the victim chain from becom-
ColorTrace makes it possible for holding-agnostic ing negative (and thus blocking their attempt to move
remint batching. In a lossless token coloring scheme, deficit), but in theory would allow a single entity that
an application can only remint as many tokens as they controls two colors to double the yield of their underly-
hold—that is, they must hold a token to burn it in ex- ing funds. This problem can be fixed using a threshold
change for an asset which is then used to remint a new to- control mechanism to temporarily restrict the movement
ken. Applications that create demand for very large asset of specific-colored deficits, or by restricting the routing
flows but only hold a relatively small quantity of tokens of ∆θ flows to prevent the creation of a tight loop on
would be forced to remint small quantities of tokens– a small set of low-cost blockchains. In practice, there
very often under a lossless scheme–thus resulting in high must also be a threshold for ∆θ synchronization, as small
crosschain messaging overheads and transaction fees. In deficits can be created using a small amount of capital
a ColorTrace deployment, this application can simply re- and would cost the synchronizing entity potentially large
color tokens as they flow into their wallet under the hope gas fees for the source and destination transactions on
that some portion of their recolorings are preserved in the top of the crosschain messaging fees. In addition, the

8
source chain and the destination chain for a synchroniza-
tion request should be different, to prevent trivial griefing
by attackers seeking to hide their deficit. Economic and
deficit availability semantics must be carefully defined
and implemented by the organization managing the to-
ken, but these details are orthogonal to this paper.

6 Conclusion
We present ColorTrace, an algorithm that implements ef-
ficient onchain attribution of fungible tokens by solving
the token coloring problem. A vault on the primary chain
governs the association of underlying value to onchain
colored tokens and token contracts deployed to a collec-
tion of independent blockchains conduct transactions and
periodically synchronize token recolorings to the vault.
ColorTrace is divided into a coloring layer and synchro-
nization layer. The coloring layer implements O(1) to-
ken transfers with predictable gas consumption for all
user-facing operations, but introduces entropy into the
system in the form of token recolorings and chain-local
∆ imbalances (nonzero ∆θ ). This divergence in the sys-
tem is resolved by the synchronization layer, which im-
plements safe and globally consistent synchronization of
recolorings to the vault. Both the coloring and synchro-
nization layers are provably safe by ensuring the net error
in the system is zero via the delta-zero invariant. Color-
Trace opens the potential for blockchain applications to
integrate more deeply with fungible tokens and enables a
more equitable Web3 ecosystem.

References
[1] A SSIA , Y., B UTERIN , V., L IORHAKI L IOR , M., ROSEN -
FELD , M., AND L EV, R. Colored coins whitepaper.
https://www.etoro.com/wp-content/uploads/2022/
03/Colored-Coins-white-paper-Digital-Assets.pdf.
[2] E NTRIKEN , W., S HIRLEY, D., E VANS , J., AND S ACHS , N. Erc-
721: Non-fungible token standard. https://eips.ethereum.
org/EIPS/eip-721.
[3] ROSENFELD , M. Overview of colored coins. https://
bitcoil.co.il/BitcoinX.pdf, 2012.
[4] Z ARICK , R., P ELLEGRINO , B., AND BANISTER , C.
Layerzero: Trustless omnichain interoperability proto-
col. https://layerzero.network/pdf/LayerZero_
Whitepaper_Release.pdf.
[5] Z ARICK , R., P ELLEGRINO , B., Z HANG , I., K IM , T., AND BAN -
ISTER , C. ColorFloat: Constant space token coloring. https:
//layerzero.network/publications/ColorFloat.pdf.