💻 computer science

PACE: Policy-Bound Multi-Party Authorization with State-Consistent Execution for Smart Contracts

This paper introduces PACE, a framework for smart contracts that ensures state-consistent multi-party authorization by binding collective decisions to active policies and execution contexts through a two-round lattice-based signature scheme, thereby guaranteeing consistency across policy, decision, request, and execution while maintaining stable verification costs.

Original authors: Yaowei Sun, Cong Wang, Maode Ma, Zhilu Zhang, Yanan Zhang, Guangquan Xu

Published 2026-10-12

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Yaowei Sun, Cong Wang, Maode Ma, Zhilu Zhang, Yanan Zhang, Guangquan Xu

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

In the digital world of smart contracts, code acts as the law, automatically executing agreements when certain conditions are met. These programs often manage valuable assets or sensitive permissions, requiring strict rules about who can do what. Traditionally, a single person or a simple password might grant access, but for high-stakes decisions involving multiple organizations, a single point of approval is often too risky. Instead, a group of trusted parties must agree together before an action can happen. This is known as multi-party authorization. However, a significant gap exists between the moment a group agrees to a request and the moment the contract actually executes it. Between these two moments, the rules might change, the request might be altered, or the permission might be used twice. If the system does not tightly lock the agreement to the specific action and the current rules, a valid signature from a group could be misused to authorize something they never intended, or to execute a transaction after the rules have already changed.

Researchers have developed a new framework called PACE to solve this problem of loose connections in digital authorization. The team, led by Yaowei Sun and colleagues, created a system that ensures the permission granted by a group of authorities remains perfectly tied to the specific request, the current set of rules, and the exact moment of execution. Imagine a group of bank managers signing a check; with PACE, the signature is not just a mark of approval, but a digital seal that locks the signature to the exact amount, the specific bank branch, and the current date, preventing anyone from changing the details or using the signature on a different day. The researchers built a prototype to test this idea, simulating a scenario where multiple authorities must agree before a smart contract performs a protected operation. Their work demonstrates that by binding the approval to a specific policy version and a unique session, they can prevent unauthorized actions even if the rules change or if a malicious actor tries to reuse an old permission.

The core of the PACE system is a three-step process that links the people, the rules, and the action into a single, unbreakable chain. First, the system establishes a policy-bound configuration. This means that before any group can give permission, the system records exactly which rules are active and which specific people are authorized to sign. If the rules change later, the system moves to a new "epoch," or version, and old signatures from the previous version become invalid. This prevents a group from using an old agreement to bypass new restrictions. Second, the authorities engage in a context-bound joint authorization. When a request comes in, every authorized person reviews the exact details of the request—the specific contract to be called, the data to be sent, and the time limit. They then work together to generate a single piece of cryptographic evidence. This evidence is not just a collection of individual signatures; it is a unified proof that the entire group agreed to this specific set of details at this specific time. The system uses advanced mathematical techniques based on lattice structures, which are designed to be secure even against future quantum computers, to create this joint proof.

Finally, the system performs a state-consistent execution. When the request arrives at the smart contract, the contract does not just check if the signature looks valid. It performs a series of strict checks to ensure everything matches. It verifies that the rules active at the moment of execution are the same as the rules the group agreed to. It checks that the request being executed is identical to the one the group reviewed. It confirms that the permission has not expired and has not been used before. Crucially, the system ties the consumption of the permission to the execution of the action in a single, atomic step. This means that if the action fails for any reason, the permission is not used up, and if the permission is used, the action must succeed. There is no gap where a permission could be spent without a corresponding result, or where a result could occur without the permission being properly spent.

To test how well this system works, the researchers built a simulation using a standard computer processor and a specific set of mathematical parameters designed to handle up to thirty-two different authorities. They ran thousands of tests to see how the system behaved under different conditions, such as changing the number of people in the group or the size of the data being processed. The results showed that the system successfully enforced all the intended rules. When the researchers tried to trick the system by submitting an old permission, changing the request details, or trying to use a permission twice, the system correctly rejected the attempt. The tests confirmed that the checks for policy consistency, request binding, and authorization state worked as designed. In scenarios where the target action failed, the system correctly rolled back the entire process, ensuring that no partial state changes were left behind.

