Thank you @ligi for great work!

Here are some additions:

We need different kind of stamps.

Two many stamps can be confusing. I would see only one stamp per independent audit.

Let see it from user’s perspective: the user will know if he can trust the code or not. He needs only the single high level message communicating if the code is OK or not.

Details are only interesting if the code is not OK.

So I would propose to organize all the stamps hierarchically with the single stamp at the top presented to User. If we have only one Stamp per Audit on the top level, we can combine many Stamps from independent auditors, which is usual praxis.

This top-level OK/FAIL should not only combine all partial “stamps” but also checks the completeness of implemented standards at the time of audit. It should also check the list of official claims made by author about the code (and used in his promotions).

This claims are free text Auditing Questions/Assurances, like that:

[YES/NO] This token has fixed supply

[YES/NO] This token has no super user

[YES/NO] This contract has emergency stop mode, which can be deactivated later [YES/NO]

Please note that there is no standards for all possible Audited Claims because they are free text, so it will not be possible to put some stamp as the sign of compliance.

By buying an Audit, the Author presents the list of the Claims he would like to have audited. If an Auditor accept the Claim List, it means he believes it makes some sense and can be meaningful audited.

Everything above is about positive stamps. I need to think more about negative stamps.