Zpoken Successfully Deploys the Compound Protocol on Neon EVM

Neon Labs
Neon Labs
Published in
4 min readOct 21, 2022

Over the last few months, Neon Labs has partnered with several organizations to test and deploy various protocols and projects on Neon EVM. Neon Labs’ most recent partnership with Zpoken has resulted in the successful deployment of the Compound protocol on Neon EVM. The deployment of Compound on Neon EVM serves to further test the readiness of Neon EVM for production and the onboarding of complex dApps to its ecosystem.

Compound is a DeFi dApp that first launched in September, 2018 on Ethereum. The protocol allows users to lend and borrow cryptocurrencies without an intermediary.

Who is Zpoken?

Zpoken is a full-stack Web3 development firm. The company has shipped more than 50 projects and has 30 active builders across 10+ blockchain networks. Zpoken’s specializations include high-end web3 development, cryptography, capital markets, token design, and liquidity.

Our Objective

The main objective of the exercise with Zpoken was to test Neon EVM’s performance and functionality during the deployment of the Compound protocol contracts to Neon Devnet.

Following the successful deployment, Zpoken conducted unit tests on the protocol. The goal was to ensure the appropriate performance and workflow of the protocol contracts as well as the correctness of the contract calculations and logic.

Testing Methodology

Zpoken tested the following smart contract functions to verify the performance of Compound on Neon EVM:

  • Deploy compound contracts to Neon Devnet network;
  • Test cToken contract functions (constructor, mint, mintFresh, redeem, redeemFreshTokens, redeemFreshAmount, liquidateBorrow, liquidateBorrowFresh, seize, _setComptroller, transfer, balanceOfUnderlying, borrow, borrowRatePerBlock, supplyRatePerBlock, borrowBalanceCurrent, borrowBalanceStored, exchangeRateStored, getCash, borrowFresh, repayBorrowFresh, repayBorrow, repayBorrowBehalf, accrueInterest, _setInterestRateModel, _setInterestRateModelFresh, _setReserveFactor, _setReserveFactorFresh, _reduceReserves, _reduceReservesFresh, admin, pendingAdmin, _setPendingAdmin, _acceptAdmin);
  • Test CEther contract functions (getCashPrior, doTransferIn, doTransferOut, mintExplicit, mintFallback, redeemCTokens, redeemUnderlying, borrow, borrowFresh, repayBorrow, repayBorrowFresh, repayBorrowBehalf, addReserves);
  • Test Comptroller contract functions (constructor, _setLiquidationIncentive, _setPriceOracle, _setCloseFactor, _setCollateralFactor, _supportMarket, liquidateBorrowAllowed, redeemVerify, liquidateCalculateAmountSeize, _setPauseGuardian, setting paused, liquidity, getAccountLiquidity, getHypotheticalAccountLiquidity, admin, pendingAdmin, _setPendingAdmin, _acceptAdmin);
  • Test CompoundLens contract functions (cTokenMetadata, cTokenMetadataAll, cTokenBalances, cTokenBalancesAll, cTokenUnderlyingPrice, cTokenUnderlyingPriceAll, getAccountLimits, governance, comp);
  • Test PriceOracleProxy contract functions (constructor, getUnderlyingPrice);
  • Test Timelock contract functions (constructor, setDelay, setPendingAdmin, acceptAdmin, queueTransaction, cancelTransaction, executeTransaction, executeTransaction, queue and cancel empty);
  • Test InterestRateModel contract functions (baseP025-slopeP20, jump rate tests, baseP05-slopeP45, isInterestRateModel, calculates correct borrow value, jump-rate);
  • Test CCompLikeDelegate contract functions (_delegateCompLikeTo);
  • Test Maximillion contract functions (constructor, repayBehalf);
  • Test DAIInterestRateModelV3 contract functions (constructor, getBorrowRate, getSupplyRate);
  • Test Flywheel contract functions (_grantComp, getCompMarkets, _setCompSpeeds, updateCompBorrowIndex, updateCompSupplyIndex, distributeBorrowerComp, distributeSupplierComp, transferComp, claimComp, claimComp batch, harnessRefreshCompSpeeds, harnessSetCompSpeeds, harnessAddCompMarkets, updateContributorRewards, _setContributorCompSpeed).

Testing Scope

The scope of testing focused on the following deployed contracts:

Testing Execution

Prior to deployment and testing, Zpoken made two primary changes to the Compound protocol smart contracts:

  • The first change was made to the GRACE_PERIOD and MINIMUM_DELAY constants in Timelock.sol. The constants influence time limits for function execution in contracts. The changes were required as the Zpoken team conducted tests on live Neon network nodes and were not able to manipulate time and block numbers.
  • The second change adjusted the address of the external Comp contract in the Comptroller.sol contract (via the function getCompAddress()).

Once the contract adjustments were made, the Zpoken team deployed to Neon Devnet from the repository neon-smart-contract-dev/compound-finance using the yarn deploy -n neon command.

Following the deployment, tests were run from the repository neon-smart-contract-dev/compound-finance. To run the tests, the local Neon environment first needed to be configured and the private keys added to ~/.neon/neon. The command to run the tests was . start.sh

Tests were also run in the local Neon environment via Docker in the repository neon-smart-contract-dev/compound-finance. The steps to conduct the test are as follows:

  1. Run a local Neon node using proxy-model.py
  2. Build the docker image using sudo docker build -t compound-protocol
  3. Run the container using sudo docker run -it — net=host compound-protocol

Project deliverables include deployment and test scripts, as well as integration and unit tests. Deployment and test scripts can be accessed via the repository. The integration and unit tests performed are available in a GitHub repository and can be run in a Docker container to re-play the testing scenarios.

Findings

Zpoken successfully deployed and tested the Compound protocol base contracts as well as swap pool. The deployment and associated tests indicated that Neon EVM is running correctly and is fully compatible with Ethereum with regards to running complex dApps like Compound. All integration and unit tests were passed. The contract deployment, logic, math, and functionality are working as expected by the Compound developer team. The only thing that could not be tested was the Compound Web Application due to the lack of the Compound API in public GitHub repositories.

Zpoken also identified two issues with the Neon platform::

  1. Deploying and testing the Compound contracts required support for RPC eth_accounts. The method has been implemented but there are errors that Neon Labs is currently addressing.
  2. The multi-threaded execution of test scripts implemented in the original Compound tests is not supported by the Neon network. The tests were created for Ganache, a personal Ethereum blockchain simulator, rather than a live node. Attempting to use multiple threads results in “nonce too low” errors. To avoid the error, each script should be run from a different deployer address. However, in tests that use multiple threads within a single test, the error cannot be avoided. The tests could not be run in these scenarios and were skipped.

Conclusion

It’s time for YOU to deploy your own smart contracts to Neon EVM. Make sure to share your Neon EVM feedback with us throughout the process. If you have any issues or need additional guidance, check out our Neon Docs or reach out to a team member on Discord. We know that you’ll create something great!

--

--