EmulatorBase

Adds a UTxO to the ledger directly, bypassing transaction validation. Overwrites any UTxO already sitting at the same input.

An inline datum on output joins the datum store, so getDatum answers for a script UTxO seeded this way exactly as it does for one produced by a transaction.

Index of applied transactions by hash, for O(1) lookup.

Ordered log of transactions applied to this emulator, in submission order (oldest first).

Unlike appliedTxs (hashes only), each entry retains the full transaction together with the slot it was applied at and the inputs it consumed (resolved against the pre-application UTxO set). This lets callers reconstruct chain history — e.g. walk the continuing outputs of an asset — without keeping their own submitted-transaction bookkeeping.

Ordering reflects submission order. Under concurrent submission the log entry and the ledger state transition it describes are published together, so a reader never sees a UTxO set that has moved past the log.

Hashes of all applied transactions. Held as a materialized set (derived from appliedTxLog by EmulatorState, so it cannot drift) rather than a per-call key-set view, so access is a plain O(1) field read.

Returns CardanoInfo for this reader.

This is always available synchronously after the reader is constructed. For emulators, this returns the current context. For remote providers like BlockfrostProvider, the CardanoInfo is fetched during async construction.

Whether this emulator has applied the transaction.

Authoritative, unlike the inherited default, which infers status from the UTxOs a transaction produced: findUtxos here answers Right(empty) for a transaction it has never seen, and an emulator that has applied a transaction whose outputs are all since spent produces none either. The applied-transaction index knows the answer outright.

Clear the applied-transaction bookkeeping (appliedTxLog and appliedTxIndex), leaving the ledger state (utxos, certState, datums) untouched.

Returns the current slot number.

The current slot, without the Future wrapper.

An emulator's slot is in-memory state, so the effectful accessor above is a formality imposed by the BlockchainReader interface. Streaming needs the value synchronously while building a chain point, where handing back an already-completed Future and unwrapping it would be pure ceremony.

Evaluator mode the emulator runs Plutus scripts in (e.g. Validate vs EvaluateAndComputeCost). Exposed so snapshots such as ImmutableEmulator.fromEmulator can preserve it rather than silently reverting to the Context default.

Emulator uses parasitic EC since all operations are synchronous.

Fetches the latest protocol parameters from the network.

Find UTxOs using a type-safe query.

findUtxos without the Future. The emulator's state is in memory and its query evaluation is pure, so the effect wrapper is an interface formality — JavaScript and Java callers both want the value.

Look up the full applied-tx record (transaction + slot + spent inputs) by hash.

Look up a datum by its hash. Returns None if unknown.

Look up a previously applied transaction by hash, or None if it was never applied.

Removes a UTxO from the ledger directly, bypassing transaction validation. A no-op if no UTxO sits at that input.

A datum the removed UTxO carried inline stays in the datum store: a node keeps answering for a datum it has seen after the output holding it is spent, and so does this.

An independent emulator starting from this one's state, taken as a single read — the copy and the original share no mutable cell and evolve separately from here on.

Live stake per registered stake credential: the lovelace sitting at addresses delegating to it, plus its reward balance, and the pool it delegates to.

This is the emulator's answer to "who controls how much stake", the query a governance or delegation test needs. It is not a reward calculation: nothing is paid out.

Pointer addresses are ignored — they are deprecated and carry no stake here.

Reads the state cell once, the way snapshot does. Two reads would let a submission land between them on the JVM, producing a row whose stake came from the post-transaction UTxO set and whose rewards came from the pre-transaction certificate state.

Submits a transaction to the network.

Submit a transaction with debug scripts for diagnostic replay.

When a release script fails with empty logs, the evaluator replays it using the debug script to produce diagnostic output.

Synchronously submit a transaction with debug scripts for diagnostic replay.

Find a single UTxO by its transaction input.

Find all UTxOs at the given address.

Find UTxOs by a set of transaction inputs (fails with NotFound if not all are found).

Map over the Future effect using this reader's captured ExecutionContext.

Poll for transaction confirmation.

Default implementation for emulators: a single check is sufficient since confirmation is instant.

Query UTxOs using a lambda DSL.

Translates the lambda to a UtxoQuery at compile time and returns a builder that can be further configured before execution. Effect-polymorphic — the resulting .execute() returns the reader's own F[Either[UtxoQueryError, Utxos]], so the same call shape works on Future-typed providers (Blockfrost, JS) and direct-style providers (ox Id).

Example:

// Simple query — execute immediately
reader.queryUtxos { u =>
 u.output.address == myAddress
}.execute()

// With pagination and minimum total
reader.queryUtxos { u =>
 u.output.address == myAddress && u.output.value.hasAsset(policyId, assetName)
}.minTotal(Coin.ada(100)).limit(10).execute()

Supported expressions:

• u.output.address == addr — query by address
• u.input.transactionId == txId — query by transaction
• u.output.value.hasAsset(policyId, assetName) — query/filter by asset
• u.output.value.coin >= amount — filter by minimum lovelace
• u.output.hasDatumHash(hash) — filter by datum hash
• && — AND combination
• || — OR combination

Submit a transaction and poll until confirmed.

Default implementation composes submit and pollForConfirmation.