Supertree Reputation API
Reputation API for dApps managed by TCRs and funded via Superfluid protocol
Most crypto scams can be prevented today, with technology we have today!
Technologies like Superfluid and Solidity/EVM has evolved enough to help with this problem. We now have all the missing ingredient to keep users safe, or warn users when they transact using web3 and their crypto wallet.
Web3 offers immense potential, but to get there we need to de-risk and handhold the user as much as possible, without impeding the utility for the power users of this world.
Supertree API can help get us there sooner, by offering near real-time risk assessment for every dApp interaction.
In Depth
Let's look into the types of monetary loss the can happen to a user, and how...
- Phishing
- Rug pull
- Takeover attack of a reputable entity
- User Device tampering
- User Social engineering
We will only look at the 1-3 cases, as those we believe are common and yet not solved by technological means.
Phishing
A phishing attack is simply getting user to go to a domain that is trying to impersonate the legitimate entity. User does not notice a slighly differently spelled domain, they connect their wallet, transact without checking the details of the transaction and lose all their funds.
This attack is notoriously hard to prevent as we as users are asked to look out for UI differences, or errors in text/copy etc. A really determined bad actor will have no problem with crafting such site and fool even experts on a bad day. User is only a tap away via their email, tweet or sms message from landing on such site, and from there the experience can be identical to a legitimate site.
We have seen and reported sites that have been featured in Google Ads top positions for the brand of the entity like Aave or Near Protocol, which look 100% identical.
A failed web2 effort to prevent phishing was called EV (Extended validation) certificates but the subjective nature and manual/costly verification just cloud not scale to 1.8b websites. The number of web3 dApps is now experiencing a similar explosive growth, so this is our chance to do it right this time and stakes are even higher because users now connect their wallets with irreversible consequences.
Rug pull
In comparison to phishing, rug pull is when a dApp appears to be and operates legitimately at the beginning, but then at some point goes rogue. It could be a complete change of behaviour with no return. The founders or operators of the entity drain the users wallets and go on the run, or the dapp just targets the high net worth individuals, but works as expected for others, to try to stay longer undetected. The community members are often fooled en masse, and suffer the losses.
There could be also a slow decline of the dApp where founders and close collaborators just embezzle and mismanage the service over longer amount of time. Rug pulls can also happen after the original founders sell the entity to a dubious buyer. And these attacks can be on Front-End/Web layer or on smart contract layer (via some admin permission for example)
Takeover attack
The third case worth talking about, is a scenario where you as a operator of a site, suddenly find yourself under some external attack or breach. It could be a social engineering attack that allows attacker to make a code change on the Front-End or contract layer, or high jacking of DNS (Domain Name Service) records redirecting the site to a malicious actor.
Supply chain attach is another potential way, where dev tooling is used to trick the official developers accidentally pushing to production malicious code and not detecting the issue for some time.
Attacks like this happened in the past because of rogue employees too, but these normally prevented with internal restrictions and following best practices.
TCA (Token curated registries) to the rescue
TCAs seems like a promising solution to address all 3 of the attacks described above.
TCRs create a set of incentives between users and curators of the list to act in mutually beneficial way and avoid having a rogue dApp in the registry with the usage of staking (a deposit) and voting for or against addition and removals to the list.
What Supertree offers is a framework for efficient management of such lists forming list of lists that model a tree.
One of the major issues with existing TCPs is that the participation required is not always rewarded, so there is a lack of interested users that can vote on outcomes. Supertree offers a single unified api, with any fees that are earned are redistributed to the participants. The rewards flow down proportionally like in an up-side-down tree, to all the leaves. Large portions of required admin and voting is automated and off-chain with on-chain (monthly) voting commitments when rewards are allocated and distributed.
The different roles participating in this ecosystem are:
- End user
- API user
- Tree keepers
End Users simply use the wallets and tools that they are used to, but now the see a risk assessment in a form of a 0-100% or green, amber, red indicators. It's up to the wallet to decide how they would like to show this. This risk assessment is fluid. So for example if this site is very new to the parent list in the tree, it does not yet have a high amount of staked funds from other Tree keepers, so it's risk/safety value would be low. Similarly, if a site just had a recent update in its Front End codebase (automatically detected), then some Tree keepers would choose to de-stake temporarily to reduce their risk, so the risk/safety value will be again temporarily reduced. You, as a user can see this and be more cautious, or even be prevented from using the site by the wallet.
API Users are software toolmakers, most likely web3 wallets, that pay the fee for using the API. They pay a subscription, and the proceeds get distributed to all Tree keepers proportionally. The subscription fee also determines how often this API user can call the api for latest data.
Tree Keepers are the participants in the Supertree system, who can either just put up some capital into the lists in the tree that they are knowledgeable about or propose new additions, removals or moves of content. These users use a streaming protocol rather than a single time transfer to lock up their stake, which means that with time the amount that they lock up decreases, and eventually the only thing they are risking is the future profits/fee return from the system. Tree keepers can de-stake off-chain in almost real time, if they see that the risk of a list or a single item in the list increases. They get rewarded by being fist to detect the risk, and after de-staking they give up any earnings from the API fees for these items in the list, but by being first they will earn a percentage of any subsequent de-staking by others. This way if a FUD (Fear, Uncertainty and Doubt) about a dApp spreads, those that started it or first to detect get a reward.
Monthly reconciliation
Any off-chain signals/de-stakes etc all get voted on in bulk once a month on-chain, and the earnings are distributed to the whole Supertree ecosystem gets redistributed using Superfluid IDA (Instant Distribution Agreement)
API
Finding a single entry
curl -u ADDR:KEY https://api.futurepeer.io/supertree/entity \
?parentId=######&content=somedapp.com
Response
{
"id": "######",
"parentId: "######"
"content": "somedapp.com",
"type": "leaf",
"rep": 0.878908
}
Getting a content of a list
curl -u ADDR:KEY https://api.futurepeer.io/supertree/entities \
?parentId=######&from=######&flatEntities=0
Response
{
"entities": [
{
"id": "######",
"parentId: "######"
"content": "somedapp.com",
"type": "leaf",
"rep": 0.878908
},
{
"id": "######",
"parentId: "######"
"content": "somedapp.com",
"type": "node",
"rep": 0.878908
}
],
"nextCursor": "######"
}
Entities can be flattened out and paginated indefinitely, or can be left not flattened.
In addition to just dApp urls, Supertree can also hold ENS names and smart contract addresses that are highly used and trusted.
Tree keepers can develop their own autimation and insights on how best to detect bad actors or reduce risk/exposure via scanning of domains for code changes, scanning DNS for tampering or using any other 3rd party sources like social media for user sentiment.
If you are interested, or know someone would like to take part in the development of Supertree API, please get in touch by leaving your email below.
EDITED: 3 Thu 2022