About
About Sullend Labs
Sullend Labs is a web3 R&D company. We build developer tools, DeFi protocols, and DAO infrastructure — and we release everything as open-source.
We are not a VC-backed startup optimizing for a token launch. We are engineers who got tired of building on top of protocols that were underdocumented, unaudited, or abandoned six months after launch. We got tired of SDKs that worked until the underlying library released a breaking version. We got tired of governance systems that were, in practice, theater.
So we started building the infrastructure we wanted to use. Infrastructure that can be read, audited, forked, and deployed by any engineer with the appropriate context — without needing to contact the original authors or wait for a support ticket.
Background
Where Sullend Labs came from
The immediate predecessor to Sullend Labs was a series of internal tools built while integrating multiple DeFi protocols across different chains. Each protocol had its own integration pattern. Some had SDKs, some didn't. Those that did often had incomplete types, undocumented edge cases, or dependencies that conflicted with other tooling in the same monorepo.
The CoreLend architecture emerged from a specific frustration with forked lending protocols: the fork carries the coupling of the original but not the security history. You inherit the complexity without inheriting the years of adversarial testing. Building from scratch with explicit separation of concerns proved faster to audit and easier to reason about than untangling an existing fork.
Govern came last. It came from watching governance systems fail not because the contracts were buggy, but because they were too complex to reason about clearly under time pressure. Smaller, individually auditable modules with a single responsibility each proved more resilient in practice.
Approach
How we make decisions
Every significant design decision in a Sullend Labs project starts with a question: what is the failure mode? We do not optimize for the happy path. We design for the conditions under which the system will be stressed — high utilization, oracle failures, governance attacks, unexpected token behaviors.
We prefer narrow interfaces over rich ones. A contract that does one thing well and exposes a three-function interface is easier to audit, easier to replace, and easier to compose than a contract that tries to anticipate every use case. Richness can be layered on top; you cannot take complexity out once it's in.
We do not ship on timelines that require skipping the audit step. This sounds obvious. In practice it means we have delayed releases and declined launch opportunities that were conditional on deploying before an audit was complete. The decision is not difficult when it's a stated principle, not a negotiation.
How we work
Labs-first. Ship first.
Open by default
Every line of code we write goes public. No private repos, no enterprise tiers, no delayed open-source releases. If we build it, you can read it, fork it, and deploy it. This is not a policy we revisit — it is a structural constraint we build around.
Audit before mainnet
We don't ship financial contracts without a third-party audit. Every protocol we release has a public audit report committed to the same repository as the contracts. No exceptions, no "audit in progress" caveats on mainnet deployments. The audit report is a release artifact, not an afterthought.
Documentation is code
Docs live in the same repo as the contracts and SDK. They are updated in the same PR. If it's not documented, it doesn't ship. Natspec is generated and published as part of the release process, not maintained separately by a technical writer who wasn't in the room.
Engineering standards
Test coverage
All contracts ship with unit tests covering the primary execution paths and known edge cases, plus integration tests running against a forked mainnet state. Coverage is not a metric we optimize — it is a minimum bar below which code does not merge. A 100% coverage score on trivial tests is not the goal. Meaningful coverage of non-trivial behavior is.
Formal specification
CoreLend is being specified formally using a combination of natspec invariants and a separate specification document. The specification describes the intended behavior of the system under all reachable states, including adversarial inputs. The audit engages against this specification, not just against the code.
Dependency policy
We keep runtime dependencies minimal. Every dependency introduces supply-chain risk, version coupling, and bundle weight. We evaluate each dependency against whether we can implement the required functionality in a reasonable number of lines without introducing its own risk surface. When in doubt, we implement it ourselves.
Breaking change policy
Public interfaces do not change without a major version bump and a documented migration guide. We do not ship silent behavioral changes in minor versions. If you are pinned to a version of the SDK or a deployed contract address, we do not break that pin without warning and a clearly documented path forward.
Principles
- 01 Build for engineers, not for token holders.
- 02 Complexity is a cost. Pay it only when necessary.
- 03 If the abstraction leaks, fix the abstraction.
- 04 Audit reports are public. Always.
- 05 Ship incrementally. Don't announce vaporware.
- 06 A failure mode not considered is a vulnerability waiting to be found.
- 07 Documentation written after the fact is documentation written for nobody.
Working on something in the EVM space? We are always interested in talking to teams building serious infrastructure.