Ricequant Beta Version Release

Finally it comes.

The Beta version of Ricequant got delayed around 3 days. We hurried a lot at the final moment to publish the Beta version. We gave up Qing Ming festival and every night we always need to push some guy back home… Firstly I would like to thank all my team members who are like a whole family.

Screen Shot 2015-04-27 at 3.25.01 PM

And we sincerely thank our users who already registered and tried out Beta version. Thanks a lot for your valuable opinions so we could improve our product. Ricequant is still very rough, but we have a lot of features to be implemented. So that you could use more easily and develop and test your own strategy more quickly. And you could share and discuss your ideas with other users.

We already got some feedbacks, we’re improving some user experience like auto-complete the stock code, API code etc. And we’re adding more purified data into our platform.

This is just the starting point. We want to improve quantitative trading & research in China and maybe the whole APAC area. Maybe it’s still rough, but we are aiming for open, we’re happy to share our knowledge with you and we engineers are eager to build awesome tools for you. It’s a lot like web or internet – open and easy.

So I think this is the future of trading.

Again, welcome to Ricequant.

Ricequant Security Insider

Ricequant is a platform which allows users to execute their own strategies on the cloud. And those strategies are the core properties of each user. We put vast effort on protecting your key interests. Let’s take a not-so-brief look of what we did.

WHAT Is Security

‘Security’ in our dictionary has two meanings. First, safety of your privacy, including your code, your portfolio and your strategy’s behaviour (order, trades and etc.). Second, the uptime of the Ricequant platform. Losing the strategy means losing money, platform down also means losing money. So they are equally important.

WHY Do We Share

We chose to share these information because we want to convince you to trust us ‘over-protecting’ your properties. Moreover, we believe it is better for the community to find our flaws and give us feedback rather than letting the attackers to find them.

Our technology mostly comes from the open source community. We are full of thanks to those geniuses who created them.

HOW We Do It


Since the essential functionality of our platform is about executing user’s code on our servers. But this is usually the first step for an attacker: trying to get the permission to execute any code. This makes it very challenging for us to ensure security.

If we did not do anything, there is even no need to “hack”, we will be a self-hacked cloud based zombie provider, which is not so good. On October 2014, before the registration of Ricequant company, we already started putting efforts solving this problem.


We provide API for users to write their strategies on, but we do not want the users’ strategies to consume a lot of resources and to affect the normal execution of other users’ strategies. Apparently stopping one strategy to access others is a must.

A strategy can only do trading related logic, and nothing more. If we can make sure of this, problem solved. But we cannot control the shape of the strategy, we have to treat the strategy as a black box, and put a cage around it.

Our cage has three layers: 1)  make sure that in compile time, there is no more dependencies provided other than the API; 2) restrict what function the strategy can call from the JDK 3) place a safeguard that even the strategy breaks security level 1 and 2 with some unknown security holes in Java, there is still nothing it can do to break our defined security.

Compiling and Loading: Independent API and Multilevel ClassLoaders

To make sure the strategy code not to do anything more than allowed, most efficient way is we do not provide the tools for it to even think about it.

First step, when we compile the code, only API and JDK are provided as dependencies. Our API is just a bunch of Java interfaces, and it does not depends on anything else. By doing so, any static reference from the strategy code out of the dependency scope will be blocked while compiling.

Second step, during runtime, to prevent the strategy to harm the strategy executor (who loads the compiled strategy and execute it), we load the strategy and the executor in different Java ClassLoaders. So that unless there is a security breach in JVM, it is impossible for the strategy to load classes in or depended by the executor via reflection (like Class.forName(…)).

The second step also comes with a benefit: when we decide to support user-defined third party library, we do not need to worry about version conflicts (user wants to use log4j-2.0 but in our executor we load log4j-2.1, for instance). It is also how the famous plugin framework OSGI does it.

Restricting: Java Security Policy

Java Security Policy can control what a class can do in a very fine grain. For instance, we can block the code from accessing file system, executing system command, creating thread and etc..

Safeguard: Linux Container

With the first two layers of the cage, our system has basic protection. But we want to go further. We do not want to handle everything in Java. Thus this layer is added.

In the era of virtual computing, there has been plenty of tools to ensure the security of a virtual environment. For instance, Google App Engine can host users’ code written in various languages, in the mean time keeps its own safety and other user’s privacy. Quarantine of the virtual environment is the technology behind it.

We studied various quarantine technologies exist on Linux platform (recommend reading: Overview of Linux Kernel Security Features by Manager of Oracle Mainline Linux Kernel Team – James Morris). Based on lxc, we built a lightweight quarantine environment – the linux container. lxc is a lightweight virtual computing technology, it provides process-id-namespace (to hide the true process ids of the host system) and cgroup (to limit the resources the container can access). This allows us to write a few rules to limit strategies try to eat all CPU resources by a simple dead loop. More importantly, based on lxc, we can use chroot jail to provide isolation of file systems. The strategy can only see what it is allowed to see during runtime – of course another user’s strategy is not one of them.

It is still not enough.

Another tool we used  is seccomp, which limits what kind of system calls can a process invoke. This reduces the range of potential vulnerability. Iptables and tc are also used to limit the network bandwidth a strategy executor process can consume, to enhance the overall stability of our platform. We are planning to introduce SELinux in the phase 2 development cycle, to prepare for allowing self-defined third-party libraries.


We already did a lot of things to protect hacker from breaching our platform from the code execution mechanism. Still, we also did what other websites do to protect your properties. But they are out of the scope of this blog, and I believe there are already plenty of resources can be found on the Internet.

Except those technical protection we talked about above, we also have those not-so-technical protections. First, we do not store password anywhere in the network that an exposed server can access. We feed the passwords single-way from an internal server to the exposed servers (but not the other way round). Second, we log almost every movement that a strategy does, and examine them using robots. If we found anything abnormal, we block the account, shut down the server gracefully, and alert the team to do analysis.


Above we disclosed almost everything we did in ensuring security. Again, by full disclosure we want your trust, also your opinions. We crave for your advices.

Ricequant is coming.

Ricequant – a Quantitative Trading Platform

Ricequant will be a brand new quantitative trading system, inspired by another great platform quantopian.com. We are trying to make the quantitative trading tools dramatically simpler than what we have ever had, allowing a much greater population to start doing quantitative trading, with a low cost.

Ricequant will also be a community, just like our precursor, Quantopian. We will provide a place for quantitative traders to share, to learn and to discover. We will try our best to make the community resourceful and hence helpful.

Welcome to Ricequant.