hubiinetwork / nahmii-contracts Goto Github PK

Description

Both Exchange and AntiFraud work with operational mode, a property that is more global than those two contracts. Configuration contract should thus manage this property rather than Exchange and AntiFraud. The latter will eventually set operational mode to Exit after which operation it may not be reset to Normal. The former will read operational mode.

Definition of done

• Configuration contract has been updated
• Exchange and AntiFraud contracts have been updated
• Unit tests have been updated

Details & Questions

This issue is currently not represented in the Omphalos specification.

Depends on

Description

Implement challenge of fraudulent deal by trade in Exchange smart contract according to section ChallengeFraudulentDealByTrade.

Definition of done

• Exchange smart contract features has been implemented
• Unit tests for Exchange features have been implemented

Details & Questions

Depends on

Description

The DSC challenge functions (challengeByOrder(), unchallengeOrderCandidateByTrade(), challengeByTrade() and challengeByPayment()) should check whether the provided challenge candidate is deemed fraudulent in the FC. If deemed fraudulent the challenge attempt should revert.

Definition of done

• DSC challenge functions revert upon detecting fraudulent challenge candidate
• Unit tests have been updated

Details & Questions

Depends on

Description

Implement initial pieces of Reserve fund smart contract according to section Reserve fund fund in specification (v0.12).

The initial pieces required are the ones that deal with updating balance blocks (Fallback function and DepositToken()) and calculation of aggregate balance blocks in range of block numbers (BalanceBlocksIn()).

The Reserve fund is where clients may make deposits and earn share of revenue relative to their contribution.

Definition of done

• Reserve fund smart contract functions has been implemented
• Unit tests for Reserve fund functions have been implemented
• Migration of Reserve fund have been updated

Details & Questions

