Security

Not audited. Last checked 2026-11-02. These are design requirements. Unless a page shows evidence, assume an invariant isn’t implemented yet.

Invariants

Every implementation must keep these true:

Execution can’t exceed authorization. It can’t exceed the signed amount, recipients, duration, asset or contract version.
Verification doesn’t depend on Dial services. Holding the object is enough to check the signature and the commitment.
Unverifiable means rejected. Stale, missing or unreachable data fails closed.
Side effects happen at most once per authorization.
Irreversible effects wait for settlement at the level that route requires.
A destination is only advertised if its derivation is proven against real deployment.
Every state claim has evidence. A webhook or cache entry is only a signal.

You can verify independently	You have to trust
The SPORE signature and its terms	That the signer’s key wasn’t stolen, and that the identity binding is right
The SPAWN commitment	The code behind the commitment, unless audited
On-chain execution and settlement	The network’s consensus
Route constraints in the signed object	The provider’s actual performance
	Any off-chain service’s claims
	An admin or guardian key where a contract has one

Threat	Required handling
Replayed authorization	Nonce and sequence checks, and durable deduplication before side effects
Credit granted before settlement	Hold irreversible effects until settlement. Keep a reversal path for pending states
Tampered amount or payee	Signature covers them, and clients display only signed values
Expired or revoked object	Checked at execution time, as well as at display time
Quote changed after approval	Re-authorization
Malicious metadata	Treat unsigned content as untrusted, and sanitize it for display
Wrong token or network	Warn before payment, and publish the recovery policy per adapter
Address mismatch	Four-way equality before funds
Lost deployment inputs	Store and back up salt and init code, or make them recoverable from the signed object
Reorg	Wait for the route’s stated finality
Partial failure	Report it as unresolved, with a named owner for recovery
Compromised service	Separate public read services from privileged signing services

A payment request delivered by text or email looks the same whether it’s real or forged. So:

Show the issuer only from a verified signature and identity binding, never from the message text or page content.
Show a clear unverified state when verification fails or can’t run.
Display the exact recipient, asset and network from the signed object.
Use one known resolver domain, and teach users to expect it.
Treat a link as a pointer. It carries no authority.

Explore invoicing: Programmable Invoicing