Skip to main content

ChainBounty (Sentinel Protocol legacy)

ChainBounty (Sentinel Protocol legacy) — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

ChainBounty — a Security | Infra project (L2/L3 network + web applications) with a token (symbol: BOUNTY).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: a Web3 platform and its own network (ChainBounty Mainnet) for reporting, validating and investigating crypto incidents/scams via a “bounty mechanic”.
  • Who it’s for: users/victims who want to record a case; researchers/validators; companies/organizations that need threat information and address verification.
  • Why onchain/token: onchain is used for transparent accounting/storage of labels and data on addresses and for the “decentralized rewards” mechanics; BOUNTY is the native currency of the network (gas) and the ecosystem token.

How it works (very briefly)

  1. The user does: publishes a report about a scam/incident or checks an address/cases in the web application.
  2. The system does: community validators check/confirm the reports; data and “labeling” for addresses are stored/updated in the network (Layer‑2/Layer‑3 stack).
  3. The user gets: threat intelligence/public cases, validation status and results, access to tools (including scam check).
  4. Where the blockchain is: storage of/access to label data and transaction logic on ChainBounty Mainnet + the BOUNTY contract/asset in the Arbitrum ecosystem.
  5. Token role (if any): BOUNTY — the network currency (fees/gas); rewards and the available “reward system” mechanics are also described in public materials as the CBP points system (see FAQ).

Quick links: AI thesis fit

Project passport

Field Value
Project name ChainBounty (Sentinel Protocol legacy)
Also known as (aliases) Sentinel Protocol (legacy); Uppsala Security; TRDB; CBP (ChainBounty Points)
Logo (logo) ../assets/119_sentinel-protocol_logo.png
Token symbol (ticker) BOUNTY
Category Security | Infra
Primary chain (chain) ChainBounty Mainnet
Type Appchain
Network status mainnet
Consensus (consensus) Rollup/Orbit (sequencer-based, PoS-secured by base chain - high level)
Launch date (launch_date) 2024-12 (mainnet launch claimed)
Project status (status) active
Token (standard) ERC-20
Token contract 0x6a9896837021EA3eD83F623F655C119c54abE02c (Arbitrum One)
Token model (token_type) utility (fee-mechanism)
Max supply 555,416,661 (ERC‑20 on Arbitrum One)
Issuance fixed (per maxTotalSupply; no details found in the Tier‑1 tokenomics)
Tokenomics (tokenomics, brief) no Tier‑1 distribution/vesting found; the FAQ focuses on the CBP points system
Governance company / planned DAO (“Collaborative Governance” is claimed in the roadmap)
Admins/keys — (no Tier‑1 found)
Audit —
Bug bounty yes (a bounty platform for cyber incidents; not a classic security bounty)
Team (team) Uppsala Security (mentioned as the initiator in the documentation)
Funding (investors/funding) — (no Tier‑1 found)
AI component (ai_component) AI scam check / AI-driven threat tools
Use‑case (use_case) anti-scam reports, threat intel, bounty investigations
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 2 / 1 / 3
Last verified 2026-02-11

General project overview

ChainBounty is a Web3 platform for fighting crypto cybercrime via a system of “bounties”: users publish cases/reports, the community and validators verify the information, and the results and key data become available as threat intelligence.

In the documentation, ChainBounty is directly positioned as a continuation and development of the legacy of Sentinel Protocol (Uppsala Security) and describes Sentinel Protocol’s key asset — the TRDB threat database, containing tens of millions of records/address labels. To work with “labeling” at scale, the project claims a move to a Layer‑2/Orbit approach and a separate ChainBounty Mainnet network.

Features/modules

  • Scam/incident reports and public cases (web app).
  • Validation by the community/validators (described in the FAQ).
  • Wallet risk analysis (described in the FAQ).
  • Storage of/access to address labels (labeling) on the network (described in the tech stack).
  • Quick AI Scam Check (a UI tool in the web app).

Typical scenarios

  • Scenario 1: a user publishes a report about phishing/a scam → the case is verified → other users see warnings/details.
  • Scenario 2: a validator checks a report/labels → confirms/rejects → the data becomes part of the public threat database.
  • Scenario 3: a user runs a quick AI check of a suspicious screenshot/image → receives a risk assessment (as an application feature).

Getting started (wallet/network)

  • What you need: a web browser; for actions requiring a signature/onchain — an EVM wallet.
  • Network/chain: ChainBounty Mainnet (if you interact with the network) and/or Arbitrum One (if you work with the ERC‑20 BOUNTY).
  • Fees: network fees (gas) in BOUNTY for network transactions; Arbitrum fees — for ERC‑20 operations.

Architecture/tech (non‑AI)

  • Components: web app (reports/community), the validator role, the ChainBounty Mainnet L2/L3 network, RPC, block explorer (Blockscout), onchain storage of/access to label data.
  • Participant roles: reporters, researchers, validators, users of wallet analytics, operator/initiator (Uppsala Security).
  • Where logic runs: content publishing/moderation/AI check — web/offchain; storage of and access to labels/data — onchain on ChainBounty Mainnet (described).
  • Dependencies: Orbit/Layer‑2 stack, RPC rpc.chainbounty.io, block explorer scan.chainbounty.io, connection with the Arbitrum ecosystem (ERC‑20 on Arbitrum One).

Token/economics (expanded, no forecasts)

  • Token utility: BOUNTY — the network currency (gas) and the onchain unit for transactions in ChainBounty Mainnet; at the same time, the FAQ describes the CBP points system as the reward mechanic.
  • Protocol necessity drivers: without BOUNTY it is impossible to pay for transactions/use the onchain part of the network; however, parts of the product (community/content) can work offchain.
  • Who pays fees: users executing transactions in the network.
  • Where fees go: as standard — to the network validators/operators (at the level of blockchain economics); project‑specific distribution parameters were not found in Tier‑1.
  • Issuance/burn: max supply of the ERC‑20 on Arbitrum One: 555,416,661 (Arbiscan). The issuance/burn model at the network level is not disclosed in Tier‑1.
  • Security/incentive mechanisms: validators (described as a role in the ecosystem); the reward mechanic for users is described in the FAQ as CBP.
  • Distribution and token issuance schedule: no Tier‑1 BOUNTY tokenomics (distribution/vesting) was found.
  • Treasury: not disclosed (Tier‑1).

Governance

  • Who makes decisions: the team/organization (Uppsala Security) + the claimed “Collaborative Governance/DAO” plans in the roadmap.
  • How protocol parameters change: Tier‑1 contains no described governance/voting process; the roadmap claims a transition to a DAO in 2026.
  • Where decisions are discussed/made: the GitBook docs and the web application/community; public details of governance processes were not found.
  • Keys/multisig: not disclosed (Tier‑1).

Security and incidents

  • Audits: no public Tier‑1 audits of the network/contracts were found.
  • Bug bounty: not found as a separate security program; the main “bounty” in the project is a product for investigations/reports, not a classic bug bounty.
  • Incidents: no Tier‑1 postmortems/major incidents of the project were found.
  • Threat model: false reports/spam (validation quality), compromise of validators/moderation, privacy risks (erroneous deanonymization), network risks (sequencer/RPC), as well as errors in the onchain storage of labels.

Project status and timeline

  • Current status: mainnet is claimed (ChainBounty Mainnet, Chain ID 51828) + an active web application.
  • Key releases/milestones: mainnet launch claimed for December 2024; 2025 — full feature rollout; 2026 — AI‑driven threat tools + DAO (roadmap).
  • Roadmap: on the website (see links Roadmap).

Ecosystem/integrations

  • Integrations: Blockscout explorer (scan.chainbounty.io), RPC (rpc.chainbounty.io), Arbitrum ecosystem (the token is on Arbitrum One; the website footer also has a bridge link).
  • Partners: the website lists a set of partners (logos; without details of agreements/integration scope).
  • Where it’s actually used: the web application for reports/cases and community investigations; storage of labels and data — in the network (described in the tech stack).

