Glossary

How the Midgard ledger worksWhat this explorer tracks, and where each record comes from

Transaction lifecycle

A transaction moves from queued through validating and accepted, waits as pending commit, then becomes committed once a Midgard block includes it. Rejected transactions stop and keep their reason.

Block finalization

The operator commits Midgard blocks, then submits a finalization transaction to Cardano. A block is finalized only after that Cardano transaction is confirmed and stable.

L1 ↔ L2 bridge

Deposits move value onto the Midgard ledger, withdrawals move it back to Cardano, and forced transactions are orders escrowed on Cardano that the operator must include.

Ledger

Chain tip: The newest block Midgard has made that this explorer can read. Midgard makes a block only when work is waiting, so an old tip is normal when nothing waits.
Blocks: Every block Midgard has made that this explorer has recorded. The hourly chart above the latest blocks shows recent activity.
Transactions: Every transaction included in a Midgard block so far. The hourly chart above the latest transactions shows recent activity.
Awaiting settlement: Blocks made on Midgard that the node has not yet reported final on Cardano. Their transactions can still be reversed until settlement completes.
Block settlements: Blocks the node has posted to Cardano to make them final there. A block's transactions are final once its settlement is finalized on Cardano.
Deposits: Funds sent from Cardano into Midgard, as the node recorded them. A deposit changes Midgard balances once a Midgard block includes it.
Withdrawals: Funds leaving Midgard for Cardano, as the node recorded them. Each withdrawal's status shows how far it has got, from awaiting to finalized.
Forced transactions: Transactions submitted on Cardano that the Midgard operator must include. They let a user reach the ledger even when the operator would not include their transaction.
Records: Every record the node keeps of what it did on Cardano. It is the sum of block settlements, deposits, withdrawals and forced transactions.
Block height: The block's sequential position in the Midgard chain. A greater height is newer, but height alone does not prove Cardano finality.
Block hash: The content-derived identifier for one exact block. Compare the full value when verifying a block because heights can be reorganized.
Slot: The Cardano time slot in which the containing block was produced. Validity bounds expressed in slots decide whether a transaction can be accepted.
Epoch: A numbered Cardano period containing many slots. Protocol parameters and stake state can change at epoch boundaries.
Committed to Cardano: Blocks whose commit reached the required depth on Cardano and that the node applied to its own ledger. A committed block is final only once it merges into the confirmed state; the block list shows which have.
L1 settlement: The node has posted the Midgard block to Cardano and reports it final there. Until then, the block's transactions can still be reversed if its settlement is abandoned.
Payment credential: The key hash or script hash that authorizes spending from an address. A script credential requires successful script execution; a key credential requires its signature.
Stake credential: The key or script identity controlling staking rights associated with an address. It determines delegation and reward authority, not who can spend the payment value.
Consumed by: The later transaction that spent this exact UTxO. A consumed output is historical and no longer contributes to the current ledger balance.
State commitment: The Midgard block header written into a Cardano transaction, holding the Merkle roots for that block's transactions, deposits, withdrawals, forced transactions and state transition. It is what Cardano actually records about a Midgard block. The block's contents are not on Cardano, so this is the durable evidence a block was committed, not a copy of what it contained.
Merkle root: A single hash summarising a whole set of items, so any one item can be proven a member of the set without publishing the rest. A matching root proves the set has not changed since it was committed. It does not by itself reveal or retrieve any item in that set.
Settlement transaction: The Cardano transaction that carried this state commitment onto the L1 chain. Until a commitment is attributed to one, the explorer has seen the header re-output by a later transaction but has not yet observed the transaction that first committed it.

Transaction

