Introduction and Diamond Explainer
A Brief Overview of the Diamond Architecture
Introduction and Diamond Explainer
Symmio's core contracts are organized as a Diamond: a single deployed proxy address that internally routes calls to a set of facets (logic contracts), each responsible for a slice of the protocol's functionality. The Diamond pattern is defined in EIP-2535.
There are two main Diamonds in the current (0.8.5) architecture:
The Symmio core diamond: quotes, positions, funding, liquidation, settlement.
The AccountLayer diamond: sub-accounts, virtual accounts, affiliates, fee distribution, hooks.
The InstantLayer is a separate (non-Diamond) contract that sits in front of both, providing EIP-712 batched execution and delegation.
Why a Diamond?
The protocol is large (quote management, funding rates, liquidation, ADL, ClearingHouse, oracle-less binding, withdrawal flows), and it wouldn't fit inside a single contract under the 24 KB EIP-170 limit. The Diamond pattern splits the logic across many smaller facets while keeping a single stable address that users and integrators interact with.
It also gives per-function upgradeability: new behavior can be added or fixed without redeploying the whole protocol or changing the address that frontends, indexers, and bots point at.
Facets and selectors
Each facet exposes a set of external functions. The Diamond maintains a mapping from function selector (the first four bytes of keccak256(signature)) to the facet address that implements it. When a call arrives:
The Diamond's fallback reads the selector from
msg.sig.It looks up which facet implements that selector.
It
delegatecalls into that facet.
Because the call is a delegatecall, the facet code runs in the Diamond's storage context: facets are stateless executables that operate on the Diamond's storage. This is what lets the protocol be split across many facets while preserving a single shared state.
To see the full facet/selector mapping for a given chain, use the Intent Inspector: paste any diamond address and you'll get a live readout of every facet, every selector, and which function sits at which selector.
Storage layout
Sharing storage across facets is the most error-prone part of working with diamonds. Symmio uses the Diamond Storage pattern (sometimes called AppStorage): each storage area is namespaced under a fixed slot derived from a string constant, e.g.
Library functions resolve slot → struct and let facets read and write the same struct from anywhere. Because slots are derived from unique strings, two unrelated storage areas can't collide as long as the strings are unique.
Notable v0.8.5 storage areas on the AccountLayer:
AccountStorage
keccak256("diamond.standard.storage.accountlayer.account")
SubAccount/VA data, nonces, globalSigner, AccountManager bytecode
AffiliateStorage
keccak256("diamond.standard.storage.accountlayer.affiliate")
Affiliate configs, fee details, hooks, operators, hookContext
AccountLayerStorage
keccak256("diamond.standard.storage.accountlayer")
RBAC (hasRole, roleAdmins), global pause flag
Reentrancy guard
keccak256("diamond.standard.storage.accountlayer.reentrancy")
Reentrancy status flag
The Symmio core diamond has its own set of storage areas for quote state, balances, funding rates, and so on.
Last updated