🛡️ 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. Fume never holds the fund's assets: they stay in the custody the manager chooses. The fund contract holds capital only for as long as needed: between a deposit and the next NAV calculation (or until the manager moves it earlier), and before a payout. A fund can also be deployed with instant transfer, where an investor's payment goes straight to the fund's custody in the same transaction and the units are issued at the next NAV calculation. This approach minimizes exposure and keeps liquidity in a secure environment.

The protocol architecture has been designed by engineers from EPFL, one of the top computer science universities in Europe.

External Security ReviewCopy Anchor Link

ChainSecurity, one of the leading smart contract auditors, reviewed the first version of our protocol. The review provided an independent assessment of our architecture, confirmed our approach, and pointed out areas to strengthen.

👉 Read the ChainSecurity report

The current version of the protocol (v2) is reviewed internally and formally checked: symbolic proofs check key properties of the contracts for every possible input, on top of the automated tests described below.

Security by DesignCopy Anchor Link

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 and eliminates 99.9% of the potential vulnerabilities typically targeted in hacks.

Authentication and Access ControlCopy Anchor Link

There are no passwords on the Tokenization Engine. 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 industry-standard security and encryption.

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

Implementation Best PracticesCopy Anchor Link

Fume follows established implementation standards to mitigate risks:

• Automated testing and formal checks: Our smart contracts are covered by unit tests, fuzz testing (which randomly generates valid inputs to find edge cases), invariant tests (which check that rules such as "the high-water mark never decreases" hold after any sequence of actions), gas-limit tests, and symbolic proofs with Halmos. Every check must pass before a change reaches the main branch.
• Integer Overflow/Underflow: 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 use two strategies: proper code ordering and the OpenZeppelin re-entrancy guard. We combine these with static analysis using tools like Foundry and Slither.
• Internal code review: the Fume team internally reviews every change before even considering changing lines of code.

Fixes and UpgradabilityCopy Anchor Link

If an unforeseen issue arises, it can be fixed without moving the fund:

1. Upgradeable fund contract: Each fund's contract is an upgradeable proxy. A fix is deployed as new contract code, and the fund keeps its address, its state and its history. The share token contracts of each class are not upgradeable.
2. Administrator: Upgrades can only be made by the fund's administrator wallet. Upgrades take effect immediately, with no delay. For funds deployed by Fume, the administrator is a Fume multisig smart wallet. Clients running Fume on-premise hold their own administrator wallet.
3. Limited administrator powers: Apart from upgrades, the administrator can only set the wallet that receives the Fume fee and close down the fund. It cannot change the Fume fee rates. It cannot run the fund: whitelisting, NAV calculations, liquidity and payouts stay with the fund manager.
4. Approval required: The CTO has to personally approve all changes to the application and the contracts.