Security

Information about XCCY's security measures, audits, and responsible disclosure.

Security

This page describes protocol-level security properties and contract-enforced controls in XCCY. It focuses on how the system is designed to fail safely and what invariants are enforced on-chain.

Core security model

XCCY separates responsibilities across contracts:

• vAMM / VAMMManager: pricing and delta computation (no custody of funds)

• CollateralEngine: custody, position accounting, settlement, liquidation execution

• RiskEngine: margin requirement computation (worst-case assumptions)

• OracleHub + AprOracle: guarded price inputs (USD valuation) and rate accumulation (VY tracking)

The key safety property is: any state transition that would leave an account undercollateralized must revert.

Access control and permissions

XCCY uses strict call permissions on state-mutating paths:

• updateAccountMargin() Only the account owner can deposit/withdraw collateral for that account.

• updatePositionPostVAMMAction() Only VAMMManager can apply trading/liquidity deltas to positions (prevents arbitrary position mutation).

• liquidateAccount() Permissionless, but only executable when the account is liquidatable (health < 1.0).

Admin-only functions (protocol parameters) are restricted to governance/admin authority. Typical admin-set parameters include:

• worst-case VY bounds (per pool)

• collateral discount factors (per asset)

• oracle configuration and safety thresholds

Oracle safety (prices and rates)

XCCY relies on oracles for two classes of inputs:

OracleHub (USD prices)

OracleHub provides USD prices used for collateral valuation and converting losses to USD. It enforces data quality via:

• staleness checks (maximum acceptable age)

• validity / sanity checks (reject invalid readings)

• optional deviation bounds (reject abrupt jumps beyond configured limits)

AprOracle (rate accumulation)

AprOracle provides an accumulated yield factor over a period:

• getRateFromTo(start, end) returns the accumulated VY factor, not a spot APY

This is used in:

• settlement cashflow computation (realized VY over the term)

• margin calculation inputs (through worst-case bounds and/or conservative assumptions)

Margin and liquidation safety

Worst-case margin requirement

RiskEngine computes margin using conservative assumptions:

• If variableTokenBalance > 0 (receiving VY), worst case assumes VY drops

• If variableTokenBalance < 0 (paying VY), worst case assumes VY rises

The margin requirement is sized to cover the worst-case loss at maturity under these bounds.

Collateral haircuts (discount factors)

Collateral valuation applies asset-specific discount factors:

• stable assets can be near full value

• volatile assets receive haircuts to create liquidation buffer

Health factor gate

Account safety is enforced via:

• health = collateralValue / marginRequired

• health > 1.0 → safe

• health <= 1.0 → unsafe / liquidatable

Any operation that would push health below the threshold must revert (except liquidation paths which are meant to resolve unsafe accounts).

Safety checks on critical actions

Withdrawals

Before allowing a withdrawal, the system must:

1. Bring position/accounting current (mark-to-market / fee growth checkpoints if applicable)

2. Recompute marginRequired and collateralValue after the withdrawal

3. Revert if health would fall below the required threshold

Trades and liquidity actions (swap / mint / burn)

For any state-changing action, the system must:

1. Validate pool state (exists, not expired)

2. Apply deltas through CollateralEngine (positions + fees)

3. Run the margin check and revert if insufficient

Settlement safety

At maturity, settlement computes cashflow using:

• a fixed factor derived from time

• an accumulated variable factor from AprOracle

Then CollateralEngine applies the cashflow to margin:

• positive cashflow credits margin

• negative cashflow debits margin (or triggers forced handling if design requires)

Settlement must be gated by maturity time and must not allow settlement prior to pool expiry.

Liquidation execution model

When an account is liquidatable (health < 1.0), liquidation is permissionless and is executed through CollateralEngine.

Typical liquidation steps:

1. Verify the account is liquidatable

2. Close LP liquidity where applicable (burn)

3. Transfer positions to the liquidator (liquidator inherits fixed/variable balances)

4. Transfer remaining collateral per protocol rules

5. Clear the original account state

Known protocol-level dependencies and risks

• Oracle dependence: incorrect or stale prices/rates can distort valuation, margin checks, settlement, and liquidation triggers. Mitigation is via oracle guards (staleness/validity/deviation thresholds) and conservative parameterization.

• Complex state interactions: concentrated liquidity and multi-leg positions increase state-space complexity. Mitigation is strict call permissions (only VAMMManager can mutate positions) and margin checks on every state transition.

• Parameter risk: worst-case factors and discount factors are powerful levers. Misconfiguration can make the system overly strict or under-protective. Mitigation is governance discipline and bounded parameter ranges in code (where applicable).

Security contact

For contract-level security issues, use the security contact channel provided by the team.