Saleem, I think you're asking two different questions, and they're both good ones. The first question is "is this worth it?" The second one is "can I trust Quantopian?"
For the first one, I'm going to re-use an answer I gave last month.
A developer's royalty payments depends on three factors: 1) the size of their allocation 2) the performance of their algorithm and 3) the fraction of the net profit that the developer receives. Today, our allocations are on the smaller side, probably too small for Quantopian to replace what most developers can earn at a full time job.
Our goal is to increase the size of the allocations we make significantly in 2017. I'm sure you heard about our agreement with Steve Cohen. We hope that he is the first of what will be many investors whose money we can allocate. This investor money is what makes larger allocations possible.
I'll give you a completely hypothetical, back-of-the-envelope example answer. Please understand that this is for illustration purposes only and the actual details of any future allocation are sure to vary. The details of the calculation of net profit and the payment schedule are not covered in this simple example.
- allocation: $3 million, levered 6X to $18 million trading allocation
- algorithm net profit: $1.44 million return in one year (8% return)
- author's share of net profit: 10%
- author's royalty payment: $144,000
The second question, about trust, is another good one. I wrote a few paragraphs about it in August.
We are committed as a company to protect your intellectual property and to keep it private. We do not look at your code except for specific, rare exceptions that are explained in our terms of use. The exceptions include when a community member's algorithm is believed to be threatening our site security or we need to comply with any legal or regulatory requirements. Also, of course, sometimes members explicitly grant us permission to look at their code for technical support or other reasons.
Your code is on our servers. That's a necessary and important part of how Quantopian works. We provide clean data sources, computing power, code execution, broker integration, education, support, and more. Quantopian does all of these things without looking at your code. That's all possible because of the way our platform is implemented.
For this all to work, it requires trust. We've known from the very beginning that trust is vital. If we were to lose the trust of our community, our business would fail. We work to earn your trust every day. We commit to be transparent and open in how we do business. We are open about who we are (Find us on LinkedIn! See who we know in common) and about what we do.
For long-term community members, that will all sound familiar. And Pravin asked a different question that I'd like to answer. "What controls are in place at Quantopian so that a random employee cannot access our code?" I interpret that question to be about what internal controls we have in Quantopian for our internal employees. The controls are multi-layered, as most security systems are. Here are some of the relevant ones:
- All code (algorithms, backtests, notebooks, etc.) is stored in encrypted form. Access to the decryption key is very carefully
controlled and limited to a few key Quantpian employees. The key is
periodically rotated.
- The access to the databases/datastores of the encrypted code is carefully controlled and limited to a few key Quantpian employees.
Credentials are periodically rotated.
- Access to production servers is obviously controlled in similar ways.
- We hire a third party to do background checks on all new Quantopian hires.
- We hire a third party security firm to evaluate and test our security.
- We have a method for support people to see a community member's code when the community member permits it. That ability is restricted to people giving support (like Jamie and me). When that power is exercised it is logged and periodically double-checked.
We regularly evaluate and improve these protocols.
(In that post I also mentioned a forthcoming improvement to how we manage support requests. We rolled that out already, but I haven't done a formal announcement. I'll announce it early in December).
Let me know if there are follow-up questions.