List of Solidity libraries in the wild

You probably know by now that I like making lists :slight_smile:
This one is about keeping track of Solidity libraries that are used by projects out there in the wild.

:warning: This is not an endorsement of any kind.
Unless it is mentioned specifically, OpenZeppelin haven't audited any of these libraries and you should assess their quality and extensively test your integrations with them before using them in production.

A side effect of the list is that we can discuss about including the strongest and more popular building blocks into OpenZeppelin Contracts, so they are reviewed and maintained by our community.

This is a wiki, and comments are open. Please add the libraries you have used, and let us know about your experience using them.

OpenZeppelin Contracts is a library for secure smart contract development. Build on a solid foundation of community-vetted code.

When you are looking for a library, we always recommend to search for it first in OpenZeppelin Contracts. The list below is for contracts that are not part of the OpenZeppelin library.


Math

Integer Arithmetic

Floating Point Arithmetic

Fixed Point Arithmetic

Fractions

Other

Random

Bytes

Arrays

Type conversion

Memory

Proxy

Wallet

Multisig

Data Structures

Strings

Dates

Serialization

Encoding

Cryptography

Tokens

Voting

Timelock

17 Likes

Hi @elopio, great list!

We’ve got a bunch of libraries we’ve done ourselves, which might be of use for some people. We try to make them simple but top quality, following your lead.

Our goal is to show how common business use cases can be implemented, but sometimes that leads us to develop basic building blocks as well.

Please have a look at our repo.

Contents:
AccessControl - This is a similar approach to your own 3.0 access control libraries (we are helping you :D), but some people might appreciate the extra context.
Classifieds - How to implement a simple classifieds board, like Craigslist.
Exchange - We grabbed the Uniswap code and ported it back to Solidity. It’s a great pattern to create decentralized exchanges and markets.
Issuance - A simpler version of Crowdsale, intended to explain how issuance or ICO processes work at a contract level. It has some interesting reuses.
Lists - Implementations of Linked Lists, Doubly Linked Lists, Sorted Sets and so on.
State - A simple implementation of a State Machine. We find it very useful to manage contract state in a consistent manner across projects.
Token - Among others, there is an implementation for a dividend-bearing ERC20 token.
DAO - A demo of how to build a DAO, in this case for a Venture Capital Fund. Reuses the contracts above for a very clear implementation.
Energy - A demo of how to use the uniswap market pattern (not the contract yet) to build an energy trading market.

I’m also the guy that implemented the FixidityLib library. Those were fun times. We’ve forked it to our repo since unfortunately it seems that CementDAO are not maintaining it. We are happy to receive PRs.

3 Likes

Nice @albertocuestacanada! Thanks for sharing and the great work.
I have some problems understanding what is a library and what is a demo. I think this list should only have generic building blocks, what do you think?

Feel free to edit the post and add the ones you think that will be useful and fit the format. I can go through them later in the week.

1 Like

We aim to produce implementation patterns, and during that process a few building blocks have appeared.

If you are just interested in directly reusable contracts you should check these ones:

And as mentioned by yourself:

Our driving concern is that we often have to code a number of recurrent solutions. The patterns are repetitive but we are not sure that coding them into reusable packages would make sense due to their complexity.

We prefer to provide simple examples that just show how things work, and then build the contracts from scratch but customized to a high degree. These might interest some other people in this forum:

  • Classifieds - Simplest implementation of an ERC721 DEX.
  • Exchange - Simplest implementation of an ERC20 DEX.
  • Issuance - An ICO, as well as share issuance.
  • DAO - We are having lots of fun coding a DAO, which reuses 4 of the projects above (Issuance, Voting, Dividends and State Machine). We don’t plan to compete with Aragon, though.
  • Energy - Yet another DEX, this time to trade energy.
1 Like

Great! I’ve added the ones you mentioned as reusable.

I’m not sure the Dividend Bearing ERC20 is as generic as the others in the list On the other hand, I think your Roles implementation should be in the list.
But I like that the guidelines to bootstrap the list are blurry. Let’s give this a try and some time. When more people join and leave their libraries and their comments it will be clearer what’s useful to keep in here.

About your other contracts that are more like a demo, I think having topics for some on them in the showcase category would be awesome.

1 Like

Thanks for pointing out your showcases section, we will definitely be contributing!

1 Like

Chiming in to shill my recently launched fixed-point math library, PRBMath.

The nice thing about PRBMath is that it ticks off all requirements that have been discussed in Designing Fixed Point Math in OpenZeppelin Contracts. It operates with 256-bit word sizes, it has a fixed number of 18 decimals, and it supports both signed and unsigned numbers. But PRBMath doesn’t compromise on gas efficiency - it is comparable in gas prices to ABDKMath64x64, which is known to be efficient.

2 Likes

Hi @PaulRBerg,

Thanks for creating and for sharing. I added to the list. It is a wiki so feel free to add a description.

I love this list!
Could you maybe restore some of the links to augur? The libraries can now be found at:

I'm not sure if I can edit the list myself.

1 Like

Thanks @Markus, I've updated the links.

1 Like

Are there libraries you can use that are deployed so that you don't have to spend gas deploying extra code?

What are the tradeoffs of compiling a library versus of "dynamic linking" to a library that's already deployed on-chain?

Using a library through "dynamic linking" has significant added cost of at least 2600 gas each time the library is used, in addition to encoding/decoding costs that will depend on the data that needs to be passed around.

Those costs are not present when inlining library code, which will generally be a lot cheaper.

The cost of deployment can be high but it is generally accepted that developers are willing to pay a higher price at deployment in exchange for optimized runtime costs for users, given that it is a one time cost and that it can wait to happen at times of lower congestion (i.e. lower gas prices) for significant savings. A service like GasHawk can help you get this timing right.