forkdelta / smart_contract Goto Github PK

https://github.com/forkdelta/forkdelta.github.io/issues/20

MetaMask is currently displaying the following when the user attempts to sign an off-chain order:

Signing this message can have dangerous side effects. Only sign messages from sites you fully trust with your entire account. This dangerous method will be removed in a future version. Read more here.

With the added ECR223 compatibility we need test cases for the following:

• Use approve and depositToken to deposit an ECR223 token into the FD contract. Expected: Updated user token balance
• Use Token.transfer to deposit an ECR223 token into the FD contract. Expected: Updated user token balance.
• Use approve and depositToken to deposit an ECR223 token that fails to implement approve/transferFrom into the FD contract. Expected: Sender does not lose funds
• Use Token.transfer to deposit an ECR223 token that fails to implement approve/transferFrom into the FD contract. Expected: Updated user token balance.

Hey Forkdelta Team,

I noticed on your roadmap that you mention working on 0x. Let me know how I can help or if you have any questions or designs you'd like to talk over.

0x v2 is on Kovan right now and is going through security audits. We expect to be on mainnet after the completion of these audits.

If you want to take a sneak peak we have a starter project going over the usecases (Ganache and Kovan).

Feel free to reach out any time via [email protected] or in our Rocket Chat

tradeBalances checks the current time to see if it is before may 1st and if it is, the trades are free.

We should make this a variable that the admin address can transmit so we can run free trading promotions in the future.

So, ERC223 brought about a new transfer function that cuts the gas necessary in half.

However, we can't bundle both ERC20's old transfer methods and ERC223's new transfer as solidity doesn't allow us to check what type the requested token is AFAIK.

The current smart_contract.sol in this repo "supports" ERC223 by using a fallback, but it still goes through approve and transferFrom .

I propose that, for future proofing, we create some sort of system where each protocol (ERC20, ERC223) can have a separate contract. Then, the interface calls the contracts based on the type of token. That way, we can utilize each protocol's benefits. This would also allow us to add future protocols with ease as we would simply create a new contract for the protocol instead of editing an old one.

This is not necessary NOW, but would be a welcome addition in the future.

Hi,
When i deposit the OMG TOKEN
https://etherscan.io/address/0xd26114cd6EE289AccF82350c8d8487fedB8A0C07
, i find run error, i find out The OMG source transferFrom function not return any ,

contract ERC20 is ERC20Basic {
  function allowance(address owner, address spender) constant returns (uint);
  function transferFrom(address from, address to, uint value);
  function approve(address spender, uint value);
  event Approval(address indexed owner, address indexed spender, uint value);
}

but the ERC20 interface is require return bool type value. I find out this project deposit function's ERC20 interface is return bool value.
It run for deposit OMG will error. seems

    require(IToken(token).transferFrom(msg.sender, this, amount));

throw should be replaced with revert() because throw is deprecated.
revert() is beneficial because it returns unused gas.

trying to compile with truffle and get always this error
Expected identifier, string or number.

Picture
http://prntscr.com/ker26k

https://ropsten.etherscan.io/tx/0x96679c7cec365c4130bfce5859cc05f20a7dcaa2f0005b1d86574a77dd410db0
Contract created successfully, but transaction itself is failed. Why? No explanation what is the problem, nothing.

Can anyone resolve this issue and spot where exactly the problem and why this transaction is failed but contract is success?

Contract constructor parameters are:

"0xB4deA6568c35501F745b6e764941B82974787159", "0xB4deA6568c35501F745b6e764941B82974787159",
10,
0,
"0xB4deA6568c35501F745b6e764941B82974787159"

• Init a truffle project directory
• Add a README.MD for developers
• Add initial support for at least testRPC, maybe ganache

Hello

I need someone to install the contract for me.

I am willing to pay

Please contact me [email protected]

On which parameters?
What is the use case for this?
How much more expensive will the events be?

i can pay for the job email me
[email protected]

Hi can someone advise me please
When you build the contracts it outputs JSON files for each of them where do I find the byte code

Also once I have deployed them do I need to add them to the websites smartcontract section in this location
https://github.com/forkdelta/forkdelta.github.io/tree/master/smart_contract

If someone could just point me in the right direction I have every thing setup and working now just deploying the smartcontracts is holding me back

Thank you

"ismaelbej 2 points 1 month ago
There's an issue with ERC 223 tokens. When you call depositToken it will call transferFrom from the token contract, and ERC223 tokens check the recipient is a contract and tries to call tokenFallback. Since the recipient is the EtherDelta contract it tries to call tokenFallback which doesn't exists, so the default fallback is called instead, which throws immediately."

ethereum/EIPs#223 (comment)

When calling functions in other contracts we make assumptions about what happens there, e.g. with our calls:

Token(token).transfer(msg.sender, amount)
Token(token).transferFrom(msg.sender, this, amount)

We should check after these calls, if what we expected actually happened, e.g. after Token(token).transferFrom(msg.sender, this, amount) we expect amount more tokens in our contract than before.

could you add a function to send ETH or TOKENS that are on the smart contract to a ETH address of my choice? so I don't have to withdraw and send than from my address and use gas twice?
the function right now only works from the ETH address that is connected to FD but not directly form the SC _> so you need to make two transactions for something that could be done in one.

I always hated that about ED would love to use that feature on FD.

maybe the menu point Transfer could have both options to send from my ETH address as it is now or from the smart contract.

We should have proper comments within the smart contract itself at least for every function.

This will help us create full documentation of the smart contract when it's finished.
More importantly, this will make it much easier for normal users to understand what is going on in the smart contract.