ShotsAI Whitepaper

Version: v1.0 · 2026-05 Protocol Name: ShotsAI Protocol Token: $SHOT (ShotToken) Deployed Networks: BNB Smart Chain Mainnet (2026-05-12), Kasplex Network Mainnet (2026-05-11); Ethereum / BSC / Kasplex testnets available Repository: https://github.com/shots-chat/ShotsAI Website: https://shots.chat

Executive Summary

ShotsAI is a full-stack DApp protocol that fuses crypto payments, social, and privacy into a single product. It bundles the safety mechanisms users expect from traditional finance (escrow, dispute protection, recognizable counterparties), the hard guarantees of crypto-native systems (non-custodial control, on-chain finality, permissionless participation), and the social semantics of the messaging era (friends, chat, notifications) — all into one integrated experience. The outcome: users can transact in P2P, C2B, and B2B contexts at a privacy strength they choose, not one a platform forces on them.

ShotsAI's core product power comes from five composable on-chain payment modes + one end-to-end encrypted social layer + one dual-track dispute arbitration system:

1. Time-Locked Escrow — funds locked on-chain, auto-released on schedule, disputable by either party, resolved either by a multi-sig committee or by token-weighted DAO vote.
2. Stealth Payments — one-time stealth addresses derived from secp256k1 ECDH with view-tag-accelerated scanning, making each transfer fully unlinkable on-chain.
3. Phantom Routing — 3–10 hops through ephemeral stealth addresses with randomized delays. A workable, engineering-grade defense against chain-graph analysis, offered in Basic / Advanced / Maximum tiers.
4. Batch Send — up to dozens of recipients in a single transaction, ~60% gas savings versus sequential transfers, composable with stealth addresses to enable "batch stealth payroll."
5. Hybrid Smart Recommend — a 4-step questionnaire wizard that maps user preferences (amount, speed, privacy, dispute protection) to the optimal payment composition automatically.

The social and protocol layers include: end-to-end encrypted chat (AES-GCM messages + RSA-OAEP key exchange; the server never sees plaintext), a friend graph and request lifecycle, 11 categories of real-time notifications, an on-chain daily check-in primitive (growth infrastructure), and $SHOT — the ShotsAI native protocol token (ERC20 + Permit + Votes, fixed 1 billion supply).

All contracts are live on BSC Mainnet and Kasplex Mainnet (2026-05-11/12). All five payment modes and the social layer are usable today. This whitepaper is written for investors, integration partners, the developer community, and future DAO members. It comprehensively covers the market positioning, technical architecture, token economy, security model, compliance posture, and roadmap.

Table of Contents

1. Industry Background and Problem Statement
2. Market Opportunity and Target Users
3. ShotsAI Protocol Overview
4. Five Payment Modes: Deep Product Dive
5. The Encrypted Social Layer
6. Contract Layer Architecture
7. Backend Service Architecture
8. Frontend Experience and Design Language
9. Multi-Chain Strategy
10. User Personas and Use Cases
11. Competitive Landscape and Differentiation
12. $SHOT Token Economy
13. Operational Infrastructure: Volume Tool
14. Threat Model and Security
15. Compliance Posture and Regulatory Considerations
16. Roadmap
17. Governance and DAO Evolution
18. Team, Partners, and Community
19. Risk Disclosure
20. Conclusion
21. Glossary
22. On-chain Address Inventory

1. Industry Background and Problem Statement

1.1 The State of Crypto-Native Payments

Over a decade of development has put the foundational infrastructure for on-chain payments in place: ERC-20 stablecoins move freely 24/7 across EVM chains; L2s like BNB Chain, Polygon, Arbitrum, and Base have compressed per-transaction cost to the cent level; wallet onboarding (WalletConnect, RainbowKit, Account Abstraction) is approaching Web2 UX standards.

And yet, crypto payments have not become part of the average user's daily life. The reason isn't technical immaturity — it's that the protocol layer is missing three pieces of infrastructure that ordinary people need to complete a payment:

1. Fund protection for "deliver-then-pay" / "pay-then-deliver" scenarios (escrow / dispute);
2. Privacy from strangers regarding amounts, counterparties, and timing;
3. Semantic identity — knowing who you're transacting with (social).

1.2 Pain Point A: No Disputable Fund Protection

On-chain transfer primitives — transfer, transferFrom, call{value}() — are irreversible the moment they hit the chain. There's no "cancel," no "hold," no "freeze." That irreversibility is great for the system (settlement finality) but catastrophic for scenarios that require coordinated execution between two parties:

• Secondary marketplaces: Buyer pays first, seller never ships? Buyer has nothing but social-media shaming. Seller ships first, buyer refuses to pay? Same problem in reverse.
• Freelance / service contracts: Developer delivers 70% of a spec, client disputes quality and refuses to pay. No neutral third party to intervene.
• B2B cross-border settlement: Pre-payment risk is high, post-delivery payment is slow, traditional letters of credit take 30+ days at significant cost.
• Rental deposits: Once paid, return depends entirely on the landlord. On-chain has no mechanism to guarantee return at lease end.

Traditional payment platforms (PayPal, Stripe, Taobao, Xianyu) solve this through custodial escrow + customer-service arbitration — but at the price of: users must surrender funds to the platform, and the platform can unilaterally freeze, fine, or seize accounts. This violates the core promise of crypto payments — non-custody.

On-chain escrow protocols have existed for years (Kleros, Aragon Court, OpenLaw, etc.), but they are either too specialized (jurors/lawyers UX, incomprehensible to ordinary users), too distant from payments (require navigating to a separate dapp), or too narrowly scoped (DAO-internal disputes, domain disputes). No escrow protocol has been packaged as "the default safety net for crypto payments."

1.3 Pain Point B: On-chain Transparency Is a Privacy Disaster

Every on-chain transfer's metadata — sender address, recipient address, amount, timestamp, token type, related transactions — is permanently public. Anyone with BscScan, Etherscan, Arkham, or Nansen can pull up a wallet's entire history in 5 seconds.

This transparency translates into direct safety / commercial threats in concrete scenarios:

• Payroll: A DAO paying team members on-chain is publicizing the internal salary spread to every team member. Devastating for morale and retention.
• Charitable giving: Donors don't want their giving to be doxxed; recipients don't want fund sources to be traced and audited.
• M&A / business negotiations: Large on-chain transfers can be sniffed by markets and front-run.
• Personal safety: High-net-worth holders making their address public is hanging a target. Chain-analysis firms can tie addresses to real identities through IP leaks, address clustering, and KYC database cross-references.
• B2B supply chain: Settlement transparency lets competitors reverse-engineer your customer relationships, order frequencies, and unit prices.

Existing on-chain privacy solutions include:

• Mixers (Tornado Cash, etc.): Massive compliance risk, terrible UX, sanctioned in multiple jurisdictions.
• Privacy chains (Monero, Zcash): Isolated from the EVM ecosystem, assets cannot interact with DeFi.
• L2 privacy (Aztec, Aleo): Limited scope, small user base, cross-chain coordination is difficult.
• Legacy stealth address protocols: technically mature but UX-hostile — users must manage stealth keys, run their own scans, manually withdraw, with no payment protection or social semantics layered on.

The result: today's crypto user trying to pay privately must either accept severe compliance risk (Tornado), abandon the entire EVM ecosystem (Monero), or use a protocol with UX so bad that 95% of users bounce. None of the existing options is private, compliance-friendly, AND UX-friendly at the same time.

1.4 Pain Point C: Address-Centric vs Human-Centric

Crypto protocols are address-centric: 0xC6C8...4004c interacting with 0x5a7c...3970. But humans are relationship-centric: you're not sending money to 0xC6C8...4004c, you're sending it to your brother, your designer, your local coffee shop.

This semantic mismatch creates three downstream problems:

1. No way to verify counterparty identity. You agreed on a price with "a designer" over Telegram and got their address. But how do you know that address is really theirs? Traditional payments show you bank-account names or Venmo handles; on-chain you're staring at hex.
2. No way to reach the counterparty when things go wrong. Wrong address, payment not received, need to renegotiate terms — on-chain has no official communication channel.
3. No way to build long-term relationships. You work with a vendor regularly, but your wallet has no view of "how many payments did I make to this vendor, what's outstanding?" — all that state lives outside the browser.

This semantic mismatch is one of the fundamental reasons ordinary users reject on-chain payments. It's not a technical problem (ENS, Lens, Farcaster are addressing it piecemeal), it's a product problem: no one has shipped "crypto payments + social semantics" as a single coherent product.

