What nimimo deliberately does not do, and why.
Scope discipline is part of the architecture. The four-axis separation in architecture/four-axes.md holds because nimimo refuses to take on operations that would force one axis to acquire authority over another. Every item below is something nimimo could technically build but has chosen not to, because building it would either collapse an axis, recreate a regulated activity, or duplicate a category of solution that already exists and that nimimo composes with cleanly.
The goal is not minimalism for its own sake. The goal is that nimimo remains the identity primitive, and lets every other category be solved by whoever solves it best.
A note on scope. The items below are things nimimo-as-it-exists-today refuses to build into itself, because doing so would collapse the four-axis separation that a solo, self-funded project cannot safely operate under. They are not a blanket claim that these capabilities should never touch nimimo. Most of them — fiat ramps, custodial recovery paths, KYC onboarding, swap/staking surfaces — already exist inside regulated operators such as wallets and exchanges. A regulated acquirer or integration partner combining its existing rails with nimimo's identity primitive, especially alongside its onboarding, is a scenario the author is explicitly open to, up to and including an acquisition in which nimimo becomes the identity and UX layer of a larger regulated product. The author is also open to being directly involved in solving the integration points that sit across the non-feature boundary in that kind of arrangement. The alignment bar for any such conversation is documented in architecture/ethics.md under "Capital must serve the mission, not distort it".
Decentralized exchange / swap
nimimo does not match orders, hold liquidity, route swaps, quote prices, or earn fees on trades. Users who want to swap between assets use any DEX, aggregator, or wallet swap feature they prefer. nimimo's job is to resolve a name to an address, not to operate a market.
Building a swap into nimimo would force the Ownership axis to participate in trade execution and would put nimimo in the value path. That collapse is not worth it for a category that has many strong solutions already.
Cross-chain bridge
nimimo does not bridge value between chains, lock assets on one chain, mint wrappers on another, or operate any kind of multi-chain liquidity. Senders pick the chain they want to pay on; the recipient receives on that chain natively. If a user needs to move value between chains, they use a bridge separately, with eyes open about the risk.
Bridging requires custody or trust assumptions that the four-axis model rejects.
Mixer / privacy pool
nimimo does not mix, anonymize, obfuscate, or pool transactions. Privacy at the chain level is whatever the underlying chain provides. Users who want stronger transactional privacy use protocols designed for it.
This is also a category with severe regulatory exposure, exactly the exposure the rest of the architecture is designed to avoid.
Fiat on-ramp / off-ramp
nimimo does not buy or sell crypto for fiat, hold customer fiat balances, or operate card processing. On-ramping and off-ramping are solved by dedicated providers; users compose them with nimimo externally.
A fiat ramp would introduce deposit-taking and KYC obligations that the architecture is structurally free of today.
Token / points / loyalty
nimimo has no token. There is no governance token, no utility token, no points program, no rewards token, no airdrop, no presale, no treasury, no vesting schedule. The product is free, and value accrues to users in the form of usable identity, not redeemable units.
A token would create an issuer, an issuer creates regulatory attachment points, and the entire regulatory posture documented in architecture/regulatory-posture.md would have to be rewritten.
Yield / staking / interest
nimimo does not pay interest, generate yield, route deposits to staking, restake, or offer any return on holdings. Funds at a nimimo address sit at that address until the user moves them. Yield-bearing strategies are an entirely different product category.
Lending / borrowing
nimimo does not lend, borrow, accept collateral, liquidate positions, or operate credit lines. Lending markets exist as their own protocols and products; nimimo does not duplicate them.
Custodial option / "easy mode" wallet
nimimo does not offer a custodial fallback for users who would prefer it. There is no nimimo-managed wallet, no "we hold your keys for you" mode, no recovery-by-support flow, and no admin override. The Ownership axis is non-negotiable. A user who genuinely wants custody is better served by a product built around custody from the ground up.
This is the single most-requested feature that nimimo will never ship. It is the feature whose absence the entire architecture exists to guarantee.
Account recovery via support
nimimo cannot reset, restore, or transfer ownership on a user's behalf. Recovery is the user's encrypted artifact and the user's PIN; nimimo never holds the PIN and therefore never has a path to reconstruct ownership. There is no support ticket that can unlock an account, because there is no account in the custodial sense. No human at nimimo has authority over your ownership material.
Today the encrypted artifact itself is user-held — a QR code, a printable PDF, or both. If a user loses both their access methods and the artifact, the ownership material is gone. That is the current cost of the non-custodial guarantee, and it is paid honestly rather than hidden behind an emergency override.
That cost is also the single biggest gap between momentary self-custody and long-term portability, and the scope of this non-feature should be read narrowly. The commitment is the absence of support-mediated recovery — any path where a person at nimimo restores an account on a user's behalf. That is the door that stays closed.
Improving recovery ergonomics without giving nimimo authority over ownership material is an exemption the author has thought about, and there are workable shapes for it inside the four-axis separation. If user demand makes one worth building, it can be built without touching the commitment above.
What nimimo does build: creator monetization
nimimo profiles can receive tips, sell content behind a price, and accept direct payments. These features are not on the non-features list because they do not collapse any axis:
- Ownership remains cryptographic and device-local. Payments settle to the creator's own address; nimimo never holds funds.
- Access still carries no authority. A compromised session cannot redirect payments or alter ownership.
- Identity gains a richer surface (tip options, content cards) but remains referential. It points at ownership; it cannot override it.
- Recovery is unaffected.
Creator monetization extends the profile from a name that resolves to addresses into a page that people can actually pay. The architectural guarantee is the same: nimimo is the resolver, not the custodian.
Tips carry no platform fee. Content payments currently carry no fee either. If a fee model is introduced in the future it will be assessed against the same axis-separation bar that governs every other feature decision.
What nimimo composes with
The non-features above are not gaps. They are interfaces. Every one of them can be filled by an existing, well-suited product that the user chooses themselves. nimimo's job is to be the stable identity layer underneath.
This is the same posture the rest of the internet takes toward identity and addressing: a name is a name, and the things that use the name are separate.