This repository contains the DotNS smart-contract suite: reference and proof-of-concept code and patterns for a Polkadot naming system. It is intended for reference and experimentation, not as a production-ready artefact.

Unless a specific release states otherwise, this repository has not received a full security audit. Use in production or production-like deployments should only follow an independent security review of the relevant code, configuration, generated output, and deployment environment.

Even where no Parity-operated production deployment exists today, this code may be used by third parties on live networks, or reused in future production contexts once published.

The contracts are scanned on every pull request by static-analysis tools, currently Slither and 4naly3er, with the reports published to GitHub Pages. All findings raised by these tools have been reviewed and are deemed false positives or accepted non-issues for this codebase. They are retained for transparency rather than as a list of outstanding defects, so a tool reporting a finding is not in itself grounds for a vulnerability report. If you believe a specific finding has genuine, demonstrable impact, raise it through the disclosure process below with the evidence required under "What to report".

Security fixes are provided only for versions, packages, or branches actively maintained by Parity. Experimental, archived, deprecated, or explicitly-unsupported packages, examples, or branches may not be triaged unless the issue affects maintained packages, Parity-operated infrastructure, user funds, private keys, signing flows, or transaction integrity.

This repository is not in scope for Parity's paid bug bounty programme unless explicitly listed in the official bounty scope at the time of submission. Reports may still be reviewed through responsible disclosure, but bounty eligibility applies only where the affected asset or vulnerability class is explicitly in scope.

Report an issue only if it demonstrates realistic impact against one or more of:

• Parity-operated production infrastructure or deployed services;
• maintained packages downstream users are expected to consume;
• user funds or assets;
• private keys, seed phrases, signer flows, or key-management boundaries;
• transaction construction, integrity, or signing intent;
• remote code execution or credential compromise in a realistic deployment.

Local-development-only issues; demo/example/testnet-only issues; missing security headers on non-production demos; missing rate limiting in local examples; dependency reports without a working exploit path or that don't affect shipped packages; hypothetical attack paths; "this code is unaudited"; documented known limitations; unsafe use contrary to documented warnings; issues requiring access to internal Parity systems not in scope.

Do not open a public issue for a qualifying vulnerability. Email security@parity.io with:

• the affected repository, package, commit, branch, or release;
• clear reproduction steps and realistic impact;
• whether it affects production infrastructure, maintained packages, user funds, keys, signing, or only local/demo/testnet usage;
• any proof of concept, logs, or generated code involved;
• assumptions required for exploitation.

Don't access, modify, or delete data that isn't yours; don't disrupt services; don't extract keys or secrets beyond what's needed to demonstrate impact safely; don't test against production systems not in scope; no social engineering or physical attacks; don't disclose publicly until Parity has had a reasonable opportunity to remediate.

Before any production or production-like deployment, review at minimum: how keys/seeds/signers are generated, stored, and destroyed; whether signing prompts display transaction intent before approval; whether transactions are built against the intended chain/account/network; whether deployment scripts default to testnet/devnet; whether storage assumptions are appropriate; whether examples rely on internal/test/unstable endpoints; whether dependencies are pinned and reviewed; whether contract code has been manually reviewed and tested before deployment; and whether deployment configuration, CORS, admin/owner roles, upgrade authority, logging, and telemetry suit the intended environment.