ERC-7512: Onchain Audit Representation

ERCs
2

The idea of having on-chain audits is useful. However the implementation proposed in this ERC is overcomplicated significantly.

The goal of having on-chain audit registry is to allow contracts to verify if a contract is secure or nobody ever reviewed it (the fact that it was reviewed and assigned a “secure” label does not automatically mean that it is really secure however).

Taking this into account lets review audit properties:

  • Auditor - Do we need it at all?
    • name - well, there are better ways of recognizing auditors. For example just keep a track of auditors addresses in an open registry and let contracts match the issuer of the on-chain report against one of the auditors publicly available addresses.
    • uri - it doesn’t tell contract anything. A human can follow the link and read whatever is written there but not the contract.
    • authors - it doesn’t tell contract anything.
  • Audit
    • auditor - ok
    • contract - ok, chainID and address are useful.
    • issuedAt - may be
    • ercs - why is it important at all? I don’t think that a contract may want to conduct this type of standard recognition via audit reports instead of ERC-165 for example. Also, USDT is not compliant with ERC-20 spec, do you expect some auditor like OpenZeppelin or CertiK to say “USDT is not a ERC-20 token”?
    • auditHash - ok
    • auditUri - ok

Auditor Verification

Why would someone need such a complex system of auditor verification if that same task can be accomplished in a much easier way - just let auditors submit audit reports from a publicly known address and match addresses to the name of the auditing company.

Like 0x111111 is OpenZeppelin
0x222222 is CertiK
0x333333 is Callisto Audits
etc.

You don’t need such a complex structure and the whole load of processes for signing / verifying if it can be done in a way that would allow even a technically inexperienced user to verify who is the auditor.

The current ERC does not have any mentions of the findings of an audits.

This is the most crucial part honestly. There can be multiple audit reports for one contract and if at least one indicates a problem with the contract - it is more important than all other reports that do not indicate any problems with this exact contract.

If you have 3 auditors who have reviewed one contract, two of them found nothing and the third found a critical vulnerability - it’s much more logical to indicate that “the contract might have a critical vulnerability” rather than resort to an assumption “if there is at least one audit report that doesn’t indicate any problems then the contract is most likely safe”.

I think that a system that does not allow for findings specification and independent audits submissions for multiple different auditors - will not work or even worse it will deceive users into thinking that some contract is secure while in fact there are problems with it.

3 Likes