Stake to Take Protocol

Stake to Take is the stake-backed dispute-protection path for payment methods with a nonzero risk window. It is currently active for Venmo and PayPal. The system locks canonical USDC at a 1:1 ratio against the gross on-chain intent amount, then keeps the settled amount locked through the payment method's dispute window.

This page describes the protocol path. For the buyer flow, see the Stake to Take guide.

Architecture

OrchestratorV3
  -> IntentLifecycleHookV1
       -> WhitelistPolicy                 (trusted takers can bypass stake)
       -> DisputeProtectionPolicy         (admission and dispute lifecycle)
            -> StakeVault                 (USDC custody and lock accounting)
            -> DisputeVerifier            (signed dispute evidence)
            -> DisputeNullifierRegistry   (dispute replay protection)

OrchestratorV3 snapshots the active lifecycle hook onto each intent. The production IntentLifecycleHookV1 combines whitelist admission with stake-backed admission and forwards cancellation and settlement callbacks to the DisputeProtectionPolicy.

StakeVault holds the collateral, while DisputeProtectionPolicy controls locks and dispute outcomes. Stake does not earn protocol yield.

Production addresses

The active deployment is on Base mainnet (chain ID 8453). These addresses were verified at Base block 50,560,704 and match @zkp2p/contracts-v2@0.4.1-rc.9.

Component	Address	Role
USDC	0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913	Stake token and supported protected-intent token
OrchestratorV3	0x014025fDE093f8701d86e9f38e2C3a9b779cb5c7	Intent lifecycle and lifecycle-hook callbacks
IntentLifecycleHookV1	0x5Dd6C675a7406fE8C9f0D93394a36fd6e8c50031	Combines whitelist and stake-backed admission
WhitelistPolicy	0x389Cd9bA91FfFcd83d267B241E975541892759Ce	Deposit- and payment-method-scoped trusted-taker policy
StakeVault	0x47c26258222e2f96424bD2B21bf173f0DA5034C7	USDC custody, delegation, locks, and claimable balances
DisputeProtectionPolicy	0xbF4B769dB70DBEc89b6b2c44988304a7aD2de4Fc	Admission, risk windows, settlement, release, and dispute resolution
DisputeVerifier	0x30d4947f005653637005eed991005119D9eB2f34	Validates signed evidence against the original payment
DisputeNullifierRegistry	0xA845615b5203F7a21321DdF5e3a1ca024D93a443	Prevents reuse of a payment-method-scoped dispute ID

See V3 Deployments for the complete production registry. Integrations should resolve addresses from the contracts package or the SDK instead of copying constants from this page.

Admission logic

The lifecycle hook evaluates the deposit's whitelist first, then the payment-method-specific dispute-protection route.

Condition	Result
Taker is allowed by an enabled whitelist	Admit without a stake lock
Taker is not whitelisted; protection is enabled and the risk window is nonzero	Lock the full intent amount from the effective stake owner
Whitelist is enabled and no stake-backed route is available	Reject the intent
Whitelist is disabled and no stake-backed route is available	Admit without a stake lock

Dispute protection defaults on for methods with a nonzero risk window, with a per-(deposit, paymentMethod) opt-out. Admission also requires canonical Base USDC, unpaused admissions, and enough free stake. Any failure reverts the complete signal transaction.

Current risk windows

Payment method	bytes32 identifier	Window
Venmo	0x90262a3db0edd0be2369c6b28f9e8511ec0bac7136cefbada0880602f87e7268	1,209,600 seconds (14 days)
Cash App	0x10940ee67cfb3c6c064569ec92c0ee934cd7afa18dd2ca2d6a2254fcb009c17d	0 seconds (non-chargebackable)
PayPal	0x3ccc3d4d5e769b1f82dc4988485551dc0cd3c7a3926d7d8a4dde91507199490f	1,209,600 seconds (14 days)

Methods with a zero window do not use stake-backed admission. Risk windows are governance-controlled, so integrations should read getRiskWindow(paymentMethod) on-chain. These values were read at Base block 50,562,572.

Lock lifecycle

Intent transition	Stake transition
Signaled	Lock the full gross intent.amount with no time-based maturity
Cancelled/pruned	Unlock the complete pending lock immediately
Settled	Resize the lock to releaseAmount before fees and set releaseEligibleAt
Matured release	Any account may execute the release after releaseEligibleAt, returning free stake
Upheld dispute	Resolve the lock into an immediately claimable USDC balance for the depositor

The passage of the risk window makes a settled lock eligible for release; it does not release the lock by itself. Until a permissionless release transaction executes, valid dispute evidence can still resolve the lock.

Shared stake

Another account can back a taker after both accounts opt in. Delegation does not transfer ownership or withdrawal rights, and each lock snapshots its stake owner when the intent opens.

Dispute resolution

DisputeVerifier validates signed evidence, and DisputeNullifierRegistry prevents reuse. An upheld dispute resolves the settled lock into a claimable StakeVault balance for the depositor.

SDK integration

Use @zkp2p/sdk for deployment-aware stake, risk-window, protection, and readiness reads. See the SDK client reference for stake writes, keeper releases, indexed state, and readiness states.