Swap AssistantThe user-authorized execution path
The browser collects the selected assets, networks, amount and recipient. Next.js server-side quote handling communicates with approved routing providers and normalizes the result. The review surface shows what the user is being asked to authorize. The connected wallet signs ordinary swap transactions; the application backend does not hold the user's private key.
- User inputs -> quote validation -> approved provider route
- Normalized quote -> fee and minimum-received review -> wallet approval
- Submitted transaction -> chain/provider observations -> delivery status
The application-data boundary
Spring Boot and PostgreSQL store wallet-authenticated history, favorites and notification preferences. A wallet sign-in proves account control for these saved features. Admin operations use separate protection. Quoting and public product evaluation must not expose private user records.
Email, Telegram and push use configured delivery services. These channels notify users; a price alert is not authorization to move funds. Duplicate handling, cooldowns and outbox delivery belong in this application layer rather than in the browser's success message.
What changes for cross-chain delivery
A same-chain transaction receipt can establish a particular on-chain result. A cross-chain route needs source and destination progress tracked separately. Destination address compatibility, bridge/provider state and a possible refund are part of the delivery model.
The current approved provider scope includes 0x and LI.FI routes where configured and supported. That is not a guarantee of all network combinations. A quote can become unavailable because of provider policy, liquidity, amount, account limits or network conditions.
Revenue evidence is not browser telemetry
The implementation binds server-originated quote evidence to authenticated history and submitted transactions. Expected, not verified, accrued, received and failed are separate states. Independent reconciliation must support a verified fee result; a browser-reported confirmation alone cannot promote revenue.
A cached quote may be reused by separate transactions. Each transaction needs its own identity and evidence. Conversely, receiving the same transaction twice must not create two fee records. This distinction is useful when evaluating any swap application's accounting claims.
Keep market intelligence isolated
Market Radar has a separate collector boundary so exchange-feed failures do not need to interrupt authentication, contact enquiries or swap history. Its public demo is synthetic. Private Binance research access is not a commercial data license, and commercial live redistribution remains gated.
Visible liquidity can move or disappear. Structural scores describe observed evidence, not a probability of profit or a guaranteed reversal. There is no automatic transition from Radar signal to trade execution.
Review before deployment
The application has tests, validation, rate limits, protected administration and controlled release checks. A customer deployment still needs its own threat review, operator permissions, approved accounts, secret configuration, backup checks and acceptance evidence. Non-custody does not remove software, protocol or legal risk.
Start with the isolated demo and an integration fit review. Agree the exact routes, interfaces, responsibilities and exclusions before selecting a pilot scope.
Questions before a pilot
Does a server mean the application is custodial?
Not by itself. The important distinction is who controls keys and spending authorization. Servers can store preferences, request quotes and reconcile evidence without signing ordinary swaps for users.
Is this an independently audited architecture?
No independent audit or certification is claimed. Automated tests and internal review are evidence of engineering work, not a guarantee against vulnerabilities.