Cuvex Sovereign Authorization
YOUR CUSTODIAN SHOULD NOT
BE YOUR FINAL AUTHORITY
Add an independent, offline, and physically separate authorization layer to the digital asset operations your organization cannot afford to execute incorrectly.
FIREBLOCKS-FIRST - VENDOR-NEUTRAL BY DESIGN - OFFLINE HUMAN VERIFICATION - CRYPTOGRAPHIC TRANSACTION BINDING
FIREBLOCKS-FIRST.
VENDOR-NEUTRAL BY DESIGN
OFFLINE HUMAN VERIFICATION
CRYPTOGRAPHIC TRANSACTION BINDING
No migration required
KEEP YOUR CUSTODIAN. KEEP YOUR MPC. KEEP YOUR WALLETS.
ADD AN INDEPENDENT AUTHORITY
No migration required
KEEP YOUR CUSTODIAN.
KEEP YOUR MPC.
KEEP YOUR WALLETS.
ADD AN INDEPENDENT AUTHORITY.
The structural problem
FOR YEARS, WE’VE PROTECTED THE KEYS.
Now we also need to protect authorization.
MPC, HSMs, RBAC, policy engines, multi-user approvals, allowlists, cold wallets, and SIEM can provide exceptionally strong protection for an infrastructure.
​
And yet one question remains: who has the final say over which operation should be executed?
~$1.5B
PROTECTED KEYS. LEGITIMATE SIGNERS. CATASTROPHIC AUTHORIZATION FAILURE.
February 2025 - BYBIT
The Bybit incident showed why protecting keys does not eliminate the risk of compromising the context in which humans authorize an operation.
​
Cuvex does not claim that it would have automatically prevented that specific incident.
​
The lesson is architectural: key security and authorization security are not the same problem.
A new security domain
CUSTODY PROTECTS EXECUTION.
CUVEX PROTECTS
AUTHORITY.
01
YOUR INFRASTRUCTURE PROPOSES
The operation originates in Fireblocks or the infrastructure you already use.
02
CUVEX RECONSTRUCTS INTENT
The Connector derives the actual parameters and normalizes them into a canonical representation.
03
CROSSES ANOTHER DOMAIN
The operation is transferred to the offline device.
04
THE HUMAN SEES THE REAL EFFECT
Asset, amount, network, destination, policy y quorum.
05
CUVEX AUTHORIZES
Independent cryptographic evidence is generated and bound to that operation.
06
THE CUSTODIAN PROCEEDS
Blockchain signing and execution remain under the existing custodian.
Transaction binding
ONE
OPERATION.
ONE
AUTHORIZATION.
AUTHORIZED
10,000,000 USDC
TREASURY A
→ 0xABCD...3912
HOST ATTEMPTS TO CHANGE
10,000,000 USDC
TREASURY A
→ 0xEVIL...9211
RESULT
AUTHORIZATION INVALID
NEW AUTHORIZATION REQUIRED
Human-verifiable authorization
WHAT YOU SEE IS WHAT YOU AUTHORIZE.
The approver does not authorize an abstract ID.
​
They authorize the actual economic and operational effect.
CRITICAL OPERATION
ASSET
USDC
AMOUNT 10,000,000
NETWORK
ETHEREUM
DESTINATION
0xABCD...3912
POLICY
TREASURY-V3
AUTHORIZATION
2 OF 3 REQUIRED
Enforcement
AN APPROVAL THAT CAN BE IGNORED IS NOT ENFORCEMENT.
Risk-based authorization
SECURITY WHERE IT MATTERS.
FRICTION ONLY WHERE IT IS JUSTIFIED.
01
HIGH-VALUE TRANSFER
02
NEW BENEFICIARY
03
POLICY CHANGE
04
CUSTODY CHANGE
05
COLD TREASURY
06
EMERGENCY / BREAK-GLASS
Policy
DEFINE WHEN CUVEX HAS THE FINAL SAY.
IF amount > 5M
REQUIRE CUVEX
IF recipient == NEW
REQUIRE CUVEX
IF operation == POLICY_CHANGE
REQUIRE 3 OF 5
IF operation == EMERGENCY
REQUIRE TREASURY + SECURITY
IF asset NOT IN ALLOWLIST
REJECT
Vendor-neutral by design
YOUR FINAL AUTHORITY SHOULD NOT BE TIED TO YOUR CUSTODIAN.
Vendor-neutral by design
YOUR FINAL AUTHORITY SHOULD NOT BE TIED TO YOUR CUSTODIAN.
The physical trust boundary
SOFTWARE CANNOT CREATE A PHYSICAL BOUNDARY
Cuvex BIT physically eliminates Bluetooth and NFC. Its operational communication uses USB-C.
​
The transport layer can be treated as untrusted. The device independently re-verifies the operation.
Architecture target
POST-QUANTUM AUTHORIZATION.
Cuvex authorization belongs to a cryptographic domain separate from blockchain signing.
​
The target architecture is designed around ML-DSA-65, subject to final validation of implementation, performance, and hardware hardening.
KEEP YOUR ASSETS WHERE THEY
ARE. CUVEX DOES NOT REQUIRE:
Custody the assets
Receive funds
Access the seed
Hold blockchain private keys
Control the wallets
Become part of the
MPC by default.
SUPPORT
No. It is designed to complement the existing infrastructure.
Not in this architecture.
Not in the initial model. It signs the independent institutional authorization.
No. The Connector handles normalization within Cuvex.
To ensure that critical authorization cannot be generated entirely within the same online domain.
We do not make that claim. The Bybit incident illustrates the class of risk that CSAL is designed to reduce:
legitimate signers authorizing a transaction within a compromised context.
The target architecture for Cuvex authorization uses ML-DSA-65. Production deployment is subject to final validation and security hardening.
No. It is designed for transactions selected based on risk.
Currently available through the Institutional Early Access / Design Partner PoC program.