Safety Norms: Blockchain Development

1Purpose, Scope, and Safety Principles

These norms apply to anyone who writes, reviews, tests, or deploys blockchain software. This includes smart contracts, node software, wallets, bridges, oracles, token issuance tools, and supporting back-end services. They also cover the tools used to build them, such as development environments, test networks, continuous integration pipelines, and package repositories.

Three principles guide everything here. First, deployed code and confirmed transactions are often irreversible, so prevention matters more than correction. Second, secrets such as private keys and seed phrases must never be exposed. Third, no testing may touch a system, account, or network without written authorization from its owner. Words such as must and never mark mandatory norms. Words such as should mark recommendations that teams may adapt with documented reasons.

2Roles, Competence, and Accountability

The project owner approves scope, risk acceptance, and release decisions. The lead developer ensures code follows the approved design and that peer review happens before any merge. The security reviewer checks contract logic, access control, upgrade paths, and external dependencies. This reviewer must not be the only author of the code under review. The operations engineer manages nodes, deployment infrastructure, and monitoring. The privacy or compliance contact confirms how personal and financial data is handled and which legal obligations apply.

Competence is demonstrated through training and supervised practice before a developer receives production keys or deployment rights. Accountability is recorded. Every release, privileged change, and exception has a named approver and a written reason. Developers work only on systems and networks they are authorized to use.

• Assign one accountable owner for each contract, service, and key set.
• Grant mainnet or production deployment rights only after a documented competence review.
• Separate authors, reviewers, and deployers wherever team size allows.
• Recommended: rotate key custodians on a schedule set by the project owner.

3Course-Specific Hazards and Risk Assessment

Blockchain development hazards are mostly digital and financial, but they can also affect people, operations, and public trust. Common on-chain hazards include reentrancy, where an external call re-enters a function before state updates finish. Other examples are integer errors in older compiler versions, missing access checks, unsafe delegate calls, front running, oracle manipulation, unbounded loops that exhaust execution limits, misconfigured upgrade proxies, and predictable randomness. Off-chain hazards include leaked private keys, compromised dependencies, malicious browser extensions, phishing messages, and insecure cloud secrets.

Risk should be assessed before work starts. For each contract or service, list the assets (funds, tokens, user records, admin keys), the actors (users, developers, validators, insiders, attackers), the entry points (public functions, bridges, front ends, package updates), and the consequences of failure. Rate likelihood and impact as low, medium, or high. Any item that could move or lock funds, expose personal data, or halt a live network is treated as high impact by default and requires a second reviewer and documented mitigation. Record the risk owner and the residual risk accepted. Reassess when design, dependencies, or value at risk change materially. A lending protocol that adds a new collateral token, for example, gains a new oracle entry point and must repeat the assessment before listing.

Physical hazards also exist. Validator and mining hardware involves electrical and heat risks, and hardware wallet handling involves loss or theft. These are governed by facility rules and must be handled by qualified technicians, not by developers working alone.

• Reentrancy: update state before external calls, add guards where needed, and prove the behavior with tests.
• Access control: every privileged function names its allowed role and is tested against unauthorized callers.
• Dependencies: pin versions, review changes before upgrading, and record where each library came from.
• Oracles: validate inputs, enforce freshness limits, and document a fallback behavior.
• Upgrades: proxy admin control requires multisignature approval and, where the design supports it, a timelock.

4Preventive Controls and Safe Work Practices

Preventive controls are mandatory for production work. Use a version-controlled repository with protected branches, required peer review, and signed commits where tooling supports them. Maintain unit, integration, and property-based tests with coverage targets set by the project owner. Run static analysis and recognized fuzzing tools before each release. Treat findings as blocking until they are fixed or formally accepted with written reasoning.

Safe work starts with the environment. Develop and test on local chains, public test networks, or isolated sandboxes. Never use real customer funds, real personal data, or production credentials in development. Testing against a copy of mainnet state is allowed only with an approved scope, a fresh state snapshot, and no live signing keys. Testing that involves live nodes, exchanges, wallets, or third-party services requires written permission from the system owner, a defined scope, rules of engagement, and an agreed time window. Bug bounty participation must follow the published program rules.

Deployment follows a documented runbook. Dry-run the deployment script on a test network. Verify constructor arguments, addresses, and the compiled bytecode hash. A second person confirms the transaction payload before signing. After deployment, confirm that ownership and admin roles match the approved design, and publish verified source code where appropriate. Retain the runbook record with the deployment transaction hashes.

