Following our framework for evaluating Aave’s infrastructure and the positive signaling from the community on the forum, we present an analysis of the Plasma network regarding its suitability for deploying an instance of the Aave v3 (v3.5) protocol.
DISCLOSURE. This is an independent assessment of different technical components that we consider important for Aave software to run optimally. It is not a categorical analysis stating the network is “good” or “bad”, and it does not impose any requirements for Aave to be deployed on the candidate network. That decision is up to Aave governance, regardless of our opinion.
In addition, we currently have no financial, investment, services, or engagement interest in the Plasma ecosystem.
Report
1. Introduction to Plasma
Plasma is an EVM compatible L1 that is purpose-built for global stablecoin payments. It features a fully EVM-compatible execution layer with a custom PoS (Proof-of-Stake) PlasmaBFT-based consensus layer to optimise for high transaction volume and low latency.
Plasma uses the XPL token for gas payment and to participate in the consensus mechanism/governance of the network.
Please note: At the time of publication, Plasma is operating in a Private Mainnet state, and we were granted access to this preliminary infrastructure to conduct our analysis. As this represents early-stage deployment, our findings reflect the current state of the network and may be subject to changes as the infrastructure continues to develop.
2. Our methodology
Methodology and scoring details
This report does not attempt to provide a full, detailed analysis of the Plasma network. Instead, it focuses on the high-level aspects necessary for the Aave community to decide whether to deploy the Aave v3 (v3.5) 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.
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 Plasma, we evaluate full optimality if said price feeds are available.
| Plasma Network | Oracle Infrastructure available | Info/Links |
|---|---|---|
| Chainlink Price Feeds |  |
Plasma docs |
3.2. Blockchain explorer
For Aave, as for any other blockchain project, block explorers like Etherscan are a fundamental component, specifically for the following:
- Verifiable smart contract code visualization.
- Read/write interface with smart contracts.
- Basic data analysis tool for miscellaneous aspects, like token holders.
The official blockchain explorer of Plasma can be found at http://plasmascan.to/, which is an instance of Routescan.
Even though Plasma does not have an official instance of Etherscan, the Routescan instance is acceptable.
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 a node, of Plasma in this case.
Plasma HAS compatibility with Reth client. Depending on the node provider, there can also be support for non-standard endpoints (e.g. trace_*, debug_traceTransaction).
3.4 Compatibility with Ethereum account format (addresses)
One of the strengths of non-Ethereum networks (e.g., Polygon, Avalanche C-Chain, etc.) is their compatibility with Ethereum’s 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.
Plasma 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.
Plasma HAS an official endpoint at https://rpc.plasma.to
Third-party RPCs like Quicknode and Tenderly are also available and can be found in the official Plasma documentation here. As per communication with the Plasma team, the consensus node is not public, so running your own non-validator node is not available, but it should be made public soon after the public launch.
3.6. Custom behaviour (lack of) of the execution layer
Whenever a network has custom or extended behavior concerning Ethereum, it is important to be aware of it and evaluate whether it has any impact on the Aave protocol.
Examples of this potential behavior include the presence of new pre-compiles (compared to Ethereum or similar rollups like Optimism), EVM opcodes, native account abstraction and meta-transactions, and chainId definitions that are out of the norm, etc.
Given the alignment with the Reth node implementation, we checked that:
- The
chainIdbehaviour is appropriate, with the id9745for Plasma not clashing with any other. - Currently, Plasma supports the latest Prague EVM version.
- The execution layer runs on the upstream Reth client and has no custom changes.
- As part of an extra security procedure, we deployed a test instance of the Aave v3.5 protocol on the Plasma 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.
3.7. Support of wallet providers
Wallet products like Rabby, MetaMask, Ledger, Coinbase Wallet, and others are fundamental pieces of infrastructure that allow 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 major EVM compatibility, Plasma IS supported by the majority of chain-agnostic EVM wallets.
3.8. On-chain multi-signature infrastructure
The permissions in the Aave ecosystem are directly held by on-chain governance smart contracts or are scheduled to be like that once cross-chain governance infrastructure can be applied across all networks.
However, different protection and emergency mechanisms, such as the ability to cancel cross-chain governance proposals or pause an Aave asset or pool, depend on the Aave Guardian, who can act faster than the governance process.
Consequently, having on-chain multi-signature contracts is a prerequisite for having Aave on a different network, with a high preference for industry-standard tools like Gnosis Safe.
Also, having alternative interfaces ensures continuous access and functionality in the case the official one is inaccessible for any circumstance.
Plasma does not have support on the official instance of the Safe{Wallet} contracts.
However, an alternative interface for accessing Plasma Safe contracts is the Protofire Safe interface.
3.9. Transactions simulation infrastructure (fork)
Lately, a really important development experience component is the ability to execute test transactions (simulations) on forked production networks.
A significant part of the tooling around Aave depends on simulations using different libraries and frameworks, such as 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.
In terms of tooling that can be used for simulation supporting Plasma:
- Tenderly has support for Plasma.
- Phalcon simulator does not have support for Plasma.
- Foundry and Hardhat are supported on Plasma.
3.10. Chain data/indexing solutions
For different projects and entities integrating Aave, even if it’s not a blocker for deployment, solutions like TheGraph or Dune must be operating on the candidate network to avoid building data pipelines from scratch.
Plasma is not supported by TheGraph, but has an alternative subgraph support via Goldsky. In addition, there are other indexing solutions available as well, like Quicknode streams.
Plasma currently does not have support for Dune, but the team has confirmed that it will be added soon.
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. There are 2 types of bridging affecting Aave: assets and generic messaging. In the case of Plasma, the state of these 2 types is as follows:
Assets bridging: sub-use case of the generic messaging infrastructure focused on assets like ERC20 or ERC721. In the case of Plasma, there is no so called “native” bridge of the network, but the team operates a bridge solution built on the Stargate infrastructure. The bridged assets will be based on LayerZero’s Omnichain Fungible Token (OFT) standard, which is acceptable.
Generic messaging: Plasma does not have a native bridge at the moment, but third-party bridges like Chainlink CCIP, LayerZero and Hyperlane are present, making the Aave a.DI infrastructure compatible.
3.12. 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 controlling the network, its degree of decentralization, mechanisms, and procedures for preventing and responding to security incidents).
Regarding its morphology/type, Plasma is technically a layer one blockchain, very similar to Ethereum itself.
Regarding its security model, the approach of the Plasma network is similar to other Proof-of-Stake blockchains:
- The network uses a custom consensus layer PlasmaBFT, a pipelined implementation of Fast HotStuff written in Rust, and the execution layer is handled by the Reth client, which is fully compliant with the upstream version.
- The custom consensus mechanism PlasmaBFT finalizes blocks in rapid succession without relying on slot-based finality.
- The network separates validator nodes (which propose and finalize blocks) from non-validator nodes. The non-validator nodes, which serve RPCs and follow the chain without affecting consensus, fully ‘follow’ a trusted validator for finalized blocks and fork-choice updates.
- In case of a misbehaving validator, the network does not slash the staked asset, but rather only slashes the rewards.
3.12.1. Centralization points
At the launch, there will be only a small group of validators proposing and finalizing blocks with no permissionless participation. This is according to their progressive decentralization model, starting out with a small group of validators and gradually supporting the permissionless participation of validators.
On the execution layer, having exclusively Reth as the client also creates some centralizing risks, as it is less battle-tested in the market compared to more established alternatives like Geth, which somewhat reduces overall network resilience.
3.12.2. Upgradability strategy and sync with Ethereum
In terms of upgrades and the procedures surrounding them, Plasma needs to perform hard forks similar to the Ethereum Mainnet.
The Plasma team has confirmed that the strategy to sync with Ethereum upgrades is ad-hoc, but they are fully committed to keeping as much sync as possible with Ethereum.
3.12.3. Security programs (e.g., bug bounty)
Plasma does not have an ongoing bug bounty campaign, but the team has planned for a bug bounty campaign, especially around their custom node client.
3.12.4. Security audits
The Plasma team has conducted multiple audits of the consensus client, 4 by Cantina, 1 by Zellic, and 1 by Zenith. The Cantina audit report can be found HERE, with all issues either fixed or acknowledged.
3.12.5. Commitment to security incidents
A communication channel will be maintained between Plasma and the assigned technical team of the Aave community (e.g., BGD) for any necessary updates concerning the network and, consequently, Aave on Plasma.
4. Summary
An expansion of Aave to Plasma will imply allocating some development resources for both the initial setup and some overhead for maintenance and monitoring over time, similar to other networks.
From our analysis, we conclude that Plasma, even in a relatively early stage, is an acceptable network candidate in terms of technical requirements, with no current hard blockers for the Aave v3 (v3.5) protocol to work properly.