Advanced Account Management

Chainflip does not directly support full account delegation, however it provides some advanced account management features that can be used by delegation service providers to provide additional guarantees to their users.

This process looks like this:

1. User A (Operator) sets up a State Chain account and an associated validator node.
2. User B (Delegator) has an Ethereum wallet with $FLIP they want to "delegate" to the Operator's node.
3. The Operator can bind the Delegator's Ethereum address as their "Redeem Address", which is an irreversible action. See Redeem Address Binding
4. Funds can only be redeemed to the Delegator's Ethereum address from now on - including future rewards but only the Operator can trigger any redemption claims. This means a degree of trust is still required.

Redeem Address Binding

Any account may be explicitly bound to a single redemption address. Henceforth, any redemption request from that account can only redeem to this exact address.

Example #1:

The account cFc00Ld00d is bound to the redeem address 0xdeadbeef. This was a bad idea since it's unlikely that cFc00Ld00d knows the private key for 0xdeadbeef, so his or her funds are effectively permanently locked. Do not do this.

Example #2:

A liquid staking provider wants to allow users to pool their $FLIP through a smart contract on Ethereum, to then fund a validator account. They bind their validator account to the smart contract address. This binding is permanent and irrevocable, so users can now rest assured that there is no way the pooled funds can be redeemed to any other address.

In order to bind a redemption address, use the chainflip-cli. Log on to the node that contains the keys to the account for which you want to bind a redemption address.

In order to check if the account is currently bound to a redemption address:

chainflip-cli get-bound-redeem-address

In order to permanently bind a redeem address:

chainflip-cli bind-redeem-address <ETH_ADDRESS>

Redemption Execution Address Binding

Similar to the above, redemptions can be restricted such that only a single specific Ethereum address can be the executor of a redemption.

In order to bind an executor address, proceed as above using the chainflip-cli.

Query for any currently bound address like so:

chainflip-cli get-bound-executor-address

In order to permanently bind an executor address:

chainflip-cli bind-executor-address <ETH_ADDRESS>

Now, if you want to redeem, you must explicitly provide this address as the executor:

chainflip-cli redeem --exact 15314 <REDEEM_ADDRESS> <EXECUTOR_ADDRESS>

This can also be done via Auctions App > My Nodes (opens in a new tab).

Restricted Balances

Certain funding sources are considered restricted, such that funds originating from that source can only be redeemed back to whence they came. In order to enforce this, we track the amount of funds added from restricted addresses and ensure that the account always has enough funds to cover its obligations to these addresses.

This is used primarily to enforce vesting restrictions. Some of the $FLIP tokens in existence may be locked in a vesting contract that controls when the tokens can be freely accessed. In the meantime, we still would like the tokens to be used productively in the protocol. However this is not possible without restricting the funds, since otherwise the vesting restrictions can be trivially circumvented by funding an account and immediately redeeming to any other address.

Example:

The address 0xabc is marked as restricted because it is a smart contract holding $FLIP for early investors.

Imagine an account has 1,000 $FLIP funded from address 0xabc and earns a return of 10 $FLIP after some period of time. Subject to other restrictions (bond etc.) those 10 $FLIP can be redeemed to any address. Any more than that can only be redeemed from the restricted balance of 1,000 $FLIP, and only to the originating address 0xabc.

In case of Restricted addresses the limitation of Redeem Address Binding and Redemption Execution Address Binding are not applied. Withdrawals to restricted addresses ignore any address bindings.