ChainScore Labs
All Guides

Asset Onboarding Criteria for Synthetic Protocols

LABS

Asset Onboarding Criteria for Synthetic Protocols

Chainscore © 2025

Core Pillars of Onboarding

The foundational criteria synthetic asset protocols use to evaluate and integrate new collateral assets, balancing security, utility, and market stability.

Collateral Security & Verifiability

On-chain verifiability is paramount. The asset's supply, ownership, and transfer history must be transparently auditable on its native chain.

  • Requires a public, immutable ledger for all transactions.
  • Excludes opaque, off-chain, or privately settled assets.
  • Enables the protocol to algorithmically verify collateral backing without trusted oracles.
  • This direct verifiability is the bedrock of trustless synthetic issuance.

Price Feed Resilience

Oracle robustness determines an asset's viability. The reference price must be manipulation-resistant and available during high volatility.

  • Relies on decentralized oracle networks like Chainlink or Pyth.
  • Assesses liquidity depth across major CEXs and DEXs for feed accuracy.
  • Requires low latency and high uptime to prevent stale price attacks.
  • A resilient feed is critical for accurate collateral valuation and safe liquidations.

Market Depth & Liquidity

Sufficient liquidity ensures the underlying asset can be acquired or exited without significant slippage, protecting the protocol's solvency.

  • Measured by 24h volume, order book depth, and spread on primary markets.
  • High liquidity allows for efficient liquidation of undercollateralized positions.
  • Mitigates the risk of market manipulation via large, isolated trades.
  • Protocols often set minimum liquidity thresholds (e.g., $50M daily volume) for onboarding.

Regulatory & Compliance Posture

Regulatory clarity assesses legal risks associated with the asset's classification and the jurisdictions of its holders.

  • Evaluates if the asset is likely deemed a security by major regulators (e.g., SEC, MiCA).
  • Considers the asset's issuance history and centralization of control.
  • Aims to minimize protocol exposure to enforcement actions or geo-blocking requirements.
  • This analysis protects the protocol's long-term operational viability.

Technical Integration Complexity

Cross-chain interoperability defines the effort required to securely bridge and custody the asset within the protocol's ecosystem.

  • Evaluates the maturity and security of available canonical bridges or trust-minimized solutions.
  • Assesses smart contract risks of the asset's standard (e.g., ERC-20, SPL) and any unique logic.
  • Considers gas efficiency for frequent price updates and transfers.
  • Higher complexity can delay onboarding or require custom, audited adapters.

Community Demand & Utility

End-user utility validates the synthetic asset's purpose. Demand should be driven by clear use cases, not mere speculation.

  • Identified through governance proposals, market surveys, and derivative trading volume for similar assets.
  • Use cases include hedging, leveraged trading, payments, or as collateral in other DeFi protocols.
  • An asset with strong utility ensures an active market for the synthetic, maintaining peg stability.
  • This pillar aligns protocol growth with actual user needs.

Risk Assessment Models

Understanding Risk Assessment

Risk assessment models are systematic frameworks used by synthetic protocols to evaluate the safety and viability of adding a new asset. They analyze factors like price volatility, liquidity depth, and market manipulation potential to decide if an asset can be minted as a synthetic token.

Key Components of Risk

  • Price Feed Reliability: Assessing the quality and decentralization of oracles providing the asset's price. A single, centralized oracle is a major risk.
  • Market Liquidity: Evaluating the trading volume and depth on major exchanges. Low liquidity can lead to high slippage and price inaccuracies.
  • Collateral Volatility: Analyzing the historical price swings of the underlying asset. Highly volatile assets require higher collateralization ratios to protect the protocol.

Real-World Example

When Synthetix considers adding a new crypto asset, it reviews its trading history on venues like Binance and Coinbase, the robustness of its Chainlink oracle feed, and its correlation to existing assets in the system to avoid concentrated risk.

Liquidity and Market Depth Verification

Process for evaluating an asset's on-chain liquidity to ensure robust synthetic asset creation.

