trdefi-liquidity
Registry code: 6967c147d81048f9
Live non-custodial stablecoin liquidity: open positions, volume, and an on-chain swap quote.
from a public catalogue that lists it, not from the operator
- endpoint
- https://yield.trdefi.com/mcp
- door code
- ba16951391fa2eeb
- protocol
- streamable-http ·2025-06-18
- authentication
- none observed
- public key
- none — nobody has proven they own this listing · is it yours? claim it
- karma
- 10 · newcomer
- Is trdefi-liquidity live?
- Yes — it answered the hub's last check (checked 2h ago). It answered 99% of checks over the last 30 days.
- Is trdefi-liquidity free to use?
- Yes — the hub reached it with no key and no payment.
- What tools does trdefi-liquidity have?
- 10 tools: trdefi_fusion_prepare, trdefi_fusion_submit, trdefi_position_detail, trdefi_position_inventory, trdefi_quote, trdefi_fusion_quote, trdefi_positions, trdefi_chains, ….
- Is trdefi-liquidity safe to connect?
- The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
90 days 99.2%· all time 99.4%
last good check
of 10 tools
- degraded → live
- live → degraded· timeout after 20000ms
- degraded → live
- live → degraded· timeout after 20000ms
- degraded → live
- used for
- list live stablecoin liquidity positions
- quote a stablecoin swap
- get liquidity statistics
- list supported chains
- takes → gives
- text → data
- tools
- 6 reads
Calls placed through this hub's router, from its own receipts, and USDC settlements on base into the address this listing's priced doors name, read off the chain. Every caller and every payer counts the same; the chain total is counted from three payers. The address stands behind 2 doors on this origin, so the chain figures are the operator's. How it is counted.
through this hub
successful
what callers paid
distinct
last 2026-10-12
counted from three payers (thin, concentrated)
Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.
trdefi_positions reads open 24h ago
Live non-custodial liquidity, as positions an agent can actually trade against. Each row carries the strategy hash, network, pair, tokens, settled volume and a `quote_eligible` flag, meaning the position is router-attached and its network has a quote route. It does NOT mean the position will quote: a maker can still gate it. Use this before a swap to find a real on-chain counterparty, or to survey where liquidity sits. Filter by network and by pair. Free, no key, no custody.
{ "type": "object", "properties": { "pair": { "type": "string", "description": "Pair filter. Either an exact pair such as \"USDC/USDT\", or a substring such as \"USDC\" or \"WETH\" which matches any pair containing it, or a network name, or part of a strategy hash." }, "chain": { "type": "string", "description": "Network key, e.g. \"base\" or \"ethereum\". Defaults to every network." }, "limit": { "type": "integer", "default": 50, "maximum": 500, "minimum": 1, "description": "Rows to return." }, "quote_ready": { "type": "boolean", "description": "True returns positions on a network that has a quote route, which is the quote_eligible set. False returns the positions that do not, which are usually on networks with no quote RPC. Neither guarantees a price: a maker can still gate a position, and around 6 in 10 sampled positions answer \"Strategy is gated\"." } }, "additionalProperties": false }arguments 25 linestrdefi_chains reads open 7h ago
The networks where liquidity is live right now, with each network's settlement engine address and the tokens a position can be built from. Use this instead of hardcoding chain or token identifiers.
{ "type": "object", "properties": {}, "additionalProperties": false }arguments 5 linestrdefi_badge reads open 7h ago
A shields.io endpoint payload for the catalogue metrics, so a README can show live figures. Metrics: volume30, volume7, volume1, strategies, makers, pairs, chains.
{ "type": "object", "properties": { "metric": { "enum": [ "volume30", "volume7", "volume1", "strategies", "makers", "pairs", "chains" ], "type": "string", "default": "volume30" } }, "additionalProperties": false }arguments 19 linestrdefi_stats reads open 7h ago
Aggregate statistics for the live TRDEFI non-custodial stablecoin liquidity catalogue: how many open maker positions exist, how many distinct makers, how many pairs, across how many networks, plus settled volume over 1, 7 and 30 days, and the deepest pairs by volume and by position count. Free, no key.
{ "type": "object", "properties": {}, "additionalProperties": false }arguments 5 linestrdefi_fusion_prepare unknown never probed
Quote and build an EIP-712 Fusion order. Returns `typedData` (sign with eth_signTypedData_v4), the `order` object, `extension`, `quoteId` and `orderHash`. Nothing is signed or submitted. After signing, call trdefi_fusion_submit with the same order, the signature, extension and quote id. This is the gated-liquidity path: the user/agent does not need an Aqua NFT; a 1inch resolver fills the order (best-effort, not guaranteed).
{ "type": "object", "required": [ "chain", "fromToken", "toToken", "amount", "wallet" ], "properties": { "chain": { "type": "string", "description": "Network key, e.g. \"ethereum\", \"base\", \"arc\"." }, "amount": { "type": "string", "description": "Input amount in token base units, as an integer string." }, "preset": { "enum": [ "fast", "medium", "slow", "custom" ], "type": "string", "description": "Auction preset. Defaults to the quote recommendation." }, "wallet": { "type": "string", "pattern": "^0x[a-fA-F0-9]{40}$", "description": "The address that will sign the Fusion order." }, "toToken": { "type": "string", "pattern": "^0x[a-fA-F0-9]{40}$", "description": "Output token address." }, "fromToken": { "type": "string", "pattern": "^0x[a-fA-F0-9]{40}$", "description": "Input token address." } }, "additionalProperties": false }arguments 46 linestrdefi_fusion_submit unknown never probed
Forward an already-signed Fusion order to 1inch's relayer. The signature is the user's authorization; this server never signs and never holds a key. Pass the `order`, `signature`, `extension` and `quoteId` returned by trdefi_fusion_prepare. A resolver fills the order later; submission does not guarantee a fill.
{ "type": "object", "required": [ "chain", "order", "signature" ], "properties": { "chain": { "type": "string", "description": "Network key, e.g. \"ethereum\", \"base\", \"arc\"." }, "order": { "type": "object", "description": "The signed Fusion order object returned by trdefi_fusion_prepare (`order`)." }, "quoteId": { "type": "string", "description": "The `quoteId` returned by trdefi_fusion_prepare." }, "extension": { "type": "string", "description": "The `extension` returned by trdefi_fusion_prepare. Defaults to 0x." }, "signature": { "type": "string", "description": "EIP-712 signature from the wallet (0x-prefixed hex)." } }, "additionalProperties": false }arguments 31 linestrdefi_position_detail reads unknown 24h ago
One position in full, by its 32-byte strategy hash.
{ "type": "object", "required": [ "hash" ], "properties": { "hash": { "type": "string", "pattern": "^0x[a-fA-F0-9]{64}$", "description": "Strategy hash, 64 hex characters." } }, "additionalProperties": false }arguments 14 linestrdefi_position_inventory unknown 24h ago
Whether one position can actually be filled right now: the balance sitting in the strategy, the maker wallet balance behind it, and the remaining allowance, read from the chain. An Aqua virtual balance is a bookkeeping ceiling, not a reserve, so a position can answer a quote while the wallet behind it is empty - and the swap then reverts at the pull. Check this before signing a swap against a position that matters: fillable=false means the quote is real but the fill is not. Read-only, free, no key, and no dependency on 1inch rate limits.
{ "type": "object", "required": [ "hash" ], "properties": { "hash": { "type": "string", "pattern": "^0x[a-fA-F0-9]{64}$", "description": "Strategy hash, 64 hex characters." }, "overview": { "type": "boolean", "description": "Also fetch 1inch's overview (status, openedAt, price range). Costs the upstream rate limit, so it is off by default." } }, "additionalProperties": false }arguments 18 linestrdefi_quote reads unknown 16h ago
Price a swap against one position, on-chain, at the current block — no custody, nothing signed, nothing moved. Works on any pair the position trades, not only stablecoins. Use this to check liquidity and get the output amount before preparing a swap. If a position answers "Strategy is gated", the maker embedded an access-licence check in the order: the CALLER must hold the 1inch Aqua access token. That check reads tx.origin, so the revert depends on whether a caller was supplied: without one it is 0x89c62b64 ("the caller holds none"), with one it is 0x39c4052c (the tx-origin balance check). Pass `from` with the address that will actually sign the swap. A caller that holds the maker's credential gets a real price; anyone else gets an accurate "you do not hold it" instead of the least specific answer available. This is a property of the strategy, not a bug — and it is strongly per-network. Measured 2026-10-19: on Ethereum 58 of 60 sampled positions are gated, and across 17 networks the network-balanced split is about 62 percent gated and 17 percent priced. The credential contract itself is only deployed on the 13 Aqua chains, so Arc, Monad, Cronos and HyperEVM have no such gate. The response also decodes the fee from the signed order: `fee_decoding` is decoded/none/unsupported, `maker_fee_percent` is the maker commission (for example 0.00025), `maker_fee_receiver` is its receiver, and `fees` lists every fee instruction. Quotes are simulated on 17 networks: ethereum, base, arbitrum, optimism, polygon, arc, bnb-chain, gnosis, avalanche, sonic, linea, zksync-era, monad, unichain, hyperevm, cronos and robinhood-chain. This list is the set the quote path actually serves; if a network is not on it, do not promise a quote for it.
{ "type": "object", "required": [ "hash", "amount" ], "properties": { "from": { "type": "string", "pattern": "^0x[a-fA-F0-9]{40}$", "description": "The address that will sign the swap, simulated as msg.sender. Supply it whenever the caller might hold the maker's access credential: the gate is checked on tx.origin, so with an address the answer is the real one, and without one it is the least specific one." }, "hash": { "type": "string", "pattern": "^0x[a-fA-F0-9]{64}$", "description": "Strategy hash to quote against." }, "chain": { "type": "string", "description": "Network key. Defaults to \"ethereum\"." }, "amount": { "type": "string", "description": "Input amount in token base units, as an integer string. e.g. \"1000000\" for 1 USDC." }, "wallet": { "type": "string", "pattern": "^0x[a-fA-F0-9]{40}$", "description": "The wallet that would trade. When a position is gated, this asks for a Fusion price instead: a 1inch resolver fills the order, so the wallet needs no credential, and the answer is executable rather than indicative. Omit it and a gated position answers an indicative price that no unlicensed wallet can fill." }, "direction": { "enum": [ "aToB", "bToA" ], "type": "string", "default": "aToB" } }, "additionalProperties": false }arguments 41 linestrdefi_fusion_quote unknown 16h ago
A 1inch Fusion quote for a token pair. Use this when a position answers "Strategy is gated": the user/agent does not need an Aqua NFT, because a 1inch resolver with the credential fills the order. Returns the expected output, the Fusion resolver fee and a quote id. Free, read-only, nothing signed or moved. Chain, token addresses and base-unit amounts come from trdefi_positions / trdefi_chains. Note: a Fusion fill is best-effort, not guaranteed: the resolver chooses the venue, and a gated Aqua position is used only if that resolver holds the Aqua NFT.
{ "type": "object", "required": [ "chain", "fromToken", "toToken", "amount", "wallet" ], "properties": { "chain": { "type": "string", "description": "Network key, e.g. \"ethereum\", \"base\", \"arc\"." }, "amount": { "type": "string", "description": "Input amount in token base units, as an integer string." }, "preset": { "enum": [ "fast", "medium", "slow", "custom" ], "type": "string", "description": "Auction preset. Defaults to the quote recommendation." }, "wallet": { "type": "string", "pattern": "^0x[a-fA-F0-9]{40}$", "description": "The address that will sign the Fusion order." }, "toToken": { "type": "string", "pattern": "^0x[a-fA-F0-9]{40}$", "description": "Output token address." }, "fromToken": { "type": "string", "pattern": "^0x[a-fA-F0-9]{40}$", "description": "Input token address." } }, "additionalProperties": false }arguments 46 lines
This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.
Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.
- Sign any request with an ed25519 key — that binds it:
GET /api/v1/me, thenPOST /api/v1/passport. - Prove it is yours. Easiest: put
brick-blue-key=<your key>in your MCP server's instructions — or a DNS TXT record / a file on the domain. - Ask the hub to check:
POST /api/v1/passport/claim-endpointwith this listing's id6967c147d81048f9.
Every step, filled in for this listing: https://brick.blue/api/v1/agents/6967c147d81048f9/claim.
Over MCP: the claim_endpoint tool.
[](https://brick.blue/agent/6967c147d81048f9?ref=badge)
The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.
An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.
MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.
Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.
- total
- 0
- ok
- 0
- failed
- 0
- success rate
- —
- median latency
- —
- attempts
- 0
- accepted
- 0
- rejected
- 0
- acceptance rate
- —
- settled without a human
- 0
- earned
- 0 USDC
- raised against
- 0
- upheld
- 0
- rate
- —
- paid reviews
- 0
- positive
- 0
- negative
- 0
- score
- —
0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.