Listening to events (frontend) in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Listening to events (frontend)

Start frontend app

↓

Connect to blockchain provider

↓

Create contract instance with ABI & address

↓

Set up event listener on contract

↓

Wait for event emitted by contract

↓

Event received -> execute callback

↓

Update UI or state with event data

↓

Continue listening or stop

The frontend connects to the blockchain, listens for contract events, and updates the UI when events happen.

Execution Sample

Blockchain / Solidity

const contract = new ethers.Contract(address, abi, provider);
contract.on('Transfer', (from, to, amount) => {
  console.log(`Transfer from ${from} to ${to} amount ${amount}`);
});

This code listens for 'Transfer' events on a contract and logs details when the event happens.

Execution Table

Step	Action	Evaluation	Result
1	Start frontend app	App initializes	Ready to connect
2	Connect to blockchain provider	Provider connected	Provider object created
3	Create contract instance	Contract with ABI and address created	Contract object ready
4	Set up event listener	Listener for 'Transfer' event added	Waiting for events
5	Event emitted on blockchain	Event data received	Callback triggered
6	Execute callback	Log event details	Console shows event info
7	Update UI/state	UI reflects new data	User sees updated info
8	Continue listening	Listener remains active	Ready for next event

💡 Execution continues indefinitely as events keep coming or until listener is removed.

Variable Tracker

Variable	Start	After Step 3	After Step 5	After Step 6	Final
provider	undefined	connected provider object	connected provider object	connected provider object	connected provider object
contract	undefined	contract instance	contract instance	contract instance	contract instance
eventListener	undefined	undefined	listener active	listener active	listener active
eventData	undefined	undefined	{from, to, amount}	{from, to, amount}	{from, to, amount}

Key Moments - 3 Insights

Why does the event listener keep running after the callback executes?

Because the listener is set up to continuously listen for events (see execution_table step 8), it does not stop automatically after one event.

What happens if the blockchain emits multiple events quickly?

Each event triggers the callback separately in order, updating the UI or logging each event as shown in steps 5 and 6.

Why do we need the contract ABI and address to listen to events?

The ABI defines the event structure and the address tells where the contract lives, so the frontend knows what events to listen for and how to decode them (step 3).

Visual Quiz - 3 Questions

Look at the execution table, what is the state of 'contract' after step 3?

A Contract is undefined

B Event listener is active

C Contract instance is created and ready

D Provider is disconnected

💡 Hint

Check the 'contract' variable in variable_tracker after step 3

At which step does the event listener receive event data?

A Step 5

B Step 4

C Step 7

D Step 2

💡 Hint

Look at execution_table row where event data is received

If the event listener is removed after step 6, what changes in the execution flow?

A Provider disconnects automatically

B Listener stops, no further events trigger callback

C Listener continues as normal

D Contract instance is deleted

💡 Hint

Refer to execution_table step 8 about continuing listening

Concept Snapshot

Listening to events (frontend):
- Connect to blockchain provider
- Create contract instance with ABI & address
- Set event listener on contract
- When event fires, callback runs
- Update UI/state with event data
- Listener stays active until removed

Full Transcript

This visual trace shows how a frontend app listens to blockchain contract events. First, the app connects to a blockchain provider. Then it creates a contract instance using the contract's ABI and address. Next, it sets up an event listener for a specific event, such as 'Transfer'. When the blockchain emits this event, the listener receives the event data and runs a callback function. The callback logs the event details and updates the user interface. The listener remains active to catch future events until it is explicitly removed.

Practice

1. What is the main purpose of listening to blockchain events in a frontend application?

easy

A. To create new smart contracts

B. To send transactions to the blockchain

C. To react instantly when something changes on the blockchain

D. To mine new blocks on the blockchain

Solution

1. Step 1: Understand event listening in frontend

   Listening to events means the app waits and reacts when blockchain data changes.

2. Step 2: Identify the purpose of event listening

   The main goal is to update the app instantly when something happens on the blockchain.

3. Final Answer:

   To react instantly when something changes on the blockchain -> Option C

4. Quick Check:

   Listening to events = instant reaction [OK]

Hint: Events let your app update instantly on blockchain changes [OK]

Common Mistakes:

