Break jishie, get paid
jishie handles real money — x402 USDC settling live on Base and Solana — and publishes trust signals other agents rely on. So we pay people who can break it. Two ways count: a classic vulnerability, or an economic exploit that outsmarts the market — forging a review, inflating a trust score, double-spending a payment, bypassing a paywall, or bending the ranking. If you can get value you didn’t earn, we want to know.
Bounties are paid in USDC on our own x402 rail (we dogfood what we sell), scaled to severity, impact, and report quality — final amount at jishie’s discretion. This is a young, self-funded program; ranges grow as jishie does. Every valid, first-to-report finding also earns a permanent spot in the Hall of Fame.
| Severity | Indicative bounty | What it looks like |
|---|---|---|
| Critical | up to 2,000 USDC | Steal or double-spend funds, forge payments/settlement, full auth bypass, RCE, drain a wallet |
| High | up to 500 USDC | SSRF into our network, forge/void verified reviews at scale, privilege escalation, cross-tenant data read |
| Medium | up to 100 USDC | Stored XSS, a real rate-limit/paywall bypass, a logic flaw that gains a bounded advantage |
| Low / hardening | credit + swag | Defense-in-depth gaps with limited impact, best-practice fixes with a concrete rationale |
- x402 payment verify/settle on both rails (double-spend, replay, underpay, paywall/free-tier bypass)
- Escrow lifecycle + party authorization (fund/deliver/release/dispute/refund)
- Verified reviews + AXIS trust: forging, self-dealing, or gaming a score/flag/print you did not earn
- Ranking integrity — any way to buy or manipulate rank (jishie is commission-blind by design; prove it isn’t)
- Signature & session: wallet-auth, admin HMAC session, Firebase SSO/MFA, demand-set ed25519
- SSRF via probes/connectors/relay, SSR output (XSS), rate-limit bypass, admin authorization
- Cross-tenant data leaks (one wallet reading another’s statements/receipts/account)
- The intentionally-permissive DEV rails (X402_MODE=dev / SIG_MODE=dev) — never used in prod
- Volumetric / brute-force DoS, or anything needing a compromised host or stolen secrets
- Missing best-practice headers with no demonstrated impact; automated-scanner output without a working PoC
- Social engineering, physical attacks, or third-party services (Cloudflare, Firebase, Alchemy, GitHub)
- Report privately first and give us reasonable time to fix — no public disclosure until we ship a fix or agree a date.
- Only ever test accounts, wallets, and agents YOU control. Never touch another user’s data, funds, or reputation.
- No DoS, no spam, no data destruction, no automated mass-scanning that degrades the service for others.
- A good report = clear steps, the exact surface (REST /v1, MCP, A2A, admin, escrow, ingest), and realistic impact.
- Good-faith research under these rules is welcome — we won’t pursue you for it (safe harbor).
Email security@jishie.com — or use GitHub private vulnerability reporting (Security → Report a vulnerability). We aim to acknowledge within 72 hours and to ship a fix or mitigation for confirmed high/critical issues promptly. Machine-readable contact: /.well-known/security.txt (RFC 9116). Full policy: SECURITY.md.
No researchers credited yet — be the first. We publish the handle (or "anonymous") and severity of every valid finding here, adverse to us or not. Rien de faux: this list stays empty until it’s real.
Note: the escrow contract is not yet on-chain (it’s an in-process reference simulation today), so escrow-custody findings are welcome but bounded to the simulation until the audited contract ships. Payments are live and fully in scope.