Do we need Ethereum-like events on Miden

[Dominik1999]

Ethereum-like events on Miden

Some builders coming from Ethereum have asked for “events” on Miden. They are used to wiring their apps around event streams: backends and frontends subscribe to specific contracts and react when those contracts emit events.

Recap what are Ethereum-like events

On Ethereum and other EVM chains, events are logs emitted by smart contracts during execution. Contracts call emit MyEvent(arg1, arg2, ...).

The EVM writes a log entry containing:

• The contract address
• A list of topics (event signature hash + indexed fields)
• An unindexed data blob

These logs become part of the transaction receipt. They are not readable on-chain and only for off-chain consumption. But they are accessible via APIs like eth_getLogs and eth_subscribe.

How they are used today:

• Backends / indexers: Subscribe to events to update state, trigger automation, or maintain databases.
• Frontends: Show live protocol activity (trades, swaps, liquidations, governance actions).
• Bots & keepers: React to specific events.
• Analytics & monitoring: Parse event logs for dashboards and alerts.
• General off-chain signalling: Contracts tell the off-chain world “something happened.”
• Events are a simple but powerful integration point for applications.

Solana doesn't have events like this but Solana programs also emit log messages.

How can we replicate this on Miden?

On Miden, clients can already subscribe to certain note tags. And with 0xMiden/miden-client#467 we will allow clients to ract to certain "events".

However, currently it is not possible to react to a deposit into a smart contract or to the creation of a new smart contract of a certain type. Ideally, builders or developers could set certain flags in their code when to emit events. We do already support events in the VM, as far as I know they just stay local. So a rather straight forward implementation would be

For any public action (network account changes, public accounts, maybe public notes?) we can expose the event logs with the transaction. Then, anyone can subscribe via

• getEvents for historical queries
• subscribeEvents for live streams

This is very familiar for EVM devs, it's clean and simple and easy to filter. The problem might be, events are fully public and we add more data to the network.

I am sure there are better options.

[bobbinth]

Could we flash out the use case a bit more? My current assumptions:

1. A local user needs to monitor a network account.
2. Just following the updates of the account is not sufficient, or
3. The user cannot follow the updates locally for some reason.

Are these correct? I'm specifically curious about the second point because things like "react to a deposit into a smart contract" should be pretty easy to do by just observing account updates that we already get from the network (after 0xMiden/miden-client#467 is done).

[mmagician]

Good questions - I think it mostly comes down to intent signaling vs state tracking.

Following account updates is sufficient to answer "what is the new state?", but it doesn’t always answer "what kind of thing just happened?" without additional bookkeeping.

Concretely, reacting to a deposit into a contract is possible by observing account updates, but requires the consumer to:

• track prior state, compute the diffs,
• and infer intent ("this was a deposit", not just "state changed". A balance increase might be a result of a "pure" deposit, but might also be triggered by a SWAP. While it's certainly possible to infer intent from state changes, it requires complex and custom logic for handling multiple scenarios).

An event, on the other hand, is an explicit, structured signal that says a specific action occurred independent of historical state.

[bobbinth]

I think this makes sense. But to clarify the use case:

• We have a client that wants to follow updates to some network account.
• As the client syncs with the account, in addition to state updates, the client also receives a set of events that were emitted when these updates were made.

Is this correct?

[mmagician]

We have a client that wants to follow updates to some network account.

Not necessarily to a network account, I think any public account is of interest.

in addition to state updates

The client might not even be interested in state updates per-se. For example, if a deposit happens, only then query further for state updates, but it might also do other offchain actions (e.g. send push notification).

[mmagician]

A concrete first design can be fairly minimal. Assuming we keep the trust in the node centralized, we can avoid changing the block header at this point, and have the node simply collect the event logs for offchain (gRPC) access.

Rename emit -> host_hint (or similar)

First - I would rename the current emit instruction to host_hint and treat it purely as the host integration surface for nondeterministic advice and precompiles. That frees up emit to mean "user facing event log" like EVM devs expect.

New emit instruction

Then, I'd introduce a new emit that takes a variable number of immediates - one mandatory topic and a variable number of payload elements:

• emit.<topic>.<k0>.<k1>...
• each k_i is a key - the host handling this event tries to resolve each key via the advice map and attaches the value to the emitted record. If the value under the key is not found, treat the key as the value

Node

On handling the event in the host, it can enrich each emitted event with execution metadata that is not provided by the caller - e.g. contract account ID, block number, etc. This keeps the VM interface minimal, while giving indexers and devs more contextual data that they typically expect to get from an event stream.

The node then captures these emitted events during tx execution and persist them alongside the block data, then exposes them over gRPC e.g. via getEvents(filters) or even streamEvents(filters) for a streaming gRPC.

---

For a future iteration (when trust in a central block producer is no longer acceptable) we'd need to adjust the block header to include the commitment to emitted events.

[bobbinth]

Assuming I understand the use case correctly, I don't think we need any changes in the VM for this. I think these events are more of a transaction-level construct - similar to output notes and account delta.

Here is some understanding:

• The developer wants to emit some set of events during transaction execution.
• As the events are emitted, we build a cryptographic commitment to them (tracked in the transaction kernel).
• At the end of the transaction kernel, commitment to these events is returned via the output stack (similar how we return commitment to the output notes).
• When the client syncs with the node (e.g., via the SyncTransactions endpoint), they also get all the events emitted the the returned transaction.
• The client can then interpret these events as needed in the context of the specific account.

The node then captures these emitted events during tx execution and persist them alongside the block data, then exposes them over gRPC e.g. via getEvents(filters) or even streamEvents(filters) for a streaming gRPC.

I'm not sure doing this at the block level is all that useful. If the user is interested in following a small set of accounts, they should be able to get the events only for that accounts. For these, we could have a separate endpoint - e.g., GetAccountEvents or something similar.

First - I would rename the current emit instruction to host_hint and treat it purely as the host integration surface for nondeterministic advice and precompiles. That frees up emit to mean "user facing event log" like EVM devs expect.

As I mentioned above, I don't think this is a VM-level construct. So, I'd keep the emit instruction there. To support this at the blockchain level, we can introduce a new kernel procedure - we could call it emit as well, but I also thing log may be a more appropriate name. The usage could be something like:

use miden::protocol::tx

begin
    exec.tx::log
end