In the original IPC model, the entire subnet hierarchy adopted the parent's coin for both circulating supply and stake. A few months ago, we introduced the ability to appoint an ERC20 token in the parent as the subnet's native circulating supply by popular request. See the supply sources spec.
However, the stake/collateral power mode for determining consensus weights and securing consensus remained untouched. When a subnet selects this mode at deployment time, validators can only deposit collateral in the parent's native coin. For L2s rooted on the Filecoin L1, that's FIL. L3+ anchored on subnets with alternative supply sources will inherit the native coin of their respective parent for collateral deposits (which before adding the aforementioned feature could only be the root's coin).
Note that consensus staking is a distinct path from application staking, e.g. Fluence uses FLT for compute provider staking. And this is managed entirely as business logic (actors or contracts) inside the subnet.
Relying on FIL for consensus stake is desirable because its value is relatively stable and liquid, it benefits from a broad tokenholder base that subnet operators can tap into through delegated staking, and it's relatively well supported in DeFi tools. In addition, relying on recently launched tokens (which are often volatile) for consensus security may be risky.
However, several adopters (e.g. Fluence and Akave) are interested in token-bound staking. That is, adopting their ERC20 tokens on the parent as consensus validator stake in their subnets. To mitigate concerns about value volatility, it may make sense to bootstrap a subnet with PoA, and later switch to PoS when the value of the token is stabilized.
Arguments supporting this feature:
Unnecessary complexity to force users and validators to deal with two coins/tokens (FIL and network token).
Acquiring FIL to deposit as collateral may not be financially accessible to many, whereas using the network's token is relatively simple (e.g. leveraging Foundation treasury, validator grants, etc.)
Easier to reason through cryptoecon reward/incentive/penalty loops across all stake variants (consensus, application) in a single currency.
It's also worth noting that consensus validator rewards are simplified. Given that a subnet cannot mint FIL to reward validators in the currency they staked, there were two options: (a) endow a reward pool with FIL from which rewards are disbursed at the parent, (b) reward validators in the subnet's token (either in the parent or the child). With (b), the validator is exposed to FIL (and slashed in FIL) but earns in the custom token, which makes the profitability dependent on the FIL/TOK value.
With token-bound validator collateral, validator economics are detached from FIL and are entirely the responsibility of the subnet operator. However, this feature introduces early fragmentation across subnets, and hinders future plans to launch generic IPC validator networks and services, which I know some adopters are really keen to have.
Delegated staking
Another request that has come up in the past is delegated staking. That is, enabling token holders to route funds for a validator to use as collateral, enjoying a pre-negotiated yield or revenue share with the validator.
Token-bound validator collateral
In the original IPC model, the entire subnet hierarchy adopted the parent's coin for both circulating supply and stake. A few months ago, we introduced the ability to appoint an ERC20 token in the parent as the subnet's native circulating supply by popular request. See the supply sources spec.
However, the stake/collateral power mode for determining consensus weights and securing consensus remained untouched. When a subnet selects this mode at deployment time, validators can only deposit collateral in the parent's native coin. For L2s rooted on the Filecoin L1, that's FIL. L3+ anchored on subnets with alternative supply sources will inherit the native coin of their respective parent for collateral deposits (which before adding the aforementioned feature could only be the root's coin).
Note that consensus staking is a distinct path from application staking, e.g. Fluence uses FLT for compute provider staking. And this is managed entirely as business logic (actors or contracts) inside the subnet.
Relying on FIL for consensus stake is desirable because its value is relatively stable and liquid, it benefits from a broad tokenholder base that subnet operators can tap into through delegated staking, and it's relatively well supported in DeFi tools. In addition, relying on recently launched tokens (which are often volatile) for consensus security may be risky.
However, several adopters (e.g. Fluence and Akave) are interested in token-bound staking. That is, adopting their ERC20 tokens on the parent as consensus validator stake in their subnets. To mitigate concerns about value volatility, it may make sense to bootstrap a subnet with PoA, and later switch to PoS when the value of the token is stabilized.
Arguments supporting this feature:
It's also worth noting that consensus validator rewards are simplified. Given that a subnet cannot mint FIL to reward validators in the currency they staked, there were two options: (a) endow a reward pool with FIL from which rewards are disbursed at the parent, (b) reward validators in the subnet's token (either in the parent or the child). With (b), the validator is exposed to FIL (and slashed in FIL) but earns in the custom token, which makes the profitability dependent on the FIL/TOK value.
With token-bound validator collateral, validator economics are detached from FIL and are entirely the responsibility of the subnet operator. However, this feature introduces early fragmentation across subnets, and hinders future plans to launch generic IPC validator networks and services, which I know some adopters are really keen to have.
Delegated staking
Another request that has come up in the past is delegated staking. That is, enabling token holders to route funds for a validator to use as collateral, enjoying a pre-negotiated yield or revenue share with the validator.
See more here: #1100.