Ocean Protocol security record
As of 30 Oct 2026, Ocean Protocol has 2 audit reports by 2 security firms on Trustblock; the latest is by OpenZeppelin, dated 12 Oct 2023. Those reports list no open critical findings.
Record last updated . It holds audits and findings, contracts and incidents up to Oct 2026. Trustblock does not review code.
Audits2
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| Ocean Vesting Wallet Audit | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | No open critical findings | Open · blog.openzeppelin.com |
| Ocean Protocol v3 | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
Findings67
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 1 | 0 |
| Medium | 1 | 2 | 2 |
| Low | 0 | 30 | 31 |
HighInvalid AssumptionOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The _viewlock_ modifier and the way it is utilized infer that the functions it guards will be uninvokable when the reentrancy mutex has been placed on the contract. While this is true, they will not be "unviewable" as it would still be possible for an attacker to gain access to the underlying data the function's protect via low level assembly calls. As such, its usefulness can be disputed as it can ultimately be bypassed.
Open the reportMediumOwner of the Splitter Contract Can Dilute Existing ShareholdersOcean Vesting Wallet Audit · OpenZeppelin · 12 Oct 2023Acknowledged
The report gives no description here.
Open the reportMediumVestingWalletHalving Administrative Functions Ignore Previously Released TokensOcean Vesting Wallet Audit · OpenZeppelin · 12 Oct 2023Acknowledged
The report gives no description here.
Open the reportLowThe Caller of release Will Pay Gas Fees for All PayeesOcean Vesting Wallet Audit · OpenZeppelin · 12 Oct 2023Acknowledged
The report gives no description here.
Open the reportLowCalculation OptimizationsOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The whole contract could be further optimized.
Open the reportLowCompatibility NoticeOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The linked function implementations are correct in evaluating whether the transfers were successful or not, however certain ERC20 tokens incorrectly implement the specification by ultimately not returning any variable.
Open the reportLowdelete Instead of Empty AssignmentOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The linked statement assigns a zeroed out struct to the mapping location of the unbound token.
Open the reportLowDocumentation of FunctionalityOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The functions bmul and bdiv conducts a ceiling operation on the result which is undocumented.
Open the reportLowERC-20 Compatibility NoticeOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The linked function implementations are correct in evaluating whether the transfers were successful or not, however certain ERC20 tokens incorrectly implement the specification by ultimately not returning any variable.
Open the reportLowExplicit return of Named Return VariableOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The spotPrice is a named return variable, meaning that whatever value it holds will be automatically returned at the end of the function's execution. On the last statement of calcSpotPrice , the final value the function is meant to return is assigned to the return variable as well as returned explicitly.
Open the reportShow 10 more
LowFunctionally Equivalent GettersOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The two linked getters return the exact same variables albeit the latter of the two imposes a require check prior to fulfilling the getter request.
Open the reportLowGeneral CommentOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
No findings were identified at this stage of the audit.
Open the reportLowInconsistent SpecificationOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The specification of the calcSingleInGivenPoolOut function states that the denominator of the division is equal to 1, denoted by the constant BONE , subtracted by the normalized weight (weight in divided by total weight) and finally multiplied by the swap fee. This is not aligned with the actual calculations carried within the function as a final additional subtraction occurs between the final result of the above equation and once again the value of 1 denoted by BONE , the value being subtracted from BONE .
Open the reportLowIncorrect CommentOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The linked comment contains a discrepancy with the actual implementation that accompanies it. The comment implementation contains a subtraction with 1 whereby the Solidity implementation contains an addition.
Open the reportLowIncorrect Variable LabelsOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The function setController is meant to replace the existing controller address with a new one, however the new one is labelled as manager and its accompanying error message also states ERR_INVALID_MANAGER_ADDRESS which is not the case as we are handling a controller at this point.
Open the reportLowInvalid DocumentationOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The getCurrentTokenIndex function, as its comments dictate, should return the index of the current token. However, the variable returned is actually initialized at 1 and is named currentTokenCount .
Open the reportLowMisleading CommentOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The comment denotes that the index member of the struct is private , a concept that does not exist within Solidity in the same terms it exists in other languages. Any contract can arbitrarily read the storage of another contract regardless of what access control restrictions are imposed, meaning that this comment can be misleading to an unaware reader
Open the reportLowNecessity of Function VisibilityOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The `createToken` function is declared as `public` yet remains unused by any of the contracts within the project.
Open the reportLowPull-over-Push PatternOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
Directly replacing the managerial address of a contract is dangerous as a single misinputed character can freeze the administrative functions of the contract indefinitely.
Open the reportLowRedundant require ChecksOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The linked require checks are redundant as they are checked by the underlying implementation of bsub .
Open the reportShow 10 more
LowRedundant Type CastingOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The variables utilized are already of type address and are redundantly casted to that data type.
Open the reportLowRedundant Value AssignmentOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The linked initialized variable is a bool data type. In Solidity, all data types are automatically assigned their default value, in the case of a bool being false , meaning that the explicit assignment of false to the variable is redundant.
Open the reportLowrequire to modifierOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The linked require statements are replicated multiple times across the contact and can instead be set as re-usable modifiers .
Open the reportLowStruct OptimizationOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The index variable is declared as a uint which is a shorthand of uint256 whilst it is meant to represent values between 0 and 8 , according to the imposed limit of BConst.sol ( MAX_BOUND_TOKENS being equal to 8 ). Since this number will always realistically fit even within a uint8 representation never exceeding the value of 255 it is possible to adjust its data type to tightly pack it with the preceding bool variable bound reducing the total storage cost of the struct from 4 slots to 3, significantly optimizing gas cost.
Open the reportLowUnusual Naming ConventionOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The naming convention utilized for the linked modifiers does not conform to the Solidity style guide as it includes the underscore ( _ ) character on both ends of the name declaration.
Open the reportLowUser Defined GetterOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
In general, it is a good practise to avoid user-defined getters and instead rely on compilergenerated ones via the `public` keyword as they are far more maintainable and aid in the legibility of the codebase.
Open the reportLowUser Defined GettersOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
In general, it is a good practise to avoid user-defined getters and instead rely on compilergenerated ones via the public keyword as they are far more maintainable and aid in the legibility of the codebase.
Open the reportLowUser Defined GettersOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
In general, it is a good practise to avoid user-defined getters and instead rely on compilergenerated ones via the public keyword as they are far more maintainable and aid in the legibility of the codebase.
Open the reportLowValue Based RefundOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The current implementation utilizes a value-based refund instead of a proportional refund.
Open the reportLowVariable Mutability SpecifiersOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
The linked variables are only assigned to once in their actual declaration.
Open the reportShow 3 more
LowVariable Naming ConventionOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
While the documentation of the functions was extremely helpful in properly evaluating the intended purpose of the functions, the variable names utilized within (foo, bar, zaz etc.) are generally utilized as placeholders and are ill-advised to exist in production-ready code.
Open the reportLowVariable OrderingOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
Within Solidity, the order of variable declaration is important within a contract as it dictates how the compiler will tightly-pack the variables it is provided with. While the layout of the contract does not appear to follow a particular convention, it has tightly packed most slots possible except one.
Open the reportLowVariable UsefulnessOcean Protocol v3 · CertiK · 8 Oct 2020Acknowledged
Throughout the codebase, these two input variables appear to be hard-coded as false when passed to the function call.
Open the reportContracts
No deployed address is recorded for these audits.
The reports name a repository or files. Open a report to see its scope.
Show this on your site
Is this your project? Show this record on your own website. The label states what the record holds, links to this page and updates by itself. It is free and needs no sign-in.
Content
Automatic: the three strongest facts of this project’s own record (its last audit and two more), highlighted. They update with the record. Picking a fact turns Automatic off.
Style
Format
<head><script src="https://widget.trustblock.run/project-widget.min.js" defer></script></head><body><divdata-tb-project-widgetdata-tb-project-slug="ocean-protocol"></div></body>
Paste the code where the label should appear. It uses no API credit and updates by itself.
Something wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us