Top 10 FTSO Data Provider Vote Delegation Index!

[brianwalden]

I created a data provider index using multiple wallets to delegate your FTSO vote equally (10% each) to the current top 10 data providers.

UPDATE: This doesn't work. It appears things have changed between the whitepaper and the implementation.

Why would you want to do this? I think the first half-week of rewards has had much more disparity than we were expecting. What we don't know is what the week to week performance will look like. This week A-FTSO, Scandinodes, and Bifrost seemed to pull away from the pack and do much better than the rest. Will that keep up, or will next week see new leaders while they fall back? And even if we could predict that they'd be the top three every week, what happens if everyone apes into them, putting them over the 10% cap and then your rewards are limited. Spreading your votes out means you're hopefully sacrificing the extremes of a really good or bad week to be consistently good from week to week.

Ok, so let's slow down and explain how this works. I used flaremetrics.io/ftso to get the top 10 rewards earners (BTW, although that site has no branding I believe it's created and run by FTSO_AU's Tim Rawley). Then I created a series of wallets so I could delegate votes among each of them. For example the Top 10 wallet delegates one tenth of its votes to tenth place FTSO_AU, and then the rest to the Top 9 wallet. The Top 9 Wallet delegates one ninth of its votes to ninth place Sun-Dara and the rest to the Top 8 wallet and so on. The thing I geek out over is that the whole system is recursive. If you want an index of the top 5 providers instead of 10, delegate your votes to the Top 5 wallet. If someone wants to create a Top 20 index, they can set up the wallets for the Top 20 down to 11 and then have the Top 11 wallet point at my Top 10 and the whole thing will just work together seamlessly.

UPDATE: This doesn't work. It appears things have changed between the whitepaper and the implementation.

Edited October 8, 2021 by brianwalden

[Guest]

I'm hoping to spend some time looking into these contracts myself and so I'm not joining this right now, but I appreciate your initiative. I'll wait for a couple of epochs to see the results of your work before I tip you a bit, but wanted to check - is your tip wallet an SGB address ?

[brianwalden]

40 minutes ago, Ripley said:

I'm hoping to spend some time looking into these contracts myself and so I'm not joining this right now, but I appreciate your initiative. I'll wait for a couple of epochs to see the results of your work before I tip you a bit, but wanted to check - is your tip wallet an SGB address ?

Yes, Songbird. And just to clarify, they're not smart contracts. I just set up ordinary wallets. No programming involved.

But yeah, the wise thing to do is to wait and let me be the guinea pig. We should know if they're working on Saturday.

[jbjnr]

Dear @brianwalden- I have delegated some of my token to the Top 5 wallet for testing purposes. You will be rewarded in the event of a successful test.

I wonder if the delegation is truly transitive. If wallet A delegates to wallet B and B to A, we create a tiny cyclic graph. This would be trivial to detect, but larger cycles can become tedious to test for. I wonder if it's worth creating a graph of wallets with a circular loop in them and seeing if the network handles it gracefully. (Ideally it would check for this when performing the delegation and produce a transaction failed if a loop is introduced - either backwards or forwards wrt the current transaction - by which I mean that if you change one of your top 4,3,2 wallets to point back to mine after I have set mine to your top 5, 6, 7 etc, then it should fail). There's a potential race condition on delegation setting too, if I create dozens of transactions all setting delegations to related wallets and they all go into the same block and cycles are introduced or broken depending on the order they are applied. I wonder if this stuff has been tested for ....

[brianwalden]

1 minute ago, jbjnr said:

Dear @brianwalden- I have delegated some of my token to the Top 5 wallet for testing purposes. You will be rewarded in the event of a successful test.

