This document presents the security review performed by Nethermind Security for Origami protocol smart contracts. Origami is a decentralized finance protocol designed to offer users leveraged exposure to the Olympus ecosystem through a tokenized vault system.
The system uses a tokenized balance sheet to manage assets and liabilities, enabling accurate share pricing and redemptions. It includes automated LTV optimization, surplus management for liquidity, and vote delegation for governance.
Users can deposit gOHM tokens that will be used as collateral in MonoCooler to borrow USDS that may be used to do buybacks and increase the gOHM entitled to users. The Vault automates a strategy allowing users to leverage their gOHM to earn more gOHM.
The Vault shares (HOhm) can also be bridged through layer zero to be traded and used on other chains.
The audited code comprises 1,582 lines of Solidity code. The audit was performed using (a) manual analysis of the codebase, (b) automated analysis tools, and (c) creation of test cases.
This review covers 13 contracts organized into four main components: access control, an OFT (Omnichain Fungible Token) standard token, a tokenized vault based on the ERC-4626 standard, and a manager contract responsible for collateral management and enforcing maximum borrowing limits in the Olympus MonoCooler system. Fig. 2 presents a package diagram that highlights the main packages and contracts included in the scope of this review.
Fig. 2: The package diagram shows the main packages and contracts for a system overview.
Origami system relies on LayerZero to use OFT (Omnichain Fungible Token) standard to allow hOHM to be transferred cross-chain. As presented in Fig. 3, the OrigamiTeleportableToken contract is an ERC20 token with the support of the ERC20Permit that does not require token approval to be spent by the trusted teleporter. The OrigamiOFT contract extends the LayerZero OFT contract, allowing cross-chain token transfers while preserving compatibility with ERC-20 and its extensions. All these contracts also inherit from OrigamiElevatedAccess to manage administrative permissions.
Fig. 3 shows that OrigamiTokenTeleporter contract extends the OFTAdapter to enable interoperability of hOHM across multiple chains. Since this contract is deployed on the mainnet, the inner token is locked, rather than burned, when transferred through it.
Fig. 3: The class diagram highlights the omnichain token.Fig. 4: The sequence diagram illustrates the main function calls involved in joining and exiting the vault. For simplicity, it focuses on the token-based join and exit operations. However, the mechanism also supports joining and exiting using shares.
4.1 The Vault and Manager Contracts
The contracts OrigamiHOhmVault and OrigamiHOhmManager work together to implement a tokenized financial mechanism based on collateral and debt. The Vault serves as a tokenized balance sheet vault, allowing users to mint and burn shares in exchange for assets (collateral) and liabilities (debt). The Manager contract handles interactions with the Olympus MonoCooler system to add/remove collateral and to borrow or repay debt, always aiming to maintain the Loan-to-Value (LTV) ratio at the maximum allowed by Cooler. The Manager also manages the delegation of gOHM voting power and handles surplus debt token strategies, optimizing for yield and system stability. Fig. 4 illustrates this interaction between both contracts.
4.1.1 OrigamiTokenizedBalanceSheetVault
As presented in Fig 3, the OrigamiTokenizedBalanceSheetVault contract extends the OrigamiTeleportableToken. Basically, the shares in this vault represent a proportional part of both the assets and liabilities within this structure.
Assets: Represent the positive value held by the vault. They may consist of zero or more ERC20 tokens, with each asset having an independent balance.
Liabilities: Represent the debt owed by the vault. Like assets, these may include zero or more ERC20 tokens with varying balances.
Minting Shares. When users mint new shares:
They provide a proportional amount of each asset based on the current balance sheet.
They receive a proportional amount of each liability.
A number of shares is minted to represent the proportional ownership of the vault balance sheet equity.
Redeeming Shares. Users can redeem their shares:
They provide a proportional amount of liability tokens for the respective number of shares.
They receive a proportional amount of each asset according to the respective number of shares.
Then, the corresponding shares are burned.
Dynamic Balance Sheet:
The asset and liability token balances can change over time due to yield generation, rebalancing, or debt accrual.
The asset and liability token addresses can also change (e.g., rolling yield tokens or removal of tokens with zero balance).
Core functions. Fig. 4 illustrates a sequence diagram for two of the core functions. The contract exposes several public and external functions. Inspired by ERC4626, it provides the following core operations:
seed(assetAmounts, liabilityAmounts, sharesToMint, receiver, newMaxTotalSupply): It is invoked by an elevated access role to initialize the vault. The caller must provide the amount of each asset and liability, along with the number of shares to mint. These values define the initial share price for each asset and liability.
joinWithToken(tokenAddress, amount): Mints shares based on the input of a single asset or liability. The vault derives the share amount and any remaining required token transfers proportionally. Fig. 2 depicts how this function interacts with other contracts.
joinWithShares(shares): Mints a specified number of shares. The vault pulls a proportional amount of assets from the user and sends the corresponding liabilities. The flow is similar to the joinWithToken function, the difference is based on the input parameter.
exitWithToken(tokenAddress, amount): Burns shares to allow for redemption based on a single token (asset or liability). The vault determines the proportional share amount and additional transfers. Fig. 2 depicts how this function interacts with other contracts.
exitWithShares(shares): Burns a specified number of shares. The vault sends a proportional amount of assets to the user and pulls the corresponding liabilities. The flow is similar to the joinWithToken function, the difference is based on the input parameter.
4.1.2 OrigamiHOhmVault
The OrigamiHOhmVault contract is a specialized implementation of the OrigamiTokenizedBalanceSheetVault (shown in Fig. 4), designed to manage a leveraged gOHM position using the MonoCooler lending system. It allows users to deposit gOHM as collateral and receive a combination of vault shares (hOHM) and borrowed debt tokens (e.g., USDS).
This vault tracks a single asset (the gOHM collateral) and a single liability (the debt token). While the base vault handles share minting, burning, and conversions between tokens and shares, OrigamiHOhmVault adds logic specific to the Olympus ecosystem. It delegates all borrowing and collateral interactions to the OrigamiHOhmManager contract.
The key responsibilities of OrigamiHOhmVault include:
- Defining the tokenized asset and liability types (gOHM and debt token).
- Exposing vault controls like areJoinsPaused, areExitsPaused, and burn.
- Synchronizing the delegation of voting power in gOHM.
- Triggering interactions with the manager when users join or exit the vault.
- Managing user share balances and ensuring that delegation amounts reflect current gOHM holdings after minting, transfers, or redemptions.
4.1.3 OrigamiHOhmManager
The OrigamiHOhmManager contract serves as the core logic handler for interactions between the OrigamiHOhmVault and Olympus MonoCooler lending platform. Its primary role is to abstract and automate the process of managing collateral and debt within the vault.
Responsibilities: This manager contract is responsible for:
- Adding and removing gOHM collateral to/from the MonoCooler contract.
- Managing borrowing and repay operations in a way that preserves a target Loan-To-Value (LTV) ratio.
- Automatic synchronization of gOHM delegation through the Olympus delegation module (DLGTEv1).
- Handling exit fees and performance fees during vault exits.
- Maintain a surplus buffer in debtToken (e.g., USDS) to ensure liquidity and support redemptions.
- Interfacing with a Swapper contract to periodically perform buybacks and burn hOHM using excess debt tokens.
Delegation Management: The manager tracks the delegation information per account and updates the delegation amounts automatically when the vault shares change. It computes a user's proportional collateral based on their share of the total supply and submits the corresponding delegation update to the MonoCooler contract.
Debt Optimization: Upon each vault join or exit, the OrigamiHOhmManager invokes the _coolerMaxBorrow function to determine the optimal change in debt necessary to maintain the maximum allowed origination LTV. The result is applied by calling borrow or repay on MonoCooler. This flow is presented in Fig. 4.
Surplus strategy: Any surplus debtToken held by the contract can be deposited in a yield-bearing savings vault (e.g., sUSDS) which has a higher interest rate than the cooler interest rate. The contract also provides the sweep function that can be called to use the surplus token to buy hOHM from the market and then burn it. The goal for this function is to decrease the total supply, consequently, increase the share price of both the collateral and the debt tokens per hOHM.
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.
The Vault allows users to execute join operations that would result in zero shares due to rounding. Users could join but not receive any shares in exchange.
Recommendation
Consider reverting when minting zero shares.
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 Origami team has provided comprehensive documentation that describes expected flows and behaviors, including detailed examples of minting, redeeming, buybacks, and seeding operations. The codebase is also well-commented, addressing both business logic and low-level implementation details. Moreover, the team addressed all questions and concerns raised by the Nethermind Security team, offering valuable insights and demonstrating a strong understanding of the project's technical aspects.
All the relevant issues raised by the AuditAgent have been incorporated into this report. The AuditAgent is an AI-powered smart contract auditing tool that analyses code, detects vulnerabilities, and provides actionable fixes. It accelerates the security analysis process, complementing human expertise with advanced AI models to deliver efficient and comprehensive smart contract audits. Available at https://app.auditagent.nethermind.io.
Test suite
512Tests passed
0Failed
The complete test output is in the full report.
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.
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.
