Before ZeroLoss had a dashboard, a referral program, or a single automation unit running in production, it had one architectural constraint that shaped everything built after it: never take custody of user funds, under any circumstance, regardless of what that constraint made harder to build. This wasn't a feature decided on partway through development. It was the starting premise everything else had to be designed around.
A constraint, not a feature to add later
It would have been technically simpler, in the earliest stages, to build a platform that pooled user funds into a central wallet and executed trades centrally from there — that's a genuinely easier system to build, and it's how a meaningful share of automated trading products in this space have historically operated. We chose the harder path instead: trade-only API access, and nothing else, from the very first version. The reasoning was straightforward even if the implementation wasn't: a pooled-custody model asks users to trust a company's solvency, internal controls, and continued good judgment indefinitely. A non-custodial model asks users to verify a specific, checkable permission on their own exchange account instead. Verification is a fundamentally more durable basis for trust than a promise, and we wanted the product built on the former from day one.
What this ruled out early, before it ever got built
Certain product ideas that assumed some form of custody — a unified cross-exchange wallet, a simplified onboarding flow that briefly held funds during a transition step, a "vault" feature that consolidated balances for convenience — were shelved before development started, specifically because they conflicted with the non-custodial constraint we'd already committed to. Some of these would likely have made onboarding marginally smoother in the short term. We judged that trade-off against the constraint we'd already decided was non-negotiable, and the constraint won every time it came up.
Why this was worth the added difficulty
The crypto industry's history includes enough custodial failures — platforms that held user funds and then couldn't, or wouldn't, return them — that "trust us with your funds" was never going to be a credible pitch to build a company around, regardless of how genuinely trustworthy we believed our own intentions to be. Intentions aren't verifiable from the outside. A structural inability to withdraw funds is. We wanted to build something whose core security property didn't depend on anyone believing us, and that meant accepting the additional engineering complexity of a non-custodial architecture from the very beginning, rather than treating it as a feature to bolt on once the easier, pooled-custody version had already proven the concept.
What this looks like today, years later
Every subsequent product decision — the referral program, the VIP tier, the franchise structure, the card feature currently in development — has been built to fit within this same constraint rather than requiring an exception to it. That consistency isn't an accident; it's the direct, ongoing consequence of treating the non-custodial principle as foundational rather than as one feature among many. Years later, it remains the reason the rest of the architecture looks the way it does, unit by unit, feature by feature.
The current state of that architecture, in full technical and legal detail, is described in our Non-custodial Disclaimer and About Us.