If you came here from the Settlement Finality Classifier and it told you FINALITY_RISK_MOVED_OFFCHAIN, this is why: on Avalanche, finality is sub-second with no reorg tier, so the optimistic-rollup challenge-window math this suite ships elsewhere — the seven-day dispute window ART-321 checks, the validity-proof timing ART-290 checks — simply does not apply. There is no window to wait out. That does not mean an Avalanche L1 deployment carries no settlement risk. It means the risk relocated to three places nobody sells receipts for: who is authorized to sign a cross-chain message on the source chain's behalf, who is permitted to transact or deploy on the destination chain, and whether the chain itself stays funded. The five workflows below cover those three places.
Written for the ITGC, internal-audit, and treasury functions of an institution running or joining a permissioned Avalanche L1 (an Evergreen deployment), and for the engineers building one. Everything runs locally in your browser: no backend, no signup, no data leaves your machine. Every result carries a hash, so a counterparty or an examiner can rerun the same workflow on the same inputs and confirm they get the same answer. This is an independent project by Post Oak Labs, not an Avalanche product.
Avalanche's institutional pivot centers on Evergreen: a permissioned-L1 suite that lets a bank or consortium run its own subnet-EVM chain with protocol-level access controls, while still settling cross-chain via Avalanche's Interchain Messaging (ICM, formerly AWM). Under Avalanche consensus, a transaction finalizes in well under a second and stays final — there is no probabilistic reorg window and no optimistic-rollup dispute period to model. That single fact is why ART-492 flags FINALITY_RISK_MOVED_OFFCHAIN for Avalanche deployments and points here instead of at a challenge-window calculator.
Settlement risk on a permissioned Avalanche L1 shows up in three other places instead: cross-chain message trust (how many of a source chain's validators would have to collude to forge a message ICM would deliver), who holds protocol-level power on the chain itself (the five subnet-EVM precompiles that gate transacting, deploying, minting, and fee-setting), and whether the chain keeps running (ACP-77's continuous P-Chain fee draws down an L1 balance that can hit zero). None of those questions have a generic answer — each one needs the specific validator set, precompile configuration, or fee schedule an institution actually configured, which is exactly what the workflows below take as input.
Each node answers a distinct question. None of them read a chain, an RPC, or live data — every input is caller-supplied transcribed state, so the same inputs always reproduce the same receipt.
FINALITY_RISK_MOVED_OFFCHAIN points at.AVAX-SOD-1): the shipped ART-459 SoD Matrix Check already expresses this correctly once the lattice is enumerated into the ruleset, so no new node was built. ART-459 ships an Avalanche preset that does the enumeration for you, plus a negative-control preset showing the false-green receipt a naively flattened ruleset would produce over the identical grants.All four ART-494–498 nodes ship compute_proof_ready: deferred pending a batched GPU proving pass — the receipt and hash are live and reproducible today; the zero-knowledge compute proof binding follows in a later change.
The workflows above take your configuration as input regardless of who operates the underlying L1 — that choice is not a feature checklist, it is a decision about who holds operational control of the surfaces the nodes above measure.
The mechanics above — sub-second finality, ICM's BLS aggregate quorum, the five subnet-EVM precompiles, ACP-77's continuous fee — are docs-grade facts, re-verified against primary Avalanche documentation 2026-07-30. Several widely cited institutional deployments on Avalanche are not: they are reported in press and vendor materials but not independently confirmed against a primary source, and no workflow on this page rests its output on them.
Every tool on this page emits an OpenChainGraph artifact with the following properties, consistent across ART-459 and ART-494 through ART-498.
chaingraph_version: "0.4.0" in their §4 artifact payload, so consuming systems can verify schema compatibility before ingesting the artifact.
execution_hash covering node inputs, processing parameters, and outputs, computed by the shared canonical hash path. Either party in a bilateral relationship — an operator and a counterparty, an institution and its auditor — can re-run verify_execution_hash against the hash to confirm the node was run as claimed, without sharing the underlying validator set or ownership map.
mcp_name shown on each workflow card above.