AI component of the project

  • What is real AI here? The web application claims a Quick AI Scam Check (risk assessment based on an image/screenshot), and the roadmap — “AI‑driven tools for threat data sharing”.
  • What is truly onchain? Storage/accounting of labels (labeling) and data on addresses on the ChainBounty Mainnet network; the ERC‑20 BOUNTY on Arbitrum One.
  • Why is a token needed? BOUNTY is needed as the gas/currency of the network; at the same time, part of the “reward system” is publicly described as points (CBP), which creates uncertainty about the token’s role in rewards.
  • Red flags (based on the information found): AI‑washing (an AI feature is claimed, but there are no metrics/model description), token‑washing (the token exists, but Tier‑1 tokenomics/the role in rewards is partly replaced by a points system), brand mixing (legacy Sentinel Protocol / UPP vs the new ChainBounty / BOUNTY — the migration requires clarification).

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality low 1
Onchain necessity medium 2
Token necessity low 1
Evidence Tier‑1 present 3
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): the roadmap contains plans for “AI‑driven tools”, but AI is already claimed as an available feature (Quick AI Scam Check, see AI_1), so AI_0 as “intent only” does not apply
  • Evidence: Tier‑1 — https://chainbounty.io/#roadmap ; https://community.chainbounty.io/
  • Why sufficient / why not (one line): by definition, AI_0=1 is set only if AI_1..AI_4 = 0
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): “Quick AI Scam Check” performs a risk assessment based on an uploaded image/screenshot
  • Evidence: Tier‑1 — https://community.chainbounty.io/
  • Why sufficient / why not (one line): the interface explicitly indicates the AI purpose (AI scam check) and the result format (risk assessment)
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): the AI tool is visible in the UI, but no reproducible Tier‑1 “input→output” example (a sample AI check report) was found
  • Evidence: Tier‑1 — https://community.chainbounty.io/
  • Why sufficient / why not (one line): without a sample result/instructions or a public case, we do not consider the demo proven
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://chainbounty.io/ ; https://community.chainbounty.io/
  • Why sufficient / why not (one line): there are no metrics of the accuracy/recall/errors of the AI scam check in Tier‑1
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): no technical description of the AI model/architecture/versions was found in Tier‑1
  • Evidence: Tier‑1 — https://chainbounty.io/ ; https://chainbounty.gitbook.io/chainbounty
  • Why sufficient / why not (one line): there is a UI claim, but no specifications/models/versioning
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: ChainBounty Mainnet (Chain ID 51828) + Arbitrum One (ERC‑20)
  • Addresses/identifiers: RPC https://rpc.chainbounty.io; explorer https://scan.chainbounty.io/; Arbitrum One token contract 0x6a9896837021EA3eD83F623F655C119c54abE02c
  • Evidence: Tier‑1 — https://chainbounty.gitbook.io/chainbounty/chainbounty/7.-chainbountys-technological-stack/ ; https://scan.chainbounty.io/ ; https://arbiscan.io/token/0x6a9896837021EA3eD83F623F655C119c54abE02c
  • Why sufficient / why not (one line): the tech stack records the network parameters (chain id/rpc/explorer), and Arbiscan confirms the token contract
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: storage of “labeling” for 100M+ addresses on L2/L3, access via smart contracts and transactions, participation of validators in data verification
  • Evidence: Tier‑1 — https://chainbounty.gitbook.io/chainbounty/chainbounty/7.-chainbountys-technological-stack/ ; https://chainbounty.gitbook.io/chainbounty/faq
  • Why sufficient / why not (one line): Tier‑1 describes the onchain label storage and the role of validators, i.e. onchain = not only a token
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the transparency/verifiability of labels and their immutability are an argument in favor of onchain, but Tier‑1 does not prove that an equivalent cannot be built centrally
  • Evidence: Tier‑1 — https://chainbounty.gitbook.io/chainbounty/chainbounty/7.-chainbountys-technological-stack/
  • Why sufficient / why not (one line): there is no direct Tier‑1 “without onchain, X breaks down”
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token/currency BOUNTY (native) and an ERC‑20 BOUNTY on Arbitrum One
  • Evidence: Tier‑1 — https://chainbounty.gitbook.io/chainbounty/chainbounty/7.-chainbountys-technological-stack/ ; https://arbiscan.io/token/0x6a9896837021EA3eD83F623F655C119c54abE02c
  • Why sufficient / why not (one line): the tech stack records the currency symbol BOUNTY, Arbiscan confirms the ERC‑20 contract
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): BOUNTY is used to pay network fees (gas) in ChainBounty Mainnet
  • Evidence: Tier‑1 — https://chainbounty.gitbook.io/chainbounty/chainbounty/7.-chainbountys-technological-stack/
  • Why sufficient / why not (one line): the network info specifies the currency symbol BOUNTY, which implies that fees are paid in this currency
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 0
  • Claim (one line): in Tier‑1, the reward mechanic for users is described as the CBP points system, not as onchain incentives in the BOUNTY token
  • Evidence: Tier‑1 — https://chainbounty.gitbook.io/chainbounty/faq
  • Why sufficient / why not (one line): there is no Tier‑1 confirmation of “staking/slashing/rewards in BOUNTY”, only CBP points
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): nothing was found in Tier‑1 indicating that BOUNTY is used in governance; the DAO is claimed as a plan
  • Evidence: Tier‑1 — https://chainbounty.io/#roadmap
  • Why sufficient / why not (one line): the roadmap speaks of a DAO, but without token‑voting mechanics
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): as the native network currency for paying fees, BOUNTY is practically mandatory for onchain interactions
  • Evidence: Tier‑1 — https://chainbounty.gitbook.io/chainbounty/chainbounty/7.-chainbountys-technological-stack/
  • Why sufficient / why not (one line): the network description explicitly sets the currency symbol, so a “replacement” is impossible without changing the network protocol
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://chainbounty.io/ product description, roadmap (AI‑driven tools + DAO), partners (logos)
Tier‑1 https://chainbounty.gitbook.io/chainbounty ChainBounty positioning and documentation structure
Tier‑1 https://chainbounty.gitbook.io/chainbounty/chainbounty/1.-overview Tier‑1 motivation/goals: a decentralized bounty platform on L2
Tier‑1 https://chainbounty.gitbook.io/chainbounty/chainbounty/3.-background-and-legacy-of-sentinel-protocol connection with Sentinel Protocol and Uppsala Security (legacy/context)
Tier‑1 https://chainbounty.gitbook.io/chainbounty/chainbounty/7.-chainbountys-technological-stack/ L2/L3 stack, onchain labeling for 100M+ addresses, network info (chain id/rpc/explorer/currency)
Tier‑1 https://chainbounty.gitbook.io/chainbounty/faq CBP points as the reward system and the role of validators in verifying reports
Tier‑1 https://community.chainbounty.io/ web application, Quick AI Scam Check (AI claim) and examples of community investigations
Tier‑1 https://scan.chainbounty.io/ network block explorer (Blockscout)
Tier‑1 https://arbiscan.io/token/0x6a9896837021EA3eD83F623F655C119c54abE02c ERC‑20 BOUNTY on Arbitrum One (supply/contract)

No comments to display

Back to top