Version: 1.1 · Effective: 2026-09-25 · Applies to: https://yield.trdefi.com/api/ and https://yield.trdefi.com/v1/

This document states what the API is, what it is not, where its data comes from, what we guarantee, and what we explicitly do not. It is the foundation the other two documents rest on: read this first.

---

1 · What this API is

A public, read-first API over the live non-custodial liquidity catalogue that TRDEFI normalises across supported networks, plus — for accredited integrators holding a key — a prepare-only write path that turns an intent into unsigned transactions for the client's own wallet to sign.

Concretely, it answers five questions:

1. What is open right now? — how many liquidity positions are quoting, on which networks, in which pairs, by how many distinct makers.
2. What has actually settled? — traded volume over 24 hours, 7 days and 30 days, per pair and per chain, derived from on-chain fills.
3. What would a trade look like? — an indicative quote. Nothing is signed and nothing moves.
4. Is a given chain or pair live? — the live catalog, so a client never hardcodes identifiers.
5. What exactly would I have to sign? — the write path returns the complete, unsigned transaction set for a position, fee included, for the client's wallet to sign or reject.

2 · What this API is not

Stated plainly, because an integration decision may depend on it:

It is not	Because
A custody service	Nothing in the API holds, moves or controls funds. There is no deposit step anywhere.
A signing service	We never sign. There is no signing grant, no delegated key, no moment at which a credential of ours produces a signature. The write path prepares; the client's wallet signs.
A broadcaster	We never submit a transaction on a client's behalf. Broadcast is the client's call, from the client's own address.
A trading venue of record	It reports positions and volume; it does not settle trades. Settlement is on-chain.
A price oracle	Quotes are indicative and sourced from a live catalogue. They are not a reference rate and must not be used as one.
A financial product	No returns are offered, promised or implied. Figures describe activity that has already happened.
A data warehouse	It exposes aggregates and lists, not bulk row access. There is no SQL endpoint and no export of raw rows.

3 · Data sources and freshness

Every figure is derived, never entered by hand.

Layer	Source	Refresh
Open positions	The public liquidity registry on each supported network, read directly from the chain	On a scheduled refresh; the catalogue is re-listed and traded volume recomputed, stalest rows first
Settled volume	On-chain fill events, aggregated	Same schedule
Aggregates (/api/stats, /api/chains)	Pre-aggregated roll-ups computed from the above	Same schedule
Quotes	Live read against the routing layer	Per request
Prepared transactions	Built at request time against the current block and price	Per request; expires

Freshness is part of the response, not a footnote. meta.freshnessSeconds states how old the underlying roll-up is, and meta.cached says whether the reply came from our short-lived cache. A client that needs to know whether a number is a minute or three hours old does not have to guess.

What we commit to: we disclose the age. What we do not promise: that the roll-up is second-fresh. It is not, and treating it as a real-time feed is a misuse of the API.

4 · Custody and security model

The API is designed so that a compromised API credential cannot move value. This is not a promise about our operational discipline; it follows from the architecture.

Property	Value
Token custody	The owner's wallet, at all times
Value the read API can move	None
Credential required to read	None
Credential required to prepare	An API key, held server-side by the client
Value the write path can move	None. It returns unsigned transactions.
What can actually move value	Only a signature from the client's own wallet, against a bounded, revocable allowance
Lock-up	None
Exit	Owner-initiated, single transaction
Key material of clients	Never held, never requested
Signatures produced by us	None, ever

Three further commitments:

• There is no signing grant to steal. A design in which a partner's credential can authorise a transfer has a single point of failure whose blast radius is the partner's balance. Ours does not: the credential prepares, and preparation alone is inert.
• Write paths are origin-restricted and chain-asserted. A write request from an origin we do not recognise is refused, and a request naming an unexpected network is refused before anything is prepared. A misconfigured client cannot cause a mainnet operation by accident.
• No upstream vendor leaks. Errors carry our own stable codes. An upstream provider's name or status code never appears in a public response.

5 · Fees

Every position created through TRDEFI carries a 0.05 % protocol fee embedded in the signed order data — the same whether the position is created through the web app or the API.

