@zkp2p/sdk 0.14.10 → 0.15.0-rc.1

package/README.md

@@ -35,7 +35,7 @@ and chargeback-risk surface. The workspace version lives in `package.json`.
 
 ## Optional Venmo Gmail connection
 
-For partner cash-out integrations, prefer stable `@zkp2p/cash@0.7.2` and its
+For partner cash-out integrations, prefer stable `@zkp2p/cash@0.7.3` and its
 [prepare/open/status flow](https://docs.peer.xyz/developer/peer-cash/guide#optional-venmo-receipt-linking).
 It selects the matching environment and keeps linking separate from cash-out.
 The direct SDK helpers below require `@zkp2p/sdk@0.14.2` or later.
@@ -81,7 +81,7 @@ apart. Deploy the hosted page before using the SDK helper. See the
 
 ### X Money receipt linking
 
-`getXMoneyConnectUrl` and `openXMoneyConnect` use the same mailbox flow at
+SDK `0.14.10` adds `getXMoneyConnectUrl` and `openXMoneyConnect`, using the same mailbox flow at
 `/connect/xmoney`. Pass the registered `payeeDetails` hash and `payeeUsername`.
 The normalized X username must hash to that identity. Both stay in the URL
 fragment. X Money email notifications must be enabled and the inbox must contain
@@ -332,14 +332,17 @@ console.log(result.hash);
 console.log(result.depositDetails);
 ```
 
-By default, `createDeposit()` enables the trusted group bypass on Venmo and
-PayPal methods. After the deposit mines, it sends one
-`WhitelistPolicy.configureDeposit` per Venmo/PayPal method with the Peer Pay
+The trusted-group whitelist is opt-in via `enableTrustedGroupBypass: true`
+(defaults to false). By default, `createDeposit()` sends only the deposit and
+returns empty `result.accessPolicyTxHashes` without waiting for a receipt.
+When opted in, after the deposit mines, it sends one `configureDeposit` on the
+current deposit whitelist (see [Deposit Access Policy](#deposit-access-policy))
+per Venmo/PayPal method with the Peer Pay
 merchant group and returns the confirmed hashes as
 `result.accessPolicyTxHashes` (empty for other methods). Members of that group
-skip dispute-protection staking; other takers still stake, and until the policy
-mines, merchants stake too. Pass `enableTrustedGroupBypass: false` to skip it.
-If the deposit was sent but the policy was not confirmed, it throws a
+skip dispute-protection staking. On OrchestratorV4 an enabled whitelist makes
+the deposit private: only Peer Pay merchant-group members can signal.
+When opted in, if the deposit was sent but the policy was not confirmed, it throws a
 `ContractError` whose `details.hash` is the deposit transaction. `prepareCreateDeposit()` does not add
 the policy; custom senders call `client.accessPolicy.prepareConfigurePeerPayMerchantDeposit()`
 once the deposit ID is known.
@@ -408,6 +411,7 @@ await client.setTakerAuthorization({ taker, authorized: true }); // signed by th
 await client.selectStakeOwner({ stakeOwner: safeAddress }); // signed by the taker
 await client.clearStakeOwner(); // taker returns to self-stake
 
+// Explicit vaults are verified through the live stack independently by each client.
 const onchain = await client.getStakeVaultState({
   staker: takerAddress,
   taker: takerAddress,
@@ -416,7 +420,7 @@ const onchain = await client.getStakeVaultState({
 const indexed = await client.indexer.getStakingState({
   chainId: 8453,
   environment: 'base',
-  vaultAddress: client.getStakeVaultContract().address,
+  vaultAddress: (await client.getActiveStakeVaultContract()).address,
   disputeProtectionPolicyAddress: client.getDisputeProtectionPolicyContract().address,
   taker: takerAddress,
   // Always supply the effective owner from the fresh on-chain read.
@@ -427,7 +431,7 @@ const indexed = await client.indexer.getStakingState({
 
 const locks = await client.indexer.getStakeLocks({
   chainId: 8453,
-  vaultAddress: client.getStakeVaultContract().address,
+  vaultAddress: (await client.getActiveStakeVaultContract()).address,
   stakeOwner: onchain.stakeOwner,
   status: 'ACTIVE',
   limit: 50,
@@ -435,7 +439,7 @@ const locks = await client.indexer.getStakeLocks({
 
 const activity = await client.indexer.getStakeActivity({
   chainId: 8453,
-  vaultAddress: client.getStakeVaultContract().address,
+  vaultAddress: (await client.getActiveStakeVaultContract()).address,
   merchant: takerAddress,
   orderDirection: 'desc', // Newest first; defaults to asc for chronological ingestion.
   limit: 50,
@@ -447,7 +451,7 @@ const activity = await client.indexer.getStakeActivity({
 
 const totals = await client.indexer.getStakeTotals({
   chainId: 8453,
-  vaultAddress: client.getStakeVaultContract().address,
+  vaultAddress: (await client.getActiveStakeVaultContract()).address,
 });
 // totals.totalStaked and totals.totalLocked are decimal strings in token base units.
 // totals.stakerCount counts owners whose stake balance is greater than zero.
@@ -469,9 +473,34 @@ withdraws the complete claimable balance. Chargebackable capacity is exactly
 the effective owner's free stake (1:1); never sum a taker's self-stake with a
 sponsor's stake.
 
-The vault's controller is the `DisputeProtectionPolicy` contract. It owns
+`getDisputeProtectionStacks()` discovers `{ current, draining }` from
+OrchestratorV4 and OrchestratorV3 respectively, following O4 settlementPolicy to its vault, and the August/O3 hook to its policy and
+vault. Discovery is cached for 30 seconds; failures are retried. The active vault
+is the V4 vault when V4 is deployed, otherwise the V3 vault. Known previous vaults
+remain selectable with `stakeVaultAddress` for reads and withdrawals; on staging these
+are the August and Bypass vaults. The Bypass policy also stays known, so O3 intents
+holding records there still resolve. O4 discovery verifies
+`policy.isOrchestratorAuthorized(O4)` and `vault.isController(policy)`. V2 uses
+the StakeVaultV2 ABI; August vaults retain StakeVault and its single controller. A missing
+current stack fails closed. `@zkp2p/contracts-v2@0.4.4-rc.6` exports the Base staging
+V4 stack. Base exports zero placeholders, which never enable V4.
+
+Explicit vault addresses passed to stake reads, writes and allowance setup are verified
+against bundled deployments or the trusted V4 live stack, cached per client for 30 seconds.
+Use `await client.resolveStakeVaultContract({ stakeVaultAddress })` when contract
+coordinates are needed before a direct read. `getStakeVaultContract` remains a
+synchronous lookup of already-known vaults.
+
+`getAdmissionsPaused`, `getRiskWindow`, `isDisputeProtectionEnabled` and
+`setDisputeProtectionEnabled` target only the August V1 policy behind
+OrchestratorV3. An explicit V2 address or a missing V3 stack fails closed.
+V2 has no on-chain risk-window or pause getter; `StakeVaultState.admissionsPaused`
+is omitted for V2 vaults. Use the attestor rail policy for quote-time defaults.
+Releases look up each intent's original policy;
+a batch spanning policies throws `ValidationError`.
+
+The August vault's controller is the `DisputeProtectionPolicy` contract. It owns
 per-payment-method risk windows (`getRiskWindow(paymentMethodHash)`),
-per-deposit chargeback enablement (`isDisputeProtectionEnabled(escrow, depositId)`),
 and the global `admissionsPaused()` switch. The selected `@zkp2p/contracts-v2`
 bundle resolves the StakeVault, DisputeProtectionPolicy, and OrchestratorV3 for
 both the production and staging bundles; a bundle without them fails closed
@@ -482,9 +511,11 @@ deployments).
 Keeper writes are direct and prepareable:
 
 ```ts
+// August V1 policy behind OrchestratorV3 only.
 const enableProtection = await client.setDisputeProtectionEnabled.prepare({
   escrow: depositEscrow,
   depositId: 42n,
+  paymentMethod: paymentMethodHash,
   enabled: true,
 });
 
@@ -518,18 +549,10 @@ same finalized cutoff for every cursor in one ingestion pass. Follow
 `endCursor` with its final block/log position; `endCursor` is null only for an
 empty page.
 
-Before enabling dispute-protected admission, prove that the live Base contracts
-still match the deployment manifest embedded in the exact SDK artifact:
+The existing readiness API verifies the V3 manifest only. V4 readiness is pending
+the new deployment manifest.
 
-```ts
-const readiness = await client.getDisputeProtectionReadiness();
-
-if (readiness.state !== 'active_successor_verified' || !readiness.readyForDisputeProtection) {
-  throw new Error(`Dispute protection is unavailable: ${readiness.state}`);
-}
-```
-
-The reader pins every code and state read to one `asOfBlock`, including exact
+The manifest reader pins every code and state read to one `asOfBlock`, including exact
 governance owners, authorization sets, attestation witnesses, and signature
 thresholds. It distinguishes
 `recognized_predecessor`, `passive_successor`, `active_successor_verified`,
@@ -541,6 +564,15 @@ verified while `orchestratorPaused`, `allowMultipleIntents`, and
 traffic. Unknown hooks, misconfigured successors, runtime-code changes,
 dependency mismatches, and RPC failures return `mismatch` and fail closed.
 
+An activated successor may keep its recognized predecessor policy as a
+`DisputeNullifierRegistry` writer while that predecessor's intents drain. The
+active state therefore requires every active writer and accepts the
+manifest's `RecognizedPredecessorPolicy` as the only additional writer, after
+verifying its packaged runtime hash at `asOfBlock`. Any other writer, or a
+missing active writer, is a `mismatch`. The passive state keeps its exact
+writer set, and an orchestrator the manifest does not list is always a
+`mismatch`.
+
 Dispute evidence callers should read the current attestation trust roots before
 requesting evidence and again before submitting it:
 
@@ -549,6 +581,7 @@ const attestationConfig = await readDisputeAttestationConfig({
   publicClient,
   chainId: 8453,
   environment: 'production',
+  // policyAddress: found.policyAddress, // optional known historical policy
 });
 
 if (attestationConfig.requiredSignatures !== 1) {
@@ -652,6 +685,125 @@ await client.releaseFundsToPayer({
 
 Use `referralFees[]` for multi-recipient fee distribution on OrchestratorV2 and V3.
 
+### Signal data and deferred payouts
+
+New intents target OrchestratorV4 when its deployment is present, otherwise
+OrchestratorV3. Caller `data?: Hex` and `postIntentHook` are O3-only;
+O4 rejects non-empty caller data or a nonzero hook. Its `/v3/sign` request omits
+`postIntentHook` and sends `data: '0x'`. O4 fulfilment contains only `paymentProof`, `intentHash`, and
+`verificationData`; non-empty `postIntentHookData` is rejected. Existing intents resolve their original orchestrator through indexer
+routing and on-chain reads; they keep fulfilling, cancelling and releasing there.
+O4 reads use the package O4 ABI directly, including account-intent enumeration;
+ProtocolViewerV2 only decodes O3 and older intents. O4 intents have no `postIntentHook`.
+Use `getCurrentOrchestratorContract()` for new intents and
+`resolveIntentOrchestrator(intentHash)` for existing ones.
+
+Every O4 `signalIntent` struct ends with `bytes data`. The SDK always sends `0x`,
+so the gating signature covers the plain V3 packed message. The contracts can
+check a conditions hash carried in `data`, but nothing sets one yet. A stale O4
+ABI fails before signing or encoding.
+
+Attestation data retains the 448-byte UPV3 payload. For non-manual O4
+fulfilment, extension word 0 is the required `disputeWindow` in seconds (0 means
+pay now, maximum 180 days), so O4 payloads are 480 bytes. O3's 448-byte payload
+is unchanged. The SDK forwards the attestor's bytes unchanged.
+
+V2 may require stake or hold a payout when the rail default window is positive,
+the deposit token is the vault's stake token (USDC), the deposit+method whitelist
+is off, and the taker is not a registered relayer bypassing collateral.
+Registered relayers bypass by default unless the deposit has opted out.
+Registration means O4's current `relayerRegistry()`: the policy has no registry of
+its own and reads O4's at settlement, so compute `takerIsRelayer` from O4's
+registry at the same block as the other quote inputs. The SDK re-exports `DISPUTE_WINDOW_POLICY`,
+`getDefaultDisputeWindow` and `DisputeWindowPaymentMethod` from the attestation
+client. `mayRequireDisputeProtection({ paymentMethod, depositToken, stakeToken,
+whitelistEnabled, takerIsRelayer, relayerBypassOptedOut })` implements this
+quote-time rule. Venmo and PayPal default to 14 days; other supported rails default to zero. The attestor can sign a
+shorter window, including zero for balance-funded Venmo buyer-TEE evidence or
+when its window config switch is disabled.
+
+Manual release, a signed zero window, or a non-stake deposit token pays now
+without a policy record or event. With a positive window and USDC, an enabled
+deposit+method whitelist with an allowed taker pays directly without a record
+or policy event. Registered relayers also pay directly unless the deposit opts out.
+Otherwise sufficient free stake produces `STAKE`, or the net payout is
+held as `DEFERRED_PAYOUT` until `releaseEligibleAt = settlement time + window`.
+Whitelist membership, relayer registration (O4's registry, read by the policy at
+settlement) and the deposit opt-out are read live at fulfilment. O4 never executes post-intent hooks.
+
+`setDepositOptOutForRelayerBypass({ escrow, depositId, optOut })` and its
+`.prepare()` form configure a V2 deposit after creation. Only the depositor may
+write, not a delegate (`NotDepositor`). Read the setting with
+`isDepositOptedOutForRelayerBypass({ escrow, depositId })`; false is the default.
+Both methods resolve and verify the current O4 `settlementPolicy()` and fail
+closed without O4. This is deposit-wide, independent of payment method; indexer
+projections use `relayerBypassOptedOut`. It does not disable protection generally
+or change the whitelist. No deposit-creation setting is added.
+
+`CollateralSource` is `NONE, STAKE, DEFERRED_PAYOUT`. A missing (`NONE`)
+record returns `NOT_PROTECTED`; callers treat that as paid only after successful
+fulfilment. Whitelisted orders also read as `NONE`. Deferred records are `SETTLED` from
+creation. Classify a fulfil receipt using the policy's
+`DisputeProtectionIntentSettled` log first (it has no `isManualRelease`), then
+O4's `IntentPayoutDeferred` (deferred, including after policy rotation), then
+`IntentFulfilled.isManualRelease` for direct/unprotected payouts.
+`parsePayoutSettlementFromLogs(logs, intentHash, resolvedAddresses)` applies this
+order and rejects logs from other addresses or intents; call it only for a successful receipt.
+
+```ts
+const payout = await client.getPayoutStatus(intentHash);
+const payouts = await client.getPayoutStatuses(intentHashes);
+const prepared = await client.claimFor.prepare({ intentHash });
+```
+
+`PayoutState` contains `NOT_PROTECTED`, `PAID`, `HELD`,
+`CLAIMABLE`, `CLAIMED`, `RELEASED_TO_STAKE`, and `DISPUTED`. Results include
+`collateralSource`, `recipient`, `taker`, `lockedAmount`, `claimedAmount`,
+`releaseEligibleAt`, and `claimable`. Reads pin the intent and dependent free-stake
+batches to one block. A released payout can be claimed only up to the remaining
+per-intent amount and the recipient's free stake. The taker or recipient may call
+`claimFor`; funds always go to the recipient.
+
+`claimFor({ intentHash, disputeProtectionPolicyAddress?, txOverrides? })` resolves
+the policy holding the intent. An optional `disputeProtectionPolicyAddress` must
+match that resolved policy; a mismatch, missing intent, invalid hash, or
+non-cascade policy throws `ValidationError`. Both sending and `.prepare()` target
+the resolved cascade policy. Omitting the address performs the same lookup.
+Payout reads and `claimFor` first ask the client's indexer for the intent's
+settlement policy (`IntentSettlementPolicyState`, recorded from O4's
+`IntentSettlementPolicySnapshotted`; O4 deletes its own snapshot at settlement).
+They read the record from that policy and use that policy's `stakeVault()`, so a
+policy rotated out before a package update still resolves. Only rows for the
+client's chain and packaged OrchestratorV4 count, and the indexed policy must
+return a valid V2 record for the intent. When the indexer has no row (for example
+just after fulfilment), fails, or does not serve the entity yet, or the indexed
+policy has no record, the SDK falls back to the packaged `disputeProtectionPolicyV2`
+and the live `settlementPolicy()` read from the packaged OrchestratorV4 address.
+Zero addresses are skipped and candidates are deduplicated; both are classified
+as V2. If the indexed policy's read fails and the fallback finds no record, the
+read throws instead of returning `NOT_PROTECTED`. Payout reads pin every record,
+each holding policy's `stakeVault()`, and its recipient's `freeStake` to one
+block. No record returns `NOT_PROTECTED`; records on two fallback policies fail
+closed. Claims target the policy holding the record, which pays only the
+record's recipient. The standalone `getPayoutStatuses(publicClient, chainId, env,
+hashes, { indexer? })` and `findDisputeProtectionIntent({ ..., indexer? })` use an
+indexer only when one is passed. The strict current-stack checks for stake writes
+are unchanged.
+
+`client.parseDeferredPayoutFromLogs(logs, intentHash)` accepts only events from
+its packaged cascade policy or V4 orchestrator. O4's `IntentPayoutDeferred` also identifies deferrals after policy rotation. The standalone parser additionally
+requires `{ disputeProtectionPolicyV2Address, orchestratorV4Address }`.
+
+`findDisputeProtectionIntent` returns a discriminated `generation`:
+`PolicyGeneration.V2` has a validated ten-field record (no `riskWindow` or `releaseAmount`) and four statuses (`NONE`, `SETTLED`, `RELEASED`, `DISPUTED`, ordinals 0–3);
+`PolicyGeneration.V1` retains the eight-field record and six statuses.
+`readDisputeAttestationConfig({ policyAddress })` follows either known generation.
+
+V4 readiness and indexer APIs that list deferred payouts await the new manifest
+and indexer schema; payout reads already use the indexer's settlement-policy rows
+when it serves them. The retained readiness reader verifies V3 only and is not V4 readiness
+proof. This SDK version is `0.15.0-rc.1`, a prerelease on the npm `dev` tag.
+
 ## Extend an Intent Lifetime
 
 The standalone `IntentGuardian` lets any payer buy more time for a live intent.
@@ -699,15 +851,28 @@ The guardian charges the target deposit's token and pays the deposit owner.
 Extension payments are prepaid and non-refundable. `extendIntentLifetime.prepare()`
 returns calldata without sending it.
 
-## Historical Deposit Access Policy
+## Deposit Access Policy
 
 `client.accessPolicy` exposes environment-aware reads and unwind-only prepared
 transactions for policies written before Groups were retired. Gate use on
 `client.accessPolicy.isSupported`; unsupported deployments fail closed.
 
+It targets the current orchestrator's deposit whitelist. That is
+`WhitelistPolicyV4` when OrchestratorV4 is deployed (Base staging), otherwise
+`WhitelistPolicy` (Base production). `getContracts().addresses.whitelistPolicy`
+and `client.whitelistPolicyAddress` resolve the same contract, which equals
+`whitelistPolicy()` on OrchestratorV4 and DisputeProtectionPolicyV2. If
+OrchestratorV4 is deployed without `WhitelistPolicyV4`, both are undefined and
+access-policy calls fail closed. They never fall back to O3's whitelist.
+Every deposit starts with the whitelist off on `WhitelistPolicyV4`. Entries on
+O3's `WhitelistPolicy` don't carry over and only gate OrchestratorV3 signals.
+
 Existing policies remain enforced on-chain until disabled or their deposits
-close. The only new policy is the trusted group bypass that `createDeposit()`
-adds to Venmo and PayPal deposits by default. Depositors can use
+close. The only new policy is the opt-in trusted-group whitelist that
+`createDeposit()` adds to Venmo and PayPal deposits only with
+`enableTrustedGroupBypass: true` (defaults to false). On OrchestratorV4 an enabled
+whitelist makes the deposit private: only Peer Pay merchant-group members can
+signal, and members skip dispute-protection staking. Depositors can use
 `prepareDisable`, `prepareRemoveAllowedGroups`, and
 `prepareRemoveWhitelistedAddresses` to fail open and remove historical entries.
 
@@ -1213,3 +1378,21 @@ pnpm docs
 Use `platform: 'upi'` with `callerAddress` and `sessionMaterial: { sessionCookie, userAgent }` in the private extension runtime. Omit `payeeId` and `offchainId` when creating the bundle: the attestor derives the receiving VPA from Amazon's current QR. `getAmazonPaySellerIdentity(bundle)` reads that returned identity; storage registers that exact VPA and checks its maker hash against the sealed bundle. Never expose session material to the requesting page.
 
 Amazon capture requires extension 0.6.8 or later. Staging SAR uses the trusted staging attestor and staging provider templates; production requires its Amazon template and backend rollout. This source change does not publish either package or extension.
+
+### Historical dispute policy lookup
+
+`findDisputeProtectionIntent({ publicClient, chainId, environment, intentHash,
+blockNumber?, indexer? })` first reads the indexer's settlement policy for the
+intent when an `indexer` is passed (see deferred payouts). Otherwise, or when that
+policy holds no record, it queries the packaged V2 and O4 live settlement policies, then
+canonical, manifest, and recognized predecessor policies, deduplicated at one
+block. Both V2 candidates use the cascade ABI. Multiple V2 records for one hash
+throw; otherwise the first intent whose status is not `None` wins. It returns `null` only when every intent read parses as
+`None`; an unreadable intent throws. The result contains the policy
+`generation` (`v2` or `v1`), `policyAddress`, and the `intent` parsed with
+that generation's struct and status enum.
+All calls share a block. Use the returned policy for dispute submission and
+`readDisputeAttestationConfig({ publicClient, chainId, environment, policyAddress })`.
+For a known non-manifest policy, the latter follows `disputeVerifier()` and
+`attestationVerifier()` before reading witnesses and threshold at one block.
+Unknown policies throw. Omitting `policyAddress` preserves manifest behavior.

package/dist/build-metadata.json

@@ -2,12 +2,12 @@
   "schemaVersion": 2,
   "source": {
     "repository": "zkp2p/zkp2p-clients",
-    "commitSha": "561ca15adeac3e97e582647c818656e69289020d",
+    "commitSha": "503d0587c1f674b6402f741b143a2881f0b55ca5",
     "kind": "github",
     "distributable": true
   },
-  "sdkPackageVersion": "0.14.10",
-  "contractsPackageVersion": "0.4.4-rc.2",
+  "sdkPackageVersion": "0.15.0-rc.1",
+  "contractsPackageVersion": "0.4.4-rc.6",
   "indexerSchemaPackageVersion": "0.22.0",
   "activeDisputeStack": {
     "base": {

package/dist/chunk-FCGUBJAP.mjs

@@ -0,0 +1,12 @@
+var __defProp = Object.defineProperty;
+var __export = (target, all) => {
+  for (var name in all)
+    __defProp(target, name, { get: all[name], enumerable: true });
+};
+
+// <define:__ZKP2P_SDK_BUILD_METADATA__>
+var define_ZKP2P_SDK_BUILD_METADATA_default = { schemaVersion: 2, source: { repository: "zkp2p/zkp2p-clients", commitSha: "503d0587c1f674b6402f741b143a2881f0b55ca5", kind: "github", distributable: true }, sdkPackageVersion: "0.15.0-rc.1", contractsPackageVersion: "0.4.4-rc.6", indexerSchemaPackageVersion: "0.22.0", activeDisputeStack: { base: { version: 2, selectionHash: "ba40c2954b408d0c658881a8d28e5bfcc9bade5cc3d953fd17eae1eca69d841c" }, baseStaging: { version: 2, selectionHash: "6c49c1ce51eec594a22385c4efcab08aa9926b6b63a725e14a0027ec5d2f4fc9" } } };
+
+export { __export, define_ZKP2P_SDK_BUILD_METADATA_default };
+//# sourceMappingURL=chunk-FCGUBJAP.mjs.map
+//# sourceMappingURL=chunk-FCGUBJAP.mjs.map

package/dist/chunk-FCGUBJAP.mjs.map

@@ -0,0 +1 @@
+{"version":3,"sources":["%3Cdefine:__ZKP2P_SDK_BUILD_METADATA__%3E"],"names":[],"mappings":";;;;;;;AAAA,IAAA,uCAAA,GAAA,EAAC,aAAA,EAAgB,CAAA,EAAE,MAAA,EAAS,EAAC,YAAa,qBAAA,EAAsB,SAAA,EAAY,0CAAA,EAA2C,IAAA,EAAO,UAAS,aAAA,EAAgB,IAAA,EAAI,EAAE,iBAAA,EAAoB,eAAc,uBAAA,EAA0B,YAAA,EAAa,2BAAA,EAA8B,QAAA,EAAS,oBAAqB,EAAC,IAAA,EAAO,EAAC,OAAA,EAAU,GAAE,aAAA,EAAgB,kEAAA,EAAkE,EAAE,WAAA,EAAc,EAAC,OAAA,EAAU,CAAA,EAAE,aAAA,EAAgB,kEAAA,IAAmE","file":"chunk-FCGUBJAP.mjs","sourcesContent":["{\"schemaVersion\":2,\"source\":{\"repository\":\"zkp2p/zkp2p-clients\",\"commitSha\":\"503d0587c1f674b6402f741b143a2881f0b55ca5\",\"kind\":\"github\",\"distributable\":true},\"sdkPackageVersion\":\"0.15.0-rc.1\",\"contractsPackageVersion\":\"0.4.4-rc.6\",\"indexerSchemaPackageVersion\":\"0.22.0\",\"activeDisputeStack\":{\"base\":{\"version\":2,\"selectionHash\":\"ba40c2954b408d0c658881a8d28e5bfcc9bade5cc3d953fd17eae1eca69d841c\"},\"baseStaging\":{\"version\":2,\"selectionHash\":\"6c49c1ce51eec594a22385c4efcab08aa9926b6b63a725e14a0027ec5d2f4fc9\"}}}"]}