diff --git a/docs/contract-consumer-boundaries.md b/docs/contract-consumer-boundaries.md index a49f332..7c40005 100644 --- a/docs/contract-consumer-boundaries.md +++ b/docs/contract-consumer-boundaries.md @@ -36,6 +36,41 @@ For any event payload or event name change, contributors should follow this comp For storage key details tied to creator registration metadata and ownership expectations, see [Storage Key Invariants](./storage-key-invariants.md). +## Event field types and Soroban encoding format + +Contract events carry fields encoded in Soroban XDR format. Indexers and consumers need to know the specific type mappings for each field to decode them correctly. + +### register event + +Emitted when a creator is registered via `register_creator`. + +**Topics:** `(Symbol, Address)` +- Index 0: `REGISTER_EVENT_NAME` (Symbol) - Event name identifier +- Index 1: `creator` (Address) - Creator's Stellar address (32 bytes) + +**Data:** `CreatorRegisteredEvent` struct +- `creator` (Address) - Creator's Stellar address (32 bytes) +- `handle` (String) - Creator's handle string (variable length, UTF-8 encoded) +- `supply` (u32) - Initial key supply (32-bit unsigned integer, always 0 at registration) +- `holder_count` (u32) - Initial holder count (32-bit unsigned integer, always 0 at registration) + +**Type notes:** All fields use straightforward Soroban types matching their Rust definitions. The `supply` and `holder_count` fields are zero at registration time and increment with subsequent buy/sell operations. + +### buy event + +Emitted when a key is purchased via `buy_key`. + +**Topics:** `(Symbol, Address, Address)` +- Index 0: `BUY_EVENT_NAME` (Symbol) - Event name identifier +- Index 1: `creator` (Address) - Creator's Stellar address (32 bytes) +- Index 2: `buyer` (Address) - Buyer's Stellar address (32 bytes) + +**Data:** Tuple `(u32, i128)` +- `supply` (u32) - New total supply after purchase (32-bit unsigned integer) +- `payment` (i128) - Payment amount in stroops (128-bit signed integer) + +**Type notes:** The `payment` field uses `i128` (signed 128-bit integer) to represent the payment amount in stroops (the smallest unit of XLM, 1 stroop = 0.0000001 XLM). This matches Soroban's standard token amount representation. The `supply` field is a `u32` representing the total number of keys minted for the creator. + ## Compatibility expectations | Change | Expectation |