Pickle (⬡,⬡)
Pickle (⬡,⬡) 23 minutes reading from Chainlink

Chainlink vs. Chainlink: An Interview with Chainlink’s Founder

web3 crypto Layer0 wars are here, forget about L2s.

There have been lot of bad takes on twitter since @StargateFinance went live. Let's dive deep for some alpha.


Vs @Chainlink CCIP LINK


Layer 0 Wars: LayerZero vs Chainlink's CCIPLayer 0 Wars: LayerZero vs Chainlink's CCIP

The article is extensive on both protocols and in alpha. I recommend everyone read it. Especially for users of bridges and holders of their tokens.


Here's the 🧵

What's a layer0 protocol?

I define it as: A communication protocol, enabling smart contract execution across multiple chains, with one transaction from any one source chain enabling cross-chain functionality for dApps and (native) token bridging

Why is this important? For any DeFi users across multiple chains, it should be self evident, even more so for the multi-chainooooors.

@LayerZero_Labs protocol is the child of @PrimordialAA and

@ryanzarick with input from well known ex-Sushi developer (and Tokemak advisor) @0xMaki

'LayerZero, the first trustless omnichain interoperability protocol, which provides a powerful, low level communication primitive upon which a diverse set of cross-chain applications can be built. Using this new primitive, developers can implement seamless inter-chain ...

..applications like a cross-chain DEX or multi-chain yield aggregator without having to rely on a trusted custodian or intermediate transactions.'

How does LayerZero work?

'LayerZero Endpoint exists on each (supported) chain, and any chain with a LayerZero Endpoint can conduct cross-chain transactions involving any other chain with a LayerZero Endpoint. In essence, this creates a fully connected network where every node has a direct connection to'

Let's run an example: 1. Cross-chain action committed on chain A (e.g. against a deposited asset in a lending protocol on ETH, borrow USDC from the same lending protocol on Polygon) and sent to the endpoint.


The endpoint sends information to the Relayer and Oracle - both separate entities and both off chain.


The Oracle confirms the block header (the oracle on testnet was Chainlink)

4. The Relayer confirms the transaction on chain A (it’s function is similar to an Oracle but looking for a different bit of data).

5. Presuming everything is in order, the rest of the action stated on chain A is committed on chain B (USDC is received in wallet on Polygon).

If there is any contention between the Relayer or Oracle as to information being passed on, the smart contract is paused and not committed to chain B.

'To ensure valid delivery, the only requirement is that for any given message sent using the LayerZero protocol, the Oracle and Relayer must be independent of each other. The protocol itself does not require any specific implementation of a Relayer, and in theory the users of...

LayerZero could even implement their own Relayer service. This design allows users to be sure that the Relayer cannot collude with the Oracle, and this independence is what allows us to implement trustless validated delivery.' Also quoting from Primo in the discord, see attached

There is a presumption that LayerZero will tokenise eventually, and likely have a staking element to its operations and potential slashing (loss of staked ZRO tokens) for bad actors/malicious behaviour of relayers, presumably. This is all conjecture and no confirmation yet.

CCIP was announced in August 2021 during the now annual Chainlink SmartCon event by the CEO and co-founder Sergey Nazarov. In addition to this, the primary source of information is the official Chainlink site.

Cross-Chain Interoperability Protocol (CCIP) | ChainlinkCross-Chain Interoperability Protocol (CCIP) | Chainlink

@alpha_pls produced

fantastic thread summarising CCIP

Aylo on TwitterAylo on Twitter

CCIP will fit into the wider middleware infrastructure that Chainlink have been building

since 2017 and will take advantage of pre-existing innovations including OCR and Decentralised Oracle Networks (DONS) to enable high throughput off-chain computations + oracle functions

Much of what we know of CCIP thus far is discussed by Ben Chan in the below video, and also provides foundational knowledge regarding the current Chainlink infrastructure relating to this.

Ben Chan: Exploring the Cross-Chain Interoperability Protocol (CCIP)Ben Chan: Exploring the Cross-Chain Interoperability Protocol (CCIP)

