2 and more tripple vaults can exist for the same 3 mini vaults

[hats-bug-reporter[bot]]

Github username: @0x3b33 Twitter username: -- Submission hash (on-chain): 0x4b9037273954ca5fa9a6d761eb614b4178055290ec8bf8db27225a5ac7097f8d Severity: low

Description: Description

When _createTriple creates our triple vault, it checks a few things:

1. If the mini vaults exist.
2. If the mini vaults are triple vaults.

        uint256[3] memory tripleAtomIds = [subjectId, predicateId, objectId];

        for (uint256 i = 0; i < 3; i++) {
            // Ensure atoms exist; otherwise, revert.
            if (tripleAtomIds[i] == 0 || tripleAtomIds[i] > count) {
                revert Errors.MultiVault_AtomDoesNotExist(tripleAtomIds[i]);
            }

            // Ensure each ID is not a triple vault ID.
            if (isTripleId(tripleAtomIds[i])) {
                revert Errors.MultiVault_VaultIsTriple(tripleAtomIds[i]);
            }
        }

3. If they are already used in another triple vault.

        // Check if triple already exists.
        bytes32 hash = tripleHashFromAtoms(subjectId, predicateId, objectId);
        if (triplesByHash[hash] != 0) {
            revert Errors.MultiVault_TripleExists(subjectId, predicateId, objectId);
        }

Later, our new triple hash is saved inside triplesByHash, and our mini vaults are saved corresponding to the triple ID.

        triplesByHash[hash] = id;
        // Map the triple's vault ID to the underlying atom vault IDs.
        triples[id] = [subjectId, predicateId, objectId];

However, it's important to note that tripleHashFromAtoms can produce a unique hash for every order of the same mini vaults. Changing the order of vault 1 and 2 can generate a new hash, creating a new triple vault with the same three vaults inside. In the current state with 3 mini vaults it's possible to create 6 unique tripple vaults.

This behavior may be acceptable within this system, but integrators may find it tedious or even risky to manage.

Recommendations

Mark the three mini vaults as already used in a triple and forbid their further use in other triples.

[mihailo-maksa]

The concern about multiple triple vaults existing for the same three mini vaults has been carefully examined. Here is our detailed response:

Intended Design: The creation of multiple triple vaults using the same mini vaults in different orders is a deliberate design choice. Our system permits this flexibility, allowing users to define triples in the manner that best suits their needs.

Market Validation: This design leverages the power of the free market to determine the value and relevance of different triples. By allowing variations in the order of mini vaults, we enable a diverse range of claims and assertions, which can be evaluated based on their utility and importance.

Integration Considerations: Contrary to concerns about integration difficulties, our system ensures that each triple, regardless of the order of its components, is unique and identifiable. This approach does not introduce any integration risks or management issues, as each triple is distinct within the protocol.

Conclusion: The ability to create multiple unique triples from the same set of mini vaults is an intentional feature that enhances the system's flexibility and robustness. It does not pose any risk to system integrity or external integrations.

Therefore, we consider this behavior to be functioning as intended and beneficial to the overall ecosystem, and for that reason, the issue is classified as invalid.