• Mandatory: no seed phrases, private keys, or API secrets in source code, logs, tickets, or chat.
• Mandatory: privileged actions require multisignature or equivalent two-person control.
• Mandatory: contracts holding user funds receive an independent security review before mainnet deployment.
• Mandatory: stop a release if tests fail, audit findings remain open, or the deployment checklist is incomplete.
• Recommended: use formal verification or model checking for high-value logic.
• Recommended: document any emergency pause, including who may trigger it and how users will be informed.

5Equipment, Environment, Information, and Protective Safeguards

Key management is the central safeguard. Signing keys should be held in hardware security modules, hardware wallets, or managed key services approved by the organization. Keys must be generated only in approved systems, never on shared or unmanaged computers. Backups should be encrypted or split across separate locations with controlled access. Developer workstations should use full disk encryption, current operating system patches, approved endpoint protection, and separate browser profiles for wallet interactions.

Information safeguards cover privacy and security. Public ledgers are copied across nodes and cannot be erased, so personal data should stay off-chain wherever possible. Store personal information in access-controlled systems, and use hashes or commitments only after a privacy review. Logs must omit secrets and unnecessary personal data. Node and API endpoints need rate limits, authentication where applicable, and monitored access. Wallet and front-end interfaces should show clear transaction details, avoid unlimited token approvals by default, display contract addresses for verification, and be tested to confirm that signing requests are not silently redirected.

Physical controls apply to lab spaces, servers, and hardware. Keep signing devices locked when unattended and store backup media in controlled locations. Electrical installation and maintenance of validator or mining equipment must be performed by qualified personnel under facility rules. Data protection and financial rules that apply to your product are jurisdiction-dependent, so verify them with qualified counsel.

• Mandatory: keys never leave approved custody systems in plain form.
• Mandatory: production and admin accounts use separate identities from everyday email and social accounts.
• Recommended: use a dedicated device for transaction signing.
• Recommended: minimize stored personal data and delete it when the retention basis ends.

6Incident Reporting, Emergency Response, and Escalation

Report suspected incidents immediately. This includes suspected key compromise, unexpected privileged transactions, failed invariant checks, node outages, and vulnerability reports from outside researchers. Do not wait for proof. The first responder notifies the incident lead and the security reviewer, records what is known, and avoids public speculation that could help an attacker. Use the internal communication channel defined in the incident plan, not public forums.

Containment comes first. Pause affected functions only if the design allows and the pause procedure is documented. Revoke compromised credentials and rotate affected keys. Move funds only through pre-approved emergency procedures with multisignature approval. Preserve evidence, including transaction hashes, logs, configuration versions, and timestamps. Do not attempt to exploit a vulnerability to prove a point. Coordinate with legal and communications teams. Where funds or personal data are affected, notify competent authorities and affected users as applicable rules require. Public statements should be factual, reviewed by the incident lead, and should not promise recovery of funds until technical and legal teams confirm it.

Near misses matter. A missed signing check or a misconfigured deployment reveals the same weakness that could later cause loss, so record it and review it. For threats to personal safety, suspected criminal activity, or extortion, contact local emergency services or law enforcement. Developers must not confront suspects or negotiate with attackers.

• Mandatory: report suspected key compromise to the incident lead immediately.
• Mandatory: handle externally reported vulnerabilities under the published responsible disclosure policy.
• Mandatory: complete a post-incident review after containment, with each corrective action assigned to a named owner.

7Records, Training, Monitoring, and Review

Maintain records for requirements, threat models, design decisions, reviews, test results, deployment transactions, key ceremonies, access grants, and incident reports. Retention periods depend on applicable legal and organizational requirements, which vary by jurisdiction and sector, so confirm them with qualified professionals.

Training covers secure coding, threat modeling, key handling, phishing awareness, privacy basics, and the incident procedure. Refresh training after major platform changes or lessons learned from incidents. Monitoring includes alerts for privileged on-chain events, dependency vulnerability notices, node health, and unusual access patterns. Review privileged access at a frequency set by the project owner and confirm that role assignments still match actual responsibilities after staff changes. Review these norms after each major release or incident, comparing outcomes against open findings and remediation times.

• Mandatory: review privileged access at the frequency set by the project owner and remove unused rights.
• Recommended: run tabletop exercises for key compromise and failed upgrades.
• Recommended: track open findings and time to remediation as simple safety metrics.

Implementation checklist

• Confirm scope and written authorization before any testing of live systems.
• Keep all seed phrases, private keys, and API secrets out of code, logs, tickets, and chat.
• Test on a local or public test network before any mainnet action.
• Obtain independent security review for contracts that hold user funds.
• Require two-person approval for privileged transactions and upgrades.
• Verify deployment addresses, bytecode hash, and admin roles after every release.
• Minimize personal data on-chain and document the privacy review.
• Report suspected compromise immediately and preserve evidence.
• Verify applicable laws, standards, and platform rules with qualified professionals.