feat(ts-sdk): waitlist deposit builders - #267
Merged
Merged
Conversation
Canary environments fund accounts with a real USDC deposit on the source
chain instead of the mint faucet. Add the two pure encoders the flow needs,
matching the existing build-only style (no wallet, no keys):
- buildApprove(token, spender, amount) — the ERC-20 approval, step 1
- buildWaitlistDeposit({waitlist, token, amount, from, ...}) — the waitlist
deposit(...) call, step 2; callContract defaults to the CLOB so the credit
lands as trading balance, reserveBalance to 10000, permit to 0x
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
poszu
approved these changes
Aug 6, 2026
abresas
added a commit
that referenced
this pull request
Aug 6, 2026
Adds the waitlist deposit builders (buildApprove, buildWaitlistDeposit) from #267. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
poszu
added a commit
that referenced
this pull request
Aug 10, 2026
`0.2.0` shipped from main while this was open (`fa7fbac`, carrying the waitlist deposit builders from #267), so the version this branch had claimed is now published and cannot be reused — a publish from here would 403. Rebased onto the release and bumped past it. Minor rather than patch because this is breaking, which pre-1.0 is what a minor bump says: `Order.amendRejected` is gone (the refusal moved to `OrderEvent.amendRejection`), and `pod_orders` is gone from `Channel`. Anyone on `0.2.0` reading either needs to move.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Two pure tx-request builders in
/writefor the canary waitlist deposit flow (real USDC on the source chain instead of the mint faucet):buildApprove(token, spender, amount)— the ERC-20 approval, step 1buildWaitlistDeposit({waitlist, token, amount, from, to?, callContract?, reserveBalance?, permit?})— the waitlistdeposit(...)call, step 2Both return
{to, data, value}for the consumer's wallet to sign and send on the source chain, matching the existing encode-only style (no wallet, no keys, no transport). Defaults:to = from,callContract= the CLOB (credit lands as trading balance),reserveBalance = 10000,permit = 0x.Relayer tooling for the same contract is a follow-up: #268 (
protocol/scripts/apply-deposit.sh).Why
The trading app's canary environment replaces the Mint button with a Deposit flow (approve + deposit through the waitlist contract on Arbitrum One); per the repo split, everything that encodes protocol calls belongs here. Frontend PR: podnetwork/frontend#14 — it needs these released to npm and the
@pod-network/trade-sdkversion bumped.Testing
npm run buildclean; encoding verified against the deployed canary waitlist: replaying a pending deposit's decoded values reproduces its storeddepositHashesentry exactly.🤖 Generated with Claude Code