Execution modes

When indexers produce a subgrove’s data, Willow has to be sure they produced it correctly. The execution mode chooses how that’s guaranteed. You set execution_mode on the BlockchainIndexing mode when you register (alongside the manifest), and it defaults to ConsensusExecution.

The modes trade off assurance against cost: stronger verification means more work per block.

ConsensusExecution

Validators re-execute the indexing for every block and compare against what the indexers submitted. Anything that doesn’t match is rejected. This is the strongest guarantee — the network itself recomputes the result — and also the heaviest, so it suits high-value datasets.

This is the default, and the mode the canonical subgroves run today.

"execution_mode": "ConsensusExecution"

IndexerExecution

Indexers execute the work and the network verifies a sample of their output rather than every block. You set sampling_rate_percent (0–50); higher means more checking. Much cheaper and scales to high-volume indexing, at the cost of probabilistic rather than total verification.

"execution_mode": { "IndexerExecution": { "sampling_rate_percent": 5 } }

TeeExecution

Indexing runs inside a Trusted Execution Environment, and the result is backed by a hardware attestation proving the expected code produced it — strong assurance without full re-execution. tee_type is AwsNitro or IntelSgx (both supported today; AmdSev is not yet).

"execution_mode": { "TeeExecution": { "tee_type": "AwsNitro" } }

GkrExecution

Execution is accompanied by a GKR proof — a cryptographic proof that the computation was performed correctly, checkable without redoing the work.

"execution_mode": "GkrExecution"

Note

GKR’s advantage today is privacy, not speed — verifying the proof is currently slower than just re-executing. Reach for it when you need the proof to reveal nothing about the inputs, not as a performance optimization.

WarpExecution

A folding-scheme mode aimed at fast verification of large historical ranges. It takes tuning parameters (codeword_log_n, n_ood, n_shifts).

"execution_mode": { "WarpExecution": { "codeword_log_n": 20, "n_ood": 2, "n_shifts": 4 } }

Choosing a mode

Mode	Verification	Relative cost	Good for
ConsensusExecution	Full re-execution by validators	Highest	High-value data; the default
IndexerExecution	Sampled checks (0–50%)	Lowest	High-volume indexing
TeeExecution	Hardware attestation	Medium	Strong assurance without re-execution
GkrExecution	Succinct GKR proof	High	Privacy of inputs
WarpExecution	Folding-scheme proof	Medium	Fast historical-range verification

Note

If you’re unsure, start with ConsensusExecution (the default) and ask on Discord.