ColorTrace is a practical solution to the colored coin problem. Colored coins set out to create distinction among a group of fungible assets by coloring individual coins, which can be thought of as the ‘marking’ of a bill of fiat currency. Each bill is equally spendable and yet you know unique characteristics about each based on their markings, such as who held them before, where they were printed, etc.

The original Colored Coin algorithm aimed to solve this through a lossless metadata layer on top of the bitcoin ledger, but more generally in EVM would be akin to keeping an infinitely large ledger list of every address of every possible colorer and their current balance per wallet. This is intractable in both storage and compute and, as such, has never been viable to implement- leaving there few good avenues for accurate onchain value attribution.

Introducing ColorTrace.

For a practical example of ColorTrace, we’ll walk through the implementation used by USDV in their recent launch of the stablecoin.

The problem to be solved was that much of the value of existing stablecoins were driven by the market participants themselves. Groups like Uniswap, Curve, Coinbase, and Binance have moved trillions of dollars of stablecoins and given immense utility to their underlying ecosystems and yet only one of those has ever been directly rewarded for it. Circle entered into a custom agreement with Coinbase to share the yield of USDC based on Coinbase’s contributions to the success of USDC. For this Coinbase currently earns almost $1B per year. The simple solution would be to create similar deals with all other major parties, but this is where the tricky part comes in. Imagine a world today where $24B of USDC sits in circulation, with the majority in EOAs. How much yield goes to each party? For the balance sitting in Uniswap, Curve, Coinbase, and Binance it’s easy to see how much each party has contributed, but for the more than $10B+ sitting in user wallets and EOAs it’s hard to know how much each group has contributed to that.

This is where onchain value attribution comes in. ColorTrace unlocks the ability for each entity to receive pro-rata attribution for the value they have created for the underlying ecosystem. In the case of USDV, this means that each token an entity has minted into circulation will be marked with their color and be attributed to them until it is redeemed for the underlying asset — a true onchain meritocracy.

Extending beyond USDV, ColorTrace can be used for things like onchain ref links, affiliate programs, and really any use-case that allows for protocols to reward participants fairly for any value accretive action.

For a deeper look at the design of ColorTrace and the other algorithms created along the way, read Solving Fungible Token Coloring — A Nerds Version

Introduction to ColorTrace was originally published in LayerZero Official on Medium, where people are continuing the conversation by highlighting and responding to this story.

So why does this matter? To explore, let’s look at the negative repercussions of a messaging protocol with no fair ordering.

Scenario: The small (fictional) European country of Maltovania has moved its election voting on-chain such that its users can vote from multiple blockchains and the votes will be aggregated and counted on Arbitrum. When the smart contract expires at midnight on the 7th day the votes will be locked and the election is decided and the country (or DAO) has agreed to abide by the results of the smart contract who will issue a 4-year soulbound NFT to its new president.

As the votes tally in the election is extremely close, with the incumbent party at 49.7% of population vote and the challenging party at 49.6% of population vote. In a backroom deal the incumbent party bribes the existing validators to conveniently forget to deliver a few packets containing votes for the challenging party. Since there is nothing to prevent this, the vote concludes at midnight with the incumbent party remaining in power and is only discovered later that packets were dropped and chalked up to technical error that exists within the system.

Scenario: One of the largest incumbent HFT firms in traditional finance has found it harder and harder to compete. They used to make up almost 25% of the $10B+ annual profit that the HFT industry captures every year by being the fastest to frontrun retail and institutional order-flow to each other exchange as orders are being executed. It was about this time that they were really beginning to feel the effects of that increasingly competitive HFT landscape that they discovered the world of decentralized finance and blockchains.

As they were exploring this world they set to designing a system such that they would always have a monopoly over the industry of frontrunning and value extraction over all transaction execution. At first they came to the obvious conclusion, if we simply own the flow of messaging we can always insert ourselves first and frontrun each transaction upon submission without the need for any other competitive party to exist.

‘As long we can convince others to use our messaging protocol they thought, we will always have complete rights to all extractable value. What they didn’t realize until later is that this was just the tip of the iceberg, eventually they realized that without any sort of enforced ordering they could not only frontrun each individual message, but they could re-order the messages as well! By omitting forced ordering they now were able to hold back and delay specific transactions and re-order the entire in-flight psuedo mempool such that rather than extracting simply the maximum from each individual message they could extract the maximum across the entire surface of in-flight messages. Creating an entirely new segment of extractable value that didn’t exist before (and thus an additional tax on each end consumer).

