createHatできる人の制御の仕方を検討・実装

[yu23ki14]

Issue

Description

HatプロトコルではcreateHatできるのはAdmin（親HatもしくはTopHatのwearer）のみになっている。
そこで、Toban上でcreateHatできる人をどのように制御するかが問題になる。

ぱっと思いつくオプションは以下

• HatterHatとしてtimeframeHatterModuleだけでなく、HatsHatCreatorModuleコントラクトをつくってToban独自のルールでcreateHatできるようにする。

Notes

• ファイルは /contract/contracts/hatsmodule/HatsHatCreatorModule.sol にする
• 機能
  • createHatができる人をアドレス単位で制限できるようにする
    • 権限の追加・削除（grantとrevoke）ができるようにする
  • Hats.solのcreateHat関数を叩く
  • BigBang.solのbigbang関数の実行をしたら、hatsTimeframeModuleと同じようにデプロイされて、HatterHatがミントされる

Screenshots

If applicable, add screenshots to help explain your problem.

[tanapl]

@yu23ki14

I’ve successfully built a custom HatsHatCreatorModule that deploys from BigBang.sol and controls who can call createHat(...). The core flow is in place:

• BigBang mints a topHat to itself (address(this)),
• creates a new sub-hat via Hats.createHat(...),
• deploys HatsHatCreatorModule and HatsTimeFrameModule,
• then transfers the topHat to _owner.
• includes grantCreateHat and revokeCreateHat so its owner can add or remove permission

However, the test is failing with “Transaction reverted without a reason string,” likely due to a silent revert in one of the Hats calls (e.g. createHat, mintHat, or transferHat). The usual culprit is an admin check in Hats (the caller must still be wearing the admin hat). I'm verifying that...BigBang? (address(this)) remains the topHat’s wearer at the time of calling createHat(...). Console logging or try/catch around each step can pinpoint exactly where it reverts and confirm the admin logic. Once that’s resolved, the HatsHatCreatorModule integration should work as intended.

main...issue/235