Event declaration in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Event declaration

Start contract

↓

Declare event with name and parameters

↓

Use event in functions to emit logs

↓

Listen to event outside contract

↓

React to event data

↓

End

This flow shows how an event is declared in a contract, emitted during function calls, and then listened to externally.

Execution Sample

Blockchain / Solidity

event Transfer(address indexed from, address indexed to, uint amount);

function send(address to, uint amount) public {
    emit Transfer(msg.sender, to, amount);
}

Declares a Transfer event and emits it inside a send function with sender, receiver, and amount.

Execution Table

Step	Action	Event Declaration	Emit Event	Output/Log
1	Contract starts	Transfer event declared with parameters (from, to, amount)	No	No log
2	Function send called with to=0xABC, amount=100	Event already declared	Emit Transfer event with (msg.sender, 0xABC, 100)	Log created: Transfer(from=caller, to=0xABC, amount=100)
3	External listener receives event	No change	No emit	Listener reads Transfer event data
4	End	No change	No emit	No further logs

💡 Execution stops after event is emitted and listener processes the log.

Variable Tracker

Variable	Start	After send call	Final
Transfer event	Declared with (from, to, amount)	Emitted with (caller, 0xABC, 100)	Available for listeners
msg.sender	Caller address	Used as 'from' in event	No change
to	N/A	0xABC	No change
amount	N/A	100	No change

Key Moments - 3 Insights

Why do we declare the event before using it?

The event must be declared first (see step 1 in execution_table) so the contract knows its name and parameters before emitting it.

What happens when we emit an event inside a function?

Emitting creates a log entry (step 2) that external listeners can read later (step 3), but it does not change contract state.

Can events be read inside the contract after emitting?

No, events are for external listeners only; inside the contract, they do not store data accessible later.

Visual Quiz - 3 Questions

Look at the execution_table, what is logged when the send function is called?

A No event is logged

B Transfer event with sender, receiver, and amount

C Only the amount is logged

D An error occurs

💡 Hint

Check row 2 under Output/Log in execution_table

At which step does the external listener receive the event data?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look at the Action column in execution_table for when listener reads event

If the event was not declared before emitting, what would happen?

A The contract would compile and emit normally

B The event would be emitted with default parameters

C The contract would fail to compile

D The event would be ignored silently

💡 Hint

Refer to key_moments about event declaration necessity

Concept Snapshot

Event declaration syntax:
event EventName(type indexed param1, type param2);

Emit event inside function:
emit EventName(value1, value2);

Events create logs for external listeners.
Must declare event before emitting.
Events do not change contract state.

Full Transcript

In blockchain smart contracts, events are declared with a name and parameters to create logs. The contract declares the event first, then emits it inside functions to record actions like transfers. External listeners watch for these events to react to contract activity. Events do not store data inside the contract but provide a history log. The execution flow starts with event declaration, then function calls emit the event, and listeners receive the event data. This helps track contract actions externally.

Practice

1. What is the purpose of declaring an event in a blockchain smart contract?

easy

A. To create a new token within the contract

B. To store user data permanently on the blockchain

C. To log important actions so external apps can track them

D. To execute a function automatically on contract deployment

Solution

1. Step 1: Understand event declaration purpose

   Events are declared to notify external apps about important contract actions.

2. Step 2: Compare options with event role

   Only To log important actions so external apps can track them matches the role of events as logs for external tracking.

3. Final Answer:

   To log important actions so external apps can track them -> Option C

4. Quick Check:

   Events = Logs for external apps [OK]

Hint: Events are for logging actions, not storing data [OK]

Common Mistakes:

• Confusing events with storage variables
• Thinking events execute code automatically
• Assuming events create tokens

2. Which of the following is the correct syntax to declare an event named Transfer with two indexed address parameters from and to in Solidity?

easy

A. event Transfer(address from indexed, address to indexed);

B. event Transfer(address indexed from, address indexed to);

