Tri-Proof Guard
Tri-Proof GuardDocs
Open Demo
Complete product documentationSolana-first security layer

Understand every Tri-Proof Guard decision.

Tri-Proof Guard helps Web3 teams review campaign wallet lists, reduce reward leakage, and protect users before risky wallet signatures. This guide explains the full product layer: Sybil analysis, ScamGuard, evidence scoring, admin intelligence, exports, and API integration.

Sybil review

campaign wallet lists

ScamGuard

pre-sign protection

API ready

partner integrations

Decision map

From raw input to operational output

Live guide

1. Upload or paste campaign wallets

Start with a CSV, manual wallet list, or public mini audit sample from an airdrop, quest, testnet, allowlist, loyalty campaign, or rewards program.

2. Normalize and validate rows

The engine removes duplicates, separates invalid rows, detects chain context, and keeps parse issues visible so teams know exactly what was accepted.

3. Collect provider evidence

When providers are configured, Tri-Proof Guard enriches wallets with account age, balances, token activity, signatures, owner programs, and contract context.

4. Score behavior and reputation

Signals are weighted through strict, balanced, or conservative policy modes instead of relying on a single weak rule.

5. Build the evidence graph

Funding origins, referrers, referral codes, timing, and known-service context are joined into explainable campaign components.

What it solves

One security story for campaigns and wallet actions.

Web3 teams face two related problems: fake or low-quality wallets can drain campaign rewards, and users can be pushed into unsafe claim, mint, approval, or wallet-signing flows. Tri-Proof Guard connects both surfaces into one review layer so the team can make better decisions before value moves.

The product is built around explainability. Every warning should answer five questions: what was scanned, what evidence was available, what risk drivers appeared, what the system recommends, and what would make the action safer.

Sybil wallet analysis
Reviews campaign wallet lists before rewards are distributed. It focuses on eligibility, suspicious clusters, known entities, low-quality wallets, and decision exports.
ScamGuard pre-sign protection
Checks URLs, wallets, token mints, contracts, and transaction intent before a user clicks or signs. It is built for browser extension, API, and partner app flows.
Admin intelligence console
Lets the team manage trusted domains, suspicious domains, known bad spenders, verified projects, and override decisions without changing code.
API and partner integration
Wallets, launchpads, campaign platforms, and dApps can call authenticated endpoints to receive consistent ScamGuard and wallet-risk decisions.
Workflow

How a wallet list becomes a decision list.

The workflow is designed for campaign operators: upload, enrich, inspect, decide, export, and keep enough evidence to defend the decision later.

01
Upload or paste campaign wallets
Start with a CSV, manual wallet list, or public mini audit sample from an airdrop, quest, testnet, allowlist, loyalty campaign, or rewards program.
02
Normalize and validate rows
The engine removes duplicates, separates invalid rows, detects chain context, and keeps parse issues visible so teams know exactly what was accepted.
03
Collect provider evidence
When providers are configured, Tri-Proof Guard enriches wallets with account age, balances, token activity, signatures, owner programs, and contract context.
04
Score behavior and reputation
Signals are weighted through strict, balanced, or conservative policy modes instead of relying on a single weak rule.
05
Build the evidence graph
Funding origins, referrers, referral codes, timing, and known-service context are joined into explainable campaign components.
06
Export decisions and evidence
Teams can review approved, Gray Zone, and rejected outputs, then export CSV or report data for reward operations and internal audit trails.
Evidence model

Risk is built from layers, not one shortcut.

A good security product should avoid both extremes: calling every unknown project dangerous, or trusting every branded page blindly. Tri-Proof Guard weighs wallet evidence, domain evidence, transaction evidence, and reviewer context separately.

01

Input quality

Duplicate rows, invalid addresses, chain mismatch, CSV parsing errors, and row-level exclusions.

02

On-chain account state

Age, balance, token holdings, owner program, transaction count, and sampled historical activity.

