feat: custom ERC20 destination and source tokens - #23
Open
soos3d wants to merge 13 commits into
Open
Conversation
- CustomErc20Token / CustomSourceToken / DestinationToken types - DestinationConfig.token accepts any ERC20 (EVM chains only) - DepositClientConfig.sourceTokens for custom deposit sources - resolveDestinationTokenSpec discriminated seam + isCustomToken guard - Onramp gated off for custom destination tokens (no RampNow route) - Sweeper throws a clear not-yet-implemented error for custom delivery (replaced by the buy->transfer pipeline in the next commit)
- src/sweep/custom-delivery.ts: buy the deposits' aggregate USD value into the custom token, wait for settlement + balance arrival, then transfer the UA's FULL token balance to the destination (self-healing: stranded balances from failed runs are recovered on the next delivery) - buy amount ladder (100/97/94/90%) until fee-calibrated post-spike - src/sweep/erc20-rpc.ts: dependency-free balanceOf reads over public RPC - fromSmallestUnit added to erc20.ts - Sweeper routes custom destination specs through the new flow (readTokenBalance + customDelivery tuning seams injectable for tests)
- src/sweep/custom-source.ts: CustomSourceWatcher polls balanceOf for each configured sourceTokens entry on the intermediary UA; at/above minAmount it sells the full balance via createSellTransaction (preferTokenType USD); proceeds are a primary asset the existing pipeline detects and delivers - in-flight guard holds each token until the sell settles (no double-sell) - src/sweep/ua-transaction.ts: shared sign+send with sweep error semantics (extracted from custom-delivery) - DepositClient wires the watcher into startWatching/stopWatching/destroy
- DepositConfig.sourceTokens pass-through to DepositClient - react entry re-exports DestinationToken / CustomErc20Token / CustomSourceToken types (onramp gating and widget symbol display for custom destination tokens landed with the type-union commit)
Live spike results (LINK on Base, 2026-07-08): - buy quotes carry the standard feeQuotes shape -> reuse extractFeeBreakdown - buy fees are charged ON TOP of amountInUSD from primary assets, and the post-buy transfer pays its own fee (~$0.14 on Base) from primary assets too -> executed buy amount is now baseUSD − buyFee − transferReserve (reserve = max(quoted gas fee, $0.05)); quote-size ladder kept only as a fallback for obtaining fee data - unknown tokens fail with code -32686 'Token metadata not found' -> typed immediately (no pointless retries); the source watcher marks such tokens unsellable for the session - buy result tokenChanges.incr matches balanceOf exactly (full-balance transfer approach confirmed)
- DestinationPanel: custom ERC20 editor (address/decimals/symbol, prefilled LINK on Base) applying via setDestination; custom-aware chain/token chips, onramp-unavailable notice, and dev-note snippet - providers.tsx: sourceTokens configured with LINK on Base for source-flow testing - BuyDemo/DepositDemo render via destinationTokenSymbol (custom token objects are not directly renderable) - SDK reference: spike-verified fee overhead + -32686 error documented - demo README: 'Testing custom ERC20 tokens' walkthrough
Live test found the two flows fighting: with LINK on Base as BOTH the custom destination and a sourceTokens entry, the delivery bought ~$1.1 of LINK and the source watcher immediately sold the balance back into USDC (~$0.78 kept in the UA, sell fee lost), leaving the transfer only ~$0.08. - assertDestinationNotSourceToken: ConfigurationError on same chain+address overlap, enforced at construction and setDestination (case-insensitive) - demo: sourceTokens switched to AERO on Base so both directions are testable side by side; README + SDK reference document the limitation
The spike page served its purpose: it live-verified UA buy/sell/transfer semantics for custom ERC20 tokens (documented in docs/CUSTOM-ERC20-PLAN.md). The real flows are now covered by the SDK implementation and the demo's custom-token wiring.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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
1 participant
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.
Summary
Any ERC20 can now be used on either side of a deposit, riding the Universal Account's buy/sell primitives:
createBuyTransaction, then the full intermediary balance is transferred to the destination (src/sweep/custom-delivery.ts). Full-balance transfer makes delivery self-healing: anything stranded by a failed run is picked up by the next delivery.CustomSourceWatcherpollsbalanceOffor each configured token, sells arrivals into USDC (preferTokenType: USD), and the proceeds are detected and swept by the existing pipeline (src/sweep/custom-source.ts).Key design points (established by a live spike with LINK on Base and verified end to end):
expectTokens/createUniversalTransactionis primary-tokens-only, so custom delivery must be buy → transfer (two UA transactions).depositUSD − buyFee − transferReserve, where the reserve covers the follow-up transfer's fee — without it the bought tokens strand in the intermediary.-32686("Token metadata not found") — surfaced as a typed error, no retries; the source watcher marks such tokens unsellable.ConfigurationErrorrejects a token configured as both destination and source on the same chain (found live: the watcher sold the freshly bought destination balance).sourceTokensthrough.Known v1 limitations (documented in
sdk/docs/CUSTOM-ERC20-PLAN.md)minAmountis the dust gate instead ofminValueUSD.Related
chore/remove-arbitrumis stacked on this branch (Arbitrum removal touched this branch's test files); it will be PR'd after this merges.Test plan
npm run test), including new suites:custom-token-config,custom-delivery,custom-sourcenpm run typecheckandnpm run buildpass[CustomSource]sell logs, USDC proceeds, normal sweep (unit-tested; live run pending)