Bidya logo
  Crypto Coin Prices and News  

HOPR Price   

Cap | Volume | High | Low | Old | New | Rare | Vs | Blockchains | Exchanges | Market | News | Dev News | Search | Watchlist



HOPR Price:
$535.9 K
All Time High:
Market Cap:
$17.5 M

Circulating Supply:
Total Supply:
Max Supply:


The price of #HOPR today is $0.06 USD.

The lowest HOPR price for this period was $0, the highest was $0.065, and the current live price for one HOPR coin is $0.06453.

The all-time high HOPR coin price was $2.16.

Use our custom price calculator to see the hypothetical price of HOPR with market cap of BTC or other crypto coins.


The code for HOPR crypto currency is also #HOPR.

HOPR is 1.6 years old.


The current market capitalization for HOPR is $17,488,136.

HOPR is ranking upwards to #475, by market cap (and other factors).


The trading volume is medium during the past 24 hours for #HOPR.

Today's 24-hour trading volume across all exchanges for HOPR is $535,926.


The circulating supply of HOPR is 270,992,604 coins, which is 208% of the maximum coin supply.


HOPR is a token on the Ethereum blockchain, and has digital contracts with 1 other blockchain.

See list of the HOPR Blockchain contracts with 2 different blockchains.


HOPR is available on several crypto currency exchanges.

View #HOPR trading pairs and crypto exchanges that currently support #HOPR purchase.



A Post-Merge Vision for Web3

The upcoming Ethereum Merge is a major milestone in the development of web3. This is a good time to take stock of how things are going, what a future web3 could look like, and what we’ll need to build to get there. It will come as no surprise that we think the answer is transport level privacy! In many ways the world after the Merge will be business as usual, and most users probably won’t even notice the switch, but the Merge will also fundamentally alter the dynamics of the ecosystem. Some of these changes are obvious, but others are subtle and their effects unpredictable. This is particularly true for issues around MEV, because the Merge drastically alters what MEV extraction could look like and which parties are able to do it. The Merge also sees the implementation of mev-boost from Flashbots, which is not directly linked to the Merge but will still significantly affect MEV in the post-Merge world. It’s been another rollercoaster year in crypto, but the major concerns for the future are the same as they’ve always been: Centralization: Is the ecosystem developing in a way that promotes decentralization or not?, Censorship: Is the ecosystem sufficiently robust against censorship?, Perverse Incentives: Crypto systems generally rely on actors being rational and greedy. This works brilliantly when incentives are aligned for the greater good, but misaligned incentives can create significant disruption., These issues are closely interlinked. Decentralized networks are generally more robust against censorship. Common examples of perverse incentives in crypto would be those which lead to increased centralization or censorship. Etc. etc. Straddling all of these issues we have MEV (maximal extractable value, formally miner extractable value). This is obviously a perverse incentives issue, because incentives to maximize MEV can disrupt the expected and desired ordering of transactions on the chain, even going so far as preventing transactions from being included at all. At this point it’s clearly also a censorship issue. Finally, MEV is a centralization issue, because often only a handful of actors are able to harvest this value. So how does the Merge alter the MEV landscape, and what does an optimistic future look like where all these problems are solved? — MEV and Perverse Incentives Post-Merge - It may seem like MEV opportunities are unaffected by the Merge. After all, blocks will still be built from the same mempool. However, changes to the protocol could radically affect how much MEV is extracted and who will be doing the extraction. First of all, the switch to proof of stake adds a huge degree of predictability. Block times will be fixed, and validators will know which slots they’re assigned to in advance. This gives MEV searches much clearer parameters to operate under, which may open up more sophisticated MEV approaches (under PoW, why invest in a complicated MEV search if the mempool can radically shift at any time because a new block has been mined?). Second, the Merge also coincides with the implementation of mev-boost from Flashbots, a block space marketplace designed to implement proposer-builder separation (PBS). Here block proposers would outsource the actual building of their block to block builders who bid on block space and take a cut of the MEV generated. mev-boost is a welcome addition for all the reasons outlined in the Flashbots post, but it’s unclear how it will interact with the validator sniping attack which HOPR has been trying to draw attention to these past months. A blockspace auction is basically a price-finding mechanism for which upcoming blocks are worth sniping, with the added wrinkle that it’s now less clear who loses out if the attack is successful. We’re not alone in this fear. Although the Ethereum Foundation closed ranks somewhat in our discussion with them on validator sniping, here’s Justin Drake from the Ethereum Foundation talking at the dedicated MEV panel at ETH Amsterdam in April outlining the exact same attack, explaining that linking pubkeys to IP addresses and DDoSing proposers is “fairly easy”. The moderator suggests that this is a solved problem, but as Drake points out these solutions rarely apply to ‘home validators”. (Also, our soon to be published research with Imperial College London suggests that many protections are insufficient for this particular attack.) Drake brought this up in response to a question about what change most needed to be done “yesterday”, highlighting the importance of this issue. His proposed solution is Single Secret Leader Election, which would remove the foreknowledge of which validator is assigned which block. But it’s unlikely that this will be implemented soon, something which Drake himself tacitly acknowledges (“[T]here will be a small period of time — or many not so small period of time — where proposers will still be known ahead of time.”). Based on the Ethereum Foundation’s timelines for the Merge itself, it seems likely that we should expect SSLE to be implemented later rather than sooner. In the meantime, the best way to mask validator IPs and sever the link with pubkeys is a transport level privacy solution. — Censorship Post-Merge - There’s a very broad consensus that transaction censorship is bad. If you have sufficient funds and you pay sufficient gas, your transaction should be included on the chain. But even here things are complex. There’s little support for blanket blacklisting as we saw in the case of Tornado Cash, especially when that bleeds into self-censorship from other unrelated services. But people generally support blacklisting to prevent hacked funds being transferred, even though those are perfectly legitimate transactions within the system. This isn’t the place to get into all the ramifications of the Tornado Cash decision. HOPR recently announced that it is a founding member of LPA, an umbrella organization of many crypto projects which will be better placed to tackle these regulatory issues. More details will be announced at Devcon in October. And of course the US Treasury decision isn’t directly related to the Merge, it just happened at around the same time. But the Merge will radically change the dynamics of transaction censorship, due to a shift in the demographics of who will be proposing blocks. Previously blocks were proposed by miners, who broadly speaking could be expected to ignore censorship pressures (unless they were part of an MEV opportunity). Now the power will shift to ETH holders. And who are the biggest holders? Exchanges, entities which already have a complex and fractured relationship with regulators and a strong incentive to stay on their good side. Many of the proposed solutions to prevent censorship rely on market dynamics. For example, mev-boost is asserted to reduce censorship since its auction dynamic creates a “competitive market between several builders” which is “better for Ethereum’s censorship resistance, as censoring builders will make less money than non-censoring ones and not be able to bid as much.” However, exchanges face different pressures around respectability, as noted in this analysis of MEV post-Merge. They may also have sufficient wealth that they’re prepared to offset (perceived) risk by taking a hit in profitability. Transport level privacy doesn’t directly prevent censorship here (once a transaction is in the mempool, it’s public, so getting it there privately can only achieve so much). However, it’s clear that the kind of robust privacy tools needed to prevent transaction censorship will need to operate in tandem with a transport level privacy solution if they’re going to provide genuine and effective privacy. We predict this will be a major issue for 2023, with many crypto services continuing to over-correct into self-censorship until it becomes clear how radically disruptive this will be for regular users. At that point, we hope everyone will understand that privacy and choice over what data and metadata we expose is a fundamental right and necessity which isn’t synonymous with secrecy or illegality. — Centralization Post-Merge - We’ve already noted the expected change in power dynamics post-Merge, moving away from mining pools to exchanges and validator pools. This is probably a slight improvement, numerically speaking, but far from the dream of full decentralization with tens of thousands of users running nodes from their homes. But do we need that? It’s over five years old now, but Vitalik Buterin’s ruminations on the nuances of decentralization are still relevant today. Full decentralization is ephemeral, probably unachievable and maybe not even useful. A common thread throughout proposed solutions to today’s crypto problems is targeted centralization of certain roles, with heavily decentralized complementary roles acting as a counterbalance. We see this in mev-boost, where the expectation is that PBS will result in a few block proposers but a diverse number of builders and block space pricing methods. We see this in governance, where it’s proving very difficult to motivate mass participation, and it’s not even clear that this is desirable. Decision making on complex problems isn’t improved by adding more people to the mix, but it’s very important to have a broad voter base who can keep decision makers in check. We see this in the anti-censorship debate too. Here’s Justin Drake again, this time talking in ETHCC in Paris on a panel on the Merge. Drake notes that Ethereum is robust against censorship because the validators can always overrule, even in cases where a single builder controls all block creation. But he also stresses that these validators “might be running on Raspberry Pis”, placing in the same category of node runners he noted was vulnerable at the MEV talk in ETH Amsterdam. More broadly, almost every vision of a scaled-up web3 future places small node runners at its core. We see this particularly in Vitalik’s work, but this sentiment is echoed everywhere. So the repeated mantra is the need for many smaller node runners, even if their roles are limited or specialized. But these smaller node runners are most vulnerable to attacks, easiest to censor, and most likely to be affected by perverse incentives. They’re also less likely to be able to implement complicated or expensive security measures. The ecosystem seems to be doing a good job in balancing things on the incentives side, but there’s less focus on creating robust solutions to ensure these node runners can easily join the network and remain there safely. These users will need robust privacy solutions across the stack, but especially at the transport level. Providing this privacy should be a priority post-Merge, to ensure we can build the fair and free web3 future we all dream of. Dr Sebastian Bürgel, HOPR Founder Website: Twitter: Telegram: Discord: Forum: Staking: Bounties: Playground: A Post-Merge Vision for Web3 was originally published in HOPR on Medium, where people are continuing the conversation by highlighting and responding to this story.

