Summon
Payment Router

The new split payment functionality of the PaymentRouterNative contract was in scope, replacing multisig-based fee handling with direct recipient management.

report id

0412

1 Executive Summary

This document outlines the security review conducted by Nethermind Security for Summon. The audit focused on the new split payment functionality of the PaymentRouterNative smart contract. The multisig wallet functionality was removed in favor of direct fee recipient management. Additionally, funds are now sent to the admin caller instead of the multisig for emergency withdrawals.

The audited code comprises 273 lines of code written in the Solidity language. The audit focuses on the new split payment functionality for the PaymentRouterNative smart contract.

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	January 31, 2025
Final Report	February 6, 2025
Repository	contracts-monorepo
Commit	`9f9a1ca733`
Final Commit	`9c76d8a476`
Documentation	PR description
Documentation Assessment	Medium
Test Suite Assessment	Medium

Total findings: 2
Fixed: 1
Acknowledged: 0
Mitigated: 0
Unresolved: 1

Findings by severity

Critical0
High0
Medium1
Low0
Informational0
Best Practices1

2 Audited Files

#	Contract	LoC	Comments	Ratio	Blank	Total
1	`contracts/payments/PaymentRouterNative.sol`	273	153	56.0%	51	477
	Total	273	153	56.0%	51	477

3 Summary of Issues

#	Finding	Severity	Update
1	The `removeFeeRecipient(...)` function doesn’t remove `recipient` from `feeRecipientAddresses`	Medium	Fixed
2	Unused variable `totalPercentage`	Best Practices	Unresolved

4 System Overview

4.1 Actors

The participants of PaymentRouterNative contract are outlined below.

Admin: Address with the admin role can grant and revoke other roles. They can also withdraw the stuck funds from the contract.
Dev Config: Address with Dev Config role can grant and revoke the whitelisted signer role. The role can also set and update Payment Config for specific payment IDs.
Manager: Address with Manager role can pause and unpause the contracts. They can also set and update fee recipients.
Whitelisted Signer: Whitelisted Sigher address is operated by the project’s backend and signs the data for collectibles that users can later pay for.
User: Users pay for in-game collectibles or get access tokens, which can be later claimed for rewards.

4.2 Payment Router Native

The PaymentRouterNative contract manages payments for in-game collectibles within the Summon ecosystem. It allows for configuring payment IDs, each with a configurable price and associated metadata URI. The contract supports role-based access control, enabling different levels of permissions for managing payment configurations and performing critical operations, such as updating prices and URIs, pausing/unpausing payment IDs, and handling the fee recipients. Authorized backend services sign messages to verify that a user can purchase specific in-game collectibles. Users can then call the pay(...) function to complete the transaction using the Game7 native tokens. Payments are securely routed to fee recipients. As a result, only authorized actions, validated by the signed messages, are executed within the system. The contract includes emergency withdrawal functionality to rescue any stuck funds from the contract.

4.3 Fee Recipients

The Fee Recipients receive their corresponding pro rata amount from the payment received in the pay(...) function by their respective assigned percentages. The setFeeRecipient(...) function is used to set a Fee Recipient and its percentage, whereas the removeFeeRecipient(...) function is used to remove a Fee Recipient. The pay(...) function will revert if the total percentage allocated to fee recipients does not precisely equal 100 percent.

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 The `removeFeeRecipient(...)` function doesn’t remove `recipient` from `feeRecipientAddresses`

File	Fix commit	Type	Status
`contracts/payments/PaymentRouterNative.sol`	PR #184	Medium	Fixed

The setFeeRecipient(...) and batchSetFeeRecipients(...) functions push recipient to feeRecipientAddresses array if active field is false for that recipient. When the removeFeeRecipient(...) function is called, it simply sets the active field to false and percentage field to 0 but doesn’t remove the recipient from feeRecipientAddresses array as seen below:

function removeFeeRecipient(address recipient) external onlyRole(MANAGER_ROLE) {
    // @audit should remove feeRecipient to avoid duplication and double counting of percentages.
    if (!feeRecipients[recipient].active) revert FeeRecipientDoesNotExist();
    feeRecipients[recipient].active = false;
    feeRecipients[recipient].percentage = 0;
    emit FeeRecipientRemoved(recipient);
}

Therefore, if a recipient was removed and added again, then feeRecipientAddresses would contain duplicate entries. As a result, getTotalFeePercentage(...) and getFeeRecipients(...) function would return duplicated entries.

Given the pay(...) function loops through feeRecipientAddresses array, it will transfer multiple times to the same recipient as it contains duplicated entries.

Recommendation

Consider removing the recipient from the feeRecipientAddresses.

Resolution

9c76d8a

6.2 Unused variable `totalPercentage`

File	Fix commit	Type	Status
`contracts/payments/PaymentRouterNative.sol`	—	Best Practices	Unresolved

The variable totalPercentage is not used anywhere in setFeeRecipient(...) function as seen below:

function setFeeRecipient(
    address recipient,
    uint256 percentage
) external onlyRole(MANAGER_ROLE) {
    // ...
    uint256 totalPercentage = getTotalFeePercentage();
    if (!feeRecipients[recipient].active) {
        totalPercentage += percentage;
    } else {
        totalPercentage = totalPercentage - feeRecipients[recipient].percentage + percentage;
    }
    // ...
}

Recommendation

Consider removing the variable totalPercentage or add a condition to make sure that it’s not greater than HUNDRED_PERCENT.

Resolution

Acknowledged

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 audit scope was limited to the PaymentRouterNative.sol contract which was part of summon-contracts project. Therefore, the following test output is an extraction of tests output strictly related to the PaymentRouterNative contract and other test outputs are ignored.

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.

SummonPayment Router

1

Executive Summary

2

Audited Files

3

Summary of Issues

4

System Overview

4.1 Actors

4.2 Payment Router Native

4.3 Fee Recipients

5

Risk Rating Methodology

6

Issues

6.1 The removeFeeRecipient(...) function doesn’t remove recipient from feeRecipientAddresses

6.2 Unused variable totalPercentage

7

Documentation Evaluation

8

Remarks & Test Suite

Summon
Payment Router

6.1 The `removeFeeRecipient(...)` function doesn’t remove `recipient` from `feeRecipientAddresses`

6.2 Unused variable `totalPercentage`