There will likely be 2 instances deployed of this smart contract, one for trade reserves and one for payment reserves. If this were to happen there will also be two instances deployed of the Revenue fund (#8), one for trade revenues and one for payment revenue. Each of the two reserve fund instances of this issue will then be a beneficiary of the revenue fund corresponding to the same deal type.

Depends on

Description

The amount to be staged after a settlement is closely bound to the amount settled and the balance of the driip settled. Thus the amount to be staged should be introduced into the driip settlement challenge.

Also settlement functions only should call ClientFund.stage function. Wallets should be prevented from calling this function directly.

Definition of done

Details & Questions

Based on Slack conversation with Mark where he stated:

Thinking about this thing we missed about settlement. I guess we were guilty of assuming that it would always be the person with a positive net balance settling. However, obviously that's not the case. I can't help but think it might be a very simple fix though. I may be missing something though. My suggestion would be simply to make SettleDeal() always move funds for the caller, for that currency to the staged balance... No matter which direction the net change is in. I feel like there would be no problem with this... Security would still function exactly the same way.

Depends on

Description

Current exchange contract is getting too big, requiring more than 6m gas to deploy. Anti-fraud logics should be factored out into separate AntiFraud contract.

Definition of done

• Exchange contract has been updated
• New AntiFraud contract has been implemented
• Deployment scripts have been updated
• Unit tests have been updated/implemented

Details & Questions

This issue is currently not represented in the Omphalos specification.

Depends on

Description

ClaimAccrual() in ReserveFund must have a boolean parameter for compounding earned accrual (i.e. add to active balance) or not (i.e. add to staged balance). Currently ClaimAccrual() does not allow compounding. It is suggested that the parameter be named compoundAccrual. A value of true will thus increment active balance and false will increment staged balance.

Definition of done

• ReserveFund has been updated
• Unit tests have been updated

Details & Questions

This issue is currently not represented in the Omphalos specification.

Depends on

Description

Implement Community vote smart contract according to section Community vote in specification (v0.12).

The Community vote smart contract is an oracle for relevant decisions made by the community.

Definition of done

• Community vote smart contract has been implemented
• Unit tests for Community vote have been implemented
• Migration of Community vote have been updated

Details & Questions

Depends on

Description

The great number of contracts that external clients (e.g. Hubii Core) will be able to interact with should be presented to clients in a consistent manner. This is particularly relevant for all fraud challenge contracts.

Configuration contract may be updated with functionality to host overview of deployed contracts. Alternatively Migrations contract may be augmented with the required features.

Definition of done

• The full set of contracts that external clients may interact with is retrievable
• Unit tests have been created

Details & Questions

@mxmauro had some thoughts on this

yes but we have two options here:

1. if the dapp only calls 1 or 2 fraud SCs, they can be configured by a call to something like setFraudChallengeXXXAddress
2. if the dapp needs to call any fraud SC based on some logic, then we need to implement something like getFraudChallengeXXXAddress(string typeOfFraudChallegeRequested) to get the address dynamically and do the call. But this logic can be also added to the configuration SC

Depends on

Description

With the advent of AntiFraud contract that relies on many of the same compound data structures, enums and hash functions these should be factored out of Exchange and AntiFraud into separate library to be imported into both contracts.

Definition of done

• Common types have been removed from Exchange and AntiFraud contracts
• Types library as been implemented
• Deployment scripts have been updated
• Unit tests have been updated

Details & Questions

This issue is currently not represented in the Omphalos specification.

Depends on

Description

RevenueToken smart contract should have properties for name and symbol. Also totalSupply should be public. All these properties should be adjustable.

Finally the token contract also needs to allow for subdivisions and subdenominations by having decimals. Like HBT contract it should have 15 decimals, thus one unit of the token should equal 10^15 subunits.

Definition of done

When RevenueToken has the mentioned public and adjustable properties.

Details & Questions

Depends on

Description

Replace the use of uintX by intX in monetary values in Exchange contract.

Definition of done

• Integer types have been replaced.
• Unit tests have been updated.

Details & Questions

Depends on

Description

It is beneficial to a allow partners to charge extra fees on top of Hubii's fees applied to trades and payments.

The suggested first half of the implementation describes the implementation of a new contract called PartnerFund with the following main features:

1. Setters and getters for fees (fractions) for trade maker, trade taker and payments. (We'd probably like to keep these configurable fractions separate from our own set of config parameters that are managed by Configuration contract.)
2. Fallback function and DepositTokens() function will receive fees from Exchange and ReserveFund contracts, each transfer identified by partnerTag value.
3. SetPartnerAddress() function will update mapping of partnerTag to partner address.
4. Stage() function will be callable by partner to stage their active balance (of revenue) in preparation for withdrawal.
5. WithdrawEther()/WithdrawTokens() function will be callable by partner to transfer from staged balance to partner's address.

Definition of done

• PartnerFund contract is implemented
• Unit tests have been implemented/updated

Details & Questions

This issues does not include the implemention of interaction with PartnerFund during settlement of driips, the description which is found in #175.

This issue was created based on the following description by @markbkk:

The ability for us to add an "additional partner specified fee" over and above the based striim fee. I believe this should be expressed as an additional % over the main fee combined with volume discounts. So if partner P wants to charge double the fee as Striim itself does, then they would set a figure of 200%. If striim was charging "0.1% - volume discount" for a payment of 1,000 ETH, then partner P would add on 200% and so the overall fee would be "(1 + 200%) * (0.1% - volume discount)".

Depends on

Description

Complete implementation of Reserve fund smart contract according to section Reserve fund fund in specification (v0.12).

The Reserve fund is where clients may make deposits and earn share of revenue relative to their contribution.

Definition of done

• Complete reserve fund smart contract has been implemented
• Unit tests for all of reserve fund have been implemented

Details & Questions

There will likely be 2 instances deployed of this smart contract, one for trade reserves and one for payment reserves. If this were to happen there will also be two instances deployed of the Revenue fund (#8), one for trade revenues and one for payment revenue. Each of the two reserve fund instances of this issue will then be a beneficiary of the revenue fund corresponding to the same deal type.

Depends on

• Initial functions of reserve fund smart contract (#4)

Description

The current code base is geared towards ERC20. Additional non-ERC20 tokens, non-fungible ones such as ERC721 and ERC1155 as well as fungible ones, may be of interest in the future.

The outcome of this issue is to suggest changes needed in the code base to be able to support new tokens smart contracts. Such a support naturally suggests modularity in the way striim contracts interfaces token contracts.

Definition of done

• The full set of contracts have been examined w.r.t. the addition of support for non-ERC20 token contracts

Details & Questions

Depends on

Description

Currently if driip settlement challenge result is Disqualified the funds of the settling wallet (msg.sender of settleDriipAsTrade()/settleDriipAsPayment() or wallet if called by owner) is seized, even if the settling wallet was not the driip party causing overrun and thus Disqualified challenge result.

Rather settleDriipAsTrade()/settleDriipAsPayment() should only seize funds of the settling wallet if the driip causes overrun for that particular wallet.

A driip settlement challenge may indeed find overrun for both driip parties, but if only one party is settling this settlement should not seize the funds of the other party.

Definition of done

• Exchange.settleDriipAsTrade() and Exchange.settleDriipAsPayment() only triggers fund seizure when settling wallet was found to overrun by DSC.
• Unit tests have been updated.

Details & Questions

Depends on

Description

Import features from DexTrade that are useful according to Exchange specification (v0.12).

Definition of done

• Exchange smart contract features has been implemented
• Unit tests for Exchange features have been implemented

Details & Questions

Depends on

Description

Implement challenge of fraudulent deal by trade order residual in Exchange smart contract according to section ChallengeFraudulentDealByTradeOrderResidual.

Definition of done

• Exchange smart contract features has been implemented
• Unit tests for Exchange features have been implemented

Details & Questions

Depends on

Description

Replace the use of uintX by intX in monetary values in ReserveFund contract.

Definition of done

• Integer types have been replaced.
• Unit tests have been updated.

Details & Questions

Depends on

Description

Implement the following features:

• CancelOrders(orders: o[], trade: t)
• GetCancelledOrders(wallet: w, trade: t)
• ChallengeCancelledOrder(trade: t, wallet: w)
• CancelledOrdersChallengePhase(wallet: w)
• StartDealSettlementChallenge(deal: d, wallet: w)
• GetChallengedDeal(wallet: w)
• ChallengeDealSettlementByOrder(order: o)
• UnchallengeDealSettlementOrderByTrade(order: o, trade: t)
• ChallengeDealSettlementByTrade(trade: t, wallet: w)
• ChallengeDealSettlementByPayment(payment: p, wallet: w)
• DealSettlementChallengePhase(wallet: w)
• DealSettlementChallengeStatus(wallet: w)
• UpdateDoubleSpenders()
• GetDoubleSpenders()
• UpdateHighestAbsoluteDealNonce()
• GetHighestAbsoluteDealNonce()
• DisableUpdateOfCommunityVote()
• CommunityVote(address: a)
• TradesRevenueFund(address: a)
• PaymentsRevenueFund(address: a)
• TradesReserveFund(address: a)
• PaymentsReserveFund(address: a)
• SecurityBond(address: a)
• FraudulentDealChallenge(address: a)
• DealSettlementChallenge(address: a)

Definition of done

• Exchange supports the features above
• Unit tests have been implemented

Details & Questions

Current implementation has one revenue fund for trades and payments combined. The use of this one revenue fund will have to be split in two.

Depends on

Description

Fee setters will only accept block number larger than the current block number on the network.

Definition of done

• Configuration contract has been updated
• Unit tests have been updated

Details & Questions

Depends on

Description

In client fund smart contract add functions Withdrawal(wallet: w, index: i) and WithdrawalCount(wallet: w). These are complementary to Deposit(wallet: w, index: i) and DepositCount(wallet: w).

Withdrawal(wallet: w, index: i) returns stats about withdrawal at index i from the staged balance of wallet w.

WithdrawalCount(wallet: w) returns the number of withdrawals by wallet w.

Definition of done

• Client fund functions Withdrawal(wallet: w, index: i) and WithdrawalCount(wallet: w) are implemented
• Unit tests for Withdrawal(wallet: w, index: i) and WithdrawalCount(wallet: w) are implemented

Details & Questions

This implementation is not included in the Omphalos specification.

Depends on

Description

Implement Configuration smart contract according to section Configuration in specification (v0.12).

The Configuration smart contract is an oracle for configuration values such as fees, challenge timeouts, stake size and possibly more.

Definition of done

• Configuration smart contract has been implemented
• Unit tests for Configuration have been implemented
• Migration of Configuration have been updated

Details & Questions

Depends on

Description

Implement challenge of double spent order in Exchange smart contract according to section ChallengeDoubleSpentOrder.

Definition of done

• Exchange smart contract features has been implemented
• Unit tests for Exchange features have been implemented

Details & Questions

Depends on

Description

Implement Exchange smart contract according to section Revenue fund in specification (v0.12).

The Exchange smart contract is the orchestrator of trades and payments on-chain including a.o. settlements and challenges.

Definition of done

• Exchange smart contract has been implemented
• Unit tests for Exchange have been implemented
• Migration of Exchange have been updated

Details & Questions

The bulk of code for this smart contract can be factored out from previous Trade smart contract.

Depends on

• Reserve fund (#4)
• Token holder revenue fund (#9)

Description

Implement Security bond smart contract according to section Security bond fund in specification (v0.12).

The Security bond contains crypto incentive for function specified as UnchallengeDealSettlementOrderByTrade().

Definition of done

• Security bond smart contract has been implemented
• Unit tests for Security bond have been implemented
• Migration of Security bond have been updated

Details & Questions

Depends on

Description

Definition of done

Details & Questions

Depends on

Description

Implement settle deal in Exchange smart contract according to section SettleDeal.

Definition of done

• Exchange smart contract features has been implemented
• Unit tests for Exchange features have been implemented

Details & Questions

Depends on

Description

Implement challenge of fraudulent deal by payment in Exchange smart contract according to section ChallengeFraudulentDealByPayment.

Definition of done

• Exchange smart contract features has been implemented
• Unit tests for Exchange features have been implemented

Details & Questions

Depends on

Description

The 6 fee block number arrays are currently not sorted. Although naturally the addition of new fees values are likely to happen in block number incremental order it is not required. Thus the update of fee values should assure that the corresponding fee block number array is kept sorted.

Definition of done

• Configuration contract has been updated
• Unit tests have been updated

Details & Questions

This is a left-over from #44.

Depends on

Description

Payments fees need to be defined per currency. Thus getters and setters of payment fees in Configuration contract need the address of currency as parameter. And Exchange contract's retrieval of payment fees need to pass currency address as argument. (Currency address 0 is ETH.)

Definition of done

• Configuration and Exchange contracts have been updated.
• Unit tests have been updated.

Details & Questions

This issue is currently not represented in the Omphalos specification.

Depends on

Description

A new instance of SecurityBond contract must be created. This contract will act as data availability bond with higher beneficiary fraction than SecurityBond.

Definition of done

• Enable new instance of SecurityBond contract in migration scripts.

Details & Questions

Depends on

Description

A certain number of features in FraudChallenge contract have been left commented out in order to prevent out-of-gas exception when deploying. Pieces of code that needs to be uncommented are labeled // TODO Enable when deployment out-of-gas is solved.

Definition of done

• Concerned pieces of code in FraudChallenge.sol and FraudChallenge.js have been uncommented.
• Unit tests in FraudChallenge.js are running.

Details & Questions

This is left-over from #75.

Depends on

Description

Implement Token holder revenue fund smart contract according to section Token holder revenue fund fund in specification (v0.12).

The Token holder revenue fund manages the revenue earned by revenue token holders.

Definition of done

• Token holder revenue fund smart contract has been implemented
• Unit tests for Token holder revenue fund have been implemented
• Migration of Token holder revenue fund have been updated

Details & Questions

Depends on

Description

Exchange contract's settleDriipAsTrade() and settleDriipAsPayment() should check that (hash of) driip that is being settled has not been flagged as fraudulent by FraudChallenge contract.

Definition of done

• settleDriipAsTrade() and settleDriipAsPayment() in Exchange does no settle fraudulent driip
• Unit tests have been updated

Details & Questions

Depends on

Description

It should be possible to transfer funds from ReserveFund to ClientFund. This implementation is close to identical to the one of #55. A suggested implementation goes as follows:

1. Add new function StageTo() to ReserveFund. Albeit very similar to existing Stage() function StageTo() will take an additional parameter of target address. When called in order to transfer to ClientFund the target address argument will have the value of the address of (trade or payment) ClientFund instance.
2. Add interface Beneficiary

interface Beneficiary {
    function DepositEther(address: b, amount: a) public payable;
    function DepositTokens(address: b, amount: a, token: t) public;
}

3. Make ClientFund implement interface Beneficiary. Its current DepositTokens() already does. The new DepositEther() will be very much identical to the ClientFund fallback function. Only where fallback function works with balances of msg.sender the new function will rather work with balances of address b. Core logics of fallback function should be factored out into new internal function that can be called both by fallback function as well as by DepositEther() function.

Definition of done

• ReserveFund has been updated
• ClientFund has been updated
• Unit tests have been updated

Details & Questions

This issue is currently not represented in the Omphalos specification.

Depends on

Description

Functional support in ClientFund needed that takes all deposited and settled funds of one wallet and moves it to staged wallet of another. This function will be used to seize balances from wallets whose deals are deemed fraudulent by Exchange contract challenge functions.

Essentially the required functionality is similar to stage(). But where source and destination of balance movements in the current implementation of stage() is the same wallet, it is necessary that source and destination be different wallets in this new use case. Also this use case only happens when triggered from registered service (here the Exchange contract).

It thus seems most reasonable to implement a new function, e.g. named seizeDepositedAndSettledBalances() in ClientFund.

Definition of done

• Implementation of function in ClientFund that supports the seizure of deposited and settled balances of one wallet by moving it to staged balances of another wallet.
• Unit tests are implemented/updated.

Details & Questions

Depends on

Description

Implement Exchange smart contract according to section Exchange in specification (v0.12).

The Exchange smart contract is the orchestrator of trades and payments on-chain including a.o. settlements and challenges.

Implementation subissues

• Generic
  • Import from abandoned DexTrade contract (#21)
• Continuous challenges
  • Challenge fraudulent deal by trade (#14)
  • Challenge fraudulent deal by payment (#15)
  • Challenge fraudulent deal by balance (#16)
  • Challenge fraudulent deal by trade order residual (#17)
  • Challenge double spent order (#18)
• Deal settlement
  • Settle deal (#19)
• (Remainder to be gauged later)

Definition of done

• Implementation of all subissues done

Details & Questions

Depends on

• Client fund (#3)
• Community vote (#7)
• Revenue fund (#8)
• Reserve fund (#4)
• Community vote (#7)
• Security bond (#10)
• Configuration (#5)

Description

Implement Client fund smart contract according to section Client fund in specification (v0.12).

The Client fund is where clients’ crypto assets are deposited into, staged and withdrawn from.

Definition of done

• Client fund smart contract has been implemented
• Unit tests for Client fund have been implemented
• Migration of Client fund have been updated

Details & Questions

The bulk of code for this smart contract can be factored out from previous Trade smart contract.

Depends on

Description

Implement challenge of fraudulent deal by balance in Exchange smart contract according to section ChallengeFraudulentDealBySuccession.

Definition of done

• Exchange smart contract features has been implemented
• Unit tests for Exchange features have been implemented

Details & Questions

Depends on

Description

It should be possible to transfer funds from ClientFund to ReserveFund. Thus ClientFund can serve as single entry point for funds from wallets that are inbound to Omphalos. A suggested implementation goes as follows:

1. Add new function StageTo() to client fund. Albeit very similar to existing Stage() function StageTo() will take an additional parameter of target address. When called in order to transfer to ReserveFund the target address argument will have the value of the address of (trade or payment) ReserveFund instance.
2. Add interface Beneficiary

interface Beneficiary {
    function DepositEther(address: b, amount: a) public payable;
    function DepositTokens(address: b, amount: a, token: t) public;
}

3. Make ReserveFund implement interface Beneficiary. Its current DepositTokens() already does. The new DepositEther() will be very much identical to the ReserveFund fallback function. Only where fallback function works with balances of msg.sender the new function will rather work with balances of address b. Core logics of fallback function should be factored out into new internal function that can be called both by fallback function as well as by DepositEther() function.

Definition of done

• ClientFund has been updated
• ReserveFund has been updated
• Unit tests have been updated

Details & Questions

This issue is currently not represented in the Omphalos specification.

Depends on

Description

In order to support future new driip types it may be worthwhile to split current contracts by driip types. Candidate contracts include a.o. DriipSettlementChallenge, DriipSettlementChallenger, Configuration and Exchange. The intention of splitting contracts is to minimize the impact and need to redeploy existing features with the introduction of new driip types.

The outcome of this issue is an outline of the work required and possible effect in terms of altered gas costs related to deployment and execution.

Definition of done

• Concerned contracts have been examined w.r.t. splitting of contracts by driip types.

Details & Questions

Depends on

Description

Replace the use of uintX by intX in monetary values in Configuration contract.

Definition of done

• Relevant integer types have been replaced.
• Unit tests have been updated.

Details & Questions

Depends on

Description

Export of state of a number of contracts is needed for the possible redeployment of updated contracts. The concerned contracts include but is not limited to CancelOrdersChallenge, DriipSettlementChallenge, FraudChallenge, Exchange, RevenueFund, ReserveFund and SecurityBond. Contracts containing ETH and token balances have to be able to transfer funds to new contract instance.

ClientFund and ReserveFund already have mechanism in place from their stageTo() functions that can be used to transfer user balances. However, aggregate balances are not covered by this function.

Definition of done

• All concerned contracts support export of state including transfer of ETH and token balances.
• Unit test have been updated.

Details & Questions

Depends on

Description

When wallets deals are deemed fraudulent the deposited and settled balances of the wallet must be seized by calling ClientFund's seizeDepositedAndSettledBalances() from Exchange's challengeFraudulentDealByTrade() and challengeFraudulentDealByPayment() (and possibly other function implemented by #26).

Definition of done

• challengeFraudulentDealByTrade() in Exchange calls seizeDepositedAndSettledBalances() in ClientFund when trade is deemed fraudulent and fraud attributed to particular wallet.
• challengeFraudulentDealByPayment() in Exchange calls seizeDepositedAndSettledBalances() in ClientFund when payment is deemed fraudulent and fraud attributed to particular wallet.
• Unit tests are updated.

Details & Questions

This issue is left-over of #14.

Depends on

• Seizure of balances in ClientFund (#26)

Description

Set up build config in TeamCity with automated testing in place.

Definition of done

red/green status for each commit/branch in TeamCity.

Details & Questions

Depends on

Description

The stakes managed by Configuration contract should be fractional (in units of PARTS_PER) and not absolute as they are today. The staging of fund in SecurityBond contract will also have to be modified accordingly, either by stage() function having fraction and partsPer parameters rather than the current amount, or by calculating the fractional amount in function that calls stage().

Definition of done

• Configuration contract stores stake fractions rather than absolute amounts
• Staging in SecurityBond supports fractional configuration values
• Unit tests are updated

Details & Questions

Depends on

Description

Replace the use of uintX by intX in monetary values in ClientFund contract.

Definition of done

• Integer types have been replaced.
• Unit tests have been updated.

Details & Questions

Depends on

Description

ReserveFund contract needs to allow registered services in similar manner as SecurityBond contract. It will need function RegisterService() that adds address to array of registered service addresses if not already present. It will also need function DeregisterService() that removes an address from that array of registered service addresses if it has previously been registered.

Also, where it in fallback, DepositTokens() and CloseAccrualPeriod() functions is indicated that msg.sender should be owner it should rather be required that msg.sender is found amongst registered service addresses. The canonical registered service will be the RevenueFund contract.

Definition of done

• ReserveFund functions have been implemented/updated.
• Unit tests have been updated.

Details & Questions

Depends on

Description

The client fund does not allow funds to be explicitly staged. Thus at present the only way that a wallet can withdraw funds from the client fund is if its active balance is for deals and settlements increment the wallet's staged balance.

The new concepts for the client fund was exemplified in Slack message from @jijordre to @markbkk.

--

First, let’s rename client fund 1 balance and introduce 1 more balance. The active balance in the current spec we rename to deposited balance. The concept of staged balance is unchanged. We then introduce the concept of settled balance. (In name this matches what L&B suggested, although semantically it may be different.:smile:). This means that a wallet will have 3 balances (i.e. balance values) per currency.

Also we (re)introduce function Stage() in the client fund. Details about its implementation are below.

Then, we look at some actions.

1. Wallet a makes an initial deposit of 10 ETH. This increments his deposited balance of ETH.

2. Wallet a places a payment of 2 ETH to wallet b.

3. Wallet a then wants to withdraw its ETH. It is successful in running the deal settlement challenge for the payment deal.

4. Wallet a settles the payment deal on-chain by calling exchange contract’s SettleDeal() (Let’s assume immediate settlement is requested and/or discarding the reserve fund for now.) According to the net transfer of the payment it increments wallet b’s settled balance of ETH by an amount of 2 and decrements wallet a’s settled balance of ETH by the same amount of 2.

5. Wallet a continues towards withdrawal by calling client fund contract’s Stage(). The increment to its staged balance of ETH is the sum of deposited balance (10) and settled balance (-2) of ETH, with the total value of 8 ETH. This action also zeros out the deposited balance and settled balance of wallet a.

6. Wallet b then wants to withdraw its ETH and starts off by calling client fund’s Stage(). The increment to its staged balance of ETH is the sum of deposited balance (0) and settled balance (+2) of ETH, with the total value of 2 ETH. This action also zeros out the deposited balance and settled balance of wallet b.

7. Wallet a choses to not withdraw after all but rather wants to reengage with orders and payments. It calls Unstage() which increments the deposited balance of ETH to 8 and zeros out the staged balance of ETH.

8. Wallet b choses to withdraw by calling Withdraw() and zeros the staged balance of ETH.

I believe this scenario can be easily extended to trades as well. In addition we should bake into it the possibility of partial withdrawal and partial unstage. Partial stage may or may not make sense. I can’t quite decide yet.

Definition of done

• Active balance has been renamed to deposited balance in client fund.
• Settled balance has been implemented in client fund.
• Function Stage() has been implemented in client fund.
• Client fund function TransferFromActiveToStagedBalance() has been renamed to TransferFromDepositedToSettledBalance() and implementation updated to deal with updated balances.
• Client fund function WithdrawFromActiveBalance() has been renamed to WithdrawFromDepositedBalance() and implementation updated to deal with deposited balance instead of active balance.
• Client fund function DepositEtherToStagedBalance() has been renamed to DepositEtherToSettledBalance() and implementation updated to deal with settled balance instead of staged balance.
• Client fund function DepositTokenToStagedBalance() has been renamed to DepositTokenToSettledBalance() and implementation updated to deal with settled balance instead of staged balance.
• Unit tests are implemented/updated.

Details & Questions

This implementation is not included in the Omphalos specification.

Depends on