MINTLY — SMART CONTRACT TEMPLATES

This document provides a detailed overview of all token smart contract templates available in Mintly. Each template is designed for a specific use case and follows a transparent, immutable, and non-custodial design.

Standard Template

1. Overview

The Standard template is a basic ERC-20 token with no additional management logic. It is designed for simple and secure token issuance with a fixed total supply that is created once at deployment.

The contract is based on OpenZeppelin ERC20 and Ownable and fully supports proxy clones via EIP-1167.

2. Core Functionality

• Standard ERC-20 functions (transfer, balanceOf, approve, transferFrom)
• Fixed total supply
• Contract ownership assignment
• Full compatibility with wallets, DEXs, and ERC-20 infrastructure

No additional control or management features are included.

3. Token Creation Logic

• Token name and symbol are set during initialization
• Total supply is defined once
• All tokens are minted immediately
• 100% of supply is sent to the owner wallet
• Ownership is assigned during initialization

The init function can only be executed once.

4. Ownership Model

• Uses the Ownable model
• The owner receives 100% of the supply
• No owner-only token logic exists beyond standard ownership
• Ownership is used for transparency and compatibility, not active control

5. Limitations

This template does not support:

• Additional minting
• Burning tokens
• Transfer taxes
• Max transaction limits
• Max wallet limits
• Pause, blacklist, or whitelist
• Contract upgrades

6. Typical Use Cases

• Simple utility tokens
• Demo and test projects
• DAO tokens without advanced logic
• Airdrop tokens
• Exchange listings requiring a clean ERC-20
• Projects prioritizing simplicity and compatibility

7. Risk & Responsibility Notes

• All parameters are permanent
• Mistakes cannot be corrected after deployment
• Mintly cannot modify or stop the contract
• Token management is fully controlled by the owner wallet

8. Summary

The Standard template is the safest and simplest option:

• One-time deployment
• Fixed supply
• No custom logic
• Maximum ERC-20 compatibility

Mintable Template

1. Overview

Mintable is an ERC-20 token that supports additional token issuance after deployment. This template extends the basic ERC-20 standard by adding a mint function that is available only to the contract owner.

The contract is based on OpenZeppelin ERC20 and Ownable and supports proxy clones using the EIP-1167 standard.

2. Core Functionality

The Mintable template includes standard ERC-20 functionality along with controlled token issuance:

• all standard ERC-20 operations (transfer, approve, transferFrom)
• a fixed initial supply defined at deployment
• ability to mint additional tokens after deployment
• access control for minting via onlyOwner
• full compatibility with ERC-20 wallets, DEXs, and infrastructure

3. Token Creation Logic

During initialization (init):

• the token name and symbol are defined
• the initial total supply is specified
• the entire initial supply is minted once
• all tokens are sent to the owner wallet
• contract ownership is assigned during initialization

Initialization can only be performed once.

4. Minting Logic

After deployment, the contract owner can issue new tokens:

• via the function mint(address to, uint256 amount)
• available only to the owner
• allows minting any amount of tokens
• can be executed at any time after deployment
• newly minted tokens increase the total supply

There is no built-in maximum supply cap.

5. Ownership Model

• The contract uses the Ownable access model
• The owner:
• receives the full initial supply
• can mint additional tokens
• controls all token issuance
• Ownership can be transferred using standard Ownable mechanisms (if supported by the deployed OpenZeppelin version)

6. Limitations

The Mintable template does not support:

• burning of tokens
• transfer taxes or fees
• transaction size limits
• wallet balance limits
• pause, blacklist, or whitelist mechanisms
• automatic supply caps or hard limits

Supply control is entirely based on trust in the contract owner.

7. Typical Use Cases

The Mintable template is suitable for:

• tokens with staged or progressive issuance
• projects with DAO or centralized supply management
• reward systems and incentive mechanisms
• gaming tokens
• projects where the supply is expected to grow over time
• internal accounting and bonus tokens

8. Risk & Responsibility Notes

