Walk through a rights market
ENTITY does not need to make information bytes scarce in order to create an economic instrument. The scarce/governed object can be a bounded right: inspect, query, train, derive, redistribute, commercialize, execute or another explicitly defined permission.
1. Start from a governed object
Use an existing ENTITY/BTDU object whose source, controller and evidence context are known. Do not infer economic rights merely because the object exists in BTDU.
2. Define the rights instrument
The adoption surface exposes POST /instruments. The issuer must control the underlying object/right and the terms must be explicit.
Choose the appropriate instrument class: SPOT_LICENSE, SUBSCRIPTION, COMPUTE_TO_DATA, PROCUREMENT, CONTRIBUTION or SECONDARY_LICENSE.
| Field/category to establish | Question it answers |
|---|---|
| Underlying object/right | What governed interest is being instrumented? |
| Issuer/controller | Who has authority to issue it? |
| Scope | Which actions are allowed? |
| Constraints | Purpose, time, quantity, geography, model, downstream use? |
| Transfer/economic terms | How can the right be acquired, transferred or participated in? |
3. List with disclosure
Use POST /listings to publish the instrument. Bind the venue/instrument to disclosure evidence and lot/tick constraints. A listing should make the rights and restrictions inspectable before execution.
4. Choose an execution model
ORDER_BOOK
Submit canonical signed BUY/SELL orders through POST /orders. Orders use replay-resistant nonces and explicit quantity/price/time-in-force state.
RFQ
Create a request with POST /rfq, collect signed quotes, then explicitly accept one before expiry.
CALL_AUCTION
Use POST /auctions for deterministic batch price discovery under venue policy.
Whichever path is used, the venue does not become the issuer/controller simply because it operates execution infrastructure.
5. Trade and clear
A valid execution produces trade/clearing state under the engine's authority, balance and replay rules. At this point there may be a valid market obligation even though no external money movement has yet been verified.
6. Keep settlement evidence separate
POST /settlements records settlement for an executed trade. Where external payment evidence is required, use authorized settlement-verifier/payment-attestation records.
7. Query entitlement and record usage
Use GET /positions for rights-unit balances/entitlements. Once a participant exercises the granted right, record usage so the lineage can connect entitlement → use → derived output → economic consequence.
GET /market-data can expose venue observations, but market observations are not automatically accounting fair value or legal determinations.
8. Check the invariant
The adoption SDK exposes market_status() and reports whether the engine preserves the invariant that rights are traded, not information bytes. It also exposes exchange_routes() for the public adoption surface.
9. Success criteria
- The underlying governed object/right and issuer authority are explicit.
- The instrument and listing disclose scope/constraints.
- The execution path is signed and replay-resistant.
- Trade/clearing state is not mislabeled as external payment.
- Entitlement and usage remain machine-linked to the instrument.
- Any revenue/participation terms were explicit rather than inferred retroactively from provenance.