Trust Center

Data handling

How data moves today

Agent checks receive only the input needed for the selected check, such as a token address, an unsigned transaction or a transaction hash. KushBitx never asks for or holds private keys, never signs and never moves funds. We do not accept client files. Reconciliation and close services were discontinued on 24 October 2026.

Service providers used by the code today

• Cloudflare: hosting, the website database and request logs.
• Brevo: sending business email. Brevo adds an anonymous open-tracking pixel that we cannot switch off.
• Google (Gmail): the owner's mailbox.
• Coinbase Developer Platform (CDP): the primary x402 facilitator that verifies and settles paid checks.
• PayAI: the fallback x402 facilitator, used only when CDP is unavailable.
• Alchemy: the public Base endpoint, used for onchain reads, including market data read directly from DEX pools when market-data providers are unavailable.
• Sourcify: verified contract ABIs, used to read token owner controls onchain.
• Agent check data: public Base RPC endpoints (Base and PublicNode), DexScreener and GeckoTerminal market data, and GoPlus and Honeypot.is security data. Only the data needed for the selected check is sent.
• DigitalOcean: an older operations server that still holds enquiries received before 7 October 2026. It is being shut down and its data deleted.

AI tools

Client data is not processed with an AI tool until KushBitx has approved a commercial route for it, after reviewing the product terms, training, retention and sub-processors. We do not train models on client data.

Deletion

Past enquiries: the last one was received on 7 October 2026. Each is deleted automatically 90 days after receipt, so all are deleted by 5 January 2027. Paid tool reports and recovery records: 30 days. Evidence Chain records: 30 days after a chain's last record. API reliability observations and anonymous site events: up to 30 days. Existing backups follow their own retention policy. Details are in the privacy notice.

Contact

Privacy or security questions: admin@kushbitx.com. Vulnerability reports: security policy.

Architecture

Non-custodial boundary

Security

Vulnerability disclosure

Privacy

External security ratings

Public pledges

Registry listings

KushBitx Preflight — Internal Test Results v0.1 (Base)

These are results of an internal test we ran while developing the engine. They are not an independent evaluation. We built the cases, ran them and classified the results ourselves.

Version tested. Preflight engine commit 7e40897. Production version 3fe4ddd2 runs the same engine. The test ran on 2026-11-02 against our staging environment through a dry-run route: nothing was signed, sent or paid. Ranges in brackets are 95% Wilson confidence intervals. The samples are small, so the ranges are wide; read them before the point figures.

Main result: 52 real Base transactions not used for tuning

One hour of recent, successful Base transactions (blocks 53,406,471 to 53,408,470), collected after the last engine change and never used to adjust it. Senders are ordinary wallets (no contract code), and no counterparty was on ScamSniffer or Forta when the cases were built. The 52 transactions come from 52 different senders, to 37 different recipients or contracts, and involve 30 different tokens.

A successful transaction is not necessarily a safe one. We did not verify these transactions one by one, so we sort each flag by its cause.

• A "strong risk signal" is one of these: a token whose sell simulation fails or whose sell tax is extreme; a token with blacklist, pause or mint powers; an approval to a contract we cannot identify; or an outflow the transaction does not declare. A flag does not mean the transaction was fraud.
• Both BLOCK results are tokens that could not be sold: the honeypot check or the sell simulation failed.

How decisions are made

• ALLOW: every required check finished, and no rule fired above information level.
• REVIEW: do not sign automatically. A person or the agent's own policy has to decide. REVIEW is also the answer whenever a required check could not finish (fail-closed).
• BLOCK: a critical finding. Examples: the counterparty is listed for phishing or theft by a named source; the swap output goes to someone else; the token cannot be sold; the transfer breaks the caller's policy.

Where each signal comes from:

• When a provider fails, the answer is REVIEW, never ALLOW.
• How much depends on outside providers:
  • Real transactions: of all 53 flags across the four real windows, 26 rest on a signal from our own simulation or rules, 22 only on a provider signal (Honeypot.is, or GoPlus token or address data), and 5 on a check that could not finish. In the main window, 8 of the 14 flags rest on our own signal.
  • Constructed cases: of the 70 flagged constructed cases, 20 rest only on GoPlus address reputation.
  • Turning off address reputation changed the result in 26 of all 354 cases.

Development set (used while tuning the engine)

These cases were used while we changed the engine, so they show that the rules work as designed, not how the engine does on unseen data.

A. 140 constructed and listed cases. 8 of them are standalone Token Risk checks, not Preflight; they are reported separately below. The table covers the other 132 Preflight cases.

• (a) uses counterparties on the ScamSniffer and Forta lists (20 each). Without address reputation, Preflight still flags the 20 unlimited approvals to them, because an unlimited approval to a wallet is a risk on its own, but not the 20 plain transfers.
• (b) were designed by us, from risk types we wrote rules for. 30 of 30 shows that those rules work as designed. It does not show that Preflight finds new, unknown threats. Their counterparties were not on the lists we checked (ScamSniffer, Forta, GoPlus) on 2026-11-02. By design, an address blocklist cannot catch these patterns.

• The blocklist baseline wrongly blocks the 10 approval revocations among the benign cases. Removing an approval given to a listed address is a protective action.
• Standalone Token Risk (separate service, 8 large tokens): 7 ALLOW, 1 REVIEW. The REVIEW is bridged DAI on Base: its largest Base trading pair holds about $60,000 of liquidity, and one ordinary wallet holds about 28% of the Base supply. Both facts were true on the test day.

B. Three earlier windows of real Base transactions (162).

