Modules

Modules are smart contracts that bundle custom logic around core operations. Core operations are the actions you can take on a central primitive to change its state. For example, token primitives have the core operations of mint, burn, and transfer which mutate the fundamental storage of token balances and ownership.

While some core operations are exposed externally and therefore have a predefined behavior and control flow, e.g. token transfer, many core operations are kept internal when defined by ERC’s which leaves the use of them open to the developer. This is great for designing new standards, but leads to a fragmentation in the exposed external forms of these operations (how many different mint functions have you seen on an NFT contract that are all mostly the same).

Modules are a design pattern that takes the logic that wraps a core operation, like minting a token, out of the primitive’s contract and into another contract that has permission to call the core primitive. For example, GroupOS deploys a module called GasCoinPurchaseModule that factiliates the purchase of an ERC-721 NFT with the network’s native gas coin, e.g. ETH. This module is responsible for guaranteeing that the NFT collection creator gets paid, the minter gets an NFT, and Station receives a reward for facilitating the transaction.

Taking the idea of externalizing logic to its maximum, the ERC-721 NFT actually does not have any opinions about when or how NFTs should be minted, burned, or transfered and delegates that responsibility entirely to Modules. Modules connect fluidly to primitives, serving many simultaneously and each primitive can equivalently have many modules controlling it at once.

Modules are also great for creating multi-contract integrations that need to make related, protected operations atomically without trust. For example, we want to configure a loyalty system where we reward users by minting an NFT Badge and fungible Points in a known ratio that we can change over time. In a normal contract system, it is not obvious if this logic should live on the Badge contract, Points contract, or force merging them together to one. However with Modules, it is intuitive to externalize this logic to a new loyalty system manager that configures Badge token ids to points values and has the permission on both contracts to control their minting operation behavior.