Transaction hash: The content-derived identifier of one exact transaction. Use the full hash, not its shortened display, when comparing or linking records.
Fee: The lovelace paid for processing and storing this transaction. It is consumed rather than sent to an output, so inputs must cover outputs plus this amount.
Total output: The sum of lovelace assigned to every output in the transaction. It excludes the fee and does not describe native-asset quantities.
Validity interval: The inclusive slot range in which the ledger may accept the transaction. Outside that range the transaction is invalid even if its signatures and scripts pass.
Network ID: The Cardano network the transaction declares, such as mainnet or a testnet. A mismatched network prevents the transaction from being valid on the connected chain.
Format version: The transaction-body encoding version decoded by the explorer. Unknown versions may leave otherwise valid bytes only partially decoded.
Witness set: The signatures, scripts, datums, and redeemers supplied to authorize a transaction. Missing or invalid required witnesses cause validation to fail.
Input: A previously created UTxO that this transaction consumes. After a valid transaction is applied, that exact UTxO cannot be spent again.
Output: A new UTxO created at an address with ada, assets, and optional script data. It remains spendable until another transaction consumes its transaction-hash and index pair.
Reference input: A UTxO made available to a script for reading without being spent. The referenced value stays in the ledger after this transaction succeeds.
Collateral input: A key-controlled input reserved to cover script-validation costs. It can be collected when phase-two script validation fails.
Collateral return: The output returning collateral value not required by the transaction. When present, only the declared total collateral is at risk rather than the whole collateral input.
Transaction metadata: Auxiliary label-keyed data attached to the transaction but not held in a UTxO. Applications may interpret it, but spending rules do not treat it as ledger state.
CIP-20 message: Human-readable message fragments stored under transaction metadata label 674. The text is user-supplied and should not be treated as verified identity or protocol instruction.
Certificate deposit: Lovelace deposited or refunded by stake, pool, DRep, or governance certificates. It changes the transaction balance independently of ordinary UTxO outputs.

Script

Datum hash: The hash committing an output to the datum a spending script expects. The actual datum must match this hash when the output is spent.
Inline datum: Script state stored directly inside an output instead of only by hash. A spender can read it without supplying separate datum bytes, but still must satisfy the script.
Reference script: Reusable script bytes stored on an output and referenced by another transaction. The spending transaction can avoid carrying those bytes again, reducing its size and fee.
Script bytes: The serialized on-ledger program that participates in transaction validation. Recompute and compare its hash before treating the displayed script identity as verified.
Redeemer: The transaction-supplied argument and purpose for one Plutus script execution. Its value and indexed purpose influence whether that script accepts the transaction.
Execution units: The measured Plutus memory and CPU-step budgets used by a script execution. Exceeding either declared limit makes validation fail and affects the execution fee.
Script size: The number of bytes in the serialized script. Larger scripts increase transaction size when carried directly and can increase fees.
Protocol event: A Midgard action classified from an authoritative validator output and its datum. An event the explorer cannot classify is still shown, with its raw datum.

Asset

Mint / burn: A signed change to a native asset's total supply under its policy. Positive quantities create units and negative quantities permanently remove units.
Policy ID: The hash identifying the minting policy that controls an asset. Assets with the same display name but different policy IDs are unrelated.
Asset name: Up to 32 user-chosen bytes paired with a policy ID. Decoded text is untrusted and non-unique, so compare the canonical bytes or fingerprint.
Asset fingerprint: A CIP-14 checksum derived from the policy ID and asset-name bytes. It provides a shorter identity to compare without trusting the asset's display name.

Status

