- Communication between the Coordinator and the Model Runner is encrypted
- Requests genuinely come from the expected Coordinator
- The Model Runner is controlled by the on-chain identity (wallet) it claims
How it works
Certificate issuance
The Crunch Protocol issues TLS certificates through a private certificate service, signed by the
protocol’s Certificate Authority (CA).
Mutual TLS (mTLS)
Both the Coordinator and the Model Runner present valid certificates when connecting. The
connection is encrypted end-to-end, and both endpoints are authenticated.
Wallet binding
A wallet signature binds the TLS public key to an on-chain identity. A rotatable hotkey
allows the owner to invalidate old bindings if a key is compromised.
Authentication message
Each side generates atls_auth_message containing:
- The TLS public key (
cert_pub) - A hotkey value
- A wallet signature over the message
| Header | Description |
|---|---|
x-auth-message | The signed authentication message |
x-auth-signature | Wallet signature over the message |
x-auth-wallet-pubkey | Wallet public key (debug only — chain is the source of truth) |
Verification checks
When a request arrives, the receiver validates three things before accepting it:- Wallet signature — verify that
x-auth-signaturecorrectly signsx-auth-message, using the wallet public key fetched from the blockchain - TLS certificate binding — confirm that the TLS public key in
x-auth-messagematches the certificate used in the active mTLS connection - Hotkey validity — confirm that the hotkey in
x-auth-messagematches the hotkey currently registered on-chain
Next: Crunch lifecycle
Understand the full lifecycle of a Crunch — from creation through payout to closure.