BSAFE is a secure multi-signature non-custodial wallet built on top of Fuel Stack.

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.

Okay, so how does it work?

Explaining the tool's operation briefly, this is the workflow:

1. Vault creation

   1. Creates predicate;

   2. Predicate rules

   3. Minimum number of subscribers

   4. Subscriber addresses;

   5. Save binary, ABI, and address.

2. Transaction

   1. Instantiate using the Fuel TS-SDK

   2. Save the hash (tx_id) of the transaction;

   3. Off-chain.

3. Signature

   1. Signatures on the transaction hash;

   2. Save the signature.

4. Validation

   1. UI identifies signatures and executes the transaction;

   2. Predicate retrieves the transaction hash;

   3. Predicate validates transaction rules;

   4. Transaction in sent.

But technically speaking, how does all of this work?

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.

To better understand what happens on-chain and off-chain, we can refer to this diagram:

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:

• Website

• Github

• X (Twitter)

• Discord community

• Telegram community

Feel free to message me on Discord as well. Nickname: joaobolsoni