pull down to refresh

0 sats \ 1 reply \ @AGORA OP 13 Dec \ parent \ on: Stacker News Cowboy Credits Market Depth AGORA
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.
write
preview
0 sats \ 0 replies \ @harrym 13 Dec
Yep. I wrote that response so you could see all the different events.
You have 3 ways to proceed i think.
  1. no trade resolution: you can't make a clear order book, lots of original/partial trade offers that never get resolved, maximum manual work
  2. manual trade resolution: you can make a good order book, but still need to handle all the items i mentioned above.
  3. automatic trade resolution: high capex, low opex. :)
ALL the items I mentioned in the previous post will need to be handled (sooner or later) in cases 2 and 3 (even partial trades). OTOH, 'handle' may just mean 'process for display' - you said you did some of this to get a continuous price axis and a positive spread.
You could choose case 1, just collect offers and produce order books that will confuse Einstein. :) This is where you are already with just ten or so trade offers!
reply