Programmable Invoicing
Invoicing is one application of the stack. Here Bob bills Alice 500 USDC for design work, and Alice has no Dial account.
1. Start with what the business means
From: Bob's Studio
To: Alice
Amount: 500 USDC
Due: 30 days
For: Design work, OctoberNothing here mentions a network, an address or a contract. In the planned model an invoice stays that way: it has no dependency on EVM, Cardano or any wallet.
2. Sign it as a SPORE
Bob signs the invoice. The signature covers the amount, the recipient’s settlement constraints, the fee treatment, the expiry and a reference to the program. See what a SPORE binds. Anyone who changes the amount or payout details invalidates it.
3. Reference a SPAWN program
The invoice references a program commitment describing how payment is handled. The commitment is computed from the program’s rules first and then signed, which avoids a circular dependency between the hash of the signed object and the commitment inside it.
4. Optionally, a pay destination
If Bob accepts payment on a network that supports it, an adapter can bind the commitment to a destination there. On EVM that’s a CREATE2 address, and on Cardano it’s a script address. They are different addresses computed differently, and both answer to the same commitment.
5. Alice opens the invoice
Bob shares a link. The planned public viewer is dial.work/s/{reference}, and that’s a page for the object in the product, separate from this documentation. Alice’s client resolves the object and verifies it before showing it as genuine.
Payment requests sent by text or email are a phishing target. The issuer name shown to Alice has to come from the verified signature and identity binding. See security.
6. Calvin quotes
Calvin takes what Alice can pay with and what Bob accepts, and returns a quote. Under the planned DNN Payments profile the quote shows the principal, a 25 bps protocol fee, route fees and network fees, each with who pays it.
7. Alice authorizes, and the action runs
Alice approves that quote. If it expires or the fees change, she has to approve again. The adapter then executes within those limits.
8. Receipt
The result is a receipt tied to the invoice. Reloading the link shows the settled state and doesn’t charge her again. Alice, Bob or an auditor can check the evidence independently.
When things go wrong
| Problem | Expected result |
|---|---|
| Amount tampered with | Signature check fails, nothing is shown as valid |
| Invoice expired or revoked | Payment is refused |
| Quote expired | New quote, new authorization |
| Alice pays twice | No second settlement through the route. A separate manual transfer needs reconciliation |
| Wrong token sent to the destination | Depends on the adapter. May be unrecoverable |
Explore invoicing: Programmable Invoicing