C. event Transfer(address from, address to) indexed;

D. event Transfer(indexed address from, indexed address to);

Solution

1. Step 1: Recall Solidity event syntax

   Indexed parameters are declared as type indexed name inside parentheses.

2. Step 2: Check each option's syntax

   Only event Transfer(address indexed from, address indexed to); correctly places indexed after the type and before the parameter name.

3. Final Answer:

   event Transfer(address indexed from, address indexed to); -> Option B

4. Quick Check:

   Indexed parameters = type indexed name [OK]

Hint: Put 'indexed' right after the type, before the name [OK]

Common Mistakes:

• Placing 'indexed' after the parameter name
• Adding 'indexed' outside parentheses
• Swapping order of 'indexed' and type

3. Given the Solidity code below, what will be the output when the function sendTokens is called?

contract Token {
    event Sent(address indexed from, address indexed to, uint amount);

    function sendTokens(address receiver, uint amount) public {
        emit Sent(msg.sender, receiver, amount);
    }
}

medium

A. An event 'Sent' is emitted with sender, receiver, and amount data

B. A compilation error due to missing return statement

C. Nothing happens because events do not emit automatically

D. The function returns the amount sent

Solution

1. Step 1: Understand event emission in function

   The function calls emit Sent(...) which triggers the event with given parameters.

2. Step 2: Check function behavior

   The function does not return anything but emits the event, so An event 'Sent' is emitted with sender, receiver, and amount data is correct.

3. Final Answer:

   An event 'Sent' is emitted with sender, receiver, and amount data -> Option A

4. Quick Check:

   emit triggers event with data [OK]

Hint: emit keyword triggers event logs during function execution [OK]

Common Mistakes:

• Expecting a return value from event emission
• Thinking events execute code or change state
• Confusing event emission with function return

4. Identify the error in the following Solidity event declaration:

contract Example {
    event LogMessage(string message);

    function log(string memory msg) public {
        emit LogMessage(msg);
    }
}

medium

A. There is no error; the code is correct

B. The event declaration is missing the indexed keyword

C. The event cannot have string type parameters

D. The function parameter name conflicts with a reserved keyword

Solution

1. Step 1: Review event declaration and usage

   The event LogMessage with a string parameter is valid and emitted correctly.

2. Step 2: Check for reserved keyword conflicts

   The parameter name msg is allowed as a variable name; it does not conflict with reserved keywords.

3. Final Answer:

   There is no error; the code is correct -> Option A

4. Quick Check:

   Valid event with string parameter and emit usage [OK]

Hint: Strings are allowed in events; 'msg' is not reserved as variable name [OK]

Common Mistakes:

• Assuming all event parameters must be indexed
• Thinking 'msg' is a reserved keyword variable
• Believing strings cannot be event parameters

5. You want to declare an event Approval that logs the owner, spender, and amount approved. You also want to filter logs by owner and spender efficiently. Which is the best event declaration?

hard

A. event Approval(indexed address owner, indexed address spender, uint amount);

B. event Approval(address owner, address spender, uint indexed amount);

C. event Approval(address owner indexed, address spender indexed, uint amount);

D. event Approval(address indexed owner, address indexed spender, uint amount);

Solution

1. Step 1: Understand indexed parameters for filtering

   Indexed parameters allow efficient filtering in event logs by those fields.

2. Step 2: Check correct syntax and indexing

   event Approval(address indexed owner, address indexed spender, uint amount); correctly indexes owner and spender addresses, allowing filtering; amount is not indexed.

3. Final Answer:

   event Approval(address indexed owner, address indexed spender, uint amount); -> Option D

4. Quick Check:

   Indexed parameters = filterable fields [OK]

Hint: Index addresses to filter events; amount usually not indexed [OK]

Common Mistakes:

• Indexing non-address parameters unnecessarily
• Incorrect syntax for indexed keyword placement
• Indexing parameters in wrong order