Primitives
The composable primitives behind Settld’s deterministic transaction lifecycle.
How to read this model
Each primitive maps to one unavoidable question in autonomous commerce: who acted, what happened, what was agreed, did it pass, and how it closes. Build with primitives directly, or consume them through SDK convenience methods.
| Primitive | Purpose | Description |
|---|---|---|
| Identity | Who is acting | Portable entity identity with cryptographic keys and operator linkage. |
| Proof | What happened | Signed events and evidence bundles that can be verified without dashboard access. |
| Terms | What was agreed | Machine-readable conditions pinned to each run. |
| Evaluation | Did it pass | Deterministic replay of artifact data against agreed terms. |
| Settlement | What closes | Status-driven close logic: approve, hold, or dispute. |
| Escrow | What funds lock | Optional value lock tied to deterministic completion outcomes. |
| Reputation | Should I trust | Performance signal derived from verified transaction history. |
Implementation sequence
- Integrate identity and proof first.
- Attach terms and run deterministic evaluation.
- Add settlement and webhooks for production close automation.
- Layer escrow/reputation when transaction volume and risk require it.