Docs · 06 / 8

Execution

How the indexer verifies and applies an action, and what makes it invalid.

The pipeline#

For every transaction in every block, the indexer decides in this order:

1. Is it a deploy? A reveal whose input 0 carries a valid envelope (see Deploying). If so it stores the program and runs init.
2. Is it an action? Every input must be a valid program-account leaf spend (see Actions). If any input is not, the transaction is ignored: it is not an action.
3. The OP_RETURN must hold JSON with a prog_id naming a deployed program, and the input leaves must carry that program's cmr. A different cmr, or an unknown program, means the transaction is ignored.
4. Output 1 must be input 0's own program account, and the transaction must have at least 3 outputs.
5. The action must have p equal to sats-20, and an op that is one of the program's write methods.
6. The method's require conditions are evaluated, then its set steps. If anything fails, the action is rejected and no state changes.
7. On success the writes and the record are saved atomically, and an action already recorded is never applied twice.

Invalid actions#

An invalid action is simply not part of the protocol state; nothing needs to be undone. An action is invalid when any of the following holds:

• An input is not a valid program-account leaf spend.
• The prog_id is unknown, or an input leaf carries a different cmr.
• Output 1 is not input 0's own program account, or there are fewer than 3 outputs.
• p is not sats-20, or op is not a write method of the program.
• A require fails, or a step fails (for example division by zero or an out-of-range $tx index).