Blowfish

• Name: Blowfish
• URL: https://blowfish.xyz/
• Category: wallet-security middleware company / transaction-simulation and dapp-risk operator / blocklist-distribution infrastructure provider
• Summary: Blowfish belongs as an entity note, not a protocol note. The useful question is who classifies domains and dapps, authors signing-risk interpretations, distributes blocklist updates, defines override paths, and decides how much privacy or request metadata sits with the provider versus the integrator. The real control surface is the company-run trust-and-safety stack in front of wallet and dapp actions.
• What it does:
  • Provides wallet-facing trust-and-safety infrastructure for scanning domains, dapps, transactions, and signing flows before users approve them
  • Aggregates Blowfish-authored intelligence with outside risk-signal sources rather than exposing only one internal phishing list
  • Publishes a local blocklist library so integrators can fetch blocklist objects and bloom filters, rescan domains locally, set priority allow / block lists, and persist local overrides
  • Recommends frequent blocklist refreshes and makes blocklist freshness, TTL behavior, and local enforcement logic explicit
  • Publishes a simple reverse-proxy image so integrators can hide user IP addresses from Blowfish and keep API keys out of client apps
  • Open-sourced the now-deprecated Blowfish Protect frontend stack, which still exposes how the company decomposed extension UX, backend, transaction portal, and shared packages
• Key claims:
  • The homepage presents Blowfish as a complete trust & safety platform for wallets rather than as a narrow blacklist or one-off simulation API
  • The local blocklist package shows that Blowfish is not just returning hosted verdicts; it is also distributing policy artifacts that integrators can cache, prioritize, override, and partially internalize
  • The blocklist README recommends refreshes every 5 minutes and documents bloom-filter hash tracking plus a 24-hour default TTL, making freshness policy part of the real control surface
  • The simple-proxy repo shows a second practical authority boundary: integrators can change who sees end-user IP addresses, where API keys live, and how much request metadata sits directly with Blowfish
  • Public repos show Blowfish covering both domain reputation and transaction-signing review, which makes the company more important as a wallet trust-and-safety operator than as a generic security vendor
• Whitepaper: No classic whitepaper or litepaper is the important artifact here. The useful primary-source snapshot is ../whitepapers/blowfish-primary-sources-2026-05-14.md.
• Sources:
  • https://blowfish.xyz/
  • https://github.com/blowfishxyz
  • https://raw.githubusercontent.com/blowfishxyz/blocklist/main/README.md
  • https://github.com/blowfishxyz/simple-proxy
  • https://raw.githubusercontent.com/blowfishxyz/blowfish-frontend-monorepo/main/README.md

Why this company note belongs in the corpus

• Blowfish is analytically stronger as an operator note than as a project note because the meaningful question is not what protocol does it run? but who supplies the risk verdicts and update stream that wallet teams start treating as policy?
• The local blocklist tooling makes the company boundary especially important: Blowfish does not just host a UI feature, it authors and distributes the trust material that downstream wallets can turn into warnings, friction, or hard stops.
• The proxy deployment pattern matters too. Privacy posture, API-custody choices, and where sensitive request metadata terminates are part of the operational boundary, not just implementation trivia.

Internal linkages

• Legacy project-layer alias preserved for old links: blowfish.
• Best adjacent wallet-safety comparison: blockaid.
• Best adjacent operator-risk comparison: hypernative.
• Positive-design companion on keeping losses bounded after bad classifications or compromised sessions: post-authentication-bounded-loss-design.
• Positive-design companion on signer-facing authenticity and transaction interpretation: signer-intent-truth-security-object.

Protocol / company boundary

• There is no especially clean standalone Blowfish protocol boundary doing the analytical work here.
• The useful surface is the company-run classification, simulation, blocklist-distribution, override, and deployment-policy stack that sits between raw wallet intent and the final user action.
• That is why Blowfish belongs in companies/: the real control question is who authors and ships the warning and enforcement layer, not whether one API or SDK endpoint can be described as a product.

Control surface

• Practical leverage sits in risk classification, signal-source selection, blocklist freshness, priority allow / block lists, local-override semantics, proxy placement, and the exact wallet defaults that turn Blowfish outputs into advice, friction, or denial.

• None of that is onchain. The visible prompt is only the last step; authority already accumulated when Blowfish or the integrating wallet decided what counts as suspicious enough to surface or stop.

• If a wallet starts treating Blowfish outputs as canonical risk truth, meaningful control shifts into that offchain interpretation and distribution layer even when the final signature still belongs to the user.

• Treat Blowfish as trust-and-safety policy infrastructure, not as a neutral protocol primitive.

• Last reviewed: 2026-08-13 UTC