Skip to main content
All Posts By


Different types of cryptocurrency wallets: The one you need

Mighty Block

In Mighty Block, our purpose is to help onboard the next billion users into Web3. To achieve this, users have to know how to use applications that allow them to connect to the web3, also known as wallets. The problem is that there are different types of cryptocurrency wallets, and even more types of users. Which is the best wallet for each of them? Let’s analyze:

Custodial Wallets

Custodial wallets are those that are managed by a third party. It is the closest thing to a “web2” application (such as a social network) since users will authenticate themselves in the way they do in the applications they use in their daily lives using, for example, their email and a password.

Advantages of Custodial Wallets

  • It is very easy to use.
  • Recovering an account if I lose my password is quite accessible.

Disadvantages of Custodial Wallets

  • You are not the owner of your private keys and therefore do not have full control over your funds.

In resume, it’s a centralized solution for a decentralized world.


Regular Self Custody

In these type of wallets, it is the user who must be in charge of storing and securing their private keys. Among these we find: browser wallets, desktop wallets, some apps and hardware wallets.

Advantages of Regular Self Custody Wallets

  • Now we really own our accounts
  • The security of our account depends on ourselves and not on third parties.

Disadvantages of Regular Self Custody Wallets

  • It’s not uncommon to lose access to an account or get hacked.

MPC Wallets

MPC (for Multi-Party Computation) allows multiple parties to participate in the signing of a transaction. Each part will have a private key and thanks to complex cryptographic algorithms the desired signature is achieved.

Advantages of a MPC Wallet

  • It is a decentralized procedure since it does not store private keys in a third party.
  • Reinforces security thanks to complex cryptographic algorithms.

Disadvantages of a MPC Wallet

  • It can be a bit more complex in its usability
  • Requires more than one physical device which can make it difficult to recover funds.
  • It is not compatible (today) with hardware wallets.

Smart Wallets

These are managed by smart contracts and therefore not only allow to store and transfer but also can execute pieces of code that add functionality such as multisignature.

Advantages of Smart Wallets

  • They have flexibility without losing decentralization.
  • You can even add logic to pay fees with ERC20 tokens.

Disadvantages of Smart Wallets

  • The code can expose vulnerabilities and make transaction costs more expensive.

So, which one should I use?

I believe that there is no silver bullet wallet, but I can give you some clues as to which one is best for you. 

  • You are not a technical user and you want the easiest to use? Custodial wallet.
  • I’m a technical user but I’m not careful with my keys. I prefer to have an easy way to recover my account => Custodial wallet
  • I am a technical user and I want a simple way to manage my account, and I am also very careful with my keys => Self custodial
  • I am a technical user who doesn’t take good care of his keys, but who thinks that multi-factor authentication would work for him => MPC
  • I am a technical user who would like to customize the use of his wallet to even adapt it to decentralized applications => Smart Wallet

Why do I recommend a centralized wallet in some scenarios? Because I think it’s the easiest way to start. And if what we are looking for is adoption, it is important first that everyone can use a wallet, and then become experts and choose the most suitable one.

I hope that with this article you now have a clearer idea about the different types of cryptocurrency wallets that exist.

Which wallet do you think is the most appropriate for you? Let me know in the comments !

Why Devcon is the most important event for web3 developers


Last month the sixth edition of Devcon was held in the city of Bogotá in Colombia. But first…

What is Devcon?

Devcon is a global conference for Ethereum developers that was created in 2014 and is held every year in different countries and continents:

  • Devcon 0: Berlin (2014)
  • Devcon 1: London (2015)
  • Devcon 2: Shanghai (2016)
  • Devcon 3: Cancun (2017)
  • Devcon 4: Prague (2018)
  • Devcon 5: Tokio (2019)
  • Devcon 6: Bogotá (2020)

2020? Well… It was planned for that year but you can guess what happened. Therefore, this edition was not just another edition: it also meant its definitive return. Because of this, people came from all over the world and that leads me to the next paragraph.

Devcon - The most important Conference
Devcon – The most important Conference

People from all over the world

The fact that it was the return to face-to-face was a great attraction for people from all over the world. Networking opportunities and meeting new people are for me the best things about attending this kind of conferences. You can have a coffee and also an interesting conversation with people who are not from your circle of acquaintances and may not even live on your continent. And there are also specific and funny spaces to generate new links and conversations…

Side events

These meetings are happening around the conference. Events can be from breakfast to after office and even rave parties. It is a great time to generate more informal and relaxed conversations, but it also provides opportunities to discuss technical details and do business. If you were busy watching presentations at the conference, side events are the right place to chat. Regarding presentations, if you were busy there it was because…

First class speakers

The best-known experts in the Ethereum world as Vitalik Buterin were on the grid of this conference. In addition to the technical content, it was very valuable to have the opportunity to approach a speaker and interact directly on the topic of the talk. This is clearly not an option in virtuality. Most of the experts have been present at events prior to the Devcon such as…

EthBogota and EthLatam

EthBogota is one of the hackathons organized by the Ethereum Foundation. It was the weekend before Devcon so the people could attend both events on the same trip. More than 1000 people participated in this competition with more than 500K USD in prizes. The day before the Devcon, a special event was held for the Latin American community that had already had an edition in the city of Buenos Aires: EthLatam. Both events added to the Devcon gave the opportunity to bring many experts closer to a region that seems to emerge as a point of interest…

