SOV Rewards and BitcoinOS as the Canonical Ledger

[Phrygian12]

How do you ensure people restake? I mean, people that committed to staking so they could collect sip 24 still are obligated, right?

I’m not against the idea, but 15million liquid SOV on the market could be harmful.

[interferenz]

Until yesterday I would have said that BitcoinOS would generate so much rewards that everyone would want to restake. But then OneDigit said on discord that BitcoinOS is not generating fees for SOV stakers - that it is going to be a free product for everyone to use and well yes then I would take that liquid SOV and dump if thats the case because what is the value of SOV if all we get is a 2-5% APY from DEX after the new SIP24 rewards run out if there are no more SOV to distribute? BitcoinOS was the holy grail of making SOV valuable but we are now giving that away for free?!?
So this only works if the enticement of staking SOV is big enough that this does not become a dump event and for that part of BitcoinOS transaction fees need to go to SOV stakers.

[Phrygian12]

So essentially, we are just hoping they restake?

[Martin_Adriaan]

to be sure that we’re on the same page, the proposal would be to set the penalty for early unstaking to 0 for a fixed period (so, the proposal would not be to unstake everyone and then hope they restake). in other words, anyone who does nothing will simply remain staked on Rootstock.

staking over at other chains / venues will presumably be incentivized in the same way that staking on rootstock is incentivized, by the value of governance of that implementation of Sovryn + collection of generated fees. the more ppl unstake at Rootstock and restake at other place, the more APR will go up for those that stay at Rootstock, so there is no real risk of Rootstock being abandoned. (btw, I think going multichain is very smart; each implementation will drive up demand for SOV and grow the community; while making Sovryn increasingly tech agnostic; across chains, I think much more SOV will end up being staked than currently).

[Phrygian12]

But SIP 24 rewards diminish over time, no? So people that staked right at the time of SIP 24 end would have gotten the highest amounts of there subsidies, without the obligation they committed to, while others would have gotten much less.

Like I said, not that I’m against it, but it would be unfair to all SOV stakers that staked previous to that and it would also create a large amount of liquid SOV which could destabilize the token price quickly.

And… If a bunch of people unstaked, and didn’t restake, it could have consequences for Bitocracy.

On this particular SIP, I just wouldn’t vote, because I’m not quite confident I can see all the positive and negative effects.

[one_digit]

Before anyone simply assumes this is a reasonable summary of what I said, I encourage you to read the dialogue on the general channel in discord as well as my brief statement here:

BitcoinOS Fees for SOV Stakers?

Thanks for raising this here. I hope @yago and others will weigh in with greater clarity. I think you’ll be hard-pressed to document that I said “there will be no fees except from DEX.” That is your logical inference from what I said, not exactly what I actually said. Instead, I’m trying to focus on stating what is clear. That is, some of the value accrued by BitcoinOS will be directed to SOV stakers. The wiki says: The SOV token is the governance token of Sovryn modules and jurisdictions in…

[one_digit]

@Martin_Adriaan @Phrygian12 @interferenz @capitalist42 @Hyde @AllRoadsLeadToSovryn

I’ve written up a simple plan on the SOV rewards SIP forum post and also tried to clarify an aspect of Yago’s SIP proposal. I think the plan is largely in keeping with what people are aiming for here but deals better with the post-BitcoinOS reality.

Would be good to continue the conversation over there, since it’s a more recent post.

SIP Proposal: SOV Rewards

There seems to be a lot of confusion about rSOV on Rootstock and SOV on BitcoinOS and so-called transferring. As I see it, there is only one sensible way to transition canonical SOV to BitcoinOS. At the same time, it’s the simplest, most obvious, and fairest way to do it. The Plan Set a specific timet for the transition. When the transition time arrives, the ownership of all SOV on Rootstock—including liquid, staked, and vesting SOV—is recorded. Using that record, the exact same alloca…

[Martin_Adriaan]

@one_digit

Would be good to continue the conversation over there, since it’s a more recent post.

I think it’s best if the community is a little systematic in where we have the bitocracy conversations imo; if we keep it on the Forum, we have a complete record of the discussions, so that we can refer back to it, ppl joining can trace back the decision making, and so on.

[Martin_Adriaan]

I think there is a lot to say for the plan as you outline it. It is how I understoodYago’s reissue plan, with the only difference that you propose to reissue all SOV, not just the special non-transferrable SOV rewards (I understood Yago’s proposal to restrict the reissue to the reward SOV, but might be wrong). Just comparing these two proposals, I prefer your (@one_digit’s) suggestion to reissue all SOV, on the Sovryn rollup within BitcoinOS, as it gives incentive to all ways of holding SOV.

