Security model
PressChain security is not limited to smart-contract correctness. A production system spans user signing, RPC infrastructure, contract permissions, APIs, indexers, economic policy and operational controls. A weakness in any one layer can make an otherwise correct protocol difficult or unsafe to use.Keep user keys out of servers
The most important application rule is simple: do not move a user private key into a backend because server-side signing feels convenient. PressKey exists so user-authorized actions can remain non-custodial. A backend can prepare transaction intent, validate metadata and simulate execution without becoming the user signer. Delegated automation must use an explicit protocol delegation mechanism. A private key stored in an environment variable is not a delegation model.Authority before convenience
Client checks improve UX but do not replace authoritative enforcement. Role, bond, contributor, outlet and economic constraints must be checked by the appropriate contract or trusted service when state changes. A disabled button is not a security boundary.Replay and duplicate protection
Economic and publishing workflows must be safe to retry. Use deterministic identifiers, nonces, transaction hashes and idempotent processing so a network timeout does not create duplicate logical actions. This is especially important for bounty funding, settlement, feed publication and automated jobs.Economic safety controls
V3 policy requires controls including:- treasury floors
- automatic bounty budget caps
- maximum active bounty limits
- role and bond revalidation at settlement
- duplicate prevention
- emergency pause capability
- immutable enforcement and settlement audit events
API boundaries
Public or broadly accessible APIs should expose only the authority they need. The current Rust API is read-only by design. Adding write operations later should require explicit authentication, authorization and scope design rather than reusing read credentials. Keep service accounts separate from human PressKey identity.Projection integrity
Indexers can be attacked indirectly by malformed logs, reorganization assumptions, oversized metadata and data that violates application expectations even when contract execution is valid. Validate decoded records, bound external fetches and preserve raw chain coordinates. If enrichment fails, the canonical projection should remain recoverable.External content safety
Evidence and metadata can reference external URIs. Treat retrieved content as untrusted.- enforce MIME allowlists where rendering occurs
- avoid executing active HTML from evidence sources
- limit fetch size and duration
- protect internal network ranges from server-side request forgery
- verify content hashes before showing verified status
- isolate document previews
Secrets management
Operational secrets include infrastructure credentials, API signing secrets, deployment credentials and any privileged administration keys. Store them in an appropriate secret manager, rotate them and restrict them to the smallest service scope. Do not place secrets in public docs, client bundles, Git history or diagnostic screenshots.Administrative actions
Protocol administration should be rare, explicit and auditable. Separate administration identities from ordinary publishing identities where possible. If emergency pause or ownership transfer exists, document the operational ceremony internally: who can initiate it, who reviews it, how the action is verified and how recovery proceeds.Dependency and supply-chain security
Pin important dependencies, review upgrade diffs and run automated vulnerability scanning. For browser extensions and Explorer deployments, build provenance matters because users are trusting shipped JavaScript with access to valuable workflows.Incident response
A useful incident plan defines how to:- classify the affected layer
- preserve logs and chain evidence
- stop unsafe writes without destroying read access where possible
- rotate compromised credentials
- reconcile pending transactions
- restore projections from authoritative data
- communicate which records or time ranges were affected