Skip to main content

Elastic Security

Traditional blockchains enforce a uniform security model — a $5 transaction pays for the same level of security as a $5 billion transaction. YNP addresses this with Value-Proportional Security: the cluster size protecting an account scales with the economic value it holds.

Value-at-Risk Calculation

Every account has a Total Value (V_A) denominated in YELLOW:

V_A = sum(Balance_i × Price_i)  for each asset i
  • Prices are derived internally from the Native Liquidity Pools using the manipulation-resistant P_EMA (exponential moving average), not spot prices.
  • Recalculation occurs at the start of every transaction or epoch.

Dynamic Quorum Extension (DQE)

The required signing cluster size k for an account is computed dynamically:

k_required = min(256, max(k_min, (V_A × SafetyMultiplier) / AvgCollateral))
ParameterValueDescription
k_min3Minimum viable BLS threshold cluster (2-of-3 quorum)
SafetyMultiplier1.2Cost-of-corruption must be 1.2x the value-at-risk
AvgCollateraldynamicNetwork-wide rolling average of all registered NodeID collaterals, recalculated every epoch from Registry contract events

Dual-Layer Sizing

The DQE formula sizes two parameters independently:

  • k is sized for performance — consensus latency scales with cluster size.
  • r (replication set) is sized for security — corruption cost scales with the number of independent verifiers.

The constraint the protocol enforces is:

CostOfCorruption(r) > V_A

where the cost of corruption is measured against the replication set, not the signing cluster. A successful theft requires either bribing C_sign without detection (impossible if C_watch is honest) or bribing floor(2r/3) + 1 of C_watch to suppress the Dispute Certificate.

Truncation

When the calculated k_required exceeds 256, the protocol truncates the signing cluster to the 256 closest NodeIDs by XOR distance. The replication set r is truncated independently at min(256, k × f_r).

Security Ceiling (Per-Certificate Value Cap)

When both k and r reach the 256-node cap, the dual-layer model degenerates: C_sign = C_watch, eliminating independent watchers. To restore the security constraint, the protocol enforces a per-certificate value cap:

SecurityCeiling = CostOfCorruption(r_max) / SafetyMultiplier
= (floor(2 × 256 / 3) + 1) × AvgCollateral / 1.2
= 171 × AvgCollateral / 1.2

Rule: No single certificate (Credit, Swap, Escrow) SHALL carry a YELLOW-equivalent value exceeding the Security Ceiling. The YELLOW-equivalent value is:

V_cert = Amount × P_EMA(AssetYELLOW)

When It Binds

For accounts where V_A < SecurityCeiling, the cap does not bind — DQE scales k and r normally. The ceiling activates only when V_A exceeds what the maximum cluster can secure (i.e., when DQE would require k > 256).

Consequence for Large Accounts

A user withdrawing or transferring a balance exceeding the Security Ceiling MUST split the operation into multiple certificates, each individually within the cap. Each withdrawal carries its own challenge period; each transfer its own CreditOp.

Velocity Constraint

For any account, the cumulative YELLOW-equivalent value of all certificates produced within a single challenge period MUST NOT exceed the Security Ceiling. This prevents a corrupted cluster from producing multiple certificates in rapid succession to circumvent the per-certificate cap.

Enforcement (Defense in Depth)

The Security Ceiling is enforced at three independent layers:

  1. Off-chain — Signing ceremony: C_sign nodes MUST refuse to sign any certificate whose V_cert exceeds the ceiling. A certificate requires floor(2k/3) + 1 honest signatures, so a minority of corrupt nodes cannot produce an oversized certificate.

  2. Cross-cluster — Recipient validation: C_Recipient MUST reject any incoming CreditOp whose V_cert exceeds the ceiling, providing independent enforcement even if the sender's cluster is fully compromised.

  3. On-chain — Custody backstop: The Custody contract maintains a governance-updatable maxWithdrawalAmount[asset] mapping. startWithdrawal MUST revert if amount > maxWithdrawalAmount[asset]. The per-asset cap is derived from SecurityCeiling / P_EMA(Asset) and updated periodically by governance or an automated keeper.

Collateral Mechanics

Collateral is posted in YELLOW tokens to the Registry contract at registration time and mirrored off-chain in Balances[1040].

Minimum Collateral (Node Slot Price)

The minimum collateral per NodeID follows a continuous curve:

P_n = P_base × (P_target / P_base) ^ (N_t / N_max)
ParameterValueDescription
P_base10,000 YELLOWMinimum at genesis
P_target125,000 YELLOWMinimum at full network capacity
N_tdynamicCurrent active NodeIDs
N_max65,536Maximum NodeIDs

As the network grows from genesis to saturation, the required collateral rises from 10,000 to 125,000 YELLOW.

Auto-Compounding

100% of transaction fees and emission incentive distributions are auto-compounded into Balances[1040], allowing nodes to organically grow their stake without manual top-ups. This ensures existing nodes keep pace with the rising slot price as the network grows.

Excess Withdrawal

Collateral above P_n × buffer MAY be withdrawn to the operator's available balance via the standard Escrow Certificate flow.

The Escrow Certificate Gate

All collateral — whether from a voluntary departure or a slashed operator — remains in the Custody contract after eviction. There is no on-chain function that automatically returns or seizes collateral. Instead, the standard Escrow Certificate withdrawal flow is the single point of control for all collateral movement:

  • Honest operator (voluntary departure): After cooldown + eviction, the operator requests an Escrow Certificate for their collateral. The network produces it, and the operator withdraws through the standard challenge-period flow.
  • Slashed operator (dispute): After a successful dispute, the network marks the corrupt signers as slashed and refuses to produce an Escrow Certificate for their collateral. Their stake is effectively forfeit — no on-chain slashing function is needed because the same certificate gate that protects all withdrawals also enforces slashing.

Unbonding Period

Voluntary withdrawal of collateral requires the full cooldown (1 hour) plus eviction window (7 days) to elapse after unregistration. During this entire period the NodeID remains in the Kademlia tree for verification consistency.