How Brïdge works — design in two lines
Brïdge exposes a minimal API to websites: request addresses, request a signature, and query public keys. The extension or native host forwards signed requests to the Trezor via USB/WebHID/WebUSB. Crucially, Brïdge never transmits private keys to the host; it only relays unsigned payloads to the device and returns signatures after the user confirms on‑device. This design preserves on‑device authority while enabling modern web integrations.
User flow — connect, approve, sign
The typical user flow is intentionally simple:
- Open the DApp and click connect — the DApp will call Brïdge's connect function.
- Brïdge prompts the user to allow the origin; the user approves in the browser UI.
- The Trezor is contacted and asks the user to allow the host; after approving, the DApp can request addresses or signing operations.
- For each transaction, the device shows the payload; the user inspects and physically approves or rejects it.
Security model & recommendations
Brïdge is not a security boundary — the Trezor device and firmware are. Brïdge reduces attack surface by enforcing origin scoping and minimizing persistent privileges. Recommendations for users and integrators:
- Only install Brïdge from official sources and verify release signatures where available.
- Grant permissions intentionally — treat each origin like a separate application and revoke when not needed.
- Always inspect the device screen: amounts, recipient addresses, and contract data should be verified on‑device.
- Keep Trezor firmware updated via the official Suite; firmware fixes are the primary security patches.
Developer integration guide
Developers will find Brïdge straightforward. The API surface is small: connect()
, getAddresses()
, signTransaction()
, and signMessage()
. Provide clear UI cues and context when requesting signatures — users decide based on the information shown on the device.
/* Example pseudocode */
const bridge = await Brïdge.connect();
const address = await bridge.getAddresses({ coin: 'ETH', account: 0 });
const signature = await bridge.signTransaction({ to, value, data });
// send signature to network
Key developer notes:
- Serialize transactions according to the target chain's spec (EIP‑155, Bitcoin PSBT, etc.).
- Present human‑readable intent prior to calling for signatures and avoid bundling unrelated approvals into one request.
- Test across browsers and platforms — WebUSB, WebHID, and native connectors behave differently.
Privacy considerations
Brïdge aims to be privacy-preserving. It doesn't ship telemetry, store user keys, or track usage. Sites will learn when a user connects, but origin scoping prevents cross‑site leakage via Brïdge. Developers should still avoid leaking unnecessary information and should minimize account enumeration requests.
Frequently asked questions
- Can Brïdge sign without my device?
- No. All signing requires the physical Trezor device and on‑device confirmation.
- Is Brïdge open source?
- Yes — source and release artifacts are available for audit. Check the official repo linked in the docs.
- What if I see a request I don't understand?
- Reject it. Investigate the DApp and inspect the payload. Contact support or consult developer docs if uncertain.
Troubleshooting & tips
- If Brïdge can't detect your device: try a different USB cable, enable WebUSB/WebHID permissions, or use the native Suite integration.
- If a DApp fails after connecting: revoke origin permissions and reconnect afresh to reset the session state.
- For repeated failures, check firmware and Brïdge version compatibility and consult the changelog for breaking changes.