Security Policies

These Security Policies describe the public security posture for web3 validator and the web34ever.com site. They are intended for delegators, network teams, partners, and security researchers who need a clear point of reference.

1. Non-custodial delegation model

Ordinary staking with web3 validator is non-custodial. Delegators use the official wallet, explorer, or staking interface for a network and keep control of their own private keys. web3 validator receives delegated voting power according to the protocol; it does not receive custody of delegated tokens through the website.

2. Validator operational security

Operational controls vary by chain, but the baseline approach is conservative:

• separate operational procedures per network and validator role;
• careful signing-key handling and restricted access to validator hosts;
• monitoring for downtime, missed blocks, peer health, resource pressure, and upgrade windows;
• change coordination around chain upgrades, client releases, and network-specific advisories;
• fallback procedures designed to avoid unsafe restarts or duplicate signing paths.

Exact infrastructure details are intentionally not published, because exposing them would make targeted attacks easier. Public validator profiles and repository links remain available where they help delegators verify participation.

3. Slashing risk management

web3 validator treats slashing prevention as a core operational responsibility. Controls are designed to reduce double-sign and downtime risk, but no public validator can eliminate all risk. Protocol bugs, client bugs, data-center incidents, network partitions, governance changes, and human error can still affect validator performance.

This policy does not create a reimbursement guarantee. Any incident-specific remediation, if applicable, would be communicated through public channels after the on-chain facts and root cause are understood.

4. Site and application security

• Static hosting. web34ever.com is generated as static SvelteKit output and served through Cloudflare Pages.
• No wallet connection. The website does not request seed phrases, private keys, wallet signatures, or token approvals.
• No server-side contact database. The contact form opens a mailto link instead of storing submissions in an application database.
• HTTPS via Cloudflare. Public traffic is served over HTTPS with Cloudflare edge security and caching.
• Limited third-party code. The site does not intentionally load advertising pixels, social tracking widgets, or analytics scripts.

5. Incident response

For validator incidents, the operational priority is to protect the network and avoid making a bad state worse. Typical response steps include isolating the affected validator, confirming on-chain status, reviewing logs, coordinating around network upgrade channels where relevant, restoring service safely, and communicating material outcomes when facts are known.

For website incidents such as defacement, broken deployment, or suspicious third-party links, the priority is to remove the issue, redeploy verified static assets, rotate affected credentials if needed, and publish a correction when users may have been exposed to risk.

6. Responsible disclosure

If you believe you found a vulnerability in web34ever.com, a public web3 validator repository, or a web3 validator-operated public surface, report it privately to [email protected] before public disclosure. Include the affected URL or repository, a clear reproduction path, impact, and any safe proof of concept.

Please do not perform denial-of-service attacks, social engineering, physical attacks, attacks against third-party services, attempts to access private keys, or activity that could disrupt a live blockchain network. There is no public bug bounty unless one is announced separately in writing.

7. User safety checklist

• Always verify validator addresses in official explorers or staking interfaces before delegating.
• Never share seed phrases, private keys, or wallet passwords with anyone claiming to represent web3 validator.
• Be cautious with lookalike domains, fake Telegram accounts, and direct messages offering support.
• Use hardware wallets or secure key management for significant balances where supported by the network.

8. Changes

We may update these Security Policies as infrastructure, site architecture, or operational practice changes. The "Last updated" date reflects the latest revision.

9. Contact

Security enquiries can be sent to [email protected].