Vault #220

markspanbroek · 2025-02-06T15:45:36Z

Adds a Vault contract, that allows funds to be locked up for a certain amount of time. These funds can be transferred, burned or even flow over time to other addresses.

Follows the design from codex-research/design/contract-deployment

~~Requires #219 to be merged first.~~

markspanbroek · 2025-02-20T14:24:55Z

Added functionality to have multiple accounts for an account holder inside a fund. This ensures that in the codex marketplace we keep funds for the client and for each slot separate, even though some providers may choose to fill multiple slots, or a client might decide to fill a slot in the storage contract itself.

markspanbroek · 2025-02-24T15:15:30Z

Replaced 🔥 burnFund() with ❄️ freezeFund().
Freezing a fund stops all flows and disallows any further changes to the fund until it unlocks.

emizzle

Really great job Mark! Huge effort 💪 🙌

This was quite a lot to go through. I used the implementation branch (master...vault-integration#diff-5973808e32384782b5978a63e85b893b67d634be8aa42001f0ef480f189a0688R179) to get a better understanding of how some of the functionality relates to the Marketplace.

One question:
When we discussed freezing the vault, we discussed that it would not be able to be unfrozen by a controlling party. In this implementation, unfreezing happens after some time has elapsed, making the funds withdrawable again. Is the idea here that in the case of an attack, the vaults would all be locked in some way with a very long expiry?

contracts/vault/VaultBase.sol

contracts/vault/Locks.sol

contracts/vault/VaultBase.sol

AuHau

Great work Mark! 🎉

I don't see any big problem with the general approach and design here. My only concern is the usage of the uint128 for the balance tracking. See my comment bellow.

This is big PR, so this is just my first iteration of review. Will do more later on.

contracts/Vault.sol

contracts/vault/Accounts.sol

contracts/vault/VaultBase.sol

contracts/vault/Locks.sol

markspanbroek · 2025-03-03T13:11:45Z

Thanks for the good feedback @AuHau and @emizzle. I think I addressed most of the naming concerns.

One question:
When we discussed freezing the vault, we discussed that it would not be able to be unfrozen by a controlling party. In this implementation, unfreezing happens after some time has elapsed, making the funds withdrawable again. Is the idea here that in the case of an attack, the vaults would all be locked in some way with a very long expiry?

The freezeFund() function only freezes a single fund, meaning that there can be no transfers or flows anymore until the fund unlocks and withdrawal can happen. This can happen in the marketplace when a storage request fails. The freezing functionality that we discussed and wrote down in the design document is different. This is about freezing the entire contract, allowing only withdrawals, in an emergency situation where our contracts are under attack. This is implemented by the vault through the use of the Pausable contract.

contracts/vault/VaultBase.sol

Updates to the API of the Vault contract as worked on in codex-storage/codex-contracts-eth#220 Most important changes: - token transfers are much more restricted in the vault, improving its safety - when a storage request fails, only the providers at fault are punished, the rest are not - when a storage request fails, the client is only reimbursed for the remaining time in the contract - no longer possible for the marketplace to request one final storage proof before allowing withdrawal - repair reward is temporarily stored with the client's funds while slot is free, and not yet filled; this could lead to client withdrawing repair rewards when slots are free when the request ends

AuHau

Another round of comments.

AuHau · 2025-03-17T16:33:50Z

contracts/Vault.sol

+  function unpause() public onlyOwner {
+    _unpause();
+  }


Didn't we discuss that it would be possible to only freeze the contract without the possibility to unfreeze it?

We discussed it, but didn't come to a conclusion yet. It may be nice to be able to pause the vault while working on a critical fix for the marketplace contract, and then unpause it once the fix is in place.

AuHau · 2025-03-17T16:54:24Z

test/Vault.tests.js

+    let account
+
+    beforeEach(async function () {
+      account = await vault.encodeAccountId(holder.address, randomBytes(12))


Why a random account? Wouldn't a fixed account be better?

Any account discriminator should work for these tests

AuHau · 2025-03-17T17:03:14Z

test/Vault.tests.js

+      expect(await vault.getLockExpiry(fund)).to.equal(expiry)
+    })
+
+    it("does not allow a lock with expiry past maximum", async function () {


What about setting the expiry/maximum into the past?

That is currently allowed, although not very useful

test/Vault.tests.js

contracts/vault/VaultBase.sol

AuHau · 2025-03-17T18:33:11Z

contracts/vault/Funds.sol

+  /// Indicates that a locked fund is frozen. Flows have stopped, nothing is
+  /// allowed until the fund unlocks.
+  Frozen,


Why Frozen also stop the flows? I could imagine a use-case, where you deposit and set up all the funds in the Locked stage and then you would just want to make it "immutable" to just wait until funds get unlocked and prevent any changes to the setting. Frozen could almost be used for it, except it stops the flows...

Honestly, I would rather specify this using the functions that freeze the funds eq. having freezeFund() (will not stop the flows) and freezeFundsAndStopFlows() (will freeze funds and stop flows).

Yes, I see that freezing can be interpreted in more than one way. I chose this, because for the marketplace we need the interpretation that the balances do not change after this point. I would suggest to revisit this when needed.

- NoLock -> Inactive - Unlocked -> Withdrawing

Co-Authored-by: Adam Uhlíř <adam@uhlir.dev>

Reason: update() is too generic, and can easily be interpreted as changing the on-chain state, whereas it actually updates the in-memory struct. Co-Authored-By: Eric <5089238+emizzle@users.noreply.github.com> Co-Authored-By: Adam Uhlíř <adam@uhlir.dev>

Co-Authored-By: Adam Uhlíř <adam@uhlir.dev>

markspanbroek force-pushed the update-solidity branch from 20a32c1 to 81e88dd Compare February 10, 2025 10:55

markspanbroek force-pushed the vault branch from 60bed15 to ed8b536 Compare February 10, 2025 10:58

markspanbroek force-pushed the update-solidity branch from 81e88dd to b54cd59 Compare February 11, 2025 13:17

markspanbroek force-pushed the vault branch from 6067583 to 73f3a4a Compare February 11, 2025 13:17

markspanbroek marked this pull request as ready for review February 11, 2025 13:20

This was referenced Feb 11, 2025

Vault contract updates codex-storage/codex-research#199

Merged

feat: require proof for freeSlot #191

Closed

Require proof for freeSlot #143

Closed

markspanbroek force-pushed the vault branch 2 times, most recently from 3049325 to 724670b Compare February 24, 2025 15:13

emizzle approved these changes Feb 26, 2025

View reviewed changes

contracts/vault/VaultBase.sol Outdated Show resolved Hide resolved

contracts/vault/Locks.sol Outdated Show resolved Hide resolved

contracts/vault/VaultBase.sol Outdated Show resolved Hide resolved

markspanbroek force-pushed the update-solidity branch from b54cd59 to 6816355 Compare February 26, 2025 09:59

markspanbroek force-pushed the vault branch from 724670b to e2cc75a Compare February 26, 2025 10:02

AuHau reviewed Feb 26, 2025

View reviewed changes

markspanbroek force-pushed the update-solidity branch from 6816355 to 7b14c20 Compare March 4, 2025 08:30

Base automatically changed from update-solidity to master March 4, 2025 08:33

markspanbroek force-pushed the vault branch from d80b1bf to 9b42a46 Compare March 4, 2025 10:29

emizzle reviewed Mar 10, 2025

View reviewed changes

contracts/vault/VaultBase.sol Show resolved Hide resolved

AuHau reviewed Mar 20, 2025

View reviewed changes

markspanbroek mentioned this pull request Apr 15, 2025

Marketplace vault codex-storage/nim-codex#1196

Open

markspanbroek added 6 commits April 16, 2025 09:12

vault: deposit and withdraw

11d6ea9

vault: change data structure to be recipient oriented

72fbc57

vault: burning funds

7be033e

vault: transfer tokens from one recipient to the other

080a814

vault: designate tokens for a single recipient

5205e7f

vault: lock up tokens until expiry time

70ea171

markspanbroek and others added 24 commits April 16, 2025 09:12

vault: formatting

adb8587

vault: test lock state transitions

816d216

vault: clean up errors

89d7d75

vault: rename burn -> burnAccount, burnAll -> burnFund

2ed51e7

vault: burn part of designated tokens

c0d5896

vault: burn designated/fund allowed when flowing

26f6d6d

vault: prefix errors with 'Vault'

75c1832

vault: cleanup

5f22091

vault: remove dead code

23ee19a

vault: add documentation

9746dbe

vault: fix accounting of locked value when burning designated tokens

e2c6506

vault: update documentation

6584647

update openzeppelin contracts to 5.2.0

696edd0

vault: format all solidity files

c686243

vault: cleanup tests

cbd5077

vault: pausing and unpausing

0618d0b

vault: rename account->holder in tests

f01b40f

vault: allow for multiple accounts for one account holder

ef87c36

vault: only allow account holder to withdraw for itself

633b145

vault: freezeFund() instead of burnFund()

675bc8a

vault: rename Fund -> FundId

c3b49c6

vault: rename lock states

5e8eb28

- NoLock -> Inactive - Unlocked -> Withdrawing

vault: rename Lock -> Fund

4e481e3

vault: clarification

2f2c6d8

Co-Authored-by: Adam Uhlíř <adam@uhlir.dev>

markspanbroek force-pushed the vault branch from 9b42a46 to 6a7d559 Compare April 16, 2025 08:40

markspanbroek and others added 2 commits April 16, 2025 11:05

vault: rephrase

957f6ec

Co-Authored-By: Adam Uhlíř <adam@uhlir.dev>

markspanbroek force-pushed the vault branch from 6a7d559 to 957f6ec Compare April 16, 2025 09:06

markspanbroek merged commit e49abc4 into master Apr 16, 2025
4 checks passed

markspanbroek deleted the vault branch April 16, 2025 09:57

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Vault #220

Vault #220

markspanbroek commented Feb 6, 2025 •

edited

Loading

markspanbroek commented Feb 20, 2025

markspanbroek commented Feb 24, 2025

emizzle left a comment

AuHau left a comment

markspanbroek commented Mar 3, 2025

AuHau left a comment

AuHau Mar 17, 2025

markspanbroek Apr 16, 2025

AuHau Mar 17, 2025

markspanbroek Apr 16, 2025 •

edited

Loading

AuHau Mar 17, 2025

markspanbroek Apr 16, 2025

AuHau Mar 17, 2025

markspanbroek Apr 16, 2025

Vault #220

Vault #220

Conversation

markspanbroek commented Feb 6, 2025 • edited Loading

markspanbroek commented Feb 20, 2025

markspanbroek commented Feb 24, 2025

emizzle left a comment

Choose a reason for hiding this comment

AuHau left a comment

Choose a reason for hiding this comment

markspanbroek commented Mar 3, 2025

AuHau left a comment

Choose a reason for hiding this comment

AuHau Mar 17, 2025

Choose a reason for hiding this comment

markspanbroek Apr 16, 2025

Choose a reason for hiding this comment

AuHau Mar 17, 2025

Choose a reason for hiding this comment

markspanbroek Apr 16, 2025 • edited Loading

Choose a reason for hiding this comment

AuHau Mar 17, 2025

Choose a reason for hiding this comment

markspanbroek Apr 16, 2025

Choose a reason for hiding this comment

AuHau Mar 17, 2025

Choose a reason for hiding this comment

markspanbroek Apr 16, 2025

Choose a reason for hiding this comment

markspanbroek commented Feb 6, 2025 •

edited

Loading

markspanbroek Apr 16, 2025 •

edited

Loading