Smart contracts overview

EBG Tokenizer uses a factory plus per-collection certificate contracts deployed from one blueprint (ERC-5202). Together they implement certificate NFTs with structured onchain metadata and standard ERC-721 behavior.

Security model

• Access control — DEFAULT_ADMIN_ROLE and MINTER_ROLE (OpenZeppelin-style roles) gate administrative and minting actions on the factory.
• Mint cap — A global maximum_mints on the factory limits total mints across all collections; admins can increase the cap.
• Certificate owner — Each collection uses Ownable; the owner can update per-token certificate fields through dedicated functions.
• Permit — EIP-712 typed data supports gasless approvals where the contract allows it.

Standards

Standard	Role
ERC-165	Interface detection
ERC-721	NFTs with metadata, enumerable extension
ERC-3643	Certificate / security-token style identity pattern
ERC-4906	Metadata update events
ERC-5267	EIP-712 domain metadata
ERC-5202	Blueprint-based contract creation

Factory pattern

• One blueprint bytecode is reused for every new collection, reducing deployment overhead.
• The factory keeps a registry of collection addresses by incrementing id.
• A relayer (minter) address is fixed at factory deployment for operational clarity.

Deployment (conceptual)

Operators typically:

1. Deploy the certificate contract as a blueprint.
2. Deploy the factory with the blueprint address and an initial maximum_mints.
3. Use create_certificate / mint_certificate (or the HTTP API) for day-to-day operations.

Constructor arguments and tooling depend on your deployment pipeline; this documentation focuses on behavior and integration.

Related pages

• Factory contract — Entry points, registry, events.
• Certificate contract — ERC-721 surface and updates.
• Certificate data model — Struct fields shared by chain and API.