OpenZeppelin Contracts (Solidity) MCP server

Endpoint: https://mcp.openzeppelin.com/contracts/solidity/mcp · Authentication: No auth

Generates Solidity smart contracts from OpenZeppelin Contracts Wizard templates. It needs no account or API key.

Test it live Run the release-readiness report

How do I authenticate?

Add the endpoint directly in your client. The catalog records no authentication requirement; no OAuth sign-in or API key is configured in this setup. The live server may change.

Authentication and connection guide

Connection specification

Remote endpoint: https://mcp.openzeppelin.com/contracts/solidity/mcp
Browser access: Not yet measured
Declared MCP transport: Streamable HTTP
Live-validated MCP transport: Streamable HTTP — Observed by the latest catalog validation
Declared authentication: No authentication
Detected authentication: No authentication detected or retained from publisher evidence
Protocol lifecycle: Stateful MCP · 2025-11-25
Category: Developer Tools

Product documentation · Source repository · Official listing documentation

More Developer Tools MCP servers · Browse all MCP servers · Test this endpoint in the MCP Playground

Authorization setup

No app registration needed

This catalog entry does not require authorization or provider app registration.

Connect it

Live-validated endpoint: https://mcp.openzeppelin.com/contracts/solidity/mcp · Streamable HTTP. No authentication is required by the catalog listing.

Agent prompt for Claude Code or Codex

Add the OpenZeppelin Contracts (Solidity) MCP server to my MCP client configuration and verify that it works.

What it is: Generates Solidity smart contracts from OpenZeppelin Contracts Wizard templates. It needs no account or API key.
Server URL: https://mcp.openzeppelin.com/contracts/solidity/mcp
Transport: Streamable HTTP (remote MCP server, no local install).
Authentication: none. The server accepts connections without credentials.
Tools (8, as last observed by mcptest): solidity-account, solidity-custom, solidity-erc1155, solidity-erc20, solidity-erc721, solidity-governor, solidity-rwa, solidity-stablecoin.
Reference: https://mcptest.io/servers/openzeppelin-solidity/

Steps:
1. Work out which MCP client I use (Claude Code, Codex, Cursor, VS Code or another) and add the server under the name "openzeppelin-solidity" in that client's MCP configuration, user scope unless I ask otherwise.
Claude Code: claude mcp add --transport http --scope user 'openzeppelin-solidity' 'https://mcp.openzeppelin.com/contracts/solidity/mcp'
Codex: codex mcp add 'openzeppelin-solidity' --url 'https://mcp.openzeppelin.com/contracts/solidity/mcp'
Other clients: use the setup for that client on the reference page.
2. Never write a credential value into a file that could be committed; reference an environment variable or the client's secret store, and ask me for any value you need.
3. Verify: connect to the server and call tools/list. Confirm the tools above are listed, and report any sign-in step I still have to complete.

Claude Code setup

Run in a terminal. This user-scoped entry is available across projects.

claude mcp add --transport http --scope user 'openzeppelin-solidity' 'https://mcp.openzeppelin.com/contracts/solidity/mcp'

Codex CLI setup

Run in a terminal; Codex stores the entry in ~/.codex/config.toml.

codex mcp add 'openzeppelin-solidity' --url 'https://mcp.openzeppelin.com/contracts/solidity/mcp'

Cursor setup

Add to .cursor/mcp.json for this project, or ~/.cursor/mcp.json for all projects.

{
  "mcpServers": {
    "openzeppelin-solidity": {
      "url": "https://mcp.openzeppelin.com/contracts/solidity/mcp"
    }
  }
}

VS Code setup

Add to .vscode/mcp.json, or run “MCP: Open User Configuration” for a private user-level entry.

{
  "servers": {
    "openzeppelin-solidity": {
      "type": "http",
      "url": "https://mcp.openzeppelin.com/contracts/solidity/mcp"
    }
  }
}

Claude setup

Add the endpoint above in Claude:

Customize > Connectors > Add custom connector
Team/Enterprise: Organization settings > Connectors > Add > Custom > Web

Claude Desktop setup

Add the endpoint above in Claude Desktop:

Remote: Customize > Connectors (same as claude.ai)
Local: Settings > Developer > Edit Config, or Settings > Extensions for .mcpb files
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows), local servers only