HOPR in Istanbul — Major Announcements!

HOPR in Istanbul — Major Announcements! - This week we’re in Istanbul visiting our Turkish community, with a series of events hosted by Altcoin Turk. HOPR’s Turkish channel is the second largest of our local community channels, and the Turkish community have been some of HOPR’s longest and most dedicated supporters. We wanted to reward that dedication with a special visit where we’re making not one, but THREE major HOPR announcements. First, HOPR has partnered with leading crypto hardware provider DAppNode to produce a special HOPR version of their DAppNode x Gnosis Chain device. HOPR is designed to run on as broad a range of devices and setups as possible, but we believe dedicated hardware nodes in users’ homes are the cornerstone of a robust privacy network. DAppNode is also based in Istanbul, so this is the perfect venue to announce this expansion in choice for how users can interact with HOPR. The HOPR-branded DAppNode has the HOPR logo etched right into the metal and comes with all kinds of sweet bonuses. The 16GB machine comes with four Gnosis Beacon Chain validator nodes preloaded and funded, which is the equivalent of 4 GNO and 500 Nodes (dAppnode Token). You’ll also receive a share of the 48,535 HOPR tokens which the HOPR DAO voted to allocate to growing the HOPR hardware node network. You can pre-register for your limited edition HOPR DAppNode right now: dappnode.ioproducts/hopr-special-edition The node will be available for purchase from August 26th, with delivery from September 26th. The initial run of this device is limited to just 50 machines. So what does this mean for our existing AVADO users and everyone running a node on their local devices or in the cloud? Don’t worry, we have great news for you too. We’ll have a follow-up announcement when HOPR visits Devcon in Bogota in early October. Second, we teased the existence of a new privacy alliance, of which HOPR is a founding member. An alliance of like-minded projects will allow us to put up a united front against the alarming attacks on privacy web3 has witnessed in recent months. The alliance will bring together privacy projects from across the web3 stack to actively and constructively promote data privacy in crypto and beyond. Look out for more details at Devcon. Finally, we’re excited to announce that we’ll be returning to Istanbul in April next year for a special event and hackathon: ETH Istanbul. This hackathon will mark the culmination of our mission to integrate HOPR with web3 wallets to bring privacy to the most fundamental aspect of crypto: your transactions. Starting next month with a UX workshop at our ETH Zurich event, HOPR is partnering with major wallets including MetaMask to work out the best way to integrate privacy directly into wallets, allowing users to transact privately and safely with the minimum extra effort. The results of the UX workshop will be fed into hackathons at various events around the world, with the goal of producing a seamless integration in 2023. Register now: www.ETHIstanbul.NET We’ve had an amazing time in Istanbul and we hope to see you here when we return in the spring. We’ll be sharing more details about all these initiatives over the coming weeks. Rik Krieger, HOPR Co-founder Website: Twitter: Telegram: Discord: Forum: Staking: Bounties: Playground: HOPR in Istanbul — Major Announcements! was originally published in HOPR on Medium, where people are continuing the conversation by highlighting and responding to this story.

