Operating principles
- Do not request or accept private keys, seed phrases, or unilateral protocol authority.
- Use least-privilege, read-only access before any write capability.
- Keep client, protocol, wallet, environment, and provider boundaries explicit.
- Record material alerts, acknowledgements, changes, and decisions.
- Separate verified facts from hypotheses during incident work.
- Use signed scopes and named human authority for production-impacting activity.
Public-site controls
The launch site uses TLS, restrictive browser-security headers, same-origin scripts and styles, CSRF protection, honeypot and rate-limit controls, parameterized database queries, an access-controlled operator console, and private storage outside the public web root.
Responsible disclosure
To report a vulnerability in this site or an Onchain On-Call-owned component, use the support form and choose Security disclosure. Start the message with SECURITY DISCLOSURE. Provide a safe description, affected URL or component, and contact method. Do not include customer data, private keys, destructive proof, or details belonging to a third-party protocol.
The public form and mailbox are routing channels, not encrypted disclosure vaults and not a promise of confidentiality or a bounty. We will establish a narrower channel when a report requires sensitive supporting detail.
We will distinguish good-faith, non-destructive research from abuse. This process does not authorize testing third-party infrastructure, social engineering, denial of service, data exfiltration, or access beyond what is necessary to demonstrate the issue safely.
Client incidents
Do not submit active exploit details through the public form. Existing clients must use the secure channels and authority model defined in their signed engagement. Non-clients should use established emergency-response resources appropriate to their ecosystem.