It seemed crazy to me that none of the personal newsletter services out there let you just write the filter prompt yourself, so I built this. I think its much simpler and more flexible. Feedback welcome!
> But those fees go to stakers (who do provide a service, albeit a dumb one).
That service is the point of the whole thing. The fees go to stakers who *execute your computation for you and ensure the integrity of the results*. ETH is analogous to credits on AWS. It's simply an execution environment with different properties from AWS.
Again. I don’t know how to say this enough times or clearly enough.
If people were buying goods and services with crypto then I would agree with you but they are not.
Right now it’s circular and moving in the wrong direction. People buy coins with fiat to pay stakers to buy other currency. That’s the only use case. And a big part of that is because what ETH does is actually one of the theoretically worst ways to buy goods/services imaginable.
That is why it’s a ponzi scheme no matter how similar it seems to non ponzi businesses.
Let’s put it this way, Lu Lu roe (or whatever that mlm scam was called) looks a lot like lululemon, except in one people bought the leggings because they liked them and in the other they bought the leggings to get rich.
Only one of those two was a ponzi, even if they both sold leggings.
Is amazon web services not a service people pay for? People are currently buying computation (a service) with crypto. I spend ETH to deploy and execute code, in the exact same way I pay USD to AWS to deploy and execute my code.
They aren't that unusual on an absolute basis but relative to the number of orders in a stock they are quite rare (iirc - it's been a while since I was directly involved in this).
This is a cool project btw - I'm looking for my first chance to really sink my teeth into rust so found it interesting. A few non-rust observations (you probably know all this but kept your orderbook simple which is totally cool but just in case):
An actual order book has a "tick ladder" which specifies which price points are valid for a given ticker on a given venue. This means you actually know all the possible prices ahead of time. If you ever wanted to productionize this you could probably take advantage of that and make a custom data structure that used the fact that you had all the keys preset and did the insert and lookup in O(1).
Secondly in real life the matching logic is quite a bit more complex because of order flags and venue logic. If you're just covering US venues you don't need to worry about venues because of Reg NMS but anywhere else you'll want the order books to actually by venue and symbol not just symbol.
Order flags interfere with matching in a number of ways. Firstly a normal limit order will partially match up to the limit and any remaining quantity will sit on the book waiting to be matched. You can flag the order as "fill or kill" to say fill the whole order or nothing and you can flag it as "immediate or cancel" to say don't put any remaining quantity passively on the book. There are many other order flags but those are probably the most important ones for matching.
Secondly on many venues orders can have an iceberg order type which means that only the "tip" quantity gets shown on the book but they will actually match up to a larger quantity at that price.
Finally you can add a "minimum executed quantity" on any passive orders to prevent pinging (information leakage). This will only match with incoming orders bigger than the MXQ, so messes with the normal price, time ordering. Orders behind that order could match first potentially. MXQ is more important for dark venues or order types so maybe you don't need to consider it.
Thanks for the info! I definitely did not know all of that :). I do work at a crypto exchange, but on the custody/stablecoin side, not the exchange team.
Can you elaborate a little on the "pinging" process to extract information? Sounds interesting
You are most welcome. I'd be somewhat surprised if crypto exchanges supported all the same stuff I mentioned - it's based on my history on equity exchanges and I'd expect crypto to be different.
Anyway the way MXQ and pinging works is imagine you have an orderbook where passive orders are not visible to other participants (ie the venue is dark or you have a grey venue where some orders can be flagged as dark). It's possible fro participants to pay to learn what orders are in the book by making some very small aggressive orders and seeing where they match. In the world of equities this would be buy 1 share agressively, sell 1 share agressively with a limit in each case. This is called "pinging" because it's like ICMP ping discovering whether hosts are alive. The concept in crypto (if it applies) would be the smallest quantity the exchange allows you to buy or sell.
Assuming the venue supports it, you can prevent your dark orders matching these pings by setting an MXQ. If your MXQ is 100 say, they would need to buy 100 shares for your order to match. You would set the size to a point where you don't mind giving up the information about where your order level is because the match is meaningful enough.
Async/await syntax is poorly documented across the ecosystem but has landed now and is useful, without it codebases will look outdated soon enough, hyper itself has some of the best docs
Lazystatic is popular way to use globals like that yet don't really bother with it anymore. The paradigms are a bit different for a language, you are discouraged from such things for a reason, there's certainly ways around using globals.
You don't need extern crate with 2018 edition and macros are automatically imported
Instead of lazy static, use once_cell’s Lazy type[0]! It is a replacement that does away with the macro-based approach, possible thanks to improvements in const fn. This leads to improved IDE experience.
Thanks! What would you suggest instead of a global/lazy static in this situation though? I recall struggling to pass some dynamically allocated structure into the hyper service instantiation.
reply