I think the most quietly important detail in any smart contract system is not the code you can see. It is the key that controls what the code becomes tomorrow.
A few months back I was reviewing a DeFi protocol for a client who wanted to integrate it into a payment workflow. The architecture looked clean. Audited contracts. Reasonable tokenomics. A team with a credible track record. I was about to recommend it when I noticed something in the deployment configuration that I had almost skipped past. The logic contract was behind an upgradeable proxy. The upgrade key was held by a three of five multisig. Two of the five signers were anonymous.
I did not recommend the integration.
Not because upgradeable proxies are inherently bad. They are not. Systems need to fix bugs. Improvements need to be deployed. Nobody wants to migrate millions of users every time something breaks. The proxy pattern exists for legitimate reasons and dismissing it entirely would be naive.
What I could not get past was the specific answer to a specific question. Who holds the upgrade key. Because whoever holds that key holds the real rules of the system. Not the rules written in the contract you can see today. The rules that will be written in the contract that replaces it tomorrow.
This is the angle I keep thinking about when I read through Sign Protocol's architecture. Because Sign is not a simple payment contract. It is identity infrastructure. Attestation systems. CBDC rails for national governments. The upgrade key question in that context is not a DeFi risk management question. It is a sovereignty question.
What they got right:
The proxy pattern itself is the right architectural choice for infrastructure that needs to evolve. A fixed immutable contract sounds reassuring until a critical vulnerability is discovered or a regulatory requirement changes or a government partner needs a specific compliance feature added. Immutability at the protocol level trades flexibility for permanence and in government infrastructure contexts that trade is almost never acceptable.
Sign building upgradeability into its contracts reflects an understanding of how real institutional deployment actually works. Governments do not sign multi-year infrastructure agreements with systems that cannot be updated. They need to know that when regulations change the infrastructure can change with it. The proxy pattern is not a compromise of the design. It is a requirement for the market Sign is serving.
What bugs me:
The proxy pattern splits every contract into two parts. One contract holds the data. Balances. Identity history. Attestation records. Another contract holds the logic. The rules. The permissions. Who can do what. The proxy sits in front and routes interactions to the logic contract.
The logic contract can be swapped. Same address. Same user account. Different rules.
That swap does not require any user to do anything. It does not require migration. It does not require notification in any form that the current documentation describes. The user is still interacting with the same contract address they always used. Everything looks normal. The rules have changed behind the scenes.
In a consumer DeFi context this is a meaningful risk. In a government CBDC context the implications are considerably more serious. A central bank that controls the upgrade key to the CBDC logic contract controls not just the bug fixes. It controls the transaction filtering rules. The permission structures. The usage restrictions. The compliance logic. All of it can be updated through a proxy swap without any on-chain announcement that users would recognize as a policy change rather than routine maintenance.
It does not look like control. It looks like maintenance. That distinction is the entire point.
My concern though:
Sign's identity layer makes this more consequential not less. When attestations tie identity approval and validation into the contract system upgrades are not just technical changes. They can affect who is allowed to do what. A proxy swap that changes the permission logic of an identity-linked system is a policy decision delivered through a code deployment.
The escalation matters here. A small developer team holding an upgrade key is one risk profile. A private company holding it is another. A government holding it for its own CBDC infrastructure is a different category of concern entirely because now the upgrade key is not just a technical control mechanism. It is a policy lever with no described accountability layer around when and how it can be used.
I am not saying Sign intends any of the concerning use cases this architecture enables. I am saying that the documentation describing the proxy upgrade architecture does not describe the governance framework around who holds the upgrade key under what circumstances upgrades can be deployed what notification requirements apply to affected users and what recourse exists for institutions that disagree with a deployed change.
For infrastructure positioning itself as sovereign protection for national governments that governance gap is the question worth asking before the question of which countries are deploying it.
Still figuring out:
The DeFi protocol I declined to recommend for my client eventually upgraded its logic contract eight months after my review. The change was described in a blog post as a security improvement. Two of the anonymous multisig signers approved it. The upgrade changed how withdrawals were processed in a way that affected users who had not read the blog post.
Nothing catastrophic happened. But the users who were affected had no warning and no recourse because the contract address they trusted had new rules they had never agreed to.
Sign is building infrastructure for governments not for DeFi users. The stakes are different and so is the accountability that the upgrade key governance should carry.
Whoever holds the upgrade key holds the real owner of the system. Not the code you see today. The code that replaces it tomorrow. And in an identity-linked CBDC system that ownership is not a technical detail.
It is the sovereignty question that the whitepaper has not yet answered.
Honestly still figuring out whether Sign's upgradeable proxy architecture is the flexible foundation that makes national infrastructure deployment actually possible or a quiet control mechanism whose governance framework needs to be described with considerably more specificity before any government should be comfortable depending on it.