TerminusAuthorizingProxy contract

[zomglings]

An authorizing proxy contract is a contract A which provides controlled access (via calls) to a contract B, using any access-control mechanism.

Our experiment with the TerminusControllerFacet showed the difficulty of creating and maintaining custom authorization proxies to other contracts. Doing so especially for upgradable contracts would almost force the proxy itself to be upgradable.

The same constraints that make it difficult to maintain custom hand-written authorization proxy contracts also make it difficult to create and maintain such contracts through code generation.

There are in general two strategies to achieve the kind of abstraction required to create an authorizing proxy wrapper around arbitrary contracts:

1. Build-time abstractions - e.g. custom hand-written contracts, code generation
2. Run-time abstractions - e.g. a registry contract for authorization checks on entrypoints to an implementation contract

Our experiments with build-time abstractions indicate that that is the wrong approach to a proxy abstraction.

The EIP-2535 standard for multi-faceted proxy contracts shows the viability of creating such a proxy using run-time abstractions.

This issue proposes we implement an authorizing proxy using the same principles as EIP-2535.

Our authorizing proxy contract will map implementation contract entrypoints to Terminus pools (and whether a caller must hold a token or burn it to make a call).

We will also generalize this implementation into an interface which will support arbitrary authorization mechanisms.

[kellan-simiotics]

If the target method relies on the value of message.sender, it's behavior will not be correct.

[zomglings]

If the target method relies on the value of message.sender, it's behavior will not be correct.

Good point, for example if the target method mints a token to msg.sender, it will be minted to the proxy contract and not to the original caller.