RustQuant: a Rust quant library that is honest about being a side project
Rust library for quantitative finance.
At a glance
- What is it?
- RustQuant bundles option pricing, stochastic process generators, time and calendar handling, a limit order book and a small machine learning module into one Apache-2.0 crate. Its own README tells you not to trade on it, and that warning should shape how you read the rest.
- Who is it for?
- Adopt RustQuant if you are building a Rust pricing or simulation tool and want a single dependency that already covers day counters, calendars, distributions, Brownian motion variants, short-rate models and a basic limit order book, and if you are willing to read the source when the docs run out.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What RustQuant is trying to be, and who it is aimed at
RustQuant is a Rust library for quantitative finance, published under a dual MIT and Apache-2.0 licence and hosted at avhz/RustQuant. The README frames it as a broad toolkit rather than a single-purpose crate: pricing instruments, generating stochastic processes, handling dates and calendars, storing curves and surfaces, running regressions, and maintaining a limit order book all live in the same repository. The author's own pitch is a direct appeal for collaborators, asking experienced quant developers in any language to get in touch.
That framing tells you the intended audience. This is not a library built for a bank's production risk stack, where a single wrong day-count convention is a regulatory problem. It is for people who want to write Rust and do quantitative work in the same process: a Rust developer prototyping a pricing model, a researcher who wants type safety and Cargo's dependency management instead of a Python environment, or someone building a simulation harness who would rather not reimplement the normal distribution and a Brownian motion generator from scratch.
The scope is wide, and width is the point. A user who needs only a limit order book still pulls in the pricing and statistics code, because the modules ship together.
The module map is the real documentation
The README's most useful content is its module table, because it tells you what actually exists rather than what the project aspires to. The autodiff module implements algorithmic adjoint differentiation for gradients of scalar-valued functions, the technique used to compute sensitivities of a price to many market inputs in one pass. Instruments covers bonds, options and money types with their pricing. Stochastics generates Brownian motion in standard, arithmetic, fractional and geometric forms, plus short-rate models including CIR, OU, Vasicek and Hull-White. Time handles day counters, calendars, conventions and schedules. Data covers curves, term structures and surfaces, with readers and writers for CSV, JSON and Parquet, and a Yahoo Finance downloader. Math provides distributions with PDF, CDF and characteristic functions, FFT, double-exponential quadrature, gradient descent and Newton-Raphson root finding, plus sequence helpers like linspace and cumsum.
Two entries deserve scrutiny. The ml module is described as currently only linear and logistic regression plus k-nearest neighbours classification, which is a long way from a modelling toolkit and should be treated as a convenience rather than a reason to choose the crate. The trading module is described as currently only a basic limit order book. Both are honest labels, and both signal that these areas are early. The macros module contains two macros, plot_vector! and assert_approx_equal!, and nothing else. If you are evaluating RustQuant for machine learning or execution logic, the README itself is telling you the answer is no for now.
How the pieces fit together at runtime
The architecture visible from the module table is a layered one. Time sits underneath everything: day counters, calendars and schedules decide how a date range becomes a year fraction, and that year fraction is what a pricing formula consumes. Math sits beside it, supplying the distributions and numerical routines that pricing and model code call into. Data builds on top, holding curves, term structures and surfaces, and providing the IO layer that reads and writes them. Instruments and models consume curves and distributions to produce prices. Stochastics generates the paths that models and simulations need. Portfolio holds a HashMap of Position values, and trading holds the order book.
This is a conventional decomposition, and the practical consequence is that a pricing call is rarely a single function. You construct a day counter, build a schedule, discount cashflows along it, and the price emerges from those steps. That is the same shape as established quant libraries, and it means the learning curve is about assembling the pieces, not about learning an unusual abstraction.
The autodiff module is the one piece that does not fit the layering cleanly. It is a general numerical technique that happens to be most valuable for Greeks, and it sits at the same level as math rather than inside instruments. Whether pricing code in the repository actually uses it is not stated in the README.
Getting it running: examples, not a tutorial
The README gives one concrete command for exercising the library. The examples directory holds various uses of RustQuant, and you run them with cargo run --example followed by the example name. That is the documented path from a fresh clone to executing code. There is no quickstart snippet in the README showing a minimal pricing call, no Cargo.toml dependency line to copy, and no walkthrough of constructing a curve or a schedule. The module table links to docs.rs for each module, and the homepage is a separate site, so the README functions as an index rather than a guide.
For a Rust developer this is less of an obstacle than it sounds. Adding the crate and reading the generated documentation is a normal workflow, and the examples directory is where the intended usage patterns actually live. But it does mean the first hour is spent reading source and examples rather than following a tutorial, and if you are evaluating the library against a deadline, budget for that.
The README also does not document rollback, migration between major versions, or any deprecation policy. The CHANGELOG is the only place those questions are answered, and the README points to it in the contact table.
The disclaimer is the most important line in the README
RustQuant's README carries a note stating that it is currently a free-time project and not a professional financial software library, that nothing in it should be taken as financial advice, and that the author does not recommend using it for trading or making financial decisions. That is unusually direct, and it should be read as a technical statement rather than boilerplate. A library whose author declines to recommend it for trading is telling you that validation, edge cases and numerical accuracy have not been certified to the standard a trading system requires.
The concrete failure modes follow from that. Pricing code that has not been checked against a reference implementation across the full range of inputs can be wrong in ways that only appear for specific parameter combinations: deep out-of-the-money strikes, very short or very long maturities, negative rates, or unusual day-count conventions. A limit order book described as basic is unlikely to model queue position, iceberg orders or exchange-specific matching rules. The ml module's scope is narrow enough that it will not substitute for a dedicated crate.
This does not make RustQuant bad. It makes it a library you read before you trust, which is a reasonable position for a research or prototyping tool and an unacceptable one for a system that moves money.
Where RustQuant sits against QuantLib
The obvious comparison is QuantLib, and the repository's own topics list includes quantlib, so the author is aware of it. The difference in approach is not subtle. QuantLib is a long-established C++ library with bindings to several languages, a large contributor base and a documented methodology for pricing instruments, and it is the reference implementation that many desks validate against. RustQuant is a Rust-native library with a single primary author soliciting help.
The practical trade-off is integration cost against maturity. If you are writing Rust, QuantLib means C++ FFI, a build system you did not choose, and a boundary where types and error handling stop being idiomatic. RustQuant means one Cargo dependency and no foreign function layer. What you give up is the accumulated validation, the breadth of instrument coverage, and the certainty that someone has already hit the edge case you are about to hit. For a research prototype in a Rust codebase, that trade can be worth making. For a production valuation service, it usually is not, and the README's own disclaimer supports that reading.
Maintenance, releases and what the licence permits
The repository is not archived and the last push was on 2026-09-12, so the project is receiving commits. The most recent releases listed are RustQuant_utils-v0.4.0, RustQuant_time-v0.4.0 and RustQuant_stochastics-v0.4.0, all dated 2024-11-23. The gap between the 0.4.0 release tags and the current commit activity is worth noting: the workspace is split into separately versioned crates, so a tag on a sub-crate does not tell you the state of the top-level RustQuant crate on crates.io. If you depend on RustQuant, check which version you actually resolved and read the CHANGELOG for what changed after 0.4.0.
The version numbers matter for upgrade cost. Everything published so far is 0.x, which under Cargo's semver rules means a minor version bump can contain breaking changes. Pinning to an exact version and reading the changelog before each bump is the realistic policy. The workspace split into utils, time and stochastics crates suggests the project is moving toward finer-grained dependencies, which would reduce what you pull in, but the README describes the library as a single entity and does not explain the split.
On licensing, the README badge and repository metadata indicate dual MIT and Apache-2.0 terms, which is the standard permissive pairing for Rust crates and permits commercial use. This is not legal advice; if you redistribute the library or embed it in a product, read both licence texts in the repository and confirm the terms for the specific version you depend on.
Editorial conclusion
Adopt RustQuant if you are building a Rust pricing or simulation tool and want a single dependency that already covers day counters, calendars, distributions, Brownian motion variants, short-rate models and a basic limit order book, and if you are willing to read the source when the docs run out. Do not adopt it as the valuation or risk engine behind live trading decisions: the README states plainly that it is a free-time project, not professional financial software, and that the author does not recommend using it for trading or financial decisions. Before committing, check the docs.rs page for the specific module you need, confirm the crate version published on crates.io matches what you expect, and read the CHANGELOG for the breaking changes that landed after the 0.4.0 releases in November 2024.
Community notes