umaprotocol / protocol Goto Github PK

and others...

I don't think there are any auto formatters out for solidity (sadly). I think we should pick a linter that will check code format and look for simple issues. solhint appears to be relatively mature, has plugins for a bunch of IDEs, and it allows customization through configs and comments.

Now that we're using structs that keep information in a cleaner way, we should rewrite the whoDefaults function to be a little less clunky.

Are we exclusively storing margin in ETH? It seems to be the default choice because of its relative stability and its trustworthiness when compared to other crypto assets/stablecoins. I may be operating on outdated or incorrect info, so feel free to correct me.

In any case, storing margin in ETH presents some currency risk to participants, and they would likely want to hedge out that risk. This sort of margin currency issue is probably a familiar one in financial circles. However, I would guess that the volatility of our margin currency and the relative difficulty of getting short exposure to crypto might mean that a common flow would be to create two swaps at once - one for the original swap and a second to translate the margin risk into a currency that each party feels more comfortable holding. Does this sound right to y'all? Or am I missing something? I'm not sure if there's anything actionable here other than the fact that we may want to build our contracts/tutorials/docs with this use case in mind.

Also, this presents the issue of how to set margin requirements. If the swap, itself, has nothing directly to do with ETH, we may want to encode the relative value of ETH in the margin requirements to ensure a severe drop or increase in the value of ETH doesn't cause the effective margin requirement to vary wildly. Thoughts?

cc @hlambur @allisonlu22 @cc7768 @sglyon

We haven't reached consensus on exactly what parties to restrict it to, but that will be added to this issue once it's decided.

We should set up a CI system that verifies that PRs build and pass tests (once we write them :) ).

Both of these contracts should inherit from the same common base class.

We need to create a new TokenizedDerivative that allows one counterparty to provide "tokenized" exposure to the asset. The tokens can be authorized by the offering counterparty, created/bought by the investing counterparty, and redeemed for ETH by the investing counterparty.

• Build Basic Logic
• Add Tests

We should add checks to ensure that the JS code is formatted by prettier.

There is a global size limit for contract bytecode in Ethereum. Because the bytecode of the contracts that the registry creates must be included in the registry's bytecode, we need to fragment the registry into multiple "creator" contracts that are allowed to register contracts that they create with the registry to ensure the Registry is "deployable".

bool isDerivativeRegistered(address)

• This method returns true if the contract is registered and false if it is not.

array[(address creatorAddress, address derivativeAddress)] getRegisteredDerivatives(address counterparty)

• Returns a list of all the derivatives that the counterparty is involved in.

bool isDerivativeCreatorAuthorized(address derivativeCreator)

• Returns whether a derivative creator is authorized or not.

addContractCreator(address contractCreator)
removeDerivativeCreator(address contractCreator)

• These methods add and remove derivative creators from the list of authorized derivative creators that are allowed to register contracts.
• Only the owner (Oracle) can call these methods

registerDerivative(array[address] counterparties, address derivativeAddress)

• Registers a new derivative.
• Only an authorized derivative creator can call this method.

Implement the price feed replacement for the MockOracle contract.

disputeNow() allows a provider to dispute the price right now rather than at the last remargin time. This is necessary to ensure that a user can dispute a price feed that is no longer publishing prices. Open question: how does the contract determine if the dispute was correct and the deposit should be refunded?

The Dapp controller method should essentially combine the authorizeTokens() and createTokens() methods to allow a user, if their address matches both the investor and provider, to do both with a single method call. This method should have the following basic structure:

function authorizeAndCreateTokens(uint tokenNavToCreate) external payable onlyProvider onlyInvestor
{
    ...
} 

Normal derivative should be called TRS (or something similar), and its deployment should not assume one of the counterparties is the sender. All notation within the contract should be changed to long-short rather than the maker-taker notation currently used.

Currently, the margin requirement for the investor is set to 100%, but this should really be impossible to go below. We should eliminate the margin requirement for the investor altogether and treat the investor balance == NAV as a contract invariant.

We should update the comments above each state in the enum to better reflect their purpose in the TokenizedDerivative context.

Some of these structs were discussed and proposed in comments on #20

