Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 35 additions & 0 deletions docs/contract-consumer-boundaries.md
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
Expand Down
Loading