Latam as a point of interest

Latin America is one of the regions with the highest adoption of cryptocurrencies and blockchain-based projects partially due to economic needs but mostly due to a high technical level and a great capacity to undertake. It is very interesting to see the projects that have come out of this region, such as OpenZeppelin. One of the remarkable progress was in digital identity, and one of the most interesting topics discussed in the conference was Zero Knowledge Proof…

ZK is the future

Something that surprised me was to see a lot of technical content on this topic. Undoubtedly, it is something that will be critical in the coming years and that all of the projects will adopt in one way or another. My recommendation if you are in the web3 industry: learn about Zero Knowledge Proof.

Personal opinion

Personally, it was a great satisfaction to attend the event, being face to face one more time with the community and of course meet new people. The technical content was outstanding, but I must confess that I have to rewatch a lot of the talks to get the most out of them (I think I should do it more often). If you haven’t had a chance to go, stay tuned for next year, and don’t forget to contact me for coffee and a chat there.

Upgradeable Contracts: An introductory guide

One of the first things we learn in Solidity/Ethereum is that contracts are immutable. If you upload a contract on the blockchain, you can’t change its source code and therefore you can’t change its logic.

We must be extremely careful with the code we use: if we make one simple mistake it could be extremely expensive. That’s why we consider alternatives as a way to avoid this limitation. Let’s see how we can use an upgradeable contracts.

Contracts Old School

The simplest thing we can do is upload a new version of the contract (and thus a new deploy and a new address). But this has its issues, for example let’s think about what it was like to have a shop a few years ago (before the internet). If we wanted to move to another address, we had no way of notifying all our clients and potential future clients of this change. The same thing happens in smart contracts, all users must know that the address has changed, but not having a user registry makes it very difficult.

Example no upgradeable contracts

Ways to create a upgradeable contracts

There are currently 4 ways to create an upgradeable contracts.

Using an interface / proxy

Taking advantage of inheritance and polymorphism, an interface with the contract structure can be exposed. So now we have two contracts: one with the contract definition (and external calls) and the other with the function’s implementation. The user interacts with the contract through the interface and if an update is required, the address of the contract is simply changed for the new version in a simple variable inside the contract.

Example upgradeable contracts

It is not possible to modify the contract’s structure since we MUST respect its interface, but its main disadvantage is that the stored values ​​will remain in the contract that has the logic, and if we want to update it with that of another contract, we will lose the storage state.

What is done to solve the storage issue is to have a “proxy” contract that has the same structure as the one with the logic, and it is accessed through the delegatecall instruction. It is SUPER IMPORTANT to keep the same variable structure in the contracts since we will be sharing the storage, and if both do not have the same variable structure, a collision could occur. A possible solution for this is that they both inherit from a base contract that sets the same variable-structure for all of the contract versions.

It seems to be a better alternative but in terms of gas it is expensive: we are always adding variables that we will most likely never use in every logic contract we implement. This can be improved if a third-party storage contract is used, for this, we can use solutions such as OpenZeppelin or combine it with an unstructured storage.

OpenZeppelin Transparent Proxy

If you are a user of the OpenZeppelin contracts you have noticed this plugin for sure. Inside, it uses a mechanism known as Transparent Proxy, which uses unstructured storage to avoid collisions (as long as we add the variables at the end and never at the beginning). This proxy is already integrated as a plugin and is compatible with Hardhat and Truffle.

Link here

Diamond Pattern

This is one of the most popular and most complex, since we have an intermediary contract, but instead of aiming for a single final contract, each function will be implemented in a different smart contract. In addition, each “Facet” contract (as they are called) will have a fixed memory space to avoid collisions. A major advantage is, a whole contract deployment is not required, just a contract with one function implementation. That’s cheaper than deploying a complete-structure contract with all of the functions and also as there is just one function per contract, the size limit is very hard to reach. It is undoubtedly the favoured solution for the complex scenarios that are created today and there is even an EIP that refers to it.

Link here

Syntethix Router Proxies

At ETH Latam event, Alejandro Santander (known as The Ethernaut) presented a solution called Router Proxies. It is quite similar to the Diamond Pattern, but simpler. I recommend watching this talk!

Link here

Video here

Metamorphosis Smart Contract

What? Well, we are not actually modifying the contract, but if we had the ability to remove the contract from storage, we could force a deployment to that same address, then replace one contract with another. And this is how this technique works. Through the selfdestruct() statement, it is possible to remove a contract from the blockchain storage, and using the create2 operation, a new version of the contract is deployed to THE SAME ADDRESS.

Link here

Ok, but… is it okay to modify a Smart Contract?

In centralized software, not only is this not a bad thing, it is a necessary thing. What happens in decentralized projects? Who should update the code? Is a DAO reliable enough? On the one hand, an immutable contract seems more reliable than an upgradeable contracts but it also makes it more vulnerable to attacks. In my opinion, it is good to consider all these alternatives and use them if the project requires a sophisticated architecture. Making a contract upgradeable makes its code much harder to understand and trace, but improves its resistance to attacks. If the strength of a project is its simplicity, I would not work on making the contract updatable, but I would do so in complex projects with multiple contracts.