Proof is the
only key.

Reporting a vulnerability

Report privately — never in a public issue. Use GitHub private advisories or email hello@keenetix.xyz.

Include where the issue is, how to reproduce it, and what an attacker gains. We aim to acknowledge within three business days and to share a remediation timeline within ten. We credit reporters in the advisory unless you prefer to stay anonymous.

What we treat as critical

Keenetix releases capital against cryptographic proof, so findings in these areas are triaged first:

• Scope bypass — an API key acting beyond the permissions it was granted.
• Tenancy break — any query reaching rows outside the caller’s workspace.
• Premature settlement — a path reaching a settled state without valid verification.
• Receipt forgery — a forged, replayed, or unrelated transaction accepted as confirmation.
• Signature bypass — defeating Ed25519 attestation checks or webhook HMAC comparison.
• Session compromise — fixation, cookie scope, or hash bypass in authentication.

How credentials are stored

Raw API keys and session tokens are never persisted. We store SHA-256 hashes and match against them, so a database dump alone yields no usable credential. A key is displayed once at creation and cannot be recovered afterwards — only a short prefix is retained so the dashboard can tell keys apart.

Passwords are hashed. Revoked keys are rejected at authentication, before any scope or rate-limit evaluation.

Workspace isolation

The workspace is the tenancy boundary. Every request resolves to a workspace before it touches data — from the session cookie for browser traffic, or from the API key for machine traffic — and every query is filtered by that identifier. A workspace identifier supplied by a client is never trusted.

API surface controls

Each /api/v1 request passes through the same sequence: bearer key lookup by hash, revocation check, scope enforcement, per-key rate limiting on a fixed sixty-second window, and an audit log entry recording method, path, and forwarded IP.

Because auditing happens inside the authentication layer rather than in individual handlers, a new endpoint is audited by construction.

Verification integrity

Three independent sources can attest that a condition was met, each with its own trust mechanism: verifier attestations are checked with Ed25519 against a registered public key; oracle submissions require a scoped key and recorded evidence; GitHub CI results are validated by HMAC-SHA256 using a constant-time comparison.

A passing signal can only advance a commitment that is funded or executing. A late or duplicated proof cannot rewind a commitment that has already settled.

Settlement safeguards

Keenetix never holds keys and never signs a transaction. Wallets sign in your browser; the server verifies the result on chain.

Receipts are validated for shape before any network call — EVM receipts require a non-zero chain id, a 32-byte transaction hash, and a 20-byte escrow address; Solana receipts require a base58 signature and escrow token account within expected length bounds. Confirmation is a two-step handshake: a receipt is submitted, then read back from the chain before the settlement is marked complete. Value is only released for commitments already in a verified state.

Out of scope

Findings against marketing pages with no data impact, missing hardening headers without a demonstrated exploit, rate-limit tuning opinions, automated scanner output without a working proof of concept, and social engineering are out of scope.

Safe harbour

If you make a good-faith effort to comply with this policy, we will not pursue legal action against you for your research. Please avoid privacy violations, service degradation, and any destruction or exfiltration of data that is not yours. Give us reasonable time to remediate before public disclosure.

Supported versions

The main branch is the only supported version. Fixes ship forward; there are no backports.