Skip to main content

PressKey identity

PressKey is the browser-native identity and signing surface for PressChain. It is designed so an application can request an account, sign or submit authorized actions and respond to session changes without receiving the user private key. Current extension implementation is Manifest V3 and exposes a provider at window.presschain.
If no other EIP-style provider is installed, PressKey also assigns itself to window.ethereum. PressChain applications should prefer the explicit window.presschain handle so there is no ambiguity about which signer the application intends to use.

Request model

The injected provider exposes:
Internally, requests are bridged from the page to the extension with a request ID and a 30-second timeout. Responses resolve or reject the matching promise. Your application should treat requests as asynchronous user interactions. The extension may be locked, the user may deny an action, or the request may time out.
Before shipping code that relies on a specific PressKey request method, verify it against the current extension release. The provider transport is EIP-style, while PressChain-specific capabilities can evolve with the extension.

Live provider events

PressKey emits live session, lock and network events and provides EIP-style aliases where useful.
A session change can result in accountsChanged. A network change can result in chainChanged. Lock state is available through lockChanged. Do not cache an account forever after the first connection. The signer state is live application state.

Non-custodial application boundary

A website should never ask the user to paste a PressKey private key or recovery phrase. The application prepares the intent and requests authorization through the provider. This boundary applies to publishing, evidence, role activation, voting and other user actions. A backend can validate metadata or estimate a transaction, but it should not become the user signer.

Session behavior

Current extension source keeps unlocked signing material in memory for a bounded session and clears legacy private key fields from extension storage. Applications should still assume a session can lock at any point. That means a multi-step publish experience should separate preparation from authorization:
  1. validate content and metadata
  2. create or upload durable artifacts
  3. compute hashes
  4. build transaction calldata
  5. re-check account and chain
  6. request user authorization
  7. track the transaction to inclusion
  8. index and display the resulting Capsule state
If PressKey locks between steps 4 and 6, the app can ask the user to unlock rather than rebuilding the whole article.

Identity is more than an address

A wallet address is the cryptographic actor, but PressChain role and outlet state add protocol context. A good application resolves those records before showing privileged actions. For example, a button labeled “Attach official evidence” should not appear merely because an account is connected. Canonical evidence attachment is constrained by the Capsule relationship and contract authorization. Community or dispute evidence follows a different path. PressKey proves who is authorizing. Protocol state determines what that identity is allowed to do.