I took a deeper look at the
Nomic protocol to describe the incentives governing it here. Nomic is currently functional, but the sidechain functionality is limited to 21
BTC before an audit has been concluded. There is also a fork called
OraiDex or OraiChain - they seem to be more active with development, but be cautious like with every new project
The whitepaper is
here.
Nomic is to my knowledge the most advanced project which has implemented a
dynamic federation. This means: The sidechain is run by a set of validators which also operate a Bitcoin client and vote for every valid peg-in and peg-out. In the case of Nomic, the sidechain is controlled by a proof-of-stake algorithm, i.e. the validators are also probably those with most stake in the utility token. This makes the incentive structure easier than in merged-mined sidechains if we assume that the stakers are interested in their token's value (what
Vitalik Buterin called once "altruism-prime"), but of course if this is not the case then the typical potential vulnerabilities of PoS consensus are also present in Nomic.
The Nomic stakers are also
signatories of a multisig address called
Reserve Wallet on the Bitcoin main chain. They have to pay a collateral which will be slashed if they misbehave. Via Schnorr signatures and MAST trees up to 1000 signatories can be supported in a so called
reserve script controlling the coins. This set of signatories is
regularly updated, see below.
Nomic signatories have to vote with a 2/3 supermajority for each transaction they carry out. The voting (through the reserve script) occurs in two ways: via a key path using the Musig2 Taproot multisig algorithm containing a "standard" set of signatories, or with a fallback script using a standard multisignature scheme, if one of the signatories in the key path becomes unresponsive.
How does this work in practice?1. When a Bitcoin user wants to
peg-in the coins (i.e. deposit coins on the mainchain to receive sidechainBTC), he transfers the
BTC to the Reserve Wallet via a P2TR transaction with an additional OP_RETURN output containing the sidechain address the user wants the sidechain coins to be deposited to, and a timelocked "reclaim" scriptpath for the case the sidechain signatories are unresponsive, then the user can reclaim the funds after a number of blocks (144 are recommended according to the whitepaper).
The sidechain nodes build a deposit proof from the deposit transaction and publish it in the sidechain network. This will later enable the user who deposited Bitcoins create sidechainBTC on the Nomic sidechain.
2. When a sidechain user wants to
peg-out, he builds a transaction on the Nomic sidechain burning the sidechainBTC and requesting withdrawal to a Bitcoin address.
3. Periodically, the signatories publish
checkpoints on the Bitcoin main chain. This allows to process deposits, pre-process withdrawals and update the signatory set if the set of validators/signatories has changed on Nomic. Checkpoints are made of up to three connected transactions:
- Deposit Collection Transaction: The signatories spend all deposit utxos to a script containing the current sidechain reserve script. This transaction is only carried out if since the last checkpoint deposits have been made.
- Checkpoint Transaction: This transaction is always carried out, even without deposits. It collects the UTXO from the last checkpoint transactions and, if deposits were made, the UTXO from the Deposit Collection Transaction. The coins are spent to the Reserve script, and if withdrawals have been made, then a second UTXO is spent to which will pay out the withdrawals. The main purpose of this transaction is to update the set of signatories (stakers).
- Disbursal Transaction: This transaction pays out pending peg-outs or withdrawals from the second UTXO of the Checkpoint Transaction. It is only carried out if there were withdrawals since the last checkpoint.
In addition an Emergency Disbursal Transaction is signed, which would send the whole reserve to the current sidechainBTC holders. This transaction has a long Locktime. It protects sidechain holders from a "liveness failure", i.e. when the signatories become unresponsive for a long time. At the same time it slashes all collaterals on the sidechain, so the signatories are incentived to always create checkpoints regularly.
As far as I interpret the whitepaper, the Deposit Collection Transaction is still signed by the "old" set of signatories (where the depositors spent to), while from the Checkpoint transaction on, the reserve script contains the "new" set of signatories and these also sign the transaction.
I also interpret that after a deposit, the sidechainBTC will be created only after another checkpoint (more precisely: the Deposit Collection transaction) has occurred, to prevent the depositors to cheat, create sidechainBTC and then spending the coins of the "reclaim" script path (see above).
The peg-out process depends on the behavior of the signatories before the Disbursal Transaction is built. This means that, before voting positively for a withdrawal, the nodes have to check that the withdrawal request corresponds to a legitimate "burn" on the sidechain and that its ancestry is correct (this should of course be validated continuously by the PoS validators).
At a first glance the scheme looks reasonable. It does not protect 100% from a liveness failure but as long as the PoS incentive process works correctly the sidechain should also work as expected. In the case of a liveness failure the coins will be returned and the signatories/stakers will be punished for that failure. This means that the system depends heavily on the Nomic tokens having at least some value to make punishing effective, but again, that is common to PoS systems. Another reason the utility token should be valuable is that otherwise the signatories could be contempted to "pause" their participation in periods with high Bitcoin fees (e.g. around Bitcoin's last halving).
The big con is, of course like in most L2 projects, the premine of the utility token NOM. However, at this moment the NOM token is not traded at any exchange, so it's not the typical pump and dump where the utility token is launched and dumped before the main functionality is added. And of course it's possible to think about a no-premine fork
Nomic also doesn't provide a tail emission for Bitcoin miners via merge-mining, a topic we discussed in several threads which could be a long term solution for Bitcoin's "Year 2140 problem". Possibly the protocol could however be changed in a way to make that possible, for example if the sidechain block "production" is changed to a PoW/PoS model.