Problem
StellarWalletContext stores the Freighter module as walletApi: any and src/components/UnlockModal/UnlockModal.tsx passes it straight to unlockAssets as any. This bypasses TypeScript's type checking for every wallet call, making it easy to accidentally call a non-existent method or pass the wrong argument shape without a compile-time error.
const [walletApi, setWalletApi] = useState<any | null>(null);
Acceptance Criteria
Relevant Files
src/types/freighter.ts — create this file
src/context/StellarWalletContext.tsx — replace any
src/lib/soroban.ts — walletApi: any in method signatures
src/components/UnlockModal/UnlockModal.tsx — prop type for walletApi
Problem
StellarWalletContextstores the Freighter module aswalletApi: anyandsrc/components/UnlockModal/UnlockModal.tsxpasses it straight tounlockAssetsasany. This bypasses TypeScript's type checking for every wallet call, making it easy to accidentally call a non-existent method or pass the wrong argument shape without a compile-time error.Acceptance Criteria
src/types/freighter.tsdefines aFreighterApiinterface mirroring the methods actually used:isConnected(),isAllowed(),requestAccess(),getAddress(),getNetworkDetails(),signTransaction(xdr: string, opts: { networkPassphrase: string }): Promise<{ signedTxXdr: string; error?: string }>StellarWalletContexttypeswalletApiasFreighterApi | null— no moreanyStellarWalletContextValue.walletApiexposed to consumers is typedFreighterApi | nullsrc/lib/soroban.tsall methods receivingwalletApiparameter replaceanywithFreighterApi@stellar/freighter-apiis imported via dynamic import as before, but cast toFreighterApiafter theisConnectedcheck (the import type is compatible)tsconfig.jsonhas"strict": true; no@ts-ignoreoras anyremains in wallet-related filestsc --noEmitproduces zero errors after the changeRelevant Files
src/types/freighter.ts— create this filesrc/context/StellarWalletContext.tsx— replaceanysrc/lib/soroban.ts—walletApi: anyin method signaturessrc/components/UnlockModal/UnlockModal.tsx— prop type forwalletApi