pull down to refresh
0 sats \ 9 replies \ @harrym 11 Dec \ parent \ on: Stacker News Cowboy Credits Market Depth AGORA
You'd have to execute the overlapping trades first, then you can show a less confusing order book.
reply
reply
I learnt by looking at normal exchanges (mtgox, bitstamp, bitfinex).
I don't think I ever used anything I could offer as a reference, but there are many youtube traders.
hmm. I did at one time read discussion from when bitfinex was being created - I guess the ideas started becoming clear then.
I'm not a trader, but i did try to get it clear in my head back then.
I just realized you are new to trading, so the useful key words for you would be 'exchange order book'. I just did one that tells way more than you need: https://www.investopedia.com/terms/o/order-book.asp
I'm happy to help if I can.
Are you planning to make the changes to resolve the trades automatically?
If you expect any traffic, manual resolution is out of the question.
reply
That help a lot! Made some changes and should be live soon. I was also able to give the
SPREAD a positive value.I, indeed, am not a trader either and am not familiar with such things. This was an exercise to track the effective value of CCs against Bitcoin (sats), as
1cc = 1sat is just the default value SN is selling CCs.For now, manual resolution seems the obvious path, as stackers are posting here buy and sell offers. But I see the case for resolving the trades automatically somehow. Have no idea where to start, and any help is more than welcome.
reply
There's a lot of work around efficient trade engines (which I have no interest in).
Assuming efficiency is not important tho, I can see a simple scan thru the price range and check/resolve any trades that can be executed. You might need to decide who offered their trade first at any given price i guess.
I have no idea what your programming environment is. Would the code run on SN? A Bash script maybe? Is there a database holding the trade offers?
Perl used to fantastic at handling text only stuff, but noone likes it any more :(
reply
efficient trade engines
Not even know wth is that, I'll look into it just for curiosity.
Would the code run on SN? A Bash script
Fun fact I'm not a dev, I don't see such a solution built-in in SN, a Bash script? Perhaps. The ~AGORA marketplace is available as a space to post such offer/bids. Have no idea how or where a db can be hold and maintained. For now it's just a
js embedded in this html.Any suggestion on how to handle this is more than welcome, as I see there's a need for some stackers to get rid of unwanted CCs and others that want to buy P2P at better rate.
reply
I see the problem.
Its expected to be low volume, so minimal effort to get something working. But that means high ongoing maintenance to update trades, execute trades, confirm trades, allow partial trades, etc.
I'm not sure how you want to proceed.
For sure, you will prolly NOT want to be hard coding the orders like that forever. You likely want them out in a db-like file, even if its text, say csv? That would enable order updates more easily.
I'm no javascript guy, but surely there's a simple database module you can call in? With something like that, maybe you need more js that ensures standard format and allows user additions to the order file.
Some thoughts that apply whether you do manual or automatic handling...
Background on exchange order types:
1 spot orders, where a user just specifies the volume and the exchange fills the order starting at the best price (for the user) and then 'next' available (but worse) price etc. until the volume is reached.
2 limit orders, where a user specifies a volume and a limit price and the exchange handles all trades available until the price is reached or the trade is filled.
You're using something like limit orders, except you're not allowing for users to get the best price at the time of execution. For example, I might place an order to buy something at .9 sats and someone else places an order to sell that item at .89, then my order should get filled at .89. That makes your order book look weird, and you (or users) would need to notice then resubmit the trade.
Both types may result in partial order fulfillment. That would also need to be handled.
How would you actually know a trade had been resolved by any two users? They would likely just leave their trade offers in your list unless you hound them.
reply
I see the problem. Its expected to be low volume, so minimal effort to get something working. But that means high ongoing maintenance to update trades, execute trades, confirm trades, allow partial trades, etc.
Perhaps really minimal effort. And if we continue having this amount of offers/demands, a solution like this will probably be enough.
I'm not sure how you want to proceed.
I'm not sure about that either.
For sure, you will prolly NOT want to be hard coding the orders like that forever.
Indeed no! That's why I shared the repo for others to easily add offers and contribute.
You likely want them out in a db-like file, even if its text, say csv? That would enable order updates more easily.
That would be an ideal scenario.
I'm no javascript guy, but surely there's a simple database module you can call in?
Yes, I could. This means we will need a way for users to submit the requests/offers to the db with a form Ui or something.
With something like that, maybe you need more js that ensures standard format and allows user additions to the order file. Some thoughts that apply whether you do manual or automatic handling...
This is a great exercise for me, to learn about markets first and also how to handle such things. Thank you.
1 spot orders, where a user just specifies the volume and the exchange fills the order starting at the best price (for the user) and then 'next' available (but worse) price etc. until the volume is reached.
in this case, would the user pay a higher cc/sat rate, which he is not in control of?
2 limit orders, where a user specifies a volume and a limit price and the exchange handles all trades available until the price is reached or the trade is filled.
This makes more sense, but as you can see from the current orders list, both types of orders have arrived. That's why I decided to simplify the order book, showing only the cc/sat exchange rate from the orders.
You're using something like limit orders, except you're not allowing for users to get the best price at the time of execution. For example, I might place an order to buy something at .9 sats and someone else places an order to sell that item at .89, then my order should get filled at .89. That makes your order book look weird, and you (or users) would need to notice then resubmit the trade.
We are talking proper automation here! That would be super cool to have an order filled when a better offer is made available. But how? Again, for now CCs are available only inside SN and the trades happen P2P. Another factor to consider are the syblil fees: territory funders are able to offer better rates because they get 21% (for now) back from each zap, and zaps are the only way to deliver CCs to the buyer. SATs can be delivered out of SN and avoid syblil fees. Some orders have fees included; others, like this, seem not to consider sybil fees. Consequently, to the unseasoned stacker, this offer could appear the most advantageous, but in reality, is not, as I don't think Darthcoin is willing to pay extra 30% fees to fulfill the order at the
1cc=1sat rate he is offering.So this sybil fee is kind of an issue, and I'm not sure how to handle it.
Both types may result in partial order fulfillment. That would also need to be handled.
That's another extra case scenario I did not consider. I guess it is a consequence of automating order fulfillment?
How would you actually know a trade had been resolved by any two users? They would likely just leave their trade offers in your list unless you hound them.
Correct, most of the offers there now are open offers. CCs vendors are usually just sharing the cc/sat rate they aim to sell and waiting for buyers to come.