Does the use of a nested mapping possess any threats to the security of the contract below?

contract Users {

    struct User {
        address payable regAddress;
        uint64 timestamp;
        bool registered;
        string name;
        string surname;
        uint nonce;

    mapping(string => mapping(string => mapping(uint => bool))) public isRegistered;
    mapping(bytes32 => User) public users;

    function registerUser(string calldata _name, string calldata _surname, uint _nonce) public returns (bytes32) {
        require(!isRegistered[_name][_surname][_nonce], "This profile is already registered");
        isRegistered[_name][_surname][_nonce] = true;
        bytes32 ID = keccak256(abi.encodePacked(_name, _surname, _nonce));
        User storage user = users[ID];
        user.regAddress = payable(msg.sender);
        user.timestamp = uint64(block.timestamp);
        user.registered = true;
        user.name = _name;
        user.surname = _surname;
        user.nonce = _nonce;

        return ID;


Looks to me like there shouldn't be any issues, but aren't there any potential threats of a Denial of service attack, for example?


1 Answer 1


No. The only (very theorical) issue with mappings are hash collisions. Basically, the storage slot for a mapping's entry is the hash of its key, so you could theorically end up with 2 different keys resolving to the same slot (congrats btw, that means you broke keccak256), but yes, in practice that's never gonna happen

  • thanks a bunch!
    – Mila A
    Jul 2, 2023 at 15:01
  • would you mind sharing if you can see any vulnerabilities in the contract itself, considering the contract will be used by other external contracts as a registry of users and will later attach some permissions (think "rights") based on the user's ID? My guess is that if the user changes his name/surname later (if there's an updateProfile() function), and considering that some external contract attached the rights to the user's ID, the user's ID will get changed as it's just an encoded packed value of user's name, surname and nonce, the wrong user will get those rights.
    – Mila A
    Jul 2, 2023 at 15:21
  • 1
    Well that would indeed be an issue if the user's ID can change (imo it shouldnt). Also, we have a built-in way of identifying unique users in Ethereum, it's called addresses. Any reason why you're not using those directly? @MilaA
    – Foxxxey
    Jul 2, 2023 at 16:48
  • thanks a bunch for your reply. Yes, I agree. This contract is a part of a smart contracts hacking testing I'm currently passing, and that was a requirement that the user should be identified by his id, not his address "because one user can have multiple addresses". That's just a requirement, but I think it's a bad design principle
    – Mila A
    Jul 4, 2023 at 10:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.