King Protocol
LayerZero Bridge

Covered the new LayerZero-based cross-chain integration bridging KING between Ethereum mainnet and Swell Chain.

report id

0452

1 Executive Summary

This document presents the security review performed by Nethermind Security of the King Protocol. The review focused on the new cross-chain integration leveraging LayerZero to facilitate the efficient transfer of liquid restaking rewards across multiple chains.

King Protocol introduces a standardized mechanism for consolidating and distributing rewards from Actively Validated Services (AVSs). In traditional liquid restaking token (LRT) systems, these rewards are fragmented across multiple protocols, making them costly and inefficient to claim. The protocol addresses this by aggregating AVS rewards into a unified vault, allowing LRTs to mint KING tokens as a representation of deposited assets. Users receive KING instead of multiple reward tokens, significantly simplifying distribution.

The new integration enables seamless bridging of KING between Ethereum mainnet and Swell Chain, a staking-focused Layer 2 built on the OP Stack. This approach reduces gas costs and streamlines the user experience by ensuring that rewards remain within the LRT ecosystem. Claims and redemptions are processed directly through each LRT protocol, maintaining efficiency and asset integrity.

The audited code comprises 224 lines of code written in the Solidity language. The audit focused on the new cross-chain integration of the King protocol.

The audit was performed using (a) manual analysis of the codebase, (b) automated analysis tools, and (c) creation of test cases.

Audit assessment
Audit Type	Security Review
Initial Report	February 13, 2025
Final Report	February 14, 2025
Repository	king-cross-chain
Start Commit	`c444200eed`
Final Commit	`0afc4c0179`
Documentation	Docs
Documentation Assessment	Medium
Test Suite Assessment	Low

Total findings: 3
Fixed: 3
Acknowledged: 0
Mitigated: 0
Unresolved: 0

Findings by severity

Critical0
High0
Medium0
Low0
Informational0
Best Practices3

2 Audited Files

The following table presents the files at the start of the audit, corresponding to commit c444200. During the audit, these files were renamed in commit 664b05d, but their content remained unchanged. For consistency, this security review report references the file names as they appeared in the initial commit.

Specifically, the following renames were made:

KingOFTAdapterUpgradeable.sol → KingOFTL1.sol
KingOFTUpgradeable.sol → KingOFTL2.sol
PairwiseRateLimiter.sol remained unchanged.

The non-upgradeable KingOFTAdapter.sol has been removed entirely from the codebase.

#	Contract	LoC	Comments	Ratio	Blank	Total
1	`contracts/KingOFTAdapterUpgradeable.sol`	51	17	33.3%	14	82
2	`contracts/KingOFTAdapter.sol`	11	1	9.1%	3	15
3	`contracts/PairwiseRateLimiter.sol`	94	91	96.8%	21	206
4	`contracts/KingOFTUpgradeable.sol`	68	27	39.7%	18	113
	Total	224	136	60.7%	56	416

3 Summary of Issues

#	Finding	Severity	Update
1	Incorrect use of the `reinitializer` modifier in `initialize(...)`	Best Practices	Fixed
2	The `PairwiseRateLimiter` contract should reserve space for future state variable upgrades	Best Practices	Fixed
3	Unused imports	Best Practices	Fixed

4 System Overview

King Protocol introduces a standardized mechanism for handling liquid restaking rewards across multiple chains, leveraging LayerZero for seamless interoperability. The primary goal of the new cross-chain integration is to efficiently aggregate and distribute restaking rewards while minimizing transaction costs and user overhead.

4.1 Motivation and Problem Statement

Liquid Restaking Tokens (LRTs) allow users to stake assets while maintaining liquidity. However, rewards from Actively Validated Services (AVSs) accrue in small, fragmented amounts across various protocols, making them difficult and costly to claim. The King Protocol addresses this by consolidating these rewards into a unified vault, enabling users to claim proportional shares efficiently.

4.2 Architecture and Workflow

The protocol's key mechanism involves:

LRT protocols consolidating AVS rewards and depositing them into the King vault.
Minting King tokens (KING) as a representation of the deposited assets.
Users receiving KING instead of multiple reward tokens, simplifying distribution.
Bridging KING across chains, currently integrating with Swell, a staking-focused Layer 2 on the OP Stack.
KING tokens can be burned on mainnet to receive the original AVS rewards.

4.3 Cross-Chain Functionality

The integration leverages LayerZero to enable:

Bridging of KING between Ethereum mainnet and Swell Chain.
Ensuring that claims and reward calculations remain within the LRT ecosystem.
Redemption of KING solely on Ethereum mainnet to maintain protocol efficiency and asset integrity.

By centralizing reward aggregation and distribution while allowing selective cross-chain transfers, King Protocol enhances user experience and reduces fragmentation within the liquid restaking ecosystem.

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

6.1 Incorrect use of the `reinitializer` modifier in `initialize(...)`

File	Fix commit	Type	Status
`contracts/KingOFTAdapterUpgradeable.sol`	—	Best Practices	Fixed

The initialize(...) function in the KingOFTAdapterUpgradeable contract is responsible for initializing the state of an upgradeable contract. However, it incorrectly applies the reinitializer(2) modifier from OpenZeppelin’s Initializable module. In an upgradeable contract’s initial deployment, the initializer modifier should be used to ensure proper initialization. The reinitializer modifier is intended for use in subsequent upgrades where new storage variables are introduced. By setting reinitializer(2), the contract mistakenly suggests that this is the second version, even though it is the first deployment. This could lead to issues in upgradeability and contract lifecycle management.

Recommendation

