Integration Paths¶
TAO Intents has two integration surfaces:
- Smart contracts. Partners and users open intents by calling
FullSettler.open(...)directly on-chain. This is the path that escrows funds, emits the canonical order event, and starts settlement. - Service API. The API is a companion service for quotes, preflight checks, optional post-broadcast notifications, mirrored status reads, and pending/expired intent views.
The Service API does not create, sign, relay, or submit transactions. It does not custody funds. Chain events and contract state are the source of truth; API status is a mirror or helper view over that state.
The Service API also records wallet acceptance of the current Terms & Conditions. This is an off-chain compliance gate for the optional post-broadcast notification endpoint; it is separate from TAO Public API bearer authentication and is not part of the smart contract lifecycle. User identity and funds are still established by the on-chain open() transaction.
Task decision table¶
| Task | Use | Notes |
|---|---|---|
| Open intent | Contract Integration | Call FullSettler.open(...) on the origin chain. |
| Sign/broadcast transaction | Your wallet or transaction stack | The Service API does not sign, relay, or submit transactions. |
| Get quote | Service API | Use before building the on-chain order. |
| Discover supported chains, tokens, deployments | Deployment/config data | Deployment and route metadata is supplied through the current TAO Intents deployment/configuration source for the target environment. |
| Accept current Terms & Conditions | Service API | SIWE-based, per-wallet, versioned acceptance before using the optional notification endpoint. |
| Track status | Contracts + Service API mirror | The API provides mirrored status reads; contracts and events remain canonical. |
| Notify after broadcast | Service API | Optional helper after you broadcast the on-chain transaction yourself; requires current T&C acceptance for userAddress. |
| Verify source of truth | Contracts and chain events | Open events and contract state are authoritative. |
Recommended flow¶
- Get deployment/config data for the supported origin chain, destination chain, tokens, and
FullSettleraddress. - Request a quote or run preflight checks through the Service API.
- If you plan to use the optional notification endpoint, check
GET /intents/v1/tc/status?walletAddress=...; if needed, get a nonce, have the wallet sign a SIWE message with resourcetao-tc:vN, and submit it toPOST /intents/v1/tc/accept. - Build the
OnchainCrossChainOrderfor the quoted route. - Have the user sign and broadcast a transaction that calls
FullSettler.open(...)directly on-chain. - Store the transaction hash and emitted
orderIdfrom theOpenevent. - Optionally notify the Service API after broadcast so API status can update sooner. If the wallet has not accepted the current T&C version,
POST /intents/v1/intentsreturns403 TC_NOT_ACCEPTEDwithacceptedVersionandcurrentTcVersion. - Track progress through chain events/contracts, using mirrored API status reads as a companion view.
Where to go next¶
- Contract Integration: how to call
FullSettler.open(...)and encode orders. - Service API Reference: documented endpoints and schemas.