feat: enable on-ramp on Starknet.#504
Conversation
- Removed Starknet-specific checks from various components and hooks, simplifying the handling of on-ramp conditions. - Replaced the deprecated `isValidEvmAddressCaseInsensitive` function with a new `validateWalletAddress` function that supports both EVM and Starknet address formats. - Updated the `RecipientDetailsForm` and `TransactionForm` components to utilize the new validation logic, enhancing code clarity and maintainability. - Removed unused Starknet-related props and conditions across components to improve overall code efficiency.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughRemoves Starknet-specific on-ramp gating across MainPageContent, TransactionForm, and useSwapButton; adds network-aware wallet address validation and wires it into RecipientDetailsForm. TransactionForm now derives connected wallet address via useWalletAddress. ChangesStarknet On-ramp Enablement
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
app/pages/TransactionForm.tsx (1)
39-39: ⚡ Quick winUnused import:
useWalletAddressis not referenced.The import is never used in this file. Either remove it or use it to derive
connectedWalletAddress(see comment on line 1111).♻️ Remove unused import
-import { useWalletAddress } from "../hooks/useWalletAddress";🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/pages/TransactionForm.tsx` at line 39, The import useWalletAddress is unused; either remove the import statement or use the hook inside the TransactionForm component to derive connectedWalletAddress. If you choose to use it, call useWalletAddress() (e.g., const connectedWalletAddress = useWalletAddress()) inside the TransactionForm function and replace any existing hardcoded or placeholder connectedWalletAddress references with that value; otherwise delete the unused import line to eliminate the dead import. Ensure you update any downstream code in TransactionForm that expects connectedWalletAddress to use the hook-derived value.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@app/pages/TransactionForm.tsx`:
- Line 1111: activeWallet?.address is being passed into the
connectedWalletAddress prop but activeWallet has no Starknet-specific branch, so
embedded Starknet wallets get an EVM address; call the existing hook
useWalletAddress near the top of the component (after the existing hooks around
line ~91) to obtain walletAddress (network-aware) and replace
connectedWalletAddress={activeWallet?.address ?? undefined} with
connectedWalletAddress={walletAddress ?? undefined}; ensure useWalletAddress is
imported/used and remove reliance on activeWallet for the recipient address so
Starknet users receive their correct embedded Starknet wallet address.
---
Nitpick comments:
In `@app/pages/TransactionForm.tsx`:
- Line 39: The import useWalletAddress is unused; either remove the import
statement or use the hook inside the TransactionForm component to derive
connectedWalletAddress. If you choose to use it, call useWalletAddress() (e.g.,
const connectedWalletAddress = useWalletAddress()) inside the TransactionForm
function and replace any existing hardcoded or placeholder
connectedWalletAddress references with that value; otherwise delete the unused
import line to eliminate the dead import. Ensure you update any downstream code
in TransactionForm that expects connectedWalletAddress to use the hook-derived
value.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a18524c2-899f-4523-9abe-d9efaf63104c
📒 Files selected for processing (1)
app/pages/TransactionForm.tsx
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@app/pages/TransactionForm.tsx`:
- Around line 583-593: The effect only clears EVM-shaped addresses when
switching to Starknet, causing stale Starknet recipients to persist when
switching back to EVM; update the useEffect that reads
getValues("walletAddress") and uses selectedNetwork.chain.name so it validates
the current wallet address against the newly selected network and clears it if
invalid. Concretely, replace the current condition (which only checks
selectedNetwork.chain.name === "Starknet" &&
isValidEvmAddressCaseInsensitive(w)) with a network-aware validity check: if
selectedNetwork.chain.name is "Starknet" ensure the address is a valid Starknet
address (use the existing Starknet validator, e.g., isValidStarknetAddress),
otherwise ensure the address is a valid EVM address
(isValidEvmAddressCaseInsensitive); if the address is invalid for the selected
network call setValue("walletAddress", "", { shouldDirty: true }). Ensure you
reference the same useEffect, getValues, setValue and selectedNetwork.chain.name
symbols when making the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 1d626bce-8e7d-41cd-bc75-0f134ddafa81
📒 Files selected for processing (3)
app/hooks/useWalletAddress.tsapp/pages/TransactionForm.tsxapp/pages/TransactionPreview.tsx
✅ Files skipped from review due to trivial changes (1)
- app/pages/TransactionPreview.tsx
Summary
useWalletAddress()inTransactionFormfor on-ramp "My wallet" / recipient address so the payout target is the Starknet embedded wallet on Starknet (not the EVM smart wallet).validateWalletAddressinapp/lib/validation.tsfor network-aware on-ramp recipient validation (EVM unchanged via existingisValidEvmAddressCaseInsensitive; Starknet via newisValidStarknetAddress).RecipientDetailsFormtovalidateWalletAddressso short/full Starknet addresses validate correctly (fixes false "Invalid wallet address format" from EVM-only checks).Description
Off-ramp on Starknet is already supported on Noblocks (gateway order via
/api/starknet/create-order). This PR enables on-ramp on Starknet so users can fund their Starknet wallet the same way as on other networks: fiat pay-in through the existing v2 sender on-ramp path (createV2SenderPaymentOrder), not the Starknet gateway off-ramp API.Frontend changes
MainPageContent: Remove early return that skipped buy-side rate fetching on Starknet; remove guard that prevented advancing to preview whenswapMode === "onramp"on Starknet.TransactionForm: Remove Starknet on-ramp lock UI (banner, disabled token dropdown,aria-describedby); passuseWalletAddress()asconnectedWalletAddressfor the recipient form.useSwapButton: RemoveisStarknetOnrampprop and related "Coming soon" / disabled submit behavior.RecipientDetailsForm: Validate on-ramp wallet addresses withvalidateWalletAddress(value, networkName)instead of EVM-only validation.validation.ts: AddisValidStarknetAddressandvalidateWalletAddress.isValidEvmAddressCaseInsensitiveis unchanged and still used for EVM networks and to reject 42-char EVM addresses on Starknet.Unchanged
/api/starknet/create-order).createV2SenderPaymentOrder) — same as EVM; aggregator must expose Starknet tokens and buy rates in the target environment.?side=(initialSwapModeForHomeForm).Breaking changes: None for API or public contracts.
Alternatives considered: Hand-rolling Starknet validation only in
RecipientDetailsForm(rejected in favor of sharedvalidation.ts); loosening the EVM regex to accept Starknet lengths (rejected — would break EVM-only callers).Assumption: Aggregator supports Starknet as a crypto destination for v2 on-ramp (tokens,
side=buyrates, provider settlement to recipient address).References
Testing
Manual (staging/local with aggregator Starknet on-ramp configured)
0x…form) → no "Invalid wallet address format".txHashis available.Checklist
mainBy submitting a PR, I agree to Paycrest's Contributor Code of Conduct and Contribution Guide.
Summary by CodeRabbit
Bug Fixes
Improvements
Other