Skip to content
Open
Changes from 4 commits
Commits
Show all changes
21 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
86 changes: 86 additions & 0 deletions src/interfaces/IHookMetadata.sol
Original file line number Diff line number Diff line change
@@ -0,0 +1,86 @@
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

interface IHookMetadata {
/// @notice Represents the auditor
/// @param name The name of the auditor.
/// @param uri The URI with additional information about the auditor.
/// @param authors List of authors responsible for the audit.
struct Auditor {
string name;
string uri;
string[] authors;
}


/// @notice Represents a summary of the audit.
/// @param auditor The auditor who performed the audit.
/// @param issuedAt The timestamp at which the audit was issued.
/// @param ercs List of ERC standards that were covered in the audit.
/// @param bytecodeHash Hash of the audited smart contract bytecode.
/// @param auditHash Hash of the audit document.
/// @param auditUri URI with additional information or the full audit report.
struct AuditSummary {
Auditor auditor;
uint256 issuedAt;
uint256[] ercs;
bytes32 bytecodeHash;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i do wonder how practical a bytecodeHash is in practice? It changes even you change the optimiser runs, sometimes if you the deploy parameters, and other very small tweaks - and because its not reversible it might become impossible to see what someone actually audited?
If you have a bytecodeHash from an auditor... how are you meant to find the version of the code that they audited?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just thinking out loud here, it still might be the best option. But just wondering if youve thought this through

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I think we are talking about the next options here:

  • commit hash - I don't this reasonable because someone can actually change the code during the deployment and you have to read an actual contract code anyway. But would love to hear your opinion;

  • bytecodeHash - I think we can also ask devs to deploy with some specific params for optimiser, etc, to be able to allow onchain audit verification. As for deploy parameters - I think we can focus only on the code itself without constructor params;

how are you meant to find the version of the code that they audited?

So, I think the regular flow - they have to have a link to the repo on their website, commit hash, etc. But as for the onchain verification I see bytecodeHash as only one possible option

bytes32 auditHash;
string auditUri;
}


/// @notice Defines different types of signature standards.
enum SignatureType {
SECP256K1,
BLS,
ERC1271,
SECP256R1
}

/// @notice Represents a cryptographic signature.
/// @param signatureType The type of the signature (e.g., SECP256K1, BLS, etc.).
/// @param data The actual signature data.
struct Signature {
SignatureType signatureType;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What was the motivation for removing the EIP712 stuff? Happy either way just interested :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I think we want to provide more flexibility in terms of what should be inside of hash for the signature since we can't define function eip712Domain specifically in the interface

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One of the main benefits of EIP712 domain signatures would be for DeFi protocols to prevent replay attacks on their signed limit orders using the chain id, contract address, etc... as parameters. In this case there is nothing anyone can do with a signed audit payload so it doesn't need that extra security. I do think a domain separator could add some specification around what is being signed here but it's not necessary

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I agree. + we removed it to provide more flexibility actually

bytes data;
}

/// @notice Represents a signed audit summary.
/// @param summary The audit summary being signed.
/// @param signedAt Timestamp indicating when the audit summary was signed.
/// @param auditorSignature Signature of the auditor for authenticity.
struct SignedAuditSummary {
AuditSummary summary;
uint256 signedAt;
Signature auditorSignature;
}

/// @notice Returns the name of the hook.
/// @return The hook's name as a string.
function name() external view returns (string memory);

/// @notice Returns the repository URI for the smart contract code.
/// @return The repository URI.
function repository() external view returns (string memory);

/// @notice Returns the URI for the hook's logo.
/// @return The logo URI.
function logoURI() external view returns (string memory);

/// @notice Returns the URI for the hook's website.
/// @return The website URI.
function websiteURI() external view returns (string memory);

/// @notice Returns a description of the hook.
/// @return The hook's description.
function description() external view returns (string memory);

/// @notice Returns the version of the hook.
/// @return The version identifier as bytes32.
function version() external view returns (bytes32);

/// @notice Returns all audit records of the hook.
/// @return An array of SignedAuditSummary structs containing audit summary and signature details.
function audits() external view returns (SignedAuditSummary[] memory);
}
Loading