Who holds the key?
Every on-chain system in production depends on a few private keys. Where they live, who can use them and what happens when someone leaves are architecture decisions, not handover notes.
An audited smart contract gives a precise kind of assurance: the code does what it says. It says nothing about the other half of the system, which is who can sign. Every on-chain application in production depends on at least one private key that matters — the one that signs anchoring transactions, the one holding the admin role, the one that can pause, upgrade or mint. Whoever controls those keys controls the system, regardless of how good the code is.
Where the key usually lives
In most projects the key is born during the demo. It gets pasted into an environment variable or a config file on a server, because that is the fastest way to make the first transaction go through. Then the demo becomes production, the server gets cloned into staging, a backup is taken, a colleague copies the file to debug something, and nobody goes back.
A private key is not a password. There is no reset link. If it leaks, whoever holds it has exactly the authority you have, and the chain has no way to tell the two of you apart. Rotation, where the contract allows it, is a transaction signed by the very key you are worried about.
Custody is an operational design
The useful questions are not cryptographic. They are about roles, limits and people.
Split the keys by what they can do. The hot key that signs routine transactions should not be the key that can change the rules. Give it the smallest role the contract allows and fund it with only what it needs for the next period.
Put the powerful role behind more than one person. The admin or upgrade role belongs behind a multisig, or inside a KMS or HSM where the key cannot be exported, with approval from more than one person. A single laptop is not a custody model.
Write the rotation procedure before you need it. Which key replaces which, who signs the change, how long the old key stays valid, how you tell partners. Written and rehearsed, not improvised during an incident.
Plan for people leaving. The engineer who set everything up will eventually change job. If the only working knowledge of the keys leaves with them, the system has a single point of failure with a notice period.
Why it belongs in the design review
A counterpart doing due diligence — a bank, an auditor, a foreign partner — will ask who can move funds or change the contract before they ask anything about the code. For organisations in scope of NIS2, key management is already part of the security measures they are expected to document. In both cases the answer has to exist before the question is asked.
Custody is part of the architecture. If it only appears in the handover notes, it was not designed.
Where does the key that controls your contract live today, and who else could sign with it?