Description

By using IPFS to host the site, and OrbitDB and ZeroX (decentralized exchange protocol, takes care of Solidity exchange logic) to create a separate order book on top of EtherDelta's, a 100% decentralized exchange where there are no hosting costs or scaling concerns becomes possible.
Along with the normal green and red orders showing up in the order book, orange ones could appear that indicate an order that will cost the taker no fees and offer a significantly lower gas price than available through the ED contract.
In the future, the ZeroX infrastructure could give us access to liquidity from other exchanges like Radar Relay in addition to ED.

OrbitDB is a decentralized database protocol built on IPFS, it will enable users to make and take orders off-chain without relying on a centralized service.

Rationale

A 0% fee would undercut the industry. Along with the increased trust that comes from an entirely decentralized and open source project, integrating orders that are free to all users on top of normal ED 0.3% orders would allow a smooth transition for users as liquidity eventually moves to the new system. Finally, EtherDelta's fee code wastes a significant amount of gas, so users stand to save even more than the fee itself. This system has the potential to leapfrog all other exchanges and create an industry standard that the entire Ethereum community can be proud of.

0x requires Mist/Metamask which makes it hard to write bots I don't think it is the best idea for the future @freeatnet

So, having to manually list every token is cumbersome and requires a constant developer on the project.

I propose we figure out a way for this system to list as many ERC20 tokens automatically as possible.

We could use CMC to pull every ERC20 token they have listed as a start and write some code that scans large exchanges later.

Is there a way to scan for new ERC20 tokens and automatically list them?

This would be a future addition, but it seems NEO is here to stay. Maybe we should start looking into integrating NEO down the road?

I believe that the end goal is to use 0x as our trading contract. However, I believe that, in the interim, we can make some slight changes to ED's original contract that could make it much cheaper. This would be a temporary solution, but could be a really quick fix to about half of the fees currently on the system and would help us start having our own order book.

I copied this from Reddit, so I haven't verified its' contents:

"I suggest that you rewrite the contract to eliminate the fees. Eliminating the fees will also lower the gas cost by half. Looking at the source code, make these changes:

proposed changes to https://etherscan.io/address/0x8d12a197cb00d4747a1fe03395095ce2a5cc6819#code

eliminate lines 131 to line 149 because all accounts are equal and none should pay a fee

eliminate lines 155, 156, 157
all lines with the word 'fee'

line 168 to 175...i think this can be eliminated, but I am not sure what the function of admin is

not sure what the purpose of line 177 to 179 is

I think lines 181 to 212 can be eliminated, but I am not sure

line 252, I don't understand how signatures work (that is, the r and the s)

line 265 to 279, I think much of this can be eliminated, but not sure. Also, I am not entirely clear on the distinction between private and public functions

line 281 to 287, I am not sure on this. I don't know why there is a 'testTrade' function. Perhaps this tests to see if a trade is allowable before executing it. This would prevent malformed orders"

We need to introduce API rate limiting to ensure fair and equitable access to the system and to prevent abusive behaviour.

Every connection must be attributed to an API client. I see there a number of use-cases into which API clients can be bucketed:

1. Public trading interface
2. Personal copy of the ForkDelta interface
3. Trading bot
4. Utility client: a website, mobile app, or script that requests data, but does not place any orders

Public Trading Interface

A public trading interface allows a human user to retrieve data and post new orders. Connections are restricted to a specific set of Origin headers, and are rate-limited based on end-user IP address (based on the IP of the client connecting to our API). A public trading interface may additionally be limited to a finite number of simultaneous user connections. Currently, only one public trading interface will be allowed: the official ForkDelta interface.

Personal Copy of The ForkDelta Interface

A personal copy of the interface client is similar to a public trading interface client. A personal copy of the interface may not be accessible publicly from the Internet or indexable by Google (the interface can be restricted by being hosted on localhost, an IP address filter, HTTP authentication, or any other means ensuring no public access). A personal copy of the interface will be limited to a finite number of simultaneous user connections.

Trading Bot

A trading bot may receive data and post new orders to the website. A trading bot client is restricted to a specific set IP addresses or required to connect with a specified secret, and is rate-limited across all connections. Trading bot clients are subject to periodic audit of their API usage.

Utility Client

A utility client may receive data from the API, but is not allowed to post orders. A utility client is restricted to either a specific IP address, a specific set of Origin headers, or required to connect with a specific secret. The client is not rate-limited beyond the global limits.

Rate limiting

Rate limiting should occur based on the type of action performed by the client using the leaky bucket model. The bucket will be filled with the maximum amount of API "credits" upon initial connection, less the cost of the connection, based on the API client type. When the client connection issues a request, a number of API credits proportional to the cost of the associated operation will be subtracted. The subtraction may occur before or after the requested operation. If the client does not have sufficient credits to perform the operation, the API will respond with a defined error code. The bucket will be re-filled on a periodic basis and will expire after a fixed amount of time after creation.

Further Work

• Exact values of API credits issued per connection per client type should be worked out.
• A client application type can further be split into tiers based on the needs of an application.

Rationale:

1. No server costs.
2. Infinite scaling.
3. Massively increased user trust by enabling signature verification of that the code on the website matches the publicly reviewable code on Github.
4. Increased protection from MITM and impersonation attacks due to (3).

POC: http://zaptremworld.com

This could be used for dev updates, changelogs, token listings, events, etc.

Possible platforms: Medium, Wordpress

Docs do not mention how to cancel my open order over ForkDelta API. Is it possible?

https://github.com/forkdelta/backend-replacement/tree/master/docs/api

Roadmap
FAQ
Links to Community stuff

Adding this here so I remember.

This should be added to live and nextgen-ui.

We will be launching our Hardware Wallet in December, How do we go about getting you guys to support the hardware wallet? Htttps://gymledger.com

Change default pair and landing page from PPT-ETH to DAI-ETH.

Rationale:

1. More neutral (no bias toward any specific speculative token)
2. More intuitive (users are used to seeing the Big Three tied to USD values)

Allow users to search for tokens by their symbol and full name.

Multiple people have reached out offering donations to help the service along. I think that's a sign to set something up.

Questions:

• How are those funds distributed and used?
• Do we reward donations? If so, how?
• Are there any restrictions on donations accepted?

ADDED

• What is the spending schedule of the donations?