I have pretty big smart contract with a lot of structs. Each struct has in average 3-4 related methods (i.e. methods with first parameter MyLibrary.MyType storage self).

Question about code organization: does it makes sense to store each struct/type with corresponding methods in separate library and link it to contract or keep it altogether under single big library?

Another approach I see is to store all structs/types in single library but move all methods to separate libs.

Right now I cannot see any advantages in separate small libraries except code readability.

1 Answer 1


You might even prefer to separate it into several contracts, not libraries.

The reason is that if you decide to change a specific functionality in the future, you can easily replace the specific contract which implements it.

This is not feasible if you have everything under a single contract (in which case, you'd have to replace the entire contract).

It is also not feasible if you have everything split between several libraries, since all of them will be compiled and linked into the single contract which imports them.

Of course, in order to allow for such future replacements, you will have to add in the main contract a setter function for each sub-contract (and make sure that you restrict it to owner-only, otherwise you get a security-breach where anyone can replace your sub-contracts).

  • It involves too much additional charges to communicates between contracts, isn't it?
    – Alex G.P.
    Commented May 10, 2018 at 9:01
  • "too much" depends on what exactly you do. For example, if you have a "massive" for loop, then yes - you would better not call a function on another contract from inside the loop (or perhaps even a function on the same contract). But in other cases, it may be negligible. You'll need to define your system requirements, and then design it accordingly. Commented May 10, 2018 at 12:11
  • As @goodvibration mentioned, besides code readability, the ability to change specific functions, ability to split costs between contracts depending on what you're storing and what functions you have, and ability to replace, sounds like a much better architecture than one long contract.You could in theory have one large library, then end up implementing a 'basic' version of that which only calls specific methods (ex: open zeppelin erc721 vs. basic). Either way, you'll find yourself making multiple contracts. Commented May 10, 2018 at 16:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.