Bounty tasks, referrals and on-chain rewards inside JBC Launchgate

Reward settlement in JBC Launchgate ends up on a public ledger: every payout is a BEP-20 transfer on BNB Smart Chain against the JimmyBoss Collective (JBC) token, whose contract sits on BscScan at 0xa9CC0D38…E40cb6473. Everything before that point — the bounty catalogue, the proof you upload, your submission state, the referral tree — lives in the Launchgate backend, reached through the optimized WebView the app wraps around the JBC portal. Two stores, one account. Pulling them together is the whole job here.

So the integration we build is a runnable client first. It signs into a consented account, walks the portal endpoints the WebView already calls, and reconciles each credited reward against the matching on-chain transfer. You give us the app name and what you want out of it; access and the consent setup are arranged with you as part of the work.

What the terminal stores per operative

The app's own copy names most of these surfaces. The table maps each to where it originates and what an integrator would do with it once it is out.

Three ways into the account data

These are the routes that actually fit a WebView-fronted Web3 terminal with on-chain settlement. We would run them together, not pick one and stop.

1 — Consented portal session

The WebView talks to the Launchgate backend over HTTP. We sign in with a consenting account — Protocol ID plus the Email OTP or Google Authenticator step — and map the request and response shapes for tasks, submissions, referrals and the reward ledger. Reachable: nearly all account-scoped data. Effort: moderate, mostly traffic mapping. Durability: good while the portal contract stays stable; we re-map if it shifts.

2 — On-chain reads of the JBC contract

Reward settlement is public. Reading BEP-20 Transfer events against the JBC contract on BNB Smart Chain gives the authoritative paid amount per wallet, with no consent needed for the chain side. Reachable: settlement, balances, history. Effort: low. Durability: permanent — it is a blockchain.

3 — Protocol analysis of the mobile traffic

Where a surface is only exercised by the native shell rather than the WebView, we capture and document that traffic under the account holder's authorization. Reachable: anything the portal session misses. Effort: higher. Durability: tied to the app version we map against.

For this app the spine is route 1 carrying the live state and route 2 settling the money question; route 3 fills gaps the WebView session does not reach. We recommend building 1 and 2 first and reaching for 3 only where a real surface is missing.

What ships to your repository

The first thing you get is a client that runs against your own account. In rough order of delivery:

• A runnable client (Python and Node.js) — session login, the bounty, submission, referral and reward endpoints, plus a BSC reader for the JBC contract, returning one reconciled object per reward.
• A webhook / push handler — subscribes to the same OneSignal uplink the app uses, so a new reward pool fires a delta pull instead of a polling loop.
• An automated test suite — fixtures for the portal responses and on-chain transfers, pinning the field shapes the client depends on.
• Batch-vs-realtime sync design — a backfill path for history and a delta path for live state, with the on-chain transfer treated as the settlement record.
• An OpenAPI/Swagger spec of the mapped portal surface, and a protocol and auth-flow report covering the Protocol ID, OTP/TOTP and session/cookie chain.
• Interface documentation and data-retention guidance for the wallet, profile and reward records you ingest.

A reward pull, request to settlement

Illustrative, not a published spec — field names are confirmed during the build against your account. It shows the shape of route 1 plus route 2 in one pass.

from jbc_launchgate import Terminal   # the client we deliver

# Session comes from a consented Protocol ID login;
# the TOTP arg mirrors the app's Google Authenticator 2FA step.
term = Terminal(base="https://launchgate.jbc.finance")
term.authenticate(protocol_id=PID, totp=code)

# Open bounties and this account's submission state
for task in term.bounties(status="open"):
    sub = term.submission(task_id=task["id"])
    print(task["title"], task["reward_jbc"], sub["state"])

# Reconcile a credited reward against the on-chain transfer
payout  = term.rewards(since="2026-01-01")[0]
settled = term.chain.transfer(
    token="0xa9CC0D38E57dBEC771D7EaCd133d509E40cb6473",  # JBC BEP-20
    to=payout["wallet"],
    tx=payout["tx_hash"])

# Portal credit must equal the tokens that actually moved
assert settled["value"] == payout["amount"]

The assert is the point. A reward the portal marked credited but the chain never settled is exactly the kind of gap this client is built to catch.

The shape we hand back

However the portal names its fields internally, the client normalizes to a stable record so your downstream code does not care about the raw wire format.