1

Define Liquidity Metrics and Data Sources

Establish the key quantitative thresholds and identify the primary data endpoints for analysis.

Detailed Instructions

Define the minimum liquidity thresholds required for synthetic asset onboarding. Common metrics include a 30-day average daily volume exceeding $1 million and a market capitalization above $10 million. Identify the primary data sources, such as DEX aggregator APIs (e.g., 0x, 1inch), on-chain analytics platforms (Dune Analytics, The Graph), and centralized exchange data feeds where applicable. For Ethereum-based assets, use the Uniswap V3 subgraph to query pool data. Establish a baseline for slippage tolerance, typically requiring that a $100,000 trade does not move the price by more than 2%.

  • Sub-step 1: Set volume and market cap minimums for the asset class (e.g., large-cap vs. altcoin).
  • Sub-step 2: Configure API endpoints for real-time and historical liquidity data.
  • Sub-step 3: Define the acceptable slippage model for large simulated trades.
javascript
// Example: Querying Uniswap V3 pool for 24h volume const query = `{ pools(where: {token0: "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", token1: "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2"}) { volumeUSD txCount } }`;

Tip: Use multiple, independent data sources to cross-verify liquidity figures and avoid reliance on a single oracle.

2

Analyze On-Chain DEX Liquidity

Evaluate the depth and concentration of liquidity across decentralized exchanges.

Detailed Instructions

Assess the liquidity distribution across major DEX pools. Calculate the total value locked (TVL) in primary trading pairs (e.g., WETH, USDC). Use tools like Dune Analytics to visualize liquidity concentration; be wary of assets where over 60% of liquidity resides in a single pool, as this creates a central point of failure. Examine the pool composition for signs of incentivized or "farm" liquidity, which can be ephemeral. Check the historical stability of the liquidity by reviewing 90-day TVL charts. For automated analysis, script calls to DEX router contracts to simulate large swaps and measure expected output.

  • Sub-step 1: Aggregate TVL from all major DEX pools (Uniswap V2/V3, SushiSwap, Balancer).
  • Sub-step 2: Calculate the Herfindahl-Hirschman Index (HHI) for liquidity concentration.
  • Sub-step 3: Simulate a $250,000 swap via the getAmountsOut function on a router.
solidity
// Simulating a trade via a router contract (conceptual) // router.getAmountsOut(amountIn, path); // Where path = [assetAddress, WETH_address]

Tip: Liquidity on concentrated liquidity AMMs (like Uniswap V3) is more capital efficient but can be fragmented across ticks; ensure you aggregate all active positions.

3

Assess Centralized Exchange Depth

Verify order book depth and trading volume on major centralized exchanges.

Detailed Instructions

While synthetic protocols are decentralized, CEX liquidity is a critical indicator of overall market health and price discovery. Use exchange APIs (e.g., Binance, Coinbase, Kraken) to pull order book data for the asset's primary trading pairs (usually against BTC, ETH, or USD stablecoins). Analyze the first 10 price levels on both sides of the book to calculate the available depth. Compute the bid-ask spread as a percentage of the mid-price; a spread consistently below 0.5% is a positive signal. Correlate CEX volume with on-chain DEX volume to identify discrepancies or wash trading. Persistent, high volume on reputable CEXs supports the asset's legitimacy.

  • Sub-step 1: Fetch order book snapshots for BTC and USDT pairs from top-5 exchanges by volume.
  • Sub-step 2: Calculate the cumulative depth available to absorb a $500,000 market order.
  • Sub-step 3: Compare 24h reported CEX volume with on-chain DEX volume for consistency.
bash
# Example curl command to fetch Binance order book (BTC/USDT pair) curl -X GET "https://api.binance.com/api/v3/depth?symbol=BTCUSDT&limit=10"

Tip: Be cautious of assets whose volume is dominated by a single, less reputable exchange, as this may indicate inflated or non-representative liquidity.

4

Evaluate Liquidity Provider Decentralization

