Skip to content

feat: add outbound USDT0 bridging - #158

Draft
ben-kaufman wants to merge 11 commits into
feat/usdt-arbitrumfrom
feat/usdt0-outbound
Draft

ben-kaufman wants to merge 11 commits into
feat/usdt-arbitrumfrom
feat/usdt0-outbound

Conversation

@ben-kaufman

@ben-kaufman ben-kaufman commented Sep 24, 2026 •

Copy link
Copy Markdown
Collaborator

Description

Adds outbound USDT0 transfers from the Arbitrum wallet to Ethereum, Polygon, Plasma and Stable. Users review the destination amount and maximum total USDT fee, including bridge costs, without needing ETH.

  • Uses USDT0's OFT contracts and transaction helper to fund the cross-network transfer in USDT.
  • Validates the route, helper liquidity and approved fee limits before submission. Helper approval is limited to the payment and revoked within the same operation.
  • Tracks source execution separately from destination delivery. A successful Arbitrum transaction enters the bridging state; confirmation requires LayerZero evidence matching the source transaction, message GUID and route.
  • Looks up delivery through the protected chain service, with backoff for retryable problems and no further polling after delivery or a permanent failure.
  • Preserves bridge amounts, fees and message identifiers in activity and restored history. Delivery problems remain visible and never trigger an automatic paid retry.

Based on #157. This PR adds outbound bridging APIs; native release sends remain Arbitrum-only until routes are enabled and validated. Inbound deposit addresses are provided separately by #159.

QA Notes

  • Run cargo test --locked --lib modules::usdt, cargo fmt --check and cargo clippy --locked --lib --tests.
  • Coverage includes bridge quotes, approval limits, source settlement, delivery-message matching, polling and history recovery. The opt-in Arbitrum fork test exercises deployed helper contracts, USDT fee collection and atomic rollback.
  • Fork fixtures do not establish live bridge pricing or destination delivery. Validate destination receipt, actual fees and blocked-delivery handling before enabling each route.
  • The deployed helper requires native liquidity and has documented audit limitations; see the module README for the pinned deployment and operating assumptions.
  • Release packaging targets unpublished v0.6.0. Before remote package consumption, build the selected merged source, record the final SwiftPM checksum in a release-preparation commit, and tag/publish that exact iOS archive and matching Android package. Use matching local artifacts for branch testing; later stack layers must use a new version if an earlier layer has already been released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant