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?


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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