VersaProxy is a proxy contract that supports multiple versions of a logic contract and routes calls to the correct version using a given version number.

• The proxy can route calls to the correct logic contract using a given uint256 version number. This allows users and developers to manage migrations more smoothly.

• Thanks to ERC-7201 (Namespaced Storage Layout), developers can choose to have multiple versions of the logic contract working on the same storage slot or reset the state by changing the storage slot used by the new version of the logic contract.

• By convention, all functions called through VersaProxy must have <uint256 version> as their first parameter, even if the version number is not used by the logic contract.

• Libraries cannot be used as-is and must be rewritten to include the version number as the first parameter of proxiable functions.

Smart contracts are immutable—once deployed, they cannot be updated to fix bugs or add features. Until now, when you wanted to change the logic of your decentralized application, you basically had two options:

1. Deploy a new version of your smart contracts and update all frontends to use the new version, or juggle between different contract versions.

   The two major drawbacks of this approach are:
   a. All frontends must be updated at once, which can be a major issue in a truly decentralized environment.
   b. Migrating the state/storage of a smart contract is neither easy nor free.

2. Use OpenZeppelin upgradeable contracts, where a proxy contract delegates calls to a logic contract. When developers deploy a new version of the logic contract, they call a special function on the proxy contract to update the logic contract being used.

   A key benefit of this pattern is that the contract state and storage are preserved, as they belong to the proxy. However, the major drawback is the lack of soft migration:

   • If the second version introduces breaking changes, users who haven't upgraded in time may find their clients broken.

With both approaches, users are forced to migrate immediately when the developer pushes an update. However, in some cases, this is not feasible, as not all users can update their clients simultaneously.

VersaProxy was developed to provide an alternative way to manage smart contract upgrades with a smooth transition between versions. Developers have more flexibility to upgrade their smart contracts while allowing users to migrate at their own pace without breaking their clients.

Not everything will be possible, and not every option will be the right one.

Be cautious.

VersaProxy follows only two conventions:

1. Use ERC-7201 Namespaced Storage Layout in your logic contract. This gives you fine-grained control over whether different logic contract versions share the same storage slot or not.

2. All functions of the logic contract that are called through the proxy must include a uint256 parameter as the target version number, even if the parameter is not used by the logic contract.

The fallback function of VersaProxy scans the calldata to automatically extract and use the target version number. It does this by:

• Skipping the function selector.

• Reading a 32-byte word that, by convention, represents the target version number.

The rest functions similarly to OpenZeppelin's proxy contract.

   /**
     * @dev Fallback function that proxies calls to the target implementation by using a version number
     * provided in the first 4 bytes of the calldata. The calldata will be forwarded to the implementation contract
     * withtout the first 4 bytes.
     */
    fallback() external payable {
        
        // Get the target version number as a uint256 from the first parameter in calldata.
        // 
        // The convention is all proxied functions in the implementation contracts MUST have the version number as the first parameter.
        // In order to achieve this, we need to skip the function selector (4 bytes) and read the first parameter as a uint256.
        uint256 version;
        assembly {
            // Extract the first parameter (version as uint256) from calldata
            version := calldataload(4)
        }

        // Get the implementation address for the provided version
        require(version < _nextVersion, "Unsupported version");
        require(_enabledVersions[version], "Version not enabled");
        address implementation = _implementations[version];
        //console.log("Target version is:", version);
        //console.log("Target implementation is:", implementation);

        // Regular delegatecall to the implementation contract as per Proxy pattern
        assembly {
            // Copy calldata to memory
            calldatacopy(0, 0, calldatasize())

            // Delegatecall to the implementation contract
            let result := delegatecall(gas(), implementation, 0, calldatasize(), 0, 0)

            // Copy returndata to memory
            returndatacopy(0, 0, returndatasize())

            // Handle success or failure
            switch result
            case 0 { revert(0, returndatasize()) }
            default { return(0, returndatasize()) }
        }
    }

Below is an example of a smart contract function that has been rewritten to be used through VersaProxy (see source code: VersaOwnableV0.sol).

    /**
     * @param version Not used here. The version number use dby VersaProxy to route the call (convention)
     * @dev Returns the address of the current owner.
     */
    function owner(uint256 version) public view virtual returns (address) {
        VersaOwnableV0Storage storage $ = _getVersaOwnableV0Storage();
        return $._owner;
    }

The next steps will be to create a public code repository providing the source code of VersaProxy, its tests, rewritten contract libraries, and examples.