CCIP will include all the functions discussed above in relation to LayerZero, including a programmable token bridge to allow similar DApps to Stargate Finance to be built out.

The additional innovation with CCIP, as mentioned in the youtube links above, is the creation of ‘Hybrid Smart Contracts’ which will enable both on-chain and off-chain smart contracts to work together, in conjunction with cross chain execution.

CCIP equivalent to LayerZero endpoints are called ‘messaging router smart contracts’ which from here on I was refer to as MRSCs.

n CCIP there is not significant differentiation between relayer and oracle functions and are both done by the Chainlink DONS which must agree information matches and is accurate, before passing information on from chain A (through MRSCs) to chain B (through MRSCs).

In my humble opinion, this is no less secure, and in fact potentially more secure than the LayerZero design, as things stand.

In addition to the functions which are similar to LayerZero, CCIP will have the Anti-Fraud Network, as discussed by Ben in the above presentation. This will be a separate set of nodes to those processing cross-chain transactions which will monitor for discrepancies and pause...

he smart contract function if something inconsistent is detected between executed transaction messages and the state of chain A in a transaction. This can be considered an additional layer of security on top of what is comparable on LayerZero.

Unfortunately beyond what I’ve stated, the rest would be inference and conjecture as CCIP is yet to go live and documents regarding its implementation are not yet available. The presumption is that the Anti-Fraud Network nodes will have similarly high levels of decentralisation..

to current DONs/the DONs acting as the traditional Oracle and Relayer for the cross-chain transactions.

The other major presumption within the community is that explicit staking will go live alongside/very near the time of CCIPs release.

It would strengthen economic incentives for the node operators to work correctly and potentially institute slashing for bad actors. All of this is yet to be clarified or corroborated officially by the team, who are notorious for playing their cards close.


Firstly, and most importantly, the issue has been raised that the oracle currently on chain is not Chainlink. The current oracle provision is not currently decentralised or battle tested, which does mean there is a higher chance of exploitation or hacks.

Primo has confirmed, as with their testnet, the primary oracle available will be Chainlink soon. Primo stated this to me in a direct chat days before this came up as an issue on social media, this was not a quick response to allay fears, but their long-term plan already.

Next issue; relayer.

The relayer being an independent/separate entity from the oracle is noted to allow for trustless and more secure transactions in the whitepaper, but I think this needs further exploration.

zefram.eth (🏎,🐙,☯,⭐️,🐰,🐮,🕹) on Twitterzefram.eth (🏎,🐙,☯,⭐️,🐰,🐮,🕹) on Twitter

Firstly, it may well be difficult to ensure that they are independent entities.

By allowing DApps to choose their own oracle and relayer (permissionless), malicious attacks could be permissible whereby both the chosen oracle and relayer collude to, for example...

..pretend an asset is being bridged, resulting in minting of assets on chain B, while retaining them on chain A as well. Collusion is very possible.

Realistically, this is the same risk as any DApp has and should be fairly transparent when DApps are planning to act in a malicious way from published smart contracts on chain, before any funds are stolen.

Also, it’s almost certain every serious DApp would use Chainlink for the oracle portion of their DApp. If the relayer acts maliciously/is hacked/doesn’t work, the LINK oracle will disagree with the outcome and prevent any losses beyond gas for execution on the originating chain

Are there potential benefits to an ‘independent’ relayer from the oracle (read: run by a separate entity)? Yes. To quote Primo again from a brief chat with him

Some assumptions have to be made here for this to be an effective and realistic alternative to just using Chainlink for both actions;

1) Chainlink nodes are fallable (no system is perfect, but the battle-hardened protocol has only had one notable mistake, which was not an Oracle issue but a human error of mispricing silver with gold price for on-chain feeds in February 2020)

2) Chainlink nodes do not have sufficient incentives to prevent malicious actors from providing wrong Oracle data (the DONs system would mean the majority of nodes, in a large collection, would have to collude together, against their own interests, whilst also all being KYC’d..

and well established participants who would have massive reputational damage from such actions). This has not yet happened for any aspect of Chainlink Oracle functions.

