Covered the integration of Magna's claim-and-stake hook with Skate, auto-staking claimed funds into EigenLayer, plus post-deployment verification of the OFT Skate token across Ethereum, Binance Chain, and Solana.
This document presents the results of a security review conducted by Nethermind Security for Skate.
Skate is an infrastructure layer that enables users to interact seamlessly from their native chains by connecting them to Virtual machines across chains. It uses LayerZero for cross-chain communication. This audit engagement is focused on the integration of Magna platform’s protocol-level hooks with Skate. When the tokens on Magna platform are claimed by the user, using the protocol level hook of Magna platform, the Skate will automatically stake the claimed funds into the Eigen Layer in the same transaction. The implementation leverages the stake function with the signature of the Strategy Manager in Eigen Layer to achieve this. The claim-initiating function will capture the signature of the signer to process the transaction.
The audit comprises 74 lines of Solidity code. The audit was performed using (a) manual analysis of the codebase, (b) automated analysis tools, and (c) creation of test cases. The audit also consisted of verifying the post-deployment of the OFT Skate token on three chains: Ethereum, Binance Chain, and Solana. No issues were found during the audit of the code in scope.
The process is designed to allow users to claim their tokens from the Magna Platform and have them automatically staked into an EigenLayer strategy, all within a single atomic transaction.
The User (Staker) initiates a token claim on the Magna Platform. As part of this process, the Magna Platform collects the User's signature. This signature is intended to authorize not only the claim but also the subsequent staking action on EigenLayer.
Upon a successful claim, the Magna Platform's protocol level hook will be triggered. This hook calls the handlePostClaim function on the ClaimAndStakeHandlerHook, the handler contract implemented by Skate. When calling handlePostClaim, the Magna Platform transfers the claimed tokens to the ClaimAndStakeHandlerHook contract.
Magna Platform also passes the User's signature to the ClaimAndStakeHandlerHook Contract. This is typically done via extraData parameter of the hook function call.
The ClaimAndStakeHandlerHook contract receives the claimed tokens and the user's signature. Then it sends these funds to EigenLayer's strategy manager. To do this, it calls the depositIntoStrategyWithSignature function on the target EigenLayer strategy contract. The ClaimAndStakeHandlerHook uses the user's signature received from Magna Platform to authorize this deposit, effectively staking the tokens on behalf of the User.
If the signature is valid and all conditions are met, the EigenLayer strategy accepts the tokens, and they are staked on behalf of the user. The entire sequence, from claim to stake, occurs within the context of the initial transaction initiated by the user on the Magna Platform. 0 The following diagram provides a high-level illustration of the Skate - Magna Platform integration.
Fig. 2: Magna-Skate Integration
4.1 System Components
4.2 Magna Platform
The Magna Platform offers Protocol level hooks to handle uses cases related to handling of claimed tokens. In order to listen to the hook function, the handler contract implements IPostClaimHandlerinterface which has handlePostClaim hook function.
4.3 Skate
The Skate implemented ClaimAndStakeHandlerHook,a handler contract that will listen to the handlePostClaim hook function. The claimed funds are received into the handler contract, which then stakes the funds in favor of the last withdrawal address received as parameter to the hook. Magna Platform will pass the signature of the withdrawal address along with expiry in extraData field.
ClaimAndStakeHandlerHook has a reference to the StrategyManager. The handler contract stakes the received funds in favor of withdrawal address on the Eigen layer in the same transaction by calling depositIntoStrategyWithSignature function.
4.4 EigenLayer
EigenLayer's StrategyManager contract is the final destination for tokens claimed by users. It provides depositIntoStrategyWithSignature function that enables Skate to deposit and stake funds on behalf of the user using offchain signature.
4.5 Security Assumptions for the Skate-Magna Integration
The security and correct functioning of the integrated claiming (via Magna) and staking (via Skate into EigenLayer) process rely on the following core assumptions:
Standard ERC20 Token Behavior: Skate is assumed to only interact with ERC20 tokens that adhere to the standard interface and behavior. Tokens with non-standard mechanics, such as "fee-on-transfer" tokens, rebasing tokens, or those with other weird behaviors that might alter transfer amounts or impede transfers, are explicitly not supported by this integration.
Origin of Signature: The signature provided by the Magna Platform within the extraData parameter (which is passed to Skate's handlePostClaim function) is assumed to be a valid signature from the account designated as the Last withdrawal account. This implies that the signature directly authorizes actions on behalf of this specific user account for the staking operation on EigenLayer.
Exclusion of Multisig Wallets as Last Withdrawal Account: The automated claim-and-stake flow facilitated by this Skate-Magna integration is not designed to support multisig wallets as the Last Withdrawal Account. The mechanism relies on a single signature, typically from an Externally Owned Account (EOA), and is not intended to handle the complexities of multisig authorization for this specific automated pathway.
4.6 Note regarding the post-deployment of OFT tokens
As part of their request, we reviewed their layer zero on-chain deployment for the OFT Skate token that was deployed on Ethereum, Binance, and Solana chains. The client used the default DVNs, receive, and send libraries of LayerZero. Two observations are worth mentioning:
The trusted peers and connections to OFT deployments must be established only after configuring the DVN and Executor. This is because invoking setPeer opens the OFT deployments to receive messages from the messaging channel. Without prior DVN and Executor configuration, any bridge message will become stuck, as detailed in the LayerZero documentation. We noticed that in the transactions' configuration order, setPeer is the first transaction invoked, which doesn't align with the recommendation. The client acknowledged this and confirmed that they used the LayerZero CLI command to set all the configurations together, so the order mismatch came from the command execution rather than a manual configuration.
Currently, only 1 DVN is configured, and the threshold is defaulted to zero; there is no problem with that, but we would recommend adding more DVNs and increasing the threshold accordingly.
5
Risk Rating Methodology
The risk rating methodology used by Nethermind Security follows the principles established by the OWASP Foundation. The severity of each finding is determined by two factors: Likelihood and Impact.
Likelihood measures how likely the finding is to be uncovered and exploited by an attacker. This factor will be one of the following values:
High: the issue is trivial to exploit and has no specific conditions that need to be met;
Medium: the issue is moderately complex and may have some conditions that need to be met;
Low: the issue is very complex and requires very specific conditions to be met.
When defining the likelihood of a finding, other factors are also considered. These can include but are not limited to motive, opportunity, exploit accessibility, ease of discovery, and ease of exploit.
Impact is a measure of the damage that may be caused if an attacker exploits the finding. This factor will be one of the following values:
High: the issue can cause significant damage, such as loss of funds or the protocol entering an unrecoverable state;
Medium: the issue can cause moderate damage, such as impacts that only affect a small group of users or only a particular part of the protocol;
Low: the issue can cause little to no damage, such as bugs that are easily recoverable or cause unexpected interactions that cause minor inconveniences.
When defining the impact of a finding, other factors are also considered. These can include but are not limited to data and state integrity, loss of availability, financial loss, and reputation damage. After defining the likelihood and impact of an issue, the severity is determined according to the table below.
Impact / Likelihood
Low
Medium
High
High
Medium
High
Critical
Medium
Low
Medium
High
Low
Info / Best Practices
Low
Medium
Undetermined
Undetermined
Undetermined
Undetermined
To address issues that do not fit a High, Medium or Low severity, Nethermind Security also uses three more finding severities: Informational, Best Practices, and Undetermined.
Informational findings do not pose any risk to the application, but they carry some information that the audit team intends to pass to the client formally;
Best Practice findings are used when some piece of code does not conform with smart contract development best practices;
Undetermined findings are used when we cannot predict the impact or likelihood of the issue.
6
Issues
No issues were identified during the audit.
7
Documentation Evaluation
Software documentation refers to the written or visual information that describes the functionality, architecture, design, and implementation of software. It provides a comprehensive overview of the software system and helps users, developers, and stakeholders understand how the software works, how to use it, and how to maintain it. Software documentation can take different forms, such as user manuals, system manuals, technical specifications, requirements documents, design documents, and code comments. Software documentation is critical in software development, enabling effective communication between developers, testers, users, and other stakeholders. It helps to ensure that everyone involved in the development process has a shared understanding of the software system and its functionality. Moreover, software documentation can improve software maintenance by providing a clear and complete understanding of the software system, making it easier for developers to maintain, modify, and update the software over time. Smart contracts can use various types of software documentation. Some of the most common types include:
Technical whitepaper: A technical whitepaper is a comprehensive document describing the smart contract’s design and technical details. It includes information about the purpose of the contract, its architecture, its components, and how they interact with each other;
User manual: A user manual is a document that provides information about how to use the smart contract. It includes step-by-step instructions on how to perform various tasks and explains the different features and functionalities of the contract;
Code documentation: Code documentation is a document that provides details about the code of the smart contract. It includes information about the functions, variables, and classes used in the code, as well as explanations of how they work;
API documentation: API documentation is a document that provides information about the API (Application Programming Interface) of the smart contract. It includes details about the methods, parameters, and responses that can be used to interact with the contract;
Testing documentation: Testing documentation is a document that provides information about how the smart contract was tested. It includes details about the test cases that were used, the results of the tests, and any issues that were identified during testing;
Audit documentation: Audit documentation includes reports, notes, and other materials related to the security audit of the smart contract. This type of documentation is critical in ensuring that the smart contract is secure and free from vulnerabilities.
These types of documentation are essential for smart contract development and maintenance. They help ensure that the contract is properly designed, implemented, and tested, and they provide a reference for developers who need to modify or maintain the contract in the future.
8
Remarks & Test Suite
The Stake team has provided a comprehensive walkthrough of the project in the kick-off call. The Notion page and the code comments include the explanation of the intended functionalities. Moreover, the team addressed the questions and concerns raised by the Nethermind Security team, providing valuable insights and a comprehensive understanding of the project's technical aspects.
Test suite
4Tests passed
0Failed
The complete test output is in the full report.
As auditors, we recommend that any changes or updates made to the audited codebase undergo a re-audit or security review to address potential vulnerabilities or risks introduced by the modifications. By conducting a re-audit or security review of the modified codebase, you can significantly enhance the overall security of your system and reduce the likelihood of exploitation. However, we do not possess the authority or right to impose obligations or restrictions on our clients regarding codebase updates, modifications, or subsequent audits. Accordingly, the decision to seek a re-audit or security review lies solely with you.
This report is based on the scope of materials and documentation provided by you to Nethermind in order that Nethermind could conduct the security review outlined in 1. Executive Summary and 2. Audited Files. The results set out in this report may not be complete nor inclusive of all vulnerabilities. Nethermind has provided the review and this report on an as-is, where-is, and as-available basis. You agree that your access and/or use, including but not limited to any associated services, products, protocols, platforms, content, and materials, will be at your sole risk. Blockchain technology remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer, or any other areas beyond the programming language, or other programming aspects that could present security risks. This report does not indicate the endorsement of any particular project or team, nor guarantee its security. No third party should rely on this report in any way, including for the purpose of making any decisions to buy or sell a product, service or any other asset. To the fullest extent permitted by law, Nethermind disclaims any liability in connection with this report, its content, and any related services and products and your use thereof, including, without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement. Nethermind does not warrant, endorse, guarantee, or assume responsibility for any product or service advertised or offered by a third party through the product, any open source or third-party software, code, libraries, materials, or information linked to, called by, referenced by or accessible through the report, its content, and the related services and products, any hyperlinked websites, any websites or mobile applications appearing on any advertising, and Nethermind will not be a party to or in any way be responsible for monitoring any transaction between you and any third-party providers of products or services. As with the purchase or use of a product or service through any medium or in any environment, you should use your best judgment and exercise caution where appropriate. FOR AVOIDANCE OF DOUBT, THE REPORT, ITS CONTENT, ACCESS, AND/OR USAGE THEREOF, INCLUDING ANY ASSOCIATED SERVICES OR MATERIALS, SHALL NOT BE CONSIDERED OR RELIED UPON AS ANY FORM OF FINANCIAL, INVESTMENT, TAX, LEGAL, REGULATORY, OR OTHER ADVICE.
