Deposit into a venue

The complete deposit recipe: run the auction, produce the two signatures correctly, settle, and handle every failure mode.

Info

This guide covers EVM venues (txPayload.kind = "eip7702Batch"). For Hyperliquid Core venues (hypercoreAction — HLP, HYPE staking) the flow is shorter: sign coreActions[0].typedData with signTypedData and send that one signature as executeSignature — no authorization, no digest. See Core concepts.

Prerequisites

• An API key.
• The depositing wallet holds the asset (it does not need native gas).
• You can sign an EIP-7702 authorization and a raw 32-byte digest with that wallet (viem ≥ 2.21, or any 7702-capable signer).

1. Run the auction

curl -X POST https://meadow.example.com/v1/quotes \
  -H "api-key: $EDITH_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "userAddress": "0xUser…",
    "chain": 84532,
    "asset": "0xUSDC…",
    "amount": "900000000",
    "riskTier": "balanced",
    "minApyBps": 300
  }'

The winning bid arrives with netApy, the allocation, and the settlement txPayload. Two fields drive everything next: txPayload.authorization and txPayload.executeDigest.

Warning

Show txPayload.calls to the user before signing — it is the exact batch that will run as their account (typically an approve on the asset followed by a vault deposit). Signing blind defeats the design.

2. Produce the two signatures

Signature 1 — the EIP-7702 authorization. Sign the tuple exactly as returned; the nonce is already the correct account nonce for a relayed transaction (no +1):

const auth = await walletClient.signAuthorization({
  contractAddress: quote.txPayload.authorization.address,
  chainId: quote.txPayload.authorization.chainId,
  nonce: quote.txPayload.authorization.nonce,
});

Signature 2 — the plan digest. Sign executeDigest as a raw digest — not personal_sign, no EIP-191 prefix:

const executeSignature = await account.sign({
  hash: quote.txPayload.executeDigest,   // 0x + 64 hex chars
});

The settlement contract recovers this signature against your address; a prefixed signature recovers to the wrong signer and the deposit fails.

3. Settle

curl -X POST https://meadow.example.com/v1/deposits \
  -H "api-key: $EDITH_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "quoteId": "'"$QUOTE_ID"'",
    "authorization": '"$SIGNED_AUTH_JSON"',
    "executeSignature": "'"$EXECUTE_SIGNATURE"'"
  }'

You get an order in relaying with a photonTxId — the settlement is in flight through the relayer.

4. Poll the order

curl https://meadow.example.com/v1/orders/$ORDER_ID -H "api-key: $EDITH_API_KEY"

confirmed carries the executionTxHash; your positions now show the venue shares in the user's address.

Failure modes

Failure	Cause	Recovery
404 RESOURCE_001 on deposit	Quote expired (expiresAt passed)	Re-quote, re-sign both signatures for the new payload.
Deposit rejected with a validation error	Signature malformed, or authorization fields don't match the quote	Sign exactly what txPayload gave you; don't reorder or re-encode calls.
Order → failed	On-chain revert during settlement (e.g. asset balance moved after quoting)	Nothing left the wallet unnecessarily — the batch is atomic. Ensure the balance and re-quote.
Wrong digest signer	executeDigest signed with EIP-191 prefixing	Use raw-digest signing (account.sign({hash})), not signMessage.

Notes

• One quote, one settlement: executeNonce prevents replaying the same signed batch.
• The authorization delegates the account for this settlement pattern; subsequent deposits produce fresh payloads and fresh signatures.
• Deposits and withdrawals share the settlement endpoint — a withdrawal is the same mechanic with an exit plan.