I wonder if the delegation is truly transitive. If wallet A delegates to wallet B and B to A, we create a tiny cyclic graph. This would be trivial to detect, but larger cycles can become tedious to test for. I wonder if it's worth creating a graph of wallets with a circular loop in them and seeing if the network handles it gracefully. (Ideally it would check for this when performing the delegation and produce a transaction failed if a loop is introduced - either backwards or forwards wrt the current transaction - by which I mean that if you change one of your top 4,3,2 wallets to point back to mine after I have set mine to your top 5, 6, 7 etc, then it should fail). There's a potential race condition on delegation setting too, if I create dozens of transactions all setting delegations to related wallets and they all go into the same block and cycles are introduced or broken depending on the order they are applied. I wonder if this stuff has been tested for ....

I've wondered about this too. Same thing with XRPL hooks. What if Wallet A forwards all payments received to Wallet B and Wallet B forwards all payments received to Wallet A?

The good news is, if you're sophisticated enough to delegate to my Top 5 wallet, you're sophisticated enough to test this out yourself. Get two wallets and see what happens if you create a loop between them. If you break Songbird, they'll probably give you a reward for finding it before Flare launches.

[jbjnr]

19 minutes ago, brianwalden said:

I've wondered about this too. Same thing with XRPL hooks. What if Wallet A forwards all payments received to Wallet B and Wallet B forwards all payments received to Wallet A?

The good news is, if you're sophisticated enough to delegate to my Top 5 wallet, you're sophisticated enough to test this out yourself. Get two wallets and see what happens if you create a loop between them. If you break Songbird, they'll probably give you a reward for finding it before Flare launches.

I'm going to poke around and see if I can find how the rewards for the FTSO providers are calculated and then knock up a script to generate the top 5,10,20 over the last N hours/days - then instead of you generating the top 10 spreadsheet by hand, we can make it automatic. if @FTSO_AU(or anyone else) reads this and can tell me which API to query to get the info I need, then I'll start on it right away.  If not, I might get around to it next week, or the one after ... or in 2022 ...

(For circular delegations, I don't really care enough to be arsed to find out - for circular hooks, I have a theory that Jed stopped selling his last 100m just so that if hooks ever go live, he can activate thousands of accounts, fund them and  trigger them into sending circular payments around to each other to bring the xrpl to a standstill - and then gloat about it).  

[RambeauTeasebox]

42 minutes ago, brianwalden said:

I've wondered about this too. Same thing with XRPL hooks. What if Wallet A forwards all payments received to Wallet B and Wallet B forwards all payments received to Wallet A?

The good news is, if you're sophisticated enough to delegate to my Top 5 wallet, you're sophisticated enough to test this out yourself. Get two wallets and see what happens if you create a loop between them. If you break Songbird, they'll probably give you a reward for finding it before Flare launches.

For EVM-based systems, like Songbird/Flare, there is a gas limit that is set. When that is breached, the contract/transaction terminates. And when an account/contract runs out of ETH, there is nothing more it can do.

I'm not sure how Hooks is proposed to handle it, but XRPL has an XRP fee and a fee escalation mechanism. (I'd imagine that Hooks would have some kind of fee limit like EVM transactions?) At the very least, a Hook could only run as long as it has XRP to pay for fees. If it spams the XRPL with transactions, the network fee will be escalated quickly and it won't be able to fund its transactions for very long.

Edited September 30, 2021 by RambeauTeasebox
typos

[jbjnr]

4 minutes ago, RambeauTeasebox said:

For EVM-based systems, like Songbird/Flare, there is a gas limit that is set. When that is breached, the contract/transaction terminates. And when an account/contract runs out a ETH, there is nothing more it can do.

I'm not sure how Hooks is proposed to handle it, but XRPL has an XRP fee and a fee escalation mechanism. (I'd imagine that Hooks would have some kind of fee limit?) At the very least, a Hook could only run as long as it has XRP to pay for fees. If it spams the XRPL with transactions, the network fee will be escalated quickly and it won't be able to fund its transactions for very long.

Quite right. But the hooks amendment is likely to have flaws/bugs and if I had a hundred million xrp to spend and wanted to ruin my competition - then I would create hook scripts that max out the cpu for the time limit (there is a loop limit imposed inside the script and restricted functions that can be called), but I doubt anyone has tried it on thousands of accounts simultaneously and caused each validating node to choke on all the processing and/or memory that is required to run each of the virtual machines for the scripts. (The generated transactions are a secondary issue). Anyway, this is off topic for a pinned thread about Top 10 FTSO delegation, so I'll shut up now. 

