Centrifuge pools - fixed hub control and multichain distribution
Last updated:Centrifuge pools organize financial products around a fixed hub chain, with local spokes hosting share tokens and investment vaults. In the V3 architecture, the hub coordinates product configuration and accounting across those deployments. Each pool can contain multiple share classes, and each class can reach several networks. Local vaults determine accepted investment assets and deposit execution.
A manager can administer the product from its hub while investors interact through contracts on its distribution networks. Adding distribution networks extends an existing pool. Token deployment, vault deployment, and investor permissions each govern a different part of its reach.
The short version: Deploying a share token on a network enables holding, while a local vault provides its subscription and redemption entry point.
Hub contracts and local spoke balances
One hub coordinates each pool, while spokes maintain the contracts and local balances needed to distribute its share classes across the networks the product uses.
Pool configuration on the hub
Pool creation currently requires an authorized onboarding process. The Hub contract brings pool administration together, including manager assignments, share class configuration, and notifications to distribution networks. HubRegistry records the pool’s denomination and manager configuration. ShareClassManager tracks each class’s metadata, share prices, and issuance across deployments. Holdings records asset positions, and Accounting supports double-entry bookkeeping when the product uses onchain accounting. The architecture accommodates both offchain financial products and wholly onchain strategies.
Local deployment on a spoke
The Spoke contract registers pools and classes locally and coordinates token and vault deployment. A local BalanceSheet tracks asset and share balances, while PoolEscrow holds the pool’s onchain assets on that network. Factories create the relevant contracts. Local records connect the network’s assets and share issuance with the pool’s cross-chain management. A spoke can also live on the hub chain itself. A product operating on that chain alone still uses both roles, with operations between them settling on the same blockchain.
Registration messages connect network deployments
Registration messages make an existing pool and its share classes recognizable on another network, linking local token and vault deployments to the same product. The manager configures messaging adapters before sending remote notifications. NotifyPool identifies the pool on the destination, while NotifyShareClass supplies class details and the selected token hook. The destination Spoke coordinates the appropriate local contracts. Managers can batch administrative calls through the Hub’s multicall support. The Gateway routes communication through configured adapters, and the pool’s confirmation threshold governs when delivered messages can proceed to processing.
Spokes report holding changes and share issuance to the hub. Request callbacks carry processed order outcomes back to the local request manager, connecting local execution with hub-side decisions. Destination contracts apply notifications as messages execute, so a hub-side change and its remote update represent different observable states.
Which settings remain fixed after a pool launches?
The hub chain and denomination currency remain fixed after pool creation, while managers can configure distribution networks, investor permissions, share classes, and vaults afterward. Moving pool management to a different hub chain requires creating a new pool. The product’s users would also need to migrate. Hub choice determines the network where hub-side management transactions consume gas. Adding a spoke extends distribution from that existing hub without replacing the pool’s administrative home.
The denomination supplies the unit used for pricing and accounting. Vault configuration determines accepted investment assets, so the pool’s accounting currency does not define its available deposit tokens.
Share classes define terms, while vaults define entry paths
A share class groups ownership units with defined economic terms, while a vault connects that class to an accepted investment asset and a specific execution model on a network.
Class identity across token deployments
A pool can contain several share classes with different pricing or investor permissions. On networks compatible with the Ethereum Virtual Machine, each class can have an ERC-20 share token. The same class retains unified issuance tracking and share pricing, with updates traveling through protocol messages. Token deployment enables holding and permitted transfers on that network. A local vault supplies the investor-facing deposit and redemption entry point. Cross-chain share transfers depend on the product’s configuration.
Accepted assets and deposit execution
ERC-7575 support lets several vaults accept different assets while issuing the same share token. SyncDepositVault combines synchronous deposits under ERC-4626 with request-based redemptions under ERC-7540. AsyncVault uses request-based deposits and redemptions. A synchronous vault’s deposit capacity limits how much it can accept. Choosing a deposit model concerns available strategy liquidity and settlement timing, while the class defines the investment units. Both shipped vault types keep redemptions request-based, even when deposits settle immediately.
A shared class across local and remote vaults
In this hypothetical configuration, a pool distributes one share class through vaults on its hub chain and a remote supported network, with independently chosen investment assets and deposit models.
The local token on each network represents that same class. Both vaults connect to the same pool, while each uses its configured investment asset. The hub retains administration and pricing; the spokes maintain local asset balances and token contracts. The remote deployment adds a local entry path to the existing product. It does not create a second independently managed fund or require a new hub.
Suppose the hub-chain vault accepts deposits synchronously and the remote vault uses requests. The hub-chain investor receives shares in the deposit transaction. The remote investor submits a deposit request and claims the resulting shares after manager processing. Each path gives the investor tokens for the same share class. Both vaults still process redemptions through requests.
Access remains conditional on the class’s restrictions and each vault’s configuration. Shared class identity does not bypass a configured membership requirement or make the request-based vault accept instant deposits.
Manager authority and investor permissions
Hub management, local asset authority, and investor membership control different actions within the same pool, so assigning one role does not grant every permission.
Control over pool settings and local assets
Hub managers configure share classes, prices, vaults, and operational roles. The hub manager grants balance sheet management rights separately for each network. A balance sheet manager can move pool assets and issue or revoke shares within its authorized network. This role cannot change share classes or prices.
Request managers carry deposit and redemption messages between hub and spoke. The role alone grants no asset custody rights. One contract can hold both request manager and balance sheet permissions, with separate authorization for each role.
Access to subscriptions and token transfers
FullRestrictions requires membership for deposits, redemptions, and transfers. FreelyTransferable keeps membership requirements for investment and redemption requests, while allowing secondary transfers subject to freeze controls. These profiles describe different distribution choices within the same infrastructure. Investor membership grants access to the actions the selected profile allows, without conferring pool management authority.
A compromised hub manager can change pricing and reconfigure pool security. Scoped local roles limit their holders’ powers, while the hub manager retains broad authority. Choosing an entry path therefore involves the class’s permissions as well as the vault’s accepted asset and execution model.
Quick answers about Centrifuge pools
What distinguishes pools whose share tokens have the same ticker?
A pool’s unique pool ID identifies its protocol structure across networks. Token names and tickers describe a share class and can change, so a matching ticker alone does not establish a shared pool. The pool ID and class identity distinguish separate products from multiple deployments of the same product.
Which gas costs accompany a pool’s deployment on another network?
Remote deployment uses hub-chain transaction gas and funding for cross-chain messaging. Notification calls accept native currency to cover message costs and refund excess funding to the specified refund address.
Can the original hub manager lose access to a pool?
Another authorized hub manager can revoke the original manager’s role. The launch wallet has no permanent entitlement to administrative control. The protocol also permits removal of the final hub manager, leaving the pool without top-level administrative access. Manager changes differ from the fixed hub-chain choice: addresses can change while the pool’s hub network stays the same.
How can a pool pause messaging without halting every other pool?
A gateway manager can block outgoing messages for its assigned pool on a specific destination chain. The hub manager grants this role per chain. This pool-level control differs from the protocol-wide guardian pause, and the gateway manager role alone grants no authority to move assets or change the pool’s financial state.
Can offchain subscriptions enter a pool without investor vault requests?
Managers can issue pool shares directly for subscriptions arranged offchain. Direct issuance uses the applicable execution price and still respects the token’s configured access rules. A direct settlement can assign individual amounts and prices to multiple investors, while those execution prices leave the class’s published token price unchanged.
Does disabling a vault automatically disable the pool’s other vaults?
Disabling a vault stops new deposits and requests through that vault, without disabling the pool’s other vaults. Managers can disable and re-enable individual entry paths as distribution needs change. Separate vaults serving the same token remain independently managed, so a closure on one network does not establish a pool-wide closure.