Multiple Usage of Atoms in Triples Leading to Inconsistent State and Potential Insolvency

[hats-bug-reporter[bot]]

Github username: -- Twitter username: -- Submission hash (on-chain): 0x301f2aa465bc5205e1d38f7d64769bc92a3ca07464f32503718d3f282577bbfd Severity: high

Description: Description\ In the EthMultiVault contract, the createTriple function allows the same atom to be used in multiple triples. This design choice leads to several critical issues:

1. Inconsistent Share Tracking: The tripleAtomShares mapping doesn't account for atoms being part of multiple triples, leading to inaccurate share tracking.

2. Direct Deposits Inconsistency: Direct deposits to atoms are not reflected in the tripleAtomShares mapping, causing discrepancies between actual holdings and recorded shares in triples.

These issues can lead to protocol insolvency, incorrect share calculations, and potential exploitation of the system.

Attack Scenario\

1. Users depositing directly into atoms used in triples will have their shares underrepresented in the triple context.
2. Redemptions from triples may not accurately reflect the true asset distribution among atoms.

Attachments

   function testMultipleTripleInconsistency() external {
        // Create atoms
        uint256 atomCost = vault.getAtomCost();
        uint256 atom1 = vault.createAtom{value: atomCost}("atom1");
        uint256 atom2 = vault.createAtom{value: atomCost}("atom2");
        uint256 atom3 = vault.createAtom{value: atomCost}("atom3");

        // Set non-zero atomDepositFractionOnTripleCreation
        vault.setAtomDepositFractionOnTripleCreation(1 ether);

        // Create two triples using the same atom1
        uint256 tripleCost = vault.getTripleCost();
        uint256 triple1 = vault.createTriple{value: tripleCost}(atom1, atom2, atom3);
        uint256 triple2 = vault.createTriple{value: tripleCost}(atom2, atom1, atom3);

        // Check atom1's total assets
        uint256 atom1Assets = vault.vaults(atom1).totalAssets;

        // This assertion will likely show that atom1 has received double the expected deposit
        assert(atom1Assets == 2 ether);

        // Now try to redeem all shares from atom1
        uint256 atom1Shares = vault.vaults(atom1).balanceOf[address(this)];
        vault.redeemAtom(atom1Shares, address(this), atom1);

        // Check if we were able to withdraw more than we should
        uint256 finalBalance = address(this).balance;
        assert(finalBalance > 2 ether); // This might succeed, indicating over-withdrawal
    }

2. Revised Code File (Optional)
   • Prevent Atom Reuse:
   • Implement a check in the createTriple function to ensure that an atom is not already part of another triple.
   • Maintain a mapping of atoms to their associated triple (if any).
   • Pros: Simplifies accounting and prevents inconsistencies.
   • Cons: Limits flexibility in creating semantic relationships.

• Atom Locking Mechanism:

  • Introduce a locking system where atoms can be "locked" into a triple.
  • Allow atoms to be part of multiple triples, but only one "locked" triple at a time.
  • Implement special rules for locked atoms (e.g., different fee structures, withdrawal restrictions).
  • Pros: Balances flexibility and security.
  • Cons: Adds complexity to the system.

• Weighted Share System:

  • Instead of preventing reuse, implement a weighted share system for atoms in multiple triples.
  • When an atom is used in a new triple, recalculate its share distribution across all triples it's part of.
  • Pros: Allows flexible atom usage while maintaining fair distribution.
  • Cons: Increases computational complexity and gas costs.

• Separate Triple and Atom Economies:

  • Treat triple creation as a separate economic action from atom management.
  • Triple creation could "reference" atoms without directly affecting their underlying assets.
  • Implement a separate reward/fee system for triples.
  • Pros: Decouples atom asset management from triple relationships.
  • Cons: May require significant redesign of the protocol's economic model.

• Versioning System for Atoms:

  • Allow atoms to be used in multiple triples, but create a new "version" of the atom for each use.
  • Each version would have its own asset and share tracking.
  • Pros: Maintains atom uniqueness within triples while allowing reuse.
  • Cons: Increases storage requirements and complexity.

• Approval System for Atom Reuse:

  • Require atom creators or current stakeholders to approve the use of an atom in a new triple.
  • Implement a governance mechanism for this approval process.
  • Pros: Gives atom stakeholders control over reuse.
  • Cons: Adds friction to triple creation process.

• Dynamic Fee Adjustment:

  • Adjust fees and rewards based on how many triples an atom is part of.
  • For example, reduce the atomDepositFractionOnTripleCreation for atoms already in use.
  • Pros: Discourages excessive reuse without prohibiting it.
  • Cons: May lead to complex fee structures.