For the complete documentation index, see llms.txt. This page is also available as Markdown.

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.

Why the Diamond was introduced

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.

Current facet families

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.

Upgrades and selector inspection

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 118,363,255, the Unitroller used the Diamond and five facets installed by VIP-640. See the live component map for the snapshot addresses.

Last updated