# Slipvio · Whitepaper An AI consumer data network built on consumer contributions. 2026-09-28 ## Abstract Slipvio starts with receipts. It structures everyday purchase records voluntarily submitted by consumers and produces aggregated insights for authorized brands and analysts. The project connects consumers contributing data, organizations asking commercial questions, and operators maintaining extraction, validation and reward rules. The first release uses a browser DApp, wallet identity, AI receipt extraction and an offchain ledger. Eligible points redeem for a token airdrop from a fixed pool, allocated proportionally. The redemption framework is designed; actual issuance, appeals and onchain claims remain to be integrated. ## 01 / From fragmented records to shared value A merchant sees its own transactions; a consumer shops across brands, channels and categories. Slipvio tests the proposition that consumer-contributed receipts can complement a single-merchant view and help teams frame and investigate questions about category mix, spending and purchase frequency. This value depends on authentic contributions, sufficient valid samples and concrete buyer needs. Voluntary submissions introduce selection bias and do not automatically represent a population, region or market. Category proportions within the sample are not presented as market share. ## 02 / Product and participation Consumers sign in with an EVM wallet signature, with no gas required for sign-in. After acknowledging data use, they submit an image and track extraction. Validated records earn points under the campaign rules. Authorized business and research accounts view their permitted datasets. Operators review uncertain records, freeze campaigns and export contribution snapshots. All spending categories are welcome. The first release accepts JPG, PNG and WebP images of paper receipts or digital receipt screenshots. Open category coverage does not guarantee recognition of every language, layout or item. Unreliable fields remain unknown or are sent for review. ## 03 / How data moves Uploaded images pass format and size checks before entering private storage. Background jobs use DeepSeek to extract merchant, date, currency, amount and recognizable line items. Structured results pass field validation and basic duplicate checks before acceptance. Monetary totals are grouped by currency rather than added across currencies. Processing states are queued, processing, accepted, needs review, rejected and failed. Records awaiting review earn no immediate points. Users may correct details for operator approval; failed jobs support limited retries. Image hashes and purchase fields provide basic duplicate detection, not definitive proof of authenticity. ## 04 / The business intelligence layer The initial dashboard shows valid receipt counts, category coverage, category distribution and spending by currency. The database computes statistics; AI explains those aggregates and suggests questions for further validation. Ordinary business accounts cannot browse users’ original receipt images. Brand comparisons, time trends, category combinations, custom research and data APIs are potential extensions, subject to data coverage, authorization and customer demand. The current product does not claim complete competitor transaction data, real-time industry monitoring or attributable marketing outcomes. ## 05 / Contributions and incentives Slipvio uses valid contribution points to allocate its first token airdrop. Accounts meeting the threshold and review requirements redeem a proportional share of the season pool. The proposed genesis pool is 5% of total token supply, fully unlocked at claim with no later vesting. The first season lasts 42 complete UTC calendar days. Each validated receipt earns 100 PTS. An account may submit up to 10 receipts per day, earning at most 1,000 PTS daily or 42,000 PTS across the season. Daily limits reset at 00:00 UTC. Failed, rejected, duplicate and pending-review receipts earn no points. A receipt counts once. Accounts qualify with at least 1,000 final eligible PTS (10 valid receipts), a signature-bound wallet and a passed contribution review. Each participant uses one contribution account; multiple wallets must not be used to resubmit receipts or fabricate purchases. A wallet signature proves address control, not unique personhood. Individual allocation = season pool × individual final eligible points ÷ total final eligible points across qualifying accounts. Allocation is rounded down to the token’s smallest unit; rounding dust follows the unclaimed-balance policy. Only qualifying, reviewed accounts enter the denominator. Each point has equal weight. T is the collection deadline. From T to T+7 days, resolve remaining extraction, review and anomalous records. At T+7, publish individual preliminary points and eligibility and open a 7-day appeal window. From T+14, resolve appeals before freezing the final snapshot. Unresolved reviews delay freezing with revised dates announced; reviews are not silently skipped. First claims target Q1 2027 with a 90-day window. Eligible users connect the snapshot address, verify their allocation and claim through the distribution contract, fully unlocked in one claim. Sign-in requires no gas; onchain claiming may require network gas. No payment to the project or approval to spend existing tokens is required. After the claim window, unclaimed tokens and rounding dust return to a publicly disclosed future-contribution reserve, not as a top-up for existing claimants. Publish amounts and onchain records. If no accounts qualify, no division or allocation occurs; retain the entire pool and announce its future use. This is redemption design v1; claiming has not started. Total supply, ticker, chain and contract address remain to be set. The actual pool quantity must be published and fixed before the season opens. Claim contracts, eligibility lookup and appeals remain to be integrated; the calculator is not an allocated balance. ## 06 / The role of Web3 Wallets provide reusable signature identities and may connect contribution records with future onchain eligibility. Storage, extraction and points settlement currently run on the server. Private receipts and purchase details are not written to a public chain, and the offchain database is not described as a decentralized consensus network. The proposed first points-redemption pool is 5% of token supply, allocated proportionally and fully unlocked at claim. Supply, ticker, issuance chain, remaining allocations and governance powers remain undecided. Before deployment, define permissions, complete review and publish verifiable addresses. Supported sign-in chains do not determine the issuance chain. ## 07 / Business model and ecosystem Potential revenue sources include authorized insight subscriptions, thematic research and custom analysis. Brands, consultancies, data companies and new market entrants are prospective users. Pricing and commercial arrangements require demand validation; unconfirmed customers, revenue or partnership scale are not reported. Consumers create data coverage, operators maintain rules and processing, and business users frame questions and evaluate insights. If recurring business develops, incentive budgets may be adjusted against revenue, operating costs and campaign results. No automatic buyback, dividend or revenue-sharing commitment is currently defined. ## 08 / Data boundaries and limitations Users should submit only receipts they are authorized to share and cover names, phone numbers, membership IDs and payment details before uploading. An external AI service processes images; absolute zero retention is not promised. Original-image access requires authorization, while business users access permitted aggregates. Retention periods, deletion-request channels and operator contact details must be defined before public collection. Extraction errors, duplicate submissions, incentive-driven low-quality samples and service interruptions may affect results. Limits, status tracking, manual review and audit ledgers reduce these effects without guaranteeing perfect recognition, fraud prevention or availability. Demonstration data is presented separately from real contributions. ## 09 / Delivery and current status The local build implements wallet sign-in, receipt uploads and queues, the extraction adapter, points ledger, aggregate insights and operational snapshots. Production use still requires live AI and storage credentials, real-receipt integration checks, hosting, domain configuration and launch verification. Local implementation is not a live public network. The roadmap runs from Q3 2026 through Q4 2027: foundations in Q3 2026, the genesis contribution season in Q4, first airdrop redemption targeted in Q1 2027, business validation in Q2, data-service productization in Q3, and ecosystem collaboration and annual review in Q4. Quarterly goals are plans, not completed results. Exact campaign and claim dates require formal notices.