0xproject / 0x-protocol-specification Goto Github PK

HMAC_SHA256

Originally posted by @Hani1obaid in Uniswap/tokenlists-org#1788 (comment)

Context of asking: why was the AssetProxy concept removed?

I'm trying to get an order hash from an order and noticed a difference between the official EIP712 example and what is in the spec here.

https://github.com/ethereum/EIPs/blob/master/assets/eip-712/Example.sol

struct EIP712Domain {
    string  name;
    string  version;
    uint256 chainId;
    address verifyingContract;
}

https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#eip712-usage

// Hash of the EIP712 Domain Separator Schema
bytes32 constant internal EIP712_DOMAIN_SEPARATOR_SCHEMA_HASH = keccak256(abi.encodePacked(
    "EIP712Domain(",
    "string name,",
    "string version,",
    "address verifyingContract",
    ")"
));

bytes32 EIP712_DOMAIN_HASH = keccak256(abi.encodePacked(
    EIP712_DOMAIN_SEPARATOR_SCHEMA_HASH,
    keccak256(bytes("0x Protocol")),
    keccak256(bytes("2")),
    bytes32(address(this))
));

The 0x spec is missing chainId. Is this intentional? It seems like it will be a problem.

Also, what address is the "this" referring to? The only place I see "verifyingContract" used in the spec is in the code I've pasted.

On a related note, are there any examples of valid orders and hashes so I can verify that what I'm doing matches what the protocol expects?

For orderEpoch, the spec says:

Orders specified makerAddress and senderAddress with a salt <= this value are considered cancelled.

Yet in the contract has the code:

orderEpoch[order.makerAddress][order.senderAddress] > order.salt

which is equivalent to "salt < this value" rather than "salt <= this value".

See: https://github.com/0xProject/0x-monorepo/blob/v2-prototype/packages/contracts/src/2.0.0/protocol/Exchange/MixinExchangeCore.sol#L187

At OpenRelay we just discovered a bug in our v2 implementation where the 'v' value of signatures was expected to be 1 or 0 (based on the Geth implementation of ecRecover) instead of 28 or 27 as is expected in Solidity.

Many applications / libraries will accept signatures in either range, making it easy to be uncertain which should be provided in a given case. I don't think it's wise for the contract to "fix" signatures that use a 0 / 1 value for V, but I think it would be helpful if the specification clarified the expected range for this value.

"0x uses a modular system of Ethereum smart contracts which allows each component of the system to be upgraded via governance without effecting" should be changed to "0x uses a modular system of Ethereum smart contracts which allows each component of the system to be upgraded via governance without affecting"

I'm upgrading some code I wrote for v1 to v2 and am planning to make use of the matchOrders function. It works for 2-currency arbitrage opportunities, but I've seen some times where 3 orders between 3 different assets can all fill each other. Would it be possible to expand matchOrders to accept more than 2 orders? What would that involve?

It would be awesome to be able to execute triangular arbitrage without needing any tokens besides eth for gas, but if expanding matchOrders is not simple/possible, how would you recommend filling 3 or more orders in one eth transaction? I think batchFillOrKillOrders is what I should use, but that requires that I have tokens for the first order that can't come from the last order.

I asked about this and more on r/0xProject.

I want to add 0x Instant to Cheddur, and I would like to add more ERC20 tokens than are available in the default list. As an example, let's say Self Storage Coin (https://etherscan.io/token/0xa3ceac0aac5c5d868973e546ce4731ba90e873c2).

I see from the docs that this is done via the additionalAssetMetaDataMap configuration option, but the part I do not understand is how to generate asset IDs for use within this mapping.

Consider the following example from the docs:

additionalAssetMetaDataMap: {
         '0xf47261b0000000000000000000000000744d70fdbe2bc4cf95131626614a1764df805b9e': {
                assetProxyId: '0xf47261b0', // ERC20 Proxy Id
                decimals: 18,
                primaryColor: '#F2F7FF', // Optional
                symbol: 'XXX',
                name: 'My Custom Token',
            },
        },

How is 0xf47261b0000000000000000000000000744d70fdbe2bc4cf95131626614a1764df805b9e derived? It looks to be a combination of the ERC20 Proxy Id + padded zeros + the token's contract address. But the questions here are...

• How many zeros and why?
• Does the number of zeros vary from token to token?
• Is there a clean way to generate an asset's ID in javascript given a contract address and proxy type, or should we just use string concatenation?

Thanks!

Originally posted by @Hani1obaid in https://github.com/kingslay/KSAssetExportSession/issues/4