Question	Answer
How much?	0.05 % of the traded amount
Where does it go?	It is written into the order the maker signs and is executed on-chain by the position itself
Can an integrator remove it?	No. There is no parameter, tier or agreement that waives it.
Does it apply to reading data?	No. Reading is free and always has been.
Does it apply to existing positions?	No. Terms are immutable on-chain; positions created earlier keep their original terms.
Is it disclosed before signing?	Yes — in the fee object of POST /v1/positions, in the web app before confirmation, and in Overall Scheme Part 7.

The fee is part of the position, not a separate charge. An integrator that resells access passes it through; it is not a cost we absorb on their behalf.

6 · Scope boundaries

In scope — we own this:

• Correctness of the aggregates, given the data the chains expose.
• The stability of the contract: request ids, rate-limit headers, the error envelope, versioning.
• The accuracy of the freshness disclosure.
• Availability and latency within the SLO below.
• The integrity of the write path's access controls — that a request from an unknown origin, an unknown key or an unexpected chain is refused before anything is prepared.
• Correctness of the prepared transaction set given the intent we were sent: the right targets, the right amounts, the fee included.

Out of scope — we do not own this:

• Whether the client signs, and when. A prepared transaction that is never signed has no effect.
• The behaviour, liveness or correctness of any external chain or RPC endpoint.
• The correctness of third-party contract addresses or token metadata.
• Fitness for a particular trading or accounting purpose. Data is provided for information and integration; a client making financial decisions must verify independently on-chain.
• Another party's interpretation of the figures. A "maker count" is a count of distinct addresses; it is not a statement about who or what is behind them.

7 · Service level

Property	Target
Availability (read surface)	99.5 % monthly, measured on 2xx + 4xx (client errors are not outages)
Latency (p50 / p95)	Under 400 ms / under 1.5 s for /api/stats
Latency (POST /v1/positions)	Under 1.5 s p95 to return a prepared transaction set
Cache freshness	meta.cached is honest; cached replies are at most 60 s old
Incident communication	Status note on this domain, and the request id quoted in the envelope
Breaking-change notice	Minimum 90 days, published on the deprecation calendar

The SLO applies to the read surface and to preparation. Anything after preparation — signing, broadcast, inclusion on-chain — is outside it, because none of it is ours to control.

8 · Responsibility matrix

Concern	TRDEFI	Client
Holding funds and keys	—	Owns
Preparing a correct, complete, fee-inclusive transaction set	Owns	—
Signing	Never signs	Owns
Broadcasting	Never broadcasts	Owns
Authorising value movement	Provides the bounded allowance mechanism the client's wallet signs	Signs
Aggregate correctness, given chain data	Owns	—
Independent verification before acting on a figure	—	Owns
Contract stability (envelope, versioning, ids)	Owns	—
Handling a 4xx correctly	Provides stable codes	Owns
Staying inside the advertised rate limit	Advertises the limit on every reply	Owns
Regulatory position in the client's jurisdiction	Provides facts about its own operation	Owns

9 · Definitions

• Position / strategy — a maker's declared intent to quote a pair, backed by an allowance. No funds are transferred to create it.
• Prepare — to compute and return the complete set of unsigned transactions required to create a position. It changes nothing and is not a signature, a broadcast or a reservation.
• Prepared transaction — the complete set of unsigned transactions for a position, with the fee already embedded. It is inert until a wallet signs it and a broadcaster submits it, and it holds no reservation of any kind.
• Freshness — the age of the underlying roll-up, in seconds, disclosed in meta.
• Settled volume — the notional value of fills that have occurred on-chain and are visible in fill events.
• Bucket — a named rate-limit scope (see General Rules §4).
• Protocol fee — the 0.05 % embedded in every newly created position's signed order data (§5).
• Read surface — every GET endpoint documented in Overall Scheme Parts 2. It cannot sign or transfer.
• Write path — POST /v1/positions. Credentialed, origin-restricted, and able to prepare but never to sign.

---

TRDEFI Ltd, London, United Kingdom. This document describes a software interface. It is not financial advice, and nothing in it constitutes an offer to sell or a solicitation to buy any security or financial product.