Honest Protocol v0.1 Design Proposal


The HonestNFT core team has spent countless hours analyzing NFT collections over the last year. We’ve utilized our data science and forensics expertise to identify opportunities for improvement in NFT launch mechanisms. While we’ve had some success conducting public audits and advising projects on mechanisms for their NFT launches, we think we’ve identified a more scalable solution for NFT creators and collectors.

We propose building a generalized trust and curation protocol for Ethereum, tentatively called Honest Protocol. The general idea is to have a trustless database of labels that characterize NFT collections, especially as it relates to consumer protection. To achieve this, we propose creating an on-chain mapping between NFT collection smart contract addresses and key/value pairs to be curated by members of the HonestNFT community. Once these labels are deployed, we propose enabling developers of applications that display NFTs (e.g. marketplaces, explorers, portfolio trackers, etc.) to curate NFTs utilizing an on-chain filter that is defined by the HonestNFT community, the application developers, or the application user.

We believe that this infrastructure will serve as the basis for permissionless and trustless curation of crypto assets on the Ethereum blockchain, starting with NFTs.

Proposed Architecture

The proposed architecture defines how various actors may interact in the ecosystem. We propose developing a consensus mechanism whereby Auditors are incentivized to add labels and associated proofs to the protocol and Verifiers are incentivized to verify the truth of the labels provided by the Auditors. On the other hand, Curators may consume badges from the protocol that are defined by logic that they develop. Curators would use such badges to filter displays / recommendations of NFTs on their platforms. NFT communities observe outcomes on the platforms they frequent and develop values as a result of what they observe. Curators assess the values that NFT communities develop and develop logic that generates badges.

Through this cycle of incentivizing honest characterization of NFT smart contracts and observing outcomes and values, we think communities can converge on curation mechanisms that better reflect their values. The protocol will be permissionless so that anyone can create a filter and observer the outcomes associated with that filter.

Below we provide more description of the various components of the protocol architecture.




  • Review labels and proofs submitted by auditors
  • Agree with label value that was submitted by an auditor
  • Dispute a label value that was submitted by an auditor
  • Approve / reject proposals for new label / proof combinations


  • Create value by verifying validity of labels
  • Effect the downstream filtration / curation of NFT smart contracts



  • Commit label value pairs and corresponding proofs
  • Propose new labels and proofs for the ecosystem
  • Design proofs for new labels
  • Assess the impact of labels on the NFT market


  • Create value by expanding the scope of filtration / curation of NFT smart contracts
  • Increase transparency for NFT smart contracts
  • Effect the downstream filtration / curation of NFT smart contracts



  • Define logic used to filter / curate NFT smart contracts
  • Deploy new filter smart contracts
  • Consume badges that can be used to filter / curate NFT smart contracts
  • Observe and assess the value systems used by NFT communities


  • Curate lists of NFT smart contracts for users
  • Protect web3 users from malicious or scam NFT collections

NFT Creator


  • Request a mechanism audit for a deployed NFT contract (pre or post mint)
  • Stake value that NFT launch will have a given post-mint score
  • Learn best practices for launching NFTs
  • Fetch examples of audited NFT contracts that meet necessary project requirements


  • Capture as much value as possible from project
  • Protect users from being scammed by other copy-cat projects
  • Have a new channel for distribution
  • Ensure that users are able to view NFTs on curated platforms



  • A well-defined objective attribute for an NFT smart contract
  • Value for each label should map to a bool


  • Pointer to a well-defined test that determines the value of a label
  • Could take the form of a script, a dune query, list of transactions, etc.
  • Must be reproducible
  • Must yield a binary outcome, even if the test is statistical in nature


  • Process where Verifier disagrees with the value of a label
  • Process ends in reversal of label to previous state, nullification of label, or no change


  • Process by which Verifier adds confidence to a label value pair after verifying proof


  • Logic that defines rules for validation of an NFT smart contract
  • Array of bools


  • Validation result from a filter applied to label values
  • Yielded badge should be a bool

