Relic Forge Home Open Studio CURRENT ARCHITECTURE · ETHEREUM

How Relic Forge Works

Relic Forge separates collection ownership, immutable artwork and recipe data, and mint-stage policy. Forge Reveal uses immediate NFT ownership with automatic verified randomness, sizing the callback budget to each reveal group.

Current environment: Ethereum Mainnet is live for production deployments. Ethereum Sepolia remains available for rehearsals and development. Each network uses its own verified Relic Forge deployment stack.

The 30-second version

Ownership is immediate

Successful collector and creator mints emit ERC-721 Transfer events in the mint transaction. There is no reservation-to-NFT settlement step in the Forge Reveal path.

Randomness is automatic

Forge mints request randomness automatically after ownership is created. Collectors do not return for a second transaction to reveal.

Callback gas is adaptive

Each reveal group uses one of five callback-gas tiers from 400k through 1.4M. Mints above 20 NFTs split into independent groups of at most 20.

Policy is platform-managed

The Forge batch window is fixed at 30 seconds and the maximum randomness cost per request/group is 0.005 ETH for the current release. Creator LaunchConfig fields remain ABI-compatible but are overridden by the Factory defaults.

Contract graph

RelicForgeFactoryV2
  |-- EIP-1167 RelicCollectionV2R2 clone
  |-- EIP-1167 RelicProjectDataV1 clone
  `-- EIP-1167 RelicMintPhasesV2 clone

Shared infrastructure
  |-- RelicRendererV1
  |-- RelicChainlinkVRFV25DirectAdapterV2
  |-- RelicForgeCanonicalRegistryV2
  |-- RelicForgeReserveV2
  `-- RelicForgeFeePolicyV1

ProjectData holds immutable artwork and recipe data. MintPhases owns sale-stage policy. Collection owns ERC-721 state, creator proceeds, reveal state, recipe assignment, and request funding. The Factory binds each clone to the verified shared infrastructure.

Verified Mainnet deployment

Component	Ethereum Mainnet address
Factory	`0x56C9fD8a81F5d0Ce389D04C7e5EA372093930da7`
Collection implementation	`0x0FaD7F74e7f2Db759a9B7e3C01c0D12B52140398`
Randomness adapter	`0x258cf686e3BdDEB02C804739baeDDd521329a59b`
Reserve	`0x9CF57a87DA3D1A594F028Add879207a1598B8DC0`
Canonical registry	`0xC1BE92446E96B09851692aa8682C9bBde9A11e82`

What happens on a Forge mint

MintPhases validates the sale.Stage state, schedule, access proof, wallet cap, price, stage supply, and collection supply are checked.

The NFTs are minted to the recipient.Ownership and Transfer events happen before the randomness request. totalCommitted == totalMinted and pendingSupply() == 0 remain the R2 ownership invariants.

The mint is split into reveal groups.A group contains at most 20 NFTs. A 50-NFT mint therefore requests 20 + 20 + 10.

Each group gets an adaptive callback budget.The Collection selects the tier from group quantity and checks the current quote against the 0.005 ETH platform ceiling.

The adapter requests Chainlink VRF v2.5 direct funding.Adapter overhead is added upstream while the Collection's requested consumer gas stays tied to the quantity tier.

The exact word is recorded, then delivered.The adapter stores the verified word before downstream delivery. Successful delivery assigns unique recipes and completes the group's reveal automatically.

Forge Reveal callback tiers

Reveal group	Consumer callback gas
1 NFT	400,000
2–4 NFTs	550,000
5–10 NFTs	900,000
11–15 NFTs	1,150,000
16–20 NFTs	1,400,000

The adapter adds 250,000 gas of callback overhead to the upstream Chainlink request. It also maintains a delivery reserve so downstream execution is not attempted without enough remaining gas.

Platform randomness policy

Forge batch window	30 seconds · platform managed
Maximum randomness cost / request or group	0.005 ETH · platform managed
Maximum automatic reveal group	20 NFTs
VRF confirmations	3

Creators do not edit the batch window or randomness ceiling in normal Studio controls. The Factory preserves the fields in LaunchConfig for ABI compatibility, but overwrites them with the platform defaults for new R2 collections.

Exact-word replay is recovery, not a reroll

The Chainlink adapter records the verified random word before attempting Collection delivery. If downstream delivery fails, deliveredForLocalRequest remains false but the word remains available. Anyone can call replayFulfillment(localRequestId) to retry delivery of that same stored word. Replay does not request replacement randomness and cannot create a reroll.

Deferred Reveal remains two creator transactions

STEP 1
Prepare

prepareDelayedReveal() freezes exactly the current minted supply and prepares the randomness budget. Minting is frozen for the prepared delayed set.

STEP 2
Request

requestDelayedReveal() spends the prepared budget and requests verified randomness. Callback delivery reveals the frozen set automatically; no third creator reveal transaction is required.

If the collection reveals before sellout, future unsold supply switches to Forge mode. The later Forge pool excludes recipes already consumed by the delayed permutation.

Funding flow

Randomness is quoted against the actual requested callback gas. The Collection uses its reveal hopper first. If the hopper cannot cover an allowed request, the Reserve may provide only the exact bounded shortfall. Actual charge/refund accounting returns unused subsidy rather than trapping hypothetical liability.

The Reserve's 0.20 ETH minimum retention threshold governs founder/platform withdrawals, not whether collections can launch or whether an active reveal may use available Reserve funding.

Creator proceeds

Creator sale proceeds remain separate from reveal funding and accrue to the Collection's creator-proceeds accounting. withdraw() sends withdrawable creator proceeds to the configured payout receiver. Platform/reveal funding is not silently mixed into creator earnings.

What normal users do not need to manage

Normal Studio and collector flows do not expose keeper pools, manual batch locking, manual randomness request buttons, request IDs, replay controls, or settlement controls. Replay exists as a permissionless recovery primitive, but it is not part of the normal mint/reveal experience.

Network boundary

Mainnet: production deployments use the verified Mainnet stack. Sepolia: rehearsals and development use a separate deployment stack. A deployment on one network never replaces or mutates a deployment on another network.

Validation coverage

Adaptive live matrix: 1, 4, 10, 15, 20 and split 50-NFT mint/reveal cases.
Immediate ownership ordering before randomness request.
Automatic adapter delivery and reveal completion.
Unique recipe assignment across the validation set.
Exact-word replay after deliberate automatic-delivery failure, with no replacement randomness and no reroll.

Validation evidence shows that the covered paths behaved as designed; it is not a professional security audit or a guarantee that no vulnerabilities exist.