• Struct with information about balance, address balance, whether price has been confirmed
• etc...

In general, block.timestamp (or now) isn't particularly accurate and can be a security flaw if used carelessly. It's generally recommended that smart contracts avoid time based logic altogether (the solhint linter complains about this) in favor of block-number based logic, which can't be manipulated by the miner.

The contract migrations are currently a mess of mostly repeated .then() statements nested inside simple branches. This can probably be cleaned up to a more minimal, simplistic approach.

Write a test using Trail of Bits' Echidna fuzzer that analyzes the TokenizedDerivative contract.

We need to take a look through our contracts to ensure that there are no potential transaction reordering attacks. For example, in our swap contract, let's assume one party wants to dispute the current unverified price. They must make a deposit to do so (this is still a TODO). If the disputed price was correct, the counterparty receives the deposit. However, if the counterparty gets a remargin in before the dispute, the current price may change. Therefore, once the disputing party may not be disputing the price that they thought they were. For this reason, it makes sense to require them to pass the contract time point that they are trying to dispute. If the contract has moved past that time point, then the dispute gets reverted. These sorts of attacks are subtle, but important. Transaction ordering is determined by the miners based on many factors (one of which is the offered gas price), and it could also be exploited by miners with a vested interest in a particular order.

VoteCoin currently does not allow verified prices to be published until the beginning of the next voting period, even if they have already been approved and voting has ended.

[Credit @cc7768] We should have some sort of regression tests that allow us to compare the gas costs of different function PR to PR. This blog post talks about some of the gotchas, methodology, and tradeoffs wrt optimizing for gas.

We end up needing to convert between Solidity timestamps and javascript dates often. It would be nice to construct a simple javascript library to do this conversion as well as some of our common operations on the javascript dates (like creating date object with a user provided date, but application provided time on that date).

We should convert all our TODOs in code to GH issues - I think this will make them a bit easier to track. We don't necessarily need to remove them form the code, but we can link to the in-code TODO from the issue.

Add functionality for the user to provide an expiry date to the TokenizedDerivative contract.

We are currently not getting the NPV precisely at the expiry, and we are not implementing the "agree to settle logic". Once expired, each party can withdraw their entire balance. We should implement expiry NPV calculation (unverified price), agree to settle (unverified expiry price), and auto settlement on the verified price. This depends on a separation of verified and unverified feeds discussed in #12.

The oracle should provide unverified and verified feeds. It should also allow the caller to ask for a particular time.

• Contract creation
• Deposit
• Start contract once enough margin is included on both sides
• Remargin correct
• Test balances when they drop negative and ensure person can't withdraw "too much"
• Settle with confirmed price
• Settle with verified price

Build an interface for unit NAV computation and allow users to provide an address that implements this interface in their Tokenized Derivative contract.

We are essentially using contracts as the only objects in our current programming paradigm. We can use inheritance to break up concern a bit, but this doesn't necessarily give us the power to do true object composition with more complex data structures. We should move to taking advantage of [using for] and libraries to create object-like structs.

Implement a centralized oracle to work within the v0 oracle interface. Price requests should be resolved manually by a single owner.

Build a price scraper that pulls bitcoin prices and uploads them to the MockOracle.

We should do some research and discuss tradeoffs.

We need to implement a dispute flow. Disputes can arise from Live, Expired, and Defaulted states IIRC. This depends on #12.

The calcNAV method would be a view method that would allow one to calculate an updated NAV without actually updating the contract state. Optionally, it may make sense to add a calcRequiredMargin as well.

We should set up one or more project boards on GH similar to these for tracking: https://github.com/ethereum/mist/projects/11, https://github.com/ethereum/solidity/projects/4.

To safeguard our contracts from accidental integer overflow, etc, we should use a library to do runtime checks on all integer operations.

We will need mainnet deployment (and probably testnet) setup for our v0 goal. This issue tracks that effort.

The v0 interface should have a single method getPrice() that enqueues a price request to be resolved by the oracle at a later time or returns the value if it has already been resolved.

Create the interface for external price feeds that allows users to access "unverified" price feeds. This will partially replace the OracleInterface being used now.