3) A separate Relayer system to the Oracle system (which will inevitably be Chainlink, for obvious reasons, in all serious dApps moving significant value) can be more trusted (or ‘trustless’) in comparison to Chainlink nodes.

For 3. to be true, the proposed Relayers from LayerZero would need to be more decentralised with better economic (and future staking) incentives compared to Chainlink nodes, with back-up systems in place were they to fail, of similar calibre to Chainlink DONs.

Relayers being optionally created and run by dApps directly seems to be unrealistic for most protocols, for similar reasons to why most dApps choose to use Chainlink instead of their own Oracle for price feeds these days -

it’s another piece of infrastructure they’d rather not build, secure or maintain themselves, and they’d unlikely be able to produce something better or more decentralised than what already exists. Therefore, I suspect most would opt for LayerZero’s own Relayers,

or request Chainlink to perform both functions.

Ultimately, the Relayers used would have to be comparable to Chainlink DONs to make it worthwhile separating this function from the Oracle.

I think a separate Relayer function was partially instituted to reduce dependence on Chainlink, not necessarily from a security or safety perspective alone, but potentially to differentiate it from CCIP and provide more value to LayerZero (this is just me waxing lyrical).


I think having a Relayer and Oracle separated is not important, and potentially a hinderance unless done very very well. At that point LayerZero is at the very least comparable, if not better, due to sharded security.

For the sake of argument, let’s presume LayerZero and CCIP off-chain handling of Relayers and Oracle functions are equally good. What’s left to differentiate things?

1. On-chain smart contracts enabling their functions (LayerZero endpoints vs CCIP MRSCs)

2. CCIP’s Anti-Fraud Network

3. Reputation

For both 1. and 2., we do not yet have any more detailed specifics, but given Chainlink’s history, I would expect mainnet production of both to be highly tested and audited and likely to function well. Assuming on-chain smart contracts are comparable between both protocols,

then it comes down to whether the Anti-Fraud network would provide an additional layer of security (and not just complexity) to CCIP. If this is the case, then CCIP would be a better protocol for both dApps and users.

For 3.

Chainlink has a longer history and reputation for delivering safe and secure middleware infrastructure. LayerZero is new, but headed by a group of clearly intelligent and innovative developers. Time will tell how their reputation develops.

Closing thoughts Despite what I’ve said above, which leans towards CCIP, that does not mean CCIP will be more successful. Adoption of technology often comes down to being first to market, having better publicity and having better network effects, whilst being ‘good enough’

An apt comparison proving this is VHS vs Betamax.

Even then, the space may not be truly ready for cross-chain dApps, and something entirely different, further down the line, may win out. IBC is a real contender, especially with greater finality, which is interpreted differently by LayerZero and CCIP.

There have been murmurings for some time of certain DeFi 1.0 lending protocols on Ethereum using CCIP once it is ready. I think certain DeFi protocols will be ‘kingmakers’ in the layer 0 wars, and likely lead to other dApps following their lead. If they go for LayerZero,

it will certainly be hard for CCIP to overcome.

Bridges, whilst highly important, have no real moat of technology on the dApp level as things stand. They are as forkable as DEXs and would require some novel technology or network effects for a long period to ensure their

long-term success. Both LayerZero and CCIP have/will have the basic token bridge infrastructure to allow for multiple bridges, and I suspect there may be a ‘race to the bottom’ for lowest fees to encourage adoption, whilst incentivising both liquidity and holding of their token

(akin to vePTP or veCRV or veJOE models). This is a small warning to those fully and completely invested in Stargate Finance’s ( STG ) future.

To summarise, I think Chainlink and LayerZero are both good for each other. CCIP has been in the shadows for nine months, in development, and Layer Zero’s release may well push the Chainlink team to get it out sooner.

CCIP in turn encourages LayerZero to keep innovating and improving to ensure the head start it’s gained is maintained.

Competition is good, progress is good. Twitter makes everything seem PvP but I think most blockchain developers, certainly my impression of these two groups, is that they are here to move us forward and that’s good for all of us.

This post is based on this twitter thread.


Please login to comment.