The Lab · Sign Here, Broadcast There · v1 — October 18, 2026
Live · Oct 18, 2026
Sign here. Broadcast there.
How a CLAM transaction gets from a machine that holds the key and never goes online to the public chain, told with one real transaction you can check yourself and the three things that went wrong on the way. This page only teaches. It has no key field, no address field and nothing that sends.
What offline signing is
A transaction is a short run of bytes that says which coins it spends and where they go. Signing adds proof that the owner of those coins approved exactly those bytes. Once it is signed, nobody can change a single byte without breaking the signature.
That splits the job in two. Signing needs the private key, so it happens on a machine that stays offline. Broadcasting only means handing the finished bytes to the network, so any connection will do, even one you don't trust. The machine that carries the bytes never sees the key, and it can't alter what it carries. The worst it can do is fail to deliver.
The skill that makes this safe is reading the signed bytes before they leave. The Read Before You Sign checklist in the Tx Reader is the habit.
Why CLAM has no public broadcast service
On bigger chains, you can paste a signed transaction into a public web page and the page broadcasts it for you. In October 2026 we found no such service for CLAM. The public CLAM explorer reads the chain well, but it doesn't take submissions. The general-purpose wallet libraries never added CLAM either, so the common tools can't produce or send its transaction format. That format puts a timestamp after the version number and, from version 2 on, a short text note (ClamSpeech) at the end.
So the only way onto the chain is the network itself: speak CLAM's own peer-to-peer protocol to a running CLAM node and give it the bytes. That's what the path below does.
The path
Key stays hereThe benchBuilds and signs offline, then reads its own signed bytes back before anything leaves.
Bytes onlyA home relay machineAn ordinary computer that forwards the signed bytes. It never holds a key and can't change what it forwards.
Any node that answersA CLAM peerA stranger's node on the CLAM network. It checks the transaction against the rules and passes it on to its own peers.
Proof lives hereThe chainA block includes it. From then on, anyone can read it with no help from us.
What crosses every arrow: signed transaction bytes.What never crosses one: a key.
The receipt
The first transaction to take this path, October 18, 2026. It's laid out as a receipts card, the format our private bench console uses for closed operations. This is only the record: there's nothing on it to press.
CLAM · Relay Send · Receipt 1
Signed offline, broadcast through a relay, read back on chain
The fee is whatever the inputs leave unpaid; no line on a transaction says "fee". Here that's 0.001 CLAM for 196 bytes, about 0.0051 CLAM per kilobyte. The relay forwards bytes and takes nothing.
Read-back
Sent, because an independent read shows it
Read from the public CryptoID CLAM explorer on Oct 18, 2026 at 11:08 PM ET.
In block 6428301, which was mined at 10:37 PM ET. It had 33 confirmations at the time of the read.
Spent 50.00000000, paid 49.999, fee 0.001. All three match the record above.
The raw bytes hash to the txid below.
The peer's "accepted" didn't count as proof. Only the chain read does.
Don't take this card's word for it either. The Tx Reader decodes the bytes in your browser and refuses any that don't hash to this txid, and CryptoID is a public explorer we don't run.
Three things that went wrong first
All three were our own mistakes or old public lists. Each one stopped the send before anything left, and none of them could have changed the transaction.
Wall 1 · Access
A new, limited access path refused the key
We set up a new, narrowly-scoped way for the bench to hand bytes to the relay. On its first use it refused the credential, and we still don't know why. Nothing was sent.
What we did: carried the bytes over an access path that had already been proven, and logged the new one as unresolved. A refused door is a safe failure. Check the door before you suspect the bytes.
Wall 2 · Checksum
The checksum was computed over the wrong bytes
Every message on CLAM's network carries a short checksum of its contents. The broadcaster first calculated that checksum over the wrong bytes, so peers dropped the message without a word.
What we did: computed it over exactly the bytes being sent. The corrected message is the one the network accepted. It's the Read Before You Sign lesson again: check the exact bytes you send, not the bytes you meant to send.
Wall 3 · Peers
Most listed peers never answered
Public CLAM peer lists are old. Most of the nodes on them didn't answer at all.
What we did: the broadcaster now works down the list until one peer completes the handshake and takes the transaction. Even then, the peer's word isn't the proof. The read-back on chain is.
The lesson
Lesson slot · zoran-mini's lesson on signing here and broadcasting there will appear here.
The rules this page keeps
Nothing on this page can send, sign or connect a wallet. It never asks for a key or a seed phrase, and there's nowhere to type one.
The page makes no network calls of its own. Its Content-Security-Policy allows none.
The diagram is deliberately abstract. Showing how a machine is reached teaches nothing about signing.
This is mechanics, not a recommendation. Nothing here is a reason to buy, hold or move any coin.
Not financial advice. Education only. Crypto tokens are high-risk and can go to zero. No promised returns. 18+ only. Only use funds you can afford to lose, and do your own research. We will never ask for your seed phrase.