HOPR Playground is Live

We’re delighted to present the HOPR Playground, a brand new way to interact with HOPR that gets you up and running in less than a minute without any installation. Just visit the Playground site, click the button, and you’ll be given access to a connected cluster of five HOPR nodes and our growing list of dApps to test, learn and play. Share links and PeerIDs with friends to give them access. When you’re done, we hope you’ll be inspired to build a dApp of your own and earn a juicy bounty! HOPR Playground removes the long install and setup times that you may remember from our earlier testnets and Gitpod local setup for developers. When you click LAUNCH CLUSTER, within seconds you’ll be given access to one of forty clusters of five nodes for twenty minutes. A countdown shows how much longer you have left with your cluster. If all clusters are in use, please wait and a new one should become available soon. You’ll then see the HOPR dApp dock. Click an icon to see a short description of the dApp and five auto-generated links to access it, one for each node in the cluster. The nodes are pre-warmed, so once you launch the cluster it should only take around ten seconds to be ready. You’ll know everything is good to go when the PeerIDs change from “Loading…” to a HOPR address. Click a link to open a new browser tab and access a dApp. You can access all five nodes at once in different tabs. You can also send links to friends to give them access to a node so you can exchange messages or play games together. Separate clusters are their own individual HOPR networks, so there’s no way for them to interact with each other. When you’re done with a dApp select a new one and the links will automatically change for you. The cluster will be the same, so the nodes and their PeerIDs won’t change. This also means that you can run multiple dApps on the same cluster to see how they interact. For example, it can be interesting to run hoprd and see the messages sent by other dApps such as Boomerang. Here’s the chess app and hoprd running simultaneously. You can see the moves arriving in the form of messages, which are interpreted by the dApp via the HOPR API. We’re launching with six dApps, with several more in the pipeline to be added soon. Hoprd The classic admin interface for hoprd familiar to testnet users, Hopr Cockpit See stats about your HOPR node in real time, Hopr Visualizer Visualizes the entire HOPR network, Chess Play chess with friends over HOPR, Boomerang A proof of concept dApp which you can build yourself, Our flagship in-house private chat dApp, If you want to get deeper into HOPR, the most important dApp in the list is probably hoprd (the d stands for daemon). This will start up a version of the command line interface that will be familiar to anyone who participated in one of our testnets. After clicking a link to access a node, you’ll see the hoprd admin interface. Initially it will be yellow and show a bunch of warnings. Playground nodes are automatically funded with test tokens, so you can just ignore these warnings and wait for startup to finalize. The interface will turn blue when this happens. This should take less than twenty seconds. Once hoprd is ready, you can start inputting commands. Type help or visit our docs page for a list of possible things to try. When you’re familiar with using your node, you can use the other links to experiment with the other nodes in the cluster and how they interact. Playground isn’t a replacement for running your own node, and developers should still use the Gitpod cluster deployment for building dApps, but it’s an amazing tool for showcasing dApps and getting people familiar with HOPR without complicated setup requirements. A huge thanks to our backend and frontend devs for their hard work in putting it together. Another shoutout should go to the bounty hunters who built all the dApps as part of our bounty program. We’ll be showcasing their work individually on Twitter over the coming week. There are also many more dApps in the pipeline which will be added to Playground once they’re complete and tested. If you’re inspired to build a HOPR dApp, check out our bounty contest. Apply with an idea, and if you’re approved you can start work immediately. Submitted dApps which comply with the HOPR dApp standard each receive $800 in HOPR tokens. There’s also an additional $2500 prize for our favourite dApp, chosen by the HOPR bounty admins next month. Steven Noni, HOPR Engineer and Bounty Master Website: Twitter: Telegram: Discord: Forum: Staking: Bounties: Playground: HOPR Playground is Live was originally published in HOPR on Medium, where people are continuing the conversation by highlighting and responding to this story.

How HOPR Got People to Care About Privacy and Invest

