SPORE: Verifiable Instructions
Status: conceptual, last checked 2026-11-02. No SPORE code is on Dial-SDK main yet and the wire
format is not final. This page describes required behavior, not a schema you can implement against.
A SPORE is a signed object that says what someone authorized. It can travel over any channel, including a text message, an email, a thread or an API call, and the recipient can verify it without asking the sender’s server. It can represent one party’s authorization or a proposal that several parties have to approve.
A valid signature proves that a key signed these bytes. It does not prove every named party agreed, and it does not make the object a legal contract.
What a SPORE has to bind
The signature has to cover enough information that nobody can change the meaning afterwards.
| Category | Examples |
|---|---|
| Issuer and controller | Who issued it and who may change it |
| Audience | The intended recipient, or an explicit open audience |
| Permitted actions | The commands or capabilities it allows |
| Economic limits | Amount, currency, fee policy, settlement constraints |
| Time and replay | Expiry, nonce, sequence |
| Version and revocation | Which version this is and how to check whether it was revoked |
| References | Content hash, program commitment, execution environment |
Signed and presentation fields
Anything that affects authority must be signed. Display text that isn’t signed, such as a logo or a formatted description, can be changed by whoever serves it, so a client must never treat it as a statement by the issuer. This matters for payment links: a page that shows a verified issuer has to derive that name from the signed object, not from the page content.
Canonical signing bytes
Two implementations have to produce identical bytes for the same object, or signatures will not verify across languages. The final format has to specify field order, encoding and how unknown fields are handled. It will ship with cross-language test vectors, listed on the conformance page.
Verifying a SPORE
A verifier has to do all of this before relying on the object, and reject it if any check fails:
- Check that the bytes match the expected content hash.
- Recompute the canonical bytes and verify every required signature.
- Check that each signer had authority for the action at signing time.
- Check expiry, sequence and revocation state.
- Check that the audience includes the party acting on it.
- Check that any referenced commitment matches the program being executed.
If revocation or current-version data can’t be fetched, the safe result is “not verified”. Showing cached data as current is not acceptable.
Multi-party approval
A SPORE can state that an action needs more than one approver, for example two of three signers. Delegation, thresholds and policy changes each need an explicit version, so that an old approval can’t be replayed against new terms. The design is not finished. The multi-party guide shows the intended pattern.
What SPORE leaves out
SPORE does not define addresses, gas or tokens. Those belong to SPAWN adapters and Calvin Routes. Storage systems and gateways only deliver a SPORE and hold no authority over it.
Explore invoicing: Programmable Invoicing