The study also measured the cost of running this system in terms of time and data. The most time-consuming part of the process was the collaborative signing and the aggregation of the evidence, which took the majority of the computing time. As the number of authorities increased, the time required to generate the joint evidence grew, but the time required for the contract to verify the final result remained relatively stable. For example, with thirty-two authorities, the process of generating the joint evidence took about eight seconds, while the verification on the contract side took less than a second. The amount of data that needed to be exchanged between the authorities also grew with the number of participants, reaching over one hundred megabytes for a group of thirty-two, but the final piece of evidence submitted to the contract remained small and fixed in size. This suggests that while the system requires significant coordination among the group, the burden on the final execution step is manageable.

The researchers also explored how the system handles the mathematical "rejection sampling" process, which is a method used to ensure the security of the signatures by occasionally discarding attempts that do not meet strict statistical criteria. They found that by allowing a few retries, the system could successfully complete the authorization process with a very high probability. Even with a large group of authorities, the system was able to complete the task successfully in nearly all cases when given a reasonable number of attempts. This indicates that the system is robust enough to handle the occasional mathematical hiccup without failing to deliver a valid authorization. The study concludes that PACE provides a solid foundation for secure, multi-party control over smart contracts, effectively closing the gap between approval and execution. While the current version assumes a trusted setup and a specific type of group agreement, the results show that the core idea of binding policy, request, and state together is a viable path toward more secure digital governance.

Technical Summary: PACE – Policy-Bound Multi-Party Authorization with State-Consistent Execution for Smart Contracts

1. Problem Statement

Smart contracts governing sensitive operations (e.g., asset transfers, permission changes) often require multi-party authorization. However, existing mechanisms frequently treat policy updates, request binding, and authorization lifecycle management as separate concerns. This separation creates a critical gap in end-to-end authorization consistency.

Specifically, the paper identifies four research challenges (RQs) arising from the separation of off-chain approval and on-chain execution:

Policy–Decision Consistency (RQ1): How to ensure that a joint approval remains valid if the active policy or authority configuration changes (e.g., an update to the required signers) before execution.
Decision–Request Binding (RQ2): How to guarantee that the request submitted to the contract is identical to the one approved by the authorities, preventing a malicious requester from altering call parameters or the target contract.
Authorization Lifecycle Management (RQ3): How to prevent the reuse of expired, consumed, or invalid authorizations at execution time.
Authorization–Execution Consistency (RQ4): How to atomically couple the consumption of an authorization with the execution of the protected operation, ensuring that a failed operation does not leave the authorization "spent" or a successful operation proceed without consumption.

Existing solutions like SMACS (token-based) or X-LOCK (decentralized attribute-based) address subsets of these issues but fail to integrate joint approval of a specific invocation with all four consistency requirements within a single lifecycle.

2. Methodology: The PACE Framework

The authors propose PACE, a framework that binds multi-party authorization to a specific policy instance and enforces state consistency through a unified workflow.

2.1 System Model and Workflow

The system involves a Policy Owner (PO), a set of $n$ Authorities ( $A$ ), a Requester ( $U$ ), and a Smart Contract (SC) acting as an execution gateway.

Configuration Establishment: The PO defines a policy $P$ and registers authority public keys. An atomic activation process creates an epoch-specific configuration linking the policy to the current set of verification keys.
Context-Bound Joint Authorization: The requester submits a request off-chain. Authorities review a canonical execution context ( $\mu_{SC}$ $μ_{S C}$ ) which includes the domain, policy version, target contract, operation, call data, session ID, nonce, and deadline.
- Authorities use a lattice-based two-round multi-signature scheme (DualMS) to generate joint evidence.
- The scheme operates in an $n$ -out-of- $n$ mode, requiring all designated authorities to approve and participate.
State-Consistent Execution: The requester submits the request and the joint signature to the SC. The gateway performs:
- Policy Validation: Verifies the signature against the current active policy configuration, not the one used during signing.
- Context Matching: Ensures the submitted request matches the signed context exactly.
- State Checks: Verifies freshness (nonce, deadline) and checks if the session ID has been used.
- Atomic Execution: If all checks pass, the contract atomically marks the session as used and executes the protected operation. If the operation fails, the transaction reverts, including the consumption record.

2.2 Cryptographic Foundation

