🛡️ Security & Risk Mitigation

Fume’s protocol is designed from the ground up with security as its core principle. While the protocol automates administrative tasks, the underlying liquidity remains in secure, segregated custody. The protocol only interacts with liquidity during key moments such as subscriptions, redemptions, and fee management. This approach minimizes the risk of exposure and ensures that liquidity is always handled in a secure environment.

The protocol architecture has been designed by engineers from EPFL, one of the most renowned computer science universities.

External Security Review

Fume is committed to maintaining the highest level of security for its smart contracts. We engaged ChainSecurity, one of the leading smart contract auditors, to conduct a review of our protocol.

This review provided an independent assessment of our architecture, validating our approach and pointing out any improvements to further strengthen robustness. By working with top-tier security experts, we ensure that our protocol continues to meet the highest standards of safety and risk management.

👉 Read the ChainSecurity report

Security by Design

After an on-chain fund is deployed by Fume, only authorized parties can interact with the smart contract:

• Fund Manager (Owner): The fund manager is granted the ability to whitelist investors, move liquidity, perform NAV calculations, and pay fees.
• Whitelisted Investors: Only investors approved by the manager can interact with the smart contract, and their actions are limited to subscribing to the fund or redeeming their shares.

By restricting access in this way, Fume drastically reduces the on-chain attack surface, eliminating 99.9% of potential vulnerabilities typically targeted in hacks.

Authentication and Access Control

There are no passwords on Fume. Users sign in with a one-time code sent to their email, powered by Privy (security details). Logging in gives a read-only view of the fund. Any action that moves money or changes the fund (calculating NAV, moving liquidity, settling liabilities) requires wallet approval from the fund manager. We recommend multi-signature solutions like Safe Wallet or Fireblocks for the governance wallet.

For funds with multiple managers, the fund owner can specify exactly which wallets are allowed to perform which actions on the smart contract. One manager might be authorized to whitelist investors, another to run NAV calculations. No wallet gets more access than it needs.

We also do not store on-chain anything that could be considered personal or sensitive data for any of our users. We store those in our server and database, protected by best practices, industry-leading security, and encryption.

All the wallets that have important responsibilities on the Fume side are safe multisig smart wallets.

Implementation Best Practices

Fume adheres to industry-leading implementation standards to mitigate risks, including:

• 100% Code Coverage: Our smart contracts are thoroughly tested, with every line of code covered in automated testing. This includes a method called fuzzy testing, which randomly generates valid inputs to identify edge cases. GitHub actions are used for continuous testing.
• Integer Overflow/Underflow: We ensure our contracts are protected against overflow and underflow errors. Solidity version 0.8.0 automatically handles these by throwing errors and reverting when such issues arise.
• Re-entrancy Attack Prevention: To safeguard against re-entrancy attacks, we employ two strategies: ensuring proper code ordering and utilizing the OpenZeppelin re-entrancy guard. These measures, combined with thorough syntax checks using tools like Foundry, Mythril, and Slither, ensure maximum contract security.
• Internal code review: the Fume team internally reviews every change before even considering changing lines of code.

Fixes and Upgradability

If an unforeseen issue arises that cannot be fixed on the fly, we have developed a two-tiered approach:

1. No Upgradeable Contracts: We’ve opted not to use upgradeable contracts, as they introduce additional attack vectors and technical complexity.
2. Redeployment with Catch-Up Mechanism: Instead of upgrading, we redeploy a new contract with the corrected code. Importantly, the fund’s state and history are preserved through a catch-up mechanism—all key events are logged on-chain, allowing the new contract to "replay" the fund’s history and resume from the exact state before the redeployment.
3. Multisig and best practices for security: the wallet responsible for managing these processes is a safe multisig smart wallet.
4. Approval required:The CTO has to personally approve all changes to the application and the contracts.