Bako SafeHow to use BSafe SDK?
In the evolving landscape of modular blockchain technology, BSAFE stands out as Fuel's native stateless multisig. We are proud to announce our new SDK, a pivotal tool for developers on the Fuel Network. This SDK not only streamlines the integration of BSAFE multisig wallet functionality into decentralized applications (DApps) but also represents a significant advancement in secure and efficient transaction management for the entire blockchain ecosystem. In this article, we will dive into...
Bako SafeSimplifying Smart Contract Deployment with Bako Safe
Simplifying Smart Contract Deployment with Bako SafeIn this article, we introduce an exciting new feature of Bako Safe. You can now create an API token in your vault wallet, and visualize contract deployments directly within the app. This feature, together with the SDK and the Connector, significantly improves the developer experience and moves us closer to being a complete asset management solution for the Fuel ecosystem. Follow the steps below for the full process. Setting Up Your Environme...
Bako SafeUnleashing the Power of Fuel dApps with Bako Connector
Fuel is evolving fast approaching the mainnet launch, and with it, the need for seamless integration between dApps and secure environments is critical. Enter the Bako Connector, a pivotal development in the Bako Safe ecosystem, designed to bridge the gap between dApps on Fuel Network and the robust security framework of Bako Safe, Fuel’s native multisig wallet.What is the Bako Connector?The Bako Connector leverages the native Fuel Wallet connector features to provide a seamless interface for ...
Bako Safe is the native multisig wallet of Fuel Network. Gas-less vault creation, multi chain support and seamless experience.
Bako SafeHow to use BSafe SDK?
In the evolving landscape of modular blockchain technology, BSAFE stands out as Fuel's native stateless multisig. We are proud to announce our new SDK, a pivotal tool for developers on the Fuel Network. This SDK not only streamlines the integration of BSAFE multisig wallet functionality into decentralized applications (DApps) but also represents a significant advancement in secure and efficient transaction management for the entire blockchain ecosystem. In this article, we will dive into...
Bako SafeSimplifying Smart Contract Deployment with Bako Safe
Simplifying Smart Contract Deployment with Bako SafeIn this article, we introduce an exciting new feature of Bako Safe. You can now create an API token in your vault wallet, and visualize contract deployments directly within the app. This feature, together with the SDK and the Connector, significantly improves the developer experience and moves us closer to being a complete asset management solution for the Fuel ecosystem. Follow the steps below for the full process. Setting Up Your Environme...
Bako SafeUnleashing the Power of Fuel dApps with Bako Connector
Fuel is evolving fast approaching the mainnet launch, and with it, the need for seamless integration between dApps and secure environments is critical. Enter the Bako Connector, a pivotal development in the Bako Safe ecosystem, designed to bridge the gap between dApps on Fuel Network and the robust security framework of Bako Safe, Fuel’s native multisig wallet.What is the Bako Connector?The Bako Connector leverages the native Fuel Wallet connector features to provide a seamless interface for ...
Bako Safe is the native multisig wallet of Fuel Network. Gas-less vault creation, multi chain support and seamless experience.
Share Dialog
Share Dialog
Subscribe to Bako Safe
Subscribe to Bako Safe
<100 subscribers
<100 subscribers
We are the first multisig wallet based on the Fuel network. That will revolutionize the financial market in terms of safety and practicality.
Our goal is to enhance security for organizations and individuals with an easy-to-use and cost-effective tool that provides not only day-to-day actions but also financial management.
To achieve our goal, we start with a multi-sig wallet, SDKs and wallet connector for ecosystem integrations, then expand to a financial management tool with a focus on replacing current web2 solutions for web3.
We allow users to preconfigure a set of requirements that must be met for their transactions to be approved. This customized approach ensures greater security and control as each user can define its own security rule according to their needs.
Our multi-sig wallet relies on predicates and an off-chain infrastructure that enables users to create vaults with a set of requirements that must be met for their transactions to be approved. The vault also provides solutions for managing assets, creating batch transfers, signing pending transactions, and viewing transaction history.
Additionally, the tool includes a contacts list, which will be integrated with the NS System tool and developed internally. It features an internal contact tool that allows users to save contacts independently of the NS System.
Another significant advantage of BSAFE for the usability of our users is the automation tool. This will facilitate the management and execution of recurring payments through automation tools that can reduce the time and the likelihood of errors in your financial management.
Explaining the tool's operation briefly, this is the workflow:
Vault creation
Creates predicate;
Predicate rules
Minimum number of subscribers
Subscriber addresses;
Save binary, ABI, and address.
Transaction
Instantiate using the Fuel TS-SDK
Save the hash (tx_id) of the transaction;
Off-chain.
Signature
Signatures on the transaction hash;
Save the signature.
Validation
UI identifies signatures and executes the transaction;
Predicate retrieves the transaction hash;
Predicate validates transaction rules;
Transaction in sent.
Our system uses the principle of encryption for the creation, validation, and retrieval of data at each end of the system.
Initially, we request the creation of a vault, which is nothing more than a predicate. This predicate has configurable parameters and a main function that returns a boolean value to approve or reject the transaction.
Currently, the configurable parameters are the minimum number of signatures, the address of each authorized subscriber who can validate a transaction, and a random hash that serves to make the predicate unique. The rule (main function) of this predicate retrieves the transaction being sent and collects its hash and witnesses. When collecting this information, all witnesses are decrypted by the "ec_recover_address" function, which takes the transaction hash and one of the signatures as parameters, in order to find any registered address from the creation of the predicate based on the configurable parameters. After checking all the witnesses, the identified signatures must be at least the same number as the configurable "minimum number of signatures." If this statement is true, "true" is returned, which, in the system's perspective, is an approval to proceed with the transaction.
The predicate is created by the user through our UI, and its information such as the binary hash, address, and subscribers are saved in an off-chain database. This predicate can always be retrieved by a user with access to it to receive and send the coins that can be traded on the fuel network.
Users with access to this predicate can request a transaction, which is a transaction script instantiated by the TS-SDK. We store all the information of this transaction in the database, including the binary script and the generated "tx_id()".
When generating the transaction, each user registered as a subscriber of the predicate that originated the transaction will receive a signature request. The requested signature is made by the fuel's TS-SDK, where the user signs using the transaction's "tx_id()", and it is then stored together with the transaction in the database.
Note that everything up to this point has happened off-chain, including the signatures, and they are stored in a database owned by us. When the transaction meets the prerequisites (minimum number of signatures), an attempt is made to finalize this transaction through the predicate. If the main function meets all the requirements, the transaction is confirmed, and only this step happens on-chain.
In conclusion, it's important to highlight why we are doing all of this on Fuel's network. Here are some reasons:
Predicate technology, enabling a security with the best user experience and eliminating the need for contracts and gas fees;
Fuel NetworkVM is designed to reduce the wasteful processing of traditional blockchain virtual machine architectures;
Sway language and Toolchain Force.
If you have any questions or are curious to test the tool, here are some useful links:
Feel free to message me on Discord as well. Nickname: joaobolsoni
We are the first multisig wallet based on the Fuel network. That will revolutionize the financial market in terms of safety and practicality.
Our goal is to enhance security for organizations and individuals with an easy-to-use and cost-effective tool that provides not only day-to-day actions but also financial management.
To achieve our goal, we start with a multi-sig wallet, SDKs and wallet connector for ecosystem integrations, then expand to a financial management tool with a focus on replacing current web2 solutions for web3.
We allow users to preconfigure a set of requirements that must be met for their transactions to be approved. This customized approach ensures greater security and control as each user can define its own security rule according to their needs.
Our multi-sig wallet relies on predicates and an off-chain infrastructure that enables users to create vaults with a set of requirements that must be met for their transactions to be approved. The vault also provides solutions for managing assets, creating batch transfers, signing pending transactions, and viewing transaction history.
Additionally, the tool includes a contacts list, which will be integrated with the NS System tool and developed internally. It features an internal contact tool that allows users to save contacts independently of the NS System.
Another significant advantage of BSAFE for the usability of our users is the automation tool. This will facilitate the management and execution of recurring payments through automation tools that can reduce the time and the likelihood of errors in your financial management.
Explaining the tool's operation briefly, this is the workflow:
Vault creation
Creates predicate;
Predicate rules
Minimum number of subscribers
Subscriber addresses;
Save binary, ABI, and address.
Transaction
Instantiate using the Fuel TS-SDK
Save the hash (tx_id) of the transaction;
Off-chain.
Signature
Signatures on the transaction hash;
Save the signature.
Validation
UI identifies signatures and executes the transaction;
Predicate retrieves the transaction hash;
Predicate validates transaction rules;
Transaction in sent.
Our system uses the principle of encryption for the creation, validation, and retrieval of data at each end of the system.
Initially, we request the creation of a vault, which is nothing more than a predicate. This predicate has configurable parameters and a main function that returns a boolean value to approve or reject the transaction.
Currently, the configurable parameters are the minimum number of signatures, the address of each authorized subscriber who can validate a transaction, and a random hash that serves to make the predicate unique. The rule (main function) of this predicate retrieves the transaction being sent and collects its hash and witnesses. When collecting this information, all witnesses are decrypted by the "ec_recover_address" function, which takes the transaction hash and one of the signatures as parameters, in order to find any registered address from the creation of the predicate based on the configurable parameters. After checking all the witnesses, the identified signatures must be at least the same number as the configurable "minimum number of signatures." If this statement is true, "true" is returned, which, in the system's perspective, is an approval to proceed with the transaction.
The predicate is created by the user through our UI, and its information such as the binary hash, address, and subscribers are saved in an off-chain database. This predicate can always be retrieved by a user with access to it to receive and send the coins that can be traded on the fuel network.
Users with access to this predicate can request a transaction, which is a transaction script instantiated by the TS-SDK. We store all the information of this transaction in the database, including the binary script and the generated "tx_id()".
When generating the transaction, each user registered as a subscriber of the predicate that originated the transaction will receive a signature request. The requested signature is made by the fuel's TS-SDK, where the user signs using the transaction's "tx_id()", and it is then stored together with the transaction in the database.
Note that everything up to this point has happened off-chain, including the signatures, and they are stored in a database owned by us. When the transaction meets the prerequisites (minimum number of signatures), an attempt is made to finalize this transaction through the predicate. If the main function meets all the requirements, the transaction is confirmed, and only this step happens on-chain.
In conclusion, it's important to highlight why we are doing all of this on Fuel's network. Here are some reasons:
Predicate technology, enabling a security with the best user experience and eliminating the need for contracts and gas fees;
Fuel NetworkVM is designed to reduce the wasteful processing of traditional blockchain virtual machine architectures;
Sway language and Toolchain Force.
If you have any questions or are curious to test the tool, here are some useful links:
Feel free to message me on Discord as well. Nickname: joaobolsoni
No activity yet