17 sats \ 2 replies \ @SequentiaSEQ OP 6 Jul \ parent \ on: New Bitcoin sidechain (Sequentia) launches demo signet bitcoin
Your first question is a fairly good one. Unfortunately, we simply don't know the answer yet. There's still some time before we are ready to go live, and hopefully by then we can assemble a federation that's of equally reputable members as Liquid's, or maybe even share some of the same federation members...
As for the second question, I think there might be some misunderstanding. While there is no "native" peg that's required to pay transaction fees, you can still issue pegged BTC on Sequentia, and it can work exactly like L-BTC does on Liquid. The difference is that:
- You can propose transaction fees using any token issued on Sequentia, it doesn't need to be a specific pegged Bitcoin, and it can actually be any other token, such as USDT
- Unlike Liquid or existing sidechains, Sequentia will support making p2p swaps with real BTC (on the mainchain or on LN) in real-time, so you won't necessarily need to ever have any kind of representation of BTC on the sidechain.
There is no inflation because there is no native coin, block producers are only rewarded with the transaction fees they collect (in whatever tokens they're willing to accept), there aren't any block rewards on top of that.
how will we know in advance what fee the block producers will accept? if it is some illiquid shitcoin, there may not me a market rate. on liquid the fee rate is a standard 0.1 sat/vB.
reply
There will of course be infinite different ways for wallets to calculate fee estimates and some may prove more accurate than others, but in the case of tokens which are often used to pay for tx fees, looking at recent on-chain data should prove to be a sufficiently effective method.
What's important is how block producers will choose which tokens they're willing to accept and at what rate. To that end, we've developed a "price server" software which nodes can use to connect to an external data source such as a CEX API or a DEX Oracle such that they can designate a reference unit, calculate the prices of different assets in this reference unit (and apply weights/multipliers depending on factors such as liquidity), and update their list of accepted assets and rates accordingly.
if it is some illiquid shitcoin, there may not me a market rate
That's exactly right. When transferring an illiquid shitcoin, you may also need a more liquid token to pay tx fees with. In such an environment it is obviously very important to be able to bump transactions that get stuck due to the proposed asset, and even change the proposed tx fee asset using RBF - we've implemented a way to do that and it's shown in the demo!
reply