hats-finance / Intuition-0x538dbadc50cc87b281cd655f1edbc6ebda02a66a

The smart contracts of the Intuition protocol v1.
https://intuition.systems
Other
0 stars 1 forks source link

The users can create Triples using only One Atom #41

Open hats-bug-reporter[bot] opened 1 week ago

hats-bug-reporter[bot] commented 1 week ago

Github username: @Al-Qa-qa Twitter username: al_qa_qa Submission hash (on-chain): 0x590efc11e1735caefc941a4b813422392ade726f0329ac1117feaa01cc1b8388 Severity: low

Description: Description\ When Creating triples, there is no check if the ATOM IDs differs or not. So a user can only create one atom, and be able to create Trible with only that one ATOM ID.

EthMultiVault.sol#L586-L598C10

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

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

            // make sure that each id is not a triple vault id
            if (isTripleId(tripleAtomIds[i])) {
                revert Errors.MultiVault_VaultIsTriple(tripleAtomIds[i]);
            }
        }

As we can see there is no check weather the ATOM IDs is unique or not, which is not a realistic case to create a triple using only one ATOM vault.

Although it is tolerated for Semantic triple to duplicate values, in our Code, it is not a good thing to let it occuar as there are Vaults that are created, and other logics that are build in top of this.

Recommendations Check that the provided IDs is unique and no one has the same value as the other.

mihailo-maksa commented 4 days ago

The reported issue regarding the potential duplication of atom IDs in the creation of triples has been thoroughly reviewed. Here is our detailed perspective:

Intended Functionality: Allowing identical atom IDs in a triple is an intentional feature. Our system is designed to be flexible, letting users decide the composition of their triples based on their needs and the market's dynamics.

Market Dynamics: By not enforcing unique atom IDs within a triple, we empower the market to naturally determine the value and utility of each triple. Users are free to create triples as they see fit, and the ecosystem will self-regulate based on the perceived value of different configurations.

System Integrity: This approach does not introduce any harm or security vulnerabilities. The primary requirement is that triples are composed of valid atoms, and this condition is maintained regardless of whether the atoms are unique within the triple.

Conclusion: While the lack of a uniqueness check for atom IDs within a triple might seem unconventional, it aligns with our system's philosophy of flexibility and market-driven validation. Therefore, we do not consider this a vulnerability but rather a feature that supports user autonomy and market efficiency, and the report is considered invalid.