There are quite a few liquidity protocols around now that weren’t around at Nash’s inception.
Bancor, Kyber, Uniswap, Ren, Liquidity Network, Loopring, 0x, Oasis, Airswap, etc…
Totle’s integrated quite a few of these into their service.
Is it possible for Nash to integrate with some/all of these protocols to add market depth, possibly by way of having a company wallet that can move funds between the state-channels and main-chains?
Those are for ETH and ERC-20 tokens only, right ? Just curious if they’ve extended their service to other chains.
Most of the decent DeFi projects are on ETH only, for now that’s enough since there’s not much activity on NEO and we don’t support EOS yet (not much activity there either).
Ok thanks. I’m trying to grasp how that could work for Nash. Do you think it’s compatible with the state channels they’re using to build the plaform. Don’t you think this extra step would deteriorate Nash’s trading speed (and thus experience)? Liquidity is important but if it was the only issue the above names would have replaced CEXes by now…
This is the killer question ive been thinking about … we just need moar coins 
!!
im biased but forget the liquidity aggregators like 0x for the time being
Nash is the liquidity aggregator not through coin issuance but dAPI issuance (if u get me )
I got 2 queries to figure out :
Can dAPI’s be sophisticated enough to service the price information fluctuations from onchain oracles and their liquidity re-balancing algos ?
I dont think onchain swaps on BTC will ever make sense … anyone got an opinion to the contrary ? id like to hear it 
An API - be it decentralized or not - is a pretty simple concept: it works as intended or doesn’t. Unless by “sophisticated” you mean robust enough to carry the load and not too restrictive in terms of rate limiting?
I guess it could be possible but there are no plans to go that route. Fabio talked about it back in October:
Once GA arrives, liquidity on the exchange will be ramped up and should hopefully be sufficient.
yep what im getting at is these dAPI’s need to be able to suitably service onchain liquidity pools requirements.
which im distilling down to fast provision of liquidity and (or) counter party orders
moving between state channels and onchain “orders”
By “sophisticated” … maybe u can help me out here ?
these dAPI’s will need to be able to perform buy/sell and withdrawal functions based on the price oracle information and liquidity algos originating from a liquidity pool
lol that just put a pin in it 
