@zkp2p/sdk 0.7.1 → 0.7.2

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
@@ -6,7 +6,7 @@
6
6
 
7
7
  Stable TypeScript SDK for trustless fiat-to-crypto on Base. ZKP2P combines escrowed on-chain settlement, TLS attestations for payment verification, and API/indexer helpers so makers, takers, wallets, and embedded ramps can ship production-grade fiat liquidity flows without building their own contract or indexing stack.
8
8
 
9
- Current version: `0.5.2`
9
+ Current version: `0.7.1`
10
10
 
11
11
  ## Why This SDK
12
12
 
@@ -73,6 +73,7 @@ const client = new Zkp2pClient({
73
73
  - Supported runtime environments: `'production'`, `'preproduction'`, `'staging'`
74
74
  - `runtimeEnv` default: `'production'`
75
75
  - `rpcUrl`: optional RPC URL override (defaults to wallet's chain RPC)
76
+ - `rpcTransport`: optional viem transport override for contract reads
76
77
  - `apiKey`: optional internal curator API key for internal seller verification only
77
78
  - `authorizationToken` / `getAuthorizationToken`: optional bearer auth for indexer flows
78
79
  - `indexerApiKey`: optional `x-api-key` for indexer proxy auth
@@ -272,13 +273,23 @@ Use `referralFees[]` for multi-recipient fee distribution on OrchestratorV2.
272
273
 
273
274
  ## Referral Account API
274
275
 
275
- Authenticated apps can manage Peer referral accounts through the SDK. Configure
276
- `authorizationToken` or `getAuthorizationToken` on `Zkp2pClient`, or pass an
277
- override per call.
276
+ Apps can read referral data publicly by wallet address and can write with either
277
+ a Privy bearer token or an EIP-712 wallet signature. Configure
278
+ `authorizationToken` / `getAuthorizationToken` on `Zkp2pClient` for bearer mode,
279
+ or use the `WithSignature` methods for wallet-only integrations.
278
280
 
279
281
  ```ts
282
+ const publicDashboard = await client.getReferralDashboard({
283
+ address: '0x1111111111111111111111111111111111111111',
284
+ });
285
+
286
+ const lookup = await client.lookupReferralCode('PEER42');
287
+ // { code, referrerWalletAddress, isActive }
288
+
280
289
  const dashboard = await client.getReferralDashboard();
281
- // { code, l1FeeBps, l2FeeBps, l1RefereeCount, ... }
290
+ // { code, redemption, l1FeeBps, l2FeeBps, l1RefereeCount, ... }
291
+
292
+ await client.createReferralCode();
282
293
 
283
294
  await client.redeemReferralCode('PEER42');
284
295
 
@@ -288,10 +299,29 @@ const earnings = await client.getReferralEarnings();
288
299
  // { totalWei, l1Wei, l2Wei, unattributedWei, ... }
289
300
  ```
290
301
 
291
- The dashboard call returns the authenticated user's generated referral code.
292
- `redeemReferralCode()` applies another user's code to the authenticated account;
293
- `updateReferralCode()` customizes the authenticated user's own code. Codes are
294
- normalized to uppercase before being sent to curator.
302
+ For external integrators without Privy, the SDK signs the curator EIP-712
303
+ payload with the configured `walletClient`. Production signatures default to the
304
+ `base_production` audience and a current Unix `issuedAt`; override `audience` for
305
+ non-production curator environments.
306
+
307
+ ```ts
308
+ const { code: myCode } = await client.createReferralCodeWithSignature();
309
+
310
+ await client.redeemReferralCodeWithSignature('PEER42', {
311
+ referrerWalletAddress: lookup.referrerWalletAddress,
312
+ });
313
+
314
+ await client.updateReferralCodeWithSignature('MYCODE', {
315
+ oldCode: myCode,
316
+ });
317
+ ```
318
+
319
+ Public `getReferralDashboard({ address })`, `getReferralEarnings({ address })`,
320
+ and `lookupReferralCode()` do not send auth headers. Bearer-mode dashboard reads
321
+ create or fetch the authenticated user's code. Signature-mode writes send exactly
322
+ the body shape expected by `/v2/referral/code`, `/v2/referral/redeem`, and
323
+ `PATCH /v2/referral/code`; codes are normalized to uppercase before signing and
324
+ submission.
295
325
 
296
326
  ## Prepared Transactions
297
327
 
@@ -41021,5 +41021,5 @@ function enrichPvIntentView(view, chainId, env = "production") {
41021
41021
  }
41022
41022
 
41023
41023
  export { asciiToBytes32, enrichPvDepositView, enrichPvIntentView, ensureBytes32, getContracts, getGatingServiceAddress, getPaymentMethodsCatalog, getRateManagerContracts, parseBigIntLike, parseDepositView, parseIntentView, resolveFiatCurrencyBytes32, resolvePaymentMethodHash, resolvePaymentMethodHashFromCatalog, resolvePaymentMethodNameFromHash };
41024
- //# sourceMappingURL=chunk-NMIFJSZ3.mjs.map
41025
- //# sourceMappingURL=chunk-NMIFJSZ3.mjs.map
41024
+ //# sourceMappingURL=chunk-ZM4ZP5GQ.mjs.map
41025
+ //# sourceMappingURL=chunk-ZM4ZP5GQ.mjs.map