dydx Process Quality Review

Score 77%

This is a dydx Process Quality Audit started on 20 May 2020 and completed on 18 Jume 2020. This was one of the three written while developing the process. That is why it took a month. It was performed using the Process Audit process (version 0.2) then was updated to V0,4 on 27 July 2020. The process is documented here. The audit was performed by ShinkaRex of Caliburn Consulting. Check out our Telegram.

The final score of the audit is 77%, a good pass. The breakdown of the scoring is in Scoring Appendix.

Disclaimer

This report is for informational purposes only and does not constitute investment advice of any kind, nor does it constitute an offer to provide investment advisory or other services. Nothing in this report shall be considered a solicitation or offer to buy or sell any security, future, option or other financial instrument or to offer or provide any investment advice or service to any person in any jurisdiction. Nothing contained in this report constitutes investment advice or offers any opinion with respect to the suitability of any security, and the views expressed in this report should not be taken as advice to buy, sell or hold any security. The information in this report should not be relied upon for the purpose of investing. In preparing the information contained in this report, we have not taken into account the investment needs, objectives and financial circumstances of any particular investor. This information has no regard to the specific investment objectives, financial situation and particular needs of any specific recipient of this information and investments discussed may not be suitable for all investors.

Any views expressed in this report by us were prepared based upon the information available to us at the time such views were written. Changed or additional information could cause such views to change. All information is subject to possible correction. Information may quickly become unreliable for various reasons, including changes in market conditions or economic circumstances.

Executing Code Verification

This section looks at the code deployed on the Mainnet that gets audited and its corresponding software repository. The document explaining these questions is here. This audit will answer the questions;

  1. Is the deployed code address(s) readily available? (Y/N)

  2. Is the code actively being used? (%)

  3. Are the Contract(s) Verified/Verifiable? (Y/N)a

  4. Does the code match a tagged version in the code hosting platform? (%)

  5. Is the software repository healthy? (%)

Is the deployed code address(s) readily available? (Y/N)

Answer: Yes

They are available at Address https://docs.dydx.exchange/#/contracts as indicated in the Appendix: Deployed Code. This Audit only covers the SoloMargin contract (address 0x1E0447b19BB6EcFdAe1e4AE1694b0C3659614e4e created Apr 16, 2019 at 12:24 which is proxy’d to 0x56E7d4520ABFECf10b38368b00723d9BD3c21ee1 created on Apr-16-2019 12:23:36 AM +UTC (in other words, almost immediately after the first).

Is the code actively being used? (%)

Answer: 100%

Activity is well in excess of 10 transactions a day, as indicated in the Appendix.

Percentage Score Guidance

100% More than 10 transactions a day

70% More than 10 transactions a week

40% More than 10 transactions a month

10% Less than 10 transactions a month

0% No activity

Are the Contract(s) Verified/Verifiable? (Y/N)

Answer: Yes

0x56E7d4520ABFECf10b38368b00723d9BD3c21ee1is the Etherscan verified contract address.

Does the code match a tagged version on a code hosting platform? (%)

Answer: 100%

GitHub address : https://github.com/dydxprotocol​

Deployed contracts in the following file;

Matching Repository: https://github.com/dydxprotocol/solo/releases/tag/v0.5.0​

Code matches right up. No concerns.

Is development software repository healthy? (Y/N)

Answer: Yes

There are over 400 commits and 150 plus releases.

Documentation

This section looks at the software documentation. The document explaining these questions is here.

Required questions are;

  1. Is there a whitepaper? (Y/N)

  2. Are the basic application requirements documented? (Y/N)

  3. Do the requirements fully (100%) cover the deployed contracts? (%)

  4. Are there sufficiently detailed comments for all functions within the deployed contract code (%)

  5. Is it possible to trace software requirements to the implementation in code (%)

Is there a whitepaper? (Y/N)

Answer: Yes

Location: https://whitepaper.dydx.exchange/​

