# DeFi SDK: one router contract and a set of adapters over many protocols > The Zerion DeFi SDK is a set of smart contracts whose centrepiece is a Router that executes ERC20 trades and knows how to ask each supported lending and exchange protocol what a user has deposited and owes. What makes it interesting to read is the split between the two kinds of adapter and the deployment flow that goes through a wallet. **zeriontech/defi-sdk** — DeFi SDK Makes Money Lego Work - Repository: https://github.com/zeriontech/defi-sdk - Website: https://docs.zerion.io/defi-sdk/ - Stars: 845 · Forks: 265 - Language: TypeScript - License: LGPL-3.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/zeriontech-defi-sdk ## One Router, and adapters that translate each protocol The DeFi SDK is described as an open source system of smart contracts that allows you to execute trades with ERC20 tokens and track balances on different protocols, and the repository description puts it in fewer words, that it makes money Lego work. The structure is a single Router contract plus a set of adapters. The Router handles trading, and it can swap any ERC20 token on layer two chains through that one contract rather than through a different integration per venue. The adapters handle the other half of the problem, which is asking a protocol what it knows about a user: how much debt an address has on Compound, what a user has deposited in Maker or Aave or dYdX, and what the pieces of a derivative token are made of, such as how much of a wrapped position is one underlying asset and how much is another. That last example is the clearest statement of what the adapters buy you. A yield-bearing or structured token does not expose its composition, so any application that wants to show a user their real exposure has to ask each protocol, and each protocol has its own way of saying it. The adapter is the translation layer, and having it in one place is the value of the project. The README frames the same point as a feature, interacting with multiple protocols in a unified way, and the documentation is split into a page on the Router and a page on interacting with the contracts. The code is TypeScript, the licence for the smart contracts is LGPL-3.0, and the repository has a build, test, coverage and lint workflow badge each, so the project is at least instrumented for continuous integration. ## The trading surface is deliberately narrow The trading feature list is short enough to read carefully, and each item is a decision a trading interface has to make. Amounts come in two types, absolute, which is the usual amount, and relative, which is a percentage of the balance. Swaps come in two types, fixed input amount and fixed output amount. Those four combinations are the whole surface. Approvals are handled by three kinds of permit function, and this is the part that shows how much the protocol space has fragmented. There is the EIP-2612 style, the DAI-like style and the Yearn-like style, and the contract offers all three because they do not have the same signature or the same semantics, and a router that wants to work with every token in the ecosystem has to speak all of them. Fees are also split in two. The protocol fee is managed by the owner of the Router contract, and it supports one-time discounts that require the signature of an address holding a special role. The marketplace fee is managed by the creator of the transaction. So a caller can pay a fee of their own choosing into the marketplace, while the protocol takes its cut, and the protocol can waive or discount its own portion for a specific address. The last item is relayed transactions, which need only an EIP-712 signature from the user. That is what makes the Router usable from a contract or a relayer rather than only from a wallet that sends the transaction itself. The result is a Router with a small, explicit parameter space. It is the kind of interface you can reason about, and it is also the kind that will not grow new parameters without a redesign. ## Two kinds of adapter, and they live on two branches The contribution guide describes two categories of adapter, and the way the repository is organised makes the distinction structural rather than editorial. Read-only adapters and interactive adapters are maintained in separate branches of the repository, the read-only ones on master and the interactive ones on the interactive-updates branch. The default branch is called router, which is a third name again and suggests that the working branch for the Router contract is where most of the recent action is. Three branch names for three purposes is a sign of a repository that carries several lines at once, and it is a small operational cost for anyone who wants to contribute. The README does say where to go, with the full instructions on adding custom adapters in the documentation under a directory named for creating your adapters, and it invites people who want to add an adapter to reach out on the project's Discord. The other thing the adapter documentation implies is that adding a protocol is a defined, repeatable job rather than a bespoke hack. The example in the README, asking how much debt an address has on Compound, is phrased as a question, which is a good sign about the interface: the adapter answers a question, and the questions are the same shape across protocols. The addresses of every deployed contract are collected in one document, which is the piece an integrator actually needs, because an adapter that talks to a protocol has to be pointed at the right deployed instance of the SDK's own contracts. ## Deployment goes through a wallet on purpose The development notes are about deployment, and they use the Truffle Dashboard rather than a script, with a stated reason: it is used for secure deployment. The sequence is short. You install the dependencies with npm install, you start the dashboard, and then you deploy the Router contract with the router deployment command, signing the deployment transaction in your browser at the local address the dashboard serves. You then fill in the address of the newly deployed contract in the deployment script. The same instruction applies to the SimpleCaller contract with the matching command. After the fee beneficiary for the chosen network is filled in the same script, the initialise command can be run, and then the verify command checks the contract on any block explorer, which needs the explorer API key in the environment file and the hardhat configuration file that reads those keys for the explorer settings. The reason to route deployment through a wallet rather than a bare script is not a mystery. A contract that holds value and administers protocol fees is exactly the kind of artefact you want to deploy from a key you control and a machine you trust, and a dashboard that asks you to sign in the browser makes the deployment an explicit act rather than a side effect of running a script. The alternative scripts are there too, in the package manifest, where you can see the full set of deployment targets: the Router, a safe proxy, the SimpleCaller, a variant of it with permit2, and separate callers for the two versions of Uniswap. So the same codebase deploys a small family of contracts, and the fee setup and the verification are separate steps you can run again after a redeploy. ## Tests, coverage, two linters and a static analyser The tooling section is where this repository is more modern than its release history suggests. The Router contract and its dependencies are fully covered with tests, and the commands are npm run test and npm run coverage, both driven by Hardhat, which the README praises for running tests extremely fast. A gas report can be switched on or off for the test run with a flag in the environment file, and the environment sample shows that flag alongside the explorer API key and the wallet private key. There are two linters and they cover the two languages in the project. The Solidity linter runs over the contracts directory and the JavaScript one over the repository, with a combined script that runs them in sequence. A separate script runs Slither, the static analyser, filtered to skip the dependency directory, and the README notes that Slither has to be installed first, for example through pip, and that it is the tool the project uses for security analysis. The documentation has its own serve command, which runs a docs server on a port, and the configuration points at a mkdocs setup. There is also a pre-commit setup with a lint-staged configuration that formats Solidity with prettier and runs eslint over the test and script directories. Taken together, that is a solid quality setup for a contract system: fast tests, coverage on the money path, two linters, a static analyser, and formatting enforced before a commit reaches review. ## The licence, the version gap and the dependency pins Two things are worth knowing before you build on this code, and neither is in the feature list. The first is the licence. All the smart contracts are released under the GNU LGPLv3, and the package metadata says the same with the more precise SPDX identifier. The repository carries both licence files, one for the code and one for the lesser of the library terms, which is the standard way to ship a library that is also a library in the legal sense. The practical point is that a contract system published under LGPL means the terms travel with any copy of the contracts you deploy or fork, and a team that has a policy about copyleft in deployed artefacts should read those two files rather than assume a permissive licence from the general shape of the project. The second is the gap between the release history and the repository activity. The listed releases are v1.4.0 in March 2020, v2.0.0 in April 2020 with a new adapters architecture, and v2.1.0 later that month with more adapters. The last push to the repository was on 2026-10-15, so the code is being worked on while the version history stops in 2020. If you are evaluating this as a dependency, that gap is the first question to ask, because the absence of tags means you are tracking a branch rather than consuming a release. The dependency pins tell the same story from a different angle. The runtime dependencies are OpenZeppelin contracts at 4.4.0 and the core and periphery packages for Uniswap version 3 at 1.0.1 and 1.4.4. Those are exact pins to versions from 2021, which is the right thing to do for a contract system, and also a snapshot of the ecosystem as it was when the adapters were written. The final practical note is about the contracts themselves. A framework can be well tested and still not be correct for the protocol you want to integrate, so the deployed addresses document and the adapter instructions are the parts to read first. ## Conclusion Adopt the DeFi SDK if you are building a product that has to talk to several lending and exchange protocols at once and want one contract to route trades through, with adapters rather than a bespoke integration per protocol. Do not adopt it if you need a modern, actively maintained dependency tree, because the released versions stop in 2020 and the pinned OpenZeppelin and Uniswap dependencies are from the same period. Before you deploy anything, read the adapter documentation, check the deployed contract addresses for the network you care about, and have the contracts analysed with the security tooling the project provides rather than assuming the Router is safe because it is tested. ## FAQ ### What does the Zerion DeFi SDK do? It is an open source system of smart contracts that lets you execute trades with ERC20 tokens and track balances on different protocols. A single Router contract handles trading on layer two chains, and adapters translate each supported lending and exchange protocol so that balances, deposits and debt can be read in a uniform way. ### What kinds of token approvals does the DeFi SDK Router support? Three kinds of permit function, the EIP-2612 style, the DAI-like style and the Yearn-like style, because the approval mechanisms across the ecosystem do not share a signature. Swaps come in fixed input and fixed output variants, and amounts can be absolute or a percentage of the balance. ### How do I deploy the DeFi SDK Router contract? Install the dependencies with npm install, start the Truffle Dashboard with npm run truffle-dashboard, and run the router deployment command, then sign the deployment transaction in your browser at the local dashboard address. The address of the new contract goes into the deployment script, the fee beneficiary is filled in for the network, and the initialise command sets up the router fee. ### How do I add a protocol adapter to the DeFi SDK? Read-only adapters and interactive adapters are maintained on separate branches of the repository, master and interactive-updates respectively, and the full instructions are in the documentation section on creating your own adapters. The addresses of all the deployed contracts are collected in a separate document for integrators. ### What licence applies to the DeFi SDK smart contracts? The smart contracts are released under the GNU LGPLv3, with both licence files in the repository and the package metadata declaring LGPL-3.0-only. The releases listed stop in April 2020 while the repository was pushed to in October 2026, so a team evaluating it should confirm which branch or commit it intends to depend on. ## Sources - [License: LGPL-3.0](https://github.com/zeriontech/defi-sdk/blob/router/LICENSE) - [Project website](https://docs.zerion.io/defi-sdk/) - [README](https://github.com/zeriontech/defi-sdk/blob/router/README.md) - [Releases](https://github.com/zeriontech/defi-sdk/releases) - [zeriontech/defi-sdk on GitHub](https://github.com/zeriontech/defi-sdk) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zeriontech-defi-sdk