ChatGPT setup

Add the endpoint above in ChatGPT:

ChatGPT web: Plugins > Add custom MCP server, then configure authentication and accept the risk warning

Windsurf setup

Add the endpoint above in Windsurf:

~/.config/devin/mcp_config.json (%APPDATA%\devin\mcp_config.json on Windows), serverUrl or url
Cascade panel > ... > MCPs > Open MCP config file

Gemini CLI setup

Add the endpoint above in Gemini CLI:

gemini mcp add --transport http <name> <url>
~/.gemini/settings.json (user) or .gemini/settings.json (project), mcpServers

MCP SDK setup

Add the endpoint above in MCP SDK:

Programmatic: new Client(...).connect(new StreamableHTTPClientTransport(url))

Client compatibility

Client	Status	Why
Claude Code	Supported	Claude Code supports Streamable HTTP servers and servers without authentication.
Codex	Partial	Codex's documentation does not state support for servers without authentication. Codex CLI ignores resources: The server can still connect, but Codex CLI does not consume the advertised resources capability.
Cursor	Supported	Cursor supports Streamable HTTP servers and servers without authentication.
VS Code	Supported	VS Code supports Streamable HTTP servers and servers without authentication.
Claude	Supported	Claude supports Streamable HTTP servers and servers without authentication.
Claude Desktop	Supported	Claude Desktop supports Streamable HTTP servers and servers without authentication.
ChatGPT	Partial	ChatGPT ignores resources: The server can still connect, but ChatGPT does not consume the advertised resources capability. Stateful routing needs operational care: ChatGPT can preserve MCP sessions, but the deployment must route a session consistently and retain its state.
Windsurf	Partial	Windsurf's documentation does not state support for servers without authentication.
Gemini CLI	Supported	Gemini CLI supports Streamable HTTP servers and servers without authentication.
MCP SDK	Supported	MCP SDK supports Streamable HTTP servers and servers without authentication.

Computed from this server's validated transport, protocol and authentication against documented client support. Checks the catalog has not observed are not counted.

Similar servers

GitHub — GitHub's official hosted MCP server for repository context, issues, pull requests, code search, and development workflows. OAuth 2.1
MCP Registry Server — MCP interface for searching and publishing servers through the official Model Context Protocol Registry backend. No authentication
GitLab — GitLab's hosted MCP server exposes project, issue, merge-request, pipeline, and repository workflows. OAuth 2.1
CircleCI — CircleCI's hosted MCP server helps inspect pipelines, builds, tests, failures, and delivery workflows. OAuth 2.1
Sanity — Runs GROQ queries, creates and patches documents, manages releases, and reads schemas in Sanity projects. Uses OAuth by default; Sanity also documents token-based authentication. OAuth 2.1
Buildkite — Reads Buildkite pipelines, builds, jobs, logs, artifacts, and test results. This endpoint uses OAuth; headless agents can send an API token to the /direct endpoint. OAuth 2.1

Guides for this server

Watch this server for breaking changes

Share and embed

Maintain OpenZeppelin Contracts (Solidity)? Embed this badge in your README. It follows the latest catalog validation result and links to this server profile.

Markdown

