Responsible disclosure

If you have found something, please tell us before you tell anyone else.

Contact	security@co-relayer.com
Machine-readable	/.well-known/security.txt
Languages	English, German

What to send

Enough for us to reproduce it:

• what you did, step by step;
• what happened;
• what you expected instead;
• where — mainnet, devnet, which host, which route or which contract call;
• when, in UTC, and any CoRelayer-Request-Id you saw. Every response carries one, and it is the fastest way for us to find your request in the logs.

A proof of concept is welcome. A video without the steps written down is not, because we cannot run a video.

What we will do

1. Acknowledge that we received it, to a human, not an autoresponder.
2. Tell you whether we could reproduce it, and what we think the impact is — including if we disagree with your assessment, and why.
3. Keep you updated while we fix it, rather than going quiet.
4. Credit you when it is fixed, if you want to be credited. Some people do not; that is fine.

If a finding is serious, we will pause the affected scope rather than leave it running while we think. The contract has five independent pause scopes precisely so that this does not have to be all-or-nothing. (The contract)

What we ask

• Do not test against accounts that are not yours. Use devnet: it runs the same code as mainnet, with the same rules.
• Do not use a finding to move funds, yours or anyone else's.
• Do not run load or denial-of-service tests against a live environment. If you want to test capacity behaviour, ask us and we will arrange it.
• Do not publish before we have fixed it, or before we have told you we cannot. If we go quiet on you, that is our failure and you owe us nothing further.

What is in scope

The CoRelayer smart contract	Anything that lets a caller do something the role matrix says they cannot
The API	Authentication and authorisation flaws, anything that relays a transaction that should have been refused, anything that reveals another account's private data
The relay guarantees	A way to make one user action produce two executable transactions; an error returned after the commit point; a way to alter a transaction after signing
The SDK	A way to make the client sign twice, or to make it re-sign on a retry
The sites	Injection, anything that renders attacker-controlled bytes as markup

What is out of scope

	Why
Missing headers or a low grade from a scanner, with no exploit	We would rather fix a real bug
Reports from an automated scan with no reproduction	Same
Social engineering of us or our users
Physical attacks
Anything requiring a compromised user device	The threat model assumes your device is yours
Denial of service by volume	Already bounded by rate classes; tell us if you found a way around them, which is very much in scope

The bits we already know about

Listing known residuals is not a way of pre-emptively rejecting reports — a concrete exploit of any of them is a valid finding. These are documented so you do not spend time telling us something we have written down ourselves:

• the owner key is a single key with no multisig;
• a compromised signing host exposes the active relayer floats;
• a user-signed transaction we never co-signed may appear in an MCP host's logs; it is inert, but it is there.

All three, with their bounds: The trust model · Key handling.

No bounty yet

There is no bug bounty programme, and we will not imply one. If you report something serious we will discuss a reward with you directly; we would rather make a specific offer to a specific person than advertise a table we have not funded.

Code and specification findings

On devnet only

CoRelayer runs on devnet only; nothing is deployed on mainnet yet.

Findings in the code, the contract or the specification are entirely welcome, and are often the most useful kind: a bug found before it runs costs nobody anything.