HOPR is a little over two years’ old, and over that time we’ve used many different narratives to draw people’s attention to the huge privacy issues which plague Web 2.0 and Web3. Although everyone we engage with agrees with our mission to change privacy for good, getting people to actually take action has been a challenge. That all changed earlier this year when we adopted a new approach which not only got people to take crypto privacy more seriously — it directly led to significant investment from projects directly in the Web3 space. Here’s how we managed to crack through some of the apathy and convince people to put their money where their mouth is on Web3 privacy. There’s a surprising paradox when it comes to pitching data privacy narratives: virtually everyone is already convinced. People may not know the specifics, but they know private data is important, and at risk online, and they feel that companies — particularly Web 2.0 monoliths like Facebook and Google — can’t be trusted with data. Cisco’s regular consumer privacy surveys offer clear proof of this. In the 2021 survey, fully 86% of people agreed that data privacy is an issue they care about. 79% of people said they’re willing to act to protect their privacy. And that’s just regular digital consumers. In crypto you’d expect the figures to be even higher. And yet in both Web 2.0 and Web3, users, companies and projects consistently don’t act on privacy. Why? One important factor seems to be the fuzziness of the problem. The link between privacy issues and negative consequences are often vague. Yes, it’s creepy to see ads based on yesterday’s Google search in other contexts, but how does that happen, how can you stop it, and how much does it actually matter? Even in very visible situations, such as data breaches, it’s often unclear how and when the stolen data is used and what the precise consequences are. In crypto and Web3 the issue is often complacency. Many people believe that privacy issues are a relic of Web 2.0, and the very act of switching to crypto and Web3 means everything is golden now. But in fact Web3 has its own host of privacy issues, many of which will be more serious than in Web 2.0 without serious investment in solutions. Everyone agrees that education is important, but as we’ve seen it’s not as simple as explaining to people about privacy. Everyone already knows and agrees data privacy is important, they just don’t understand what to do with that narrative. So what’s a privacy project to do? The answer is to make things less vague and clearly show the extent of the problem, in ways people can clearly see and interact with. That’s why we’ve focused on building tools which take a hidden issue and put it directly in your face. Let’s look at a few of them. — D.E.R.P. - Our D.E.R.P. (Dumb Ethereum R.P.C. Provider) tool shows exactly what happens when you connect your wallet to today’s crypto services. Instead of hiding all the requests and responses that are usually abstracted away by slick user interfaces, D.E.R.P. puts them all into a table in real time. The results are alarming: in addition to your IP address, many DeFi services leak far more information than you’d expect, or they need to. Most surprising for many people: wallets often leak information about ALL your addresses, even if they’re not involved in the transaction. This proved a real eye-opener, even for people who have been in the industry for years. Try it out here. — Metadata Games - Data privacy is a global issue, but it doesn’t manifest in the same way everywhere. Our metadata games were slightly different, in that we didn’t build a new tool. But over a week we asked our different local language communities to directly engage with the problem of metadata privacy, with a focus on finding concrete examples of privacy issues, particularly ones specific to their region of the world. The result was a greater shared understanding of how metadata privacy affects different people in different ways. Read more about the results here. — Non-Private NFT - NFTs were the hot crypto topic of the past year, but of course very little attention was given to privacy factors. Our non-private NFT is a dynamic image that changes depending on who is accessing it. Looking at the NFT reveals data like your location, device, browser choice and your IP address. Like D.E.R.P., the non-private NFT exposes parts of the Web3 setup that are usually deliberately hidden from users in the name of smoother user experiences. But bringing these back to the surface shows just how far we have to go to build a private Web3 that matches the lofty ideals we have for the ecosystem. Check it out here. We don’t store any of the information used to generate the image. — What Next? - Although these tools aren’t HOPR’s core product, building them has been invaluable in getting people on board with our mission to change privacy for good. By focusing on details and not shying away from technical elements, it’s also meant our community were primed to understand our recent research into privacy issues which could affect the upcoming ETH2 Merge from proof of work to proof of stake, even though the specifics are quite complicated. This approach has really revolutionized our interactions with other projects in the Web3 space, and spurred many notable projects to put their money where their mouth is and invest in making the ecosystem more private. Far from resting on our laurels, we’re working on the next round of privacy tools. If that sounds like something you’d like to help us with, check out or jobs portal or our bounties page. Sebastian Bürgel, HOPR Founder Website: Twitter: Telegram: Discord: Forum: Staking: Bounties: How HOPR Got People to Care About Privacy and Invest was originally published in HOPR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Proof-of-Stake Validator Sniping Research

