Proxy Contract
A smart contract that forwards calls to a separate implementation contract. Lets the team upgrade logic without changing the protocol's address, but adds an admin-key risk — someone controls the right to swap the implementation.
Aliases: upgradeable contract, proxy pattern
A proxy contract holds no business logic on its own — it forwards every call (via delegatecall or its TON equivalent) to a separate implementation contract. The proxy’s address stays fixed; the team can swap the implementation to ship new logic without forcing users or liquidity to migrate.
Why use a proxy
- Bugfixes. Patch logic without re-deploying.
- Feature evolution. Add functionality without breaking integrations.
- Address stability. Hard-coded integrations and balances keep working.
Risks
- Admin key risk. If a single team controls the upgrade key, it is a central point of failure. An attacker with that key can deploy a malicious implementation and drain the entire TVL.
- Storage collisions. Storage layout must remain compatible between versions; a mismatch bricks the contract.
- Silent upgrades. Users may keep interacting after a malicious swap because nothing on the surface changes.
Mitigations
- Timelock. Mandatory delay between announce and execute (72h+) so users can exit.
- Multisig on the admin key — see multisig-threshold.
- Renounce upgrades. At some point the team formally locks upgrades (zero address into the admin slot).
- DAO-controlled upgrades. Implementation swap requires a governance token vote.
Context on TON
The proxy pattern is less common on TON than on Ethereum — many TON contracts ship with native upgradeability via a dedicated opcode. Still, major DeFi protocols (EVAA, Tonco) use similar patterns with explicit admin keys or DAO control.