[![Tested on mcptest.io](https://mcptest.io/badge/server/openzeppelin-solidity.svg)](https://mcptest.io/servers/openzeppelin-solidity/)

HTML

<a href="https://mcptest.io/servers/openzeppelin-solidity/"><img src="https://mcptest.io/badge/server/openzeppelin-solidity.svg" alt="Tested on mcptest.io"></a>

reStructuredText

.. image:: https://mcptest.io/badge/server/openzeppelin-solidity.svg
   :alt: Tested on mcptest.io
   :target: https://mcptest.io/servers/openzeppelin-solidity/

Latest validation evidence

Validation status: Online when last tested
Validation checked at: Oct 26, 2026 at 11:07 AM
Validation detail: Negotiated stateful MCP 2025-11-25 at https://mcp.openzeppelin.com/contracts/solidity/mcp; detected transport streamable-http; authentication none

Tool inventory

What the catalog validator observed on Oct 26, 2026 at https://mcp.openzeppelin.com/contracts/solidity/mcp without credentials. The live server may have changed since; connect in the Playground for the current list.

Tools provided by OpenZeppelin Contracts (Solidity) 8

Some details were sanitized for public display.

solidity-accountNo outputSchema
Make an account contract that follows the ERC-4337 standard. Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
Input batchedExecution?: boolean, ERC1155Holder?: boolean, ERC721Holder?: boolean, ERC7579Modules?: any, info?: object, name: string, signatureValidation?: any, signer?: any, upgradeable?: any
- batchedExecution?: booleanoptional
  Whether to implement a minimal batching interface for the account to allow multiple operations to be executed in a single transaction following the ERC-7821 standard.
- ERC1155Holder?: booleanoptional
  Whether to implement the `onERC1155Received` function to allow the account to receive ERC1155 tokens.
- ERC721Holder?: booleanoptional
  Whether to implement the `onERC721Received` function to allow the account to receive ERC721 tokens.
- ERC7579Modules?: anyoptional
  Whether to implement the ERC-7579 compatibility to enable functionality on the account with modules.
- info?: objectoptional
  Metadata about the contract and author
- name: stringrequired
  The name of the account contract
- signatureValidation?: anyoptional
  Whether to implement the ERC-1271 standard for validating signatures. This is useful for the account to verify signatures.
- signer?: anyoptional
  Defines the signature verification algorithm used by the account to verify user operations. Options: - ECDSA: Standard Ethereum signature validation using secp256k1, validates signatures against a specified owner address - EIP7702: Special ECDSA validation using account's own address as signer, enables EOAs to delegate execution rights - Multisig: ERC-7913 multisignature requiring minimum number of signatures from authorized signers - MultisigWeighted: ERC-7913 weighted multisignature where signers have different voting weights - P256: NIST P-256 curve (secp256r1) validation for integration wi
- upgradeable?: anyoptional
  Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades.
solidity-customNo outputSchema
Make a custom smart contract. Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
Input access?: any, info?: object, name: string, pausable?: boolean, upgradeable?: any
- access?: anyoptional
  The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions.
- info?: objectoptional
  Metadata about the contract and author
- name: stringrequired
  The name of the contract
- pausable?: booleanoptional
  Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response.
- upgradeable?: anyoptional
  Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades.
solidity-erc1155No outputSchema
Make a non-fungible token per the ERC-1155 standard. Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
Input access?: any, burnable?: boolean, crossChainBridging?: string, crossChainLinkAllowOverride?: boolean, info?: object, mintable?: boolean, name: string, pausable?: boolean, supply?: boolean, updatableUri?: boolean, upgradeable?: any, uri: string
- access?: anyoptional
  The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions.
- burnable?: booleanoptional
  Whether token holders will be able to destroy their tokens
- crossChainBridging?: stringoptional
  Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Crosschain transfers with registered counterparts burn the tokens on the source chain and mint them on the destination chain.
- crossChainLinkAllowOverride?: booleanoptional
  Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native".
- info?: objectoptional
  Metadata about the contract and author
- mintable?: booleanoptional
  Whether privileged accounts will be able to create more supply or emit more tokens
- name: stringrequired
  The name of the contract
- pausable?: booleanoptional
  Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response.
- supply?: booleanoptional
  Whether to keep track of total supply of tokens
- updatableUri?: booleanoptional
  Whether privileged accounts will be able to set a new URI for all token types
- upgradeable?: anyoptional
  Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades.
- uri: stringrequired
  The location of the metadata for the token. Clients will replace any instance of {id} in this string with the tokenId.
solidity-erc20No outputSchema
Make a fungible token per the ERC-20 standard. Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
Input access?: any, burnable?: boolean, callback?: boolean, chainlinkAce?: boolean, crossChainBridging?: any, crossChainLinkAllowOverride?: boolean, decimals?: string, flashmint?: boolean, info?: object, mintable?: boolean, name: string, namespacePrefix?: string, pausable?: boolean, permit?: boolean, premint?: string, premintChainId?: string, symbol: string, upgradeable?: any, votes?: any
- access?: anyoptional
  The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions.
- burnable?: booleanoptional
  Whether token holders will be able to destroy their tokens
- callback?: booleanoptional
  Whether to include support for code execution after transfers and approvals on recipient contracts in a single transaction.
- chainlinkAce?: booleanoptional
  Chainlink ACE (Automated Compliance Engine) adds token policy enforcement through a separately deployed and configured policy engine (integration guide: [REDACTED URI] Chainlink docs: [REDACTED URI] Defaults to false (disabled). Requires ownable or roles access; combining ACE with CCIP requires roles. This integration does not support ACE together with managed access, Callback (ERC-1363), Flash Minting, a nonzero premint, or bridge modes other than CCIP. Configure policies and register the token with the engine before use; this does not establi
- crossChainBridging?: anyoptional
  Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are custom bridges on any chain, Chainlink CCIP with a separately configured BurnMintTokenPool (integration guide: [REDACTED URI] Chainlink docs: [REDACTED URI] to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. CCIP requires role-based access control, granting the configured pool MINTER_ROLE on each supported chain, and BURNER_ROLE when Burnable
- crossChainLinkAllowOverride?: booleanoptional
  Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native".
- decimals?: stringoptional
  The number of decimals used to represent token amounts. Defaults to 18.
- flashmint?: booleanoptional
  Whether to include built-in flash loans to allow lending tokens without requiring collateral as long as they're returned in the same transaction.
- info?: objectoptional
  Metadata about the contract and author
- mintable?: booleanoptional
  Whether privileged accounts will be able to create more supply or emit more tokens
- name: stringrequired
  The name of the contract
- namespacePrefix?: stringoptional
  The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject".
- pausable?: booleanoptional
  Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response.
- permit?: booleanoptional
  Whether without paying gas, token holders will be able to allow third parties to transfer from their account.
- premint?: stringoptional
  The number of tokens to premint for the deployer.
- premintChainId?: stringoptional
  The chain ID of the network on which to premint tokens.
- symbol: stringrequired
  The short symbol for the token
- upgradeable?: anyoptional
  Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades.
- votes?: anyoptional
  Whether to keep track of historical balances for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps.
solidity-erc721No outputSchema
Make a non-fungible token per the ERC-721 standard. Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
Input access?: any, baseUri?: string, burnable?: boolean, crossChainBridging?: string, crossChainLinkAllowOverride?: boolean, enumerable?: boolean, incremental?: boolean, info?: object, mintable?: boolean, name: string, namespacePrefix?: string, pausable?: boolean, symbol: string, upgradeable?: any, uriStorage?: boolean, votes?: any
- access?: anyoptional
  The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions.
- baseUri?: stringoptional
  A base uri for the token
- burnable?: booleanoptional
  Whether token holders will be able to destroy their tokens
- crossChainBridging?: stringoptional
  Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Crosschain transfers with registered counterparts burn the token on the source chain and mint it on the destination chain. If also using incremental token ids, mint only on a single chain and link counterparts without minting, otherwise colliding ids can strand bridged tokens.
- crossChainLinkAllowOverride?: booleanoptional
  Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native".
- enumerable?: booleanoptional
  Whether to allow on-chain enumeration of all tokens or those owned by an account. Increases gas cost of transfers.
- incremental?: booleanoptional
  Whether new tokens will be automatically assigned an incremental id
- info?: objectoptional
  Metadata about the contract and author
- mintable?: booleanoptional
  Whether privileged accounts will be able to create more supply or emit more tokens
- name: stringrequired
  The name of the contract
- namespacePrefix?: stringoptional
  The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject".
- pausable?: booleanoptional
  Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response.
- symbol: stringrequired
  The short symbol for the token
- upgradeable?: anyoptional
  Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades.
- uriStorage?: booleanoptional
  Allows updating token URIs for individual token IDs
- votes?: anyoptional
  Whether to keep track of individual units for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps (defaulting to block number if not specified).
solidity-governorNo outputSchema
Make a contract to implement governance, such as for a DAO. Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
Input blockTime?: number, clockMode?: any, crossChainExecution?: boolean, decimals?: number, delay: string, info?: object, name: string, period: string, proposalThreshold?: string, quorumAbsolute?: string, quorumMode?: any, quorumPercent?: number, settings?: boolean, storage?: boolean, timelock?: any, upgradeable?: any, votes?: any
- blockTime?: numberoptional
  The block time of the chain in seconds, default is 12
- clockMode?: anyoptional
  The clock mode used by the voting token. For Governor, this must be chosen to match what the ERC20 or ERC721 voting token uses.
- crossChainExecution?: booleanoptional
  Whether passed proposals can relay execution to other chains through ERC-7786 gateways. Requires a CrosschainRemoteExecutor contract, controlled by this governor, deployed on each target chain. The gateway and executor are chosen per proposal as arguments to the relayCrosschain function.
- decimals?: numberoptional
  The number of decimals to use for the contract, default is 18 for ERC20Votes and 0 for ERC721Votes (because it does not apply to ERC721Votes)
- delay: stringrequired
  The delay since proposal is created until voting starts, default is "1 day"
- info?: objectoptional
  Metadata about the contract and author
- name: stringrequired
  The name of the contract
- period: stringrequired
  The length of period during which people can cast their vote, default is "1 week"
- proposalThreshold?: stringoptional
  Minimum number of votes an account must have to create a proposal, default is 0.
- quorumAbsolute?: stringoptional
  The absolute quorum required, in cases of quorumMode equals absolute
- quorumMode?: anyoptional
  The type of quorum mode to use
- quorumPercent?: numberoptional
  The percent required, in cases of quorumMode equals percent
- settings?: booleanoptional
  Allow governance to update voting settings (delay, period, proposal threshold)
- storage?: booleanoptional
  Enable storage of proposal details and enumerability of proposals
- timelock?: anyoptional
  The type of timelock to use
- upgradeable?: anyoptional
  Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades.
- votes?: anyoptional
  The type of voting to use
solidity-rwaNo outputSchema
Make a real-world asset token that uses the ERC-20 standard. This contract type does not support upgradeability. Experimental, some features are not audited and are subject to change. Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
Input access?: any, burnable?: boolean, callback?: boolean, chainlinkAce?: boolean, crossChainBridging?: any, crossChainLinkAllowOverride?: boolean, decimals?: string, flashmint?: boolean, freezable?: boolean, info?: object, mintable?: boolean, name: string, namespacePrefix?: string, pausable?: boolean, permit?: boolean, premint?: string, premintChainId?: string, restrictions?: any, symbol: string, upgradeable?: boolean, votes?: any
- access?: anyoptional
  The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions.
- burnable?: booleanoptional
  Whether token holders will be able to destroy their tokens
- callback?: booleanoptional
  Whether to include support for code execution after transfers and approvals on recipient contracts in a single transaction.
- chainlinkAce?: booleanoptional
  Chainlink ACE (Automated Compliance Engine) adds token policy enforcement through a separately deployed and configured policy engine (integration guide: [REDACTED URI] Chainlink docs: [REDACTED URI] Defaults to false (disabled). Requires ownable or roles access; combining ACE with CCIP requires roles. This integration does not support ACE together with managed access, Callback (ERC-1363), Flash Minting, a nonzero premint, or bridge modes other than CCIP. Configure policies and register the token with the engine before use; this does not establi
- crossChainBridging?: anyoptional
  Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are custom bridges on any chain, Chainlink CCIP with a separately configured BurnMintTokenPool (integration guide: [REDACTED URI] Chainlink docs: [REDACTED URI] to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. CCIP requires role-based access control, granting the configured pool MINTER_ROLE on each supported chain, and BURNER_ROLE when Burnable
- crossChainLinkAllowOverride?: booleanoptional
  Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native".
- decimals?: stringoptional
  The number of decimals used to represent token amounts. Defaults to 18.
- flashmint?: booleanoptional
  Whether to include built-in flash loans to allow lending tokens without requiring collateral as long as they're returned in the same transaction.
- freezable?: booleanoptional
  Whether authorized accounts can freeze and unfreeze accounts for regulatory or security purposes. This feature is experimental, not audited and is subject to change.
- info?: objectoptional
  Metadata about the contract and author
- mintable?: booleanoptional
  Whether privileged accounts will be able to create more supply or emit more tokens
- name: stringrequired
  The name of the contract
- namespacePrefix?: stringoptional
  The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject".
- pausable?: booleanoptional
  Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response.
- permit?: booleanoptional
  Whether without paying gas, token holders will be able to allow third parties to transfer from their account.
- premint?: stringoptional
  The number of tokens to premint for the deployer.
- premintChainId?: stringoptional
  The chain ID of the network on which to premint tokens.
- restrictions?: anyoptional
  Whether to restrict certain users from transferring tokens, either via allowing or blocking them. This feature is experimental, not audited and is subject to change.
- symbol: stringrequired
  The short symbol for the token
- upgradeable?: booleanoptional
  Upgradeability is not available for Stablecoin or RWA.
- votes?: anyoptional
  Whether to keep track of historical balances for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps.
solidity-stablecoinNo outputSchema
Make a stablecoin token that uses the ERC-20 standard. This contract type does not support upgradeability. Experimental, some features are not audited and are subject to change. Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
Input access?: any, burnable?: boolean, callback?: boolean, chainlinkAce?: boolean, crossChainBridging?: any, crossChainLinkAllowOverride?: boolean, decimals?: string, flashmint?: boolean, freezable?: boolean, info?: object, mintable?: boolean, name: string, namespacePrefix?: string, pausable?: boolean, permit?: boolean, premint?: string, premintChainId?: string, restrictions?: any, symbol: string, upgradeable?: boolean, votes?: any
- access?: anyoptional
  The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions.
- burnable?: booleanoptional
  Whether token holders will be able to destroy their tokens
- callback?: booleanoptional
  Whether to include support for code execution after transfers and approvals on recipient contracts in a single transaction.
- chainlinkAce?: booleanoptional
  Chainlink ACE (Automated Compliance Engine) adds token policy enforcement through a separately deployed and configured policy engine (integration guide: [REDACTED URI] Chainlink docs: [REDACTED URI] Defaults to false (disabled). Requires ownable or roles access; combining ACE with CCIP requires roles. This integration does not support ACE together with managed access, Callback (ERC-1363), Flash Minting, a nonzero premint, or bridge modes other than CCIP. Configure policies and register the token with the engine before use; this does not establi
- crossChainBridging?: anyoptional
  Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are custom bridges on any chain, Chainlink CCIP with a separately configured BurnMintTokenPool (integration guide: [REDACTED URI] Chainlink docs: [REDACTED URI] to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. CCIP requires role-based access control, granting the configured pool MINTER_ROLE on each supported chain, and BURNER_ROLE when Burnable
- crossChainLinkAllowOverride?: booleanoptional
  Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native".
- decimals?: stringoptional
  The number of decimals used to represent token amounts. Defaults to 18.
- flashmint?: booleanoptional
  Whether to include built-in flash loans to allow lending tokens without requiring collateral as long as they're returned in the same transaction.
- freezable?: booleanoptional
  Whether authorized accounts can freeze and unfreeze accounts for regulatory or security purposes. This feature is experimental, not audited and is subject to change.
- info?: objectoptional
  Metadata about the contract and author
- mintable?: booleanoptional
  Whether privileged accounts will be able to create more supply or emit more tokens
- name: stringrequired
  The name of the contract
- namespacePrefix?: stringoptional
  The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject".
- pausable?: booleanoptional
  Whether privileged accounts will be able to pause specifically marked functionality. Useful for emergency response.
- permit?: booleanoptional
  Whether without paying gas, token holders will be able to allow third parties to transfer from their account.
- premint?: stringoptional
  The number of tokens to premint for the deployer.
- premintChainId?: stringoptional
  The chain ID of the network on which to premint tokens.
- restrictions?: anyoptional
  Whether to restrict certain users from transferring tokens, either via allowing or blocking them. This feature is experimental, not audited and is subject to change.
- symbol: stringrequired
  The short symbol for the token
- upgradeable?: booleanoptional
  Upgradeability is not available for Stablecoin or RWA.
- votes?: anyoptional
  Whether to keep track of historical balances for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps.

Resources 8

Some details were sanitized for public display.

Solidity Account
Interactive Wizard UI for solidity-account
Solidity Custom
Interactive Wizard UI for solidity-custom
Solidity ERC1155
Interactive Wizard UI for solidity-erc1155
Solidity ERC20
Interactive Wizard UI for solidity-erc20
Solidity ERC721
Interactive Wizard UI for solidity-erc721
Solidity Governor
Interactive Wizard UI for solidity-governor
Solidity RWA
Interactive Wizard UI for solidity-rwa
Solidity Stablecoin
Interactive Wizard UI for solidity-stablecoin