Whitepaper · July 2026
Self-Custody Wallet Security, With a Mission Beyond Profit
Kanshi Guardian is a Web3 wallet security platform providing protection across 24 blockchain networks through a Progressive Web App and a smart-contract layer that is pre-audit and not yet deployed. Its security and analysis tools operate across every supported network, real-time server-side monitoring covers a defined set of actively-monitored chains, and its on-chain Guardian Vault is designed to enforce time-delayed asset protection wherever it is deployed once audited. Together these address the class of theft — approval exploits, phishing, drainer contracts, address poisoning — that has cost self-custody users billions of dollars with essentially no recourse once funds are gone.
Kanshi Guardian's subscription revenue is structurally allocated so that the large majority funds a Victim Assistance Fund, administered as a registered nonprofit once it reaches a defined threshold. This document describes the problem, the product, the underlying technology and its security posture, the business model, and the roadmap ahead.
Self-custody gives crypto users direct control of their assets — and removes every safety net that exists around that control elsewhere in finance. There is no fraud department to call, no chargeback, no insurance most users can access. A single malicious approval, a spoofed signature request, or a convincing phishing link can drain a wallet in seconds, and once a transaction confirms on-chain, it is final.
The tooling available to most users has not kept pace with the sophistication of the attacks against them. Wallet software generally shows a transaction's raw parameters, not its actual effect — a user approving a token spend has no built-in way to know whether that approval is unlimited, or whether the contract on the other end is a known drainer. The result is an asymmetry: attackers iterate quickly and share tooling; individual users face each new threat alone, usually for the first time, with no warning until the loss has already happened.
Kanshi Guardian is a Progressive Web App — installable directly from the browser, with no app-store dependency — providing 17 distinct security tools organized into five categories, aligned to the points in a transaction's lifecycle where a user actually needs to make a decision:
Kanshi Guardian's security and analysis tools — URL and message screening, contract and signature simulation, token risk scoring, approval management, and wallet tracing — operate across 24 blockchain networks, including Ethereum and its major L2s, Solana, Tron, XRPL, and other leading EVM and non-EVM chains. Threat intelligence is aggregated from multiple independent sources (on-chain data, community-reported scam databases, and simulation-based honeypot detection) rather than any single proprietary dataset.
The contract-analysis capability is being extended. Kensakan (検査官, "inspector") is an in-development multi-language contract-analysis engine intended to succeed the current contract simulator: it routes a contract to the right language and virtual-machine pipeline, checks it against a continuously-updated library of known drain and exploit patterns, and returns a confidence-graded report. Consistent with the platform's discipline, Kensakan is designed to report whether it did or did not observe known patterns — never a guarantee of safety, since no pattern library protects against unknown or novel exploits. It is in active development, not yet a shipped capability.
Real-time protection is delivered in tiers, and the platform is deliberate about not overstating it. Seven chains (Ethereum, Polygon, Arbitrum, Optimism, Base, zkSync Era, and Linea) receive instant push alerts — via internal-transfer-capable webhooks — the moment a suspicious withdrawal is detected. A further set of chains (including BNB Chain, Avalanche, Gnosis, Scroll, Celo, Mantle, Unichain, Ronin, Berachain, Monad, and Sonic) is monitored on the same real-time webhook mechanism, with the shortest selectable withdrawal delay held more conservatively where live delivery has been confirmed but not yet continuously observed. World Chain and Robinhood are the most recent additions to the supported set; their monitoring wiring is in progress and they are not yet claimed as continuously monitored. On chains outside the actively-monitored set, monitoring is user-determined — the app checks a user's vault whenever it is opened, with an optional reminder — while the on-chain Guardian Vault protection is designed to work identically regardless of how the chain is monitored, once deployed. This tiered coverage is disclosed clearly at the point a user deploys a vault, and the actively-monitored set is expected to expand as the platform's alerting infrastructure matures.
Kanshi Guardian is wallet-agnostic: it connects to existing wallets rather than replacing them, and holds no custody of user funds. On EVM chains it supports any standard EIP-1193 injected wallet — including MetaMask, Trust Wallet, Coinbase Wallet, OKX Wallet, Rabby, and Brave Wallet — and connects to mobile wallets over WalletConnect v2. On Solana it detects Phantom, Solflare, Backpack, Glow, and Brave Wallet, alongside any standard Solana provider.
Because detection follows the underlying wallet standards rather than a fixed hardcoded list, wallets that implement EIP-1193 (EVM) or the standard Solana provider interface are recognized automatically. On mobile, the app can be opened directly inside a wallet's built-in DApp browser — such as Trust Wallet, MetaMask Mobile, Coinbase Wallet, or Phantom — where the connected wallet is detected without any additional setup.
The platform is built as a React-based Progressive Web App backed by serverless infrastructure, with a smart-contract layer. The contracts are described here by function; their full source will be published open-source upon completion of an independent audit. The layer comprises:
The smart contracts have not been independently reviewed or audited, and no contract is deployed to mainnet on any chain. No formal audit has been commissioned or completed. Commissioning and completing an independent audit — and remediating its findings — is a prerequisite for launch, not a step already underway. The contracts described in this document are works in progress; their source will be published for public review once an independent audit is complete.
Kanshi Guardian's off-chain security tools are in open testing and available for evaluation, but paid subscriptions and every on-chain payment flow remain closed and will stay closed until an independent audit is complete and its findings are remediated. This sequencing is deliberate: the trust the platform asks users to place in it around their own wallet security should be earned before revenue depends on it, and stating an audit is underway before one is commissioned would be exactly the kind of claim this project refuses to make. Until independent audits and verifications are complete, Kanshi Guardian's services are provided for informational and product-development purposes only — not as verified security guarantees.
Every tool described so far shares one deliberate limitation: Kanshi Guardian is a warning layer. It identifies threats, flags dangerous tokens and addresses, and alerts the user before a risky action — but it does not, and cannot, act on the user's behalf. A user can always proceed past any warning. This is a direct consequence of the platform's first principle: Kanshi never takes custody of user funds and never holds the keys. The safety it provides is information and time, not control.
Kanshi TripGuard is the planned protection layer that narrows that gap without crossing the custody line. Built on account-abstraction standards — EIP-7702 delegation and ERC-4337 modules — TripGuard is designed to let a user opt into an on-chain guard that places a deliberate barrier in front of interactions with flagged contracts and addresses: a transaction toward a known drainer, an approval to a blocklisted spender, or an interaction with a quarantined token would meet an on-chain speed-bump rather than a silent, one-tap execution.
Critically, TripGuard is a guard the user controls, not a lock the platform imposes. Kanshi never takes custody, and TripGuard is designed so the user can always override it and proceed if they genuinely intend to — its purpose is to convert an accidental, irreversible mistake into a deliberate, reconsidered choice. It cannot freeze a user's assets, cannot move them, and cannot prevent a determined user from acting; it can only insist that a dangerous action be intentional.
The quarantine list works in conjunction with TripGuard: tokens flagged as malicious are added to the quarantine list, and that list is what TripGuard checks to place its on-chain speed-bump in front of an interaction with a quarantined token. Because Kanshi TripGuard operates at the transaction-authorization layer, it carries a higher security burden than the platform's off-chain tools, and it will not be deployed until its contracts complete the same independent audit the rest of the smart-contract suite must undergo. Until then, the quarantine list, the blocklist, and the signing guards remain what they are today: honest warnings that leave the final decision, and the final control, entirely with the user.
| Tier | Monthly | Annual |
|---|---|---|
| Basic | $1/mo | $11/yr |
| Starter | $8/mo | $81.60/yr |
| Pro | $14/mo | $142.80/yr |
| Trader | $24/mo | $244.80/yr |
| Business | $49/mo | $499.80/yr |
| Enterprise | $149/mo | $1,519.80/yr |
New users begin with a 60-day free trial, after which access continues on the $1/month Basic tier (or any higher tier). There is no indefinite free plan — an earlier free tier was discontinued as unsustainable; the 60-day trial and the deliberately low $1 Basic entry price are how Kanshi keeps protection reachable while remaining viable. Annual billing saves 15% on every tier except Basic, which is $11/yr (about 8% off its monthly price). The Basic tier does not include additional wallet slots.
Subscription revenue is split on-chain by the subscription contract and routed to the Victim Assistance Fund, the operating business, and (where applicable) an investor. Kanshi maintains two revenue-model designs, and which one is used depends on whether the company raises outside investment. Both are pre-audit designs; neither is deployed. Exactly one will be independently audited and deployed. They are disclosed here openly so the difference is understood.
If Kanshi does not raise, the mission takes the maximum. The nonprofit's share ramps from 50% to 85% of revenue as the platform grows — rising 5% for every $4,000 of subscription revenue received in a 30-day period (at current pricing assumptions, roughly every 380 to 450 paying subscribers), with the difference drawn from a maintenance allocation that starts high (to let the company fund its own early operating reserve without investment) and shrinks as revenue grows. The step is measured on revenue rather than subscriber count so it cannot be inflated with fake accounts, and once a step is reached it never reverses. A 10% founder royalty and a 5% maintenance stream hold through the ramp.
| Stage | Nonprofit | Maintenance | Royalty |
|---|---|---|---|
| Launch (under $4,000 in a 30-day period) | 50% | 40% | 10% |
| Ramping (+5% per $4,000 in a 30-day period) | → 85% | → 5% | 10% |
| Ramp complete ($28,000+ in a 30-day period) | 85% | 5% | 10% |
If Kanshi raises, a 10% investor share is introduced, drawn from the same pool — so the nonprofit's ramp tops out at 75% rather than 85%, with the investor receiving 10% and the founder royalty and maintenance unchanged. The 10% difference between the two models is precisely the investor's return: the mission still receives three-quarters or more of all revenue, and taking investment never reduces the mission below a dominant majority. This is the deliberate design point — a real investor return that does not abandon the nonprofit.
Shared across both versions: the 10% founder royalty reduces, one-way, to 7.5% once the platform reaches $10 million in cumulative gross subscription revenue, with the freed 2.5% going to the nonprofit. Separately, the 5% maintenance stream can be reduced once to 2.5% — a one-way change callable only by the registered nonprofit's board (a multi-signature wallet), at the board's discretion, once it judges the fund can sustain operations; the operating business has no path to force or block it. When the nonprofit is seated it takes control of the maintenance stream to fund its own operations (victim mental-health support and forensic investigation). As these shifts take effect the mission's total share rises accordingly — ultimately toward ~90% of revenue in the independent model.
Once the Victim Assistance Fund reaches $750,000, Kanshi Guardian will formally establish a registered nonprofit to administer it independently of the platform's operating business — separating the mission from any single founder or company, permanently.
Reaching the threshold is not simply a symbolic milestone — it initiates a defined, sequenced set of actions before any funds are distributed:
KanshiCommunityAid.sol disbursement contract is independently verified before a single dollar is released, on the same audit-first principle applied to the rest of the platform.Disbursement is governed on-chain by KanshiCommunityAid.sol, designed so that no single party can move funds and so that aid reaches verified victims rather than fraudulent claimants:
| Phase 1 Complete | Core threat-intelligence integration: real-time transaction risk scoring, mixer and scam-wallet detection, honeypot simulation. |
| Phase 2 | Kensakan multi-language contract-analysis engine (successor to the contract simulator), wallet-clustering and fund-flow analysis, an explainable risk-scoring engine, deployment of Guardian Vault's time-delay escrow on EVM chains following audit, and extension of the vault to Solana and the XRP Ledger. |
| Phase 3 | Expanded on-chain analytics, an internal cross-user threat-intelligence pool, and machine-learning-based detection models. |
Kanshi Guardian is currently founder-led, with a defined path toward independent, accountable governance as the platform matures. Team growth is already underway: the platform's own admin infrastructure now supports Manager and Support staff roles with independent, auditable accounts — the same access-control discipline the product applies to its users' wallets is applied internally to the team operating it.
The platform's social mission is not left to founder discretion. As described in Section 5, the Victim Assistance Fund is governed by the platform's smart contract infrastructure, and on reaching its funding threshold will be administered by a registered nonprofit operating independently of the operating business — ensuring the mission outlasts any single individual or company.
Self-custody should not mean facing modern attackers with 2015-era tooling, and the harm caused by crypto fraud should not simply be absorbed by its victims with no recourse at all. Kanshi Guardian is built to close both gaps at once — real-time protection for the wallets using it today, and a structural, on-chain commitment to the people harmed by the threats it exists to stop.
kanshiguardian.com