> For the complete documentation index, see [llms.txt](https://ola-foundation.gitbook.io/ola-lang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ola-foundation.gitbook.io/ola-lang/ola-language/event.md).

# Event

In Ola, contracts can emit events that signal that changes have occurred. For example, a Ola contract could emit a Deposit event, or BetPlaced in a poker game. These events are stored in the blockchain transaction log, so they become part of the permanent record. From Solidity’s perspective, you can emit events but you cannot access events on the chain.

Once those events are added to the chain, an off-chain application can listen for events. For example, the Web3.js interface has a subscribe() function.

An event has two parts. First, there is a limited set of topics. Usually there are no more than 3 topics, and each of those has a fixed length of 32 bytes. They are there so that an application listening for events can easily filter for particular types of events, without needing to do any decoding. There is also a data section of variable length bytes, which is ABI encoded. To decode this part, the ABI for the event must be known.

From Ola language perspective, an event has a name, and zero or more fields. The fields can either be `indexed` or not. `indexed` fields are stored as topics, so there can only be a limited number of `indexed` fields. The other fields are stored in the data section of the event. The event name does not need to be unique; just like functions, they can be overloaded as long as the fields are of different types, or the event has a different number of arguments.

The first topic is used to identify the event, this is a hash of the event signature, also known as the selector. If the event is declared `anonymous` then this is omitted, and an additional `indexed` field is available.

An event can be declared in a contract

```solidity
contract Signer {
  event CounterpartySigned (
      address indexed party,
      address counter_party,
      u32 contract_no
  );
    fn sign(address counter_party, u32 contract_no) {
        emit CounterpartySigned(contract_address(), counter_party, contract_no);
    }
}
```

In the transaction log, the first topic of an event is the poseidon hash of the signature of the event. The signature is the event name, followed by the fields types in a comma separated list in parentheses. So the first topic for the second UserModified event would be the keccak256 hash of `CounterpartySigned(address,address,u32)`.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ola-foundation.gitbook.io/ola-lang/ola-language/event.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.