Skip to main content

PressKey provider

PressKey exposes the browser-facing authorization surface for PressChain-native applications. Current extension source injects a provider at window.presschain and identifies it with isPressKey: true. Applications should prefer this explicit provider instead of relying on a generic wallet selector when the action is specifically a PressChain protocol action.

Detect PressKey

The provider also exposes network identity for PressChain V3 testnet:
Do not treat these convenience properties as a replacement for an active eth_chainId check before a write.

Request interface

The provider follows an EIP-style request pattern:
Current injection code bridges a page request into the extension, assigns a request identifier and resolves the corresponding response. The request path has a bounded timeout, so application code must be prepared for a rejection even when the extension is installed.

Request accounts only when needed

A public Capsule page should remain useful without asking for identity immediately. Request connection when the user starts an action that needs authorization.
This keeps read-only browsing separate from signing intent.

window.ethereum compatibility

Current PressKey source can assign itself to window.ethereum when another provider has not already taken that namespace. This improves compatibility with EVM libraries, but PressChain applications should still prefer window.presschain for identity-sensitive flows. A page with several wallet extensions can otherwise end up authorizing through a provider the user did not expect.

Use with ethers

For contract reads, a normal JSON-RPC provider is often simplest. For user-authorized browser activity, wrap the injected provider according to the EVM library version you use. Conceptually:
Before relying on an exact transaction method in production, validate it against the currently released PressKey extension. The transport is EIP-style, while PressChain-specific capabilities can evolve with extension releases.

Action preparation pattern

Keep transaction preparation outside the provider wrapper:
This makes the provider responsible for authorization, not business semantics.

Do not request secrets

A site should never ask for a PressKey private key or recovery phrase. The injected provider exists precisely so the signing boundary remains inside the extension. If an integration guide tells a PressKey user to paste a private key into a website, that integration is violating the intended security model.