Protocol Components

Label Contract


  • Consensus mechanism


  • Add new label value pair
  • Update label value pair
  • Get value of a label for a given smart contract address

Filter Factory Contract


  • Label contract
  • Filter


  • Generate new filter
  • Fetch address of filter contract with given logic

Filter Contract


  • Label contract
  • Filter factory contract


  • Fetch badge for a given smart contract address

Consensus Mechanism


  • Dispute
  • Agreement
  • Label
  • Proof


  • Propose a new label value pair
  • Dispute validity of a label value pair
  • Agree with a label value pair
1 Like

Hi all,

Thanks for starting a discourse. The signup confirmation mail ends up in gmail spam, so perhaps set up Mailgun?

The technical details of the proposal are out of my league. But if you continue your auditing, I think you’ll end up with sufficient credibility to provide some kind of certification for an NFT project before their launch. Reassuring potential buyers that the project at least ticks some of most important boxes. Start centralized, but automate/decentralize what is working and becomes redundant for each a priori audit.

There are entire businesses built around certification, for instance in health care. They took it too far though… (but that’s a different topic).

Thanks for starting a discourse. The signup confirmation mail ends up in gmail spam, so perhaps set up Mailgun?

Heh yea we ran into this problem too. We’ll look into mailgun.

So definitely the first certification we want to do is “USED_COMMIT_REVEAL”.
The reasoning for doing commit-reveals first is:

  1. A proper commit-reveal scheme actually does a lot for investor confidence. You know insiders couldn’t have minted rare NFTs to themselves or screwed with the secondary market pre-reveal. I feel strongly that a healthy market should demand commit-reveal schemes.
  2. They’re pretty easy for a technical user to verify but sometimes time-consuming.
  3. We can deploy it without a proper consensus mechanism because there shouldn’t be much to dispute about whether or not a commit-reveal was valid.

The consensus mechanism is going to be the hardest thing to build here. I’m kind of leaning towards something similar to Augur V2 but without the prediction market part. So just a “truth market”. Augur is pretty resilient to manipulation and as far as I know, the biggest issues have been 1) gas is expensive, 2) people abused the “invalid market scam”. Since we aren’t building a prediction market I think these two things won’t be much of an issue.

1 Like

Could this protocol be generalized to audit smart contracts?

i.e the labels can be used to tag common bugs such as reentrancy errors, over/under flows. They could also be used to flag if code is using audited libraries like Open Zeppelin.

The main idea being self regulation to not only prevent malicious actors but also encourage good practices in any dApp project.

This is definitely a use case we could explore. We’d need to make sure that we understood well what are the most high value labels to create for this use case and think through how to make the labels objective and the proofs verifiable.

Imo any use case that requires some form curation by another smart contract downstream is possible with this design.

We’re starting with NFTs primarily because that’s what our community understands better than anyone else.

That’s great to hear. I look forward to contributing to this project to the best of my capacity.

I’m a big fan of the concept of self regulation to make this space a safer place. The Wild West needs to create its own rules before we modernize our towns even if it has to stem from vigilante justice :slight_smile:

Am I right in understanding that the 3777 NFT/ will serve as a reputation and access token in this protocol?

1 Like

We’re still architecting the details of protocol design and I’m not sure if the 3,777 tokens will function as reputation tokens. The shadowy super coder and crypto sleuth soulbond NFTs will likely be used as reputation tokens for some early alpha tests.

I definitely want the 3,777 NFTs to serve as the testbed for a bunch of different types of labels though.

There’s a lot of benefits to testing out parts of the Honest Protocol (and other interesting governance ideas) on an NFT collection that we [Convex] have a bunch of.

Having some control over the smart contract can also make certain things easier (although I hope to transferOwnership on the Vigilante ERC-721 contract over to an arbitrarily complex multi-sig at some point in the future).

1 Like