Collateral Onboarding and Risk Parameter Standards

A new collateral type requires a dedicated Chainlink or Pyth price feed with a defined heartbeat and deviation threshold. Integrators must verify the feed's address on the deployment chain and ensure the node's aggregation logic aligns with Synthetix's staleness tolerance. Failure to configure this correctly can prevent liquidations during volatility, creating bad debt for the pool. Teams should simulate price staleness and deviation scenarios in a testnet environment before the SCCP execution.

Keeper operators must update their bots to monitor the new collateral's vault-specific liquidation ratio and minimum collateralization ratio (c-ratio). The liquidation engine's grace period and auction duration are defined in the SIP, and keepers need to model the profitability of liquidating the new asset, accounting for gas costs and the asset's on-chain liquidity depth. A misconfigured keeper will fail to liquidate undercollateralized positions, directly threatening the debt pool's solvency.

The core V3 router and proxy contracts must be upgraded or reconfigured to recognize the new collateral's contract address and interface. Integrators and front-end providers need to update their event indexing services to track CollateralDeposited and CollateralWithdrawn events for the new asset. A failure to update the subgraph or indexer will result in users seeing incorrect balances and positions in the UI, leading to support issues and potential loss of funds.

Before the on-chain SCCP vote, risk teams must independently validate the proposed parameters: issuance fee, liquidation ratio, and maximum debt share for the new collateral. This involves stress-testing the asset's volatility profile against the pool's existing debt composition. A parameter set that is too aggressive can expose stakers to excessive risk, while overly conservative parameters may stifle adoption. Chainscore Labs provides a formal parameter review service to model worst-case scenarios.

If the collateral is being onboarded on a chain other than Ethereum mainnet, the cross-chain messaging standard (e.g., Wormhole or Chainlink CCIP) must be verified for the new asset's token address. The governance execution must be synchronized so that the collateral is recognized simultaneously on all relevant V3 deployments. A mismatch in the token address mapping across chains can lead to a fragmented debt pool and arbitrage opportunities that drain value from stakers.

Use the official SIP registry as the starting point for collateral onboarding standards. Teams proposing a new collateral type should identify the governing SIP path, confirm whether the change requires protocol logic, a new market module, or only configuration, and review related V3 pool-and-vault architecture proposals before drafting implementation work. Risk teams should search for precedent around collateral enablement, liquidation treatment, issuance ratios, oracle requirements, and governance controls rather than assuming a single universal onboarding template applies across deployments.

The Synthetix SIPs GitHub repository is useful for reviewing proposal history, diffs, authorship, and the exact text that moved through governance. For collateral and risk-parameter work, compare SIP-level design changes with SCCP-style parameter updates such as caps, ratios, fees, and market limits. Engineering and governance operations teams should track pull requests and commits because implementation assumptions can change before a proposal reaches execution or before a configuration change is reflected on-chain.

The official Synthetix documentation should be used to map governance intent into system behavior. For collateral onboarding, focus on V3 accounts, pools, vaults, delegated collateral, market debt assignment, liquidation concepts, and integrator-facing contract patterns. Builders should verify whether a collateral asset affects only a specific pool or creates broader debt-pool exposure, and should not rely on governance text alone when implementing front-end flows, monitoring, or integration logic.

Review the V3 contract source before treating a collateral parameter as operationally safe. Risk parameters such as collateralization ratios, liquidation thresholds, debt limits, market permissions, and oracle manager configuration ultimately matter through contract behavior and deployment-specific settings. Auditors and integrators should trace the relevant modules, storage, events, and permission paths, then compare them with the SIP or SCCP language. This is especially important when a parameter can be changed by governance without redeploying the full system.

If a proposed Synthetix collateral asset depends on Chainlink pricing, teams should validate feed availability, quote currency, update behavior, heartbeat expectations, decimals, proxy usage, and stale-price handling against Chainlink’s canonical documentation and the deployed Synthetix oracle configuration. A feed existing on one network does not imply it is suitable for all Synthetix deployments. Risk reviewers should also assess liquidity depth, exchange coverage, deviation thresholds, and fallback procedures before recommending onboarding or looser collateral parameters.

For collateral or markets using Pyth, verify price feed identifiers, confidence interval handling, update submission requirements, staleness controls, and the operational role of off-chain price publishers. Collateral onboarding reviews should model what happens if updates are delayed, confidence widens during volatility, or keepers fail to submit fresh prices. Builders integrating Synthetix positions should treat oracle update mechanics as part of the collateral risk surface, not merely as a UI data dependency.