Queued: Received by the node and waiting for validation. It can still be rejected before entering the mempool.
Validating: Being checked by the node right now. It has not yet been accepted or included in a block.
Accepted: Validated and admitted to the mempool. It can still be dropped or rejected before block inclusion.
Pending commit: Processed and waiting to be merged into a Midgard block. It is not yet part of the ledger history.
Committed: Included in a Midgard block. Reversible until that block is final on Cardano.
Rejected: Failed validation and will not be included. A corrected transaction must be submitted under a new hash.
Awaiting: Observed on Cardano, waiting for its inclusion window. It has not yet changed the Midgard ledger.
Projected: Reflected in the Midgard ledger; the containing block is not final on Cardano yet. The projected effect can still be reversed.
Consumed: The event's Cardano UTxO was consumed and its effect is in the Midgard ledger. Final once the containing block settles.
Pending submission: The node has not submitted the finalization transaction to Cardano yet. Every transaction in this block remains reversible.
Submitted (local pending): Finalization submitted; the node's local confirmation is still pending. Do not treat the block as settled yet.
Submitted (unconfirmed): The node reports the finalization submitted to Cardano and not yet confirmed. The submission may still fail or be replaced.
Awaiting stability: The node reports seeing it on Cardano and is waiting for the required chain-stability depth. A short rollback could still remove it.
Merge not recorded: The node applied this block. Its place in the state queue is not recorded yet.
Waiting to merge: In the state queue on Cardano. After merging, it still waits for the Cardano rollback window to pass before finality.
Merged: Merged into the confirmed state. A Cardano rollback could still undo it.
Not observed: This explorer reads its archive of block payloads, not Cardano or the node's records. It cannot say where this block is in settlement.
Finalized: Final. Midgard treats it as permanent.
Abandoned: The node abandoned this block's finalization, so it has not settled. The node can revive it if its commit later lands on Cardano, but never one a correction removed.
Valid (transaction): The transaction passed validation. Its state change applies if the containing block remains in the chain.
Invalid (transaction): The transaction failed validation. Its ordinary outputs do not become spendable ledger state.
Valid (withdrawal): The withdrawal passed validation. It may proceed to projection and Cardano settlement.
Non-existent UTxO: The referenced Midgard UTxO does not exist. No value can be withdrawn from that reference.
Spent UTxO: The referenced Midgard UTxO was already spent. Reusing it would be a double spend, so the withdrawal cannot proceed.
Wrong owner: The withdrawal is not signed by the owner of the UTxO. The node will not authorize its payout.
Wrong value: The withdrawal value does not match the referenced UTxO. The request must be corrected before it can proceed.
Bad signature: The withdrawal signature is invalid. Ownership has not been proven, so the withdrawal cannot proceed.
Too many tokens: The withdrawal exceeds the permitted token count. Split or reduce the value before submitting another request.
Unpayable value: The value cannot be paid out on Cardano. Its amount or asset bundle must be changed to form a valid output.
Valid (forced transaction): The operator judged the forced transaction valid. Its state change applies if the block carrying it remains in the chain.
Invalid (forced transaction): The operator judged the forced transaction invalid, for the reason shown beside it. Its requested state change is not applied.
Non-existent input: An input UTxO referenced by the forced transaction does not exist. The forced transaction cannot be applied.
Invalid signature: A required signature on the forced transaction is invalid. The claimed authorization is not accepted.
Script failed: A Plutus script in the forced transaction failed to validate. Its requested state transition cannot be applied.
Fee too low: The forced transaction's fee is below the required minimum. It must pay a sufficient fee under the active parameters.
Unbalanced: The forced transaction's inputs and outputs do not balance. It would create or destroy unaccounted value, so it is rejected.

Explorer

Blocks in a window: The number of blocks Midgard made during the stated window. Zero is normal when nothing was waiting for a block in that time.
Transactions in a window: The number of transactions included in Midgard blocks during the stated window. Zero is normal when nobody submitted a transaction in that time.
Time to admit: How long the node takes to accept or reject a transaction after receiving it. Shown as the typical time and the time within which 95% finish.
Admission queue: Transactions the node has received and has not yet accepted or rejected. A queue that keeps growing means transactions arrive faster than the node can check them.
Awaiting a block: Transactions, deposits, withdrawals and forced transactions the node has not yet put in a Midgard block. The time shown is the oldest wait: a transaction counts from when the node accepted it, a deposit, withdrawal or forced transaction from when it fell due.
Block end to last record update: The time from a block's end to the last update of the node's record of it, over every block the node applied. It is not the time the node took to apply a block: the node also updates an applied block's record when it records a submission, and records no separate application time.
Raw data: The schema-validated response returned by the explorer API without presentation changes. Use it to check a value on this page against its source.
API request: The public HTTP request the explorer used to load this record. Reuse it to fetch the same record yourself. It returns schema-validated JSON.
CBOR: The canonical binary encoding used for Cardano transaction and script data. Raw bytes remain the record of truth when a decoder cannot interpret a newer shape.
Partial decode: The explorer received the record but could not interpret every encoded field. Visible decoded values remain usable, while missing values must not be assumed to be zero or absent.
Address mark: A deterministic visual mark generated from the full address. It helps spot a repeated address at a glance. Compare the text to be certain.
Script credential mark: A square credential mark denotes a script-controlled address rather than a key-controlled one. Spending from it requires the script conditions, not only a wallet signature.
Asset mark: A deterministic circular mark generated from an asset's policy and name bytes. It helps distinguish nearby rows. It is generated from the bytes, not supplied by the issuer.
Status marker: The shape beside a status label carries the same distinction its color does. Four shapes: progress, waiting, success, and failure.