Version 2 Security Audit

Audit Overview

Disclaimer: The highlighted issues of the following summary reflected an understanding of the codebase at the time the audit was performed and were inadequately conveyed to the Boson Protocol team by the Omniscia team. For more information, consult the Amendment of Report Summary chapter that follows.

We were tasked with performing another audit of the Boson Protocol and in particular their V2 implementation that revised the initial codebase to now utilize the EIP-2535 Diamond standard as well as compartmentalized code into several different entities that together form the Boson Voucher system.

Over the course of the audit, we identified multiple issues of varying severity revolving around edge cases that the system is inadequately equipped to deal with as well as certain medium issues with regards to the cryptographic implementation used by the system.

The code has been developed to a high standard, however, we have observed certain patterns that we advise against such as input validation being split between both internal and public facing functions (i.e. raiseDisputeInternal of DisputeBase expects a state different than Redeemed but is validated at the invocation level) and the presence of natural race conditions that should otherwise be avoided.

While the former type of issue does not currently pose an active security threat, it can easily evolve into one based on the programming practices as well as the expected deviation between each contributor's coding style.

With regards to the latter, we specifically refer to the creation of the various account types (buyer & seller) which allow arbitrary addresses to be specified. An unsuspecting user's "seller" account may be created with values different than the ones they specified in the creation call due to a malicious user's transaction containing the same input parameters with slight deviations and a higher transaction fee.

We strongly encourage the Boson Protocol team to reconsider the permissionless-ness of the account creation functions as they may lead to fraud attempts based on different seller configurations due to the difference between what was submitted in the UI vs what was ultimately executed on-chain due to the aforementioned race condition.

We advise the Boson Protocol team to closely evaluate all minor-and-above findings identified in the report and promptly remediate them as well as consider all optimizational exhibits identified in the report.

Post-Audit Conclusion

The Boson Protocol team evaluated all exhibits identified within the report and provided an alleviation for each one in the form of a detailed PDF document as well as rationale as to why certain exhibits will remain unaddressed.

All exhibits have either been adequately dealt with, properly nullified, or responsibly acknowledged by the Boson Protocol team and no outstanding issues identified in the report remain in the codebase.

Amendment of Report Summary

After extensive discussions with the Boson Protocol team in relation to our original audit summary, we concluded that certain aspects of the codebase required a re-visit by the Boson Protocol team as they were inadequately conveyed by us.

In detail, the split of validation logic within the code was a concious and deliberate choice by the Boson Protocol team as the same checks are not required wherever the internal-style functions are invoked thus allowing the public facing functions to apply any additional input sanitization on an as-needed basis, however, the comments of the internal functions were misleading. This was alleviated in finding DBE-01M.

With regards to the permission-less account creation, we incorrectly assumed that this was a design choice that the Boson Protocol team was aware of and thus simply commented on it rather than formulating it as a finding.

Once the Boson Protocol team evaluated the audit's summary in detail, they detected that the issues outlined within it were valid and as such should be integrated in the report as they proceeded to alleviate them.

We have thus added the incorrect comments as well as the race-condition issues as separate exhibits in the report and the Boson Protocol team performed extensive updates to correct both thus rendering them no longer applicable to the codebase.

On a final note, the Boson Protocol team assessed that the race-condition issue described for the seller and buyer accounts pose no threat to buyer creation, however, the additional case of a dispute resolver creation required this form of race-condition protection as well.

They have proceeded to amend that portion of the codebase similarly to the seller creation process with the same opt-in system described in SBE-01M.

Contracts Assessed

Audit Synopsis

Severity	Identified	Alleviated	Partially Alleviated	Acknowledged
	8	8	0	0
	43	37	0	6
	14	10	0	4
	5	5	0	0
	0	0	0	0

During the audit, we filtered and validated a total of 13 findings utilizing static analysis tools as well as identified a total of 57 findings during the manual review of the codebase. We strongly recommend that any minor severity or higher findings are dealt with promptly prior to the project's launch as they introduce potential misbehaviours of the system as well as exploits.

The list below covers each segment of the audit in depth and links to the respective chapter of the report:

• 💻 Compilation
• 🔍 Static Analysis
• 👁️ Manual Review
• 🖋️ Code Style