pull down to refresh
0 sats \ 8 replies \ @AGORA OP 12h \ parent \ on: Stacker News Cowboy Credits Market Depth AGORA
Thanks for sharing; it does make sense. Consider there's no automated exchange here for selling or buying CCs, it's all P2P. This is a simple, humble initiative to gather the data and make sure there are fair trades around.
There's probably some errors in how the data is calculated; this is a first iteration. With the help of feedback like yours, we can improve accuracy and KPIs.
How would you display the data to make it more understandable? Any reference helps
reply
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.