Bron wallet integration

BronAdapter is the only integration here that authenticates with OAuth2 against an API rather than talking to something in the browser. The registry classifies its transport as an enterprise API. It is also the only adapter in this set whose constructor requires configuration, and the only one that expects your application to own part of the auth flow rather than handling all of it internally.

What the registry declares

Transport	Enterprise API, OAuth2
Adapter package	@partylayer/adapter-bron
SDK version	>=0.1.0
Networks	devnet, testnet, mainnet
CIP-0103	Not declared

Install

npm install @partylayer/react @partylayer/adapter-bron

Construct the adapter

import { BronAdapter } from '@partylayer/adapter-bron';

// requiresConfig: true in the registry entry. Both blocks are mandatory.
const bron = new BronAdapter({
  auth: {
    authorizationUrl: process.env.NEXT_PUBLIC_BRON_AUTH_URL!,
    tokenUrl: process.env.NEXT_PUBLIC_BRON_TOKEN_URL!,
    clientId: process.env.NEXT_PUBLIC_BRON_CLIENT_ID!,
    redirectUri: `${window.location.origin}/callback`,
    usePKCE: true, // recommended for a browser client
  },
  api: { baseUrl: process.env.NEXT_PUBLIC_BRON_API_URL! },
});

Register it

Pass the adapter to PartyLayerKit. Everything else, the button and the modal, is the same for every wallet.

import { PartyLayerKit, ConnectButton } from '@partylayer/react';

export default function App() {
  return (
    <PartyLayerKit network="devnet" adapters={[bron]}>
      <ConnectButton />
    </PartyLayerKit>
  );
}

Connection flow

The adapter holds an auth client and an API client. It opens the authorization URL in a popup, and access tokens are kept in memory by default rather than written to storage. There is no URL-inferred or NODE_ENV-inferred mock: a test that wants one constructs it explicitly.

What the transport means for you

Nothing about this adapter runs in the user's browser extension or a wallet popup you do not control, which means the failure modes are the ones you already know from OAuth rather than wallet ones: popup blockers, redirect URI mismatches, and token lifetime. It also means the wallet is only available to users your OAuth client already recognises, so it belongs behind a different entry point in most apps than the self-custody wallets.

What this adapter supports

Capability	Call	Through this adapter
Sign message	useSignMessage()	Yes
Sign transaction	useSignTransaction()	Yes
Submit transaction	useSubmitTransaction()	Not available
Report transaction status	submit result	Not available
Switch network	client.switchNetwork()	Not available
Multi-party	multi-party flows	Not available

Not available, and why

submitTransaction: The registry entry declares submitTransaction: false, and BronAdapter implements no submit path. What the Bron service itself offers is a question for Bron, not something this repository has established.
transaction status: The registry entry declares transactionStatus: false.

Things that will catch you out

Your application handles the OAuth callback, not the adapterThe adapter does not implement the redirect handler. It says so directly: an unimplemented callback path raises "OAuth callback not implemented in adapter, handle in app". You must serve the route named by redirectUri, read the authorization code from the query string, and complete the exchange yourself. This is the step most likely to be missed on first integration.

Use PKCE in the browserBronAuthConfig accepts an optional clientSecret for server-side flows. Do not put one in a browser bundle. Set usePKCE: true instead, which is what the config documents as the browser recommendation.

It will not appear in a picker without configBecause the constructor requires config, the shared adapter builder in this repository returns null for Bron when none is supplied, and the wallet is simply absent from the list. If it is missing from your picker, check your configuration before looking at the registry.

Troubleshooting

Every symptom below is a real rejection path in @partylayer/adapter-bron, quoted from the adapter rather than reconstructed.

Symptom	Cause	What to do
"OAuth callback not implemented in adapter, handle in app"	The adapter deliberately stops at the point where your application must take over the redirect.	Implement the route at redirectUri. Read the code parameter, complete the token exchange, and hand the result back to your session layer.
"Failed to open auth popup"	The browser blocked the popup, usually because the call did not originate from a user gesture.	Trigger connect directly from a click handler. Do not start it from an effect, a timer, or after an await that breaks the gesture chain.
"No authorization code in callback"	The redirect landed on your callback route without a code parameter, typically a redirect URI that does not match the one registered with the authorization server.	Check that redirectUri matches the registered value exactly, including scheme, host, port and trailing path.
"OAuth flow requires browser environment"	connect ran with no window available.	Call it from the client. This adapter cannot complete an interactive OAuth flow during server rendering.
"Transaction signing denied"	The signing request was refused upstream.	Surface it as a rejection rather than a retry loop, and check that the access token still covers the scopes the request needs.

Quick Start builds a working app around this adapter.
Wallets and adapters covers registration, discovery and custom adapters.
CIP-0103 provider is the standard behind the transports above.
Bron homepage for anything about the wallet itself. This page describes the PartyLayer adapter, not the wallet's own SDK.

Other wallets

Console Wallet · 5N Loop · Cantor8 · Nightly · WalletConnect