This article was inspired by the Ledger’s recent feature of storing private keys in their system. This fact show us that even hardware wallets may contain variety of exploits. In fact, Ledger is a close sourced system, so anyone who trust this system should also trust them not adding exploits.

But what about open source hardware wallets?

Despite the fact that the security level of open source systems is generally high and inserting exploits is more challenging, an open source policy could potentially undermine the reliability of continuously modifiable repositories. Let us consider a scenario where an open source wallet introduces additional features to its code. If no one reports a security bug, these changes may be released into production, making them accessible to and observable by hackers. Hackers primary task often revolves around reverse engineering, extracting code instructions from running software, and an open source policy inadvertently facilitates their efforts. As a result, we can conclude that individuals with programming knowledge and a deep understanding of a specific wallet solution may find it relatively easier to verify updates compared to average DeFi users.

The first and most cautious approach involves generating your seed using a computer that is not connected to any network or utilizing non-digital methods. You would then physically transfer the transaction to a separate system, sign it there, and write back the signature. This method may seem cumbersome, and even though we can trust software systems that refrain from adding new features and have open-sourced their code, it does not guarantee complete security against exploits in your operating system or other PC components. Additionally, verifying all the programs you use (such as the operating system, browser, wallet, and drivers) can be practically impossible, considering the vast array of systems available.

Thus, for the average user, ensuring nothing untoward happens while enjoying the convenience of using their seed seems nearly impossible. However, there is another perspective to consider. Blockchain-based systems like multi-signature wallets and decentralized applications (DApps) appear to offer enhanced security. You can have multiple distinct wallets held either by yourself or trusted individuals. By doing so, you distribute the risk of exploits across different computers and programs. However, it is worth noting that gathering all the accounts together for each transaction may introduce delays, making it less suitable for everyday use and potentially confusing.

My solution entails implementing a contract that possesses the rights to all your funds, and its address serves as your actual address. This contract acts as a proxy, introducing a delay in your actions, such as a one-day delay as an example. Additionally, there is a trusted admin account assigned with the responsibility of changing owners if the previous owner signals the need for such a change.

Let's imagine that we have encountered a hacker who has attacked us by stealing our owner's key. The hacker is attempting to execute a transaction, but they face a challenge because all the funds are held within a smart contract that imposes a one-day delay on any actions. This delay effectively hinders the hacker's immediate execution of their malicious actions.

As the second holder of the private key, you have the ability to cancel the transaction initiated by the hacker. If the hacker attempts to send another action, you have the authority to reject it as well. This back-and-forth can potentially lead to a significant deadlock if the hacker persists. Furthermore, the hacker can also reject your transaction, thereby preventing both you and the hacker from accessing the funds.

At this crucial juncture, it is important to remember the presence of our trusted admin. In such a situation, we can initiate a special emergency call utilizing the owner rights. This emergency call will effectively halt the execution of all transactions, enabling the admin to transfer the owner rights to another contract. This measure ensures that we have a mechanism in place to address and mitigate the impact of the hacker's actions, providing an opportunity to regain control and safeguard our funds.

In a common scenario, the admin account can be generated online as a seed and never added or used anywhere else, ensuring its isolation. Alternatively, you can place trust in a multisig arrangement involving multiple accounts. The admin's role is solely to facilitate the change of owners upon request.

To hack your account, a hacker would now need to acquire both your owner private key and the admin private key. Obtaining the owner private key can still pose a risk, but the admin private key, which is never exposed online to any third party, adds an additional layer of security. This approach allows you to store your private key in any wallet while only exposing a portion of your actual private data, reducing the risk of unauthorized access to your funds.

Multi-signature wallets offer a similar effect by requiring the gathering of all keys for any action to be performed. However, the system described earlier provides the advantage of not needing to use the admin key unless a hacking incident occurs. This adds an extra layer of security.

Additionally, there are potential options for managing risk and usability within this system.

To ensure a secure period of absence or vacation, you can implement a mechanism that freezes all actions for a specific duration. This freeze period would prevent anyone from executing transactions during your absence. By incorporating such a contract, you can enjoy your vacation with peace of mind, knowing that no unauthorized transactions can take place. This adds an extra layer of protection and guarantees the security of your funds during your designated time away.

In order to address the limitation of a one-day delay for trading, it is possible to introduce operative allowances for trading within the system. Instead of relying on a one-day delay, you can perform an allowance transaction to an operative wallet, enabling trading to take place within a day through that specific trading wallet. However, it is important to note that this solution still necessitates a one-day delay for situations where quick actions are required, such as stable coin depegging.

This system is most suitable when you have sufficient funds within your contract, as it is uncommon to trade all funds at once. By having an allowance for spending a limited amount of funds each day without a daily delay, planned trading becomes more convenient.

However, in rare cases where you need to manipulate a significant amount of funds within a limited timeframe, a different approach can be considered. As previously mentioned, if a hacker obtains both the admin and owner keys, they can potentially execute any transaction, and it becomes a matter of time before they do so.

To address critical situations with time constraints, a solution can be implemented where a transaction is allowed to execute immediately if proposed by the owner and verified by the admin. Due to the infrequent use of the admin key, the time required to react to critical situations becomes comparable to the time it takes to access the admin key (e.g., retrieving a paper with the seed stored at your grandmother's home). This response time can be comparable to the time it takes to gather multisig users or access the seed of a cold wallet where most of your funds are kept.

By implementing these mechanisms, the system can effectively manage both planned trading and critical situations, ensuring a balance between security and usability.

To enhance the security of your manager seed, here are some recommendations:

1. Use a computer without Wi-Fi access: Opt for a device like a Raspberry Pi or any other simple computer that does not have a Wi-Fi module. This minimizes the risk of remote hacking attempts.

2. Generate seed phrase randomly: Avoid using seed phrases that make logical sense, such as excerpts from Shakespeare's poems or any semantically meaningful sentences. There are individuals actively searching for these types of predictable seeds. Instead, utilize open-source software like Linux Debian OS from a flash drive to generate your seed phrase and public key. Write down both on a paper.

3. Securely store your paper: Hide your paper containing the seed and public key in a location of your choice that is known only to you. Consider using a secure physical storage solution like a safe or a hidden compartment.

Now, your security relies on the offline paper that holds your seed, as well as the ability of either yourself or a trusted party (if you have entrusted them with your seed) to initiate a panic transaction within a specified time interval, such as one day. In case of an emergency, this transaction can be used to protect your funds. Sharing your seed with someone else adds an extra layer of security, as even if you are physically captured, they still cannot access your funds without your cooperation. However, be cautious and only share your seed with individuals you trust implicitly.

This article provides a concise overview of how individuals can effectively manage their funds by combining self-trust and open-source systems. The use of open-source solutions allows programmers to easily audit the system, ensuring transparency and security. This approach offers a convenient and reliable solution for everyday use, empowering users to have greater control over their financial assets while leveraging the benefits of open-source technology. By adopting these principles, individuals can achieve a balance between trust in their own abilities and the advantages provided by open-source systems, leading to a more secure and user-friendly experience in managing their funds.