• The owner can mint an unlimited number of tokens
• Inflation fully depends on the owner’s actions
• Users and investors must consider the risk of supply dilution
• Mintly does not control or restrict minting activity
• Incorrect or accidental mint operations are irreversible

9. Summary

Mintable is a flexible ERC-20 token with controlled issuance:

• initial supply defined at deployment
• unlimited minting after deployment
• simple and transparent owner-based control
• well suited for projects with evolving token economies

Mint + Burn Template

1. Overview

Mint + Burn is an ERC-20 token with a flexible supply model that allows both increasing and decreasing the total supply over time.

The contract owner can mint new tokens, while any token holder can burn (destroy) their own tokens voluntarily.

The template is based on OpenZeppelin ERC20 and Ownable and is fully compatible with EIP-1167 proxy clones.

2. Core Functionality

The Mint + Burn template combines two key supply management mechanisms:

• standard ERC-20 functionality
• minting of new tokens by the contract owner
• burning of tokens by any holder
• dynamic total supply (can increase or decrease)
• full compatibility with wallets, DEXs, and analytics tools

3. Token Creation Logic

During initialization (init):

• the token name and symbol are defined
• the initial total supply is specified
• the entire initial supply is minted once
• all tokens are sent to the owner wallet
• contract ownership is assigned during initialization

The init function can only be executed once.

4. Minting Logic

After deployment, the contract owner can issue new tokens:

• via the function mint(address to, uint256 amount)
• available only to the owner
• can be executed at any time after deployment
• increases the total supply
• has no built-in limits or maximum cap

5. Burning Logic

Any token holder can reduce the total supply:

• via the function burn(uint256 amount)
• burns tokens only from the caller’s own balance
• reduces the total supply
• does not require owner permissions
• cannot be used to burn tokens from other addresses

Burning is a fully voluntary and irreversible action.

6. Ownership Model

• The contract uses the Ownable access model
• The owner:
• receives the entire initial supply
• can mint new tokens
• Ownership does not grant the right to burn tokens belonging to others
• Supply control is split:
• mint → contract owner
• burn → each user for their own balance

7. Limitations

The Mint + Burn template does not support:

• transfer taxes or fees
• automatic burn mechanisms
• maximum supply limits
• transaction size limits
• wallet balance limits
• pause, blacklist, or whitelist features
• roles other than owner

Supply changes are performed only through manual mint and burn actions.

8. Typical Use Cases

The Mint + Burn template is suitable for:

• tokens with managed inflation and deflation
• DAO governance tokens
• utility tokens with burn mechanics
• gaming and reward tokens
• tokens with buyback-and-burn logic (implemented off-chain)
• projects where users can voluntarily reduce supply

9. Risk & Responsibility Notes

• The owner can mint an unlimited number of tokens
• Any user can permanently destroy their own tokens
• Burn operations are irreversible
• Incorrect mint or burn actions cannot be undone
• Mintly does not restrict or control owner behavior

10. Summary

Mint + Burn is a flexible ERC-20 template with dual supply control:

• initial supply defined at deployment
• minting controlled by the owner
• burning available to all token holders
• simple, transparent logic with no hidden mechanisms

Tax (Safe) Template

1. Overview

Tax (Safe) is an ERC-20 token with a built-in transfer fee (tax) mechanism. The tax is applied only when interacting with the token owner and is sent to a dedicated tax wallet.

The template is implemented using OpenZeppelin ERC20 (v5.x) and supports EIP-1167 proxy clones.

2. Core Functionality

This template extends the standard ERC-20 with:

• a transfer tax mechanism
• separate tax rates for “buy” and “sell” operations
• automatic fee distribution to a tax wallet
• administrative control over tax parameters
• built-in safety limits for maximum tax values

Regular transfers between users are not taxed.

3. Token Creation Logic

During initialization (init):

• the token name and symbol are defined
• the initial total supply is specified
• the entire supply is minted once
• all tokens are sent to the owner wallet
• the contract owner is set during initialization
• the tax wallet is set to the owner by default

The init function can be executed only once.