Examine the distribution of liquidity providers to assess resilience.

Detailed Instructions

Liquidity provider (LP) concentration is a key risk factor. A pool controlled by a few entities is vulnerable to sudden withdrawal ("rug pull"). Use blockchain explorers and DEX analytics to identify the top LP addresses. For Uniswap V2-style pools, query the balanceOf for the LP token. For Uniswap V3, analyze NFT positions. Calculate the Gini coefficient or Nakamoto coefficient to quantify decentralization. A healthy pool should have a Nakamoto coefficient >5 (meaning at least 5 entities are needed to control 51% of liquidity). Also, check if a significant portion of liquidity is in timelock contracts or owned by the project's treasury, which may indicate aligned but locked incentives.

  • Sub-step 1: Retrieve the list of top 20 LP addresses for the primary DEX pool.
  • Sub-step 2: Calculate the Nakamoto coefficient based on LP token holdings.
  • Sub-step 3: Check if any large LPs are contracts and verify their lock-up status.
sql
-- Example Dune query to find top LPs in a Uniswap V2 pool SELECT "from" as provider, SUM(value)/1e18 as lp_tokens FROM erc20."ERC20_evt_Transfer" WHERE contract_address = '0xpool_token_address' GROUP BY 1 ORDER BY 2 DESC LIMIT 20;

Tip: Sudden changes in LP concentration, especially the exit of a top-3 provider, should trigger an immediate review of the asset's eligibility.

5

Perform Stress Test and Scenario Analysis

Model the asset's liquidity under volatile market conditions.

Detailed Instructions

Conduct a stress test to model liquidity behavior during a market crisis. Use historical volatility data (e.g., 30-day annualized volatility) to simulate a liquidity black hole scenario where sell pressure increases dramatically. Estimate the potential price impact of a sell order representing 10-20% of the 24h volume. Analyze how liquidity providers might behave; automated market makers may see LPs pull out, widening spreads. Model the funding rate impact for perpetual swap-based synthetics if the underlying is heavily shorted. The goal is to ensure the synthetic asset's peg can be maintained even if the underlying market experiences a 3-sigma volatility event.

  • Sub-step 1: Simulate a $2 million sell order using historical order book and pool data.
  • Sub-step 2: Model LP withdrawal by removing the top 3 providers and recalculating depth.
  • Sub-step 3: Estimate the maximum drawdown in liquidity depth during past market crashes.
python
# Pseudocode for a simple price impact model def calc_price_impact(order_size, liquidity_depth): # Assuming linear impact for simplicity impact = order_size / liquidity_depth return impact

Tip: Incorporate funding rate data from perpetual futures markets (like dYdX, GMX) to understand the cost of maintaining synthetic short positions during high volatility.

6

Document Findings and Set Monitoring Parameters

Compile the verification report and establish ongoing liquidity surveillance.

Detailed Instructions

Create a final liquidity assessment report summarizing all metrics: average volume, market cap, DEX/CEX depth, LP concentration scores, and stress test results. Based on the findings, set continuous monitoring parameters and alert thresholds. These typically include a minimum 24h volume (e.g., $500k), a maximum allowable slippage increase (e.g., 50% baseline), and a minimum Nakamoto coefficient (e.g., 3). Configure automated alerts using services like DefiLlama alerts, Tenderly monitoring, or custom scripts that poll DEX subgraphs. The protocol's governance should define the actions for an asset falling below thresholds, such as increasing collateralization ratios or pausing new minting.

  • Sub-step 1: Generate a report with pass/fail status against each predefined criterion.
  • Sub-step 2: Deploy monitoring scripts to track key liquidity metrics daily.
  • Sub-step 3: Define the governance process for reviewing and acting on alerts.
javascript
// Example alert condition for low volume if (dailyVolumeUSD < MIN_VOLUME_THRESHOLD) { triggerAlert("LiquidityWarning", `Volume fell below ${MIN_VOLUME_THRESHOLD}`); }