The Merge is fast approaching. In a few months, the Ethereum chain will switch from proof of work (PoW) to proof of stake (PoS). This is an exciting development, but we need to highlight an important privacy issue with the post-Merge chain. The HOPR team has been leading research into the functionally identical Gnosis Beacon Chain (GBC) in collaboration with the Decentralized Systems and Security Group at Imperial College. We’ve identified large perverse incentives for validators to conduct sniping attacks on each other in an attempt to poach their block rewards. This is possible because the PoS validation scheme requires validator public keys on the beacon chain to be known to everyone ahead of time, so everyone knows the validator ordering for slots within an epoch. This foreknowledge, combined with information about a validator’s IP address, enables a particularly nasty attack whereby someone can deliberately take down a validator’s node — e.g., via a denial of service (DoS) attack — and the next validator can poach their rewards. This possibility has been known for a while — in fact it’s mentioned in several Ethereum security audits from 2020 (here’s one from Least Authority and another from Quantstamp). But it has generally been dismissed as low severity. However, the research conducted at HOPR over the past few months, as well as parallel research from our collaborators in the Decentralized Systems and Security Group at Imperial College London, lead us to conclude that the risk is much higher, for three reasons: The incentives to conduct this attack are much higher than previously thought, It’s easier to identify validator IPs than previously thought, The attack itself is easier to conduct and harder to mitigate than previously thought, Let’s outline the steps of the attack and then look at these three points in more detail. — Validator Sniping — the Basics - The basic outline of the attack is simple: watch the beacon chain network for long enough to form a link between a validator’s public key and their IP address, then when that validator becomes block proposer, take their machine offline with a DoS attack. They will be unable to complete their block proposer duties and their slot will expire. The role will pass to the next validator, who will be able to take all the MEV opportunities and transaction fees the sniped validator had access to. But how would you get the public key and IP address information needed to conduct the attack? To understand, we need to look deeper into how proof of stake will work in ETH2 and equivalent setups. Every epoch, a set of validators is randomly selected to propose blocks, and every validator gets to validate one block within the epoch. This validation process is conducted within these small groups, but the confirmations of each step — known as attestations — are broadcast throughout the network. This all happens publicly, and the only requirement for running a validator node is that you put up the requisite stake. Therefore, anyone can pay to have access to all this data. As you run your validator node, you’ll gain information about other node runners’ IP addresses and public keys. This link isn’t straightforward — attestations are often bundled for efficiency, and nodes won’t be connected to all other peers in the network, making for incomplete data and a lot of noise. But we’ll show below how it’s possible to cut through this and link IP addresses to public keys with a very high degree of certainty. Once you’ve established this link, all that remains is to wait for a suitable attack opportunity. You can then launch an extremely targeted denial of service attack (DoS) on the target validator. This isn’t like the distributed denial of service (DDoS) attacks which we’re more familiar with that take down major services for hours. It wouldn’t need to be that intense or long-lived: it just needs to knock the target machine out of action for long enough that they can’t fulfill their slot duties. But what can be gained here, and how often do these attack opportunities occur? It’s here that previous research seems to have misunderstood the stakes. — Mismatched Incentives - Our assessment is that when previous researchers and auditors considered this attack, they were mostly thinking about the incentive to cause chaos: to indiscriminately disrupt the chain, or to cause validators to be slashed by blocking them from fulfilling their validation duties. What’s been missed is that the colossal rise in MEV creates direct incentives for validators to attack each other, either working alone or in collaboration with a dedicated validator sniper who would look for opportunities to take down particular machines, much like how MEV searchers operate in tandem with miners / validators. For an attack to be viable, three things must happen simultaneously: Knowing the IP address of an upcoming block proposer, Having control of the next slot (either because you’re the validator in that slot, or you’re able to collaborate with them), Sufficient MEV opportunities in the mempool to be worth poaching, Our assessment is that this isn’t some once in a blue moon set of circumstances. In fact, we’d expect to see this happen very frequently. This is because: Finding validator IP addresses with high confidence turns out to be fairly trivial, The frequency of collaborations between MEV searchers and miners shows that opportunities are vast and these interactions emerge with little friction in the DeFi space. Although DoS-facilitated MEV attacks would be more widely frowned upon than vanilla MEV, which exists in an ethical grey zone, we’d still expect similar collaborations and services to arise quickly., MEV opportunities occur very frequently in Ethereum at present, and there’s no reason to think the switch to ETH2 will change this significantly, — Linking IP addresses to Public Keys - It has long been known that it could be possible to watch the network and form links between validators’ public keys and IP addresses. But as far as we know, HOPR is the first project to actually try it. The next sections explain in detail what we did and how easy it was. — Our Setup - Since April 21st 2022, 11 HOPR team members around the world have been running validator nodes on Gnosis Beacon Chain, using hardware nodes from our great partners at AVADO. They voluntarily shared their IP addresses and public keys with our analysis team so that the results could be confirmed. Note that the IP addresses were not used in the analysis process except for verifying the results. Separately, we ran another node which was lightly modified to harvest the IP addresses of all connected peers when they broadcast attestations and dump this to a database of IPs and public keys using Elastic Stack. The node modification was fairly trivial, as the Lighthouse client facilitates validator monitoring as standard. (This feature will be important later too, when we discuss ways to improve this data harvesting.) This generated a LOT of data. For example, between 1st June and 1st July we stored 2,285,214,572 IP / public key pairs, which could be associated with 1,253 unique IP addresses. — Linking Public Keys to IP Addresses - So how did we turn this huge amount of data into a confident link between IP addresses and public keys? Remember, just because our node received information about an attestation linked to a public key from a particular IP address, that does NOT mean that this is the IP address of the validator node with that public key. This is because some nodes aggregate attestations for faster dissemination throughout the network. In fact, our node didn’t even register that these were aggregated attestations, instead logging them in the same way as single attestations. So the task is to wade through all this noise. First, we pick some public keys to try and link. For this experiment we used the public keys which we already knew from our testers. It’s crucial to understand that this step is valid because at no point did we use our foreknowledge of the IP addresses to establish the link. The only reason to pick these public keys in advance was because we knew that we could validate these results. We could equally have just picked random public keys and worked through them one by one, eventually hitting the ones controlled by the HOPR team. Even narrowing down to these 11 public keys, it’s still a lot of data. From 21st April to 1st July, our node gathered 431,639 pairs of IP addresses associated with the 11 HOPR public keys. Over this timeframe, 1613 unique IP addresses were associated with the 11 HOPR public keys. But which were the true ones? The first thing to do is divide the data into discrete chunks of time. The choice of timeframe is arbitrary, but we chose a day because this seemed like it would give a manageable amount of data. For example, if you only looked at the past 15 minutes of attestations we might not be connected to a given HOPR node. Therefore, you would not have any information to match the public key with the correct IP address. The figure below shows the attestation count by IP and pub key of HOPR Team GBC nodes throughout June, with attestations separated by day. As we can see, our harvesting node did not connect equally to all HOPR nodes. In fact some days it connected to hardly any of them. This makes sense as a node cannot be connected to all 1600 nodes in the network at all times, and nodes are not always consistently up and reachable. Still, this is enough to give a strong link. For a given day and public key, we simply looked at which IP address was most frequently associated with attestations from that public key. This is really the most basic approach possible, but even this we found produced the correct pairing in 62% of cases. But we can easily do better. This method does nothing to account for the fact that there will be days when our harvesting node will not connect directly to the node we’re trying to identify. And put the other way, it doesn’t sufficiently use the fact that when a given HOPR pub key is associated with the correct HOPR IP on a given day, then the HOPR IP produces the highest attestation count among all other IP’s associated with that particular HOPR pub key in 99% of all cases. To improve this, we used a reweighting method where we reweight the percentage share of a given IP from the first approach with the total number of associated attestations across all days. In essence, the weighting downweights days in which a given HOPR node is not connected and shifts this weight to days where a given HOPR node is connected. This approach increased the probability of identifying the correct IP address from 62% to 89%. It also reduced the set of possible IP addresses associated with each node to 1–3. So establishing a reliable link from public key to IP address requires data to be gathered over quite a long period. But how long? The figure shows that we needed to collect around three weeks of raw attestations to link all 11 of our nodes. But this was because we already had a set of public keys we were interested in to prove our proof of concept. If we just wanted to find ANY public key to snipe, and we were prepared to accept a lower certainty threshold, then a lot less time might be needed. There are various other techniques which could cut this time by a lot, such as: Running multiple validator nodes, Cutting the connection to nodes whose links have already been established to focus on unlinked nodes, This last one brings us back to the Lighthouse modifications mentioned above. Instead of connecting indiscriminately to nodes, you can choose particular validators to connect to or ignore. This is usually used for diagnostic purposes, to test the health of nodes you control, but this can be subverted to facilitate the attack. One limitation is that there’s a lot of redundancy in the dataset. Since we’re only interested in building the IP address database, not facilitating validation on the network, there’s no point in gathering data from nodes where we already know the IP / pubkey link. So if we set a confidence threshold beyond which we’re happy that the link has been made, we can deliberately drop connections to those validators to instead focus on currently unlinked nodes. In this way we can more efficiently build up a picture of the whole network, populating the IP address database much more rapidly. — Attack Feasibility - Of course once you have the IP / pubkey link, you still need to carry out the attack. How feasible is this? That’s what our research partners from Arthur Gervaise’s group at Imperial College London are currently trying to determine. We expect their research to be published in the next few months, but we can already make some assessments. First, this doesn’t need to be a large-scale attack. The target machine just needs to be taken down for a minute or so, long enough for the slot to expire. Second, client-level solutions don’t seem to be much help here. There were a few proposed solutions in the Teku audit from 2020, but they only work if the attacker is trying to overload the node, not the whole machine. Third, we’ve seen much larger scale DoS attacks brought to bear on crypto in recent months, for potentially smaller rewards. It seems inconceivable that people wouldn’t take the opportunity to conduct a simpler, less detectable attack for higher returns. — Next Steps - So what can be done about it? The most obvious short-term solution is to manually protect your IP address. Good VPN hygiene is important of course, but note that this likely isn’t enough to protect you. Quite apart from the fact that many VPN business models open you up to other privacy issues, VPNs simply don’t provide enough IP address protection. As a case in point, let’s return to the geolocation diagram from before: We don’t want to doxx our own team members, but let’s just say that this map accurately locates the IP addresses of the nodes, but not their physical location… So you need to cycle your IP address fairly rapidly. How rapidly? That depends on how fast the IP link can be established. We needed weeks with our naive approach, but we were just running one harvesting node with little optimization. Estimates from collaborators suggest that time can be reduced as low as 15 minutes fairly easily, especially if you’re happy to accept a modest hit to the confidence threshold. Obviously as transport-level privacy project, we’re going to endorse a transport-level privacy solution. Attestations sent through a mixnet like HOPR’s would show a different IP address basically every time (the IP address of the penultimate hop in the relay chain). Attestations are also small enough that only one HOPR message would be required, so there shouldn’t be any appreciable latency or packet loss. This solution would also keep validation as a viable option for home validators, which we feel is a vital part of the decentralized future. We’ve been delighted to see that our friends at Gnosis Chain feel the same, frequently rejecting complex or resource-intensive solutions which would add further barriers to becoming a validator. But the reality of course is that a variety of solutions should be adopted, across every layer. The blockchain is the fundamental source of truth that underpins everything we build on top of it — no effort is too small to ensure its integrity and security. — Responsible Disclosure - Finally, a note on responsible disclosure. One of the biggest criticisms of our initial Twitter threads is that we should have released this information less publicly, through the private disclosure channels used for severe bugs and other threats. While we agree the initial tone of our threads was suboptimal, we disagree that this is an issue for behind closed doors. This is something which has been known about for several years, with no sign that it’s being taken very seriously. No funds are currently at risk, so there’s no immediate danger of signal boosting this information. This is an issue for everyone, but validators in particular, and we feel it’s vital that everyone be included in the conversation. We look forward to collaborating with as many people as possible on this issue in the coming months. If you’d like to reach out to us, please use one of the links below. Sebastian Bürgel, HOPR Founder Website: Twitter: Telegram: Discord: Forum: Staking: Bounties: Proof-of-Stake Validator Sniping Research was originally published in HOPR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Announcing HOPR’s Coinbase Earn Campaign

