DecentHats module #93
Conversation
contracts/DecentHats.sol
Outdated
|
|
||
| constructor(IHats _hats, address _keyValuePairs) { | ||
| bytes32 public constant SALT = bytes32(abi.encode(0xdece974a75)); |
There was a problem hiding this comment.
Just wondering where this SALT is coming from? Maybe that's reasonable to add a comment about it?
There was a problem hiding this comment.
Yeah good call. Just made it up. I'm pretty sure it doesn't really matter, is just used in deterministic address generation via the internal create2 call that the registry contract makes.
decenthats in leetspeek
There was a problem hiding this comment.
i should probably do something more proper here
There was a problem hiding this comment.
Updated, idk if this is proper enough though
| // SPDX-License-Identifier: MIT | ||
| pragma solidity ^0.8.4; | ||
|
|
||
| interface IERC6551Registry { |
There was a problem hiding this comment.
Does this mean we have custom registry deployed? Can't we use one from https://github.com/erc6551/reference
There was a problem hiding this comment.
We will not have a custom registry deployed. This Interface is included in our codebase so that I can have proper solidity typing in DecentHats when i call the registry to create new Smart Account instances.
| // SPDX-License-Identifier: MIT | ||
| pragma solidity ^0.8.4; | ||
|
|
||
| interface IERC6551Registry { |
There was a problem hiding this comment.
Same question as above - can't we leverage existing package as a dependency?
There was a problem hiding this comment.
This is just a Mock used for Testing
| function tokenId() public view returns (uint256) { | ||
| bytes memory footer = new bytes(0x20); | ||
| assembly { | ||
| // copy 0x20 bytes from final word of footer |
There was a problem hiding this comment.
I know that's not related to this PR and rather to Hats Protocol implementation of HatsAccount - but why final word of a footer? Just curious
There was a problem hiding this comment.
When a new ERC6551 contract is deployed from the Registry, the Registry appends some metadata data to the end of the contract bytecode. That metadata includes the NFT contract address and NFT token ID that this contract belongs to.
So, all we're doing with these functions is exposing those properties.
…count which will be cloned via registry
adamgall
force-pushed
the
create-erc6551-accounts
branch
from
27c6b7a
to
ea020e5
Compare
* Create DecentHats contract, and some helpers * Create tests for CreateTopHat * Add support for creating and minting admin and child hats * Fix tests * Add the IERC6551Registry.sol interface * Add the canonical implementation of ERC6551Registry for mock and test purposes * Create a mock contract which acts as an implementation of the Hats Account which will be cloned via registry * Deploy instances of Smart Accounts for the newly created Hats * Add comment * Less rigid test * Update SALT * Use smaller import * Update name of KeyValuePair key * DecentHats is wearer of TopHat until end of transaction * Update parameter order
Closes #92
Closes #94
See also #91
This PR implements a contract called
DecentHatswhich will be temporarily added as a module to Safes, in order to create and configure a Hats tree for that Safe.It also includes support for deploying instances of ERC6551 "Smart Accounts" for each new Hat.
In live environments, we'll use the
HatsAccount1ofNimplementation, which is deployed to various chains at address 0xfEf83A660b7C10a3EdaFdCF62DEee1fD8a875D29.The
ERC6551Registryalso has a canonical address on all chains: 0x000000006551c19487814612e58FE06813775758.