Webhooks

Threshold-crossing callbacks, and the deliberate reason there is no downgrade feed.

Argued in full in the whitepaper at §11, surfaces 18, 34.

subscribe.sh

curl -s "$API/webhooks" \
  -H "Authorization: Bearer $CLEATON_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your.app/hooks/cleaton",
    "pools": ["0xA0b8...", "0x4200..."],
    "when": { "horizonBelow": 14, "confidenceBelow": 6000 }
  }'

Thresholds are yours. Cleaton does not decide what counts as a worrying horizon, because that depends entirely on the lock period of whatever is reading it — fourteen days is alarming for a thirty-day strategy and irrelevant for a daily one.

Events#

Event	Fires when
`horizon.crossed`	A fresh attestation puts the horizon below your threshold
`confidence.crossed`	Confidence drops below your threshold
`flag.raised`	An attestation is published with `OUT_OF_SUPPORT`, `LOW_DATA` or `REGIME_SHIFT`
`attestation.revoked`	An attestation was withdrawn early — recorded permanently and counted against the accuracy record

Every payload carries the full signed attestation, so the receiver can verify it rather than trusting the callback. Treat the webhook as a nudge to read, not as an authenticated fact.

Why there is no downgrade feed#

This does not solve reflexivity — nothing does. It reduces the most tradeable form of it. Cleaton also commits to publishing an estimate of the induced component of outflow, measured against matched unattested controls, even though it undercuts headline accuracy.

Subscribe#

Events#

Why there is no downgrade feed#