Fraxtal Incentives Delegation

Incentives are allocated based on the activity of an address. Some addresses, like smart contracts, are unable to interact with the allocated incentives wihtout implementing the interaction upon their deployment. One of the major issues with this is that we are yet to announce how the FXTL points will be claimed and that adding additional functionality to the smart contracts increases their size.

Delegating the earned incentives using the DelegationRegistry allows for earned incentives to be allocated to an address that can interact with the claim process, be that an externally owned account, smart account, or a multi-signature wallet.

The delegations for externally owned accounts can be done directly in the DelegationRegistry.

Delegations are not recursive. This means that if you delegate to another address, and that address delegates to another one, your earned incentives will be allocated to the address you delegated to, not to the one that address delegated to.

DelegationRegistry addresses

The DelegationRegistry can be found in the Fraxtal mainnet as well as Fraxtal testnet:

Setting delegations for smart contracts

Instead of increasing your smart contract's size by adding support for DelegationRegistry, the delegations can be set during deployment.

To set the delegation during deployment, you can add the following two lines of code to your constructor or initializer:

    constructor(address delegationRegistry, address initialDelegate) {
        delegationRegistry.call(abi.encodeWithSignature("setDelegationForSelf(address)", initialDelegate));
        delegationRegistry.call(abi.encodeWithSignature("disableSelfManagingDelegations()"));
    }

⚠️WARNING: If you smart contract supports arbitrary calls to be transmitted from it, you have to disable delegation management alltogether.⚠️

Using an arbitrary call, the attacker could modify the delegation settings of your smart contract and receive the incentives that it earns. In order to disable the delegation management, you can add the following call to your constructor:

        delegationRegistry.call(abi.encodeWithSignature("disableDelegationManagement()"));

This call will preserve the delegation settings set in the first call, but won't allow delegation settings to be changed by the delegate, Flox contributor, or your smart contract. Doing so ensures you are still able to accumulate the incentives without the danger of an attacker stealing them.

The full constructor for a smart contract that is at risk of arbitrary call hijacking should look like this:

    constructor(address delegationRegistry, address initialDelegate) {
        delegationRegistry.call(abi.encodeWithSignature("setDelegationForSelf(address)", initialDelegate));
        delegationRegistry.call(abi.encodeWithSignature("disableSelfManagingDelegations()"));
        delegationRegistry.call(abi.encodeWithSignature("disableDelegationManagement()"));
    }

Once an address sets the delegation for themselves, the delegatee is not allowed to manage the addresses' delegations unti the address disables self management of delegations. This is why the two calls are needed. The first one sets the delegatee and the second one disables self management of delegations for the smart contract.