Collateral Onboarding and Offboarding Workflow

The collateral onboarding and offboarding workflow defines the end-to-end process for altering the set of assets that back the Synthetix debt pool. This is not merely a governance vote; it is a multi-phase operational sequence involving risk assessment, oracle integration, parameter configuration, and a controlled rollout. Each step is designed to ensure that a new collateral type does not introduce systemic risk to the shared debt pool and that a deprecated asset can be removed without triggering unintended liquidations or market disruptions.

The workflow begins with a quantitative risk assessment that models the asset's volatility, liquidity, and correlation with existing collateral. This analysis directly informs the configuration of critical parameters such as issuance ratio, liquidation ratio, and any applicable haircuts. Following governance approval, the technical integration phase requires a reliable Chainlink or Pyth price feed with verified staleness thresholds and circuit breaker logic. The final stage is a phased rollout, often starting with a capped debt ceiling that is gradually increased as the system demonstrates stability under live market conditions.

For offboarding, the process is equally rigorous. A deprecated asset must have its debt ceiling reduced to zero, preventing new issuance, while existing positions are given a clear timeline to migrate or close. Protocol operators and risk teams must actively monitor vault health during this period to manage the risk of a liquidity crunch. A failure to follow this structured workflow can lead to mispriced collateral, bad debt accrual, and a loss of confidence in the system's solvency. Chainscore Labs provides independent review and implementation support for teams navigating this high-stakes process.

Synthetix V3 fundamentally restructures the protocol's financial backbone by replacing the monolithic V2x debt pool with a modular architecture of discrete, isolated vaults. Each collateral type—such as sUSDC, sETH, or a stablecoin LP token—is deposited into its own dedicated vault, which is then delegated to one or more pools to provide liquidity for specific markets like perps or spot. This design is the critical context for the collateral onboarding workflow: adding a new asset is not merely a parameter tweak but the deployment of a new vault contract that must be securely integrated with the pool delegation, reward distribution, and liquidation systems.

From an operational perspective, the integration points for a new vault are extensive. The vault's oracle configuration must be aligned with the NodeModule to define a price feed, which can be a direct Chainlink or Pyth node or a more complex aggregation of multiple sources. The CollateralModule then uses this price to enforce the vault's specific issuance ratio and minimum collateralization ratio (c-ratio). Crucially, the vault's liquidation logic is not a global setting; it is configured per vault, meaning the onboarding process must explicitly define the liquidation reward, the keeper flagging window, and the account health calculation method. A misconfiguration here can create an unbacked debt position or a vault that is economically unviable for liquidators to service.

For builders and integrators, the V3 architecture means that the interface for interacting with collateral is no longer a single proxy. A new vault's address must be registered in the VaultModule and its associated pool delegations set via the PoolModule. Wallets, exchanges, and front-ends that track user positions must update their indexing logic to monitor the new vault's CollateralDeposited and CollateralWithdrawn events. Before a governance vote to onboard a new collateral type, a thorough review of these integration points—from the oracle node definition to the liquidation parameter tuning and event schema compatibility—is essential to prevent a fragmented user experience or a solvency risk. Chainscore Labs can provide an independent readiness review of this entire configuration before it goes to a Spartan Council vote.