VersaProxy is a proxy contract that supports multiple versions of a logic contract and routes calls to the correct version using a given version number.

• The proxy can route calls to the correct logic contract using a given uint256 version number. This allows users and developers to manage migrations more smoothly.

• Thanks to ERC-7201 (Namespaced Storage Layout), developers can choose to have multiple versions of the logic contract working on the same storage slot or reset the state by changing the storage slot used by the new version of the logic contract.

• By convention, all functions called through VersaProxy must have <uint256 version> as their first parameter, even if the version number is not used by the logic contract.

• Libraries cannot be used as-is and must be rewritten to include the version number as the first parameter of proxiable functions.

Smart contracts are immutable—once deployed, they cannot be updated to fix bugs or add features. Until now, when you wanted to change the logic of your decentralized application, you basically had two options:

1. Deploy a new version of your smart contracts and update all frontends to use the new version, or juggle between different contract versions.

   The two major drawbacks of this approach are:
   a. All frontends must be updated at once, which can be a major issue in a truly decentralized environment.
   b. Migrating the state/storage of a smart contract is neither easy nor free.

2. Use OpenZeppelin upgradeable contracts, where a proxy contract delegates calls to a logic contract. When developers deploy a new version of the logic contract, they call a special function on the proxy contract to update the logic contract being used.

   A key benefit of this pattern is that the contract state and storage are preserved, as they belong to the proxy. However, the major drawback is the lack of soft migration:

   • If the second version introduces breaking changes, users who haven't upgraded in time may find their clients broken.

With both approaches, users are forced to migrate immediately when the developer pushes an update. However, in some cases, this is not feasible, as not all users can update their clients simultaneously.

VersaProxy was developed to provide an alternative way to manage smart contract upgrades with a smooth transition between versions. Developers have more flexibility to upgrade their smart contracts while allowing users to migrate at their own pace without breaking their clients.

Not everything will be possible, and not every option will be the right one.

Be cautious.

VersaProxy follows only two conventions:

1. Use ERC-7201 Namespaced Storage Layout in your logic contract. This gives you fine-grained control over whether different logic contract versions share the same storage slot or not.

2. All functions of the logic contract that are called through the proxy must include a uint256 parameter as the target version number, even if the parameter is not used by the logic contract.

The fallback function of VersaProxy scans the calldata to automatically extract and use the target version number. It does this by:

• Skipping the function selector.

• Reading a 32-byte word that, by convention, represents the target version number.

The rest functions similarly to OpenZeppelin's proxy contract.

   /**
     * @dev Fallback function that proxies calls to the target implementation by using a version number
     * provided in the first 4 bytes of the calldata. The calldata will be forwarded to the implementation contract
     * withtout the first 4 bytes.
     */
    fallback() external payable {
        
        // Get the target version number as a uint256 from the first parameter in calldata.
        // 
        // The convention is all proxied functions in the implementation contracts MUST have the version number as the first parameter.
        // In order to achieve this, we need to skip the function selector (4 bytes) and read the first parameter as a uint256.
        uint256 version;
        assembly {
            // Extract the first parameter (version as uint256) from calldata
            version := calldataload(4)
        }

        // Get the implementation address for the provided version
        require(version < _nextVersion, "Unsupported version");
        require(_enabledVersions[version], "Version not enabled");
        address implementation = _implementations[version];
        //console.log("Target version is:", version);
        //console.log("Target implementation is:", implementation);

        // Regular delegatecall to the implementation contract as per Proxy pattern
        assembly {
            // Copy calldata to memory
            calldatacopy(0, 0, calldatasize())

            // Delegatecall to the implementation contract
            let result := delegatecall(gas(), implementation, 0, calldatasize(), 0, 0)

            // Copy returndata to memory
            returndatacopy(0, 0, returndatasize())

            // Handle success or failure
            switch result
            case 0 { revert(0, returndatasize()) }
            default { return(0, returndatasize()) }
        }
    }

Below is an example of a smart contract function that has been rewritten to be used through VersaProxy (see source code: VersaOwnableV0.sol).

    /**
     * @param version Not used here. The version number use dby VersaProxy to route the call (convention)
     * @dev Returns the address of the current owner.
     */
    function owner(uint256 version) public view virtual returns (address) {
        VersaOwnableV0Storage storage $ = _getVersaOwnableV0Storage();
        return $._owner;
    }

The next steps will be to create a public code repository providing the source code of VersaProxy, its tests, rewritten contract libraries, and examples.