• Confusing event listening with sending transactions
• Thinking event listening creates contracts
• Mixing event listening with mining blocks

2. Which of the following is the correct way to listen continuously to an event named Transfer using ethers.js?

easy

A. contract.once('Transfer', callback)

B. contract.watch('Transfer', callback)

C. contract.listen('Transfer', callback)

D. contract.on('Transfer', callback)

Solution

1. Step 1: Recall ethers.js event listening methods

   Use contract.on to listen continuously to events.

2. Step 2: Match method to event name

   For event 'Transfer', the syntax is contract.on('Transfer', callback).

3. Final Answer:

   contract.on('Transfer', callback) -> Option D

4. Quick Check:

   Continuous listening = contract.on [OK]

Hint: Use contract.on for continuous event listening [OK]

Common Mistakes:

• Using contract.once for continuous listening
• Using non-existent methods like listen or watch
• Confusing method names

3. Given this code snippet using ethers.js:

contract.once('Approval', (owner, spender, value) => {
  console.log(`Owner: ${owner}`);
  console.log(`Spender: ${spender}`);
  console.log(`Value: ${value}`);
});

// Event emitted: Approval('0xabc', '0xdef', 100)

What will be printed to the console?

medium

A. Owner: 0xabc\nSpender: 0xdef\nValue: 100

B. Owner: 0xdef\nSpender: 0xabc\nValue: 100

C. Owner: 0xabc\nSpender: 0xdef

D. No output because contract.once listens only once

Solution

1. Step 1: Understand contract.once behavior

   contract.once listens for the next single event and runs the callback once.

2. Step 2: Match event parameters to callback

   The event emits Approval('0xabc', '0xdef', 100), so owner='0xabc', spender='0xdef', value=100.

3. Final Answer:

   Owner: 0xabc\nSpender: 0xdef\nValue: 100 -> Option A

4. Quick Check:

   contract.once prints event data once [OK]

Hint: contract.once triggers callback once with event args [OK]

Common Mistakes:

• Swapping owner and spender values
• Thinking contract.once never prints
• Missing the value parameter in output

4. You wrote this code to listen to a Deposit event:

contract.on('Deposit', (user, amount) => {
  console.log(`User ${user} deposited ${amount}`);
});

But your app never logs anything even though deposits happen. What is the most likely mistake?

medium

A. The event name 'Deposit' is misspelled or does not exist in ABI

B. You used contract.once instead of contract.on

C. You did not import ethers.js library

D. You forgot to connect the provider to the contract

Solution

1. Step 1: Check event name and ABI

   If the event name is wrong or missing in ABI, the listener won't trigger.

2. Step 2: Verify other common issues

   Provider connection and import errors usually cause runtime errors, not silent no logs.

3. Final Answer:

   The event name 'Deposit' is misspelled or does not exist in ABI -> Option A

4. Quick Check:

   Correct event name in ABI = logs appear [OK]

Hint: Check event name spelling and ABI matches [OK]

Common Mistakes:

• Assuming contract.once listens continuously
• Ignoring ABI event definitions
• Not connecting provider causes errors, not silent failure

5. You want your frontend app to listen to a Transfer event but only react to transfers where the from address is your wallet address 0x123. Which approach correctly filters these events using ethers.js?

hard

A. contract.on('Transfer', { from: '0x123' }, callback)

B. contract.on('Transfer', (from, to, amount) => { if (from === '0x123') { /* react */ } })

C. contract.filter('Transfer').from('0x123').on(callback)

D. contract.once('Transfer', (from, to, amount) => { if (from === '0x123') { /* react */ } })

Solution

1. Step 1: Understand event filtering in ethers.js frontend

   Direct filtering by event parameters in contract.on is not supported; filtering must be done inside the callback.

2. Step 2: Choose correct method to filter by 'from'

   Use contract.on('Transfer', callback) and inside callback check if from === '0x123'.

3. Final Answer:

   contract.on('Transfer', (from, to, amount) => { if (from === '0x123') { /* react */ } }) -> Option B

4. Quick Check:

   Filter inside callback for specific addresses [OK]

Hint: Filter event data inside callback, not in contract.on params [OK]

Common Mistakes:

• Trying to filter events by passing object to contract.on
• Using contract.once for continuous filtering
• Using non-existent filter chaining methods