@pollar/react 0.11.5 → 0.12.0-rc.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -3,7 +3,17 @@
3
3
  React bindings for [Pollar](https://pollar.xyz) — drop-in authentication UI, transaction modals, and hooks for
4
4
  Stellar and Solana applications.
5
5
 
6
- > **0.11.5** (requires `@pollar/core@^0.11.5`).
6
+ > **0.12.0** (requires `@pollar/core@^0.12.0`). `<RampWidget>` runs on the v3 ramps API: routes, quotes leg by
7
+ > leg, the fields a quote asks for, the order's progress and its pending action; it signs a leg with the connected
8
+ > Stellar or Solana wallet only when the leg was built for it. **Wallets the user holds**: the wallet button lets the
9
+ > user pick co-signed or self-custody when the app leaves it to them, `<RecoveryModal>` manages passkeys, email,
10
+ > devices and the recovery phrase (`recoveryLocked`, `openRecoveryModal()`), and `<CustodyMigrationModal>` moves a
11
+ > custodial wallet to Turnkey after login. `<SendModal>` offers to create a Stellar account that does not exist.
12
+ > Branding yields to the host stylesheet, with `--pollar-font-family` and `--pollar-font-family-mono`;
13
+ > `WalletButtonTemplateProps` takes `theme`, `accentColor` and `styleOverrides`. **Breaking**; see
14
+ > [UPGRADE.md](../../UPGRADE.md).
15
+ >
16
+ > Earlier: **0.11.5** (requires `@pollar/core@^0.11.5`).
7
17
  > **Turnkey co-signed wallets**: `<CosignModal>` opens for a request the device did not settle and enables
8
18
  > Approve only after it verifies against Turnkey; `useCosign()` exposes the pending requests.
9
19
  > `<ConfirmModal>` shows every signature first under `confirmation: 'prompt'`. The ramp widget links the
@@ -139,7 +149,7 @@ Context provider that initialises the Pollar client and makes it available to ch
139
149
  <PollarProvider
140
150
  client={{
141
151
  apiKey: 'your-api-key',
142
- baseUrl: 'https://sdk.api.pollar.xyz', // optional, origin only — the SDK appends /v2
152
+ baseUrl: 'https://sdk.api.pollar.xyz', // optional, origin only — the SDK appends /v3
143
153
  stellarNetwork: 'testnet', // optional, default: 'testnet'
144
154
  storage, // optional, RN apps inject this
145
155
  keyManager, // optional, autodetects on web
@@ -258,7 +268,7 @@ const {
258
268
  // KYC: without corridorId/providerId it walks the app's own KYC steps
259
269
  openKycModal, // (options?: { corridorId?, providerId?, country?, level?, onApproved? }) => void
260
270
 
261
- // Ramp (SEP-24 on/off-ramps, wired through core)
271
+ // Ramp (fiat on/off-ramps on the v3 ramps API, wired through core)
262
272
  openRampModal, // () => void
263
273
 
264
274
  // App config / styles served by the Pollar API
@@ -369,7 +379,7 @@ already wired inside `<PollarProvider>` — and most are exported in case you wa
369
379
  | `<DistributionRulesModal>` | Manage the wallet's distribution rules |
370
380
  | `<SessionsModal>` | Lists every active refresh-token family for the current user with device metadata, marks the local session, per-row revoke, and a "Sign out everywhere" button |
371
381
  | `<KycModal>` | Identity verification: hosted (iframe or redirect) flow per option, corridor-scoped when a ramp route asks for it (`corridorId`), or started on one option (`providerId`). Shows review, expiry and retry states; without either id it walks the app's own KYC steps |
372
- | `<RampWidget>` | Buy/sell crypto via SEP-24 - direction tabs, route comparison, payment instructions (wired to `client.createOnRamp` / `client.createOffRamp`). A route whose corridor has a pending requirement step is listed locked, and the widget opens that step's modal (below) and re-quotes once it is done |
382
+ | `<RampWidget>` | Buy/sell crypto: direction tabs, country, fiat and asset pickers, route comparison leg by leg, the fields a route asks for, then the order's progress with its pending action (payment QR or bank details, Authorize, co-sign approval, verification link) and what to do when a leg fails. Orders waiting on the user can be resumed. |
373
383
  | `<RequirementFormModal>` | One `FORM` requirement step of a ramp route: renders the form the backend names (`formId`), prefilled with the user's previous answers, and stores the answers encrypted. `<RampWidget>` opens it itself; exported for consumers who build their own route list from `requirementsRequired` |
374
384
  | `<RegistryCheckModal>` | One `REGISTRY_CHECK` step (SEGIP through Stereum, `optionId`): the verified identity prefilled and read-only except the surname split and the CI complement; a check the registry did not confirm shows the review state with nothing to retry |
375
385
  | `<ProviderRegistrationModal>` | One `PROVIDER_REGISTRATION` step (`corridorId`): lists what the ramp provider receives and registers the user with it on consent; an already registered user is passed through |