Sentinel.0x
Sentinel.0x — 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).
Sentinel.0x — an AI/Other | DeFi project on the Ethereum network, token (symbol: SENT).
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 project that claims an “autonomous network/system” that monitors markets and distributes rewards to token holders.
- Who it’s for: token holders and users who participate in the reward claiming mechanics (per the project’s claim).
- Why onchain/token: onchain is used for the token and the distribution/claiming contracts; the SENT token is the central element of the distribution mechanics.
How it works (very briefly)
- The user holds the token at an address: participates in the distribution via the snapshot/claim mechanics.
- The system keeps records and calculates shares: per the project’s claim, based on onchain balance snapshots.
- The user gets: the ability to claim the distributed rewards (per the Tier‑1 docs).
- Where the blockchain is: the SENT token and the smart contracts for registry/claiming/distribution.
- Token role: participation in the distribution mechanics (hold‑to‑earn/claiming) and buyback‑and‑burn (as claimed).
Quick links: AI thesis fit
Project passport
| Field | Value |
|---|---|
| Project name | Sentinel.0x |
| Also known as (aliases) | SENT, Sentinel |
| Logo (logo) | ../assets/455_sentinel-xo_logo.png |
| Token symbol (ticker) | SENT |
| Category | AI/Other | DeFi |
| Primary chain (chain) | Ethereum |
| Type | EVM |
| Network status | mainnet |
| Consensus (consensus) | PoS (Ethereum) |
| Launch date (launch_date) | — |
| Project status (status) | active |
| Token (standard) | ERC-20 |
| Token contract | 0xe88baab9192a3cb2c0a50182ab911506e5adc304 |
| Token model (token_type) | — |
| Max supply | 3,864,215,077.207802135354220678 SENT |
| Issuance | — |
| Tokenomics (tokenomics, brief) | The Tier‑1 docs claim buyback‑and‑burn and distribution of rewards by ownership share. |
| Governance | — |
| Admins/keys | — |
| Audit | — |
| Bug bounty | — |
| Team (team) | — |
| Funding (investors/funding) | — |
| AI component (ai_component) | autonomous market monitoring + execution |
| Use‑case (use_case) | rewards distribution to token holders |
| DecAI Fit — AI thesis fit | 3/6 — medium alignment with the Decentralized AI thesis |
| DecAI Fit component summary | ai_score 1 / onchain_score 2 / token_score 1 / evidence_score 2 |
| Last verified | 2026-02-11 |
Links (links_*)
| Type | Link |
|---|---|
| Website | https://sentinelxo.com/ |
| Docs | https://sentinelxo.com/docs |
| GitHub | — |
| Releases / Changelog | — |
| Whitepaper | https://sentinelxo.com/whitepaper |
| Roadmap | — |
| Security advisories | — |
| Explorer | https://etherscan.io/token/0xe88baab9192a3cb2c0a50182ab911506e5adc304 |
| X | https://twitter.com/xCellar_ |
| Discord | — |
| Telegram | https://t.me/xCellarStudios |
| Medium | — |
| Audit report(s) | — |
| Bug bounty | — |
| CoinGecko (profile, reference) | — |
| CoinMarketCap (profile, reference) | https://coinmarketcap.com/currencies/sentinel-xo/ |
General project overview
Sentinel.0x is described in the Tier‑1 documentation as a system that monitors markets and executes operations, and then distributes rewards according to rules tied to ownership of the SENT token. An important boundary of the assessment: Tier‑1 proof of the operation of the “AI component” in the form of reproducible metrics/benchmarks/model architecture is not identified — there are only declarative descriptions of the mechanics.
Features/modules
- Reward distribution: rules for distributing rewards and claiming (docs).
- Onchain contracts: the token and the related registry/claiming contracts (listed in the docs).
- AI part (claimed): monitoring/execution as an “AI network” (without technical details per Tier‑1).
Typical scenarios
- Scenario 1: a user holds SENT at an address → participates in the calculation of the rewards share via snapshots.
- Scenario 2: a user connects a wallet → checks eligibility and claims rewards (if available).
- Scenario 3: a user checks the onchain data of the token/contracts via the explorer.
Getting started (wallet/network)
- What you need: an EVM wallet for Ethereum and access to the dashboard/claiming (see the Tier‑1 docs).
- Network/chain: Ethereum.
- Fees: Ethereum network fees (gas) for transactions (claim/transfer, etc.).
Architecture/tech (non‑AI)
- Components: the SENT token (ERC‑20) and a set of smart contracts for registry/claiming/distribution (see the docs).
- Participant roles: token holders; participants who claim rewards.
- Where logic runs: distribution/eligibility and claiming rely on onchain contracts + offchain interfaces.
- Dependencies: Ethereum RPC infrastructure and the project’s offchain UI/services.
Token/economics (expanded, no forecasts)
- Token utility: hold‑to‑earn/participation in the distribution of rewards (as claimed in the Tier‑1 docs).
- Protocol necessity drivers: the token is the key to eligibility/the share of the rewards distribution and to the burn mechanics (as claimed).
- Who pays fees: users (gas on Ethereum) for onchain operations.
- Where fees go: — (not established per Tier‑1).
- Issuance/burn: the docs claim buyback‑and‑burn mechanics; the parameters/implementation require separate verification.
- Security/incentive mechanisms: balance snapshots and eligibility checks (as claimed in the docs).
- Distribution: proportional to the ownership share (as claimed in the docs).
- Treasury: —.
Governance
- Who makes decisions: — (not established per Tier‑1).
- How protocol parameters change: —.
- Where decisions are discussed/made: —.
- Keys/multisig: —.
Security and incidents
- Audits: — (not established per Tier‑1).
- Bug bounty: — (not established per Tier‑1).
- Incidents: — (not established per Tier‑1).
- Threat model: the risks are related to the correctness of the smart contracts (claiming/registry), to the quality of the offchain interfaces and to the claims about “autonomous trading”.
Project status and timeline
- Current status: active.
- Key releases/milestones: — (not established per Tier‑1).
- Roadmap: —.
Ecosystem/integrations
- Integrations: contracts and onchain mechanics on Ethereum; an offchain dashboard/claim UI (see the docs).
- Partners: — (not established per Tier‑1).
- Where it’s actually used: the claiming/reward mechanics are described in the docs (see
links_*).
AI component of the project
- What is real AI here? The Tier‑1 docs/whitepaper claim an “AI network”, but Tier‑1 proof of an AI component (model/metrics/architecture) is not identified.
- What is truly onchain? the SENT token and the registry/claiming/distribution contracts (listed in the docs); the token contract is visible on Etherscan.
- Why is a token needed? participation in the distribution of rewards and the burn/claiming mechanics (as claimed).
- Red flags (based on the information found): “AI trading” without verifiable artifacts; a high share of marketing language; dependence on the correctness of the contracts and on the transparency of the real onchain flows.
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 | 2 |
Details
AI reality
AI_0 — AI intent (Tier‑1 roadmap) (1/0)
- AI_0 (decision): 1
- Claim (one line): In the Tier‑1 docs/whitepaper the project claims an autonomous monitoring/execution system as an “AI network”.
- Evidence: Tier‑1 — https://sentinelxo.com/docs ; https://sentinelxo.com/whitepaper
- Why sufficient / why not (one line): This is a declaration of intent, but not proof of an AI model/metrics.
- Conflict note (if any): —
AI_1 — what the AI does (1/0)
- AI_1 (decision): 0
- Claim (one line): No Tier‑1 tech description of what exactly the AI component does (model/data/algorithms) and how its quality is measured was found.
- Evidence: Tier‑1 — https://sentinelxo.com/docs
- Why sufficient / why not (one line): There are descriptions of “core engines”, but without reproducible AI artifacts — we set 0.
- Conflict note (if any): —
AI_2 — demos/examples (1/0)
- AI_2 (decision): 0
- Claim (one line): The docs describe claiming/the mechanics, but this is not a demonstration of an AI component as “AI reality”.
- Evidence: Tier‑1 — https://sentinelxo.com/docs
- Why sufficient / why not (one line): AI_2=1 requires a demo artifact of the AI part; not identified per Tier‑1.
- Conflict note (if any): —
AI_3 — metrics/quality (1/0)
- AI_3 (decision): 0
- Metrics: —
- Context (version/date/how measured): —
- Evidence: Tier‑1 — https://sentinelxo.com/docs
- Why sufficient / why not (one line): Quality metrics of the AI component (not financial indicators) are not established per Tier‑1.
- Conflict note (if any): —
AI_4 — tech description/architecture/versions (1/0)
- AI_4 (decision): 0
- Claim (one line): A tech description of the AI models/versions is not identified per Tier‑1.
- Evidence: Tier‑1 — https://sentinelxo.com/docs
- Why sufficient / why not (one line): Without specific AI artifacts (architecture/versions/metrics) we set 0.
- Conflict note (if any): —
Onchain necessity
OC_1 — contracts/addresses/chain (1/0)
- OC_1 (decision): 1
- Chain: Ethereum
- Addresses/identifiers: SENT token: 0xe88baab9192a3cb2c0a50182ab911506e5adc304
- Evidence: Tier‑1 — https://etherscan.io/token/0xe88baab9192a3cb2c0a50182ab911506e5adc304 ; https://sentinelxo.com/docs
- Why sufficient / why not (one line): The onchain artifact (ERC‑20 token) is confirmed by the explorer; the docs list additional contracts.
- Conflict note (if any): —
OC_2 — onchain beyond just a token (1/0)
- OC_2 (decision): 1
- What useful logic is onchain: the registry/eligibility/claiming contracts and the distribution (described in the docs).
- Evidence: Tier‑1 — https://sentinelxo.com/docs
- Why sufficient / why not (one line): The Tier‑1 docs list the contract addresses and the claiming/registry mechanics.
- Conflict note (if any): —
OC_3 — onchain is critical (1/0)
- OC_3 (decision): 0
- “Replace the blockchain” test: no Tier‑1 justification was found that without the blockchain the system loses a key property (rather than being implementable as a centralized distribution service).
- Evidence: Tier‑1 — https://sentinelxo.com/docs
- Why sufficient / why not (one line): OC_3 requires an explicit “replace the blockchain” argument; not identified per Tier‑1.
- Conflict note (if any): —
Token necessity
TK_0 — no token (1/0)
- TK_0 (decision): 0
- Claim (one line): The project has a token, SENT (ERC‑20), on Ethereum.
- Evidence: Tier‑1 — https://etherscan.io/token/0xe88baab9192a3cb2c0a50182ab911506e5adc304
- Why sufficient / why not (one line): The explorer records the token, the symbol and the max total supply.
- Conflict note (if any): —
TK_1..TK_4 (1/0)
TK_1 — payment for the service (1/0)
- TK_1 (decision): 0
- Claim (one line): “Payment for the service” with the token as a mandatory mechanism is not established per Tier‑1.
- Evidence: Tier‑1 — https://sentinelxo.com/docs
- Why sufficient / why not (one line): In Tier‑1 sources the token is described as an element of the reward/burn mechanics.
- Conflict note (if any): —
TK_2 — incentives/collateral/penalties (1/0)
- TK_2 (decision): 1
- Claim (one line): The Tier‑1 docs describe a hold‑to‑earn model: ownership of SENT affects the share of rewards and eligibility.
- Evidence: Tier‑1 — https://sentinelxo.com/docs
- Why sufficient / why not (one line): This is an incentive/distribution mechanic tied to ownership of the token.
- Conflict note (if any): —
TK_3 — governance (1/0)
- TK_3 (decision): 0
- Claim (one line): Governance use of the token is not established per Tier‑1.
- Evidence: Tier‑1 — https://sentinelxo.com/docs
- Why sufficient / why not (one line): There is no description of voting/governance via the token.
- Conflict note (if any): —
TK_4 — token is replaceable (1/0)
- TK_4 (decision): 0
- Claim (one line): The replaceability of the token with another mechanism is not established per Tier‑1.
- Evidence: Tier‑1 — https://sentinelxo.com/docs
- Why sufficient / why not (one line): TK_4 requires an explicit argument; not identified per Tier‑1.
- Conflict note (if any): —
Evidence (table)
| Tier | Source | What it proves |
|---|---|---|
| Tier‑1 | https://sentinelxo.com/docs | Tier‑1 description of the registry/claiming/distribution mechanics and the list of contracts. |
| Tier‑1 | https://sentinelxo.com/whitepaper | Tier‑1 claim of an “AI network” and descriptions of the token mechanics (as claims). |
| Tier‑1 | https://etherscan.io/token/0xe88baab9192a3cb2c0a50182ab911506e5adc304 | Onchain fact: the SENT ERC‑20 token, contract and max total supply. |
No comments to display
No comments to display