What this test does not cover

• Honeypots as a measured category. They appear in the real traffic above, but are not a scored class.
• Composite transactions: multicalls, and batched calls through smart accounts.
• Other chains.
• Documented Base incidents and EIP-712 signatures were not part of this test (v0.1). They were measured separately afterwards: see Address poisoning check and Signature Check: real-case results below.

Disclosures

• Replay on the previous block. We simulate each real transaction on the state of the block before it, not the state just before it inside its own block. When a transaction depends on an earlier one in the same block, the simulation fails. This caused 2 results we count as technical (both in the development windows).
• Look-ahead. Reputation, liquidity and token data come from the test day, not from the time of the original transaction.
• Related transactions. The 214 real transactions come from 201 different senders, to 110 different recipients or contracts, and involve 92 tokens. Some transactions are related, so they are not 214 fully independent samples.
• Network failures on our side. We sent 354 measurement requests in all (every set together); the main result above uses 52 of them. 33 of the 354 (all in the second development window) failed on our test machine with "fetch failed": no response reached the server. We reran them and kept the failed attempts in the files.
• Technical flags. 7 of the 53 flags on real transactions (13.2%) were technical: 3 brief provider outages (ALLOW when rechecked), 2 on one closed-source token that neither provider covers (still REVIEW, as designed), and 2 replay artifacts.
• Case-construction errors in the first run of the development set: the 25 swap cases used a wrong sender address (first a contract, then an unfunded wallet). They were rebuilt and rerun on the same engine, and the earlier results are kept.
• Speed. Measured on staging from our own machine, with a deliberate 6-second pause between requests. This is not production speed. Median 1.4 s, 95th percentile 4.6 s, 99th percentile 6.4 s, slowest 12.0 s (354 requests).
• Sources. ScamSniffer data is GPL-licensed and was last updated in February 2024, so its cases are published as aggregate numbers only.
• Version. Engine commit 7e40897; production version 3fe4ddd2 runs the same engine.

Per-case results

• real-transactions.csv: all 214 real transactions (transaction hash, verdict, reason codes, our cause classification, and the verdict without address reputation).
• constructed-cases.csv: the 120 development cases not taken from ScamSniffer (inputs, verdict, reason codes).

Next: v0.2 (independent evaluation)

• The engine is frozen before any case is collected.
• Documented Base incidents, identified by transaction hash.
• Labels reviewed by someone other than us.
• Comparison by component: simulation only, reputation only, policy only.

No date is set yet.

Address poisoning check (added 7 November 2026)

For an ETH or ERC-20 transfer, KushBitx Preflight compares the recipient with the addresses the sending wallet really paid or was paid by. Only real payments count; fake tokens and zero transfers never do. A recipient that shares the first and last 4 characters with one of those addresses, but is a different address, is REVIEW. If a planted fake-token, zero or dust transfer also connects the two, it is BLOCK.

What we measured, at the block before each transaction:

• Development cases (seen while designing the check): 6 real address poisoning payments on Base from a published analysis. The check stopped 4 of 6. The 2 it missed paid a look-alike of an address the wallet had never dealt with itself.
• Benign set (separate, from a new block window): 135 transfers, of which 115 were real ETH and USDC transfers from active wallets and 20 were payments to new addresses. The check raised 0 false alarms. With 0 of 135, the 95% upper bound on the false-alarm rate is about 2.2%.

Limits:

• The check reads each wallet's last 1,000 outgoing and 1,000 incoming transfers. Older counterparties of very active wallets are not seen.
• If the transfer history is unavailable, the report says so, and the verdict does not change.
• It does not catch a look-alike of an address the wallet never paid or was paid by. Sending expectedRecipient closes that gap: a different recipient is BLOCK.

These are internal tests, not an independent audit.

Signature Check: real-case results (added 9 November 2026)

KushBitx Signature Check answers ALLOW, REVIEW or BLOCK for an EIP-712 signature request before an agent signs it. It covers EIP-3009 (x402 payment authorisations), EIP-2612 Permit and Permit2 (allowances and signature transfers). Any other typed data is REVIEW. Each answer is bound to the EIP-712 digest of exactly what was checked.

What we measured, with typed data rebuilt from real Base transactions:

• x402 payments (EIP-3009): 10 real payment authorisations from our own settlements. In all 10 the signer recovered from the signature is the payer, so these are the exact messages that were signed. With the true recipient and amount: 10 of 10 ALLOW. With the recipient changed to another address: 10 of 10 BLOCK.
• Vestaa (10 October 2026): the Permit2 signature transfer that was replayed after a failed transaction, rebuilt from that transaction (the recovered signer is Vestaa's wallet). Result: REVIEW, with the note that a signature transfer stays usable until its deadline and a reverted transaction does not use it up.
• Permit2 allowances: 15 allowances rebuilt from recent Permit2 events (the events carry no signature, so these are reconstructions, not the signed messages). 10 to Uniswap Universal Router: ALLOW. 5 to two other routers not then on our verified list: REVIEW. Both routers were later confirmed from their official sources and added to the list.

In short: 21 of 21 scored cases gave the expected answer, all 21 with the exact signed message.

What it does not cover yet:

• Real EIP-2612 permits: their signatures are hard to find on chain without an indexer, so they were tested only with constructed cases.
• Witness data in Permit2 signature transfers (for example an order): reported as present, not interpreted.
• Smart-account signatures (ERC-1271) and batched or composite transactions (planned next).
• Whether the site asking for the signature is the one you think it is.

These are internal tests, not an independent audit.