But here is a simple question: how does this cover the additional plan of going multichain? Say that besides the move to the Sovryn Rollup (within BitcoinOS), Sovryn also wants to deploy the dapp on Stacks (mere speculation). It’s hard to iterate your plan. Which would we copy then, Sovryn on Rootstock or Sovryn on the Sovryn Rollup? Would we just continue creating SOV1, SOV2, SOV3, etc. across chains? Seems unsustainable to me, and it’s hard to make new deployments add value across all old deployments. I would repeat that the optimal approach would be a procedure that can be iterated easily, and that adds value to all previous iterations.

[Martin_Adriaan]

@SIP Proposal: SOV Rewards

In fact, bridged SOV would make no sense because that would make the underlying “real” token remain on Rootstock.

I don’t think this is true in general.

That is indeed true for many kinds of bridges, such as for lock+mint and lock+unlock bridges, the locked SOV would indeed have a claim to be the “real” token as you say. But your claim does not apply to all types of bridges. In particular, in the case of a burn+issue bridge, I don’t think it’s true that the “real” token remains on Rootstock, as SOV on Rootstock gets burned, and only complete destruction of the rSOV creates SOV over at the other chain (compare teleburning NFTs from ethereum to bitcoin, original NFT destroyed → Ordinal on Bitcoin issued).

[one_digit]

The reference I gave was to another forum post.

[one_digit]

You are correct. I was only thinking of lock+mint.

[one_digit]

I don’t think cloning bitocracy over and over is desirable. Yago says BitcoinOS would become canonical and that it would be a one-time process. I’m not sure how that works with multi-chain.

Are you suggesting that your proposal works with multi-chain? Can you explain how it would be different while retaining BitcoinOS as the canonical ledger?

[Phrygian12]

You know, I didn’t think of this (multichain) in the other discussion, but it’s also an issue for Cex listings, which from what I understand, is in the works.

As far as multichain, the tokens can be bridged to new Sovryn Dapp, on the other chain, right? So the old and new tokens could be bridged, which doesn’t really seem to change anything. I don’t know how much work making bridges are though, so it’s hard for me to speak on the matter.

However, having 2 different SOVs (rSOV and SOV) on cex sounds less than ideal, and if rSOV is more popular on the Cex, it could give advantage, and inversely, disadvantage canonical SOV.

[Martin_Adriaan]

sorry was on my phone and got lost between the different threads; my fault

[Martin_Adriaan]

@one_digit

Are you suggesting that your proposal works with multi-chain? Can you explain how it would be different while retaining BitcoinOS as the canonical ledger?

Yes I would indeed suggest that a burn+issue bridge works with multichain as well. About a canonical ledger, I’m not yet convinced that it is needed, nor that there should be a top-down decision about what is and isn’t canonical (perhaps we can let the market decide, let’s see which Sovryn is the most stable and functioning and sees the most adoption?)

The main difference is that for each new deployment of the Sovryn Dapp, there is new demand for the same SOV. This means that overall value of SOV gets more solid with each new deployment, as this value becomes distributed over different chains / rollups. I think this has advantages over duplicating the SOV token, including security, community cohesion, UX/simplicity.

This is an honest question and not meant in a snarky way: but what do you think would happen with the rSOV token and the Sovryn dApp on Rootstock after the new SOV has been issued on the Sovryn Rollup? Would it be seen as ‘old SOV’, or ‘less real SOV’? Why should we opt for a design that creates this break between ‘old’ and ‘new’ SOV? I’d really prefer a design where everyone just gets a choice in whether they want to move their SOV over at all, and if so, how much.

[AllRoadsLeadToSovryn]

What I like about @one_digit 's proposal is the simplicity. SOV : rSOV remain at a 1:1 ratio. If BitcoinOS is successful and good old Rootstock becomes slowly obsolete it won’t really matter since ‘success’ means there will be sufficient revenue streams and therefore a portion for each staker. But on the other hand if no one knows which side is successful - the old or the new one - and you had to decide how much to ‘move over’ - it all sounds like a gamble to me. So imo the presented solution seems to be the logic one. No riddles for the staker. (except the one where the rewards come from ultimately on BitcoinOS but let’s open that can when we know more).

[lactarius]

Maybe these questions have been asked before, I still have the doubts.

1. Can we imagine that in the same way there is 1 btc for each rbtc, there will be one bsov for each rsov, one bsov for each esov, and so on in other blockchains ? That is, in a universe of 100 million tokens there could, for example, be 50 million in BOS, 25 million in RSK, 10 million in the Ethereum blockchain, and 15 million in other blockchains, should we imagine it like that ?
   Or on the contrary, should the hundred million be born in BOS entirely and be the collateral for tokens still in other blockchains?

2. Will there be only two possible ways to get bsov before Q4: 1) early stake rewards and 2) migration ?

3. What are the advantages of having bsov for early stake rewards compared to bsov received during the migration event?

[one_digit]

I think all those things are still under discussion.