Proof Holdings vs Slack Approval Bots

A Slack approval bot looks like a weekend project, and the happy path is. You register a Slack app, request `chat:write`, install via OAuth, post an interactive message with Block Kit Approve/Deny buttons, and receive a `block_actions` payload when someone clicks.

The parts that don't fit in a weekend are the ones that matter: you must stand up a public HTTPS endpoint, verify Slack's request signature on every payload (HMAC over `v0:timestamp:body`, reject anything older than 5 minutes to stop replays, constant-time compare), acknowledge within 3 seconds, and persist every decision yourself — Slack hands you no durable record. Then you own it forever: rotate the signing secret, track Slack's deprecations, keep the endpoint up.

Here's the subtle part. That `block_actions` payload is authenticated to you — you verified it with a signing secret only you and Slack share. But that's exactly why it isn't *proof*: no outside party can verify it, and you could have forged an identical one. The record ends up as a row in your own database that you wrote.

Proof Holdings issues an ES256 proof token signed with a key whose public half is published. The human's approve/deny is cryptographically bound to the request and verifiable offline by anyone — an auditor, a partner, a counterparty — without trusting your database or calling Proof. That's the difference between *logging a click* and *holding a signature*. And Proof delivers to Telegram or WhatsApp, so the approver needs no Slack seat and no app install.