Consider replacing the reinitializer(2) with initializer to correctly handle the contract's first deployment.

6.2 The `PairwiseRateLimiter` contract should reserve space for future state variable upgrades

File	Fix commit	Type	Status
`contracts/PairwiseRateLimiter.sol`	—	Best Practices	Fixed

King Protocol's cross-chain contracts are upgradeable to support future code changes. However, the PairwiseRateLimiter contract, despite being used alongside other upgradeable contracts, does not account for potential state variable upgrades.

If new storage variables are added to PairwiseRateLimiter or other contracts, the storage layout could shift, leading to corruption. While this is not currently an issue due to other contracts using the EIP-7201 namespaced storage layout, best practices recommend adding a storage gap to any upgradeable contract to safeguard against future changes.

Recommendation

Consider introducing a uint256[50] private __gap variable in PairwiseRateLimiter to reserve space for future upgrades and maintain storage integrity.

6.3 Unused imports

File	Fix commit	Type	Status
*`contracts/`**	—	Best Practices	Fixed

The codebase contains imports that are not utilized by the contracts:

OpenZeppelin's Ownable in KingOFTAdapter.sol;
OpenZeppelin's Ownable in KingOFTUpgradeable.sol;

Recommendation

Consider removing unused imports to make the codebase clean and maintainable.

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 documentation for the King Protocol contracts was well-structured and provided through their official documentation, along with clear explanations during the kickoff call. The documentation offers a high-level overview of the protocol and its core mechanisms.

Additionally, the King Protocol team was highly responsive in addressing all questions and clarifications raised by the Nethermind Security team, ensuring a thorough understanding of the system's functionality. One key recommendation for improvement would be to include all necessary contextual information directly in NatSpec comments within the code. This would allow developers and auditors to understand the purpose of the code without requiring external documentation or prior discussions.

The King protocols's test suite contains very few test cases for the new cross-chain functionality. The in-scope contracts could benefit from higher test coverage to clearly outline the contract's specifications. To assess the test coverage for these files, the Nethermind Security team applied a technique called mutation testing to uncover the untested paths. This technique introduces slight modifications to the code called "mutations" or "mutants." An example of a mutation is, for example, changing the operator in an expression (a + b) to (a - b), or removing a require(a > b) statement entirely from the code. With these changes, the code no longer follows the expected business logic of the application, and the test suite should reflect that by failing.

Evaluation of the test suite with mutation testing consists of two phases:

Generating the modified version of each contract, called "mutants."
Inserting the mutant into the original codebase and running the test suite.

Only one modification can be tested at a time. If the contract has ten mutations, the test suite must run ten times (once for every mutation). If any of the tests fail, it means that the test suite caught the change in the code. Whenever that happens, the particular mutant is considered "slain" or "killed" and is removed from the mutant's set. If that does not occur, a new test case can be added to cover the code branch to "kill" the mutant.

The following table outlines the results of the analysis performed on the King's cross-chain smart contracts. The first column lists the contracts that were tested using mutation testing. The second column indicates the number of mutants generated and how many were "slain" (i.e., caught by the test suite). The third column provides the percentage of mutants slain, reflecting the effectiveness of the test suite in covering the particular contract. The higher the score, the better the test suite is at finding bugs.

Contract	Mutants (slain / total generated)	Score
`KingOFTL1.sol`	5 / 12	41.67%
`PairwiseRateLimiter.sol`	36 / 93	38.71%
`KingOFTL2.sol`	0 / 15	0%
Total	41 / 120	34.17%

Remarks about the King Protocol's test suite

The test suite for the King Protocol covers basic functionalities but is notably shallow. A significant portion of the contract, such as the KingOFTL2.sol file is not tested at all, leaving parts of the codebase unverified. Additionally, the overall result of the mutation testing is below the average for similar projects, indicating a gap in test coverage and effectiveness.

This shallow testing increases the likelihood of undetected issues in edge cases, as the suite fails to thoroughly validate state transitions and specific conditions within the contract. The lack of coverage for important functionalities poses a risk of subtle, hard-to-manually detect bugs making their way into production.

To improve the reliability of the King Protocol, it is essential to enhance the depth and breadth of the test suite. This includes adding tests for undertested contracts, expanding coverage for edge cases, and ensuring that all significant code paths are properly exercised. Incorporating mutation testing would also help identify areas of weakness by introducing small code changes and checking whether the existing tests can detect them. This approach would provide valuable insights into the effectiveness of the current test suite and guide improvements in coverage.

All the relevant issues raised by the AuditAgent have been incorporated into this report. The AuditAgent is an AI-powered smart contract auditing tool that analyses code, detects vulnerabilities, and provides actionable fixes. It accelerates the security analysis process, complementing human expertise with advanced AI models to deliver efficient and comprehensive smart contract audits. Available at https://app.auditagent.nethermind.io.

General advisory to clients

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.

Disclaimer

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.

King ProtocolLayerZero Bridge

1

Executive Summary

2

Audited Files

3

Summary of Issues

4

System Overview

4.1 Motivation and Problem Statement

4.2 Architecture and Workflow

4.3 Cross-Chain Functionality

5

Risk Rating Methodology

6

Issues

6.1 Incorrect use of the reinitializer modifier in initialize(...)

6.2 The PairwiseRateLimiter contract should reserve space for future state variable upgrades

6.3 Unused imports

7

Documentation Evaluation

8

Remarks & Test Suite

King Protocol
LayerZero Bridge

6.1 Incorrect use of the `reinitializer` modifier in `initialize(...)`

6.2 The `PairwiseRateLimiter` contract should reserve space for future state variable upgrades