Tip: Implement a circuit breaker mechanism that can automatically increase the synthetic asset's minting fee or require over-collateralization if liquidity metrics deteriorate rapidly.

Oracle Solution Requirements

Comparison of key technical and economic parameters for synthetic asset price feeds.

RequirementChainlink Data FeedsPyth NetworkAPI3 dAPIs

Update Frequency

Heartbeat: 1 hour Deviation: 0.5%

~400ms per price update

Configurable (1s to 1hr)

Data Source Model

Decentralized Node Operator Network

First-party Publisher Network

First-party Airnode Operators

On-chain Gas Cost per Update

~150k-250k gas

~80k-120k gas

~100k-180k gas

Price Feed Decentralization

31 independent nodes per feed

50 data publishers per asset

Single first-party source per feed

Maximum Price Deviation Threshold

0.5% (configurable)

Dynamic, based on market volatility

Defined by dAPI sponsor

Supported Asset Types

Crypto, Forex, Commodities, Indices

Crypto, Forex, Commodities, Equities

Crypto, Forex, Commodities, Custom APIs

Time to Finality / Latency

~1-3 minutes (block confirmations)

<1 second

Depends on update interval & blockchain

Cost Model for Protocols

Premium subscription + gas reimbursement

Fee per price update (micro-transactions)

Sponsorship model + gas costs

Governance and Parameter Setting

The process of establishing and adjusting the rules for adding new synthetic assets, managed through decentralized governance.

Collateralization Ratio

The collateralization ratio defines the minimum amount of collateral required to mint a synthetic asset. This parameter is critical for maintaining protocol solvency.

  • Typically set as a percentage (e.g., 150% for volatile assets).
  • Adjusted based on asset volatility and liquidity depth.
  • A higher ratio increases safety but reduces capital efficiency for minters.
  • Governance must balance risk and usability when setting this value.

Debt Pool Interaction

Debt pool interaction refers to how a new synthetic asset shares risk within the protocol's global debt pool. This determines the mutualization of risk among all stakers.

  • Assets can be isolated or pooled with others.
  • Pooled assets share liquidation risks across the system.
  • Governance decides the risk tier and integration model.
  • This choice directly impacts staker rewards and potential losses.

Oracle Configuration

Oracle configuration involves selecting and parameterizing the price feed for a synthetic asset. Reliable data is non-negotiable for accurate pricing and liquidations.

  • Specifies the oracle source (e.g., Chainlink, Pyth).
  • Sets the heartbeat and deviation thresholds for updates.
  • Defines a fallback oracle for redundancy.
  • Incorrect settings can lead to stale prices and system exploits.

Minting/Redemption Fees

Minting and redemption fees are protocol charges applied when creating or burning synthetic assets. These fees serve as revenue and a mechanism to manage system behavior.

  • Fees can be dynamic based on system utilization.
  • A redemption fee can discourage rapid exits during volatility.
  • Revenue is often distributed to stakers or a treasury.
  • Governance sets fee schedules to incentivize desired user actions.

Liquidation Parameters

Liquidation parameters define the conditions and mechanics for automatically closing undercollateralized positions to protect the system.

  • Sets the liquidation ratio (e.g., 125%) and penalty.
  • Determines the liquidation reward for keepers.
  • Configures the time buffer before liquidation (if any).
  • Proper calibration prevents bad debt while avoiding premature liquidations.

Governance Voting & Timelocks

The governance process for parameter changes involves tokenholder voting and execution delays. This ensures changes are deliberate and gives users time to react.

  • Proposals require a minimum stake and quorum.
  • A timelock delays execution after a vote passes.
  • Emergency multisigs may exist for critical security patches.
  • This framework prevents rapid, potentially harmful parameter shifts.
SECTION-IMPLEMENTATION-FAQ

Implementation and Integration FAQ

Ready to Start Building?

Let's bring your Web3 vision to life.

From concept to deployment, ChainScore helps you architect, build, and scale secure blockchain solutions.