Support for events has arrived in SEP-48 Contract Specs in the XDR shipping with protocol 23, and it is currently deployed on Testnet.

The Rust Soroban SDK has support for it via the contractevent macro in version 23.0.0-rc.2.2:

• https://docs.rs/soroban-sdk/23.0.0-rc.2.2/soroban_sdk/attr.contractevent.html

There are a few opportunities that are now available to the tooling ecosystem with regards to working with events in code and data systems:

1. The opportunity for SDKs to offer binding generation for events, so that given a raw event, and given the .wasm that produced the event containing the spec, tooling can generate parsers that unpack the raw event into a code structure that is self-describing, validated, and easy for developers to use.

2. The opportunity to write binding generation to not just code, but also code generate IDL of alternative file formats, such as protobuf, so that any contract can be converted with no custom code.

3. The opportunity to generate processors for the Go SDK's Ingest capability, or to hook these generated types into a generic events processor, such that processes like the Token Transfer Processor could be generated for any contract, or groups of contracts.

There's also an opportunity to present spec informed views of events in tooling UIs, such as Lab (stellar/laboratory#1512), Stellar CLI (stellar/stellar-cli#2086), OpenZeppelin Monitor (OpenZeppelin/openzeppelin-monitor#318), etc, but those are being discussed on their respective issues and this conversation here is intended to focus on coding primitives.

cc @stellar/platform-eng @stellar/data-eng @stellar/devx

To illustrate with an example:

An approve event as defined in SEP-41, can be defined in the upcoming SDK with:

#[contractevent(data_format = "vec")]
pub struct Approve {
    #[topic]
    pub from: Address,
    #[topic]
    pub spender: Address,
    pub amount: i128,
    pub live_until_ledger: u32,
}

The raw event emitted in ledger close meta contains all the values, but none, or little of, the structure:

{
  "ext": "v0",
  "contract_id": "CBUZJXHZ6PBS2YR3SEJZ3CIGMQBYP6367D3KQAR2NB3U2I5AOWLC4DU2",
  "type_": "contract",
  "body": {
    "v0": {
      "topics": [
        { "symbol": "approve" },
        { "address": "GBMBVAHBE6D4AJXJJVTBQTVU4G7SN4FEIJOL5YTOHZ4WCUMKQ52ANL2B" },
        { "address": "GCAN5IE4PWMWSMFZCYQRCJM73MCPG5JD2R7WF5HIFHHHDBWSDJFIWX7X" }
      ],
      "data": {
        "vec": [
          { "i128": "10000" },
          { "u32": 1998742 }
        ]
      }
    }
  }
}

Contract specs include the shape and structure of the event:

{
  "event_v0": {
    "name": "approve",
    "prefix_topics": ["approve"],
    "params": [
      { "name": "from", "type_":"address", "location": "topic_list" },
      { "name": "spender", "type_":"address", "location": "topic_list" },
      { "name": "amount", "type_":"i128", "location": "data" },
      { "name": "live_until_ledger", "type_":"u32", "location": "data" }
    ],
    "data_format": "vec"
  }
}

Which would allow SDKs, such as the JS SDK, Go SDK, Python SDK, etc to offer code generated types that can parse the raw contract event into the code structure:

type Approve struct {
    From            Address
    Spender         Address
    Amount          Int128
    LiveUntilLedger uint32
}

Or, for applications that would like to parse the events into other file formats, generating protobuf, or other IDLs along with the parsing logic.

message Approve {
  string from = 1;
  string spender = 2;
  string amount = 3;
  int live_until_ledger = 4;
}

The intent of this issue is to determine if adding the above types of code generation to SDKs make sense, all or some, which ones, and to brainstorm other ways SDKs or data tooling could make use of them.

There's an example prototype for how to do matching of raw contract events to specs here:

• https://github.com/leighmcculloch/exp-sep48-derived-events-example