On-Chain Implementation & Monitoring

1. Smart Contract Functions

The following functions must be implemented or extended in the Kaia smart contracts to support the inventory skew system:

Function	Parameters	Description
getInventoryRatio()	corridor, stablecoin	Returns real-time IR for the specified side of a corridor
calculateSkewOffset()	corridor, oracleMid	Returns skew offset in bps, incorporating dead zone, k, state cap, VaR amplifier
getAdjustedMid()	corridor	Returns Oracle MID ± skew offset; this is what the spread is applied to
updateSkewConfig()	corridor, k, maxSkew, deadZone	Admin-only; updates corridor parameters. Emits SkewConfigUpdated event.

2. On-Chain Events

The following events must be emitted for audit trail and analytics:

Event	Data Captured	Purpose
SkewApplied	corridor, IR, skewBps, adjustedMid, oracleMid, stateAtExecution, varUtilisation	Full audit trail per quote; enables post-trade skew effectiveness analysis
SkewConfigUpdated	corridor, old_k, new_k, old_maxSkew, new_maxSkew, old_deadZone, new_deadZone, updatedBy	Tracks all parameter changes; governance and compliance
SkewEmergencyAmplified	corridor, varUtilisation, amplifier, effectiveK	Signals VaR-triggered amplification; alerts Ops dashboard

3. Gas Optimisation Notes (Kaia-Specific)

The inventory skew calculation is computationally lightweight (one division, one multiplication, one clamp). On Kaia, this adds approximately 3,000–5,000 gas to each quote request. However, the real-time Active Pool balance read requires a storage SLOAD, which on Kaia costs approximately 2,100 gas per slot.

To minimise gas overhead, the recommended implementation caches the inventory ratio and skew offset in a transient storage slot that is updated atomically during each swap execution. This avoids redundant SLOADs when multiple quotes are requested in rapid succession within the same block.

4. Monitoring, Analytics & Ops Dashboard

4.1 Key Metrics

The following metrics must be tracked in the Ops dashboard to monitor skew system effectiveness:

Metric	Calculation	Target / Alert Threshold
Skew Effectiveness Ratio	Volume attracted in skew direction / Total volume for corridor	Target > 55%; Alert if < 45% for 24h
Avg Skew Magnitude	Rolling 1h average of |InventorySkew_bps|	Alert if > 75% of MaxSkew for 4h
Time at Max Skew	Cumulative minutes per day at |Skew| = MaxSkew	Alert if > 60 min/day
Skew-Avoided Rebalancing	Estimated external rebalancing volume avoided due to skew-attracted offsetting flow	Report weekly; target > $50K/week for USD-IDR
IR Distribution	Histogram of IR values per corridor per day	Healthy: 80% of time within dead zone or mild range

4.2 Alerting Tiers

Alert Level	Condition	Action	Channel
INFO	Skew > 50% of MaxSkew for > 1h	Log only; Ops review next business day	Dashboard log
WARNING	Skew at MaxSkew for > 30 min	Trigger Phase 1 internal rebalancing evaluation	Slack + Dashboard
CRITICAL	Skew at MaxSkew + VaR > 80%	Immediate Ops escalation; Emergency RFQ per Reserve Pool VaR	PagerDuty + Slack

5. Parameter Governance & Review Cadence

5.1 Review Schedule

Parameter	Review Cadence	Review Criteria
k (sensitivity)	Monthly	Is skew attracting sufficient offsetting flow? Compare Skew Effectiveness Ratio against target.
MaxSkew_bps	Monthly	Is the cap being hit too frequently? If Time at Max Skew is excessive, consider increasing cap or triggering rebalancing sooner.
Dead Zone	Quarterly	Is the dead zone correctly sized for the corridor's typical flow pattern? Review IR Distribution histogram.
State Cap Modifiers	Quarterly	Are elevated state skew caps providing sufficient correction without excessive LP exposure?
VaR Amplifiers	Quarterly	Is the amplification curve correctly reducing Emergency RFQ frequency?

5.2 Change Authority

All parameter changes require:

1. Written justification referencing the specific metric or incident that triggered the review.
2. Approval from at least one member of the Risk Committee and one member of the Engineering team.
3. Execution via the updateSkewConfig() admin function, which emits the SkewConfigUpdated on-chain event.
4. Post-change monitoring for 24 hours with automated rollback capability if Skew Effectiveness Ratio drops below 40%.