ENTITY Exchange API
The adoption layer exposes a compact exchange-facing API over the larger ENTITY market engine. It preserves the market lifecycle while keeping rights, authority, evidence and settlement boundaries explicit.
Adoption routes
| Route | Purpose | Developer responsibility |
|---|---|---|
POST /instruments | Define or submit a rights instrument. | Issuer must control the underlying object/right; instrument terms must be explicit. |
POST /listings | Publish an instrument listing. | Bind venue/instrument to disclosure evidence and lot/tick constraints. |
POST /orders | Submit a signed order. | Use canonical signed intent, replay-resistant nonce and valid participant authority/balance. |
POST /rfq | Create a request for quote. | Specify venue, instrument, side, quantity and expiry; quotes remain separate signed records. |
POST /auctions | Execute the call-auction profile. | Preserve deterministic execution evidence and market-policy constraints. |
POST /settlements | Settle an executed trade. | Do not infer external money movement; use authorized verification/payment evidence where required. |
GET /positions | Query rights-unit balances and entitlements. | Interpret positions as governed rights state, not ownership of source bytes by default. |
GET /market-data | Query venue market observations. | Market observations are evidence/observations, not accounting fair value or legal determinations. |
Execution models
ORDER_BOOK
Signed BUY/SELL orders with limit price, time-in-force, quantity, remaining quantity, status, receipt time and cancellation records.
CALL_AUCTION
Batch/call-auction execution profile for venue-controlled price discovery under explicit policy.
RFQ
Signed requests, signed quotes, expiry and explicit acceptance for negotiated execution without losing machine-verifiable lineage.
Instrument classes
SPOT_LICENSESUBSCRIPTIONCOMPUTE_TO_DATAPROCUREMENTCONTRIBUTIONSECONDARY_LICENSE
Market state developers can query or preserve
Under the API surface the exchange engine maintains venues, instruments, balances, listings, disclosures, orders, trades, clearing, entitlements, usage, revenue rules/rule sets, trade-revenue bindings, surveillance, RFQs, quotes, acceptances, cancellations, settlement-verifier authorizations and payment attestations.
Core invariants
- Rights are traded, not byte scarcity. A dataset can remain copyable while bounded economic interests remain scarce.
- Venue is not authority. Operating infrastructure does not replace issuer/holder/controller authority.
- Replay must fail closed. Signed market intents use nonces and canonical shapes.
- Execution is not settlement. A trade can be valid while external payment remains unverified.
- Payment evidence is scoped. Payment attestations require an authorized settlement verifier and remain attestations rather than absolute truth.
- Revenue terms are explicit. Revenue allocations and originator participation cannot be created retroactively by provenance alone.
- Recovery preserves the complete market. Economic state must be recoverable as a logical signed system, not merely copied as database bytes.
SDK status
The adoption SDK reports the market engine as preserved, exposes the market lifecycle above and surfaces whether the engine maintains the invariant that rights—not information bytes—are the traded economic object.