Privacy and data handling

Raidz uses consented social and wallet links to evaluate creator-market fit. Privacy is an architectural boundary, not a copy-only promise.

Data categories

Identity data

Display name, bio, locale, jurisdiction, languages, regions, narratives, public visibility, X/Telegram handle and normalized public profile, linked wallet, provider timestamps, and consent version.

Score and evidence

Normalized component values, model version, source timestamp, confidence, explanation, snapshots, and verified campaign history.

Marketplace and settlement

Project/campaign terms, claims, deliverables and hashes, verification results, fraud signals, reviews, reward accounting, transaction receipts, and disputes.

Analytics and attribution

Pseudonymous actor/subject, event type, source category, consent, policy version, timestamps, dedupe key, expiry, and typed outcome properties.

Placement rules

Social metrics, provider profiles, content analysis, behavior, score components, explanations, and consent records remain offchain. Onchain records should contain only public wallet/campaign identifiers, hashes, amounts, nonces, timestamps, signer outcomes, and settlement state required for verifiability.

Consent and purpose

Each provider connection requires informed user action. Wallet attribution requires separate granted consent. X data is read-oriented; Raidz must not use it to automate likes, reposts, follows, mass replies, or paid metric inflation. Telegram notifications begin only after the user starts or authorizes the bot.

Minimization and security

• Hash provider subject identifiers with a secret pepper.
• Encrypt refresh/access token material at rest.
• Store signature hashes instead of raw wallet signatures where possible.
• Do not retain raw provider responses by default.
• Sample audience graphs rather than continuously downloading complete networks.
• Avoid matching social data to off-platform identity without explicit consent.
• Redact credentials, cookies, signatures, and private evidence from logs.

Retention

The typed analytics model uses 90-day retention for short-lived visit/intent/referral events and 365 days for activation, marketplace, core-value, and most attribution events. Production needs automated expiry and deletion. Settlement and security records may require longer, specifically documented retention.

User controls

The current API allows X, Telegram, and wallet disconnection. Social rows are deleted; active wallet links are revoked. A complete production privacy workflow still needs authenticated export, correction, account deletion, token revocation, provider-source deletion, downstream analytics deletion, and clear exceptions for required settlement/security records.

Public profiles

Profile visibility defaults to false in the database. Public creator cards must distinguish verified live users from fixtures and must not expose private evidence or unnecessary provider data.