Safety Architecture

Effective and last updated: July 29, 2026

Moolzi uses defense in depth. No single device, network, or behavioral signal automatically decides that a person is fraudulent.

Reward integrity

Every catalog launch receives a short-lived random session. Provider callbacks must authenticate, match the account and provider session, and carry a unique source transaction identifier. Duplicate callbacks are idempotent. Reversals append history instead of rewriting it.

Account and device controls

Distributed rate limits cover signup, sign-in, offer sessions, and payouts. Network reputation, device hashes, integrity attestation, account age, unusual velocity, coordinated destinations, and provider quality can contribute to a versioned risk assessment.

Payout controls

Balance deduction and payout request creation happen atomically. Low-risk requests queue normally; medium-risk requests receive a time-bound hold; high-risk requests enter human review. Workers claim jobs atomically, use idempotency keys, and append every state transition.

Operational safeguards

Admin endpoints require rotatable tokens, optional IP allowlists, and immutable action audits. Hot-wallet balances should be capped, separated by chain and environment, monitored continuously, and reconciled against confirmed transactions. Fiat providers remain disabled until commercial and compliance approval is complete.

Responsible disclosure

Report a suspected vulnerability to security@moolzi.com. Do not access other users’ data, disrupt service, or move funds. A formal safe-harbor and response SLA must be finalized before public launch.