Skip to content

Diamond Comptroller in the Core pool

The BNB Chain Core Pool Comptroller uses a Unitroller proxy followed by a Diamond selector router. This architecture is specific to the BNB Core Pool; Core Pools on other networks use BeaconProxy Comptrollers from the isolated-pools repository.

As the original Comptroller grew, its implementation approached the EVM contract-size limit. Venus split application logic into facets while retaining the existing Unitroller address and storage layout.

The call path is:

user or vToken
│
▼
Unitroller (storage and public entry point)
│ delegatecall
▼
Diamond (selector router)
│ delegatecall selected by msg.sig
▼
Facet (application logic in Unitroller storage context)

Users, vTokens, and integrations continue to call the Unitroller. The Diamond and facet addresses are implementation details and must not be called as stateful application contracts.

The current Diamond routes selectors among five facets:

The facets inherit shared checks and the current ComptrollerV19Storage layout from FacetBase. Depending on the function, access may be limited to the Unitroller admin, an admin-or-guardian path, or a signature-specific Access Control Manager permission.

The Unitroller admin can install a new Diamond implementation through the Unitroller’s pending-implementation flow. The admin can also call diamondCut through the Unitroller to add, replace, or remove selector assignments.

An integration can inspect the current routing through:

  • facetAddress(bytes4) for one selector;
  • facetFunctionSelectors(address) for one facet;
  • facetAddresses() or facets() for the full map.

At BNB Chain block 132,749,058, the Unitroller used five facets. VIP-640 installed the Diamond and the PolicyFacet, RewardFacet, SetterFacet and FlashLoanFacet; VIP-672 replaced the MarketFacet. See the live component map for the snapshot addresses.