Audit: Session Token Rewards Contract

Third-party audits are a necessary process to ensure our code is safe and secure before it is deployed or used in high-risk settings. We’ve had Session audited in the past, and now we are getting the Session Token Rewards Contract audited as well.

This audit is part of a larger audit strategy which includes at least 3 audits prior to the deployment of any code to an EVM production environment. Our plan is to employ increasing levels of auditing as the code is developed; we started with fairly low-level checks using freelance auditors and internal audits. Now that the code has reached a greater level of completion, we have engaged a small team of auditors (Cipher Sleuths) for an initial third-party report. Our final audit will be completed by a top tier, large, professional auditing firm who can provide a high level of confidence in the code and aid with cryptographic code auditing.

The audit discussed herein was completed by Cipher Sleuths, a cybersecurity research duo focused on EVM and smart contract auditing. This audit splits vulnerabilities into 4 severity categories: critical, high, medium, and low; the severity is chosen based on the predicted impact and likelihood of a given attack. Cipher Sleuths reported no vulnerabilities assessed as ‘critical’, but we will provide some additional comments on issues raised.

Note: No code has been deployed to production environments, so with all issues found, we have time to address or provide fixes

High

Two issues were assessed as high severity, one is resolved and one is under review.

H-01 Attacker can enable DOS by front running the claiming of network rewards by the user

Although no funds would be at risk due to this issue, we will add a simple check to prevent this attack. Current ideas include adding claim amount checks to contract.

H-02 Revert signature verification related operations when a fraudulent node signs a transaction

Protections already provided through the C++ codebase.

When creating an aggregate signature, a node requests signatures from all other nodes. These signatures are then checked, and valid signatures are added to the aggregate. If an attacker produces an invalid signature, the signature will not be added to the signer set.

This check also prevents DOS attacks performed by submitting invalid signatures.

Medium

Four issues were assessed as medium severity, two are resolved and two (M-02 and M-03) are to relatively simple fixes and will be resolved.

M-01 A whale can get the control of the protocol by having a majority of stake in the network

There is a standard assumption that no single party can own over 51% percent of the Session Node stakes. It is expected we will seed the contract with our current service node list, which has approximately 2,000 nodes run by a diverse set of operators.

This means the Session Network will immediately have enough nodes to ensure 300 non-signers is the maximum allowed; lower level checks are not likely to come into effect unless the network has a large decrease in node count.

Adding a restriction on the X amount of nodes a single address can operate will not solve this issue, as a single user with 2 addresses can theoretically perform the same attack(s).

Instead, this is managed through:

Tokenomics ensuring the barrier to operating a node is sufficiently high such that whales cannot realistically operate 300+ nodes;
supply/demand based protection against rapid acquisition of large quantity of tokens for staking;
new players attempting to acquire tokens and operate nodes quickly would be easily noticed by the team and/or community and action may be taken against them.

M-04 `leaveRequestTimestamp` is not checked if it is set or not when `removeBLSPublicKeyWithSignature` is called

The nodes on the network only create BLS signatures which will be passed to removeBLSPublicKeyWithSignature if sufficient time has passed since its initiateRemoveBLSPublicKey.

Although this function does not directly check the leaveRequestTimestamp, it’s intended to rely on the C++ code to check before a signature is produced.

Low

Eight issues were assessed as low severity, all are to be resolved. These are not listed individually in this article as they are minor issues with mostly simple fixes. For more details, view the full report.

Next Steps

All of the items from this report will be resolved (if they are not already marked as such) before we continue with future audits and reviews of the Token Rewards Contract. Overall, this is an extremely positive step for the Token Rewards Contract, and there are no critical or difficult to solve issues before we move forward.

Further updates will be provided once all items flagged in this report are resolved.

View the full report by Cipher Sleuths here.