The WEVONE data philosophy, in numbers — WEVONE

In classical platform economics, user data is booked as an intangible asset with infinite marginal utility. At WEVONE, every byte of unencrypted, persistent user telemetry is calculated as an operational liability. Storage incurs infrastructure costs, breaches destroy enterprise value, and long-tail behavioral tracking yields diminishing returns for actual marketplace liquidity.

To build a platform that spans ten operational universes—from second-hand fashion (Tutus) to peer-to-peer transit (Pilote) and local services (Mission)—we had to establish a strict numerical threshold for what data is strictly necessary to settle transactions, resolve disputes, and run automated arbitration.

Here is the quantitative breakdown of the WEVONE data engine: what is live, what is in beta, and what we deliberately refuse to collect.

0: Raw Personal Identifiers in Cross-Universe Analytics

The standard multi-service super-app merges user identity across verticals to build advertising profiles. WEVONE’s analytics pipeline operates on zero persistent raw identifiers.

When a user completes a rental on Nest and subsequently offers a service on Mission, the underlying telemetry engine does not merge these actions into a central behavioral dossier. Instead, identity is split using asymmetric cryptographic hashes mapped to universe-level ledgers.

Live status: Operational across all 10 live universes.
Mechanism: Mia’s context memory evaluates short-term intent within an active session using ephemeral keys. Once a transaction reaches finality and the dispute window closes, the temporary session graph is detached from the user’s primary account key and flattened into an anonymous aggregate metric.
Result: WEVONE cannot sell targeted ad profiles to third parties because the relational database required to query historical browsing across Tutus and Pet does not exist in our production clusters.

128 Kilobytes: The Maximum Session Context Payload

Large language models and automated agents often collapse under the weight of bloated context windows. When Mia arbitrates a transaction dispute or routes a service request, she does not read a user's entire multi-year platform history.

We cap Mia’s context payload at 128 kilobytes per active session. This payload contains:

The state of the current universe ledger (e.g., escrow status, item condition logs).
The counterparties' Contribution Scores (a bounded numerical metric representing historical dispute outcomes and fulfillment speed).
The active contract parameters (delivery deadlines, agreed price in WEVAR or fiat).
The last 15 structured event logs relevant to the current job or rental.

By constraining context memory to 128KB, arbitration decisions remain deterministic, auditably fast, and inexpensive to process. If a dispute requires historical context beyond 128KB, Mia queries the immutable event ledger for specific cryptographic proofs rather than ingesting raw text threads.

24 Hours: The Escrow Settlement and Dispute Window

Data retention is directly tied to financial state. In traditional marketplaces, funds are held in bank escrow while behavioral monitoring algorithms flag potential fraud over 7 to 14 days. WEVONE enforces a 24-hour default settlement rule for standard physical and service transactions.

Here is how the WEVONE transactional escrow mechanism handles data during those 24 hours:

Hour 0:00 (Initiation): Escrow locks funds (fiat or WEVAR utility tokens). The transaction log generates a unique, temporary dispute hash.
Hour 0:01 to 23:59 (Execution): Geolocation beat checks (for Pilote) or digital sign-offs (for Tools or Mission) deposit cryptographic heartbeat markers onto the universe-level ledger. No continuous GPS tracks are recorded; only discrete check-in beats at origin and destination.
Hour 24:00 (Settlement): If no dispute flag is raised by either party or triggered by Mia’s anomaly detector, the smart escrow contract auto-executes, disbursing funds to the seller.
Hour 24:01 (Data Pruning): Transient session telemetry (chat logs, granular location beats) is purged from active Redis memory. Only the finalized transaction receipt and updated Contribution Score delta persist on the ledger.

10 Universes, 1 Unified Context Graph

A common architecture failure in multi-service networks is siloed infrastructure. If Nest (short-term rentals) does not share context with Tools (equipment sharing), a user with a pristine reputation renting a house has to build trust from scratch when borrowing a lawnmower.

WEVONE solves this with a single, permissioned context graph anchored by the Contribution Score. Rather than storing what you bought, the graph stores how reliably you fulfilled your obligations.

Worked Example: Borrowing Equipment on Tools

To see how this functions in production, consider a concrete scenario on the Tools universe.

Request: User A requests a high-pressure washer from User B for 48 hours. Escrow holds €35 in fiat.
Handoff: Both users scan a local QR token. The event deposits a timestamped state change onto the Tools universe ledger.
Telemetry: During the 48-hour rental, WEVONE collects zero ambient telemetry. No location tracking, no device polling, no background pinging.
Return & Anomaly: User B claims the equipment was returned with a cracked casing. User B opens a dispute within the 24-hour window.
Arbitration: Mia ingests the pre-rental photos (hashed at handoff), the post-rental dispute logs, and the historical Contribution Scores of both parties—totaling 42KB of data.
Resolution: Mia identifies that the pre-rental photo already showed hairline stress fractures on the casing hash. The dispute is closed; escrow releases funds to User A.
Cleanup: 30 days after resolution, raw photo uploads are purged from bucket storage. The ledger retains only the hash comparison outcome and the final score adjustment.

Honest Trade-offs and Architectural Limits

Minimizing data retention is not without friction. Our current architecture has real, measurable limitations in its current early deployment:

Cold-Start Latency for Recommendations: Because we do not track off-platform browsing or long-term behavioral preferences, item recommendations on Tutus can feel unrefined for new accounts. Personalization relies entirely on active session signals rather than deep historical profiles.
Dispute Appeal Overhead: If a user contests a decision after the 30-day raw log purge window, human operators must rely entirely on the cryptographic ledger summary. If the user failed to upload evidence during the active dispute window, there is zero recoverable text or image history to fall back on.
Ledger Sync Latency: Synchronizing state across ten universe-level ledgers while maintaining strict cryptographic boundaries currently incurs an average 420ms overhead on write operations during peak hours.

WEVONE is early. We do not claim to have solved multi-service marketplace scalability forever. But we have proven that a platform can facilitate trust across ten operational domains without converting its database into a surveillance apparatus.