1.5 The Three Pain Points Compound

Worse, these three pain points aren't independent — they interfere with each other in real-world scenarios:

• Try to solve trust with escrow → escrow makes the trade public, hurting privacy.
• Try to solve transparency with privacy protocols → counterparties become unidentifiable, killing social semantics.
• Try to solve identity with social protocols → on-chain behavior gets tied to off-chain identity, killing privacy entirely.

Users should not be forced to choose two out of three. ShotsAI's core thesis: these three properties must be delivered as an integrated protocol-level capability, or crypto payments will never reach mass adoption.

2. Market Opportunity and Target Users

2.1 Market Size

Global stablecoin market cap exceeded $200B by 2025; annual on-chain settlement volume crossed $10T (Chainalysis 2025 report). Of this:

• P2P transfers: ~25% of global on-chain settlement (cross-border remittance, personal transfers, freelance payments).
• Merchant collection (C2B): ~15%, concentrated in crypto-native merchants (NFT platforms, SaaS, content subscriptions).
• B2B settlement: ~10%, with stablecoins (USDC, USDT) rapidly eating SWIFT's share.

ShotsAI's directly addressable market (TAM), conservatively estimated as 20% of these three segments (all payments > $100 that need some form of safety or privacy), is approximately $500B / year based on 2025 numbers.

2.2 Target User Quadrants

                  High privacy need
                        ↑
            Quadrant B      Quadrant A
        (Privacy individuals) (Privacy B2B)
                        │
                        │
Low safety need ────────┼──────────→ High safety need
                        │
            Quadrant D      Quadrant C
        (Casual transfer)  (Trust-thin P2P)
                        │
                        ↓
                  Low privacy need

• Quadrant A — Privacy B2B (procurement, payroll, cross-border settlement): $200B+/year, highest willingness to pay; ShotsAI's flagship customer.
• Quadrant B — Privacy individuals (HNWIs, creators, politically-sensitive geographies, donors): $50B+/year; small per-tx but high frequency and extreme stickiness.
• Quadrant C — Trust-thin P2P (secondary trading, Web3 freelance, cross-border labor): $150B+/year; the natural home of escrow-based payments.
• Quadrant D — Casual transfers: not the primary battleground, but a top-of-funnel acquisition surface via free baseline functionality.

ShotsAI's product positioning lets it serve the first three quadrants simultaneously, rather than being forced into one.

2.3 Aligned with Mass-Adoption Tailwinds

Three macro trends from 2025 to 2027 accelerate ShotsAI's market window:

1. Stablecoin legislation landing (GENIUS Act in the US, SVF in Hong Kong, MiCA in the EU): compliant stablecoin circulation expands massively.
2. Account Abstraction goes mainstream (EIP-4337, EIP-7702): wallet UX approaches Web2, user onboarding friction collapses.
3. AI Agent economy emerges: AI-to-AI on-chain payments (agentic commerce) need privacy + arbitration + automation as foundational infrastructure.

Stacked, these three trends mean tens of millions of net-new users will encounter crypto payments in the next 18 months. ShotsAI's goal is to be the default payment layer for that cohort.

3. ShotsAI Protocol Overview

3.1 Core Thesis

ShotsAI's product thesis distills to three sentences:

1. Safety, privacy, and social semantics must be delivered as one protocol-level capability, not three dapps users stitch together themselves.
2. On-chain is truth; off-chain is index. All fund state is ultimately verifiable in contracts; the off-chain database exists only to make queries, chat, and notifications fast.
3. Every user has their own privacy/safety preferences. The protocol provides five composable modes; users choose in terms they understand, instead of the protocol choosing for them.

3.2 Layered Architecture

ShotsAI uses a classic "contracts + backend + frontend" three-layer architecture, with a social/chat layer added and multi-chain support at the foundation:

┌──────────────────────────────────────────────────────────────┐
│  Frontend Layer (Next.js 16 App Router)                       │
│  Graffiti UI · bilingual zh/en · desktop + mobile responsive  │
│  ┌──────────┬─────────┬──────────┬──────────┬─────────────┐  │
│  │ Dashboard│ Chat    │ Payments │ Disputes │ Notifications│  │
│  └──────────┴─────────┴──────────┴──────────┴─────────────┘  │
└────────────────────────────┬─────────────────────────────────┘
                             │  HTTPS REST + WebSocket
