malicious user can prevent trustee to register with valid trust

[hats-bug-reporter[bot]]

Github username: -- Twitter username: -- Submission hash (on-chain): 0xfe8439d72f4caa0a6592ef4839a64c1b8e762dea2ef06b7a99fc5c03fab264bf Severity: low

Description: Description\ The INVITATION_COST is burned when the trustee calls the registerHuman() function:

if (block.timestamp > invitationOnlyTime) {
                // after the invitation period, the inviter must burn the invitation cost
                _burnAndUpdateTotalSupply(_inviter, toTokenId(_inviter), INVITATION_COST);

                // mint the welcome bonus to the newly registered human
                _mintAndUpdateTotalSupply(msg.sender, toTokenId(msg.sender), WELCOME_BONUS, "");
            }

The issue arises when malicious user front-runs the trustee and transfers all tokens to another wallet, causing the trustee's registerHuman() transaction to revert because of insufficient balance to burn in truster address.

This report is similar to #10 but it's not duplicate because the root cause and the impact are different in this case.

If the trustee calls the isTrusted() function to check if the trust has not been terminated, he will see that everything appears normal because the trust remains intact.

As we know, after the invitationOnlyTime, new users need to be invited by already registered users, making user registration valuable. Therefore, users might trade for an invitation to the protocol, and the truster could exploit this issue to front-run the transaction and transfer tokens before the registerHuman() function is called by the trustee.

In the best-case scenario, this could be used to gas grief other users.

Recommendation\ Consider separating the invitation and trust mechanisms, and burn the INVITATION_COST when the invitation is made by the truster to avoid this issue.

[benjaminbollen]

Thank you for your report on the potential interference with trustee registration. After review, we've determined this is not an issue.

The scenario you describe is a natural consequence of blockchain transaction sequencing. If tokens are moved before registration, the registration will fail as expected.

We appreciate your attention to our trust system mechanics. Thank you for your participation in this security review.