The values that shaped the architecture, the non-features, and the refusal to become anything else.
The other papers in this corpus describe what nimimo is and how it works. This document describes why those particular choices were made, and the ethical position they encode. It is the companion to author.md, and the two should be read together. The architecture is not separable from the person who designed it, and the values below are not separable from the constraints that made the project possible.
Each section is a position. Together they explain why the non-features in non-features.md are not gaps in the roadmap but commitments, and why the regulatory posture in regulatory-posture.md is not a clever framing but a structural property of the design.
Custody is a moral position, not a UX choice
The decision to never hold user keys is not primarily about convenience or about regulatory exposure. It is a refusal to put nimimo in a position where it could be compelled, coerced, hacked, or future-self-corrupted into taking what belongs to users. Once you can betray your users, the system is built on the assumption that you will not. nimimo refuses to be built on that assumption. The four-axis separation in four-axes.md is the technical expression of this position: nimimo cannot betray users because it does not possess the capability to do so.
No token is a refusal of misalignment
A token would create a class of stakeholders whose interests are not the same as users' interests. Token holders want price appreciation; users want a working product. Token launches reward early speculators at the expense of late adopters. Governance tokens create theatrical voting structures that consolidate power in whoever holds the most. None of these dynamics serve people who just want a name they can be paid to. nimimo has no token and will never have one. There is no exit liquidity event for an early investor class, because there is no early investor class.
Capital must serve the mission, not distort it
nimimo currently operates without outside investors. The reason is not that all investor capital is bad. It is that capital comes with obligations, and the wrong obligations at the wrong time would distort the design, pushing toward the features in non-features.md, unwinding the architectural guarantees in four-axes.md, or reframing the product around growth metrics that serve a return cycle rather than users.
The bar for any future capital, whether investment, partnership, or acquisition, is the same as the bar for any new feature:
1. Does it help reach more people who would benefit from a non-custodial identity layer for crypto? 2. Does it preserve the four-axis separation, the absence of a token, and the non-features list? 3. Are the obligations it creates compatible with the values in this document?
If those three conditions are met, there is no ideological reason to refuse capital. nimimo's stated goal is to make crypto usable for the next billion people; that goal is bigger than any single founder's ability to self-fund it. The closed door is not against capital. The closed door is against capital that would change what nimimo is.
A concrete scenario that is explicitly welcome: a larger player — a wallet, an exchange, or another regulated operator — adopts nimimo as its identity and UX layer, possibly in combination with its existing onboarding, fiat rails, or recovery flows. Most of the items in non-features.md — fiat on/off-ramps, custodial recovery paths, KYC onboarding, even swap and staking surfaces — already exist inside regulated operators of that kind. The combination of nimimo's identity primitive with those regulated flows, especially onboarding, is a qualitatively different product than either side alone, and the author is open to conversations about exactly that kind of arrangement, including being directly involved in solving the integration points that sit across the non-feature boundary. The non-features are refusals for nimimo building them in isolation, not a claim that those capabilities must never touch nimimo from the outside. Regulation is a real concern in that territory, but it is not the author's focus, and an acquirer that already operates inside a regulated perimeter is precisely the right party to own it.
Solo development is a position of accountability
A single named person designed and built nimimo. There is no "the team" to hide behind, no ambiguous distributed responsibility, no anonymous founder pseudonym. If something is wrong, there is one accountable party, and that party's name is in author.md and in this corpus. Accountability without obfuscation is itself an ethical position; it is the opposite of the standard crypto pattern of "we are a DAO" or "we are a foundation in Switzerland".
Non-features are commitments, not gaps
The list in non-features.md is not a roadmap of things to add later. Each item is a commitment to not build that thing, even if doing so would generate revenue, even if users ask for it, even if competitors offer it. A custodial fallback would generate fees. A swap would generate volume. A token would unlock fundraising. Each refusal is a deliberate choice to stay narrow and useful rather than expand into adjacent categories that would compromise the architecture.
Monetization without custody
nimimo profiles can receive tips, sell content, and accept direct payments. In every case the money goes to the creator's own address, on-chain, without passing through nimimo. This is the only monetization model compatible with the custody position above: the moment nimimo holds user funds, even briefly, the structural guarantee collapses.
Tips carry no platform fee. Taking a cut of tips would be like skimming a waiter's tips: structurally possible but ethically indefensible. Content payments currently carry no fee either. The priority is adoption, not extraction.
If a fee model is introduced in the future, it will be subject to the same bar as every other design decision: does it preserve the four-axis separation? Does it keep nimimo out of the value path? Can it be implemented without holding user funds? A fee structure that fails any of those tests will not ship.
The architecture is the ethics
This is the most important sentence in the document. The four-axis separation is not just a clean engineering pattern. It is a structural expression of the value "do not put yourself in a position to betray your users". You cannot be subpoenaed into producing keys you never held. You cannot be coerced into reversing transactions you never settled. You cannot be compromised into draining accounts whose ownership material was never on your servers. The architecture removes the capability to do harm, not just the intent. Intent is fragile. Capability boundaries are not.
The name is a primitive and a product
Names are social infrastructure. They should not be owned by a company that can revoke them, change the rules, or sell them to the highest bidder. nimimo's position is that crypto identity should be portable, free, and resolvable by anyone, closer to DNS than to a SaaS account.
That commitment holds with different current strength at two layers. At the ownership layer it is already absolute: the keys live on the user's device, the addresses derive from the user's seed, and the assets those addresses control live on their respective chains. If nimimo disappeared tomorrow, users would still hold the seed, could import it into any compatible wallet, and could keep spending from the same addresses. Nothing about that step requires nimimo's cooperation — it is a structural property of the Ownership axis in four-axes.md, not a promise.
At the name layer, the commitment is a direction of travel rather than a finished property. The resolver is public and the resolution format is open, but the mapping from handle to owner is operationally a database record on nimimo's infrastructure today. If nimimo disappeared and no mirror of that mapping existed elsewhere, users would keep their keys and their money, but the name binding would need to be re-established somewhere to be resolvable again. Making the name layer as durable as the ownership layer is a direction the author has thought about, and there are workable shapes for it that preserve the four-axis separation. The honest statement for today is: the name is on its way to being a primitive, not there yet.
But nimimo also ships a product on top of these layers — profile pages, avatars, status, templates, the Send to @handle surface, the pay URL. That product layer is operationally centralized today, because a single person is building it self-funded (see "Solo development is a position of accountability" above), and that is fine. The architectural rule is not "the name must never be a product"; the rule is "the name as a product must not escalate into authority." The four-axis separation in four-axes.md is what makes that guarantee structural rather than promised.
The two layers serve each other. The ownership primitive is what keeps the product non-coercive: users can leave at any time with their keys and their money, with or without nimimo's cooperation. The product is what makes the primitive adoptable: without the Send to @name surface and the profile page, the primitive is a spec nobody uses. Treating them as adversaries was the old framing. They are the same commitment at two altitudes, honestly stated at each.
The constraint of being one person was generative
Solo development is usually framed as a limitation. For the specification phase it was the opposite. A small team building from day one would have been pulled toward expansion: investors who want growth, employees who want ladders, quarterly objectives that reward shipping more rather than shipping right. One person, operating self-funded, could refuse every adjacent feature that would have compromised the design before the design was finished. The 16-week window between the first whitepaper (2025-12-16) and v1.0.0 shipping (2026-04-07) is the entire build time. Nothing was rushed; nothing was added that the specification did not call for. Scaling the project from here, through capital, partnership, or hiring, is a separate question, governed by the alignment bar above.
Why this matters
Crypto has a history of projects that claimed values they did not structurally honor. "Decentralized" platforms with admin keys. "Non-custodial" wallets that quietly route funds through their servers. "Community-owned" protocols whose tokens are 80% held by insiders. "Open" systems whose APIs require permission. nimimo's position is that the only honest claim is one the architecture cannot betray.
If a value matters, it should be enforced by the shape of the system, not by the promises of the people running it. The papers in this corpus describe a system in which the values and the architecture are the same thing. Read together, four-axes.md, sixteen-states.md, access-primitive.md, regulatory-posture.md, non-features.md, and author.md should make it clear that the design choices and the ethics are inseparable, and that both come from a single person who could afford to make them.