Say no to rugs

Trond Bjorøy
Trond Bjorøy
Published in
8 min readSep 20, 2021

--

PS: This piece was written before I started working at Hathor Labs.

If you’re new to Hathor and looking for an introduction, you might want to read my previous articles in chronological order first:

Hathor — bringing blockchain to the masses?

The bullish case for Hathor (and HTRFDT)

Hathor — making blockchain easy?

This piece will be a deep dive into a subject that deserves more attention assuming mass adoption is the goal here. We’ll look at some of the features that I believe will make Hathor’s ecosystem considerably safer and more transparent than any other layer 1 out there. Let’s jump right into it.

Native, nocode layer 1 tokens and contracts

When you mint a custom token or NFT on Hathor, it’s created on layer 1. Your token becomes a native asset built directly into the protocol itself, just like HTR. This is different from most other platforms. Your custom token also inherits all HTR properties and is secured by the network’s total hash power. The same will apply to any custom tokens running on side-DAGs when these are implemented.

Nano contracts will also be native. There will be a set of pre-made nano contract blueprints that anyone can configure (a nano contract is an instance of a blueprint like an object is an instance of a class in object-oriented programming languages). These blueprints will be like nano contract templates where you simply configure a few variables, with various blueprints catered towards different use cases.

Developers will also be able to write their own blueprints, likely using Python. Although still to be confirmed, it would make sense as most of Hathor’s code is written in Python. This means easier entrance for established non-blockchain developers who won’t have to learn any new languages, emphasizing the team’s intentions of making Hathor easily accessible to everyone.

Letting anyone write their own blueprints will allow for more flexibility and custom logic when the pre-made templates don’t quite cover the needs for a specific use case. There will be a process for submitting and approving new blueprints to the network, however, the details have not been shared yet. Once a new blueprint has been approved and verified, I expect there will be an option to share it with others to use in their projects too.

Nano contracts will likely be configurable from within the Hathor wallet, i.e., you’ll have a UI there to select a blueprint and configure the variables for your contract. You’ll also be able to view contracts and their contents in the explorer.

Native tokens and contracts mitigate the risk of bugs and security issues with custom development that we see on other platforms.

The approach to verified contracts will eliminate rugs and exploits caused by contract vulnerabilities, whether intentional from the developer or not. In addition, by only allowing verified contracts, Hathor removes the possibility for projects to replace secure and audited contracts with malicious ones.

We saw this happen with Compounder Finance. After a successful security audit, the developers swapped the safe and audited contract with a malicious one where they had snuck in a call function that allowed them to withdraw all funds. That was a good example of how smart contract audits often aren’t enough (for the record, in this case, the vulnerability was flagged in the audit but they were still able to pull the rug).

The level of transparency and pre-configured, native functionality that Hathor aims for leaves a lot less room for exploits and developer blunders, creating a safer, more user-friendly ecosystem for traders, investors, and builders alike.

Not to mention risk-averse legacy companies looking for a safe way to explore blockchain with limited technical resources and understanding of the technology.

Transparent mint/melt

When you create your token, you decide whether minting additional tokens should be possible, as well as melting. Anyone can view these settings on the explorer, and there’s no way to bypass them:

A “verified” token feature will be implemented to indicate whether a token has been verified and proven “safe.” Similarly, tokens confirmed to be scams, or malicious can be flagged to help prevent anyone from buying them. The same can be done with suspicious transactions.

Verified token, visuals subject to change
Banned token, visuals subject to change
Transaction involving a banned token, visuals subject to change

Report and Metadata APIs

The team will create a couple of new APIs to enable and make use of these flagging capabilities in both internal and external applications.

The Report API will let anyone flag suspicious or malicious tokens and transactions. Possible reasons for reporting could be “scam,” “impersonation,” etc. The details are still being discussed. Hathor Labs will probably implement report features in the wallet and explorer. Anyone building on top of the network can use the API to achieve the same within their applications.

Once a token or transaction has been successfully marked, the Metadata API will expose this information to the wallet and explorer and external developers who wish to implement it. In addition to showing details about tokens and transactions, the Metadata API will include information about blocks and other network details.

These APIs and features potentially mean that any Hathor user or third party building on top of the network gets a say in who is verified or marked as scams. Simply use the reporting feature in your favorite app.

We don’t know who will have the final word in the decision-making. I guess that could be an algorithm, e.g., based on a certain number of reports from unique users and apps, or a manual process.

I’m also guessing that projects officially partnering or working with Hathor Labs will be able to get a verified badge for their token, while others could apply for one, like a security audit.

Deposits as an incentive to do good

Hathor’s deposit mechanism (which eventually could make HTR into a deflationary asset with enough network adoption) should also contribute to a safer environment for users, traders and investors.

You can’t create a token on Hathor without depositing HTR, which costs money. And even if your token has the melt function enabled, you can’t actually melt any as long as they’re in investors’ hands. So once a project has been launched and tokens distributed, it becomes difficult for you to pull out or reverse anything as a token creator. The same applies to NFTs, whereas the details around nano contracts’ fee/deposit structure remain to be seen.

The PoWer of decentralization

Many people — I’m hoping the majority of them new to crypto — don’t seem to understand or appreciate the importance of decentralization in this space. It’s easy to get blinded by marketing narratives from 100 percent centralized networks run by a few powerful entities.

Why isn’t Hathor PoS, they’ll ask, unaware of or ignorant to the fact that PoW is the most decentralized, most battle-tested, and, when merge mined with Bitcoin like Hathor is, most secure consensus mechanism out there.

Hathor is fully decentralized in the sense that no entities control it or can stop or restart the network or its nodes when they want to, and anyone who wants to help secure and further decentralize the network can run a node on their regular home computer.

Being merge mined also makes Hathor’s hash power as decentralized as it gets and on par with Bitcoin. Aside from Bitcoin, Hathor’s hashrate is unmatched, recently having passed Bitcoin Cash and usually sitting between two to five exahash at the time of writing. I expect this to continue to increase as both price and network traffic go up (remember, like blocks, transactions on Hathor have to solve PoW, which effectively increases both security and decentralization).

Combine the network security with the native implementation of tokens and contracts, and you get the safest environment available to launch your blockchain project.

The centralized trap

Could Hathor Labs risk accusations of creating a centralized network by implementing solutions like the ones described here?

The network is fully decentralized today, and there’s no reason to think that the team is willing to risk the public’s perception of this by launching features or making decisions that some could choose to see as centralized. Instead, I trust their peer review process will help them figure out the best initial designs and that they will use client and community feedback to iterate from there.

I think it’s important that someone in the space dares to try to do things better and differently from everyone else. If the goal is mass adoption, we have to watch out for every normie that knocks on the door and make sure they feel comfortable and don’t lose all their monies on the first day (unless they do it leverage trading, then they have it coming). We can’t just invite everyone in and say, hey, just click this button here to create your token, and then close the door on them and leave them to get eaten alive by the degens.

However, no one should expect anyone to hold their hand and stop them from making stupid decisions in this new computing paradigm. Everyone needs to put in the work to figure out how stuff works and do their due diligence, but we should take measures to reduce the number of attack vectors and the likelihood of anyone getting scammed in the process.

Hathor Labs is providing a framework that enables a safe environment for all participants. Once all the features are live we need to see projects put them to use and make security an integral part of their UX.

Follow me on Twitter for more updates on Hathor.

Disclaimer: I am currently not associated with Hathor Labs. While I own some HTR, I have not received any compensation from Hathor Labs or any other party for this story. None of the above is financial advice; always do your own research before investing in anything.

--

--