A List Is Not A Decision
Most people join a private beta the way they subscribe to a newsletter: the page was interesting, the form was short, and the cost of saying yes looked like nothing. Then the invitation arrives three weeks later, the workspace opens on a Tuesday evening, and there is no particular question waiting to be answered. The software gets a tour rather than a trial, and the evaluation quietly becomes an impression.
That is a waste of the only thing an early user really spends, which is attention. CVEST is software for portfolio visibility and rule-based, defined-risk options execution. It does several distinct jobs, and it does them at different stages of completeness. The useful preparation is not research into the product. It is deciding, in one sentence, which of those jobs you want to put under load.
This article describes what the intake actually does, what it deliberately does not do, and how to pick the workflow that will make your invitation worth opening.
What The Form Records
The private-beta form takes a name, an email address and an explicit consent checkbox. The schema is strict, which in practice means a request carrying any field the form does not define is rejected rather than quietly stored. The email is trimmed and lowercased before it is validated, so the same address submitted twice with different capitalisation is treated as the same address.
Alongside those three values, the server records the moment the request arrived, the version identifier of the consent text you agreed to, and a snapshot of the prices that were displayed to you at the time. The consent version matters because the wording of what you agreed to can change later; storing the identifier means the agreement can be read back as it stood, rather than as it reads today.
There is a fourth field on the form that you will never see. It is a hidden input, and a submission that fills it in is treated as automated: the request returns the ordinary receipt and nothing is written. Two rate limits sit in front of the same handler, one keyed to the email address and one global, so a single address cannot be used to flood the list and the list as a whole has a ceiling per window.
A duplicate request does not create a second row and does not overwrite the first. The insert is written to do nothing on conflict, which means the details captured the first time survive, and you receive the same receipt either way. Submitting twice because you were not sure the first one worked costs you nothing and changes nothing.
What It Does Not Create
This is the part worth being precise about, because intake forms in this category frequently do more than they appear to. A CVEST private-beta request creates no user account. It creates no session and no workspace. It creates no subscription, takes no payment details, and confers no access entitlement of any kind. It does not reserve a price.
No exchange credentials are collected at this step either, and none should be offered. The form has nowhere to put an API key, because the request is not a connection and the row it writes has no relationship to any trading account.
A request is a row on a list with your consent attached to it. Everything else — identity, workspace, connection, price — happens after an invitation, or not at all.
Name The Job, Not The Product
Write one sentence before you apply, in this shape: when this happens, I need to see this, so that I can decide this. The sentence is doing real work. It forces you to name a moment that already occurs in your own routine, which is the only reliable way to find out whether a piece of software belongs in it.
A sentence that ends in wanting to try the platform has not been written yet. Neither has one that describes a capability rather than a moment. Compare: I want to see my whole portfolio in one place, against, on Sunday evening I reconcile four accounts by hand and I cannot tell which figures are stale. The second sentence can be tested in an hour. The first cannot be tested at all.
Once the sentence exists, the workflow it belongs to is usually obvious, and so is the evidence that would settle the question.
Four Workflows You Can Put Under Load
The table below is a reading aid for matching your sentence to a workflow, not a scoring model and not a feature comparison. Read down the middle column and find the row whose evidence would actually change your mind about something.
| Workflow | The evidence it produces | What it cannot tell you |
|---|---|---|
| Portfolio visibility | Each holding beside its venue, account, native currency and the time its source was last observed | Whether a position is a good one to hold |
| Decision context | The structure, the inputs and the limits behind a candidate comparison, opened before anything is submitted | Whether a ranked structure will be profitable |
| Execution records | What was intended, what was submitted, what the venue returned, and the rule behind an exit decision | What would have happened under a different rule |
| Practice | The shape of the workflow, walked end to end with simulated fills | The fill you would have received in a real book |
Most people who get value from an early product are testing one of these, not all four. Choosing one is not a limitation on your evaluation; it is what makes the evaluation legible when the invitation arrives.
What You Cannot Evaluate Yet
Saying this plainly is more useful than a feature list. Automated execution is paused. The live-execution flag defaults to off, and turning it on is an explicit operational act tied to an exact account, not a setting a new workspace arrives with. If your sentence depends on watching CVEST place real orders, the private beta will not answer it on the day you open it.
Venue coverage is uneven by design, and the unevenness is deliberate rather than provisional. The OKX connection supports account monitoring and the defined-risk ETH options loop. IBKR monitoring and cash-funded USD tickets require a local gateway with an interactive login, and IBKR positions are managed by hand. Deribit is read-only and exists for comparison, not order submission. TradingView is a full-history file import, not a live account connection.
There is no automatic routing between venues. A comparison that spans two connections is a comparison, and it stays one. If your sentence assumes an order will find the better of two books on its own, that assumption is not implemented and should not be carried into the evaluation.
First Steps
- Write the sentence: when this happens, I need to see this, so that I can decide this. Keep it to one line and name a moment that already occurs in your week.
- Match it to one of the four workflows above, and write down the single piece of evidence that would settle the question either way.
- Join the list with that sentence saved somewhere you will find it again, and open the invitation with it in front of you.
Apply For A Question, Not For Access
An invitation confirms which features, connections and terms are available to you before any paid activation. It is the point at which the general description on a marketing page becomes a specific answer about your account. That conversation is far more useful when you arrive with a question that has a shape.
Joining the list costs a name, an email address and a consent tick. It reserves neither access nor pricing, and it can be reversed by asking for removal. The part worth preparing is not the form. It is the sentence you will test when the workspace opens.
Read the risk information and check the current product scope before evaluating a workflow.