Trust ladder
The trust ladder is the mechanism that turns repeat-submitter friction into fast-path throughput. Once a pubkey has been approved enough times on a tracking page, future submissions from that pubkey auto-approve instead of queuing for manual review. This page explains how promotions happen and the manual overrides available to owners.
Applies only when the page's verification policy is set to trust_ladder (the default). In strict mode, the ladder is inert — manual review is always required. In auto mode, the ladder is skipped entirely.
Promotion
We track how many approvals a pubkey has earned on a given tracking page. When the owner approves a submission, that count goes up. Once it meets the page's owner-configured threshold, the pubkey is promoted to trusted. The next time they submit, the submission auto-approves without owner intervention.
The promotion is silent — the visitor sees no badge, no notification.
Auto-approval on future submissions
Once trusted, a pubkey's submissions still run through all the usual checks — signature, nonce, CA gate, duplicate, queue cap. Trust only changes the final step: if the policy would have written pending, it writes auto_approved instead.
If any earlier check fails (e.g. the CA balance has dropped below the threshold), the auto-approval doesn't happen — trust doesn't bypass the holding gate.
Manual trust and revoke
Owners can override the ladder at any time in the dashboard under Settings → Embed API → Trusted submitters:
| Action | Effect |
|---|---|
| Manually trust a pubkey | Promotes the pubkey immediately, regardless of approval count. The next submission auto-approves. |
| Revoke trust | Sends future submissions back to manual review, even if the pubkey is still over threshold. |
Revocation is a soft stop: the approval count is preserved, so re-trusting later puts the pubkey back in a promoted state. Re-trust manually; there's no automatic "earn it back" path once revoked.
Visibility
The ladder state is not exposed via the public API. It's only visible to the tracking page owner in the dashboard. Visitors see only their own submission statuses via GET /session/submissions.
This is intentional: publishing which wallets are trusted would give sophisticated spammers a target list to spoof.
Edge cases
Submitter pubkey vs. submitted wallet
The pubkey that earns ladder credit is the one that signed the submission — the submitter. A user can submit multiple different wallets, and each approved submission advances their submitter pubkey's count. The wallet being submitted is irrelevant to ladder state.
In practice the submitter and the submitted wallet are usually the same pubkey (the visitor proves they own the wallet they're submitting). But because the submitter pubkey is tracked separately, the ladder works even when a user submits multiple addresses they control from the same signing wallet.
Cross-page isolation
Trust is scoped per tracking page. A pubkey trusted on page A is not trusted on page B. Owners should not assume reputation transfers.
Related
- Verification policy — how the ladder slots into the broader approval flow.
- POST /submissions — the endpoint that reads trust state.