Can this list be posted somewhere ? Or is it already public ?
Are the users that delegate funds to other protocols such as Curve, or provide liquidity are include in the list as they technically dont “hold” the assets on their own wallet ?
Can this list be posted somewhere ? Or is it already public ?
Are the users that delegate funds to other protocols such as Curve, or provide liquidity are include in the list as they technically dont “hold” the assets on their own wallet ?
We’re listening to the community which is exactly why we took the time in R7 to implement 3 bots preventive measures. We have over 30+ clicks on “I’m not a bot”, no contract-bot caller, and all calls to contract needed a secret hash.
It appears there has been a snapshot of affected 1token holders all along.
No, we have the aggregated totals from Harmony. I’m not opposed to the whitelist as long they’re prehacked victims because it will benefit actual victims. Just know that, anyone on the whitelist could just pass their private key into bot code. Suppose a large whale is technical or decides to hire someone to code for him/her. We don’t have the list, and neither does Harmony. To generate this list with minimal criticism, it is important on who and how it is generated. Any proposal?
On the minimum lowering, that’s an easy step we already support on the contract. You can assume we will do this for next round.
On the code transparency, we published the original code and had it audited. I literally added two lines to check for contract-caller, and verifying hash generated by frontend. If we expose this, then anyone with access to bot can generate the same hash as our frontend. Harmony already reached out to verify and we are happy to share with them. As for public code, do we want to eliminate bot or do we want code transparency?
I think we also need to agree on some metrics.
I don’t think duration matters as much because you could have very high unique wallets… It just means demand is high.
I’ve personally reached out to and been told by two previous R1 members that a snapshot was taken. They suggest it may be in the team’s Google Drive or other storage. Have you asked Jack? I know he’s no longer at Harmony, but he was involved with the early recovery process and R1.
I have the below document detailing a number of 1token wallets. This information had to originate from somewhere.
Good. Let’s do it.
I included rONE voters because they played a large role in R1 coming to fruition in the first place. From what I can see on the snapshot vote, there were 121 rONE voters.
Like I said though, this should all be up to the community with R1 implementing it.
I can only speaking for myself, but I’m much less concerned about bots if there is a whitelist. These are users who are supposed to be reimbursed.
Besides, the goal is to NOT have the R1 exchange insta-drained! So even if there are bots that are deployed, as long as ALL eligible users have a reasonable chance at redemption then I’m ok with it. That was the issue everyone had, that the exchange was drained instantly. “Solving” for bots but still allowing the exchange to be insta-drained is no solution at all.
I understand there are benefits and drawbacks to any methodology, but the methodology that allows for the most amount of affected users to participate is always going to be my preferred - and in my opinion, the best - choice.
I think you are completely wrong here. Duration absolutely matters. There must be a reasonable opportunity for eligible users to participate. This means users who are at work during the round’s opening, as well as community members on the other side of the globe, as well as other various life circumstances that might prevent someone from being able to exchange their funds within ~2 minutes of the R1 exchange being funded.
Wouldn’t the ideal scenario be to have very high participation over a “longer” period of time that still ends with total redemption of the funds?
This cannot be overstated: An insta-drain is not in the community’s best interest, nor does it best serve the affected users.
Does that mean there were 30+ clicks out of 27 total tx? I’m not sure I would consider this a success. Is that what you’re suggesting?
What I see is “fourteen wallets controlled by just 4 users” and “21 of 27 tx executed by just 4 users”.
There were over 120 rONE voters alone. Having 30+ clicks is terrible. And that’s not even including the much larger number of 1token users who were affected.
The goal is:
Unique wallets - HIGH
Number of tx - HIGH
Amount burned per round - 100%
It’s hard to be more specific than that at this time. The different demand levers can always be adjusted if participation is “low”, but it’s better to overestimate participation and make an adjustment to increase demand than it is to underestimate participation and have the exchange drained instantly.
But we know there are over 120 rONE voters, which is undoubtedly many times smaller than the number of 1token holders. And we know only 20 wallets were able to participate in Round 7 part 2. So even if we only look at unique wallets as a % of total rONE voters, that’s a rather small number (especially since at least 1/3 of those 20 wallets almost certainly never held rONE).
Minimum lowering of what? The exchange rate, the wallet limit, or both?
Just out of curiosity. Has the contract bytecode been tested with a Solidity decompiler to make sure the hash doesn’t leak out?
Am I stupid to think we could eliminate 100% of these problems by just setting the burn rate at the current market rate, or by simply buying the tokens on a DEX?
Here you go, the Whitelist:
This is already being done with Modulo and Tranquil.
Those are just top 100 addresses for each coin someone got from the explorer. The old R1 members will say anything to make us look bad. Jack doesn’t have it. Getting the actual data is actually very difficult because you have to sync the blockchain up to certain blocks (not even sure how to do that with Harmony), then write script to query each tokens to get the holders.
We will have a problem dealing with thousands of addresses for onchain whitelisting. So it has to be done as a mixed onchain/offchain solution.
Sounds to me like you and the R1 Team are compltely useless.
Get rid of this Team @harmonyone , save those 3k$ for burning funds, more usefull.
EDIT:
I think I understand now.
They don’t know how to implement it.
They just wanna do easy work and cash in their 1k$ every month. EZ $.
I made up my mind, get rid of them!
Or AAVE for example…
We’ve done the ‘impossible’. Funny thing is that the R1 team had this information Fall last year, it’s where my report was generated from to track the largest affected wallets.
Generating the data immediately after the hack is much easier than a year after the hack! Why is it the first time I’m seeing this? Why didn’t you guys implement this while you were at R1? You guys shit-talk around for 3 months on the R1 channel (which I’m happy to release), and ended deploying a new contract everytime, which was your “amazing” solution to bots, and a contract-checker.
We reduced the cost nearly 50%. It used be 5k, and we reduced it 3k despite the old R1 members taking the code away and building from frontend, and implement bots from scratch! Aside from that we work closely work Harmony team to coordinate funds, put together stats, work with the community (right here), and working directly with victims who come to us!
How much depegged assets do you have?
You seem to think you’re making Pioneer look bad, but if that’s true, aren’t you making yourself look even worse?
Why didn’t you implement it?! You have been on the team the entire time.
Why didn’t you even know it existed?! It makes the statements by Pioneer and Otis - that you were largely absent - much more credible.
Matt knew it existed.
Matt even said on several occasions you were too busy with other work to focus on R1.
@TrickLuhDaKidz They controlled the code, and the contract deployment (which btw a fork of original contract I wrote and vetted). All the code was closed, not share with the team. – How am I not contributing? I contributed in other matters, we had few issues about legal, upcoming projects with Tranquil.
I made myself available at all times. Most of the time it was Logan & Michael shit-talking on non-R1 related issues like prices harmony, football, and random topics.
At no point in time, anyone (including Matt) suggested to use the list that I am aware of.
There was a point where they talked about whitelisting with the that list you referred to, and decided to redeploy contract everytime, hoping the bots doesnt know the “address”.
Btw, who do you think started R1? Who wrote the voting contract, burn contract? Organized, and led, and and negotiated with Harmony to have each member of R1 paid). I also push for decision to pay evenly regardless seniority, who founded it, who did more work in the spirit of collaboration and unity. Instead Logan talking to me directly about any issues like an adult, I found out he wanted to vote me out from Matt.
We have community members like Logan, Matt to do that. Each of us have different responsibilities. I get feedback from rest of the team as the pulse of R1.
It sounds like you’re glossing over the part where Quoc wasn’t actively contributing so Otis had to create a new contract.
Even you said in your R1 telegram chat that Quoc was busy with other work outside of R1.
I don’t care about who “founded” R1 or your perceived “seniority”.
I care that the project is working well. And it’s not. This latest Round was a disaster.
The community is not receiving the service it signed up for. Most community members are receiving little to no benefit from R1.
I want it fixed and working properly, or else Harmony should just shut it down and send R1’s funding to Modulo and Tranquil.