## Implementation destruction risk

**Severity**: Critical

Context: [`Implementation.sol#L17`](https://github.com/spearbit-audits/writing-exercise/blob/de45a4c5b654710812e9fa29dde6e12526fe4786/contracts/Implementation.sol#L17)

The Implementation contract is meant to be called by many deployed Proxy contracts through a delegatecall, and thus provide shared functionality to the proxies (wallets), while each proxy holds all of its state variables and tokens and approvals.
Although Implementation is supposed to only receive calls from proxies, nothing currently prevents any other kind of contract or even an EOA from calling its functions directly, with a simple call instead of a delegatecall.

It is particularly problematic in the case of `delegatecallContract(...)`, because this function delegatecalls any user-provided contract address. The called contract might contain malicious code, and because it is a delegatecall, it will execute in the context of the Implementation contract, with read-write access to its state and most notably, with the ability to selfdestruct the contract, leaving all users of the wallet protocol with broken wallets that will fail on every transaction, and no mechanism for the team to upgrade their proxy to a new implementation nor for the users to move their assets.

**Recommendation**: The issue can be avoided by leveraging the concept of Library, which is a special kind of solidity contract that among other peculiarities can only be called via delegatecalls, thereby negating the vulnerability described above.
Switching the keyword `contract` for `library` and removing the two `payable` keywords (because libraries can't receive ETH), is a sufficient and complete fix that does not affect the contract's features.