I have noticed many EOS contract programmers choose to have a token contract and a seperate smart contract for other things to do with those tokens. What are the advantages and disadvantages to this approach as opposed to creating a unified contract that includes the token logic and the other contract functions? My reason for asking is that the contract I'm working on would only have 2-3 functions, and hardly seems like there is that much advantage to having a separate contract specifically for 2-3 token functions.

The only strong reason I could think of to follow the split contract approach, is that the initial token logic and distribution contract is unlikely to need to be updated, where the use of such tokens may get updated much more frequently. So thoughts on why to take either approach?


3 Answers 3



  1. You have to manage your resources across each of the contracts separately, meaning that one contract could run out of CPU, NET, or RAM, whilst the other contract still has enough, meaning that your system is half-working, and that can cause all manner of problems. A single contract works until it doesn't, and then everything stops.
  2. Calling inline actions between the two contracts costs more CPU time than calling an internal function within the same contract.


  1. Permissions can be structured to make certain aspects of a system immutable, whilst allowing flexibility in other parts of the code. For example, you might seperate the token contract from the token utility contract, the token utility can always be updated, but the keys for the token contract are nulled so that there is no risk of supply being increased.
  2. It can lead to cleaner functionality of each contract, and leads to less baggage
  3. Reduces the damage of a hack. If one contract is somehow compromised it does not follow that the other contracts are also compromised, and therefore a fraction of the funds that could have been taken will be saved

Separating different roles to different contracts is called separation of concerns in programming.

If functionalities are unrelated, they should not be unnecessary bundled. Unbundling leads to cleaner, easier to maintain and more bug free codebase.


The token contract is usually the standard eosio.token and just uploaded to an account to create the token for the user since there is no central token creation contract.

Then the developer manages their own contract in a separate code base to keep the code base for their development in a separate git repository. Their contract usually is developed internally and at a higher frequency compared to the token contract.

Your Answer

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

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