Playbook

Remix + OpenZeppelin Delivery Without Hardhat (Remix Openzeppelin Delivery Without Hardhat)

How the Bare Crypto protocol compiled and deployed in Remix IDE with OpenZeppelin v4.1 GitHub imports — no Hardhat/Foundry — and which ADR trade-offs followed.

Bare Crypto Solidity Marketplace Protocol

Part 1 of 5

BareNFT, reserve escrow, English auction, and NFT-gated BareToken emissions built in Remix IDE with OpenZeppelin v4.1 GitHub imports — no Hardhat/Foundry — covering ADRs, weak RNG, and emergency-power trade-offs.

Bare Crypto Solidity marketplace protocol diagram

Shipping contracts without a local toolchain

The Bare Crypto marketplace protocol was compiled inside Remix IDE by importing OpenZeppelin v4.1.0 contracts via pinned GitHub URLs — without a local Hardhat or Foundry pipeline. That was a deliberate 2021 ADR for a single-operator, high-velocity deploy: speed and version pins won; reproducible CI and typed tests lost.

Remix IDE
  ├─ BareNFT.sol
  ├─ BareNFTReserve.sol
  ├─ BareNFTAuction.sol
  └─ BareToken.sol
        |
        v
https://github.com/OpenZeppelin/.../v4.1.0/...
        |
        v
  injected Web3 / MetaMask deploy

This part locks why Bare Crypto chose a Hardhat-free delivery model and which failure modes that choice exposed.

Concepts, defined where they first appear

📦 Remix IDE
Browser-based Solidity compile-and-deploy surface that needs no local node_modules.

📦 GitHub import pin
Locking OpenZeppelin imports to a v4.1.0 blob URL to prevent version drift.

📦 ADR
Architecture Decision Record: what was chosen, why, and which consequence was accepted.

📦 Reproducible build
Same sources producing the same bytecode across machines — a weak point in Remix.

Remix plus a pinned GitHub import is a conscious trade-off between 'fast enough' and 'CI-correct'; without the pin, every compile can pull a different dependency.

ADR: no Hardhat, Remix instead

Decision: keep protocol contracts in Remix, import OpenZeppelin v4.1.0 from GitHub, deploy through MetaMask. Rationale: small team, single operator, fast iteration. Accepted cost: no automated test suite, coverage, gas reporter, or deterministic artifact archive. Under 'get the marketplace live' pressure, this ADR knowingly deferred CI debt.

Pinned OpenZeppelin surface

BareNFT and BareToken pull ERC721/ERC20/AccessControl/Pausable surfaces from https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.1.0/... paths. The tag pin stops minor drift, but Remix cache and the .deps mirror do not answer 'which bytecode is live?' as clearly as a Hardhat artifact store.

import OZ v4.1.0
  ERC721 + Enumerable + Burnable + Pausable
  AccessControlEnumerable
  SafeMath / IERC20
        |
        v
  Remix .deps/github mirror

Failure: drifting deps and silent forks

If an operator rewrites a blob URL from a tag to master, or Remix recompiles under a different pragma/optimizer setting, you get a fork that looks like the same source but emits different bytecode. The marketplace UI keeps talking to the old ABI while claim/bid calls revert; the incident is blamed on the frontend while the root cause is toolchain discipline. Performance-wise, Remix also re-resolves the large OZ tree on each compile — a slower, more brittle feedback loop than a cached local CI job.

The mappings that get confused most often

❌ Remix is only a toy and never for production
✓ Remix plus pinned OZ can be a valid ADR for a small operator marketplace — if the cost is documented

❌ GitHub imports are automatically safe
✓ Imports without a tag pin are supply-chain drift; locking the v4.1.0 blob is mandatory discipline

❌ Without Hardhat you cannot audit
✓ Audits run on source and bytecode; what you lack is a reproducible pipeline and regression tests

A checklist for auditing your own system

  1. Do your OpenZeppelin import URLs include a version tag such as v4.1.0?
  2. Do two Remix compiles from the same commit yield the same bytecode hash?
  3. Where does the ABI for deployed addresses come from — Remix export or a hand-copied file?
  4. Are compiler version and optimizer settings frozen in an ADR or README?
  5. If a dependency drifts, which marketplace UI symptom appears first, and who notices?

What to take away from this part

  1. Bare Crypto chose Hardhat-free Remix delivery for speed and accepted reproducibility as debt.
  2. The OpenZeppelin v4.1 GitHub pin is the only real version lock without a toolchain.
  3. Bytecode drift shows up as mysterious UI reverts; the root cause is rarely the frontend.

Fast delivery is a feature; an unpinned import is a silent fork factory.

FAQ

Frequently asked questions

What is Remix IDE?

Browser-based Solidity compile-and-deploy surface that needs no local node_modules.

What is GitHub import pin?

Locking OpenZeppelin imports to a v4.1.0 blob URL to prevent version drift.

Is it true that "Remix is only a toy and never for production"?

Remix plus pinned OZ can be a valid ADR for a small operator marketplace — if the cost is documented

What does this part lock in?

This part locks why Bare Crypto chose a Hardhat-free delivery model and which failure modes that choice exposed. The Bare Crypto marketplace protocol was compiled inside Remix IDE by importing OpenZeppelin v4.1.0 contracts via pinned GitHub URLs — without a local Hardhat or Foundry pipeline. That was a deliberate 2021 ADR for a single-operator, high-velocity deploy: speed and version pins won; reproducible CI and typed tests lost.

Engineering Principles Learned

  • Write the toolchain ADR together with team size and the operator trust model.
  • Never production-deploy GitHub imports that are not tag-pinned.
  • Without reproducible bytecode, root-cause analysis of incidents is speculation.

Continue reading

Continue reading

Next in series

Same series

Same series

Paylaş