03

Behavioral signals

Funding concentration, campaign-only usage, low diversity, similar timing, and repeated wallet patterns.

04

Graph evidence

Typed funding and referral edges, connected components, confidence, service neutralization, and corroborated coordination findings.

05

Reputation intelligence

Trusted project domains, suspicious surfaces, known bad counterparties, verified mints, and admin overrides.

06

Transaction semantics

Human-readable interpretation of approval, transfer, authority, and contract interaction intent.

07

Reviewer context

Primary reason, confidence, risk drivers, next action, and limitations behind the decision.

Wallet age
Newly created wallets are reviewed more carefully when combined with weak history, low balance, or campaign-only behavior.
Transaction history
Low activity, thin signature history, repetitive actions, and missing organic usage reduce confidence.
Funding and referral graph
Unknown funder fan-out, referral overlap, cycles, and timing bursts are correlated while recognized exchange or service funding is neutralized.
Contract diversity
The engine checks whether wallets show broad real usage or narrow one-purpose interaction patterns.
Known entities
Exchange, bridge, service, token mint, protocol, and program-owned accounts are marked for review or exclusion.
Suspicious clusters
Related wallets are grouped so reviewers can inspect patterns across the list instead of one address at a time.
Domain reputation
ScamGuard separates verified project domains from disposable claim, airdrop, mint, and reward lookalike domains.
URL Sandbox
ScamGuard passively reads bounded HTML through validated public IPs without executing JavaScript or connecting a wallet.
Scam DNA
Page structure, scripts, behavior, redirects, and wallet targets are compared across domains to find reused campaign kits.
Signing intent
Transaction payloads are checked for approvals, authority changes, transfers, close-account actions, and suspicious spenders.
Contract intelligence
EVM scans can inspect bytecode, verification, proxy shape, and deployer or spender reputation when API keys are configured.
ScamGuard

Pre-sign protection for the moment users are most exposed.

ScamGuard is the user-facing risk layer. It can scan the current page, every visible link, token mints, wallets, EVM contract targets, and transaction payloads. URL scans add an SSRF-safe passive sandbox and cross-domain Scam DNA comparison without executing page JavaScript.

1. Classify the surface

URL, wallet, token mint, contract address, serialized transaction, or wallet request JSON is routed to the right scanner.

2. Check source context

Domain patterns, trusted registries, suspicious TLDs, and project intelligence are evaluated together.

3. Open URLs passively

The URL Sandbox validates every DNS answer and redirect, pins the public destination IP, limits time and bytes, and never executes page code.

4. Compare Scam DNA

DOM, scripts, copy, styles, behavior, redirects, and wallet targets are compared with prior cross-domain campaign evidence.

5. Decode intent

The engine explains what the request appears to do before the user signs it.

6. Score and explain

The result includes risk level, confidence, security score, primary reason, and recommended actions.

7. Protect where users act

The same engine powers the public scanner, Chrome extension, Telegram Bot, and B2B API endpoint.

Decision outputs

Simple labels for complex evidence

Approved

No major risk pattern was detected from the available evidence. The wallet can be considered a candidate for automatic inclusion, subject to project policy.

Gray Zone

The wallet or interaction needs human review because one or more signals require context. This is the right bucket for uncertain but not clearly malicious cases.

Rejected / Not Eligible

The wallet is high-risk, inactive, protocol-owned, unreadable, clustered, or otherwise unsuitable for automatic reward distribution.

Critical / Block

ScamGuard uses this for dangerous pre-sign situations such as known scam domains, unlimited approvals to risky spenders, or authority-changing transactions.

How to read results

The score prioritizes review; the explanation guides action.

A numeric score is useful for sorting, but it is not enough for an operator. Tri-Proof Guard pairs every result with a primary reason, confidence level, risk drivers, and next step so the reviewer understands why the score exists.