PS. if @FTSO_AUis reading this - ignore by request in the post above. I've joined the discord and will look there for technical details on getting oracle feed rewards ...

[BillyOckham]

4 hours ago, jbjnr said:

PS. if @FTSO_AUis reading this - ignore by request in the post above. I've joined the discord and will look there for technical details on getting oracle feed rewards ...

Doh!!!     I dislike discord and was hoping the details would turn up accessible on this forum.  Sigh.

 

[ftso_au]

5 hours ago, jbjnr said:

PS. if @FTSO_AUis reading this - ignore by request in the post above. I've joined the discord and will look there for technical details on getting oracle feed rewards ...

Sing out if you still need it, I can point you towards the contract you need.

[jbjnr]

8 hours ago, FTSO_AU said:

Sing out if you still need it, I can point you towards the contract you need.

Thanks. Someone on discord pointed me to the RewardManager contract, and the FtsoRegistry, but I was hoping there was a rest API I could simply query to get them from somewhere. I would imaging that the rewards must be sent to the Ftso providers themselves, so if I knew which blocks to look in, I might be able to get them from there. Either way, I don't think it's going to be as trivial as I hoped, though it might be just the incentive I needed to start running a flare node and learn about writing some contracts to see if I can extract this info somehow. (I usually only write c++ so this Noddy programming using these new age tools seems very weird to me).

[ftso_au]

3 hours ago, jbjnr said:

I would imaging that the rewards must be sent to the Ftso providers themselves, so if I knew which blocks to look in, I might be able to get them from there.

No rewards come through us, we're both paid out directly from Flare at the end of the epoch. 

Keep going though, join us down the rabbit hole, you know you want too. 

[brianwalden]

So the way this works is each wallet in the index forms a chain. Each wallet uses one delegation to vote for a provider and the other one to vote for the next wallet in the chain.

I can see that this is set up properly but no service (FTSO_AU, Flare Metrics, A-FTSO, Bifrost) shows any rewards being earned from delegating to another wallet rather than to a provider directly. Can anyone confirm that you can indeed delegate your vote to any wallet and your delegation will be delegated according to that wallet's delegations?

[jbjnr]

5 hours ago, brianwalden said:

So the way this works is each wallet in the index forms a chain. Each wallet uses one delegation to vote for a provider and the other one to vote for the next wallet in the chain.

I can see that this is set up properly but no service (FTSO_AU, Flare Metrics, A-FTSO, Bifrost) shows any rewards being earned from delegating to another wallet rather than to a provider directly. Can anyone confirm that you can indeed delegate your vote to any wallet and your delegation will be delegated according to that wallet's delegations?

I was out all day and just checked my rewards and can see 0.0 earned on your 'Top 5' wallet, so I've transferred everything to another wallet where the delegations are better. Thanks for trying - it was a good idea. Pity it doesn't work. Maybe they'll fix transitive delegations at some later date.

[brianwalden]

56 minutes ago, jbjnr said:

I was out all day and just checked my rewards and can see 0.0 earned on your 'Top 5' wallet, so I've transferred everything to another wallet where the delegations are better. Thanks for trying - it was a good idea. Pity it doesn't work. Maybe they'll fix transitive delegations at some later date.

I'm not sure it doesn't work, I think the sites reporting on the rewards are only checking one step, not following the full delegation trail. But you're right to not risk it and delegate straight to a data provider for next week.

Neil from @FTSO_AU helpfully found the relevant section from the white paper that shows it should work in theory:

Quote

Token owners are free to delegate and un-delegate their votes at any time. Delegation can be structured such that one party can delegate to a second party and that second party can delegate to a third and so on. This leads naturally to the notion of an addresses voting power, which is used both by the FTSO and the governance system.

But things change between the white paper and implementation. So we'll see.