Ethereum, Base, Arbitrum, Avalanche, BNB Smart Chain, Plume

Protocol only supports standard tokens with 2-18 decimals (decimals are enforced in Spoke.sol contract), no weird tokens.

Pool manager roles are fully trusted within the context of the pool. Pool manager roles include the hub manager, balance sheet manager, gateway manager, request manager, and hook manager.

Similarly, custom gateway adapters and transfer hooks should be able to do anything in their set pool (ie, trusted), but shouldn't be able to do anything outside of their pool, and can be considered untrusted (in the context of other pools).

Relayers on the on/off ramp manager are fully trusted to decide withdrawal destinations for assets in their pool.

Merkle proof manager strategists are fully trusted to execute calls allowed within the policy set for that pool.

No.

ERC-20: issued share tokens, as well as holdings on the balance sheet of a pool.
ERC-1404: standardized compliance checks for share tokens.
ERC-2612: permit functionality built in to share tokens.
ERC-4626: tokenized vault standard, used for synchronous deposit vaults.
ERC-6909: holdings of multi-tokens on the balance sheet of a pool.
ERC-7540: asynchronous vault standard, used for asynchronous vault logic.
ERC-7575: multi-asset vault standard, to allow multiple investment assets per share token.

Issues related to EIP non-compliance can be valid only if they lead to Medium or High impact, besides the EIP violation itself.

There will be off-chain keepers for:

• Calling notifyDeposit/notifyRedeem for investor request claiming, based on the events from the BatchRequestManager.
• Repaying underpaid transactions (e.g. price updates from SimplePriceManager ), based on events from the Gateway.
• Calling QueueManager.sync, based on events from the BalanceSheet.
• Calling OnOfframpManager.deposit, based on transfers to the on/offramp manager contract.

-

See docs, e.g.

• Cross-chain design: https://v3-1.documentation-569.pages.dev/developer/protocol/features/chain-abstraction/
• Modularity: https://v3-1.documentation-569.pages.dev/developer/protocol/features/modularity/
• Technical architecture: https://v3-1.documentation-569.pages.dev/developer/protocol/architecture/overview/

Audits: https://v3-1.documentation-569.pages.dev/developer/protocol/security/

Known issues:

• Ability to manipulate prices of the SimplePriceManager if on/offramp manager or sync deposits are enabled is known (by depositing to raise assets) => it is up to the pool manager to manage this, e.g. by using max reserve.
• Prices computed in SimplePriceManager may be off if approve and issue or approve and revoke are called separately, as then assets and shares are imbalanced.
• SimplePriceManager.onUpdate may revert, when the ShareClassManager issuance is negative, due to a transfer of shares before a submitQueuedShares, blocking updating a holding value.
• Arbitrage in multi-asset pools is pool manager controlled.
• LayerZero executions on target chain can be front-run and forced to go into failed messages queue.
• Hub.createPool can be frontrun leading to griefing
• Any issue related to arbitrage between different assets/currencies in the same pool. Should be managed by pool manager
• Any arbitrage related to cross-chain price updates
• Issues related to cross-chain messages not being executed for a long time, in the wrong order or create race-conditions
• GasService estimate is under/overestimated.
• Subsidized funds can be spammed: we will add min investment limits to alleviate this.
• AsyncRequest._withdraw() using current pricePoolPerAsset which is potentially unlikely pricePoolPerAsset during approval of redemption
• Only deployed on chains with Cancun EVM support. And no zksync.
• After Root.relySchedule executes, the timelock does not apply anymore => intentional, combined with spell pattern it works
• Guardian only works with Safe, if the admin is not a Safe the pause can only be executed by the full Safe and not individual owners
• Liquidity can be stuck if a user is frozen
• Liquidity can be stuck if all vaults are unlinked
• While paused, users can still claim assets/shares
• Auth pattern does not check that there is at least 1 ward
• Manager needs to ensure hooks across domains are compatible
• User needs to ensure they transfer valid share tokens eg member
• Issues with underlying networks being compromised affecting the pools deployed on that network
• Missing existence checks in Hub for pool/sc/asset and other IDs
• Updating vault or request manager can cause loss of pending request state

Docs: https://v3-1.documentation-569.pages.dev/developer/protocol/overview/

v3.0.1 commit hash to compare: https://github.com/centrifuge/protocol/tree/7ca5819788f6d28d8481932b237951c1ffb7ff3b

Severity clarifications:

1. The DOS-related issues can be considered High severity only if they lead to a permanent lock of funds without a way to retrieve/recover them. If the funds can be recovered and the DOS is only temporary, the issue can be Medium at most.
2. Bypassing any hook check can be considered Medium-severity at most (if leads to Medium impact).
3. Issues that lead to stealing or loss of native tokens stored in the RefundEscrow for gas can be Medium at most.
4. Issues with underlying networks being compromised affecting the pools deployed on that network are out of scope.
5. Issues that are caused by price manipulation (e.g. pool donations) can be Medium at most.

A particular area of concern is pool managers being able to manipulate other pools. Several issues have been found in the past related to this, including:

• A malicious adapter set as a pool adapter, creating a batch that has pool A (its own pool) as the first message, and pool B as the next message(s). Fixed by checking all messages in the batch have the same pool ID.
• A malicious vault factory being used to rely malicious vaults on the existing AsyncRequestManager. Fixed by changing the rely flow.

The main changes in v3.1 versus v3.0.1 include:

• Separated ShareClassManager to a modular BatchRequestManager, and ShareClassManager with only the share class logic
• Simplified Spoke contract, separate VaultRegistry
• New QueueManager for automating balance sheet synchronization to the hub
• New NAVManager for automating NAV calculations
• New SimplePriceManager for automating share price calculations based on the NAV
• New OracleValuation contract for manual updates of asset prices
• Support for UpdateContract from spoke to hub
• Refactored hooks to a BaseTransferHook with simplified implementations on top
• Simplified gateway changes
• Separate protocol and ops guardian
• Gateway payment method has changed from subsidized to pay directly in call with full refunds, except for vaults which implements subsidized payments in the higher level contracts