Contract Upgradeability for Locked Funds

[rjan90]

Description

The current PandoraService contract implements UUPSUpgradeable, which creates legal and security concerns around locked funds management. For legal compliance and user trust, we need to ensure that:

• Non-upgradeable contract: The contract must not be upgradeable to prevent any possibility of modifying locked fund handling logic
• Service creator restrictions: The service creator cannot have custodial control over locked funds
• Immutable fund security: Locked funds in payment rails must be protected from any administrative access

[rjan90]

We need a brainstorming session here, and also guidance on where the boundaries of legal reasons for this change. I.e is multi-sig contract with multiple parties seen as a no-go, etc.

[BigLep]

Per 2025-07-10, @ZenGround0 is going to do some defi upgradeability research

[pali101]

TLDR: Immutable and non-custodial smart contracts are emerging as the safest standard in DeFi, both for user trust and legal risk. Upgradeable contracts, while flexible, introduce centralization and regulatory exposure.

I was looking into industry best practices and legal trends around smart contract upgradeability, especially as it affects user trust and regulatory risk. Here’s a summary of findings that could help guide decision.

Industry Patterns

Uniswap

• How it works: Each version is a new contract. Earlier versions continue to exist independently (unowned and non-upgradable).
• Pros: No upgrade path = no admin can change fund-handling logic. After deployment, admin roles are removed. User funds are never at risk of an upgrade rug pull.
• Cons: Inflexibility, bugs or improvements require new contracts and user migration.
• Governance scope: Governance controls treasury, protocol fee switches, and new deployments, but cannot upgrade or change existing contract logic.

Compound

• Model: Opposite approach to Uniswap. Uses upgradable contracts with governance.
• How it works: Use proxy or modular contracts so the logic can be upgraded (with community governance: token votes, timelocks, sometimes multisigs).
• Pros: Bugs can be fixed, new features added.
• Cons: Has enabled “governance attacks” and keeps protocol within regulatory scope longer since admins/governance retain control for longer.

Aave

• Model: Similar to Compound, but with added emergency controls.
• How it works: Uses upgradeable contracts and on-chain governance, but its "guardian" (a community-governed entity) has broader emergency powers (e.g., instantly pausing the protocol in a crisis).
• Pros: Enables rapid response to critical risks.
• Cons: Same centralization/regulatory concerns if governance/admin is not fully decentralized.

MakerDAO

• Model: Everything is upgradable via on-chain governance.
• How it works: Protocol changes (including emergency shutdown) can be triggered by a coalition of major MKR holders.
• Current trend: Moving toward "governance minimization" ,i.e., stripping out as many admin powers as possible as the protocol matures to become fully autonomous (Endgame plan).
• Goal: Continued governance minimization by removing admin keys and shrinking central authority to achieve a robust, legally resilient, user-controlled protocol.

Governance Minimization

• Best practice in recent DeFi research: mature protocols should deliberately minimize governance powers over time. Early admin control may be necessary for risk, but long-term the goal is full immutability and autonomy.

Legal and Regulatory Perspective

Van Loon v. U.S. Treasury (2024)

• The Fifth Circuit held that immutable smart contracts, which cannot be altered once deployed, are not considered “property” under U.S. sanctions law.
• These immutable contracts fall outside the scope of the Treasury’s OFAC sanctioning authority.
• In contrast, contracts that are mutable (can be changed via upgrade mechanisms or admin keys) can be viewed as property or as within the control of a party, making them subject to regulatory action or sanctions.
• References: Bloomberg Law, Arnold & Porter, Yale JREG

Regulatory "Safe Harbor" and True Decentralization

• The SEC closed its investigation into Uniswap Labs without enforcement, largely due to Uniswap's non-custodial and immutable architecture.
• Legal analysis, including from Columbia Law School, emphasized that Uniswap's users retain direct control over their assets at all times. This direct user control and absence of custodial authority was likely the key reason the SEC did not take enforcement action against Uniswap, according to multiple legal analyses.
• In contrast, platforms like Kraken or Binance are considered custodial because companies hold and control user funds and can modify protocols.
• References: Columbia Law School's Blue Sky, Uniswap Blog

Protocols that remove upgradeability and admin control maximize user trust and minimize legal risk. This approach is now recognized as best practice by both industry and regulators.

Further Reading

Industry and Protocol Docs

• Smart Contract Upgradeability Patterns (hackmd)
• Stack Overflow: How does Uniswap upgrade its smart contract given that smart contracts are immutable once deployed?
• Uniswap Governance Docs (for process, not for code upgrades)
• Compound Governance Docs
• Aave Governance Docs
• MakerDAO Governance Whitepaper
• MakerDAO Endgame Plan (forum)
• Governance Minimization by Fred Ehrsam & Dan Robinson (Paradigm)

Research and Security

• Governance Attack on Compound (Cointelegraph)
• Not so immutable: Upgradeability of Smart Contracts on Ethereum (FC'22, Springer)
• Characterizing Ethereum Upgradable Smart Contracts and Their Security Implications (WWW 2024)

Legal and Regulatory

• Smart Contracts Ruling Forces a Blockchain Development Rethink (Bloomberg Law)
• Van Loon v. Department of the Treasury (Yale JREG)
• Uniswap’s Reprieve Reveals the Uncertainty of DeFi Regulation (Columbia Law School Blue Sky Blog)
• A Win for DeFi: SEC Closes Uniswap Investigation (Uniswap Blog)

[rjan90]

@ZenGround0 and @wjmelements has been working on a design for the migration plan here: https://filoznotebook.notion.site/Filecoin-Services-Model-for-Change-241dc41950c180af85f1cac1687766a5.

Immediate code pieces that needs to land are currently in draft here: #115

[rjan90]

Removal of the contract upgradability for Filecoin-Pay was implemented here: FilOzone/filecoin-pay#196