Are the basic application requirements documented? (Y/N)

Answer: Yes

Location: https://docs.dydx.exchange/#/protocol​

How to improve this score

Do the requirements fully (100%) cover the deployed contracts? (%)

Answer: 60%

While the basic functions of the code are explained on the website and GitHub, there is no association between these explanations and the code. So it is difficult to determine all the relevant code has requirements.

How to improve this score

This score can improve by adding content to the requirements document such that it comprehensively covers the requirements. For guidance, refer to the SecurEth System Description Document . Using tools that aid traceability detection will help.

Are there sufficiently detailed comments for all functions within the deployed contract code (%)

Answer: 40%

Most structures (for instance in Actions.sol) have definitions. But most function definitions have virtually no commenting. The overall level of commenting is quite low and subsequent code maintenance could be challenging Code examples are in the Appendix: Example Code. As per the Appendix: Software Lines of Code, there is 23% commenting to code.

How to improve this score

This score can improve by adding comments to the deployed code such that it comprehensively covers the code. For guidance, refer to the SecurEth Software Requirements.

Is it possible to trace software requirements to the implementation in code (%)

Answer: 0%

No traceability artifacts are evident in the requirements document or the code. It does not appear to be any intention of the developers. For this reason a score of 0% is unavoidable. In their defense, very few blockchain development programs use traceability yet.

How to improve this score

This score can improve by adding content to the requirements document such that it comprehensively covers the requirements. For guidance, refer to the SecurEth System Description Document . Using tools that aid traceability detection will help.

Testing

This section looks at the software testing available. It is explained in this document. This section answers the following questions;

  1. Full test suite (Covers all the deployed code) (%)

  2. Code coverage (Covers all the deployed lines of code, or explains misses) (%)

  3. Scripts and instructions to run the tests (Y/N)

  4. Packaged with the deployed code (Y/N)

  5. Report of the results (%)

  6. Formal Verification test done (%)

  7. Stress Testing environment (%)

Is there a Full test suite? (%)

Answer: 100%

There are a significant number and lines of tests. There are contract tests (over 28 source files), action tests and others. Without actually running the tests it is difficult to confirm it is a complete test suite, but it certainly appears so. As per the software lines of code Appendix: Software Lines of Code, there is a 221% test to code ratio.

Code coverage (Covers all the deployed lines of code, or explains misses) (%)

Answer: 70%

There are clear artifacts of unit tests (in /tests and /src) and scripts for coverage testing. We did not find the output of the coverage tests. At this point it seems to indicate full coverage. However without evidence, we cannot give a score higher than 70%.

How to improve this score

This score can improve by adding tests achieving full code coverage. A clear report and scripts in the software repository will guarantee a high score.

Scripts and instructions to run the tests (Y/N)

Answer: Yes

In the scripts and readme subdirectory there are scripts to test, coverage, lint and verify.

Packaged with the deployed code (Y/N)

Answer: Yes

The deployed code was saved as a GitHub release. The tests and scripts were packaged with the release in the repository zip file.

Report of the results (%)

Answer: 0%

No test results or reports were saved in the repository.

How to improve this score

Add a report with the results. The test scripts should generate the report or elements of it.

Formal Verification test done (%)

Answer: 0%

No evidence of Formal Validation was found. This is still a rare type of test.

Stress Testing environment (%)

Answer: 0%

No evidence of an active test network was found for the existing deployed protocol.

Audits

Answer: 90%

dydx had multiple audits through their development as documented on their site. The OpenZeppelin audit included improvements that were resolved as indicated. The link to the Bramah audit is broken meaning the audit report is not public. We will not give credit for the second audit.

They have one audit from a top level audit organization. The audits is public and they have implemented findings in order to improve their code.

  1. Multiple Audits performed before deployment and results public and implemented or not required (100%)

  2. Single audit performed before deployment and results public and implemented or not required (90%)

  3. Audit(s) performed after deployment and no changes required. Audit report is public. (70%)

  4. No audit performed (20%)

  5. Audit Performed after deployment, existence is public, report is not public and no improvements deployed (0%)

