Following our framework of Aave’s infrastructure evaluation and the positive signaling by the community on the forum, we present the analysis of X Layer regarding its suitability to deploy an instance of the Aave v3 (v3.5, upcoming v3.6) protocol.
DISCLOSURE. This is an independent assessment of different technical components that we consider important for the Aave software to run optimally, not a categorical analysis stating the network is “good” or “bad”, and no kind of “requirement” for Aave to be deployed on the candidate network. That decision is up to the Aave governance, no matter our opinion.
In addition, currently, we have absolutely no financial/investment/services-engagement/any kind of interest in the X-Layer / OKX ecosystem.
When doing the evaluation, we contacted the X Layer team as an important source of information, which has always been exemplary and supportive, but everything in this report comes finally and exclusively from our independent criteria.
Report
1. Introduction to X Layer
X Layer is an L2 optimistic rollup by OKX, with EVM base compatibility and settling to Ethereum mainnet.
Additionally, X Layer is built on the Optimism OP-Stack and is really similar to Optimism mainnet, infrastructure-wise. As with all other optimistic rollups, X Layer is in an early stage. It is trying to improve its shape and infrastructure and address mechanics like its decentralization, cost of usage, or security.
Note: X Layer was previously a ZK L2 built with the Polygon Chain Development Kit (CDK), but the network went through an upgrade to migrate to the OP-Stack. At the time of writing, X Layer, even tho built on top of Optimism OP-Stack, is not a part of the superchain yet.
2. Our methodology
Methodology and scoring details
This report does not attempt to provide a full, detailed analysis of the X Layer network. Instead, it focuses on the high-level aspects necessary for the Aave community to decide whether to deploy the Aave v3 (v3.6) liquidity protocol there.
In addition to being extensive, this report tries to be simple enough for all participants in Aave governance to understand. However, given its technical nature, it is unavoidable to assume a certain familiarity with some relevant concepts, such as rollups, oracles, RPC nodes, or blockchain explorers, among others.
In order to simplify the interpretation of this report, we will evaluate each key component for Aave separately, and assign simplified “grades”, defined as follows:
Optimal. Fulfilling all minimal requirements, and with extra positive aspects.
Good. Fulfilling the requirements, but improvements can be made.
Acceptable. Fulfilling the requirements, but with “buts”.
Needs improvement. Mandatory requirements were not fulfilled at all. Aave will not work properly
3. Evaluation
3.1. Oracle Infrastructure
The Aave protocol uses various types of oracles within a standalone blockchain. We consider it essential to have Chainlink providing oracles for prices in any deployment, with alternatives only considered on an ad-hoc basis due to the additional complexity introduced during evaluation and integration.
In the case of networks like X Layer, we evaluate full optimality if said price feeds are available.
| X Layer Network | Oracle Infrastructure available | Info/Links |
|---|---|---|
| Chainlink Price Feeds |  |
Chainlink docs |
3.2. Blockchain explorer
For Aave, same as for any other blockchain project, block explorers like Etherscan are a fundamental component, specifically for the following:
- Verifiable smart contracts code visualization.
- Read/write interface with smart contracts.
- Basic data analysis tool for misc aspects like token holders.
X Layer DOESN’T HAVE an Etherscan instance. Alternatively, the official explorer deployed is the OKX Explorer.
3.3. Compatibility with Ethereum RPC standard
Basic compatibility with the Ethereum nodes RPC de-facto standard (eth_, web3_) is quite an important requirement for Aave or any other protocol, given that it helps to have tools built for Ethereum (or other similar networks) working out-of-the-box just by plugging them to node, of X Layer in this case.
X Layer HAS complete compatibility, with the main node being op-geth, an adaptation of go-ethereum. Depending on the node provider, there can also be support for non-standard endpoints (e.g., trace_*) in the future.
3.4 Compatibility with Ethereum account format (addresses)
One of the strengths of non-Ethereum networks (e.g. Polygon, Avalanche C-Chain, etc) is its compatibility with Ethereum private/public keys of accounts. This allows existing account holders on those networks to use the others without creating an ad-hoc wallet for it.
X Layer is fully compatible with the Ethereum account format.
3.5. RPC public endpoints and providers
Basic and reliable public RPC infrastructure is a must for Aave, as it is the way to connect to the network, both for data reading and transaction submission.
X Layer HAS an official endpoint at https://rpc.xlayer.tech
Third-party RPCs like QuickNode and GetBlock are also available and can be found in the official X Layer documentation here.
3.6. Custom behavior (lack of) of the execution layer
Whenever a network has custom/extended behavior with respect to Ethereum, it is important to be aware of it and evaluate if it has any impact on the Aave protocol.
Examples of this potential behavior are the presence of new pre-compiles (compared with Ethereum or similar rollups like Optimism), EVM opcodes, native account abstraction/meta-transactions, chainId definition out of the norm, etc.
X Layer is fully aligned with the Optimism execution layer implementation, being part of the OP-Stack. This is really important from Aave’s perspective, given the protocol is already flawlessly running on Optimism mainnet.
Even if not doing a full evaluation of the Optimistic Virtual Machine implementation (it is a relatively daunting task), we have checked the following, given that historically have been critical aspects:
-
The
chainIdbehavior is appropriate, with the id196for X Layer not clashing with any other. -
There are no extra opcodes compared with Optimism.
-
There are no extra pre-compiles compared with Optimism.
-
As part of an extra security procedure, we deployed a test instance of the Aave v3.5 protocol on X Layer network and performed end-to-end tests on core protocol functionalities. We found no issues during testing, and the protocol behaved consistently with deployments on other networks.
Additionally, we have a confirmation from the X Layer team that there is no custom basic behavior affecting the model of execution on the virtual machine.
3.7. Support of wallet providers
Wallet products like Metamask, Ledger, Kraken Wallet, and others are fundamental pieces of the infrastructure for users to access the Aave protocol. So it is a strong requirement for a network to be supported by a subset of them.
Given its EVM compatibility in the context of this document, X Layer is transparently supported by the majority of chain-agnostic wallets, such as Metamask, Ledger, Rabby, Kraken Wallet, or Frame.
3.8. On-chain multi-signature infrastructure
The permissions on the Aave ecosystem are directly held by on-chain governance smart contracts or scheduled to be like that once cross-chain governance infrastructure can be applied across all the networks.
However, different protection/emergency mechanisms, like the capability of canceling cross-chain governance proposals, or pausing an Aave asset/pool, depend on the Aave Guardian, who is capable of acting faster than the governance process.
Consequently, having on-chain multi-signature contracts is a requisite to have Aave on a different network, with a high preference for industry-standard tools like Gnosis Safe.
X Layer HAS an official instance of the Gnosis Safe contracts on-chain, supported natively inside the official interface.
3.9. Transactions simulation infrastructure (fork)
The ability to execute test transactions (simulations) on forked production networks is a core part of the Aave development and review workflow.
A good part of the tooling around Aave depends on simulations by using different libraries/frameworks like Hardhat, Foundry, or Tenderly. This way, it is possible to rapidly prototype new developments, get extra assurances on governance proposals and protocol upgrades, change risk parameters, etc.
Within this stack, support for both Foundry and Tenderly is considered a hard requirement for deploying Aave on a given network.
In terms of tooling that can be used for simulation supporting X Layer:
- Tenderly is supported on X Layer.
- Foundry and Hardhat are supported on X Layer.
3.10. Chain data/indexing solutions
For different projects and entities integrating Aave, and even if not a blocker for deployment, it is important that solutions like TheGraph or Dune are operating on the candidate network, to avoid building from scratch data pipelines.
Currently, X Layer is only supported on TheGraph.
3.11. Bridging infrastructure: assets, messages
Given the central role of Ethereum in the DeFi and Aave ecosystems, proper bridging infrastructure to/from is a must for any candidate network.
3.11.1 Assets Bridging
X Layer does not support native asset bridging using the OP-Stack StandardBridge, however users can bridge assets using third party providers via Cross-Chain Bridge | Transfer Crypto Assets Across Blockchains | OKX Wallet.
Most of the assets including USDT0, sUSDe, USDe, USDG and xBTC are based on LayerZero’s Omnichain Fungible Token (OFT) standard, which is acceptable. There is no way to bridge OKB token natively to X Layer, except for using third party bridges and the OKX exchange.
3.11.2 General Message Bridging
X Layer supports bi-directional generic message passing via the native L1CrossDomainMessenger bridge, with the same mechanism as Optimism. This is especially important for Aave in order to activate cross-chain governance.
X Layer also supports generic message passing via third-party systems like LayerZero and Wormhole.
3.12. Commitment to security incidents
Having proper mechanisms and procedures to prevent and react to security incidents is something quite fundamental for any platform and application, and networks like X Layer are no exception.
Apart from the extensive security procedures inherited from the OP-Stack, the X Layer team will keep a private channel of communication with the assigned technical team of the Aave community (e.g. BGD), for any incident of update concerning the network and consequently, Aave on X Layer.
Finally, we are aware X Layer will leverage OKX’s security, which further solidifies this part of the evaluation.
3.13. Network security/technical model
At the core of any candidate network analysis are its morphology (which type of network it is) and security model (which parties are involved in the control over the network; decentralization degree).
Regarding its morphology/type, X Layer is technically an optimist rollup as an instance of the OP-stack, which is similar to the Optimism mainnet.
Regarding its security model, X Layer’s approach is almost the same as Optimism’s mainnet: X Layer benefits through Optimism’s shared security approach and the so-called Fault proofs, which allow users to withdraw ETH on mainnet from the OP stack with a withdrawal proof that it was included in the OP stack chain.
3.13.1. Centralization points
- X Layer has a single and centralized sequencer, receiving transactions, processing them, and doing the roll-up to be settled on Ethereum mainnet.
- The X Layer infrastructure of smart contracts on Ethereum is generally upgradeable and controlled via an intermediate contract. This is not ideal, and the X Layer team confirmed that it would be migrated to a multi-sig soon.
- On the L2, a proxyAdmin that can upgrade all contracts without a timelock is controlled by an EOA, which the X Layer team also confirmed would be migrated to a more secure multi-sig.
Please note: This badge is conditional on the X Layer team migrating their intermediate contract and L2 proxyAdmin owner to a multi-sig wallet.
3.13.2. Upgradability strategy and sync with OP-Stack
In terms of upgrades and the procedures surrounding them, we have confirmed with the X Layer team that:
- There is a series of procedures to keep X Layer in sync with the OP-Stack infrastructure, both in terms of off-chain components (e.g., sequencer) and smart contracts. All introduced changes on the OP-Stack are to be reviewed and quality-tested by the X Layer team.
3.13.3. Security procedures
We have directly checked with the team and confirmed the following:
- Being part of the OP-Stack, X Layer inherits the security assurances of Optimism, being:
- All layers were audited by multiple parties: OpenZeppelin, SigmaPrime, Trail of Bits, Sherlock and Code4rena.
- The collaborative approach between 2 different teams like OKX’s and Optimism’s on the OP-stack gives extra security assurance.
- OKX also has an ongoing bug bounty program.
An overview of all of X Layer’s infrastructural smart contracts can be found here. These smart contracts seem aligned with the OP-stack contracts.
4. Summary
From our analysis, we conclude that X Layer, even at a really early stage, is an acceptable network candidate in regard to technical requirements, conditional on the X Layer team migrating their intermediate contract and L2 proxyAdmin owner to a multi-sig wallet.
Our main consideration for this conclusion is the inherited infrastructure from the OP-Stack, and the presence of Aave on both Optimism mainnet, Base, and Metis Andromeda, a fork of it.
An expansion of Aave there will imply allocating some development resources for the initial setup and some overhead of maintenance and monitoring over time, similar to other networks like Optimism.
Similar to other optimistic rollups, there is an important degree of centralization, but this is expected given the developing stage of this technology. It is up to the community to decide if the risks derived from this centralization are worth it.