Confirm the official project domain and social channels.
Check whether the wallet action matches the user intent.
Review Gray Zone clusters before sending rewards.
Compare token mints, spender addresses, and program IDs with official docs.
Export clean, review, and rejected lists before the final distribution.
Treat every score as decision support, not an identity claim.
Operations and integration

Use it as a dashboard, scanner, extension, or API.

Different teams need different surfaces. The product keeps the same decision language across public demos, full analyses, browser protection, and partner integrations.

Mini Audit
Account-backed preview
Best for first look, sales demos, and quick campaign triage.
Dashboard Analysis
Saved project workflow
Best for full wallet-list review, team decisions, exports, and repeat operations.
ScamGuard Scanner
Pre-click and pre-sign safety
Best for suspicious URLs, mints, wallets, and transaction payloads.
Chrome Extension
Live browser protection
Best for users who want warnings directly on Web3 app pages.
Telegram Bot
Chat-native ScamGuard scans
Best for users and communities that want to paste suspicious links, wallets, tokens, or transactions into Telegram.
Group Guardian
Managed community defense
Best for Telegram groups that need automatic warnings, scan history, repeated-campaign detection, admin controls, and daily summaries.
B2B API
Embedded security layer
Best for wallets, launchpads, and campaign platforms that need automated risk checks.
API touchpoints
Core endpoints that power the public product and partner integration story.

POST /api/audit/mini

Authenticated Sybil preview for wallet lists and fast campaign triage.

POST /api/scamguard/scan-url

Scan a claim, mint, reward, presale, or suspicious Web3 URL.

POST /api/scamguard/scan-token

Check token mint or contract context before interaction.

POST /api/scamguard/scan-transaction

Decode Solana instruction text, serialized payloads, or EVM wallet request JSON.

POST /api/telegram/webhook

Telegram Bot and Group Guardian webhook for private scans and group link warnings.

GET /api/telegram/daily-summary

Protected Vercel cron endpoint for per-group 24-hour security summaries.

GET/PATCH /api/admin/telegram/groups

Admin-only Group Guardian operations, approval, thresholds, and activity.

POST /api/v1/scamguard/scan

Authenticated partner endpoint for wallets, launchpads, extensions, and dApps.

POST /api/v1/analyze

Authenticated wallet-list analysis entrypoint for campaign teams.

Known limitations
Professional security tools should state uncertainty clearly.
A clean score does not guarantee safety; it means no major risk signal was found from available evidence.
A cluster is a review signal, not proof that the same person controls every wallet.
Provider limits, RPC availability, and missing historical data can reduce confidence.
Trusted project context can reduce false positives, but it should never hide dangerous transaction intent.
FAQ

Common product questions.

These are the questions a project team, grant reviewer, wallet partner, or security reviewer is most likely to ask first.

Is Tri-Proof Guard only for Solana?
The campaign-risk product is Solana-first, but ScamGuard already supports Solana and EVM surfaces. EVM coverage includes URL scans, transaction intent, approval payloads, contract context, and spender intelligence.
Why do verified projects sometimes receive caution?
Because project reputation and transaction safety are separate. A real project can still ask for a risky approval, and an unknown page can still be harmless. Tri-Proof Guard explains which part caused the warning.
Does Tri-Proof Guard make the final reward decision?
No. It provides operational decision support. The final inclusion, rejection, or manual-review decision remains with the project team.
Can reports be exported?
Yes. The full dashboard supports decision-oriented exports. The public sample report also shows how approved, Gray Zone, and rejected rows are explained.
What should a user do when ScamGuard warns?
Slow down, verify the official source, compare the wallet popup with the expected action, and avoid signing if the transaction asks for unexpected approvals or authority changes.
How does the system improve over time?
Admin intelligence, verified domains, threat feeds, user feedback, contract intelligence, and new decode rules can be added without changing the core user flow.

Ready to test the product?

Start with the public mini audit, open the ScamGuard scanner, or contact the team for a project-specific campaign review.