Our recent Coinbase listing made HOPR accessible to a whole new part of the ecosystem. One of our main goals at HOPR is to bring crypto and data privacy knowledge to everyone, regardless of their level of technical understanding, and being listed on one of the world’s major exchanges is a huge boost to that mission. Now we’re taking that to the next level with the announcement of a dedicated HOPR campaign on Coinbase Earn! Coinbase Earn is a great way for you to learn about crypto projects like HOPR and earn tokens while doing so. — How Coinbase Earn works. — Coinbase Earn lets you complete educational tasks in order to earn cryptocurrency. After watching a series of short videos, take a quiz to test what you’ve learned. Anyone with access to a Coinbase account will have this unique opportunity to earn $HOPR tokens.* *Coinbase Earn is only available in supported jurisdictions and if your account meets certain criteria. Learn more in their FAQ. — How our quiz will be structured. — HOPR’s campaign will have a three question quiz. Answering each question earns you some $HOPR tokens. The questions will be related to the HOPR protocol, HOPR staking, and HOPR’s goals for ecosystem expansion. And one you’ve completed the campaign, why not continue your learning journey by checking out our HOPR Basics series? We’re looking forward to welcoming new members to our community! For more information, please click this link. — About HOPR. — HOPR is a Swiss-based privacy project which aims to change digital privacy for good. HOPR is the first fully incentivized and scalable private mixnet, providing privacy to DeFi, web3, and ultimately any and all traditional services which require data transfer. Data and metadata sent through the HOPR network is protected from all observers within and outside the network. Only the sender and receiver will know how much data was sent to who and when. Network users can earn HOPR tokens as an incentive for running nodes that anonymously and securely relay data to other network members using HOPR’s proof-of-relay system. Users can also use the HOPR token to vote in HOPR’s DAO experiments, a governance initiative with one of the highest participation rates in the crypto space. HOPR’s unique incentivized and gamified staking program rewards participants with NFTs for participating in testing, crypto education, promotions and more. Earned NFTs stack within the staking program to boost the yield on staked tokens. The program is designed to reward active community members without requiring a lot of technical knowledge. We’re incredibly excited about this new collaboration with Coinbase, and look forward to welcoming a whole new set of people who want to help change data privacy for good. Rik Krieger, HOPR Co-founder Website: Twitter: Telegram: Discord: Forum: Staking: Bounties: Announcing HOPR’s Coinbase Earn Campaign was originally published in HOPR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Behind the Scenes at HOPR Tech Day

