TIP: TRON Multisignature Execution Protocol
Abstract
This TIP defines a standardized multisignature execution protocol for TRON smart accounts, enabling secure transaction approval by multiple owners. Instead of requiring each signer to submit an on-chain approval, authorized signers provide off-chain signatures that are bundled and submitted once via a single execTransaction(...) call. Signature validation supports both externally owned accounts (via ECDSA) and contract-based signers (via isValidSignature). A Merkle root of collected approvals MUST be generated off-chain for audit and governance tracking, but is NOT checked on-chain. Optional RPC interfaces may assist with signature collection but are not part of the authorization path. This approach reduces transaction overhead and provides a deterministic, contract-enforced consensus mechanism for DAOs, treasuries, and other controlled smart accounts.
Motivation
TRON lacks a standardized interface for contract-based multisignature wallets. As a result, developers often rely on custom implementations or fall back on the protocol-level account-permission system, which operates independently of smart contracts. A smart contract wallet model allows ownership and approval logic to be fully defined in code, enabling flexible multisignature schemes (e.g., M-of-N) without depending on native TRON permissions.
This proposal defines a consistent execution model in which a transaction must receive approvals from a quorum of designated owners before it can be executed. Each approval may come from an externally owned account (via a cryptographic signature) or from a contract-based owner (via a standardized on-chain validation interface). Enforcing the ERC‑1271 isValidSignature(bytes32,bytes) check for contract owners ensures compatibility with dApps and protocols that verify signatures across different account types.
To improve transparency and support auditability in governance scenarios, all off-chain approvals are aggregated into a Merkle root, which can be published for external verification. In this version, however, no Merkle roots or proofs are processed or stored on-chain—off-chain coordination tools are expected to manage them. This separation ensures on-chain logic remains minimal, while preserving a clear and verifiable audit trail for multisignature authorization flows.
Specification
The traditional access rights scheme in TRON supports “multi-signature”: each level of rights (owner, witness, active) is associated with a set of keys (addresses) with specified weights. This means that a transaction can be signed by multiple private keys: a sufficient sum of their weights must satisfy a threshold. To extend this model with contract signatures, it is necessary to implement the EIP-1271 standard – signature verification via a smart contract. In particular, the contract must provide the function isValidSignature(bytes32 hash, bytes signature), which, if the signature is valid, returns the magic value 0x1626ba7e . In this case, the network considers such a contract response as equivalent to a real signature.
Multisig Contract
The design of the multisig contract itself should be based on a flexible architecture with the following features:
- EIP-1271 Interface: implement the function
function isValidSignature(bytes32 hash, bytes memory signature) external view returns (bytes4 magicValue)
which returns 0x1626ba7e for valid signatures. This method and the working hash (transaction hash) in the chain are called during the rights check (see above).
- Owners and threshold: the contract stores a list of owners (EOA addresses or even other contracts) and the minimum number (or total weight) of signatures required to perform the operation. It is necessary to provide the ability to dynamically add/remove owners and change the threshold in the future to make the solution flexible and extensible. Such settings can be updated through separate contract functions with appropriate protection.
- Signature aggregation: the contract should accept as input a single aggregated signature (for example, a concatenation of ECDSA signatures of multiple owners) or a structure from an array of signatures. Inside
isValidSignature, each signature is parsed and verified: signatory addresses are restored from_signature, checked against the list of owners, and the number of valid signatures is counted. If it reaches the threshold, the method returns a success code. Example of verification:
// pseudocode for illustration
(address[] signers, bytes[] sigs) = parseSignatureBundle(signature);
uint count = 0;
for (uint i = 0; i < signers.length; i++) {
if (owners[signers[i]] && verifyECDSA(hash, sigs[i], signers[i])) {
count++;
}
}
return (count >= threshold) ? 0x1626ba7e : 0xffffffff;
This approach is consistent with the multisig wallet example in EIP-1271
- Security and Extensibility: The contract should keep a log of events (adding an owner, changing the threshold, executing a transaction, etc.) and have mechanisms to protect against repeated execution of transactions. Additional roles can also be provided (for example, an admin who can urgently change the owner if the keys are lost). All internal operations should be carefully documented, and the encoding of aggregated signatures should be explicit (for example, ABI encoding or a proprietary format).
Although the proposed multisig contract protocol is designed with a focus on systemic applications (e.g., consensus approval of decisions on behalf of a DAO/SRs), its architecture is completely universal and can be used by any user, organization, or team to autonomously manage assets or processes. Thanks to the standard
isValidSignature(bytes32, bytes)interface, this smart account can act as a full-fledged signer in any context - from allowing token transfers to participating in voting, executing meta-transactions, or confirming off-chain orders. Thus, the protocol can function not only as part of a DAO solution with a quorum of SRs, but also as a separate secure multisig wallet or DAO module that uses a collective signature to authorize important actions in any private or corporate context.
Flexible Multisig Interfaces and Authorization Layers
To support both decentralized governance and general-purpose multisig wallets (e.g. organizational accounts, secure user custody), implementations SHOULD offer a flexible interface that separates roles and policies without rigidly defining method names or structures.
At its core, the contract MUST expose the canonical isValidSignature(bytes32 hash, bytes signature) interface, enabling off-chain approvals to be verified on-chain according to arbitrary quorum logic. Building on this primitive, developers MAY define higher-level methods, modifiers, or policies to suit their specific context.
For example, a system-oriented multisig MAY expose functions such as:
function approveAction(bytes32 actionHash, bytes calldata approvalSignature) external
This function allows recognized members (e.g. Super Representatives or delegates) to submit individual approvals for an action hash. While these approvals do not directly affect execution authorization (which still depends on isValidSignature), they can emit events, populate off-chain dashboards, or serve as intermediate coordination steps before quorum is reached.
Execution itself might be triggered through a function such as:
function execute(bytes calldata callData, bytes calldata aggregatedSignatures) external
Here, the contract extracts the intent from callData, computes the transaction hash, and checks whether the provided signatures (EOA or contract-based) satisfy the threshold via internal validation. Execution proceeds only if quorum is met.
To enforce different rules depending on the type of operation or caller, the contract MAY define modifiers such as:
modifier onlyCouncilApproval(bytes32 txHash, bytes calldata signatures)
modifier onlyUserApproval(bytes32 txHash, bytes calldata signatures)
These allow a single contract to apply different approval thresholds or signer sets depending on the context. For instance, council-gated actions like withdrawToRecoveryPool() may require onlyCouncilApproval, while private wallet actions like transferTokens() might rely on onlyUserApproval. Internally, these modifiers call isValidSignature with the relevant hash and signatures, and may validate the origin or role of the caller.
To route calls through the appropriate logic, implementations MAY define a policy registry:
enum ApprovalMode { USER, COUNCIL }
mapping(bytes4 => ApprovalMode) public approvalPolicy;
function setApprovalPolicy(bytes4 selector, ApprovalMode mode) external onlyAdmin {
approvalPolicy[selector] = mode;
}
This mapping enables the contract to dynamically associate different methods with different approval strategies. The same multisig instance can therefore handle both collective governance and private use cases, adapting its behavior based on which function is being invoked.
approveAction,execute,onlyCouncilApproval), implementations MAY define their own naming conventions, data encodings, or permission layers. As long as all flows ultimately validate intent throughisValidSignature(...)and enforce quorum through contract logic, the architecture remains compliant and interoperable.
Consensus Level Changes
- Support for aggregated signatures: TRON nodes should accept a combined multi-signature (from EOA accounts or contracts) and consider it valid if the value
0x1626ba7e(according to the EIP-1271 standard) is returned whencontract.isValidSignature(hash, sig)is called. This way, smart contracts with their own validation logic (for example, a DAO or multi-sig wallet) will be able to sign transactions. - Extension of
checkPermission()in Java-Tron: when processing transactions, add a check for the account owner’s rights. If the owner is specified in the permissions as a smart contract, instead of the usual ECDSA signature check, call this contractisValidSignature. Otherwise (as usual) check the set of key signatures. This will allow “contract owners” to work side by side with EOA keys in one account. - New access type (e.g.
contractWeight): introduce a separate mode where the permission threshold is not taken into account by the weight of addresses, but by the result of executing theisValidSignatureof the contract. That is, instead of summing the weights of certain keys, the network will consider the permission received if the contract returned a successful code. This can be implemented as a special permissionType, where the threshold is triggered by the “success” of the contract check. - System triggers via board decisions (DAO approval): add special checks for critical system methods. For example, the
reward.withdrawTo(address recipient)operation can only be allowed if it has been approved by a quorum of Super Representatives via DAO multisig. The idea is that before executing such a call, the contract checks whether a sufficient number of SRs have signed it (viaisValidSignatureon the DAO contract). A similar approach is already used in TRON for on-chain proposals: SRs can change network parameters (e.g., commission sizes) by voting on proposals. By analogy, one can introduce a proposal or a separate system contract that requires SR signatures to perform specific actions.
Examples of System Triggers
To implement SR approval, a separate DAO multisig contract can be used, which has a list of current SRs and a quorum built in. Before performing sensitive functions, the system will access this contract via isValidSignature to verify approval. Following the example of EIP-1271 and DAO logic, the signature can encode the proposal number or the SR signature package, and the contract should verify that the vote passed with a quorum. This solution is consistent with the existing Tron model: SRs can already make changes to the network via on-chain proposals, and in a similar way, reward.withdrawTo requests or other critical calls can be configured via council approval.
Thus, the designed multisig system in TRON consists of two components: updates at the consensus level (to accept aggregated signatures and new verification mechanisms) and the multisig contract itself, which implements the verification logic according to EIP-1271 and the internal threshold. This approach balances reliability (the contract follows its own rules) and flexibility (a unified isValidSignature interface), ensuring seamless integration of contract multisigs into the network infrastructure.
Benefits and Impact
This proposal introduces a unified, contract-based multisig authorization protocol for TRON that brings security, governance flexibility, and long-term ecosystem alignment. By standardizing the isValidSignature(bytes32, bytes) interface and integrating it into full-node consensus logic (e.g., checkPermission()), TRON smart accounts can act as first-class actors with programmable approval logic - from simple wallets to DAO-controlled treasuries.
The protocol enhances security through threshold-based multi-party control: no single signer can execute critical actions alone. Whether used by Super Representatives for governance or by individual users for asset protection, every execution must be jointly authorized, reducing the risk of key compromise or misuse.
The system supports both on-chain enforcement and off-chain transparency. While approval data (e.g., Merkle roots) is optional and not verified on-chain in v1, it enables verifiable audit trails for governance decisions. Optional coordination APIs improve UX without compromising trust assumptions.
This architecture is flexible by design. The same contract can enforce DAO-level approvals for systemic actions like withdrawToRecoveryPool() and also operate as a lightweight multisig wallet for individuals or teams. Built-in modifiers (onlyCouncilApproval, onlyUserApproval) allow fine-grained execution policies per function.
By aligning with cross-chain standards like EIP-1271 and maintaining compatibility with existing Safe-style patterns, the protocol promotes interoperability with tools, wallets, and external contracts. It lays the groundwork for modular, upgradeable DAO governance, and moves TRON toward a more secure and programmable multi-actor execution model - without breaking backward compatibility.
Conclusion
This TIP defines a contract-based approval and execution framework that brings formal multisignature capabilities to TRON smart accounts. By adopting a standardized signature validation flow, supporting EOA and contract-based signers, and enabling threshold-based authorization, the protocol creates a unified foundation for secure multi-party governance.
The architecture is intentionally modular and upgradeable, supporting both off-chain coordination (e.g. through Merkle commitments or RPC APIs) and on-chain enforcement. It enables a wide range of applications — from high-assurance DAO governance and Super Representative approvals to lightweight organizational wallets and team-controlled assets. All of this is achieved without breaking backward compatibility with existing execution logic or imposing unnecessary consensus changes.
Ultimately, this TIP enhances the expressiveness, security, and interoperability of TRON’s smart contract layer — allowing contracts to serve not only as autonomous agents but also as verifiable signers in complex, multi-actor workflows.