masataka-eth/contractallowlist

contractallowlist's Issues

LockStatus.CalLock状態のトークンをapproveしたときの挙動について

LockStatus.CalLock状態のトークンは、どんなoperatorに対してもapprove可能であるが意図したものでしょうか？
CALによるoperatorブロックは、setApprovalForAllのみに効果があり個別設定のapproveは対象外でよかったでしたっけ？
それとも、これは意図しない不具合でしょうか？

実際の処理コードは下記になります
if (status == LockStatus.CalLock) {に入った場合、 if (ownerOf(tokenId) == msg.sender) { にelseがないため、returnはfalseに固定されておりif判定が機能していないように見えます。
ここでoperatorを含めた何らかの判定の意図があったのでしょうか？
修正方法をご相談したくIssueを切りました

    function getTokenLocked(address operator, uint256 tokenId) public virtual view returns(bool isLocked) {
        address holder = ownerOf(tokenId);
        LockStatus status = _getLockStatus(holder, tokenId);
        uint256 level = _getCALLevel(holder, tokenId);

        if (status == LockStatus.CalLock) {
            if (ownerOf(tokenId) == msg.sender) {
                return false;
            }
        } else {
            return _getLocked(operator, status, level);
        }
    }

1万点を超えるコレクションでそのまま利用するとbalanceOfがブロックガスリミット超過でエラーになる

素のPsiでは_startTokenIdから_nextTokenIdまで_existsとownerOfを繰り返すため、トークン数が多いとエラーになります。

tokenCALLevelとwalletCALLevelが標準実装であるべきか否か

現状の設計は
・walletまたはholderの選択が優先される
実情として
・CALLevelはほとんどが1に設定されている
・walletまたがholderが選択的に2を使用でき、運営サイドではこれを受け入れるしかない

Blurの追加の話もありましたが、walletとして2にしておけば、運営サイドとしてはBlurは使わせたくない！と思ってもCALに登録されていれば、ホルダーが自由に選択することができます。これが目指している仕様でしたか？

もう一つの現実の課題として、この2つを使ってることはまずなくて(私が知らないだけかもしれませんが)、特にtokenCalLevelはtransferのたびに0⇒0という操作をして、storage読み込みと同値書き込みのために2500ガスくらい(optimizerによる)消費すること、またバイトコードサイズも大きくなるので、本当にこの2つが標準的に実装されるべき機能なのか、検討する価値があると思います。

ERC-20に判定される

supportsInterfaceの実装の問題により、etherscan やOpenSeaにおいて、erc721と判定されない。
その結果、下記の現象が発生する。
・etherscanでerc721トランザクションが確認できない
・OpenSeaでトータルボリュームトレードが0のまま増えない → こちらは解消されたのでOpenSeaの不具合だったかも

token