Sent
Certified Mail defined the semantics. This is what it looks like when you press send.
Every email is a DKIM-signed, timestamped, certified edge on a temporal graph. Proof of Trust made the case. Envelopay attaches a payment proof to that edge.
Split the bill
Two friends. Dinner’s over. Alex owes Jordan $30.
Alex already knows Jordan’s wallet — they’ve split bills before. No negotiation needed. Alex sends $30 USDC on Base, then emails the proof:
From: alex@hey.com
To: jordan@gmail.com
Subject: PAY | Dinner split
X-Envelopay-Type: PAY
DKIM-Signature: v=1; a=rsa-sha256; d=hey.com; ...
{"v":"0.1.0",
"type":"pay",
"note":"Dinner — my half",
"amount":"30000000",
"token":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"chain":"base",
"proof":{"tx":"0x7a3f..."}}One email. The money moved before the message was composed. Jordan’s inbox holds a DKIM-signed receipt — hey.com certified the edge, the mail server timestamped it. Done.
That’s the simplest envelopay transaction. No task, no negotiation, no reply expected. Just money and a receipt.
Order work
Axiomatic needs a code review for PR #417. It picks blader from the trust topology — a year of clean settlements and five endorsements. Discovery is an application concern; the protocol doesn’t know or care how axiomatic chose blader.
Axiomatic doesn’t know blader’s wallet, so it sends a WHICH — subject line only, empty body. Blader replies with METHODS: Solana, USDC, here’s the wallet and the price.
METHODS reply
Subject: METHODS | Solana or Base
X-Envelopay-Type: METHODS
DKIM-Signature: v=1; a=rsa-sha256; d=agentmail.to; ...
{"v":"0.1.0",
"type":"methods",
"note":"Solana preferred, Base also accepted",
"rails":[{"chain":"solana",
"token":"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
"wallet":"6dL6n77jJFWq4bu3cQp57H8rMUPEXu7uYN1XApPxpUif",
"price":"500000000"},
{"chain":"base",
"token":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"wallet":"0x1a2B3c4D5e6F7a8B9c0D1e2F3a4B5c6D7e8F9a0B",
"price":"500000"}]}Axiomatic sends the task.
ORDER
From: axiomatic@agentmail.to
To: blader@agentmail.to
Subject: ORDER | Review PR #417
X-Envelopay-Type: ORDER
DKIM-Signature: v=1; a=rsa-sha256; d=agentmail.to; ...
{"v":"0.1.0",
"type":"order",
"id":"ord_4vJ9",
"note":"Review PR #417, focus on auth boundaries",
"task":{"description":"Review PR #417",
"repo":"github.com/axiomatic/widget",
"scope":"security"}}ORDER is just a task request — no payment fields. The worker decides what to charge. Blader replies with an INVOICE for $0.50 USDC on Solana, axiomatic sends PAY with the proof, and then blader starts work.
FULFILL
Blader does the review and replies. The In-Reply-To header threads it to the ORDER — same as any email reply.
From: blader@agentmail.to
To: axiomatic@agentmail.to
Subject: FULFILL | Approved with 2 comments
X-Envelopay-Type: FULFILL
DKIM-Signature: v=1; a=rsa-sha256; d=agentmail.to; ...
{"v":"0.1.0",
"type":"fulfill",
"id":"ful_7g8h",
"order_ref":"ord_4vJ9",
"note":"Approved with 2 comments, one medium severity",
"result":{"summary":"Approved with 2 comments",
"findings":[{"file":"handler.go","line":47,
"severity":"medium",
"finding":"Session token not validated before use"}]}}Four emails: ORDER, INVOICE, PAY, FULFILL. One on-chain transfer. Both inboxes hold DKIM-signed records of payment and work. The chain is the settlement source of truth. The thread is the evidence.
What about INVOICE?
Blader did extra work and wants to bill axiomatic:
Subject: INVOICE | Additional auth hardening
X-Envelopay-Type: INVOICE
DKIM-Signature: v=1; a=rsa-sha256; d=agentmail.to; ...
{"v":"0.1.0",
"type":"invoice",
"note":"Auth hardening beyond original scope",
"amount":"1000000",
"token":"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
"chain":"solana",
"wallet":"6dL6n77jJFWq4bu3cQp57H8rMUPEXu7uYN1XApPxpUif"}Axiomatic decides whether to pay. If it does, it sends a PAY with the proof. If it doesn’t, silence. No dispute state.
What the protocol doesn’t do
The protocol carries a proof and a message type. It deliberately stops there. Discovery, pricing, trust, escrow, disputes — those are application concerns that change faster than any wire format should.
| Protocol | Application |
|---|---|
| Message types and headers | Discovery and ranking |
| Proof payload | Pricing and negotiation |
| Email threading | Retries and timeouts |
| DKIM verification | Reputation and trust |
When things go wrong
Not every proof verifies. The receiver checks before doing work:
| Failure | What happens |
|---|---|
| Tx doesn’t exist on-chain | `OOPS |
| Amount doesn’t match | `OOPS |
| DKIM fails | `OOPS |
The harder failure is valid payment, no delivery. The protocol doesn’t prevent that — no protocol can force an agent to do work. What it does: every ORDER without a FULFILL is a DKIM-signed, timestamped record of non-delivery. Axiomatic stops emailing. The trust topology thins. Fraud detection is an application concern, but the evidence is in the thread.
Try it (humans)
The repo has a working demo. SOL instead of USDC, a toy task instead of a real code review. Same message types, same threading.
Step 1. Ask axiomatic what it accepts.
You’ll get back a METHODS reply with the wallet address and accepted rails.
Step 2. Send an ORDER — just the task, no payment yet:
Axiomatic replies with an INVOICE — the price and where to send payment.
Step 3. Send any amount of SOL to the wallet from the INVOICE, then send the tx hash as a PAY:
Axiomatic verifies the tx on-chain and replies with FULFILL.
Step 4. Get your SOL back. Paste your wallet address to send an INVOICE:
Axiomatic sends the SOL back with a FULFILL containing the refund tx hash.
Try it (agents)
Give your agent this prompt. It needs three capabilities: web fetch, email, and a Solana wallet.
Read https://june.kim/envelopay-spec.md and follow the protocol to
send 0.0001 SOL to axiomatic, then ask for it back. My
wallet is <YOUR_WALLET_ADDRESS>.That’s it. If the agent can read a web page, send email, and sign a transaction, it has everything it needs.
Sent.
Next: Open for Business | All Envelopay posts