reply on: Stacker News Cowboy Credits Market Depth \ stacker news ~AGORA

pull down to refresh

0 sats \ 3 replies \ @AGORA OP 14h \ parent \ on: Stacker News Cowboy Credits Market Depth AGORA

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.

0 sats \ 2 replies \ @harrym 14h

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 :(

0 sats \ 1 reply \ @AGORA OP 12h

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.

0 sats \ 0 replies \ @harrym 10h

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.