Skip to main content
A green ✓ after an app’s name — on its tile, the connect sheet, and the pay sheet — means Bankroll has reviewed what that origin serves and signed its manifest. Users hear it as “Verified by Bankroll”.

​
What it means

  • The name, icon, and payment recipient the user sees are the ones Bankroll attested — the origin can’t change them without Bankroll signing again.
  • It does not mean Bankroll audited your game, your odds, or your code. Unverified apps still use the bridge, sessions, and charge(); privileged server APIs require verification.

​
What it unlocks

  • Referrals — play in your app counts toward a friend’s [qualifying 30](/build/share−links),andyourtreasuryearns30](/build/share-links), and your treasury earns 10 per qualifying referral from your links (first 100 a month).
  • Notifications — notify one user or your app’s recent-user audience.
  • Matchmaking — pair players by queue and rating, with recoverable entries and atomic cancellation.
  • Webhooks — Bankroll watches the chain for references you mint and tells your server when the transaction lands.
  • Timers — set a timer on Bankroll and it calls your server when it fires.

​
How you get it

An app made with the Bankroll CLI is verified at every build: Bankroll signs its manifest before it deploys and puts the signed JWT in the deployment’s settings, so there is nothing to submit. The steps below are for an app you host yourself. For notifications or matchmaking, configure your app key before submitting your manifest for verification. Ask in the Built for Bankroll Discord. Bankroll fetches what your origin serves at /.well-known/bankroll.jwt and /.well-known/bankroll-icon.png, reviews every claim, and hands you a signed JWT. Then:
1

Serve it verbatim

Set BANKROLL_SIGNED_MANIFEST to the signed JWT; the SDK’s manifestRoute serves it byte-for-byte. The signature covers the exact bytes, so nothing may touch it.
2

Keep the signing view live

manifestRoute answers ?signing=1 with your freshly built manifest, so a later change can be re-signed without unpublishing the current one.
3

Re-sign on any change

Any claim change — including appKey, capabilities.push, name, payments, or the icon — needs a new signature. Until then the old one stays valid and the new claims aren’t live.
The signature is bound to one exact origin. A preview deployment or new tunnel needs its own manifest and verification before it can call privileged APIs. Copying another origin’s signed JWT does not verify it.