Velvet.Capital

Overview

Velvet.Capital is a non-custodial on-chain asset management platform where users deposit assets into a fund and receive a tradeable index token representing their proportional ownership.

I joined as the first engineering hire and built the protocol from an empty repository, leading its technical architecture through four audited production releases over 3.5 years. By the time I left, the protocol secured over $7 million in TVL across Ethereum, BNB Chain, Base and Arbitrum.

Correctness, security and long-term maintainability are crucial when systems manage real assets.

Problem

Investors want diversified, actively or passively managed crypto exposure without giving up custody of their assets. Within a given portfolio they trust the asset manager to make trading decisions, but every holding, fee calculation and performance metric should still be independently verifiable on-chain, not just reported after the fact.

That means every deposit, withdrawal, ownership share and fee calculation has to be represented correctly in a deterministic system that anyone can audit.

Solution

Users deposit assets into a fund and receive an index token representing their proportional ownership of the underlying portfolio. As the portfolio changes through trading, lending or staking, the token continues to represent each investor's share without requiring off-chain accounting.

The protocol integrates with more than ten DeFi protocols for trading, lending and yield generation, and prices assets using Chainlink oracles.

As the first engineering hire, I didn't simply implement features — I established the protocol's architecture, engineering standards and security practices that the team continued building upon.

Architecture

The architecture was designed around a simple principle:

Keep financial accounting deterministic while allowing the protocol itself to evolve safely over time.

Tokenization Core

The index token mints and burns against the underlying portfolio, ensuring ownership always reflects each investor's proportional share as asset values change.

Upgradeability

Early versions used the EIP-1167 minimal proxy pattern to reduce deployment costs by roughly 90%.

As the protocol matured, I migrated the architecture to ERC1967 UUPS proxies to allow protocol evolution without redeploying every existing fund.

Pricing & Fees

Chainlink oracles handled pricing, slippage protection and performance-fee calculations.

Later I redesigned the accounting model from absolute price feeds to ratio-based accounting, removing the dependency that every supported asset required a Chainlink feed.

Custody

Each portfolio's vault is itself a Safe — either custodial, with designated owners who can act on it, or non-custodial, with no owners at all, governed entirely by protocol logic. Protocol administration was separately protected through its own Safe multi-signature wallet, where I served as one of the signers.

Engineering Decisions

The upgradeability decision is the architectural choice worth highlighting most.

Minimal proxies are inexpensive and simple, but they are effectively immutable. That is an advantage for software that never changes and a limitation for a protocol expected to evolve over time.

Migrating to UUPS introduced additional complexity — upgrade authorization, storage layout compatibility and version management — but enabled the protocol to ship multiple production releases without forcing every existing fund to migrate.

Upgradeability only makes sense if the upgrade mechanism itself is treated as security-critical. Every storage change, authorization path and upgrade flow therefore became part of the audit surface and received the same scrutiny as the protocol's business logic.

Technology Stack

• Solidity
• Foundry
• Hardhat
• OpenZeppelin UUPS
• Chainlink
• Safe Multi-Sig
• TypeScript deployment and testing tooling

Trade-offs

Every significant architectural decision involved balancing competing priorities.

Upgradeability vs. Immutability — Upgradeability allowed the protocol to evolve while accepting the additional complexity and security considerations of upgrade authorization.

Oracle Dependency vs. Token Support — Chainlink provided high-confidence pricing but restricted supported assets to those with available feeds. Moving toward ratio-based accounting increased flexibility while accepting different accounting trade-offs.

Gas Optimisation vs. Readability — Reducing gas costs by roughly 20–30% required lower-level Solidity optimisations that made parts of the codebase more difficult to read. That complexity was acceptable because those execution paths received the highest level of testing and audit coverage.

Lessons Learned

Being the first engineering hire means every decision compounds.

Testing practices, review culture, documentation standards and architectural boundaries become the foundation future engineers inherit.

Nine professional audit cycles also reinforced an important lesson: the most expensive bugs are rarely the clever ones.

They are usually the boring edge cases — rounding behaviour, unexpected execution order, stale oracle responses or assumptions that nobody questioned.

I also learned that good architecture compounds over time. Strong abstractions make future versions easier to build, while poor ones become technical debt every new feature has to work around. That experience is one of the reasons I'm increasingly interested in software architecture beyond Web3.

What I'd Do Differently Today

Looking back, there are several decisions I'd approach differently.

• I'd introduce even stronger interface boundaries between protocol modules to simplify future integrations.
• I'd move towards ratio-based accounting earlier to reduce reliance on external price feeds.
• I'd invest more heavily in invariant testing and simulation before production deployment.

None of these were critical architectural mistakes — the protocol scaled successfully through multiple audited releases — but experience changes how you evaluate trade-offs.