Appendices

Author Details

The author of this audit is Rex of Caliburn Consulting.

Email : rex@caliburnc.com Twitter : @ShinkaRex

I started with Ethereum just before the DAO and that was a wonderful education. It showed the importance of code quality. The second Parity hack also showed the importance of good process. Here my aviation background offers some value. Aerospace knows how to make reliable code using quality processes.

I was coaxed to go to EthDenver 2017 and there I started SecuEth.org with Bryant and Roman. We created guidelines on good processes for blockchain code development. We got EthFoundation funding to assist in their development.

Process Quality Audits are an extension of the SecurEth guidelines that will further increase the quality processes in Solidity and Vyper development.

Career wise I am a business development for an avionics supplier.

Scoring Appendix

Deployed Code Appendix

Code Used Appendix

Example Code Appendix

/**
* @title Actions
* @author dYdX
*
* Library that defines and parses valid Actions
*/
library Actions {
​
// ============ Constants ============
​
bytes32 constant FILE = "Actions";
​
// ============ Enums ============
​
enum ActionType {
Deposit, // supply tokens
Withdraw, // borrow tokens
Transfer, // transfer balance between accounts
Buy, // buy an amount of some token (externally)
Sell, // sell an amount of some token (externally)
Trade, // trade tokens against another account
Liquidate, // liquidate an undercollateralized or expiring account
Vaporize, // use excess tokens to zero-out a completely negative account
Call // send arbitrary data to an address
}
​
enum AccountLayout {
OnePrimary,
TwoPrimary,
PrimaryAndSecondary
}
​
enum MarketLayout {
ZeroMarkets,
OneMarket,
TwoMarkets
}
​
// ============ Structs ============
​
/*
* Arguments that are passed to Solo in an ordered list as part of a single operation.
* Each ActionArgs has an actionType which specifies which action struct that this data will be
* parsed into before being processed.
*/
struct ActionArgs {
ActionType actionType;
uint256 accountId;
Types.AssetAmount amount;
uint256 primaryMarketId;
uint256 secondaryMarketId;
address otherAddress;
uint256 otherAccountId;
bytes data;
}
​
// ============ Action Types ============
​
/*
* Moves tokens from an address to Solo. Can either repay a borrow or provide additional supply.
*/
struct DepositArgs {
Types.AssetAmount amount;
Account.Info account;
uint256 market;
address from;
}
​
/*
* Moves tokens from Solo to another address. Can either borrow tokens or reduce the amount
* previously supplied.
*/
struct WithdrawArgs {
Types.AssetAmount amount;
Account.Info account;
uint256 market;
address to;
}
​
/*
* Transfers balance between two accounts. The msg.sender must be an operator for both accounts.
* The amount field applies to accountOne.
* This action does not require any token movement since the trade is done internally to Solo.
*/
struct TransferArgs {
Types.AssetAmount amount;
Account.Info accountOne;
Account.Info accountTwo;
uint256 market;
}
​
/*
* Acquires a certain amount of tokens by spending other tokens. Sends takerMarket tokens to the
* specified exchangeWrapper contract and expects makerMarket tokens in return. The amount field
* applies to the makerMarket.
*/
struct BuyArgs {
Types.AssetAmount amount;
Account.Info account;
uint256 makerMarket;
uint256 takerMarket;
address exchangeWrapper;
bytes orderData;
}
​
/*
* Spends a certain amount of tokens to acquire other tokens. Sends takerMarket tokens to the
* specified exchangeWrapper and expects makerMarket tokens in return. The amount field applies
* to the takerMarket.
*/
struct SellArgs {
Types.AssetAmount amount;
Account.Info account;
uint256 takerMarket;
uint256 makerMarket;
address exchangeWrapper;
bytes orderData;
}
​
/*
* Trades balances between two accounts using any external contract that implements the
* AutoTrader interface. The AutoTrader contract must be an operator for the makerAccount (for
* which it is trading on-behalf-of). The amount field applies to the makerAccount and the
* inputMarket. This proposed change to the makerAccount is passed to the AutoTrader which will
* quote a change for the makerAccount in the outputMarket (or will disallow the trade).
* This action does not require any token movement since the trade is done internally to Solo.
*/
struct TradeArgs {
Types.AssetAmount amount;
Account.Info takerAccount;
Account.Info makerAccount;
uint256 inputMarket;
uint256 outputMarket;
address autoTrader;
bytes tradeData;
}
​
/*
* Each account must maintain a certain margin-ratio (specified globally). If the account falls
* below this margin-ratio, it can be liquidated by any other account. This allows anyone else
* (arbitrageurs) to repay any borrowed asset (owedMarket) of the liquidating account in
* exchange for any collateral asset (heldMarket) of the liquidAccount. The ratio is determined
* by the price ratio (given by the oracles) plus a spread (specified globally). Liquidating an
* account also sets a flag on the account that the account is being liquidated. This allows
* anyone to continue liquidating the account until there are no more borrows being taken by the
* liquidating account. Liquidators do not have to liquidate the entire account all at once but
* can liquidate as much as they choose. The liquidating flag allows liquidators to continue
* liquidating the account even if it becomes collateralized through partial liquidation or
* price movement.
*/
struct LiquidateArgs {
Types.AssetAmount amount;
Account.Info solidAccount;
Account.Info liquidAccount;
uint256 owedMarket;
uint256 heldMarket;
}
​
/*
* Similar to liquidate, but vaporAccounts are accounts that have only negative balances
* remaining. The arbitrageur pays back the negative asset (owedMarket) of the vaporAccount in
* exchange for a collateral asset (heldMarket) at a favorable spread. However, since the
* liquidAccount has no collateral assets, the collateral must come from Solo's excess tokens.
*/
struct VaporizeArgs {
Types.AssetAmount amount;
Account.Info solidAccount;
Account.Info vaporAccount;
uint256 owedMarket;
uint256 heldMarket;
}
​
/*
* Passes arbitrary bytes of data to an external contract that implements the Callee interface.
* Does not change any asset amounts. This function may be useful for setting certain variables
* on layer-two contracts for certain accounts without having to make a separate Ethereum
* transaction for doing so. Also, the second-layer contracts can ensure that the call is coming
* from an operator of the particular account.
*/
struct CallArgs {
Account.Info account;
address callee;
bytes data;
}
​
// ============ Helper Functions ============
​
function getMarketLayout(
ActionType actionType
)
internal
pure
returns (MarketLayout)
{
if (
actionType == Actions.ActionType.Deposit
|| actionType == Actions.ActionType.Withdraw
|| actionType == Actions.ActionType.Transfer
) {
return MarketLayout.OneMarket;
}
else if (actionType == Actions.ActionType.Call) {
return MarketLayout.ZeroMarkets;
}
return MarketLayout.TwoMarkets;
}
​
function getAccountLayout(
ActionType actionType
)
internal
pure
returns (AccountLayout)
{
if (
actionType == Actions.ActionType.Transfer
|| actionType == Actions.ActionType.Trade
) {
return AccountLayout.TwoPrimary;
} else if (
actionType == Actions.ActionType.Liquidate
|| actionType == Actions.ActionType.Vaporize
) {
return AccountLayout.PrimaryAndSecondary;
}
return AccountLayout.OnePrimary;
}
​
// ============ Parsing Functions ============
​
function parseDepositArgs(
Account.Info[] memory accounts,
ActionArgs memory args
)
internal
pure
returns (DepositArgs memory)
{
assert(args.actionType == ActionType.Deposit);
return DepositArgs({
amount: args.amount,
account: accounts[args.accountId],
market: args.primaryMarketId,
from: args.otherAddress
});
}
​
function parseWithdrawArgs(
Account.Info[] memory accounts,
ActionArgs memory args
)
internal
pure
returns (WithdrawArgs memory)
{
assert(args.actionType == ActionType.Withdraw);
return WithdrawArgs({
amount: args.amount,
account: accounts[args.accountId],
market: args.primaryMarketId,
to: args.otherAddress
});
}
​
function parseTransferArgs(
Account.Info[] memory accounts,
ActionArgs memory args
)
internal
pure
returns (TransferArgs memory)
{
assert(args.actionType == ActionType.Transfer);
return TransferArgs({
amount: args.amount,
accountOne: accounts[args.accountId],
accountTwo: accounts[args.otherAccountId],
market: args.primaryMarketId
});
}
​
function parseBuyArgs(
Account.Info[] memory accounts,
ActionArgs memory args
)
internal
pure
returns (BuyArgs memory)
{
assert(args.actionType == ActionType.Buy);
return BuyArgs({
amount: args.amount,
account: accounts[args.accountId],
makerMarket: args.primaryMarketId,
takerMarket: args.secondaryMarketId,
exchangeWrapper: args.otherAddress,
orderData: args.data
});
}
​
function parseSellArgs(
Account.Info[] memory accounts,
ActionArgs memory args
)
internal
pure
returns (SellArgs memory)
{
assert(args.actionType == ActionType.Sell);
return SellArgs({
amount: args.amount,
account: accounts[args.accountId],
takerMarket: args.primaryMarketId,
makerMarket: args.secondaryMarketId,
exchangeWrapper: args.otherAddress,
orderData: args.data
});
}
​
function parseTradeArgs(
Account.Info[] memory accounts,
ActionArgs memory args
)
internal
pure
returns (TradeArgs memory)
{
assert(args.actionType == ActionType.Trade);
return TradeArgs({
amount: args.amount,
takerAccount: accounts[args.accountId],
makerAccount: accounts[args.otherAccountId],
inputMarket: args.primaryMarketId,
outputMarket: args.secondaryMarketId,
autoTrader: args.otherAddress,
tradeData: args.data
});
}
​
function parseLiquidateArgs(
Account.Info[] memory accounts,
ActionArgs memory args
)
internal
pure
returns (LiquidateArgs memory)
{
assert(args.actionType == ActionType.Liquidate);
return LiquidateArgs({
amount: args.amount,
solidAccount: accounts[args.accountId],
liquidAccount: accounts[args.otherAccountId],
owedMarket: args.primaryMarketId,
heldMarket: args.secondaryMarketId
});
}
​
function parseVaporizeArgs(
Account.Info[] memory accounts,
ActionArgs memory args
)
internal
pure
returns (VaporizeArgs memory)
{
assert(args.actionType == ActionType.Vaporize);
return VaporizeArgs({
amount: args.amount,
solidAccount: accounts[args.accountId],
vaporAccount: accounts[args.otherAccountId],
owedMarket: args.primaryMarketId,
heldMarket: args.secondaryMarketId
});
}
​
function parseCallArgs(
Account.Info[] memory accounts,
ActionArgs memory args
)
internal
pure
returns (CallArgs memory)
{
assert(args.actionType == ActionType.Call);
return CallArgs({
account: accounts[args.accountId],
callee: args.otherAddress,
data: args.data
});
}
}

SLOC Appendix

Solidty Contracts

Language

Files

Lines

Blanks

Comments

Code

Complexity

Solidity

32

11339

1264

1853

8222

518

Comments to Code 1853/8222 = 23%

Javascript Tests

​

Language

Files

Lines

Blanks

Comments

Code

Complexity

TypeScript

55

20465

1955

337

18173

846

Tests to Code 18173/8222 = 221%