I think this is a way to pretend that Bitcoin has covenants. Basically, you rely on a set of oracles to enforce the covenant opcodes that do not yet exist on Bitcoin. You create a transaction using non-existent opcodes in Tapscript which do not get evaluated by normal nodes, but do get evaluated by oracles that control a multisig. The oracles are supposed to only sign if the covenant script you included is satisfied.

Real-World Applications EnabledReal-World Applications Enabled

With these five opcodes, you can build:

• Vaults: Time-locked withdrawals with amount limits and emergency recovery
• Payment Pools: Shared UTXO management with off-chain updates
• Fraud Proofs: Optimistic rollups and validity challenges (MATT-style)
• Bridges: Cross-chain asset transfers with cryptographic verification
• Congestion Control: Fee-efficient transaction batching and consolidation
• State Channels: Lightning-like channels with more flexible state transitions
• Covenants: Recursive spending restrictions and coin coloring

The caveat is that you are trusting the oracles -- although, to what extent I'm not entirely sure. Seems like if they can sign on your behalf when certain extra logic is satisfied, they could also sign on your behalf without your permission. But I admire efforts like these to add the advanced functionality people want without changing block validation rules -- people who want to do complicated stuff can evaluate the trade-offs and do it, while the rest of us just keep on using Bitcoin like we always have.

Transaction PartsTransaction Parts

1. Emulated Script: The tapscript with extra op_codes you want to lock your input to, encoded in the native tapscript (for observability) and immediately dropped from the stack.
2. Oracles basic Multisig: The oracles public keys and the threshold required to sign the transaction to spend the input.
3. Witness Carrier: An OP_RETURN output containing the witness data for the emulated script, necessary to be signed so the oracles must commit to the witness they have evaluated.

I'm not fully sure how the 3rd part is working. But perhaps this description of the transaction flow makes it easier to understand:

Transaction FlowTransaction Flow

Step 1: Lock UTXOStep 1: Lock UTXO

User creates Taproot output with:

• Encoded SAKE script (emulated logic)
• Oracle public keys (e.g., 2-of-3)
• Optional: Alternative tapleafs for fallback/recovery

Step 2: Create Spending TransactionStep 2: Create Spending Transaction

User constructs transaction:

• Inputs: Spend the locked UTXO
• Outputs: Desired outputs
• Last Output: Witness Carrier (OP_RETURN with emulation witness)

Step 3: Send to OraclesStep 3: Send to Oracles

User send the transaction, prevouts and scripts to each oracle

• Oracles receive the transaction (with empty Witnesses)
• No coordination between oracles needed
• Each oracle validates independently

Step 4: Oracle Validation (Independent & Parallel)Step 4: Oracle Validation (Independent & Parallel)

Each oracle:

1. Extracts witness carrier from last output
2. Extracts encoded SAKE script from each spending input
3. Removes witness carrier from transaction
4. Runs emulation engine with witness stacks
5. If valid → signs transaction | If invalid → rejects

Step 5: Collect SignaturesStep 5: Collect Signatures

User collects threshold signatures from oracles

• Constructs Taproot witness for each input with emulated script

Step 6: Broadcast to Bitcoin NetworkStep 6: Broadcast to Bitcoin Network

Bitcoin nodes validate:

• Native Taproot script (oracle signatures + threshold)
• Standard Bitcoin consensus rules
• ✓ Transaction confirmed

Important: Oracles are stateless and don't need to communicate with each other, query the blockchain, or perform any setup ceremony. They can operate in TEEs (Trusted Execution Environments) for additional security.

I believe the particular opcodes that this method tries to emulate are:

• OP_CTV
• OP_CAT
• OP_CCV
• OP_CSFS
• OP_AMOUNT

Which were proposed as something called the Script Army Knife by Salvatore Ingala