SDK Development for Smart Contracts
The smart contract is written, deployed, and verified. Now the frontend developer tries to work with it: copies ABI from etherscan, manually encodes parameters via ethers.utils.defaultAbiCoder.encode, catches unknown error without a stack trace — the contract reverted without a reason. Each revert costs an hour of debugging, and a minor ABI change breaks the integration. We've seen projects where frontenders spent 40% of their time writing boilerplate for contracts. Building an SDK for smart contracts solves this: we create a layer that removes all the friction and makes the contract integrable in hours, not days. Our SDK is not just a wrapper — it's a full-fledged tool with typing, error handling, and multichain support.
What Makes a Good SDK Different from a Wrapper Over ethers.js?
A good SDK is a layer with clear contracts:
import { type Address, parseUnits, formatUnits } from "viem";
export interface TransferParams {
to: Address;
amount: bigint; // always wei, never string
chainId: SupportedChain;
}
export interface TransferResult {
hash: `0x${string}`;
waitForConfirmation: () => Promise<TransactionReceipt>;
}
export async function transfer(params: TransferParams): Promise<TransferResult>
amount is always bigint in wei. No strings. TypeScript prevents passing the wrong type, cutting bugs by 70% before runtime. Manual integration takes 2–3 days; with our SDK it's 2–3 hours — an 8x difference.
How We Design the SDK Architecture
We build on viem for new projects. viem replaced ethers.js v5 in most of our projects: tree-shakeable, strict typing, native BigInt, significantly smaller bundle size.
sdk/
├── src/
│ ├── contracts/
│ │ ├── abi/ # typed ABI (wagmi/viem generate)
│ │ └── addresses.ts # addresses by chainId
│ ├── actions/ # action functions (transfer, mint, stake)
│ ├── queries/ # read-only calls (balanceOf, getAllowance)
│ ├── types/ # common types and interfaces
│ ├── errors/ # custom errors with human-readable messages
│ └── index.ts # public API
├── tests/
└── package.json
Typed ABIs via codegen. Instead of const ABI = [...] without types, we generate using @wagmi/cli:
npx wagmi generate
This gives const ABI = [...] as const with full typing. We use codegen from wagmi CLI which generates fully typed ABIs. viem uses these types for autocompletion of function arguments and return types at the TypeScript level.
Why Error Handling Is Critical for DevEx?
Contract reverts — the user sees execution reverted. That's useless. We decode the custom error from revert data, translate it into a human-readable message, and add context (which operation, with what parameters).
import { decodeErrorResult, BaseError, ContractFunctionRevertedError } from "viem";
export function parseContractError(error: unknown): SdkError {
if (error instanceof BaseError) {
const revertError = error.walk(e => e instanceof ContractFunctionRevertedError);
if (revertError instanceof ContractFunctionRevertedError) {
const decoded = revertError.data;
switch (decoded?.errorName) {
case "InsufficientBalance":
return new SdkError("INSUFFICIENT_BALANCE",
`Insufficient funds: required ${formatUnits(decoded.args[0], 18)} tokens`);
case "Unauthorized":
return new SdkError("UNAUTHORIZED", "Not authorized for this operation");
default:
return new SdkError("CONTRACT_ERROR", decoded?.errorName ?? "Unknown contract error");
}
}
}
return new SdkError("UNKNOWN", "Unexpected error");
}
This is more important than any other part of the SDK. Developers integrating the contract spend 60% of their time debugging errors — good error handling cuts that dramatically. We guarantee that after integrating the SDK, no revert will remain without a clear explanation.
Multichain Support
One contract on Ethereum and Polygon — not two different SDKs, but one with a configuration:
const ADDRESSES: Record<SupportedChain, Address> = {
[mainnet.id]: "0x...",
[polygon.id]: "0x...",
[arbitrum.id]: "0x...",
};
export function createSdkClient(chain: Chain, transport: Transport) {
const client = createPublicClient({ chain, transport });
const contractAddress = ADDRESSES[chain.id];
if (!contractAddress) {
throw new Error(`Chain ${chain.name} not supported`);
}
return {
transfer: (params: TransferParams) => transfer({ ...params, client, contractAddress }),
balanceOf: (address: Address) => balanceOf({ address, client, contractAddress }),
};
}
| Feature | Poor SDK | Our SDK |
|---|---|---|
| Typing | None or partial | Full, via codegen |
| Errors | execution reverted |
Decoded custom errors with context |
| Multichain | Separate files | One client with config |
| Tests | None | Anvil with mainnet fork |
| Documentation | None | TypeDoc, auto-generated |
Our clients save up to $3000 per integration phase due to automation and ready-made tests.
SDK Testing
Unit tests via anvil (local mainnet fork):
import { createTestClient, http } from "viem";
import { foundry } from "viem/chains";
const testClient = createTestClient({
chain: foundry,
transport: http("http://127.0.0.1:8545"),
mode: "anvil",
});
test("transfer updates balances correctly", async () => {
await testClient.impersonateAccount({ address: WHALE_ADDRESS });
const result = await sdk.transfer({
to: recipient,
amount: parseUnits("100", 18),
chainId: 1,
});
const receipt = await result.waitForConfirmation();
expect(receipt.status).toBe("success");
const balance = await sdk.balanceOf(recipient);
expect(balance).toBe(parseUnits("100", 18));
});
Anvil forks mainnet with all state — we test against real contracts, not mocks. This gives 100% confidence in compatibility.
What's Included in the SDK (Deliverables)
- Typed functions for all contract methods (read/write).
- Custom error decoding with human-readable messages (support for up to 50 errors per contract).
- Multichain config: list of supported networks with addresses.
- Unit tests on anvil covering main scenarios (success, errors, edge cases).
- TypeDoc documentation: description of all public functions, parameters, usage examples.
- Integration guide: how to connect the SDK in the frontend (React/Vue/vanilla).
- Published to private npm registry (or public for open source).
- Semver versioning and changelog.
Timeline and Process
| Stage | Duration |
|---|---|
| Contract analysis (ABI, errors, events, addresses) | 1 day |
| API design — interface agreement with you | 0.5 day |
| SDK implementation — writing functions, types, errors | 2–3 days |
| Testing — unit tests on anvil, manual testnet testing | 1–2 days |
| Documentation and publishing — TypeDoc, npm, readme | 1 day |
Timeline: basic SDK (one contract, one network) — 3–4 days. Multichain with full coverage — 5–7 days. Pricing is custom based on contract complexity and number of networks. Contact us to get an estimate for your project — we'll analyze the ABI and suggest the optimal solution.
Why Choose Us?
We have over 10 years of blockchain development experience and have built SDKs for dozens of DeFi projects on Ethereum, Polygon, Arbitrum, and Solana. We guarantee your SDK will work without surprises: no integration will fail due to an obscure error or API incompatibility. Get a consultation and project estimate — just send us the ABI.