socketfi.readContract(). Unlike requestTransaction(), reads run as simulations: no transaction is submitted, no user signature is required, and nothing on-chain changes. This guide shows you how to use readContract() effectively, how to cache results, how to refresh data after a transaction, and how to handle errors.
readContract() vs requestTransaction()
Use this table to decide which method to call:
If in doubt: reads are free and instant; transactions require a user signature and network fees.
Basic read example
readContract() returns unknown — cast the result to a typed interface that matches your contract’s ABI.
Multiple read examples
Token balance
src/services/token.ts
Token metadata
src/services/token.ts
User staking position
src/services/staking.ts
Protocol vault state
src/services/vault.ts
NFT ownership
src/services/nft.ts
Governance proposal
src/services/governance.ts
Caching strategies
React Query integration
React Query is the recommended caching layer for production web apps. It handles loading state, error state, background refetching, and cache invalidation automatically.src/main.tsx
src/components/BalanceDisplay.tsx
Loading multiple data points in parallel
Combine multiple reads into a single dashboard query usingPromise.all to avoid sequential waterfall requests:
src/hooks/useDashboard.ts
Refreshing data after transactions
Prefer event-driven refreshes over polling. After a transaction succeeds, invalidate the relevant query keys so React Query immediately re-fetches the affected data.src/components/StakeButton.tsx
Error handling
Reads can fail — the contract may not exist, the method may be wrong, the arguments may be invalid, or the simulation may time out. Always wrap reads intry/catch.
Common read errors
Service layer pattern
Keep your components clean by moving allreadContract() calls into a services/ layer. Components call the service; the service calls the SDK.