Five authorities hold the money, and the owner cannot mint
Five separate authorities share the money layer, enforced on chain. The owner key administers but cannot mint a single token.
A stablecoin has one terrifying property: somebody can create money. The whole security design of the money layer is the answer to who that somebody is, and the answer is never one key. mintrr builds the stablecoin around that answer, so the shape of power is fixed before a single token exists.
Five jobs, five keys
The mintrr stablecoin has five authorities, and each one does exactly one job.
The owner administers the token. It sets the other four, points the contract at a master minter, a pauser and a blacklister, and owns the contract itself. The master minter appoints minters and sets each one's allowance, but mints nothing directly. The pauser can stop all movement. The blacklister can block individual addresses. The proxy admin, the fifth, controls upgrades, and it is deliberately not the owner: the authority that changes the code is a different key from the authority that runs the token.
That is the whole design. Five jobs, five keys, and no key that does two of them. An attacker who steals one key gets one power, not the product.
The split is enforced, not documented
A separation of duties that lives in a README is not a control. It has to fail closed when someone collapses two jobs onto one key.
In the mintrr stablecoin the initializer refuses those keys. Proxy admin and owner must differ. Owner and master minter must differ. Master minter and pauser must differ. The check runs at initialization, before any token exists, so a deploy that hands two jobs to one key does not produce a wrongly-shaped stablecoin that someone notices later. It produces nothing at all.
This is the difference between a promise and a mechanism. The promise is "you should use separate keys." The mechanism is "two keys that should differ cannot be the same, and the contract will not deploy if they are."
Why the owner cannot mint
Here is the question people ask first: if the owner administers the token, does the owner create it?
No. Minting needs two things the owner does not have by virtue of owning anything: an appointment as a minter, and a mint allowance. The mint function checks both on every call and reduces the allowance with each mint, so even an appointed minter can only create up to its limit. A stolen minter key drains its allowance and stops; it cannot mint more than it was given.
So the power is split a second time. Ownership is administration. Creation is a separate, capped, auditable grant that the owner hands to someone else and can take back. The owner can configure the money layer. The owner cannot conjure money into it.
Why five, and not one
The reason is blast radius, and it is arithmetic, not philosophy.
A stolen pauser key does real damage: it freezes the token. That is bad, and it is recoverable, because freezing is reversible and visible. A stolen blacklister key blocks addresses; also reversible, also visible. A stolen master minter key can appoint a minter and mint up to an allowance; capped, and the appointment is on chain.
A single key that owns, mints and upgrades is not one of those. It is a takeover. There is nothing to cap, nothing to reverse, no second authority to notice. Five keys mean five separate thefts have to happen at once, and each theft on its own buys the attacker strictly less than the whole.
What this looks like when you use it
You describe a stablecoin. mintrr generates the contract, checks that the separation is in the code, and hands you a deploy. You supply five keys, or five multisigs, and the contract refuses if they collapse. After deploy, mintrr reads each role back off the chain and asserts it matches what you asked for, so the shape you approved is the shape that is live, not the shape you hoped for.
If you are not a bank and five keys sounds like a lot: start with the owner as a multisig, and hand the other four to separate keys you can rotate. The point is not that you must run a compliance department. The point is that the contract gives you the shape a compliance department needs, on the day you need it, with no redeploy.
The limits, stated plainly
mintrr builds and verifies this contract. It does not hold any of the five keys, and it never signs. Who ends up holding each key, and what policy governs rotating them, is your decision and your risk. The on-chain separation is proven by the contract; the operational security of the five keys is yours.
If you want the money layer for a real business, that is exactly the shape to build on. Reach out from the contact page and we will walk through which of the five you should hold yourself and which you should delegate.