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 bootstrap it. The closed door is not against capital. The closed door is against capital that would change what nimimo is.
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.
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.
Identity should be a primitive, not 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. The product is open enough that other applications can resolve nimimo names without nimimo being in the loop. If nimimo went away tomorrow, the names would not stop working in any system that chose to keep resolving them.
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 bootstrapped, 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.