Define the rule
Agree which breach matters: daily loss, trailing drawdown, target state or another explicit condition.
Start with your current risk process.
The most useful first conversation is usually not “replace our stack.” It is “measure what happens today, identify the gap, then decide what to change.”
Pilot enquiry
Tell us what you want to measure.
Use the form for a read-only pilot, technical benchmark review, integration discussion or product question. The form opens your email client with the details prefilled—no browser-side submission service or tracking script is used.
Public technical evidencegithub.com/tkariwo/prop-rails-okx-benchmark
Suggested pilot scopeTwo weeks · one observed account · read-only API key · agreed rule conditions · a written report of your measured response time. Fixed fee, quoted per firm — ask and you will get a number in the first reply.
Data handlingWhat you send here reaches one mailbox and is used only to answer you. Nothing is passed to a third party. Privacy note.
A useful first pilot
Keep the scope narrow enough to produce a decision.
A focused account and a known rule set make the output easier to interpret than a broad, undefined “risk system test.”
Observe the account
Connect with the minimum read permissions required for the selected venue.
Collect events
Record the breach instant, your existing system response and the exchange-confirmed resulting state.
Review evidence
Use the resulting distribution and failure cases to decide whether architecture changes are justified.