Common Objections

what stops an insider from moving funds? keys are never exposed in plaintext policy checks run in a secure enclave approvals require possession of registered device keys mpc makes sure no single machine ever holds a full signing key every step is logged primevault cannot bypass your policy or sign on its own how do we know a malicious update will not change behavior? upgrades can require your co approval secure instances verify the exact code hash before unlocking anything builds are reproducible with published checksums you can pin to an approved measurement canary and rollback procedures are standard if the ui is compromised, could it trick us into signing the wrong thing? we design assuming the ui can lie and layer controls, so a compromised ui doesn’t lead to a bad signature intent must match the enclave payload even if the ui is spoofed, the enclave compares the approved intent to the raw transaction it compiles if the destination, amount, or calldata don’t match or the address isn’t on the allow list/whitelisted addresses, the request fails , and no signature is produced separate approval channel approvals happen only on registered phones the device shows an enclave verified summary (to address, asset, amount, decoded function) even if the web ui is compromised, the phone displays the actual payload coming from the enclave, not whatever the browser claims in production, sends to non approved/non whitelisted addresses are disabled new payees require a policy change (with an admin quorum) rather than a one off approval bottom line a spoofed screen might trick a user into requesting the wrong thing, but it can’t make the enclave sign it, and it can’t bypass allow lists for sensitive flows, require allow listed recipients only, distinct quorums for rule changes, and out of band verification when something looks unusual