Used for Centrifuge’s current framing as institutional-grade tokenization and onchain asset-management infrastructure with ERC-4626 / ERC-7540 composability and multichain deployment
Used to confirm that pools are the core product object combining share classes, vaults, pricing logic, permissions, hub-chain anchoring, and asynchronous request lifecycles
Used to confirm the hub-and-spoke architecture, immutable-core-plus-extensions model, standards support, and hub-side authority over accounting and pricing
Used to confirm the single-hub source-of-truth model, multi-provider proof routing, batching, gas subsidies, retries, and burn-and-mint cross-chain transfer design
Official protocol repository landing page / README
Used to cross-check the multichain architecture, immutable-core framing, extension surfaces, licensing model, and current deployment/security-review claims
Used to capture how Centrifuge currently presents itself publicly: tokenized funds, onchain portfolio management, institutional integrations, and DeFi connectivity
Key takeaways from primary sources
Centrifuge’s most useful analytical contribution is not merely RWA tokenization, but a reusable architecture for multichain pool management. The pool object bundles share classes, vaults, pricing, permissions, and request handling into one control surface.
The hub-and-spoke model is the main mechanism worth retaining. The hub is the authoritative pool-management and accounting layer, while spoke chains are user-facing balance sheets and distribution rails.
The protocol’s optional onchain accounting stack is unusually explicit. Double-entry bookkeeping, NAV updates, issuance tracking, and share-price propagation are described as smart-contract responsibilities rather than offchain administrator tasks.
The extension system is a major governance surface. Transfer hooks, hook managers, hub managers, balance-sheet managers, valuation modules, and request managers determine much of the real behavior that a user experiences from a given pool.
The cross-chain transport layer is also first-class. The docs make messaging-provider plurality, batching, gas subsidies, retries, and recovery part of the protocol design rather than invisible backend detail.
Centrifuge’s standards story matters because it exposes several liquidity and redemption interfaces at once: ERC-4626 for synchronous deposits, ERC-7540 for request-based async flows, and ERC-7575 for multi-asset vault structures.
Specific source signals worth retaining
The user Pools page is the clearest single explanation of what a Centrifuge product actually is once the brand is stripped away.
The developer Overview and Chain Abstraction pages are the best sources for understanding where authoritative control sits in the multichain architecture.
The Onchain accounting page is the most important evidence that Centrifuge is not just a distribution layer; it protocolizes accounting and pricing directly.
The Modularity page is the best source for identifying which policy surfaces are standardized versus builder-selected.
The GitHub repository matters because it reinforces that the public docs match an actively maintained protocol codebase and also surfaces the Business Source License framing around much of the implementation.
Why this entry belongs in the corpus
It sharpens the underrepresented multichain tokenized-fund operating system branch between simpler vault stacks and issuer-specific compliance products.
It separates accounting authority, compliance policy, request handling, vault interface choice, and cross-chain transport into reusable comparison layers.
The durable insight is that tokenized-asset infrastructure can decentralize distribution and composability while still centralizing authoritative pricing, accounting, and request orchestration on one chosen hub chain.