Docs · 05 / 8
Actions
The exact transaction layout of an action.
Transaction layout
An action is a Bitcoin transaction with this layout.
Inputs
Input 0
program account (sender)
witness: [signature, leaf script, control block]
witness: [signature, leaf script, control block]
Input 1…n
program accounts of this program
witness: [signature, leaf script, control block]
witness: [signature, leaf script, control block]
Outputs
Output 0
OP_RETURN · action JSON
Output 1
change → input 0's own program account
Output 2+
free; meaning set by the program via $tx.outputs[i]
Rules
| Part | Rule |
|---|---|
| Inputs | Every input must be a script-path spend of a program account of this program, through its leaf. The witness is exactly [signature, leaf script, control block]. The signature is 64 bytes (SIGHASH_DEFAULT) or 65 with SIGHASH_ALL. The leaf must be the exact 68-byte <cmr> OP_DROP <pubkey> OP_CHECKSIG, and the control block's internal key must equal the signer. |
| Output 0 | OP_RETURN with the action JSON. |
| Output 1 | Input 0's own program account: the change, where the sender's funds continue. |
| Output 2+ | Free. The program decides what they mean through $tx.outputs[i] (for example output 2 = payment or receiver). |
| Count | At least 3 outputs. |
The action JSON
output 0 (OP_RETURN)
{"p":"sats-20","op":"<method>","prog_id":"<program id>", ...args}pmust besats-20.opmust be one of the program's write methods.prog_idis the id of the target program (its deploy reveal transaction id).- The remaining keys are the method's declared arguments.
Notes
- The signature commits to the leaf (so to the
cmr) and to every output. Bitcoin consensus therefore proves who sent the action, which program it targets, and that it was not altered. $tx.inputs[i].addressis the signer's identity address, not the program account the coins sat in.$tx.inputs[0].addressis the sender.- The leaf is spent with the signer's untweaked key as a script-path (Schnorr) signature, not as a key-path spend.
- An annex is ignored.
SATS20