The entire HOPR team met in Zurich in the last week of July. As a decentralized project with team members spread across the globe, it’s a rare event to have everyone together at once, so we wanted to make the most of it. We had a lot of amazing discussions and events, but today I want to share a behind-the-scenes look at our tech team architecture discussion. The results will have far-reaching consequences for how HOPR nodes work and help us to build more stable releases faster.The tech team working on the core-ethereum refactor We met at Zurich’s Technopark for a full day of discussion, brainstorming and design. The result was some major overhauls in the architecture of the protocol and how we code, test and manage releases. — Refactoring core-ethereum - Our most important decision was to refactor the core-ethereum component within the HOPR protocol. As the name suggests, core-ethereum acts as a bridge between the core (libp2p, connectivity) and ethereum (smart contracts) components. It’s responsible for lots of crucial parts of the HOPR protocol, including assessing the current state of the payment channel topology, broadcasting and indexing transactions to and from the blockchain, and managing the locally stored database. It used to look like this:The old core-ethereum architecture This was a pleasingly simple, streamlined design, but unfortunately the simplicity obscured some issues: it could be hard to tease out the sub-components to work on in a granular fashion, and some sub-components that really belonged in core-ethereum were stranded in other parts of the protocol. We wanted a new design that really specified all the different parts and how they interact, allowing the team to understand the whole more clearly and work more easily on their individual areas of focus. The figure below shows the new design in all its glory!Updated core-ethereum architecture Although it may look more complicated, separating out these components and giving them all a clearly defined purpose will make development and testing much, much easier. One crucial factor in this architecture design is that it’s compatible with our long-term goal to migrate to Rust. Unlike the previous design, this setup can be smoothly migrated to Rust while maintaining almost identical interfaces between components. This was the major outcome of the tech team architecture discussion, but we also made some other important decisions which will improve our development processes and help us to produce better, more stable releases more quickly. Improvements to Release Processes, Testing, and Coding Practices We’ll be updating the codebase to include various new tooling, including improved code coverage, linting and lots more automation. HOPR releases are a major event with a LOT of steps and testing. As always with complex development, sometimes things go wrong and you have to go back to earlier parts of the process. We already have heavy automation here, but with the old setup there were still some manual steps here which could cause bottlenecks, especially with team members in so many different timezones. We’ll be automating these so we can save the tech team a lot of time in the long run. In cases where things don’t go to plan in the pipeline, PRs will automatically be created so they can be more easily addressed. Good news for our valued AVADO community is that we’ll be implementing automatic node migration. When we push new public versions to AVADO, all nodes will automatically update to the new version. Of course, before we implement this we’ll be running stringent tests to ensure there are no compatibility issues and user funds are safe at all times. Finally, we’ve changed our protocol identifiers on the protocol level so different releases in the same environment can talk to each other. When we first began developing HOPR, nodes from different versions couldn’t talk to each other, even if the difference between those versions was minor. Regular participants in our testnets will probably remember the dance of reinstalling their node when hotfixes were pushed. We later introduced environments (named after cities), but this behaviour still persisted, even though it didn’t need to. Obviously this doesn’t make for a great user experience, so we’ll remove this behaviour so we can re-use environments when we make small updates to releases. Major updates will require a new environment, and nodes still won’t be able to communicate across environments, but this will be much less frequent. This was a great day with the tech team firing on all cylinders to bring improvements that will pay off handsomely in the short and long term. This work all happens deep under the hood, so users and community members are unlikely to directly see any of the results of this refactoring, but everyone will benefit from reduced release times, more stable nodes and the ability to support a bigger network for longer! As always, please feel free to check out our progress on Github, or via our bi-weekly tech updates on Twitter. Steven Noni, HOPR Software Engineer and Bounty Master Website: Twitter: Telegram: Discord: Forum: Staking: Bounties: Behind the Scenes at HOPR Tech Day was originally published in HOPR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Get up to 20% Boost with the Collector NFT

Are you ready for our most valuable HOPR Boost NFT yet? With each new season of the HOPR staking program, the oldest NFTs are removed from rotation and can no longer be staked in our contract. However, we want to make sure that loyal community members who are still active have an opportunity to restore their APR boosts. Last season we had the Restaker NFT, this season we have the Collector. You’ll receive this NFT for holding sets of the discontinued NFTs — the more NFTs and the better the rank, the higher your Collector boost, up to a massive 20%. How it Works At 2pm CEST on Wednesday 3rd August we’ll take a snapshot and mint NFTs for addresses which hold collections of the discontinued Season 1 NFTs. The following NFTs were discontinued as part of Season 4: Wildhorn Tester, Puzzler (v1 and v2), Wildhorn v2 Tester, DAO v2, Surveyor, (Note that there are different versions of the Puzzler NFT based on when the puzzle was solved, some later versions were issued in Seasons 2 and 3 and so are still eligible for regular staking.) Based on your holdings on 3rd August, you’ll receive a score based on the rank of the NFT(s) you hold: Bronze 1 point, Silver 2 points, Gold 3 points, Diamond 4 points, If an address holds several NFTs of the same type, only the highest rank will count. Each address will then receive a Collector NFT based on its score: 4–7 points Bronze, 5% APR Boost, 8–11 points Silver, 10% APR Boost, 12–15 points Gold, 15% APR Boost, 16+ points Diamond, 20% APR Boost, This is our most valuable NFT yet, so make sure your collections are complete for next week. If you haven’t unstaked yet from the Season 3 site, just head here and click Unlock. Your NFTs will automatically be returned to you. You can restake on the Season 4 site. Just leave the Season 1 NFTs where they are and you’ll receive your new Collector NFT automatically next week. You can also buy and sell NFTs on various marketplaces to complete your collections. Rik Krieger, HOPR Co-founder Website: Twitter: Telegram: Discord: LinkedIn: Forum: Get up to 20% Boost with the Collector NFT was originally published in HOPR on Medium, where people are continuing the conversation by highlighting and responding to this story.

HOPR Staking 4.0

