This Multisig project leverages the power of the Fuel Network and its innovative predicate-based system to build a robust and fully non-custodial solution, enabling secure transaction approval by multiple users without the need for traditional smart contracts.
Bako Safe
Github
Bako user guide
Predicate reference
This protocol offers a modern approach to building multisigs by removing intermediaries and granting users complete control over funds and approval logic. Responsibility for asset management lies entirely with the participants, with no access or involvement from the protocol itself.
Predicate Architecture
The predicate developed by Bako consists of three configurable elements that define the approval rules required to move UTXOs associated with the linked address.
In the diagram below, the bytecode is represented as the final element encapsulating all the logic configured within the predicate. It ensures that transactions are processed according to defined rules while maintaining decentralized and non-custodial control.
Core Predicate Components
- Authorized Addresses List:
A fixed list with up to 10 slots, each representing an address authorized to sign transactions linked to this predicate. Only addresses in this list can approve and validate transactions tied to the UTXO. - Minimum Required Signatures:
A configurable value that defines the minimum number of signatures needed to authorize a transaction. This value ranges between 0 and 10 and must not exceed the total number of authorized addresses.
Example: If the list contains 5 addresses, the minimum required signatures cannot be more than 5. - Random Hash in b256 Format:
Each predicate generates a unique b256 hash to ensure that even predicates with identical configurations are distinct. This prevents collisions and strengthens security, ensuring that each predicate is uniquely tied to its respective UTXO. - Bytecode:
The compiled result of the Sway code written by the Bako team. It contains all the validation logic required for the predicate, including address verification and signature checks.
Signature Handling
When a predicate is instantiated, transactions must include in their bytecode the members’ signatures over the tx_id. The protocol currently supports Secp256r1 and Secp256k1 curves for signature validation, ensuring compatibility with both Fuel wallets and WebAuthn-based systems.
Each signature consists of three essential components:
- Bako Prefix (4 bits):
A unique identifier marking the signature format within the Bako protocol. - Curve Enum (1 bit):
Indicates the elliptic curve used to generate the signature:- Secp256k1: widely used in blockchain wallets.
- Secp256r1: common in systems like WebAuthn.
- Signature Content:
The core part of the signature, with its size depending on the key type and provider:- Fuel wallet signatures (Secp256k1): fixed size of B512.
- WebAuthn signatures: variable size based on the provider and included metadata.
This flexible format allows the protocol to support multiple signature methods while maintaining security and interoperability. Learn more about WebAuthn standards at webauthn.io.
Validation Process
The Sway contract enhances the signature process by including a validation step that recovers addresses during the recover process. It uses the signatures in the witnesses to derive the associated public addresses, which are then subjected to logical validation.
To correctly retrieve a signer’s address, the process requires both the payload and the signed value — the transaction’s tx_id, available in the predicate execution context.
If there’s any mismatch between the tx_id in the context and the one used to generate the signature, the process will still derive an address, but it won’t match any authorized addresses, rendering the signature invalid. This prevents forgery attempts and ensures that only valid signatures over the correct tx_id are accepted.
Signature Matching Algorithm
An iteration algorithm loops through all addresses in the list configured within the predicate, checking whether each recovered address exists in the authorized list. For every valid match, a counter is incremented.
At the end of the iteration, the main validation is performed:
The protocol compares the counter’s value to the minimum required signatures defined in the predicate.
- If the number of valid signatures is greater than or equal to the threshold, the transaction is approved.
- Otherwise, it’s rejected.
This ensures that only transactions approved by a sufficient number of authorized signers are processed, maintaining the system’s integrity and security.
Conclusion: Empowering Secure Transactions on Fuel Network
This robust and flexible architecture not only ensures the security and decentralization expected from non-custodial solutions but also provides a solid foundation for future innovations within the Fuel Network ecosystem.
By combining the efficiency of predicates with dynamic validation logic, Bako’s multisig protocol stands out as a scalable solution ready to adapt to the evolving needs of the Fuel Network.
With a focus on usability, security, and adaptability, the system supports a wide range of use cases — from simple applications to complex integrations — always keeping ultimate control in the hands of the users.
The future of secure and decentralized transactions on the Fuel Network is already here — and predicates are the key to making it happen.