# Signing Flow and MPC Overview **How Surf executes transactions securely without ever holding private keys** At the core of Surf’s security model is a strict separation between: Decision making\ Execution permission\ Cryptographic signing Surf never holds user private keys.\ Surf never has unilateral signing authority.\ Surf never becomes a custodian. Instead, transaction execution follows a controlled signing flow enforced through MPC and vault-scoped permissions. *** #### What is MPC? MPC stands for Multi-Party Computation. In simple terms, it means: * A private key is never stored in one place * It is split into multiple cryptographic shares * Surf uses a 3-of-5 threshold, meaning three out of five key shares must agree before any transaction can be signed. * No single system, server, or operator can sign alone * A valid signature only emerges when predefined parties and rules agree This is the same class of technology used by institutional custodians and prime brokers, but implemented in a non-custodial, on-chain compatible way. *** #### How Signing Works in Surf? **Step 1. User Creates a Vault** When a user creates a vault: * The vault becomes the on-chain owner of funds * The user wallet is registered as the ultimate authority * The Guardian Layer rules are bound to the vault * Execution permissions are scoped to approved execution contracts only No hot wallet custody.\ No shared signing keys.\ No central operator control. *** **Step 2. Surf Proposes an Action** Surf may propose actions such as: * Rebalancing between lending venues * Adjusting allocations * Moving liquidity * Closing or opening positions At this stage, nothing is signed. This is only a proposal. *** **Step 3. Guardian Layer Authorisation** Before any signing happens: * The proposed action is checked against deterministic rules * Protocol allowlists are verified * Exposure caps are enforced * Slippage and liquidity thresholds are validated * Circuit breaker conditions are evaluated If any invariant is violated: * The action is rejected * No signing process is triggered * No key material is engaged *** **Step 4. Vault-Scoped Signing via MPC** When an action is approved: * The vault triggers a signing request * The signing request is split across MPC nodes * Each node holds only a partial key share * The Guardian-approved execution payload is signed collaboratively * No node can reconstruct the private key * No node can sign arbitrary transactions The resulting signature is: * Valid only for that specific transaction * Bound to the vault * Bound to the execution path * Bound to the approved parameters *** **Step 5. Atomic On-Chain Execution** The signed transaction: * Executes as a single atomic operation * Cannot be partially completed * Cannot be altered post-signing * Cannot be rerouted to other destinations Funds move only: * Between allowlisted venues * Within the vault’s scope * Under the enforced rule set *** #### Why This Matters Most DeFi systems rely on one of two models: Hot wallet operators\ Or fully autonomous smart contracts controlled by upgrade keys Both introduce hidden trust assumptions. Surf’s model is different: * No single signing party * No operator discretion * No private key concentration * No backdoor execution path * No off-chain authority that can override rules MPC ensures: * Key material is never exposed * Execution cannot be hijacked * Compromise of one node is insufficient * Signing is bound to deterministic policy *** #### The Result For the user, this means: * You keep ownership of your vault * You keep ultimate withdrawal authority * Automation cannot sign outside its mandate * No one can move funds without rule compliance * No one can reconstruct your private keys * No silent upgrades or hidden execution paths This is how Surf operates at scale, while cryptography guarantees that control and custody never leave the user. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://surf-2.gitbook.io/surfliquid-docs/execution-security/signing-flow-and-mpc-overview.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.