┌────────────────────────────┴─────────────────────────────────┐
│  Backend Layer (Fastify + Socket.IO)                          │
│  ┌────────────────┬─────────────────┬────────────────────┐  │
│  │ REST API /v1/* │ Realtime Push   │ Worker Pool        │  │
│  │ • auth (SIWE)  │ • escrow events │ • HopWorker        │  │
│  │ • escrows      │ • chat messages │ • PhantomWorker    │  │
│  │ • messages     │ • notifications │ • EscrowAutoRelease│  │
│  │ • private-pay  │ • presence      │ • DisputeExpiry    │  │
│  │ • phantom      │                 │ • VolumeWorker × 4 │  │
│  │ • disputes     │                 │                    │  │
│  │ • notifications│                 │                    │  │
│  └────────────────┴─────────────────┴────────────────────┘  │
│              │                            │                   │
│         PostgreSQL                       Redis                │
│    (Prisma · 30+ tables)        (Pub/Sub · Queue · Cache)    │
└────────────────────────────┬─────────────────────────────────┘
                             │  RPC + Event Subscription
┌────────────────────────────┴─────────────────────────────────┐
│  On-chain Layer (Solidity 0.8.20 · OpenZeppelin · Foundry)    │
│  ┌──────────────────────────────────────────────────────┐    │
│  │ Escrow Contract ←→ Arbitration Contract              │    │
│  │ Shield Contract ←→ Stealth Key Registry ←→ Batch     │    │
│  │ ShotToken / ShotsCheckIn                             │    │
│  └──────────────────────────────────────────────────────┘    │
│        │                │                │                    │
│   BSC Mainnet    Kasplex Mainnet    Future: Ethereum / L2s   │
└──────────────────────────────────────────────────────────────┘

3.3 Bidirectional Sync and On-Chain Truth

The on-chain and off-chain layers are bound by the "on-chain is truth, off-chain is index" contract:

• All user-initiated actions (creating escrow, raising disputes, stealth payments, batch sends) must first be signed by the wallet and broadcast on-chain.
• The backend BlockchainListenerService listens for contract events (HTTP RPC polling + 12-block confirmation + reorg detection), writes events into a BlockchainRawEvent buffer table, then EventProcessor decodes them and updates the business tables.
• The off-chain database never fabricates state that doesn't exist on-chain. Every escrow the user sees in the UI can be cross-checked 1:1 on BscScan.
• EscrowSyncService V2 runs periodic full reconciliation as a backstop for missed events.
• All (chainId, txHash, logIndex) tuples have @@unique constraints in Prisma, ensuring idempotency under reorg replays.

The cost of this design is write latency (users wait for on-chain confirmation), but the gain is enormous: users do not have to trust the ShotsAI backend. Even if the backend is completely compromised, the attacker cannot forge, move, or destroy any user funds.

4. Five Payment Modes: Deep Product Dive

4.1 Escrow

4.1.1 User Scenarios

Scenario 1: Freelance Developer Collection Alice is an independent developer with a $5,000 contract from an overseas client. The client worries about delivery quality; Alice worries about not getting paid after delivery. On ShotsAI:

1. Client creates an escrow of 5,000 USDT, 14-day lock, with a memo "Frontend SPA delivery."
2. Funds lock into the contract immediately — neither party can move them.
3. Alice delivers weekly, sending demo links through ShotsAI's built-in E2E encrypted chat.
4. On day 14, the contract auto-releases to Alice (less 0.5% protocol fee).
5. If a dispute arises along the way, either party can raise it, and the multi-sig committee steps in.

The entire flow has no platform freeze risk, no 30-day withdrawal wait, no 5–10% platform cut.

Scenario 2: Xianyu-style P2P Secondary Trading Bob spots a used MacBook Pro on X for 1.5 BNB. Neither party knows the other. The buyer creates an escrow on ShotsAI; the seller ships; the buyer verifies receipt and manually Releases. If there's a problem, the buyer raises a dispute, submits photos and videos as evidence, and the multi-sig rules.

4.1.2 Contract Implementation

The core ABI of the Time-Locked Escrow contract:

function createPayment(address receiver, address token, uint256 amount, uint256 lockDuration) 
    external payable returns (uint256 paymentId);
function manualRelease(uint256 paymentId);
function autoRelease(uint256 paymentId);
function raiseDispute(uint256 paymentId, string reason);
function executeArbitration(uint256 paymentId, bool refund);
function transferDisputedToResolver(uint256 paymentId);

Supported assets: native BNB / KAS / ETH + any ERC-20-compliant token. Native is wrapped behind a placeholder address 0xEeeeE...EEeE for unified handling.

Lock duration: minimum 120 seconds (preventing abuse of "zero-delay escrow"), maximum 365 days. Production sweet spot is 1–7 days for most P2P / C2B scenarios.

Service fee: 0.5% default, owner-adjustable but hard-capped at 10% (preventing owner exit-scam or malicious rate changes). Charged only on auto-release — manual releases and dispute refunds are free.

Circuit breakers:

• minEscrowAmount 0.001 BNB default, preventing dust attack.
• maxTransferAmount 100 BNB default, per-tx ceiling.
• dailyTransferLimit 1,000 BNB default, protocol-wide daily ceiling, auto-resets at UTC 00:00 each day.
• Pausable emergency stop: owner (recommended multi-sig) can pause createPayment and autoRelease with one call. Existing escrows are unaffected — manual release and dispute paths remain available.

Dual dispute paths:

1. Multi-sig escape hatch (current production default): transferDisputedToResolver(paymentId) moves funds to a preconfigured multi-sig wallet; the resolution happens off-chain and funds are manually transferred per outcome. Fast, controllable, fits v1.x maturity.
2. DAO governance (future primary path): The DAO Arbitration contract lets $SHOT holders vote by weight; after quorum, executeArbitration runs automatically. Slow, censorship-resistant, fits v2.x community maturity.

Auto-release operators: the contract supports a whitelist of keepers who can call autoRelease after the unlock time. In production the ShotsAI backend runs an EscrowAutoReleaseWorker to monitor expired escrows — but it never auto-signs releases. It just surfaces "ready to release" hints in the UI, and the user's wallet signs the final transaction. This means: even if the backend is compromised, the attacker cannot release any escrow on the user's behalf.

4.1.3 Product Differentiation

Versus escrow / arbitration protocols like Kleros and Aragon Court:

4.2 Stealth Payments

4.2.1 User Scenarios

Scenario 1: Confidential Payroll A DAO pays 30 full-time contributors monthly. With plain transfers, everyone sees everyone else's salary, harmful to team dynamics. With ShotsAI's batch stealth payment:

1. Finance signs once; 30 transfers each generate independent one-time stealth addresses.
2. Each contributor passively scans with their registered viewing key, automatically identifying their own payment.
3. On-chain, observers see 30 equal-looking transfers to different addresses — no one can infer who got what.

Scenario 2: Commercially Sensitive Transfer Company A pays Vendor B. With plain transfers, competitors reverse-engineer the relationship, frequency, and pricing from chain data. With ShotsAI stealth:

• The send address only exposes A's one-time initiator.
• The receive address is B's one-time stealth address.
• On-chain, there's no provable long-term relationship between these two addresses.

4.2.2 Technical Mechanics

ShotsAI's stealth payments are built on industry-mature secp256k1 ECDH (Elliptic-Curve Diffie-Hellman) key agreement + diversifier derivation, accelerated by view-tag scanning. This cryptographic primitive was first proposed by Vitalik Buterin on the Bitcointalk forum in 2014 and later standardized as EIP-5564. ShotsAI builds three engineering upgrades on top of the primitive: deterministic key derivation (users never need to separately custody stealth private keys), view-tag accelerated scanning (recipient scanning cost drops by 99.6%), and end-to-end UX integration (ordinary users complete registration + send in two steps).

Key registration (once per user):

1. On first visit to the privacy page, the frontend calls useStealthKeyGeneration:
   • User signs a fixed message (containing chainId to prevent replay).
   • The signature is split into two 32-byte halves; each is hashed with keccak256, yielding spending and viewing private-key seeds.
   • secp256k1 derives the corresponding public keys.
2. The frontend registers both public keys (prefix + x-coordinate, compressed) with the Stealth Key Registry contract via a wallet signature or meta-transaction.

This step involves only one wallet signature; no plaintext private key is ever stored. Re-derivation is deterministic (RFC 6979 signatures), meaning: even after device switch, browser cache clear, or stolen laptop, the user can recover every stealth payment they've ever received using only their wallet private key.

Sending (per transfer):

1. Sender calls backend /v1/private-payments/users/:address/keys to get the recipient's (spendingPubKey, viewingPubKey).
2. Frontend web3/utils/stealth.ts computes:
   • Ephemeral private key r → ephemeral public key R = r·G.
   • Shared secret S = r · viewingPubKey (ECDH).
   • Stealth private-key offset s = keccak256(S.x).
   • Stealth address = address(spendingPubKey + s·G).
   • View tag = first byte of S.x, letting the recipient prefilter ~99.6% of unrelated events in 1 byte.
3. Sender calls the Shield contract's stealth send method (native token or ERC20), attaching:
   • The recipient's stealth address.
   • The 0.001 BNB service fee (flows to fee collector).
   • The x-coordinate of ephemeral pubkey R + ciphertext (first byte is view tag, next 31 bytes optional encrypted metadata).
4. The contract emits an on-chain event recording (receiver, amount, token, ephemeralPubKeyX, ciphertext).

Scanning (recipient):

1. The recipient's backend subscribes to events and writes them into the private_payments table with an indexed viewTag field.
2. The recipient's frontend polls events matching their view tag.
3. For each candidate, the recipient computes S = v·R (where v is their viewing private key) and verifies address match.
4. Matched payments are controllable via spending_priv + s.

Withdrawal (per payment):

1. The recipient uses the stealth address as msg.sender to call the Shield contract's withdrawal method.
2. The contract takes the balance from its internal balance mapping and transfers it to acceptor (which can be the recipient's main wallet or another stealth address).
3. Critical warning: if acceptor is the recipient's main wallet, this payment becomes linked to that main wallet. The frontend WithdrawDialog displays this warning prominently and recommends either multi-hop withdrawal or direct on-chain spending from the stealth address.

4.2.3 Comparison with Other Privacy Solutions

ShotsAI's strategy: use stealth addresses to solve "on-chain unlinkability" for the 95% of users who need it; reserve zk-SNARK-grade solutions for the small fraction of users with extreme threat models. From a product perspective, stealth is mass-adoption-friendly privacy — strong enough, simple enough, compliance-friendly enough.

4.3 Phantom Routing

4.3.1 Product Positioning

Phantom routing is the advanced tier of stealth payment, designed for "single-hop stealth isn't enough" high-sensitivity scenarios:

• The amount is large enough that chain-analysis firms might brute-force time/amount correlation.
• The recipient won't withdraw for a long time, and no intermediate state should be observable.
• The sender wants protection even if their viewing key is compromised by an attacker.

Phantom's solution: funds depart the sender, automatically hop through 3–10 intermediate stealth addresses with randomized time delays (seconds to hours), and arrive at the recipient's final stealth address. On-chain observers see N seemingly unrelated transfers; time and amount correlation cannot reconstruct the sender→receiver mapping.

4.3.2 Three Strength Tiers

Users select via radio cards in CreatePhantomModal. The frontend calls /v1/phantom/estimate-gas in real time to fetch the exact cost at current gas prices.

4.3.3 Backend Scheduler

HopSchedulerService is one of ShotsAI's most complex backend components:

1. Pre-derive hop addresses: On Phantom creation, the backend derives N intermediate addresses from an HD wallet; each private key is encrypted with AES-256-GCM (key from HOP_ENCRYPTION_KEY env var) and stored in HopDetail.stealthPrivateKey.
2. Schedule execution times: Inter-hop delays are randomized to avoid regularity.
3. Relayer-funded gas: Intermediate addresses hold only the target token, not native gas. The backend's RELAYER_PRIVATE_KEY wallet sponsors gas (with 20% buffer).
4. HopWorker × N concurrency: Workers pull tasks from a Redis queue, sign and broadcast at the scheduled time.
5. Final-hop special handling: The final hop's address is derived from the recipient's published stealth keys (a "real" stealth address). The corresponding ephemeral pubkey and view tag are written to the final HopDetail, allowing the recipient to detect it during scanning.

From the user's perspective: one signature → wait a few minutes to a few hours → receive on the other side.

4.3.4 Phantom Composed with Escrow

Phantom can be composed with Escrow: funds locked in an escrow start a multi-hop route during the lock window; when the recipient gains control at unlock, they see funds at their stealth address ready for direct withdrawal. This composition offers a one-stop solution for scenarios that demand both fund protection and untraceability (e.g., labor settlement in politically sensitive geographies).

4.4 Batch Send

4.4.1 Product Scenarios

• DAO payroll: one tx pays 30 contributors monthly.
• Airdrop: one tx distributes rewards to 200 early users.
• Group split: dinner AA, group purchase splits.
• Foundation grants: batch payouts to grantees.

ShotsAI's batch send defaults to stealth mode — each recipient receives a one-time stealth address, not their real address. This protects sensitive data like "DAO total payroll" or "foundation grantee list" from on-chain exposure.

4.4.2 Implementation Notes

Core interface of the Batch Send contract:

function batchSend(uint256 feeCommitment, SendData[]) external payable;
struct SendData { 
    address payable receiver;   // stealth address
    address tokenAddr;          // BNB placeholder or ERC20
    uint256 amount;             
    bytes32 pkx;                // ephemeral pubkey x
    bytes32 ciphertext;         // encrypted payload
}

• The data array must be sorted by token address (enforced by the contract) so the same token can transferFrom consecutively, saving gas.
• Internally: for each token segment, single approve → multiple calls to the Shield contract → reset approve to 0 (defending against approval-frontrun).
• Measured: 20 recipients in one batch saves ~60% gas vs. 20 independent stealth transfers.

4.4.3 Frontend UX

The /dapp/batch-payment page:

• CSV template download + drag-drop upload: columns address,token,amount.
• Auto-validation: address format, stealth-key registration, amount sanity.
• Failed rows are editable or removable; valid rows queue for sending.
• Payment summary card: recipient count, totals grouped by token, total service fees, estimated gas, total cost.
• Three-stage progress: isPending → isConfirming → isProcessing.

4.5 Hybrid Smart Recommend

4.5.1 Why This Mode Is Needed

Five payment modes (Hybrid included) give users plenty of choice — but choice itself is cognitive load. A new user staring at "should I use escrow, stealth, or phantom?" often abandons the flow.

Hybrid Smart Recommend solves this: users answer a 4-step questionnaire, and the "AI" (actually a rules engine + heuristic weights) recommends the optimal composition.

4.5.2 4-Step Questionnaire

Step 1: Amount range?
  [ < $100 ] [ $100-$1000 ] [ $1000-$10000 ] [ > $10000 ]

Step 2: Privacy preference?
  [ Fully public ] [ Hide from strangers ] [ Hide from anyone ] [ Maximum privacy ]

Step 3: Speed need?
  [ Immediate ] [ Few minutes ok ] [ Few hours ok ] [ Few days ok ]

Step 4: Recipient type?
  [ Existing friend ] [ First-time counterparty ] [ Complete stranger ]

4.5.3 Recommendation Engine Logic (Simplified)

• Amount > $1000 AND recipient=stranger → recommend Escrow (force lock protection).
• Privacy=maximum → recommend Phantom Maximum (ignore cost).
• Privacy=hide from strangers AND speed=immediate → recommend Stealth single-hop.
• Privacy=hide from anyone AND speed=few hours → recommend Phantom Advanced.
• Multiple recipients → recommend Batch.
• "Large amount + high privacy + unknown recipient" → recommend Phantom + Escrow composition.

The recommendation surfaces in PaymentRecommendationView with a plain-language rationale plus 2–3 alternatives. Users can one-click override.

4.5.4 Bridging to Agentic Commerce

Hybrid Recommend is ShotsAI's entry point for AI in payment decisions. In the v3.0 roadmap (see §16), ShotsAI will open an MCP (Model Context Protocol) interface, letting AI Agents — under user authorization — auto-select payment modes and execute P2P/C2B settlement. This is the foundational payment layer for agentic commerce.

5. The Encrypted Social Layer

What sets ShotsAI apart from pure payment protocols is that it ships with a complete social layer. The social layer isn't just decoration for payments — it treats payment as one verb in a social interaction.

5.1 End-to-End Encrypted Chat

5.1.1 Key Model

• On first visit to the chat page, the browser locally generates an RSA-OAEP 2048 keypair.
• The private key never leaves the browser (stored in IndexedDB / LocalStorage; Passkey integration planned).
• The public key uploads via PUT /v1/auth/public-key to User.e2ePublicKey.

5.1.2 Session Keys

• When two users chat for the first time, A pulls B's public key and generates a symmetric AES-GCM 256 session key.
• A encrypts the session key once with B's public key and ships it; B decrypts with their private key.
• Subsequent messages are encrypted with the session key + random IV; the server sees only ciphertext.

5.1.3 Server Guarantee

The Message table's content field is just ciphertext. The ShotsAI backend (including admins, ops, attackers) never gets chat plaintext. Even total database compromise yields only random bytes.

5.1.4 Payment Message Cards

The chat stream is more than text. Message.type enum: TEXT | IMAGE | FILE | PAYMENT | SYSTEM.

When a user creates an escrow / stealth / phantom payment within a chat, a PAYMENT message is auto-inserted, with metadata paymentId / mode / amount / token / status. The frontend PaymentMessageCard renders it as an interactive card:

┌─────────────────────────────────────────┐
│ 💸 0.5 BNB · ESCROW                     │
│ Status: ACTIVE                          │
│ Unlock in: 6d 14h                       │
│ [ View Details ]  [ Release ]           │
└─────────────────────────────────────────┘

This means chat and payment never split apart. Discussing price, confirming terms, initiating payment, tracking status, resolving disputes — all happen in the same thread. The counterparty is always known.

5.2 Social Graph

• FriendRequest table stores the request lifecycle: PENDING / ACCEPTED / REJECTED / CANCELLED.
• Friendship table stores accepted relationships, redundantly stored bidirectionally (A→B and B→A as separate rows) + roomHash field (sorted wallet addresses + keccak256 for fast chat-room lookup).
• Real-time events: friend-request-received, friend-request-accepted, friend-request-rejected, friend-request-cancelled, friend-deleted.

The social graph is the substrate for social semantics, but ShotsAI does not require friendship for transfers — every payment mode supports any address or registered user. The friend graph mainly streamlines repeat counterparties (autofilled addresses, shared stealth keys, aggregated payment history).

5.3 11 Real-Time Notification Categories

Users toggle each category individually at /notifications/settings. All notifications push in real time via socket (notification:new event), and persist in the Notification table for offline replay.

5.4 User Profiles

User table fields:

• walletAddress: unique identifier; all users are wallet-address → user-id 1:1 mappings.
• ensName: optional ENS reverse resolution.
• nickname: auto-generated (dictionary + random) or user-defined.
• avatarSeed: DiceBear seed; zero server-side image storage.
• bio: short self-introduction.
• e2ePublicKey: RSA public key for chat.
• isNewUser: whether onboarding is complete.
• lastSeen: last active timestamp.

The entire user profile is zero image upload, zero real-world identity — yet sufficient for human recognition.

6. Contract Layer Architecture

ShotsAI's on-chain layer comprises seven core contracts, all built on Solidity 0.8.20 + OpenZeppelin 4.x + Foundry.

6.1 Time-Locked Escrow Contract

See §4.1.2; additional notes:

• Inherits three OpenZeppelin safety modules: ReentrancyGuard, Pausable, Ownable.
• Uses SafeERC20 for all ERC-20 calls, avoiding the "transfer returns false silently" trap of tokens like USDT.
• The BNB_TOKEN_PLACEHOLDER constant unifies ETH-like native-token handling.
• Dual indexing: payments[id] primary table + userPayments[address] uint256[] user payment list.
• Event design is granular enough that listeners can sync all data without reading contract state.

6.2 DAO Arbitration Contract

See §4.1.2 dispute paths; additional notes:

• Default voting period: 3 days; configurable 1–7 days.
• Default quorum: 1,000 $SHOT; configurable (must be > 0).
• Vote weight = current $SHOT balance — not locked. A retained design choice; the future upgrade path moves to ERC20Votes snapshot to prevent flashloan voting.
• After the voting window, anyone can call executeDispute, which invokes TimeLockEscrow.executeArbitration(paymentId, refund).
• cancelDispute(disputeId, reason) is owner-only — a final backstop for maliciously manipulated disputes.

6.3 Stealth Key Registry

See §4.2.2; additional notes:

• EIP-712 domain separator is baked into the contract; signatures are compatible with major hardware wallets.
• Public keys are stored as prefix (2 / 3, the parity of y-coordinate) + x-coordinate, avoiding the gas cost of full 33-byte keys.
• _setStealthKeys internally clears old prefix slots, preventing stale data interference.
• hasStealthKeys(address) is a simple existence check used by the frontend to decide whether to prompt registration.

6.4 ShotsAI Shield — Stealth Payment Contract

See §4.2.2 for stealth payment mechanics; additional notes:

• Function names use hash-style identifiers (f7a3b2c1, e4d5c6b7, a1b2c3d4) — on the surface this looks like obfuscation; the real purpose is to make it harder for chain-analysis firms to bulk-recognize "this is a ShotsAI stealth payment", raising the bar for targeted deanonymization.
• Legacy generic send / withdraw are preserved for backward-compatible front-ends.
• Built-in sponsor-signed withdrawal (d4c3b2a1): a sponsor pays gas for the stealth address and collects a sponsor fee, freeing the recipient from needing native gas.
• On-chain event signature is (receiver, amount, token, ephemeralPubKeyX, ciphertext); the first three fields are indexed for efficient filtering.

6.5 ShotsAI Batch — Batch Send Contract

See §4.4.2; additional notes:

• The contract itself holds no funds (intermediate transfers immediately call the Shield contract), so it isn't an attack target.
• Atomicity: failures roll back the entire batch — no "partially succeeded" intermediate state.
• recoverFunds is owner-only and can only drain the contract's own balance (which should always be 0).

6.6 ShotsCheckIn — Daily Check-in

See §4.6. Though only ~50 lines of Solidity, this contract is the keystone of ShotsAI's user-growth infrastructure:

• Users check in once daily; on-chain checkInCount accumulates.
• Future utility: airdrop based on checkInCount, service-fee discounts for long-time users, VIP feature unlocks.
• Contract-level paused switch lets ops kill activity instantly even if the backend is compromised.

6.7 ShotToken — $SHOT Token Contract

Detailed token economy, allocation, vesting, and utility are covered in §12 $SHOT Token Economy.

7. Backend Service Architecture

7.1 Frameworks and Dependencies

• Fastify 5.x — high-performance Node.js framework; benchmarks 2–3× faster than Express.
• Prisma 5.x — type-safe ORM, schema-first design, auditable migration history.
• PostgreSQL 14+ — primary storage, 30+ business tables.
• Redis 7+ — distributed rate limiting + Socket.IO adapter + worker queue + offline message buffer.
• Socket.IO 4.x — bidirectional realtime with room semantics (user:{id} + room:{roomHash}).
• viem 2.x / ethers 6.x — dual clients: viem for listener (lighter), ethers for contract calls (broader compatibility).

7.2 Key Services

7.3 API Surface

All REST APIs sit under /v1/*. Auth: SIWE (EIP-4361) → JWT bearer token.

POST   /v1/auth/nonce              Generate SIWE nonce
POST   /v1/auth/verify             Verify signature → JWT
PUT    /v1/auth/public-key         Upload E2EE public key
GET    /v1/users/me                My profile
PATCH  /v1/users/me                Update nickname / bio
GET    /v1/users/search            Search by nickname / ENS / address
GET    /v1/friends                 Friend list
POST   /v1/friends/requests        Send friend request
POST   /v1/friends/requests/:id/accept
POST   /v1/friends/requests/:id/reject
GET    /v1/messages/:roomHash      Chat history (paginated, cursor-based)
GET    /v1/escrows                 Escrow list
GET    /v1/escrows/:id             Escrow detail
GET    /v1/disputes                Dispute list
POST   /v1/disputes/:id/evidence   Submit evidence
GET    /v1/private-payments/users/:address/keys  Recipient stealth keys
GET    /v1/private-payments/scan   Scan candidate payments
POST   /v1/private-payments/withdraw/sign        Generate sponsor signature
GET    /v1/phantom/estimate-gas    Phantom gas estimate
POST   /v1/phantom                 Create Phantom payment
POST   /v1/hybrid-payments/recommend  Smart Recommend
GET    /v1/notifications           Notifications
PATCH  /v1/notifications/:id/read  Mark read
PATCH  /v1/notifications/preferences  Update preferences
GET    /v1/blockchain/networks     Supported chains
GET    /v1/blockchain/tokens       Supported tokens
GET    /v1/admin/*                 Admin panel (IP / wallet whitelist)
POST   /webhooks/moralis           Moralis Streams fallback

7.4 Security Design

• Authentication: All mutating endpoints require valid JWT. Tokens expire in 7 days; refresh mechanism arrives in v1.1.
• Rate limit: Redis distributed limiter. Default: 500 req / 15min / IP; admin: 100 req / 15min / IP.
• CORS: Environment-variable whitelist; deny by default.
• Admin 2FA: Admin endpoints require IP whitelist + wallet whitelist.
• SQL injection: Prisma's type safety eliminates raw-string SQL paths.
• Key management: All secrets (DB, Redis, relayer, HOP_ENCRYPTION_KEY) are injected via environment; production uses AWS KMS or Vault.

7.5 Observability

• Structured JSON logs (Fastify's built-in pino logger).
• Critical events (escrow creation, dispute, release, withdrawal) hit BlockchainRawEvent, forming a complete audit trail.
• All Volume tool actions write to VolumeAuditLog.
• /health exposes a readiness check for load balancers / k8s probes.

8. Frontend Experience and Design Language

8.1 Stack

• Next.js 16 App Router — route-level zh/en (/[locale]/dapp/*), SSR + Streaming + RSC.
• wagmi 2.x + viem 2.x + RainbowKit 2.x — wallet connection, chain switching, contract reads/writes.
• next-intl 4.x — 530-line message catalog covering every UI string.
• Tailwind 3.x + Motion 12.x — atomic CSS + motion design.
• Zustand 4.x — client state (wallet, user, UI).
• React Query (TanStack Query) 5.x — server state cache + optimistic updates.
• Socket.IO client 4.x — realtime event subscriptions.

8.2 Design Language: Graffiti + Brutalist

ShotsAI deliberately avoids the mainstream "financial SaaS blue-white-gray" aesthetic in favor of graffiti / Brutalist:

• Heavy black borders (4–6 px): every component has a clear geometric outline; inspired by the Memphis design movement.
• Hard shadows (6–8 px offset): zero blur — box-shadow: 6px 6px 0 0 #000 — emphasizing physicality.
• Vivid color tiles: spray-yellow, mint, spray-purple, drip-orange as the 4 primary colors; ink (deep black) and bone (cream) as backgrounds.
• Drybrush / drip textures: SVG filters simulate spray-paint and dripped-paint texture, giving the UI a hand-made feel.
• Typography: display fonts use compressed weights (Knockout / Druk style); body fonts stay highly readable.

The design choice is an extension of product positioning: ShotsAI isn't BlackRock's DeFi front-door — it's a tool for the next generation of crypto-native users ("those who treat the chain like Twitter"). The visual style itself functions as a filter: target users feel "this is my protocol" at first glance.

8.3 Information Architecture

Desktop (≥1024px)
─────────────────────────────────────────────────
Header (fixed top, 64px)
  Logo + BETA | 4 main tabs | 🌐 👥 🔔 [Wallet]
─────────────────────────────────────────────────
                   Main content
              (Payments contains 5-item left sidebar)

Mobile (<1024px)
─────────────────────────────────────────────────
Header (compact: Logo + 🌐 🔔 [Wallet])

         Main content
─────────────────────────────────────────────────
Bottom tab bar
  🏠 💬  [⚡ FAB]  ⚖️ 👥
  ↑ center FAB opens BottomSheet for quick payment
─────────────────────────────────────────────────

8.4 Key UX Patterns

• Global wrong-chain warning: a fixed red banner appears site-wide when the wallet isn't on the active chain; one-click switch.
• Dynamic-precision countdown: every minute when >1h, every 10s when <1h, every second when <10min — minimizing React re-renders while preserving urgency.
• Optimistic updates: initiating an escrow immediately renders a PENDING card; the chain confirmation transparently flips it to CONFIRMED.
• Skeleton + Empty state: every list page has tailored loading skeletons and empty-state cards, avoiding the white-screen ↔ flicker dichotomy.
• Realtime feedback: socket events trigger toasts + targeted list refetches; users never refresh manually.
• Error recovery: every on-chain call has a useEscrowWatcher-class hook that actively reconciles state, catching RPC drift.

8.5 Internationalization and Localization

• Default Chinese + English, route-scoped (/zh/*, /en/*).
• Switching language preserves query params and current pathname.
• Numbers, dates, relative times all render per locale (e.g., "3 分钟前" vs. "3 minutes ago").
• Planned next: Japanese (Japan), Korean, Portuguese (LATAM), Arabic (with RTL support).

9. Multi-Chain Strategy

9.1 Currently Supported Chains

9.2 Why BSC + Kasplex

• BSC: 1M+ daily active addresses, ultra-low gas (< $0.10 per tx), deep stablecoin liquidity, user demographics that align tightly with ShotsAI's target audience (APAC and emerging markets).
• Kasplex: an EVM L2 built on Kaspa with blockDAG consensus + high concurrency; positioned as the "next-gen high-TPS smart contract platform" — gives ShotsAI a future-proof scaling option.

9.3 Multi-Chain Consistency Guarantees

• A single Prisma schema; chainId field permeates every business table.
• Composite unique constraint (chainId, contractId) prevents cross-chain ID collisions for escrows.
• The frontend swaps contract addresses dynamically based on the wallet's current chain — transparent to users.
• Listeners run as independent instances per chain, never blocking one another.

9.4 Cross-Chain Atomic Escrow Roadmap

v2.0 plans LayerZero or Wormhole integration to enable cross-chain escrows: the buyer locks USDC on chain A; the seller sees a mirrored state on chain B; on unlock, an atomic swap settles cross-chain. This solves the "liquidity fragmentation" problem of cross-border payments.

10. User Personas and Use Cases

10.1 Persona A: Web3 Freelancer (Heavy User)

Profile: Alice, developer, based in Mexico, working remotely for US startups. Monthly income $5,000–$15,000, all settled in USDC.

Pain points:

• Clients won't 100% prepay; Alice won't 100% post-pay.
• After on-chain transfer, if the client claims the work was sub-standard, Alice has no legal recourse.
• Monthly salary hitting the main wallet exposes earnings, sources, and timing forever.

ShotsAI solution:

• Every project uses escrow with a 14-day lock and auto-release.
• Large salary payments route through Phantom Maximum into a personal stealth wallet, hiding income from on-chain analytics.
• Chat with regular clients via E2EE conversations, with all payment history aggregated per counterparty.

Expected usage: 5–20 transactions / month.

10.2 Persona B: High-Net-Worth Holder (Privacy-Sensitive)

Profile: Bob, Singapore, holds $5M+ in crypto.

Pain points:

• A public wallet address is a phishing / extortion / kidnapping target.
• Transfers to family members, private doctors, etc., should not be traceable by chain-analysis firms.
• Charitable giving must not be linked to the main wallet (avoid tax tracing + targeted marketing).

ShotsAI solution:

• The main wallet never receives plain transfers — everything via Stealth + Phantom Advanced.
• Payments to family, doctors, lawyers go through ShotsAI's friend mode + Phantom, so recipients see one-time addresses only.
• Sensitive communications use ShotsAI's E2EE chat, leaving no on-chain trail.

Expected usage: 50+ transactions / month.

10.3 Persona C: DAO Operator

Profile: Carol, runs a DeFi DAO managing 30 contributors.

Pain points:

• Monthly payroll on-chain reveals salary spread to every contributor — bad for retention.
• Bonus distributions shouldn't be reverse-engineerable by competitors.
• Temporary consultants need a "deposit + final payment" mechanism.

ShotsAI solution:

• Monthly payroll uses Batch Send to 30 stealth addresses in one tx — invisible to chain analytics.
• Consultant work uses Escrow with two-phase payment.
• Internal team discussions move to ShotsAI E2EE chat — avoiding Slack/Discord leaks.

Expected usage: 10+ transactions / month (high value).

10.4 Persona D: Cross-Border E-Commerce Merchant

Profile: David, Shenzhen cross-border seller, $200K monthly GMV.

Pain points:

• Overseas customers pay in stablecoins, but order disputes have no third-party arbitration.
• Settlement with overseas warehouses / logistics partners needs "cash-on-delivery" mechanics.
• Order frequency and unit prices should not be inferable by competitors.

ShotsAI solution:

• Every customer order routes through Escrow with 30-day lock, releasing on shipping + tracking confirmation.
• Settlement with logistics partners uses Phantom Advanced, hiding supply-chain relationships.
• Multi-sig arbitration assures overseas customers ("I have third-party recourse").

Expected usage: 100+ transactions / month (small-value, high-frequency).

10.5 Persona E: Content Creator / Streamer

Profile: Emma, Substack writer with 5,000+ paid subscribers.

Pain points:

• Substack / Patreon takes 10%.
• Wants to accept crypto subscriptions without exposing subscriber geography / demographics.
• High platform-policy risk — could be deplatformed over content.

ShotsAI solution:

• Subscribers renew monthly via Stealth payments — subscription relationships fully private.
• ShotsAI takes no subscription fee (only the underlying 0.001 BNB stealth service fee per tx).
• On-chain non-custodial — platform policies don't apply.

Expected usage: 100+ subscription tx / month + occasional large tips.

11. Competitive Landscape and Differentiation

11.1 Horizontal Comparison Matrix

ShotsAI is the only protocol covering all seven core capabilities simultaneously.

11.2 Versus Traditional Payment Platforms

11.3 Differentiation Summary

ShotsAI's differentiation isn't any single capability (competitors do each one well in isolation) — it's being the only one that packages them into a single product. This packaging produces compounding effects:

• Users no longer switch between multiple dapps (↓ cognitive load).
• The protocol can design unified incentives across the user lifecycle (↑ retention).
• Third-party integrators get the whole stack from one integration (↑ ecosystem leverage).

12. $SHOT Token Economy

12.1 Token Overview

$SHOT is the sole native token of the ShotsAI protocol, combining governance, utility, and incentive functions in a single asset.

The design philosophy of $SHOT is simple, fixed, trustworthy:

• Simple — no complex dual-token, ve(3,3), or rebase mechanisms. Hold $SHOT and you receive full protocol benefits.
• Fixed — 1 billion total supply is hardcoded at the contract level, with no mint function. This means no one, including the protocol team, can ever increase the supply. A hard commitment to holders.
• Trustworthy — built on OpenZeppelin's audited ERC-20 + Permit + Votes implementation, with extensive real-world battle testing.

12.2 Token Utility

The four core utilities of $SHOT:

12.2.1 Governance

• Holding $SHOT confers governance rights over the ShotsAI protocol.
• Vote on disputes, parameter changes, and new chain integrations through the DAO Arbitration contract's vote() interface.
• Vote weight = current holdings (upgraded to ERC20Votes snapshot in v2.0 to prevent flashloan attacks).
• Major parameter changes (protocol fees, daily limit, resolver rotation) must pass $SHOT governance votes.

12.2.2 Protocol Fee Discount

The specific thresholds will be refined through DAO governance, but the principle that $SHOT holders permanently enjoy protocol fee discounts is fixed.

12.2.3 Staking Yield

• Users can stake $SHOT in the Staking contract to share in ShotsAI protocol revenue proportionally.
• Protocol revenue sources: Escrow protocol fee, Stealth service fee, Batch service fee, Phantom relayer fee.
• 50% of protocol revenue is used to buy back $SHOT and distribute to stakers (launches in v2.0).
• 30% flows to the DAO treasury for community-directed spend.
• 20% funds protocol operations and key-personnel incentives.

Per §12.5's revenue projection, once protocol annual revenue reaches $5–10M, staking APR is estimated at 5–15% (depending on staking participation rate).

12.2.4 Premium Feature Unlocks

Certain advanced features require a minimum $SHOT balance:

• Phantom Maximum Mode: ≥ 1,000 $SHOT.
• Batch payment with > 30 recipients: ≥ 10,000 $SHOT.
• ShotsAI for Business (Enterprise): ≥ 100,000 $SHOT (v3.0).
• Cross-chain atomic escrow: ≥ 5,000 $SHOT (v2.0).

Premium thresholds are adjusted by DAO governance.

12.3 Token Allocation

The 1 billion $SHOT total supply is allocated as follows:

Unlock Curve (24-month View)

$SHOT Circulating Supply
  1B ┤                                              ●━━━━━━━━━━━ Month 36: 100% circulating
     │                                       ●━━━━━━
 800M┤                                  ●━━━━
     │                          ●━━━━━━
 600M┤                  ●━━━━━━━
     │            ●━━━━━
 400M┤      ●━━━━━
     │   ●━━
 200M┤●━
     │
   0 ┼──────────────────────────────────────────────────────→
     TGE   M3    M6    M9   M12   M15   M18   M21   M24   M36

Approximately 5% (50M) circulates at TGE, primarily from the initial airdrop wave and LP seeding.

12.4 Token Velocity Model

$SHOT is engineered to lower velocity and increase holding motivation:

1. Staking lockup: stake $SHOT to gain fee discount + revenue share; minimum 7-day lockup recommended.
2. VIP thresholds: premium features require holding, not spending.
3. Governance voting: participating in governance requires holdings held ≥ 7 days (snapshot in v2.0), resisting short-term vote manipulation.
4. Protocol revenue buy-back: 50% of protocol revenue buys back $SHOT, providing structural demand.
5. Ecosystem grants: developers receiving $SHOT grants must begin project work within 6 months or trigger clawback.

12.5 Revenue Model and Three-Phase Projection

Revenue Sources

Three-Phase Revenue Projection

v1.x Phase (2026 H2, 5,000 DAU):

• Escrow: 5,000 × 30% × 3 tx/month × $500 × 0.5% = $11,250 / month
• Stealth + Batch: 5,000 × 50% × 5 tx/month × $0.5 = $6,250 / month
• Monthly total: $17,500 / month, annualized **$210K**

v2.x Phase (2027 H1, 50,000 DAU):

• Escrow: 50,000 × 35% × 4 tx/month × $800 × 0.5% = $280K / month
• Stealth + Batch: 50,000 × 60% × 8 tx/month × $0.5 = $120K / month
• Phantom relayer markup: $50K / month
• Monthly total: $450K / month, annualized **$5.4M**

v3.x Phase (2028 H1, 200,000 DAU):

• Escrow: 200,000 × 40% × 5 tx/month × $1000 × 0.5% = $2M / month
• Stealth + Batch: 200,000 × 70% × 12 tx/month × $0.5 = $840K / month
• Phantom + Cross-chain: $500K / month
• ShotsAI for Business subscription: $200K / month
• Monthly total: $3.5M / month, annualized **$42M**

At 50% revenue allocated to buy-back, annual $SHOT buy-back scale is ~$2.7M in v2.x and ~$21M in v3.x.

12.6 Token Governance

$SHOT governance scope is tiered by impact:

All L2+ governance actions must pass via Snapshot off-chain vote or DAO Arbitration on-chain vote, then survive a 48-hour Timelock delay before execution.

12.7 Token Security Guarantees

• Non-upgradeable contract: the $SHOT contract has no proxy, no mint, no admin upgrade — even the team cannot alter total supply.
• Multi-chain synchronized issuance: 500M + 500M issued independently on BSC and Kasplex (totaling 1B), kept consistent via future LayerZero / Wormhole bridges.
• Liquidity lock: the 5% liquidity-mining LP tokens are locked ≥ 12 months (Unicrypt or equivalent).
• Team lockup transparency: all team / advisor / investor wallet addresses are published at v1.1, with TimeLock contracts controlling unlocks — community can verify every unlock on-chain.
• Token audit: third-party token contract audit before v1.1 (target: CertiK, SlowMist, or Trail of Bits).

12.8 Token Milestones Aligned with Protocol Evolution

13. Operational Infrastructure: Volume Tool

13.1 Design Motivation

Every new protocol launching on mainnet hits the cold-start paradox:

• No users → on-chain looks dead → arriving users think "no one uses this, sketchy" → they leave → never any users.

Typical responses:

• Airdrop bait: attracts farm-and-dump users who don't retain.
• Heavy subsidies: burns capital faster than growth.
• PR push: loud, but converts poorly.

ShotsAI's approach: deliberately inject controlled, natural-looking on-chain activity so real visiting users perceive an active protocol — while clearly separating "seed traffic" from "real users" and ratcheting the seed traffic down as real users arrive.

13.2 Technical Implementation

The Volume Tool is a coordinated set of backend components:

• HDWalletManager: derives up to 38,300 EOAs from one mnemonic (m/44'/60'/1'/0/0..38299); keys are never persisted, derived on demand.
• VolumeCampaign: defines a 10-day campaign with an S-curve (default 800 DAU → 12,000 DAU), hourly weights (Beijing-time double peak), and check-in / real-payment mix (default 8:2).
• VolumeScheduler: generates per-minute tasks per the S-curve + weights, writing into a Redis queue.
• VolumeWorker × 4: concurrent task consumers; derive wallets, sign, broadcast checkIn or escrow deposit.
• VolumeFundingWorker: monitors wallet balances, tops them up from a master pool as needed.
• VolumeEventExpiryWorker: marks unconfirmed tasks as FAILED past timeout, preventing zombie state.

13.3 Risk Controls

• Never touches real user funds: all escrows are between wallet-pool addresses; real users are never exposed.
• Full audit log: every action lands in VolumeAuditLog with actor, action, payload.
• On-chain kill switch: ShotsCheckIn.setPaused(true) halts all check-in traffic — no backend involvement required.
• Env-var gate: the tool only runs if VOLUME_TOOL_ENABLED=true is set — disabled by default.
• Public transparency: the Volume Tool's existence and implementation are documented in this whitepaper; the community can audit it via GitHub.

13.4 Sunset Plan

The Volume Tool's life is tied to protocol maturity:

• Real DAU > 5,000: S-curve weight drops to 30%.
• Real DAU > 20,000: drops to 10%.
• Real DAU > 100,000: fully off; retained only as an emergency tool.

14. Threat Model and Security

14.1 Trust Assumptions

14.2 Identified Threats and Mitigations

14.3 Implemented Security Engineering Practices

• OpenZeppelin audited base: All contracts inherit OZ 4.x's ReentrancyGuard, Pausable, Ownable, SafeERC20, ERC20Permit, ERC20Votes.
• Foundry fuzz tests: core contracts pass 256-round fuzz testing.
• Audits: one internal audit before v1.0; one external third-party audit planned before v1.1.
• Bug bounty: ImmuneFi or similar platform launch after v1.x.
• Environment isolation: completely independent RPC, database, and key infrastructure across test and main networks.

14.4 Known Limitations

1. EVM stealth addresses require gas for withdrawal: ShotsAI uses a relayer wallet, which is centralized; future plans include decentralized relayer networks (e.g., Gelato).
2. Multi-hop time windows: high-privacy modes need hour-scale delay — unsuitable for instant settlement.
3. On-chain data is permanent: if keys leak or quantum computing matures, today's stealth payments could be retroactively de-anonymized. This is universal to non-zk privacy protocols.
4. Frontend operational dependency: users must trust that the ShotsAI frontend isn't running malicious code — universal to all web dapps. Mitigated long-term via IPFS deployment + content addressing + reproducible builds.

15. Compliance Posture and Regulatory Considerations

15.1 ShotsAI's Regulatory Position

ShotsAI is a non-custodial protocol: contracts hold no fiat, perform no KYC, issue no stablecoins, do not match orders. Under major regulatory frameworks (FinCEN in the US, MiCA in the EU, PSA in Singapore, PSAct in Japan), ShotsAI does not constitute:

• A money services business (MSB)
• A crypto exchange
• A crypto custodian
• A stablecoin issuer

ShotsAI is analogous to a "crypto-native BitTorrent" — an open-source protocol that users run nodes (wallets) for; the dev team maintains only a reference implementation.

15.2 Compliance-Friendly Design

• Circuit breakers (per-tx and daily caps) prevent the protocol from being used for large-value money laundering.
• Multi-sig arbitration makes the protocol look "like PayPal" rather than "like Tornado Cash."
• No mixing pool: stealth addresses are derived from the recipient's keys; sender and recipient are 1:1, no many-to-many obfuscation.
• Auditability: all on-chain data is public; regulators can trace flows under appropriate legal process.
• Geo-blocking hook (compliance-grade): the frontend reserves an interface to geo-block specific regions (e.g., OFAC sanctions list) when required, though disabled by default.

15.3 Key Difference from Tornado Cash

The core reason Tornado Cash was sanctioned is its anonymity-set mechanism — many users' funds are pooled and mixed, making it impossible to separate clean funds from laundered funds. ShotsAI stealth addresses have no mixing pool:

• Funds A sends to B's stealth address never leave the A→B pair.
• The recipient has full control over the stealth address; no coupling with other users' funds.
• Chain analysis cannot directly see A→B, but the viewing key holder can fully audit.

This "transparent to the key holder, unlinkable to outsiders" model is structurally analogous to traditional bank accounts ("the holder sees their statement; third parties don't") — regulator-friendly.

15.4 User Responsibility

The ShotsAI protocol itself makes no compliance judgments about user payment behavior (protocol neutrality). Within their jurisdiction, each user must:

• Ensure compliance with local AML regulations.
• Self-report taxes (on-chain activity is reportable in most jurisdictions).
• Assess local legal risk of using privacy payments where applicable.

The frontend displays an Acceptable Use Policy prohibiting use for money laundering, terrorist financing, or transactions with sanctioned entities. Violators will be frontend-blocked (although the contract itself cannot enforce).

16. Roadmap

16.1 Completed (as of 2026-05)

16.2 v1.1 (2026 Q3)

• ✅ Production server deployment (pm2 + nginx + Cloudflare)
• ✅ Load testing (target: 50K req/min, 200K concurrent WebSocket)
• ✅ Accessibility (WCAG 2.1 AA compliance)
• ✅ Language expansion (Japanese, Korean, Portuguese)
• ✅ $SHOT mainnet launch + DEX liquidity bootstrapping + airdrop snapshot
• ✅ Bug bounty launch (ImmuneFi)

16.3 v1.2 (2026 Q4)

• ⏳ Third-party security audit complete (target: Trail of Bits, CertiK, or OpenZeppelin)
• ⏳ Mobile PWA optimization (offline cache, push notification integration)
• ⏳ Account Abstraction integration (EIP-4337) — make gasless UX the default
• ⏳ $SHOT Staking contracts live; staking APR activated
• ⏳ Volume Tool weighting dropped to 30%

16.4 v2.0 (2027 Q1–Q2)

• ⏳ DAO governance path fully transitions to $SHOT voting
• ⏳ Protocol revenue buy-back of $SHOT activated
• ⏳ Cross-chain escrow: LayerZero / Wormhole integration; lock on chain A → mirror on chain B → cross-chain atomic release
• ⏳ More EVM chains: Polygon, Arbitrum, Base, opBNB
• ⏳ Native mobile apps: iOS / Android AA wallets + push

16.5 v3.0 (Post-2027 Q3)

• ⏳ ZK proof integration: optional zk-SNARK path for high-threat-model users
• ⏳ AI Agent integration: MCP interface so AI agents can auto-select payment modes under user authorization
• ⏳ DePIN integration: decentralized relayer network incentivized by $SHOT
• ⏳ On-chain credit scoring: reputation system based on escrow / dispute history
• ⏳ ShotsAI for Business: B2B-specific features (multi-account, audit API, SLA) with subscriptions priced in $SHOT

17. Governance and DAO Evolution

17.1 Current Governance Model (v1.x)

• Contract ownership held by a 5/9 multi-sig, including core team and early advisors.
• Multi-sig dispute committee appointed by the owner; initial roster of 5 covers legal, community, and technical audit roles.
• All fee / parameter / new-chain decisions go through the multi-sig vote.
• The DAO Arbitration contract is deployed but not yet the primary dispute path — awaiting $SHOT mainnet launch and community maturity.

17.2 Governance Parameters

17.3 Progressive Decentralization

Stage 1 (current v1.x): Core team multi-sig + community consultation

• The team holds all admin rights; the community expresses opinions via Discord / forum / off-chain polls.

Stage 2 (v2.0 launch): $SHOT holder votes + multi-sig execution

• Major parameter changes are decided by $SHOT vote; the multi-sig executes the result.

Stage 3 (v3.0): Fully DAO-governed

• The multi-sig exits the governance loop; all changes flow through on-chain proposals + voting + Timelock executor.
• The ShotsAI team becomes only the open-source project's core maintainer with no special privileges.

18. Team, Partners, and Community

18.1 Core Team

ShotsAI was founded by a cross-disciplinary team spanning cryptography, smart contract engineering, product design, and compliance / legal. The team has serial entrepreneurship experience with prior tenure at top-tier DeFi protocols, Web2 payments platforms, and traditional financial institutions. Specific identities will be disclosed during v1.1 launch following KYC audit.

18.2 Advisors

• Smart contract security advisor: prior audit work at OpenZeppelin, Trail of Bits, or equivalents.
• Legal advisor: coverage across US, Singapore, and EU compliance frameworks.
• Growth advisor: prior leadership taking multiple Web3 protocols from 0 to 100K MAU.

18.3 Partners

• Infrastructure: Built on BNB Chain and Kasplex Network.
• RPC providers: QuickNode, Ankr, PublicNode (multi-RPC redundancy).
• Wallets: MetaMask, WalletConnect, Coinbase Wallet, Trust Wallet.
• Oracles / security: Forta, Chainalysis (compliance monitoring).

18.4 Community and Ecosystem

• Developer community: SDK and MCP interface open after v1.1; third-party dapps encouraged to integrate ShotsAI payment.
• User community: Discord, Twitter, Telegram, X Spaces.
• Education: whitepaper (zh/en), technical documentation, video tutorials, training programs.
• Ambassador program: Regional Ambassadors launching with v2.0, covering East Asia, Southeast Asia, LATAM, and the Middle East.

19. Risk Disclosure

19.1 Technical Risk

• Smart contract vulnerabilities: despite audits, undiscovered bugs may exist. ShotsAI cannot guarantee 100% fund safety.
• Chain congestion / gas spikes: extreme BSC or Kasplex congestion may delay escrow auto-release.
• RPC node unavailability: edge case where all RPCs go down simultaneously, preventing frontend transaction initiation.
• Quantum computing threat: mature quantum computing could eventually break ECDSA, affecting all EVM protocols.

19.2 Regulatory Risk

• Privacy protocol regulation tightening: some jurisdictions may impose restrictions on privacy-payment protocols.
• Stablecoin regulation: the USDT / USDC the protocol depends on may face regulatory restrictions.
• DAO legal status: DAO governance legal recognition remains ambiguous in many countries.
• Token securitization risk: $SHOT may be classified as a security in certain jurisdictions, affecting issuance and circulation.

19.3 Market Risk

• Crypto bear market: overall on-chain activity declines, hurting protocol revenue and growth.
• Competitors: existing or new protocols may replicate ShotsAI's core design.
• Network value collapse: major events on the underlying chains (BSC / Kasplex) impact the protocol.
• $SHOT price volatility: dramatic token price swings may impact staking incentives and ecosystem expectations.

19.4 Operational Risk

• Team attrition: core members leaving may slow protocol evolution.
• Operational wallet compromise: relayer / HD wallet key leaks may cause short-term service outages (but never affect user funds).
• Sustained backend DDoS: impacts UX, doesn't impact on-chain state.

20. Conclusion

ShotsAI is not "yet another escrow protocol," not "yet another privacy protocol," not "yet another chat dapp."

Its product thesis is simple: for crypto payments to truly enter ordinary people's daily lives, safety + privacy + social semantics must be delivered as an integrated protocol-level capability. Users should not give up privacy to get escrow protection, should not give up social context to get private payments, and should not give up non-custody to get social.

Through five composable payment modes, end-to-end encrypted chat, a dual-track (multi-sig + DAO) arbitration system, a complete off-chain indexing layer, and native multi-chain support — anchored by $SHOT, which unifies governance, fee discounts, staking yield, and premium-feature access into a single asset — ShotsAI lets users, developers, and institutional integrators bind to the same protocol-value language.

The contracts are live on mainnet. All five payment modes and every social feature are usable today. Every escrow, every stealth transfer, every encrypted message from now on is a concrete realization of ShotsAI's protocol thesis:

Funds belong in your own wallet. Privacy should be the default. Semantics should center on people, not addresses. Arbitration should be community consensus, not unilateral platform decree.

We invite users, developers, researchers, compliance professionals, and institutional partners to join the next phase of protocol building, ecosystem expansion, and governance evolution.

21. Glossary

22. On-chain Address Inventory

22.1 BSC Mainnet (Chain ID: 56)

22.2 Kasplex Mainnet (Chain ID: 202555)

22.3 Testnets (Development)

• BSC Testnet (Chain ID: 97): see contracts/deployments/bsc-testnet.json
• Ethereum Sepolia (Chain ID: 11155111): see apps/backend/src/config/blockchain.ts
• Kasplex Testnet (Chain ID: 167012): see apps/backend/src/config/blockchain.ts

License and Copyright

This whitepaper is licensed under CC BY-SA 4.0. ShotsAI protocol code is currently private; v1.1+ will be open-sourced on GitHub under MIT. All contract addresses, technical parameters, and roadmap items may change during protocol evolution — consult the official GitHub repository and website for current state.

Contact

• Repository: https://github.com/shots-chat/ShotsAI
• Website: https://shots.chat
• Twitter / X: @shotsai_protocol (placeholder)
• Discord: discord.gg/shotsai (placeholder)
• Email: team@shots.chat