PressKey security
PressKey is designed to keep user signing authority out of the web application. That boundary is only useful if integrations preserve it.Never request a private key
A PressChain application should never ask a user to paste a private key, recovery phrase or exported keystore into a webpage or application backend. The page requests an authorized operation through the provider. Signing remains inside the extension session.Current extension behavior
Current source keeps unlocked signing material in extension memory for a bounded session and removes legacy private-key fields from extension storage. Applications should still treat the signer as capable of locking at any point. Do not assume a successful connection at 9:00 means signing state remains available at 9:30.Explain what the user is authorizing
Before invoking a transaction path, show a human-readable summary of:- action name
- Capsule or target identifier
- destination contract
- economic class
- amount or funded value where applicable
- current PressKey account
- current chain
Re-read permission state
A client-side permission snapshot can become stale. Immediately before authorization, refresh role, bond and relevant relationship state. For example, official evidence attachment can depend on whether the current address is the Capsule author or an active contributor. If that relationship changed after page load, the transaction should not proceed based on cached UI state.Protect against origin confusion
The extension manifest currently limits host access to PressChain domains. Applications should maintain clear domain ownership and TLS hygiene so users can distinguish legitimate PressChain surfaces from lookalike sites. Do not train users to ignore domain warnings or install extensions from unofficial download pages.Avoid secret logging
Application telemetry can record provider method name, duration, error category, account address where appropriate and transaction hash. It should not capture recovery phrases, raw private keys or decrypted signing material. Sanitize generic error logging because wallet libraries sometimes include request payloads.Timeout handling
The injected request path uses a bounded timeout. If a signing request times out, do not automatically send a second transaction. First determine whether a transaction hash exists or whether the user actually approved the first request. Ambiguous network outcomes require reconciliation, not duplication.Backend security boundary
A backend may:- validate canonical metadata
- compute or verify hashes
- resolve action policy
- construct calldata
- simulate a call
- estimate gas
- index resulting events