4. Tax Logic (How Fees Work)

The tax is calculated on each token transfer according to the direction of the transfer:

• Buy tax Applied when tokens are sent from the owner address (from == owner)
• Sell tax Applied when tokens are sent to the owner address (to == owner)
• No tax Applied to all transfers between regular users (from ≠ owner and to ≠ owner)

5. Tax Parameters

Tax values are stored in basis points:

• DIVISOR = 10,000
• buyTax — default 2.00%
• sellTax — default 3.00%

Administrative safety limits:

• Buy tax ≤ 10%
• Sell tax ≤ 15%

These limits are hardcoded in the contract and cannot be exceeded.

6. Tax Wallet

• All collected fees are sent to the taxWallet
• By default, the tax wallet equals the owner address
• The owner can change the tax wallet at any time
• The tax wallet has no special privileges other than receiving fees

7. Mint / Burn Behavior

• Mint operations (from == address(0)) are not taxed
• Burn operations (to == address(0)) are not taxed
• Taxes apply only to regular transfers

The contract does not include automatic burn or tax redistribution mechanisms.

8. Ownership Model

• The contract uses a custom owner model (not OpenZeppelin Ownable)
• Only the owner can:
• change the buy tax
• change the sell tax
• change the tax wallet
• The owner cannot:
• exceed the built-in tax limits
• disable taxes unless they are explicitly set to zero

9. Limitations

The Tax (Safe) template does not support:

• automatic liquidity taxes
• anti-bot mechanisms
• whitelist or blacklist features
• pause functionality
• maximum supply limits
• transaction size limits
• wallet balance limits
• roles other than owner

Taxes depend solely on the transfer direction relative to the owner address.

10. Typical Use Cases

The Tax (Safe) template is suitable for:

• projects with buy/sell transfer fees
• tokens monetized through transfer taxes
• simple meme tokens with transparent fees
• tokens with controlled and predictable tax behavior
• projects that require no hidden tax mechanics

11. Risk & Responsibility Notes

• The owner controls tax rates within predefined limits
• Changing the tax wallet affects who receives collected fees
• Users must understand the buy/sell logic relative to the owner address
• Mintly does not control or interfere with tax policy
• All fees are transparent and fully on-chain

12. Summary

Tax (Safe) is an ERC-20 template with a predictable and limited tax mechanism:

• taxes apply only when interacting with the owner
• separate buy and sell rates
• hardcoded safety limits
• simple and transparent logic
• no hidden or dynamic mechanisms

Max Tx Template

1. Overview

Max Tx is an ERC-20 token with a strict limit on the maximum size of a single transaction. The limit is calculated as a fixed percentage of the total token supply (totalSupply) and is automatically applied to all regular transfers.

This template is designed to restrict large token movements and is fully compatible with EIP-1167 (minimal proxy).

2. Core Functionality

The template extends the standard ERC-20 with:

• a maximum transaction size limit
• automatic limit calculation based on totalSupply
• a built-in safe preset
• explicit exceptions for the token owner
• no need for manual configuration after deployment

The limit is enforced directly at the smart contract level, not through UI or backend logic.

3. Token Creation Logic

During initialization (init):

• the token name and symbol are defined
• the initial total supply is specified
• the entire supply is minted once
• all tokens are sent to the owner
• the contract owner is set during initialization
• re-initialization is not possible

4. Max Transaction Logic

The transaction limit is enforced inside the _update() function, which is the unified entry point for all transfer operations.

Logic flow:

• every transfer is checked
• if the transfer value exceeds the limit, the transaction is reverted
• the limit is calculated as a percentage of totalSupply

Formula:

maxTx = totalSupply × 2%

5. Preset Parameters

• MAX_TX_BPS = 200 (2.00%)
• BPS_DENOMINATOR = 10,000

This means that a single transaction cannot exceed 2% of the total supply.

The preset:

• is hardcoded into the contract
• cannot be changed after deployment
• applies equally to all users

6. Exceptions (Who Is Not Limited)

The max transaction limit does not apply when:

• minting occurs (from == address(0))
• burning occurs (to == address(0))
• the sender is the contract owner
• the recipient is the contract owner

These exceptions allow the owner to:

• add liquidity
• perform large operational transfers
• handle listings and technical actions

7. Ownership Model

• The contract uses OpenZeppelin Ownable
• The owner is defined during initialization
• The owner:
• cannot modify the transaction limit
• cannot disable the Max Tx mechanism
• is automatically exempt from the limit

Max Tx is a non-administrative mechanism after deployment.

8. Mint / Burn Behavior

• Mint operations are not limited
• Burn operations are not limited
• The restriction applies only to regular user-to-user transfers

9. Limitations

The Max Tx template does not support:

• changing the limit after deployment
• different limits for different addresses
• whitelist or blacklist mechanisms
• temporary disabling of Max Tx
• wallet balance limits
• anti-bot logic
• taxes or transfer fees
• pause functionality

10. Typical Use Cases

The Max Tx template is suitable for:

• protection against large single sell-offs
• limiting whale-sized transactions
• fair launch scenarios
• meme tokens with anti-dump logic
• projects with simple and transparent rules

11. Risk & Responsibility Notes

• The transaction limit is permanently fixed
• If totalSupply increases (in templates with mint), the limit grows proportionally
• Users must consider the limit when planning transfers
• Mintly cannot modify or disable Max Tx after deployment

12. Summary

Max Tx is a simple and strict transaction-limiting template:

• fixed 2% transaction cap
• no hidden logic
• no administrative controls
• safe for fair launch scenarios
• fully on-chain and transparent

Max Wallet Template

1. Overview

Max Wallet is an ERC-20 token with a restriction on the maximum balance that a single wallet can hold. The limit is calculated as a fixed percentage of the total token supply (totalSupply) and is automatically enforced for all token recipients.

This template is designed to prevent token concentration in a single address and is fully compatible with EIP-1167 (minimal proxy).

2. Core Functionality

The template extends the standard ERC-20 with:

• a maximum wallet balance limit
• automatic limit calculation based on totalSupply
• a built-in safe preset
• explicit exceptions for the token owner
• no need for administration after deployment

The restriction is enforced directly at the smart contract level, not via UI or backend logic.

3. Token Creation Logic

During initialization (init):

• the token name and symbol are defined
• the initial total supply is specified
• the entire supply is minted once
• all tokens are sent to the owner
• the contract owner is set during initialization
• re-initialization is not possible

4. Max Wallet Logic

The wallet balance limit is enforced inside the _update() function, which is the unified processing point for all transfer, mint, and burn operations.

Logic flow:

• the recipient’s balance is checked after each transfer
• if the balance exceeds the allowed limit, the transaction is reverted
• the limit depends on the current totalSupply

Formula:

maxWallet = totalSupply × 2%

5. Preset Parameters

• MAX_WALLET_BPS = 200 (2.00%)
• BPS_DENOMINATOR = 10,000

This means that a single wallet cannot hold more than 2% of the total supply.

These parameters are:

• hardcoded into the contract
• immutable after deployment
• identical for all users

6. Exceptions (Who Is Not Limited)

The Max Wallet restriction does not apply when:

• tokens are sent to the zero address (burn)
• the recipient is the contract owner

This allows the owner to:

• hold the entire supply
• manage liquidity
• perform technical and operational actions

7. Ownership Model

• The contract uses OpenZeppelin Ownable
• The owner is defined during initialization
• The owner:
• cannot modify the wallet limit
• cannot disable the Max Wallet mechanism
• is exempt from the balance restriction

The Max Wallet mechanism is immutable after deployment.

8. Mint / Burn Behavior

• Mint operations are allowed without restriction for the owner
• Burn operations are allowed
• Burned tokens are excluded from the Max Wallet balance check
• The restriction applies only to the recipient’s final balance

9. Limitations

The Max Wallet template does not support:

• changing the limit after deployment
• different limits for different addresses
• whitelist or blacklist mechanisms
• temporary disabling of Max Wallet
• transaction size limits
• anti-bot logic
• taxes or transfer fees
• pause functionality

10. Typical Use Cases

The Max Wallet template is suitable for:

• fair launch projects
• meme tokens with anti-whale accumulation protection
• community-driven tokens
• tokens with evenly distributed supply
• projects with simple and transparent rules

11. Risk & Responsibility Notes

• The wallet limit is permanently fixed
• If totalSupply increases (in templates with mint), the limit increases proportionally
• Users must account for the limit when receiving tokens
• Mintly cannot modify or disable Max Wallet after deployment

12. Summary

Max Wallet is a simple and strict balance-limiting template:

• fixed 2% balance cap
• protection against token concentration
• no administrative controls
• transparent on-chain logic
• well-suited for fair launch and public tokens

Safe Control Template

1. Overview

Safe Control is an ERC-20 token with extended security features, designed for projects that require administrative control over token circulation after deployment.

The template includes:

• global pause of all token transfers
• blacklisting of specific addresses
• centralized control of these mechanisms by the contract owner

The contract is fully compatible with EIP-1167 (minimal proxy pattern).

2. Core Functionality

Safe Control extends the standard ERC-20 functionality with the following security mechanisms:

• ability to temporarily pause all token transfers
• ability to block specific addresses from participating in transactions
• centralized management via the owner role
• on-chain checks applied to every transfer, mint, and burn operation

All checks are enforced at the smart contract level, not at the interface or backend level.

3. Token Creation Logic

During initialization (init):

• token name and symbol are defined
• initial total supply is specified
• the entire supply is minted once
• all tokens are sent to the owner wallet
• contract ownership is assigned during initialization
• re-initialization is not possible

4. Pause Logic

The contract supports a global pause mechanism:

• pause() — stops all token transfers
• unpause() — resumes normal operation

Behavior while paused:

• all transfer, mint, and burn operations are rejected
• the paused state is checked on every _update() call

The pause applies to all addresses, including the owner.

5. Blacklist Logic

The contract maintains a blacklist of addresses.

Administrative functions:

• blacklistAddress(address) — adds an address to the blacklist
• removeFromBlacklist(address) — removes an address from the blacklist

Blacklist behavior:

• blacklisted addresses cannot send tokens
• blacklisted addresses cannot receive tokens
• checks are enforced on every _update() operation

Blacklist checks are symmetrical — both from and to addresses are verified.

6. Transfer Security Logic

All token operations pass through _update() with the following checks:

1. The contract must not be paused
2. The sender address must not be blacklisted
3. The recipient address must not be blacklisted

If any condition fails, the transaction is reverted.

7. Ownership Model

• The contract uses OpenZeppelin Ownable
• The owner is assigned during initialization
• Only the owner can:
• pause and unpause the token
• manage the blacklist
• The owner cannot:
• change the token supply (unless combined with another template)
• modify the security logic
• permanently disable Safe Control features

8. Mint / Burn Behavior

• Mint:
• allowed (when invoked by internal logic or owner)
• subject to the paused check
• Burn:
• allowed
• subject to the paused check
• Both blacklist and pause rules apply to all operations

9. Limitations

The Safe Control template does not support:

• automatic blacklist management
• temporary or conditional blacklists
• multiple roles (single owner only)
• multi-signature control
• modification of pause or blacklist rules
• transfer taxes or fees
• max wallet or max transaction limits

10. Typical Use Cases

• projects with compliance requirements
• corporate or private tokens
• test and pilot launches
• projects requiring emergency stop functionality
• tokens with elevated risk management needs
• scenarios requiring manual circulation control

11. Risk & Responsibility Notes

• The owner has a high level of control
• Pausing completely stops token circulation
• Blacklist errors may lock user funds
• Users must trust the contract owner
• Mintly does not interfere with contract management after deployment

12. Summary

Safe Control is a security-focused token template offering:

• global token pause
• address blacklist
• strict administrative control
• immutable security logic after deployment
• suitability for regulated and controlled projects