Fail-closed safe-to-pay verdicts on Base: known-bad wallets, look-alike tokens, repeat rug funders.
| Endpoint | https://biii-production.up.railway.app/mcp (streamable-http) |
|---|---|
| Registry version | 0.2.1 |
| Now | 29 tools · grade F (46) · pin ts_a0460b8260f74c6b68fe85f61f33f13d · protocol 2024-11-05 |
| First / last listed | 2026-11-05 02:05 UTC / 2026-11-05 02:05 UTC |
| Grade over time | 2026-11-05: F (46), 29 tools |
Is this your server? Own a server? ToolFit hosted watch re-checks it every 24 h ($0.25 per 30 days) or 6 h ($0.60) and sends you an HMAC-signed webhook when its tools or grade change: POST https://api.youraitools.co/toolfit/v1/watch. To opt out, see About & opt-out.
Tools: till_vet_merchant till_create_charge till_check_payment till_trust till_create_invoice till_check_invoice till_vet_asset till_vet_meme till_receipt till_roll till_export till_meter till_floor till_resolve till_kya till_authorize till_rug_powers till_launch_funder till_b20_authentic till_trace_theft till_recovery_offer till_vet_approach till_open_approvals till_watch_wallet till_vet_agent till_seed_exposure till_key_exposure till_verify_delivery till_funder_history
till_vet_merchant | MainStreet safe-to-pay preflight on a merchant address. Returns the hosted oracle read (advisory) AND a LOCAL CLASSIFIER verdict computed on this node via trust-core (pure, zero-oracle) — so a verdict holds even if the oracle is down. Vet the RECIPIENT before paying. params: address*, resourceUrl |
till_create_charge | Create a USDC-on-Base charge for a real-world merchant. Returns the charge + the EIP-681 payment URI your OWN wallet must execute (basetill holds no key, moves no funds). params: to*, amountUsd*, label, orderId |
till_check_payment | Watch Base for the USDC transfer paying a charge and verify it FIELD-FOR-FIELD (wrong chain/token/recipient/underpay/unconfirmed = NOT paid). Only the chain says paid — verification is chain-only and never depends on any trust signal. Pass withTrust:true to ALSO get the payee's advisory MainStreet trust in the same call (advisory, never changes the paid verdict). params: to*, amountMicro*, lookbackBlocks, withTrust |
till_trust | The TRUST TRIANGLE in one call: composes reputation, standing (LAWBOR proven history, if BIII_LAWBOR_URL set) and settlement (on-chain, if amountMicro given) into ONE verdict (unsafe/unknown/trusted/settled). Reputation is shown as TWO LENSES kept SEPARATE, never merged: `local` = this node's known-bad screen against public lists (no network, decisive — a BLOCK overrides everything) and `oracle` = params: counterparty*, amountMicro, rail, resourceUrl, agentId, erc8004Summary, erc8004TrustedClients |
till_create_invoice | Create a Web2-style INVOICE (number, line items, due date, bill-to) on the SAME non-custodial registry: paid by the same EIP-681 intent, verified by the same chain discipline, recorded in the same provable till roll. Returns the invoice + a human-readable bill (EN/FR) + the payment URI. params: to*, lineItems*, number, billTo, merchantName, dueDateMs, lang, rail |
till_check_invoice | Check an invoice against the chain: settled (paid on-chain, field-for-field) / overdue / issued / not_observable (settles on a rail BIII cannot read — ask the merchant's books, never assume unpaid). If settled, returns the receipt for the registry. params: to*, totalMicro*, number, dueDateMs, merchantName, rail, lookbackBlocks |
till_vet_asset | Is a TOKENIZED ASSET (stock/treasury/RWA) contract the GENUINE issuer's, or an impersonator? genuine / impersonation / unsafe / unknown — fail-closed (unknown is never genuine). Catches the FBI-flagged lookalike-token fraud. Registry is authoritative: seed only; source real addresses from issuer official docs. params: token*, claimedIssuer, claimedSymbol |
till_vet_meme | Which contract is the REAL memecoin among 10+ look-alikes? Fail-closed verdict from live market data (DexScreener). Returns: genuine (one contract dominates liquidity), ambiguous (top-2 tied — never certified), impersonation (the address you passed is NOT the dominant one), thin (no credible liquidity). Advisory + re-verifiable. ALSO returns `observedRisk`, kept SEPARATE from the verdict on purpos params: symbol*, chainId, address, siblingCount |
till_receipt | Produce the chain-anchored receipt for a VERIFIED payment (txHash + basescan link). Refuses without verification. params: to*, amountUsd*, label, merchantName, lookbackBlocks |
till_roll | PROVABLE BOOKS: render an agent/merchant's till roll — a shareable statement where EVERY line carries its own txHash + basescan link, so the reader re-verifies each payment on Base themselves (trust no one, not even BIII). This is the substitute for the settlement statement an excluded merchant/agent loses when they leave a PSP. Pure and non-custodial (BIII holds no funds). Pass the verified recei params: receipts*, merchantName, lang, brand |
till_export | ACCOUNTING EXPORT: turn the verified receipts into an accountant-ready CSV that QuickBooks / Xero / Excel import (the export finance teams need to adopt). Every row carries its own txHash + Basescan link, so the accountant re-verifies each amount on Base themselves — the export is a POINTER to the chain, never a book to trust. Non-custodial (BIII moved no funds). Columns: date, receipt_no, referen params: receipts*, fromBlockTime, toBlockTime, brand |
till_meter | USAGE → BILL for a white-label pilot, split by trust. The settled receipts are ON-CHAIN (each txHash re-verifiable on Base — the PROVABLE basis for receipt charges); the verdict count is SELF-REPORTED (verdicts are advisory reads, not chain artifacts) and labeled as such. The pricing plan is INJECTED (the partner brings their tiers). Pure, stateless, non-custodial (BIII holds no ledger). Returns t params: receipts*, verdictCount, plan, fromBlockTime, toBlockTime |
till_floor | DECENTRALIZATION PROOF: the provenance + content-FINGERPRINT of this node's known-bad floor. Two nodes with the SAME fingerprint judge on the SAME floor — sameness is a checkable fact, not an operator's word. The floor is re-derivable from named public open-licensed lists (run scripts/biii-known-bad-ingest.js and confirm the hash), so convergence is on PUBLIC DATA + a deterministic hash, never on params: none |
till_resolve | IDENTITY BRIDGE: resolve an AGENT identity — a buzz/Nostr npub (64-hex secp256k1) AND/OR a gitlawb did:key (Ed25519) — to a payable, trust-assessable BASE address, trustlessly. The binding is a BIDIRECTIONAL attestation: each identity key AND the Base key sign the same canonical message, so anyone re-verifies the signatures (BIII never takes your word). A binding needs AT LEAST one identity key (n params: npub, did, address*, nonce, chainId, expiry, sigNostr, sigDid, sigBase, verified |
till_kya | IDENTITY STANDARD (interop): read a Skyfire KYA ("Know Your Agent") JWT — the signed token binding a real human/business to an agent (Experian's identity layer). The IDENTITY counterpart to till_trust's ERC-8004 reputation lens. Parses the JWT + validates fail-closed (iss/sub present, not expired, aud matches YOU — anti-replay), and treats it as ATTESTED only when you confirm the signature verifie params: token*, expectedAudience, requireExpiry, verified |
till_authorize | SPEND AUTHORIZATION (Skyfire Programmable Payment): create a charge AND check it against what the agent's OWNER signed off — token, recipient allow-list, per-charge max, AND the cumulative cap. Fail-closed and drain-safe: an EIP-681 payment intent is issued ONLY if the charge is authorized (ten small charges cannot beat a low cap). BIII does not verify the authorization JWT signature itself — pass params: to*, amountUsd, amountMicro, label, spendAuth*, spentMicro, verified |
till_rug_powers | WHO CAN STILL RUG THIS TOKEN? till_vet_meme says which contract is the real one; this says whether the real one is itself a trap. A dangerous capability only counts if someone can still FIRE it — mintable with ownership renounced is inert, the same flag with a live owner is an armed rug, and scoring flags without that distinction is why most scanners are noise. Merges two sources that fail at oppo params: address*, chain |
till_launch_funder | WHO PAID FOR THIS LAUNCH, AND WHAT ELSE DID THEY PAY FOR? Follows the money backwards: a token names its creator, a creator minted minutes ago names the wallet that funded it, and that funder usually funded others. Three free explorer queries surface a cluster no buyer can see from a chart. Proven live: one funder had sent an identical 15.020 ETH to 26 fresh wallets. Reports STRUCTURE ONLY — a sha params: address*, chain |
till_b20_authentic | IS THIS A REAL BASE-NATIVE B20, OR AN ERC-20 WEARING ITS ADDRESS PREFIX? B20 is Base's native standard for compliant asset issuance (stablecoins, RWA); its tokens sit at addresses starting 0xb200 and run as a precompile, so a genuine one carries almost no EVM bytecode. As people learn to read 0xb200 as "official Base asset", a plain ERC-20 at a vanity address of the same prefix inherits that credi params: address*, chain |
till_trace_theft | FOLLOW STOLEN FUNDS from the victim's transaction to where the trail dies. Three modes. moved: what actually left a wallet in one transaction, marking which transfers are AUTHENTIC — ERC-20 Transfer logs are attacker-controlled text, so only the transaction signer is authoritative and forged events are flagged rather than followed. bridge: read a cross-chain exit; aggregators write the destination params: mode*, txHash, address, chain, maxHops |
till_recovery_offer | THE SECOND THEFT: judge an approach offering to recover already-stolen funds. Every other tool here tries to stop the first loss; this exists because the first loss is what makes a person findable, and a drained wallet is a lead with a market for it. Answerable with certainty rather than a score, because the ask itself is the tell: recovery happens through the thief returning funds, or a court, ex params: address, chain, asksForSignature, asksForUpfrontPayment, asksForSeedOrKey, asksToInstall |
till_vet_approach | JUDGE AN INBOUND OPPORTUNITY BY ITS ASK, NOT BY HOW GOOD IT LOOKS (podcast, interview, partnership, job, AMA). Built from a lure that worked on someone who verifies counterparties professionally: a 35-question production dossier citing his real scoring model, his settlement rails, his own catchphrase, quoting his posts verbatim — and asking genuinely HARD questions, because a flatterer never inclu params: links, platform, asksToInstall, asksForKeyOrSeed, asksForSignature, asksForUpfrontPayment, urgency |
till_open_approvals | WHICH DOORS INTO THIS WALLET ARE STILL OPEN? An ERC-20 approval is a standing permission to move your tokens without asking again, and it is the most common drain vector that does NOT require the private key: you approved a contract once for an unlimited amount and forgot. Wallets do not surface these, so almost nobody knows what they have granted. The load-bearing discipline: an Approval EVENT IS params: owner*, chain, fromBlock |
till_watch_wallet | WHAT CHANGED AROUND THIS WALLET SINCE WE LAST LOOKED? The other tools answer at a point in time; this is what turns them into a guard, because it REMEMBERS and therefore distinguishes a new door from an old one. Three unlimited approvals granted last year are a standing condition; a fourth appearing this morning is an event, and only the second deserves to interrupt anyone — a monitor that repeats params: owner*, chain, persist |
till_vet_agent | IS THIS AGENT SAFE TO CONNECT TO, AND SAFE TO PAY? The gap this closes: everything else here judges tokens, launches, thefts and wallets, but never the AGENT — which is the thing that actually holds the tools. Four checkable dangers, none of which require trusting a word of the description. It does not exist (a listing is not a service, and paying an endpoint that never answers is the simplest los params: url, payTo, chain |
till_seed_exposure | IS A RECOVERY PHRASE SITTING IN CLEARTEXT ON THIS MACHINE? Everything else here answers whether an ADDRESS is safe to pay; this answers whether the MACHINE is safe to hold a wallet, and a safe address on a compromised machine is worth nothing. "Self custody if you know how to keep your seedphrase safe" puts the whole condition in the sentence and nothing ships that checks it: an antivirus answers params: paths |
till_key_exposure | WHAT KEY MATERIAL IS ON THIS DISK, AND WHAT STILL HOLDS AN OLD COPY OF IT? The companion to till_seed_exposure, and it exists because a real theft happened without the phrase ever being written down: the key was exfiltrated. The trap is that a secp256k1 private key is 64 hex characters and so is every SHA-256 hash, git object id and transaction hash in a saved response, so the value SHAPE carries params: paths |
till_verify_delivery | I CAN PROVE I PAID. CAN I PROVE I WAS SERVED? Every other check here runs before money moves; this is the question after, and it is the one nothing in this market answers. A payment is a fact on Base that anyone can re-check forever; the deliverable was a sentence in a message. So a buyer can prove it spent and cannot prove it received — and every settlement record in existence, including the ones params: commitmentHash, received, receivedHash, paidAt, committedAt |
till_funder_history | HAS THE WALLET THAT PAID FOR THIS LAUNCH ALREADY KILLED ONE? till_launch_funder reads the graph and tells you a cluster exists; this reads our OWN observation record and tells you what happened to the rest of it. The distinction matters because every other check here asks the token a question it cannot answer in time: a curated security index returns an owner address for roughly one Base token in params: funder |
Entries describe changes in tool definitions. They are not statements about a server, its quality or its author. The grade measures how the tool definitions fit model providers (token cost, schema compatibility, confusable names) as scored by the ToolFit engine at the time of the listing. JSON: append .json. Opt-out: how or hello@youraitools.co.