PACE utilizes DualMS, a two-round lattice-based multi-signature construction (Chen 2023). This choice supports post-quantum security objectives. The protocol relies on:

Canonical Encoding: All context fields are encoded and hashed to form the message $m$ .
Rejection Sampling: Used during the signing process to prevent secret key leakage, requiring retries if samples fall outside specific norm bounds.
Target-Public-Key Security Model: Security analysis assumes an uncorrupted target authority ( $A_1$ ) within the configuration, while adversaries may control other authorities.

3. Key Contributions

The paper makes three primary contributions:

Formalization of Consistency: The authors formally define and analyze three security properties under a target-public-key experiment:
- Policy–Decision Consistency: Ensures execution only occurs if the active policy matches the one governing the approval.
- Decision–Request Binding: Ensures the executed request matches the signed context.
- Authorization–Execution Consistency: Ensures the state transition (consumption) is inextricably linked to the successful execution of the specific operation.
- The analysis demonstrates that unauthorized execution implies either a forgery of the joint signature (breaking DualMS UF-CMA security) or a collision in the context hash function.
Construction of PACE: The framework integrates the cryptographic interface with smart contract semantics. It introduces a mechanism where the gateway retrieves the verification key from the current contract state, preventing the use of signatures generated under obsolete configurations. It enforces atomicity by coupling the "Used" state update with the protected call.
Prototype Evaluation: A Python/SageMath prototype was implemented to evaluate the system.
- Consistency Checks: The prototype verified that stale policies, modified requests, and replayed sessions are correctly rejected.
- Semantic Ablations: Removing specific checks (e.g., policy matching or single-use checks) in the prototype led to the expected security failures, validating the necessity of each component.
- Performance: The system was evaluated against varying numbers of authorities ( $n=4$ to $32$) and call data lengths.

4. Results

The prototype evaluation yielded the following findings:

Computational Cost:
- Dominant Factor: Collaborative signing (generation and aggregation) accounts for the majority of the computational cost. As the number of authorities ( $n$ ) increases, aggregation time scales significantly (from ~1.09s at $n=4$ to ~8.10s at $n=32$ ).
- Stable Verification: Contract-side verification time remains relatively stable (~0.71–0.73s) regardless of $n$ , as it verifies a single aggregated signature rather than individual messages.
- Context Impact: Increasing call data length (up to 12,800 bits) had a negligible impact on cryptographic computation times, as the lattice dimensions remain fixed and the context is hashed to a fixed-length message.
- Overhead: The incremental overhead of the PACE framework over the core DualMS cryptographic operations is small (e.g., ~0.18s at $n=32$ ), indicating that policy and state checks are computationally efficient relative to the lattice operations.
Communication and Storage:
- Communication: Total communication grows linearly with the number of authorities due to the coordination traffic (collecting commitments and responses), ranging from ~30 MiB ( $n=8$ ) to ~110 MiB ( $n=32$ ). The aggregated signature size remains constant.
- Storage: Configuration storage (authority state and authorization state) grows linearly with $n$ , reaching approximately 1.07 MB for $n=32$ .
Retry Behavior:
- The rejection sampling mechanism requires retries to prevent secret leakage. With a retry budget ( $R$ ) of 6 to 8, the success probability for the full cryptographic core exceeds 0.80, stabilizing near 0.90 at $R=10$ .

5. Significance and Claims

The paper claims that PACE addresses the fragmented handling of authorization in existing smart contract systems by providing a unified lifecycle that ensures end-to-end consistency.

Integration: Unlike previous works that handle policy, binding, or lifecycle separately, PACE integrates joint approval of a specific invocation with active policy checking and atomic state transitions.
Security: The framework provides formal guarantees that unauthorized execution is computationally infeasible under the stated assumptions (DualMS security and collision resistance), specifically preventing execution under obsolete policies or with altered requests.
Post-Quantum Readiness: By utilizing lattice-based cryptography, the framework is designed with post-quantum security in mind, though the formal proof remains in the classical random oracle model.

The authors maintain a modest stance, noting that the current implementation assumes an $n$ -out-of- $n$ model, trusted configuration management, and atomic execution semantics. They explicitly state that the prototype was simulated and does not measure blockchain-specific latency or gas costs, identifying these as areas for future work.