Security first

Built to keep bots out and funds safe

Security isn't a setting in Zolea — it's the foundation. Here's exactly how the join gate, the wallet model, the database and your private spaces protect you, layer by layer.

Bot-proof joins

A join gate bots can't afford

Every join must solve a single-use, server-issued proof-of-work challenge and pass a captcha before it counts — and both are re-verified on the server, so there's nothing to fake from the browser.

  • Solving costs real CPU per attempt — trivial for one person, ruinous for a botnet.
  • Challenges are single-use and expire, so they can't be pre-computed or replayed.
  • Difficulty scales up automatically when a server is under attack.
  • Invisible to real users: a few seconds in the background and you're in.
  • Per-wallet and per-IP rate limits cap abuse even if a challenge is solved.
Verify you're human

This community runs a quick proof-of-work + captcha check to keep bots out.

Proof-of-work solved

Last step — click the rocket

🍎🚀🌙🐱🍕
Non-custodial

You keep your keys. Always.

You sign in by signing a message with your wallet — there's no password to leak and no seed phrase to hand over. Zolea is non-custodial by design: we never touch your keys or your funds.

  • Sign-in is a wallet signature over a one-time nonce — nothing more.
  • Every trade, sponsorship and donation runs in your own wallet, on-chain.
  • There's no account balance for us to hold and nothing for us to lose.
  • No email, no password database, no custody — your wallet is your identity.
Z
Welcome to Zolea
A community platform for crypto
Connect Phantom

Connecting just asks you to sign a message to prove the wallet is yours. It's not a transaction — Zolea never sees your keys or funds.

or
you@example.com
Data access

Row-level security on every table

Access rules live on the database itself, not just the UI. Every table enforces row-level security, so a member can only ever read or write the exact rows their role allows — even a forged request can't reach data it shouldn't.

  • Policies are enforced at the database, independent of any client code.
  • Members read only their own messages, servers, roles and DMs.
  • Private My Space notes are never readable by anyone but their owner.
  • A tampered or replayed request simply returns nothing it isn't entitled to.
Row-level security
messages in servers you joinedread
your own DMs & profileread
another member's DMsblocked
someone else's private notesblocked
Encrypted messages

End-to-end encrypted, the easy way

Your DMs and your personal My Space notepad are encrypted on your device before anything is ever stored — and it's completely automatic. Keys are generated and synced for you, with no passphrase or recovery codes to manage, so the server only ever holds ciphertext.

  • Encryption and decryption happen entirely in your browser.
  • Keys sync across your devices automatically — nothing to set up, nothing to lose.
  • The server stores ciphertext only — never your plaintext.
  • Other members can't read your DMs or notes; only the two of you can.
Encryption is on
Automatic — no passphrase, no codes
Keypair generated on devicedone
Backed up & synced (encrypted)done
DMs & My Space unlockedlive
ECDH P-256 · AES-256-GCM · fresh IV each message · sealed in your browser

Your private key is generated on-device and backed up encrypted, so it follows you to new devices automatically — nothing to set up, nothing to lose.

Enforcement

Nothing trusts the browser

Every action — joins, posts, payments, role changes — is re-validated on the server against your real permissions. Tampering with the client gets you exactly nowhere.

  • Permissions are checked server-side on every request, not just hidden in the UI.
  • Editing the page or forging an API call can't grant access you don't have.
  • Slow-mode and posting rules are enforced where they can't be bypassed.
  • On-chain payments are verified before any sponsorship or perk unlocks.
Server-side enforcement
complete_verification · re-checks PoWenforced
Grant self a role in browserrejected
Skip captcha, call the RPC directlyrejected
Every action re-validated on the server — the client is never trusted.
Media & identity

Locked-down media and masked identity

Uploads are served through short-lived signed URLs that can't be shared or scraped, and account details are masked by default. Wallets verify on-chain ownership before any token-gated perk unlocks.

  • Media is delivered via expiring signed URLs — a leaked link dies in seconds.
  • Wallet addresses and account details are masked in the UI by default.
  • On-chain ownership is verified before gated perks or badges appear.
  • No personal data in URLs, and the most privacy-preserving defaults throughout.
Locked-down media & identity
…/media?sig=9f3a…&exp
expires in 60s
Wallet9xQe…k4Tz
Signed URLs can't be shared or scraped; account details are masked by default.

Defense in depth

A few of the other guardrails working quietly in the background.

Single-use, expiring challenges Per-wallet & per-IP rate limits On-chain payment verification Captcha + proof-of-work on every join End-to-end encrypted DMs & My Space Server-side permission checks

Safe by default

Connect your wallet and see it for yourself — nothing to trust, everything verifiable.