{
  "task":       { "id": "bnty_…", "title": "…",
                  "reward_jbc": "…", "pool": "…", "status": "open" },
  "submission": { "task_id": "bnty_…", "state": "pending|approved|rejected",
                  "proof_ref": "…", "submitted_at": "…" },
  "reward":     { "amount": "…", "currency": "JBC", "wallet": "0x…",
                  "tx_hash": "0x…", "settled": true }
}

What the build plans around

Concrete things this specific app forces us to handle — not hurdles for you to clear, just where the engineering goes.

• WebView-fronted data. The account surfaces sit behind the in-app WebView, so we map the portal's request/response and session/cookie chain directly rather than guessing at endpoints. The OTP/TOTP step is scripted with the account holder during onboarding and the session is then refreshed by the client.
• Two stores that can disagree. The portal reward ledger and the on-chain BEP-20 transfers drift between "credited" and "settled." We make the chain the authority and reconcile every portal credit against a confirmed transfer, so a payout that never landed on-chain is flagged rather than trusted.
• Recursive referral walk. Referral rewards are downline-based; we paginate and depth-cap the walk so a large tree does not stall a sync.
• Push as a trigger, not a feed. The OneSignal uplink tells us when a pool opens; we use it to schedule a scoped pull, keeping reads off a tight polling cadence.

Authorization, MiCA and GDPR in practice

The dependable basis for every read is the account holder's own consent — their session, their wallet, their data. On top of that, this is crypto-asset and personal data, so two regimes shape how we operate. The EU's Markets in Crypto-Assets regulation (MiCA), in force since 30 December 2024 per the published framework, governs how crypto-asset data and identity are handled in the EU; GDPR governs the PII you ingest — the linked wallet, the Protocol ID, the OTP contact. We work authorized and documented, log consent, minimize what we store (the wallet and reward records you actually need, nothing more), and sign an NDA where the engagement calls for one. Biometric login stays on the device, as the app states, and never enters the integration.

Screens from the terminal

Store screenshots of the Launchgate interface — the task and reward surfaces the integration maps. Tap to enlarge.

Other quest-and-reward apps in the same orbit

If you are aggregating across this category, these come up alongside Launchgate. Plain context, no ranking.

• Galxe — cross-chain credentials and quest campaigns; holds task completion and on-chain credential data.
• Layer3 — educational quests across many chains; holds per-user quest progress and reward claims.
• Zealy — community sprints with XP and leaderboards; holds points, levels and submission records.
• TaskOn — decentralized task campaigns; holds task verification and reward eligibility data.
• QuestN — quest creation and participation; holds completion proofs and reward distribution records.
• Intract — in-app quests and engagement tracking; holds interaction and retention data.
• Airdrop Alert — curated airdrop and bounty listings; holds campaign metadata users act on.
• DappRadar — dapp and airdrop tracking; holds wallet-linked activity across protocols.

Questions integrators ask about JBC Launchgate

Can one client read both the portal ledger and the on-chain JBC settlement in a single pass?

Yes. The client we ship wraps the consented portal session for tasks, submission state and the referral tree, and a BNB Smart Chain reader for the JBC BEP-20 contract, then returns one reconciled record per reward so a credited task is matched to its settled transfer.

How is the Protocol ID and 2FA login handled during the build?

We script the Protocol ID sign-in and the Email OTP or Google Authenticator step together with the account holder during onboarding, capture the resulting session, and let the client refresh it on its own schedule. Nothing about the app's authentication is circumvented.

Is the JBC reward data on-chain or in the app backend?

Both. The bounty catalogue, submission state and referral tree live in the Launchgate backend behind the in-app WebView; reward settlement is a BEP-20 transfer on BNB Smart Chain. We read the chain for the authoritative paid amount and the portal for everything still in flight.

Which network and token does Launchgate settle rewards in?

BNB Smart Chain, using the JimmyBoss Collective (JBC) BEP-20 token. Its contract is listed on BscScan and the token reports a one billion supply on CoinGecko; the integration reads transfer events against that contract address.

Sources and review

Checked in June 2026 against the app's own listing and the JBC project material. Primary sources: the Google Play listing for the feature set and package id; the JimmyBoss Collective site for the ecosystem and reward model; BscScan for the BEP-20 contract; and CoinGecko for token supply and market data.

Compiled by OpenFinance Lab — engineering notes, 2026-06-15.

Getting a build moving

A first working client — Protocol ID login, the bounty and reward endpoints, and the on-chain reconciler — lands inside one to two weeks. Take it as source code you own for a flat fee from $300, paid only after it runs against your account and you are happy with it; or skip owning anything and call our hosted endpoints, paying per call with nothing up front. Either way you bring the app name and what you need from its data, and we set up access and consent with you. Tell us what you need →