Where your incidents go

Evidesa sends an incident when a saved observation records a change worth explaining. This page decides where yours arrive: your own endpoint, signed so you can prove the message came from here, or a Discord channel. Every delivery carries the same evidence the Telegram message carries — what changed, the base rate, what did not move, what could not be read, and what is not evaluated at all.

WholeThe instrument's 4 stations: register → challenge → verify → deliver.DrawnThe widened seam after register is the verification gap — nothing crosses it until the endpoint echoes the challenge.Not drawnNo destination — yours or anyone's — is drawn here. Fixture carries the instrument's shape, never a datum.

A destination belongs to an account, not to a browser tab. Sign in with your wallet on the account page — there is no password, and signing proves the address without moving anything.

What a destination receives, and when

Only the mints you keep. An incident reaches your destination when the mint is on your watchlist and a saved observation records a notifiable change. There is no broadcast and no feed: a token you have not kept is a token you hear nothing about.

Signed, so you can refuse a forgery. Each webhook delivery carries x-evidesa-signature, an HMAC-SHA256 over the version, the timestamp and the exact body sent, using a secret derived per destination. Reject anything that does not verify, and anything whose timestamp is older than five minutes.

Silence has three causes. Nothing changed, nothing was re-observed, or the change was not of a notifiable kind. A quiet endpoint is not evidence that a token is behaving, and no delivery here is a recommendation to do anything.

Failures are counted, then stated. An endpoint that fails repeatedly is disabled with the reason shown above, rather than retried into your rate limiter forever. Every attempt — delivered or not — is recorded in the delivery ledger behind the evidence watch.