LayerZero’s messaging guarantees that each and every packet will be delivered in the exact order it was received. This means that messages can never be re-ordered

And completely removes the ability to censor individual packets, where any attempt to drop a single packet would halt the entire pathway

When designing our system the core principle of Censorship Resistance underpinned every technical decision made. We knew we were building a system that needed to be able to be used at scale across use cases as diverse as running governmental elections to underlying the infrastructure of the entire financial system and in doing so if you build a system that can be exploited it will be exploited.

LayerZero’s messaging is immutable, censorship resistant, and entirely permissionless.

Come unlock immutable messaging within your application today https://layerzero.gitbook.io/docs/

Nonce-Order Enforcement was originally published in LayerZero Official on Medium, where people are continuing the conversation by highlighting and responding to this story.

There was a lot of discussion yesterday and a lot of misconceptions so I’m going to walk through LayerZero from first principles. What it is, how it works, what guarantees developers have and the best practices for security.

What is it?

LayerZero is a messaging protocol allowing arbitrary contract invocation across chains with an included payload.

How does it work?

A developer deploys a contract on multiple chains, let’s call these Chain A and Chain B. A transaction is committed on Chain A which constructs a resulting message to be passed to the contract on Chain B. The contract interacts with LayerZero Endpoint and then a few things happen — The application’s selected oracle and relayer retrieve the corresponding block header and tx proof. They wait for the application-specified number of block confirmations on the source chain, and then each delivers their piece independently to Chain B. On Chain B these pieces are validated via a Validation/Proof Library, followed by delivering the message contract on Chain B.

A simple example of this in production might be bridging on Stargate, a swap using SushiXSwap, or moving your Lil Pudgy across chains.

What guarantees do developers have?

Well, there are four real components here: Relayer, Oracle, Validation/Proof Library, Block Confirmations

The application can have complete control over each of these components. I’ll walk through what those controls look like below:

Relayer — Relayers are completely open and permissionless. The application may select any existing Relayer, including the ability to operate their own and select themselves. Relayers can be a network of relayers or as simple as a single signer.

Oracles — Oracles are completely open and permissionless. The application may select any existing Oracle, including the ability to operate its own and select itself. Oracles can be a network of oracles or as simple as a single signer.

Validation/Proof library — Libraries are published in an append-only registry, new libraries can be published but existing libraries can never be modified and are completely and irrevocably immutable. The application may select any existing library (which all have public audits) to perform its validation. An append-only registry allows for unlimited flexibility as new proofing mechanisms are invented, advances in fields such as zero-knowledge proofs emerge, and general optimizations around gas and utilization are made.

Block Confirmations — Block confirmations are the number of blocks that must be completed on the current source chain before a message can be passed to the destination chain. This number varies widely across consensus mechanisms and in systems with probabilistic finality are ways for applications to control the finality of a given block — much like centralized exchanges do before accepting deposits from a given chain.

If an application configures these parameters it will look like this

If an application does not setup its configuration then it uses the ‘Default’ settings which basically is just a pointer to some pointer.

In Scenario A, when an application has set its config of [ULN v2, Relayer A, Oracle Z, Block Confs X and Proof Lib V1]] there is nothing any other system in the world can do to modify these selections. At this point, Relayer A will be used with Oracle Z, all messages will be validated through ULN v2 and Proof Lib v1 after waiting for X block confs.

In scenario B when an application is using the default settings, it means that they are ceding control of the selection of these items to the LayerZero multisig. The only things that the LayerZero multisig can do is to add new libraries and change the defaults. Selecting this means that the application is delegating trust to the LayerZero multisig in selecting these items and not acting maliciously.

So, let’s discuss what the current state of the world is and what can and can’t be done.

Most generic messaging systems today work something like this

Messaging systems such as Wormhole, Nomad, etc. all work in a similar manner. All of the control sits in the [system] and can be upgraded by whoever controls the admin keys for those systems (In Wormhole’s case this is the 13/19 multisig of validators). This has previously been extremely problematic resulting in multiple issues for Wormhole and Nomad and is generally seen as unsafe practice for applications. Using LayerZero’s defaults is exactly equivalent to these systems, the application is delegating control of parameters to an external set of admin keys and relying on those parties to not act maliciously.

The difference is with each of those systems an application does not have any control and cannot ever prevent the [system] from forcing these upgrades on them and changing the underlying messaging behavior or the trust assumptions for the protocols.

LayerZero gives each application a way to explicitly choose a concrete set of security parameters that can never be modified or changed on them. We believe critical infrastructure should be immutable, open source, and always owned by user applications.