Staking Season 4 is upon us! The new staking season will begin at 2 pm CEST on Tuesday, July 26th 2022. It will run for three months, ending at 2 pm CEST on Wednesday, October 26th 2022. To claim your remaining rewards and unlock your stake, visit once the season has ended and press the Unlock button. Your stake will be returned as xHOPR tokens. Unclaimed rewards will be sent to your wallet as wrapped xHOPR tokens (wxHOPR). These will need to be unwrapped to xHOPR by using our unwrapper at To restake your stake for Season 4, visit, connect your wallet and follow the instructions. The base rate of 10% and boost cap of 150,000 HOPR tokens remain unchanged. For more information on how staking works, visit our Staking FAQ. As we move through the staking seasons, older NFTs are discontinued. For this season, only NFTs from Seasons 2, 3 and 4 will be eligible. Their boosts remain the same. The full list of discontinued NFTs is: HODLr, Wildhorn_v1 and v2, DAO_v2, Puzzlehunt_v1 and v2, Surveyor, Don’t worry, as always we’ll provide a way to recover the temporary loss of APR. This time, you’ll be eligible to receive a special Collector NFT based on the number of NFTs you collected in the past. The Collector NFT and instructions for redeeming will launch very soon, so make sure you keep hold of your old NFTs! Rik Krieger, HOPR Co-founder Website: Twitter: Telegram: Discord: LinkedIn: Forum: HOPR Staking 4.0 was originally published in HOPR on Medium, where people are continuing the conversation by highlighting and responding to this story.

DAO Experiment v0.4

It’s time for the fourth in our series of HOPR DAO experiments! This time we’re trialling a streamlined two-phase DAO process: the HOPR Association will present draft proposals for discussion on our forum, which will then be revised for a vote among all HOPR token holders. — The Topic - Which of the following proposals to redistribute the DAO’s liquidity should be adopted? We’ll be asking a series of yes/no questions related to moving some of the DAO-controlled liquidity from its HOPR-DAI pool on Uniswap to different DEXs on Gnosis Chain or to a HOPR-ETH pool on Uniswap. The proposals are not mutually exclusive — it will be possible for the DAO to execute all, none, or any combination of them. — The Background - The HOPR DAO’s liquidity pool is one of the deepest in crypto. At the time of writing it contains 68.2m HOPR and 4.7m DAI. Almost all of this is controlled by the HOPR DAO. These funds were raised during the HOPR token’s launch in February 2021 and 100% of the funds were moved to a Uniswap pool — none of the funds were allocated to the HOPR Association or HOPR team. In our first DAO experiment back in May 2021 the DAO voted to keep these funds entirely on Uniswap, but transition them to the recently launched Uni v3. — Gnosis Chain Proposals - But that was a long time ago. In the intervening months HOPR has developed a much closer relationship with Gnosis Chain — we have a close relationship with the Gnosis Chain founders and team; it’s where our staking program and HOPR Boost NFTs live; of the major non-Ethereum EVM chains, the Gnosis Chain values match most closely with our own; it’s a preferred ecosystem for our community because of the cheaper gas fees. To build on this foundation, we think it makes sense to move some of the DAO’s liquidity to Gnosis Chain. But we need to decide how much and to which DEXs. We have three proposals for consideration, based on conversations with DEXs. — ETH–DAI proposal - Another major change since launch is that crypto has firmly entered a bear market. There was a certain amount of criticism after the launch for our choice of HOPR-DAI as a liquidity pairing rather than HOPR-ETH. Having HOPR paired with a stable coin has certainly contributed to stability: during the recent downturn HOPR has outperformed most other coins thanks to this choice of pairing and the amount of liquidity provided by the DAO. But there’s also an argument for having HOPR paired with non-correlated tokens. Opening up arbitrage opportunities would encourage trading and increase DAO fees. It would also help HOPR rise up the ranks of most traded tokens. There’s also the possibility that HOPR could benefit from a future recovery in the price of ETH, piggybacking on an upswing in a way that would be impossible if HOPR remains solely pegged to DAI. Of course, the price of ETH might not go up, and impermanent loss means the DAO would not necessarily directly benefit from this. We hope these questions and more will be hotly discussed on our forum over the next few days. — The Process - As with every other HOPR DAO experiment, we’re going to be slightly changing the format to see how it affects the governance process. We’re trying to strike a balance between accessibility, depth of discussion, clarity of proposals and effectiveness of results. This time there will be just two phases: Discussion and Vote. The HOPR Association will present some draft proposals at the beginning of the discussion. There will then be a 72hr window to discuss the proposals, after which the HOPR Association will finalize the proposals based on the community’s input. These finalized proposals will then be put to a vote on our Snapshot page. The vote will last for 48 hours and votes will be counted quadratically. If you need a primer on quadratic voting, check out our quadratic voting games which we ran back in May this year. — Timeline - Phase 1 (Discussion) 17:00 Tuesday July 5th to 14:00 Friday July 8th on the HOPR forum, Transition (Proposals finalized) 14:00 Friday July 8th to 17:00 Friday July 8th, Phase 2 (Vote) 17:00 Friday July 8th to 17:00 Sunday July 10th on Snapshot, All times are CEST. — Rewards - Since we’re not running the full DAO process we won’t be employing our standard DAO incentive scheme, which relies on a series of data plugins tailored to the three-phase process on our forum. Instead, we’ll be issuing NFTs for participation across the two phases. NFTs will be issued according to the following system: Bronze: For anyone who participates in the vote phase, Silver: For anyone who participates in the discussion phase only, Gold: For anyone who participates in both phases, Diamond: For the top 5 contributors to the discussion phase, as determined by the forum moderators, Discussion participation will be assessed by the moderators and using the “active participant” forum data plugin. Earning an NFT requires active, constructive participation. Low-quality posts will be ignored and repeated spamming will result in being restricted from the forum. We usually have very high levels of participation with low numbers of Sybils, so we don’t expect to need to enforce this, but it’s important to state the rules up front. These DAO experiments are one of the most important and exciting parts of the HOPR project. We look forward to getting your input over the course of the week. Head to the forum to get started, and set a reminder to vote at the weekend! Sebastian Bürgel, HOPR Founder Website: Testnet: Twitter: Telegram: Discord: LinkedIn: Forum: Github: DAO Experiment v0.4 was originally published in HOPR on Medium, where people are continuing the conversation by highlighting and responding to this story.

HOPR vs OKB | A-Z | Topics | ISO 20022

Privacy | Terms | Contact | Powered By LiveCoinWatch