Two engines read the same moment. Your policy turns their two scores into one direction. Several machines have to agree on it and the chain has to have the receipt, before your own computer places anything at all.
All of which is slower than one server deciding on its own, and more expensive to run. The record is only worth something if we could not have written it afterwards, and that is the entire reason for the arrangement.
From a signal to an order
Any of these four could be described by any trading product. What cannot be described away is which one comes before which.
The quant engine reads market structure. The sentiment engine reads social and news text in several languages and returns a score rather than a paragraph. That last part is not a stylistic choice: a number can be weighted against another number, and a paragraph cannot be weighted against anything.
How much each engine counts, which assets are in scope, and what risk profile applies are yours to set, not ours. The output is a direction with a confidence value and a breakdown showing which engine that confidence came from, so a call you disagree with can be traced to the part you would change.
The decision is computed by several independently owned machines that cannot see each other's answers. Anything that could trigger a trade needs two thirds of them to return the same result. Where there is no majority, nothing is written and nothing runs.
Asset, direction, confidence, model version, timestamp and a hash of what the engine was looking at go on-chain first. Your own machine, holding your own keys, places the order afterwards. Reversing those two steps would make the record worth nothing, which is why it is the design rather than the process.
Where our side stops
Your exchange keys are encrypted on your own computer. They are not uploaded, not escrowed, and not held by us in any form. Orders are placed by software running in front of you, against your own exchange account, using keys we have never had a copy of.
The reason to believe that is not that we said it. It is that the same arrangement has consequences we would obviously prefer to avoid. We cannot recover your keys if you lose them, because there is nothing on our side to recover them from. We cannot place a trade for you while your machine is off, because the part that holds the keys is the part that is off. Support cannot look at your positions to help you, because support cannot see them either.
Those are not caveats bolted onto a custodial product. They are the shape of a non-custodial one, and a product that claims your keys never leave your machine while also offering to recover them for you is claiming two things that cannot both be true.
scored both engines, on the same snapshot
fused your weights, your risk profile, your assets
-> a direction and a confidence
dispatched to several machines at once. how many depends
on what the mesh has spare, not on a fixed number
agreed two thirds of them for anything that can trade,
a simple majority for anything that cannot
no majority -> nothing is written, nothing runs
written asset, direction, confidence and its breakdown,
model version, timestamp, a hash of the inputs,
and how many machines agreed out of how many
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
above this line: ours, and public
below it: yours, and private
executed your machine, your keys, your exchange accountThe count of how many machines agreed is written into the receipt alongside the decision. That means the verification depth of any individual call is checkable afterwards rather than assumed, which matters because the number of machines a job goes to depends on what the network had available at the time.