On-Chain Implementation & Monitoring
1. On-Chain vs. Off-Chain Split
The smart trigger system is primarily an off-chain component because it requires timers, time-of-day awareness, and holiday calendar lookups. The trigger decision and Phase 2 execution command are off-chain. The Reserve Pool balance reads and the final external settlement are on-chain.
| Component | Location | Rationale |
|---|---|---|
| Threshold Configuration | On-chain (configurable parameters) | Auditable; governance-controlled via admin function |
| Cooldown Timer | Off-chain (Backend Scheduler) | Timer management is not gas-efficient on-chain |
| Time-of-Day Profile | Off-chain (Backend Config) | Requires clock and calendar; off-chain is appropriate |
| Holiday Calendar | Off-chain (Backend Config) | Updated quarterly by Ops; referenced by scheduler |
| Deviation Check | Off-chain (reads on-chain balance) | Triggered after each Phase 1 settlement; reads Reserve Pool balance from chain |
| Phase 2 Execution | Off-chain Bot → On-chain settlement | RFQ/OTC execution is off-chain; settlement on-chain (unchanged from current) |
| Trigger Event Logging | On-chain (Smart Contract) | Audit trail for every trigger decision; emits events |
2. Smart Contract Functions
| Function | Parameters | Description |
|---|---|---|
updateRebalanceConfig() | pool, corridor, softThreshold, hardThreshold, emergencyThreshold, residualFactor | Admin-only; updates threshold configuration. Emits RebalanceConfigUpdated event. |
logTriggerDecision() | pool, corridor, deviation, tier, action, cooldownRemaining | Called by off-chain bot after each trigger evaluation. Emits RebalanceTriggerEvaluated event for audit trail. |
executeRebalance() | pool, corridor, amount, direction, executionRate | Executes the Phase 2 settlement on-chain. Emits RebalanceExecuted event. (Modified from current to accept amount based on Target Residual calculation.) |
3. On-Chain Events
| Event | Data Captured | Purpose |
|---|---|---|
RebalanceTriggerEvaluated | pool, corridor, deviation, tier (IDLE|SOFT|HARD|EMERGENCY), action (NONE|COOLDOWN_START|COOLDOWN_SAVED|FIRE|EMERGENCY_FIRE), timestamp | Full audit trail of every trigger decision; enables analysis of cooldown effectiveness |
CooldownSaved | pool, corridor, peakDeviation, deviationAtCancel, cooldownDuration, savedAmount | Tracks every instance where the cooldown prevented an unnecessary Phase 2; key metric for COGS savings |
RebalanceExecuted | pool, corridor, amount, direction, targetResidual, executionRate, preBalance, postBalance | Audit trail for every Phase 2 execution (modified to include targetResidual) |
RebalanceConfigUpdated | pool, corridor, old/new thresholds, old/new residualFactor, updatedBy | Governance audit trail for parameter changes |
4. Monitoring & Analytics
4.1 Key Metrics
| Metric | Calculation | Target / Alert Threshold |
|---|---|---|
| Cooldown Save Rate | Cooldown cancellations (saved) / Total cooldowns started | Target > 40% for USD-IDR; higher = cooldown is working; lower = cooldown too long or flow too one-directional |
| COGS Savings | Sum of savedAmount from CooldownSaved events × Avg execution cost bps | Track weekly; report to Risk Committee |
| Phase 2 Frequency | Number of Phase 2 executions per day per pool | Compare against pre-smart-trigger baseline; target 30–50% reduction |
| Avg Rebalance Size | Average amount per Phase 2 execution | Should be smaller than pre-smart-trigger baseline due to partial offset during cooldown |
| Cooldown-to-Hard Escalation Rate | Times position moved from Soft to Hard during cooldown / Total cooldowns | Target < 15%; if high, Soft Threshold is too close to Hard or cooldown too long |
| Emergency Override Rate | Emergency triggers / Total trigger evaluations | Target < 5%; if high, thresholds need recalibration or market conditions have changed |
| Time-of-Day Accuracy | Cooldown Save Rate during peak hours vs off-peak hours | Peak save rate should be meaningfully higher than off-peak; if not, time profiles need tuning |
4.2 Alerting Tiers
| Alert Level | Condition | Action | Channel |
|---|---|---|---|
| INFO | Cooldown saved (position dropped below Soft) | Log CooldownSaved event; Ops review weekly | Dashboard log |
| INFO | Phase 2 fired from Soft Zone (cooldown expired) | Log trigger; review if cooldown was too short | Dashboard log |
| WARNING | Cooldown-to-Hard escalation occurred | Review Soft/Hard gap and cooldown duration for the corridor | Slack + Dashboard |
| WARNING | Cooldown Save Rate < 20% for 7 consecutive days | Flow pattern may have changed; review time-of-day profiles and cooldown duration | Slack + Dashboard |
| CRITICAL | Emergency Override Rate > 10% over 7 days | Thresholds likely too high for current volume; immediate Risk Committee review | PagerDuty + Slack |
5. Parameter Governance & Review Cadence
5.1 Review Schedule
| Parameter | Review Cadence | Review Criteria |
|---|---|---|
| Soft / Hard / Emergency Thresholds | Monthly | Are thresholds correctly calibrated for current daily volume? Review Phase 2 frequency, Cooldown Save Rate, and escalation rate. |
| Cooldown Duration (base) | Monthly | Is the cooldown long enough to capture reverse flow? Compare peak vs off-peak save rates. |
| Time-of-Day Profiles | Monthly (first 3 months), then Quarterly | Do peak bilateral hours match observed flow? Compare actual flow patterns against configured profiles. |
| Residual Factor | Quarterly | Is the buffer reducing Phase 2 re-trigger frequency? Review avg time between consecutive Phase 2 fires on same pool. |
| Holiday Calendar | Quarterly | Updated with upcoming quarter's gazetted holidays for ID, SG, MY. |
5.2 Change Authority
All parameter changes follow the standard governance process:
- Written justification referencing specific metrics or incidents.
- Approval from Risk Committee + Engineering.
- Execution via
updateRebalanceConfig(), emittingRebalanceConfigUpdatedevent. - Post-change monitoring for 48 hours with automated rollback if Cooldown-to-Hard Escalation Rate exceeds 25% or Emergency Override Rate exceeds 15%.