What we ship

A typed SDK for interacting with EVM-compatible protocols. Built for developers integrating lending, governance, or liquidity contracts into applications, scripts, and automated systems.

The SDK abstracts away the mechanical overhead of EVM interaction — ABI management, multicall batching, provider configuration, and error normalization — without hiding what's happening underneath. You can drop down to raw contract calls at any point. Nothing is locked behind a black box.

Multicall3 batching is applied automatically when you read multiple values in a single SDK call. What would otherwise be forty sequential RPC requests becomes one. The performance difference is material in any latency-sensitive context: dashboards, liquidation bots, arbitrage scripts, real-time monitoring.

TypeScript types are generated at build time from the contract ABIs. There is no manual type maintenance. When a contract is updated and new types are generated, TypeScript surfaces any integration incompatibilities before you run a single line of code. The compiler does the diff for you.

The SDK is provider-agnostic by design. Pass a viem public client, an ethers.js v6 provider, or any object that satisfies the minimal read interface. We do not take a position on which provider library you use. The SDK adapts to your stack, not the other way around.

A modular lending protocol for EVM chains. Deploy isolated lending pools with configurable collateral factors, interest rate models, and liquidation parameters — without inheriting the architectural decisions of protocols designed for a different era.

CoreLend is not a fork. The architecture separates pool state, interest accrual, oracle resolution, and liquidation into independent contracts with narrow interfaces between them. Each component can be upgraded or replaced without redeploying the system. An oracle migration does not require a pool migration. A rate model update does not require touching position state.

Pool isolation is a first-class design principle. Each asset pair operates in its own pool with its own parameters. A bad debt event in one pool cannot propagate to others. Risk is bounded by construction, not by operational procedure.

The interest rate models are pluggable. The linear model suits stable or low-utilization pools. The kinked model replicates the utilization kink behavior common in established lending protocols, providing a higher-slope region above the kink to discourage over-utilization. Custom rate models can be deployed and registered without modifying the core contracts.

Flash loans are supported natively via EIP-3156. The receiver interface is standard. Any protocol that implements ERC-3156 can execute flash loans against CoreLend pools without custom integration work.

A minimal DAO governance toolkit. On-chain proposals, token-weighted voting, timelock execution, and a treasury module — all in under 800 lines of Solidity. Built for teams that need governance to function as infrastructure, not as a political process.

Govern is designed for teams that need governance without adopting a monolithic framework. Import only the modules you need. The voting contract is standalone. The treasury is standalone. Wire them together or deploy them independently. There is no hidden coupling between components.

Voting uses a snapshot-at-proposal model. Voting power is recorded at the block the proposal is created, not the block each vote is cast. This eliminates the flash loan voting attack vector that snapshot-at-vote systems are vulnerable to, without requiring token locking or a separate voting escrow contract.

The timelock implementation is interface-compatible with OpenZeppelin's TimelockController. Any frontend or tooling built for OZ governance works with Govern's timelock out of the box. We do not introduce incompatible extensions without a corresponding migration path.

The treasury module accepts ETH and ERC-20 assets. Withdrawals require a passed and executed proposal. The module is intentionally minimal — it is not a DeFi strategy manager. It holds funds and executes transfers only when governance approves. Complexity can be layered on top; the base module stays simple.