Omniscia Evergon Labs Audit

Onchain Data Containers Security Audit

Audit Report Revisions

Commit HashDateAudit Report Hash
e712cb6601December 16th 202418dda087c0
c6b23c23d8February 8th 202500cf4349d1
18bd9a145aFebruary 26th 202541227f4f6a
18bd9a145aFebruary 28th 2025c86b99d1a7

Audit Overview

We were tasked with performing an audit of the Evergon Labs codebase and in particular their Onchain Data Containers implementations that support various asset classes and use-cases.

The system makes use of the EIP-7208 architecture of a Data Manager, a Data Index, and a Data Object all of which are closely intertwined and expect calls to flow through each other in an authorized manner.

The codebase is significantly complex and there are several instances whereby call sanitization and/or security checks are performed distinctly across the aforementioned implementations, more often than not via implicit guarantees.

As an example, repeat invocations of EIP-1155 functions in the TokenWrapperToERC1155WithERC20FractionsDataManager Data Manager after the supply of a token has been burned (i.e. a burn of zero) are not possible because the EIP-1155 Data Object does not permit a transfer of zero to occur if the owner has not owned the asset in the past due to the usage of an enumerable set to maintain balances.

Such complex cross-contract security traits render the validation of function implementations difficult and we strongly advise the documentation of the project to be expanded in this regard, for example by noting any extra-contract security dependencies in the documentation of a function to permit them to be pinpointed easily.

In addition to the base asset classes the system suports, a notion of an "Omnichain" system has been introduced that permits the same data manager to be utilized for a cross-chain asset and to provide direct integration with LayerZero to facilitate cross-chain interactions.

A caveat of this approach is that the system expects the deployment address of a Data Object to be the same across the LayerZero chains integrated which is not always the case, especially so in zero-knowledge proof based L2s that usually employ address masking for smart contract addresses.

Additionally, the system employs a significant degree of centralization across contracts and expects deployments to be performed securely as many contracts rely on immediate initializer invocations post-deployment.

From a code-style perspective, there are several instances whereby project-specific abbreviations are utilized that are very similar between them (i.e. diid and diidd) adversely affecting the code's legibility.

Given that variable names do not affect the generated bytecode, we strongly recommend that proper and full-length names are utilized for variables to minimize syntax mistakes and to ensure that consumers of the codebase can immediately deduce what each variable refers to.

Over the course of the audit, we identified a total of five major vulnerabilities in addition to other issues in the codebase which are as follows:

  • Omnichain identifiers employ an incorrect bitwise shift operation
  • An EIP-1155 batch burn operation will burn assets from the caller rather than the from address
  • An EIP-721 burn operation will not validate authorization between the caller and the from address
  • An EIP-20 fraction burn operation will utilize an incorrect total supply to calculate percentages
  • An EIP-1155 fraction burn operation will utilize an incorrect total supply to calculate percentages

We advise the Evergon Labs 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 Evergon Labs team iterated through all findings within the report and provided us with a revised commit hash to evaluate all exhibits on.

We evaluated all alleviations performed by Evergon Labs and have identified that a single exhibit has not been adequately dealt with. We advise the Evergon Labs team to revisit the following exhibit: OFF-02M

Additionally, we would like to note that the alleviation implemented for ONF-03M should be applied throughout any callback-invoking EIP mechanism (i.e. EIP-721, EIP-1155 callbacks, etc.) across the omni-chain transfer implementations to ensure similar vulnerabilities do not manifest in other implementations of the system.

Post-Audit Conclusion (18bd9a145a)

The Evergon Labs team evaluated our follow-up recommendations and opted to integrate both of them into the codebase.

We validated that OFF-02M was properly alleviated and that the broader recommendation of ONF-03M was applied properly.

Additionally, we evaluated a new WrapperFactory implementation and confirmed that it has been securely implemented.

We consider all outputs of the audit report properly consumed by the Evergon Labs team with no outstanding remediative actions remaining.

Audit Synopsis

SeverityIdentifiedAlleviatedPartially AlleviatedAcknowledged
1100
312902
131201
8800
5500

During the audit, we filtered and validated a total of 8 findings utilizing static analysis tools as well as identified a total of 50 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 can introduce potential misbehaviours of the system as well as exploits.

Total Alleviations

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