Every time you mint an NFT, you are calling a smart contract. Every time you list a work for sale, accept a bid, or approve a marketplace to move your tokens, you are interacting with code that someone else wrote and deployed permanently on a blockchain. Yet most artists have never read a single line of that code.
This guide exists to change that. Not by turning you into a developer, but by giving you enough understanding to ask the right questions, spot the red flags, and protect your work. We will walk through four blockchains, from the pioneer (Ethereum) to the unexpected canvas (Bitcoin), examining how each one handles the concept of executable code on-chain.
No prior programming knowledge is required. Every technical concept is explained with plain language, diagrams, and real cases from the crypto art world.
What Is a Smart Contract, Really?
Before the blockchain, before Ethereum, before Solidity, the idea already existed. Understanding its origin reveals what it was supposed to be, and what it became.
The Idea (1994)
In 1994, computer scientist Nick Szabo proposed the concept of a "smart contract": a piece of software that automatically enforces the terms of an agreement, the same way a vending machine enforces the rule "insert coin, receive product" without needing a shopkeeper.
Szabo's vision was simple: if two parties agree on conditions, and those conditions can be verified by a machine, then the machine can execute the agreement without a trusted intermediary. No lawyer, no escrow agent, no bank.
The Reality (2015 onward)
When Ethereum launched in 2015, it gave Szabo's idea its first real home. A smart contract on Ethereum is a program stored at a specific address on the blockchain. Once deployed, nobody can modify it (with some important exceptions we will examine in Chapter 12). It runs exactly as written, every time, for anyone who calls it.
But "smart" is a generous word. A smart contract is not intelligent. It does not reason, adapt, or learn. It is a deterministic machine: given the same input, it always produces the same output. It is "smart" only in the sense that it executes automatically. A better name might be "self-executing agreement" or "autonomous program."
A smart contract is to a traditional legal contract what a player piano roll is to a sheet of music. The sheet of music requires a performer to interpret it. The piano roll executes mechanically, exactly as encoded, with no room for interpretation. The advantages (precision, automation, trustlessness) are also the dangers (rigidity, irreversibility, no judgment).
What Makes It Different from a Regular Program?
A regular program runs on someone's server. That someone can turn it off, modify it, or deny you access. A smart contract, once deployed, runs on every node of the network simultaneously. No single entity can stop it, alter it, or censor it. This is the core value proposition: code that nobody controls but everybody can verify.
Of course, "nobody controls" comes with caveats. The deployer chose what the code does. The deployer chose who has special permissions. And as we will see, some contracts are designed to be upgradeable, meaning someone does retain control. But the promise, the ideal, is radical: a program that serves its users without a master.
Anatomy of a Contract
Every smart contract, regardless of the blockchain it lives on, has the same basic components. Understanding them is like understanding the parts of a cell before studying biology.
State: The Memory
A contract has persistent storage, data that survives between calls. For an NFT contract, the state includes: who owns each token, the total number of tokens minted, the base URI pointing to the metadata, and any special permissions (who can mint, who can pause the contract).
This state lives directly on the blockchain. Modifying it costs gas (on Ethereum) or rent (on Solana), because every node in the network must store this data forever.
Functions: The Actions
Functions are the operations a contract can perform. They come in two flavors:
- Read functions (free): These only look at the state without changing it. Example: "Who owns token #42?" or "How many tokens exist?" They cost nothing to call because they do not modify the blockchain.
- Write functions (cost gas): These modify the state. Example: "Mint a new token," "Transfer token #42 to Alice," or "Set a new base URI." They require a transaction, a fee, and confirmation from the network.
Events: The Announcements
When something important happens inside a contract, it can emit an event: a log entry that external applications can listen for. When you mint an NFT and your wallet immediately shows it, that is because the wallet was listening for a Transfer event from the contract.
The Constructor: Birth and Death
The constructor is special code that runs exactly once, at the moment the contract is deployed. It sets the initial state: the name of the collection, the symbol, the owner's address, and any other configuration. After deployment, the constructor can never run again.
Persistent data | Read (free) + Write (gas) | Logs for external apps
Modifiers and Access Control
Not every function should be callable by everyone. Modifiers are rules that gate access. The most common is onlyOwner, which restricts a function to the deployer's address. Others include role-based access (only the "minter" role can mint) and time-based locks (this function cannot be called until block 10,000,000).
When you read a contract and see an onlyOwner modifier on a critical function like setBaseURI, it means the deployer can change where the metadata points. That is power. Whether it is benign or dangerous depends on who holds it and what they intend.
The Virtual Machine: Where Code Lives
Smart contracts do not run on your computer or on a company's server. They run inside a virtual machine replicated across thousands of nodes. Understanding this machine is understanding the stage on which your art performs.
What Is a Virtual Machine?
A virtual machine (VM) is an isolated computing environment. Think of it as a sandbox: programs can run inside it, but they cannot reach outside to touch files, the internet, or other programs. This isolation is critical for security. A malicious contract cannot access your hard drive, your camera, or your bank account. It can only do what the blockchain protocol allows.
The EVM (Ethereum Virtual Machine)
The EVM is the most influential virtual machine in blockchain history. Every Ethereum node runs a copy of the EVM, and every copy processes every transaction identically. The EVM is stack-based, meaning it processes data by pushing and popping values from a stack, one operation at a time.
When you deploy a Solidity contract, the compiler translates it into bytecode: a sequence of low-level instructions called opcodes. Each opcode has a fixed gas cost. ADD (addition) costs 3 gas. SSTORE (writing to storage) costs 20,000 gas for a new slot. The total gas consumed by a transaction determines its fee.
The EVM has approximately 140 opcodes. Some are arithmetic (ADD, MUL, SUB), some manage memory (MLOAD, MSTORE), some interact with the blockchain (BALANCE, BLOCKHASH), and some control execution flow (JUMP, JUMPI). No opcode accesses the internet or any external system. This is by design.
Solana: The Sealevel Runtime
Solana does not use the EVM. It runs its own runtime called Sealevel, which can process thousands of transactions in parallel. Where the EVM processes one transaction at a time, Sealevel looks at which accounts each transaction touches and runs non-conflicting transactions simultaneously.
On Solana, smart contracts are called "programs" and they are compiled to BPF (Berkeley Packet Filter) bytecode. A key architectural difference: on Solana, programs are stateless. They do not store data inside themselves. Instead, they read from and write to separate "accounts" that hold the data. This separation of logic and storage is what enables parallelism.
Tezos: The Michelson VM
Tezos runs its own stack-based virtual machine designed for formal verification: the mathematical proof that a program does exactly what it claims. Contracts are compiled down to Michelson, a low-level language where every operation is explicit and verifiable. This is the mathematician's blockchain. The emphasis is not on speed but on correctness.
Bitcoin: No Virtual Machine (Almost)
Bitcoin was never designed to run smart contracts. Its scripting language, Bitcoin Script, is intentionally limited: it is not Turing-complete, meaning it cannot loop or perform arbitrary computation. This was a deliberate choice for security and simplicity.
Yet Bitcoin has evolved. The Taproot upgrade (November 2021) expanded what Script can do, and protocols like Ordinals and Runes have found creative ways to inscribe data and define tokens on Bitcoin. We will explore this in depth in Chapter 8.
| Chain | VM / Runtime | Language | Turing-complete? | Parallelism |
|---|---|---|---|---|
| Ethereum | EVM | Solidity, Vyper | Yes | Sequential |
| Solana | Sealevel (BPF) | Rust, Anchor | Yes | Parallel |
| Tezos | Michelson VM | SmartPy, LIGO | Yes | Sequential |
| Bitcoin | Script interpreter | Bitcoin Script | No | N/A |
From Idea to Blockchain: The Life Cycle
A smart contract goes through distinct phases, from conception to permanent deployment. Each phase has implications for the artist.
Phase 1: Writing
Someone (a developer, a platform, or increasingly an AI tool) writes the contract's source code. For an NFT collection, this typically means defining: what happens when someone mints, how transfers work, what royalty information is attached, and who has administrative privileges.
Most artists never write their own contracts. They use platforms (Foundation, SuperRare, objkt, Manifold) that deploy pre-written, audited contracts on their behalf. This is practical, but it means you are trusting that platform's code with your art.
Phase 2: Compiling
The human-readable source code is translated into bytecode that the virtual machine can execute. This step is automatic and handled by a compiler (solc for Solidity, cargo for Rust/Solana, SmartPy compiler for Tezos).
Phase 3: Deploying
The compiled bytecode is sent to the blockchain in a special transaction. This transaction costs gas (or the chain's equivalent fee). Once confirmed, the contract exists at a specific address, forever. On Ethereum, this address is derived from the deployer's address and their transaction count (nonce).
Human-readable | Translation | Machine-readable | Lives on-chain forever
Phase 4: Verification
After deployment, the source code can be published on a block explorer (Etherscan, Solscan, TzKT) so anyone can verify that the bytecode on-chain matches the published source. This is called "verification." An unverified contract is a red flag. It means you cannot read what the code actually does.
Phase 5: Interaction
Users (and other contracts) interact with the deployed contract by sending transactions that call its functions. Every interaction is public, permanent, and auditable. When you mint an NFT on Foundation, your wallet sends a transaction to Foundation's contract calling the mint function with your parameters.
Deployment is irreversible. If the contract has a bug, it cannot be patched. If it has a vulnerability, it cannot be fixed. The only options are: deploy a new contract and migrate (expensive, disruptive), use an upgrade pattern if it was built in from the start (see Chapter 12), or abandon the contract entirely. This is why auditing matters.
Ethereum: The Pioneer
Ethereum invented the concept of a general-purpose blockchain. Everything that followed, from DeFi to NFTs to DAOs, was built on the foundation it laid.
Solidity: The Lingua Franca
Solidity is the dominant language for Ethereum smart contracts. Created by Gavin Wood in 2014, its syntax resembles JavaScript, making it accessible to web developers. A basic NFT contract in Solidity defines a mapping from token IDs to owner addresses, a mint function that creates new tokens, and a transfer function that moves tokens between addresses.
But accessibility is a double-edged sword. Because Solidity looks simple, developers sometimes underestimate its subtleties. Many of the worst exploits in blockchain history came from Solidity code that looked correct but contained a hidden flaw.
The EVM's Guarantees
When you call a function on an Ethereum contract, every node in the network executes the same code with the same inputs and arrives at the same result. If they disagree, the network rejects the outlier. This is consensus. It means you do not need to trust any single node; you trust the mathematics of agreement.
Gas and Computation Costs
Every operation in the EVM costs gas. Simple operations (addition, comparison) cost 3-5 gas. Storage operations cost thousands. A standard NFT mint costs roughly 50,000-150,000 gas units, depending on the contract's complexity. Multiply by the current gas price (in gwei) and the ETH price to get the dollar cost.
FUNCTION mint(recipient, tokenURI):
require(caller == owner OR caller == minter)
require(totalSupply < maxSupply)
newTokenId = totalSupply + 1
ownerOf[newTokenId] = recipient
tokenURIs[newTokenId] = tokenURI
totalSupply = totalSupply + 1
EMIT Transfer(address(0), recipient, newTokenId)
RETURN newTokenId
Vyper: The Alternative
Vyper is Ethereum's second language, designed to be simpler and more auditable than Solidity. It intentionally lacks features that Solidity has (like inheritance and operator overloading) to make contracts easier to read and verify. Some security-conscious projects prefer Vyper precisely because it has fewer places for bugs to hide.
EVM Compatibility: The Empire Expands
The EVM's influence extends far beyond Ethereum. Chains like Polygon, Arbitrum, Optimism, Base, Avalanche, and BNB Chain all run EVM-compatible virtual machines. A contract written for Ethereum can be deployed on any of these chains with minimal or no changes. This is why Solidity is the most commercially important smart contract language in the world.
Solana: The Speed Machine
Where Ethereum prioritizes decentralization and security, Solana optimizes for speed and cost. For artists minting large collections, this trade-off matters.
Programs, Not Contracts
On Solana, smart contracts are called "programs." This is not just branding: it reflects a fundamentally different architecture. A Solana program is stateless. It contains only logic, not data. All data is stored in separate "accounts" that the program reads from and writes to.
Think of it this way: on Ethereum, a contract is like a store that keeps its own inventory in the back room. On Solana, a program is like a cashier who checks a separate warehouse for inventory every time a customer asks. The cashier (program) has no memory of previous transactions; they just follow the rules and update the warehouse (accounts).
The Account Model
Everything on Solana is an account. Your wallet is an account. An NFT is an account. The metadata of that NFT is a separate account. The collection it belongs to is another account. This model is more granular than Ethereum's, and it enables parallel processing: if two transactions touch different accounts, they can execute simultaneously.
Program (Logic) → Account B (Metadata)
Program (Logic) → Account C (Collection)
Same program, different data accounts = parallel execution
Rust and the Anchor Framework
Solana programs are written in Rust, a language known for memory safety and performance but also for its steep learning curve. The Anchor framework simplifies development by providing macros and abstractions that handle much of the boilerplate. Most NFT-related programs on Solana are built with Anchor.
Metaplex: The NFT Infrastructure
Metaplex is to Solana NFTs what OpenZeppelin is to Ethereum: the standard library. It provides programs for minting, metadata management, auctions, and storefronts. The two key Metaplex programs for artists are:
- Token Metadata Program: Attaches metadata (name, symbol, URI, royalty info) to any Solana token.
- Bubblegum (v2): Enables "compressed NFTs" using Merkle trees, reducing minting cost by orders of magnitude. A collection of one million NFTs can be minted for a few SOL instead of thousands.
Metaplex Core: The Next Generation
Metaplex Core is a newer standard that uses a single-account design, reducing minting costs by over 80% compared to the original Token Metadata approach. It also provides enforced royalties at the protocol level, a flexible plugin system for custom behaviors, and native support for collections and editions.
Solana's low fees make it attractive for large editions and open editions. Compressed NFTs through Bubblegum v2 make it possible to distribute art to thousands of collectors for pennies. The trade-off: Solana has experienced several network outages, and its validator hardware requirements are significantly higher than Ethereum's, concentrating validation power among fewer, wealthier operators.
Rent and Account Lifetime
On Solana, storing data costs "rent" paid in SOL. Accounts must maintain a minimum balance (the "rent-exempt" threshold) or they will be purged by the network. For an NFT, the rent-exempt cost is typically around 0.002 SOL. This is a one-time deposit that is recoverable if the account is closed.
Tezos: The Mathematician's Chain
Tezos was built with a different philosophy: correctness over speed, governance over disruption. For a blockchain that hosts art, this matters more than you might think.
Formal Verification: Proof, Not Hope
The defining feature of Tezos smart contracts is their affinity for formal verification: the mathematical proof that a program behaves exactly as specified. While formal verification is possible on any chain, Tezos was designed from the ground up to make it practical. Its low-level language, Michelson, is stack-based and deterministic, making it amenable to automated proof tools.
Why does this matter for artists? Because a formally verified contract is one where you do not need to trust the developer's intentions or hope they made no mistakes. The mathematics guarantee it.
Michelson, SmartPy, and LIGO
Nobody writes Michelson by hand (well, almost nobody). Artists and developers use higher-level languages that compile down to Michelson:
- SmartPy: Python-like syntax, popular in the art community, used by platforms like objkt.com.
- LIGO: Offers multiple syntax flavors (CameLIGO resembles OCaml, JsLIGO resembles TypeScript). Used for complex DeFi and governance contracts.
FA2: The Multi-Asset Standard
Where Ethereum separates NFTs (ERC-721) from semi-fungible tokens (ERC-1155), Tezos unifies everything under FA2 (TZIP-12). A single FA2 contract can handle fungible tokens, non-fungible tokens, and multi-editions in one deployment. This is elegant and efficient: one contract, one interface, multiple asset types.
Tezos was the first major chain to use proof-of-stake from genesis, and its energy consumption is a fraction of Ethereum's pre-Merge levels. During the 2021-2022 NFT boom, many environmentally conscious artists chose Tezos specifically for this reason. Platforms like Hic et Nunc (now Teia) and objkt.com became cultural hubs for crypto art, creating one of the most vibrant artist communities in the ecosystem.
On-Chain Governance and Upgrades
Tezos has a unique self-amendment mechanism: the protocol itself can be upgraded through on-chain voting by bakers (Tezos validators). This means the blockchain evolves without hard forks. For smart contracts, this is significant: the rules of the virtual machine can change, but they change through democratic consensus, not corporate fiat.
Etherlink: The EVM Bridge
Recognizing the dominance of the EVM ecosystem, Tezos launched Etherlink, an EVM-compatible Layer 2 built on Smart Rollups. This means Solidity developers can deploy their Ethereum contracts on Tezos infrastructure, benefiting from its security model while maintaining compatibility with the EVM tooling ecosystem. Rarible has already added Etherlink support for NFT drops and trading.
Smart Rollups: Scaling Without Compromise
Tezos Smart Rollups are enshrined in the protocol (not a third-party add-on). They allow off-chain computation with on-chain verification, dramatically increasing throughput. The long-term target is ambitious: one million transactions per second on the rollup layer. For artists, this means large-scale generative projects and open editions become economically viable on Tezos without sacrificing the chain's correctness guarantees.
Bitcoin: The Unexpected Canvas
Bitcoin was never designed for art. It was designed to move value, period. And yet, through a combination of ingenuity and stubbornness, artists found a way in.
Bitcoin Script: The Intentional Limitation
Bitcoin's scripting language is deliberately limited. It cannot loop, it cannot store complex state, and it cannot call other scripts. Satoshi Nakamoto designed it this way to minimize the attack surface: a simpler language means fewer ways for things to go wrong.
Bitcoin Script handles conditions like "this transaction can only be spent if signature A and signature B are both provided" (multi-signature) or "this transaction cannot be spent until block height 800,000" (time-locks). Useful for financial logic, but far from what you need for NFTs.
The Taproot Upgrade (November 2021)
Taproot expanded what Bitcoin Script could do by introducing Schnorr signatures and a new script type called Tapscript. Critically, it made it economically viable to embed larger amounts of data in Bitcoin transactions. This opened the door.
Ordinals: Every Satoshi Gets a Name
In January 2023, developer Casey Rodarmor launched the Ordinals protocol, which assigns a sequential number to every satoshi (the smallest unit of Bitcoin, 1 BTC = 100,000,000 satoshis). This "ordinal number" turns each satoshi into a unique, identifiable entity.
Inscriptions take this further: you can attach data (an image, a text, an HTML page, even a program) directly to a specific satoshi. This data is stored in the witness section of a Bitcoin transaction and lives on the Bitcoin blockchain permanently. No IPFS, no Arweave, no external storage. The art is literally on Bitcoin.
By January 2026, over 107 million inscriptions had been created on Bitcoin. This is not a niche experiment; it is a cultural movement.
Runes: Fungible Tokens on Bitcoin
Also created by Casey Rodarmor, Runes (launched April 2024) enables fungible tokens natively on Bitcoin. Unlike BRC-20 (an earlier, less efficient standard), Runes uses Bitcoin's UTXO model directly, creating less blockchain bloat. For artists, Runes could enable editions, memberships, or community tokens without leaving Bitcoin.
Alkanes: Smart Contracts Come to Bitcoin
The newest development is Alkanes, a metaprotocol that brings WASM-based smart contracts to Bitcoin's base layer. Unlike Ethereum-style smart contracts, Alkanes operates without bridges or external execution layers. Developers can build applications and launch tokens natively on Bitcoin with programmable logic. This is still early, but it represents the most ambitious attempt to bring general computation to the Bitcoin base layer.
The Cultural Divide
Not everyone in the Bitcoin community welcomes these developments. Bitcoin maximalists argue that inscriptions bloat the blockchain and distract from Bitcoin's mission as sound money. Supporters counter that the security and permanence of the Bitcoin network make it the ultimate canvas for digital art. As an artist, you should know that this debate exists and that it occasionally affects technical decisions (some miners have discussed filtering inscription transactions).
In late February 2026, Magic Eden announced it would shut down support for Bitcoin Ordinals, Runes, and EVM NFTs. Trading ended March 9, and APIs went offline March 27. The lesson: marketplaces are intermediaries. Even on Bitcoin, where the data is permanent, the infrastructure around it is not.
Token Standards: The Language of Digital Art
Token standards define how digital assets behave: how they are created, transferred, and queried. They are the grammar of on-chain art.
ERC-721: The Original NFT
Proposed in January 2018, ERC-721 defined what we now call an NFT: a token where each unit is unique and non-interchangeable. The standard specifies: every token has a unique ID within its contract, every token has exactly one owner, tokens can be transferred, and ownership is queryable.
CryptoKitties (2017) was the catalyst, but ERC-721 formalized the pattern. Every NFT you have ever minted on Ethereum, Polygon, Arbitrum, or any EVM chain uses ERC-721 or its successor.
ERC-1155: The Multi-Token
Created by the Enjin team, ERC-1155 allows a single contract to manage both fungible and non-fungible tokens. You can have unique 1/1 pieces alongside editions of 100 in the same contract. Batch operations (mint 50 tokens in one transaction) reduce gas costs dramatically.
| Standard | Chain | Unique Tokens | Editions | Batch Ops | Royalty Info |
|---|---|---|---|---|---|
| ERC-721 | EVM chains | Yes | No (workaround needed) | No | Via ERC-2981 |
| ERC-1155 | EVM chains | Yes | Yes (native) | Yes | Via ERC-2981 |
| FA2 (TZIP-12) | Tezos | Yes | Yes (native) | Yes | Via TZIP-16 |
| Metaplex Core | Solana | Yes | Yes (native) | Yes | Enforced |
| Ordinals | Bitcoin | Yes | No | No | None |
FA2 on Tezos
FA2 is the unified standard. One contract, one interface, any token type. This simplicity has practical benefits: wallets, marketplaces, and indexers only need to support one standard, reducing integration complexity and bugs.
Metaplex Standards on Solana
Solana has iterated through multiple NFT standards. The original Token Metadata program required multiple accounts per NFT. Metaplex Core consolidated this into a single-account design with enforced royalties and a plugin architecture. Compressed NFTs (Bubblegum) added a third option for high-volume, low-cost minting using Merkle trees.
Ordinals: No Standard, Just Data
Bitcoin Ordinals do not follow a "token standard" in the traditional sense. There is no smart contract defining transfer logic. Ownership is determined by which satoshi the inscription is attached to, and transfers follow Bitcoin's native UTXO model. This is radically simple but also means there are no on-chain royalties, no approval mechanisms, and no programmable behavior after inscription.
What Really Happens When You Mint
The "mint" button hides an extraordinary sequence of events. Here is what actually happens, step by step, on each chain.
On Ethereum
When you click "Mint" on a platform like Foundation or SuperRare:
- Your wallet constructs a transaction calling the contract's
mintfunction, passing your address and the token's metadata URI. - You sign the transaction with your private key and submit it to the network (via an RPC endpoint, as covered in The Wallet Bible).
- The transaction enters the mempool, where it waits for a validator to include it in a block.
- A validator picks up your transaction, the EVM executes the
mintfunction: it checks that minting is allowed, assigns a new token ID, maps that ID to your address in the contract's storage, and records the metadata URI. - The contract emits a
Transferevent from address(0) (the zero address, signifying creation) to your address. - The block is finalized. The NFT now exists permanently on Ethereum.
- Indexers (like the ones OpenSea and Rarible use) detect the
Transferevent and update their databases. Your NFT appears in your profile.
Click → Sign → Broadcast → Wait → Execute → Finalize
On Solana
The process is similar in purpose but different in mechanics. When you mint on Exchange Art or Tensor:
- Your wallet constructs a transaction that invokes the Metaplex Token Metadata program (or Metaplex Core program).
- The transaction specifies which accounts to create or modify: the mint account, the metadata account, and your token account.
- A validator processes the transaction. Because Solana programs are stateless, the runtime passes the relevant accounts to the program, which verifies conditions and writes data.
- Finality is achieved in approximately 400 milliseconds. The NFT exists.
On Tezos
On objkt.com or Teia:
- Your wallet constructs an operation calling the FA2 contract's
mintentrypoint. - The operation is signed and broadcast. A baker includes it in a block.
- The Michelson VM executes the contract. The big map (Tezos's efficient key-value storage) is updated with the new token's data.
- Finality takes approximately 30 seconds (one block).
On Bitcoin
Inscriptions work differently because there is no smart contract:
- You prepare the data (image, text, HTML) and encode it into a Bitcoin transaction's witness data using the Ordinals protocol.
- The transaction is broadcast. A miner includes it in a block.
- The inscription is permanently embedded in the Bitcoin blockchain. The ordinal number of the satoshi it is attached to becomes its identifier.
- There is no "contract" to call, no "mint function" to invoke. The inscription is the artifact itself.
Ethereum: ~12 seconds per block. Solana: ~400 milliseconds. Tezos: ~30 seconds. Bitcoin: ~10 minutes. These times matter when you are minting during a high-demand drop. On Ethereum, gas prices spike as everyone competes for block space. On Solana, the speed advantage can become a disadvantage when the network is congested and transactions are dropped.
Royalties: The Broken Promise
Creator royalties were supposed to be the revolution: artists earning from every secondary sale, automatically, forever. The reality is more complicated.
The Dream
The pitch was irresistible: mint an NFT with a 10% royalty, and every time it changes hands on the secondary market, 10% of the sale price flows back to you automatically. No agents, no contracts to renegotiate, no reliance on anyone's goodwill. The smart contract enforces it.
Except it does not.
ERC-2981: A Signal, Not a Law
ERC-2981 is the Ethereum standard for royalty information. It defines a function called royaltyInfo that any marketplace can call to ask: "For this token, who should receive royalties, and how much?" The contract responds with an address and a percentage.
But here is the critical point: ERC-2981 cannot enforce payment. It is a signal, a suggestion. The standard itself says so. The marketplace is free to call royaltyInfo, read the answer, and then ignore it entirely. And increasingly, that is exactly what happens.
The Race to Zero
In 2023, the marketplace wars began. Blur launched with optional royalties, attracting traders who preferred not to pay creator fees. OpenSea responded by introducing its Operator Filter Registry, which let creators block their NFTs from being traded on marketplaces that did not honor royalties. But this created friction and fragmentation.
By late 2023, OpenSea dismantled the Operator Filter. The "race to zero" accelerated. In 2026, the landscape has settled into an uncomfortable equilibrium: some marketplaces honor royalties voluntarily (SuperRare, Foundation), some make them optional (OpenSea, Blur), and some ignore them entirely.
On Ethereum and most EVM chains, royalties are not enforceable at the protocol level. They depend on marketplace compliance. If a buyer transfers an NFT directly to another wallet (a peer-to-peer transfer), no royalty is triggered at all, because the transfer function in ERC-721 has no concept of payment.
Where Royalties Are Enforced
Metaplex Core on Solana is the notable exception. It enforces royalties at the program level. Transfers that do not respect royalty rules are rejected by the program itself, not by marketplace policy. This is a genuine technical advantage for artists who want guaranteed secondary income.
Tezos marketplaces (objkt.com, Teia) have generally maintained royalty enforcement, partly because the community culture values creator compensation and partly because the FA2 standard's flexibility allows tighter integration between transfer logic and payment.
Bitcoin Ordinals have no on-chain royalty mechanism whatsoever. Inscriptions follow Bitcoin's native transfer logic, and there is no way to programmatically attach a royalty requirement.
What Can an Artist Do?
Choose your chain and platform deliberately. If secondary royalties are critical to your economic model, Solana with Metaplex Core offers the strongest guarantee. On Ethereum, consider platforms like Manifold that give you your own contract, and accept that enforcement depends on marketplace cooperation. On Bitcoin, build your economic model on primary sales and collector relationships, not royalties.
| Chain | Royalty Standard | Enforcement Level |
|---|---|---|
| Ethereum / EVM | ERC-2981 | Voluntary (marketplace decides) |
| Solana (Metaplex Core) | Built-in | Protocol-enforced |
| Tezos | TZIP-16 / Platform | Marketplace-enforced (strong culture) |
| Bitcoin | None | None |
Upgradeable Contracts: The Mutable Immutable
Smart contracts are supposed to be immutable. But some of the most important contracts in the ecosystem can be changed after deployment. Understanding how, and the risks, is essential.
The Proxy Pattern
The most common upgrade mechanism uses a two-contract system. The first contract (the "proxy") stores all the data and receives all user calls. The second contract (the "implementation") contains the actual logic. When you call the proxy, it forwards your call to the implementation contract.
The upgrade works by changing which implementation the proxy points to. The data stays in the proxy (unchanged), but the logic that operates on that data is replaced. From the user's perspective, the contract address does not change. But the code behind it does.
After upgrade:
User → Proxy (same data + same address) → Implementation v2
Why Contracts Are Made Upgradeable
Legitimate reasons include: fixing bugs discovered after deployment, adding features requested by the community, complying with changing regulations, and optimizing gas costs. OpenZeppelin, the most widely used smart contract library, provides a standardized upgrade framework used by thousands of projects.
The Risks for Artists
An upgradeable contract means someone retains the power to change the rules after deployment. This is the antithesis of the "code is law" promise. Specific risks include:
- Metadata manipulation: The contract owner could change where token metadata points, effectively replacing your art with something else.
- Transfer restrictions: A malicious upgrade could freeze transfers, preventing you from selling or moving your tokens.
- Royalty changes: Royalty percentages or recipient addresses could be altered.
- Rug pull: In the worst case, an upgrade could drain all value from the contract.
If a contract is upgradeable and the upgrade key is held by a single address (not a multi-sig, not a DAO, not a time-locked mechanism), that single address has absolute power over the contract. One compromised key, one bad actor, one moment of weakness, and everything changes. When evaluating an NFT project, always ask: who controls the upgrade key?
Mitigations
Responsible projects use several mechanisms to make upgrades safer: time-locks (upgrades are announced days or weeks in advance, giving users time to exit), multi-signature wallets (multiple parties must approve an upgrade), governance votes (the community decides), and upgrade renunciation (the ability to permanently disable upgrades once the contract is stable).
Solana's Approach
On Solana, programs are upgradeable by default. The deployer retains an "upgrade authority" that can deploy new code to the same program address. To make a program immutable, the deployer must explicitly revoke this authority. Always check whether a Solana program's upgrade authority has been revoked if immutability matters to you.
Approvals and Permissions: The Keys You Lend
Every time you interact with a marketplace, you grant permissions. Understanding what you are granting, and to whom, is perhaps the most practically important chapter in this guide.
How Approvals Work on Ethereum
When you list an NFT for sale on OpenSea, the marketplace needs permission to transfer that NFT on your behalf when a buyer appears. You grant this permission through an "approval" transaction. There are two types:
approve(address, tokenId): Grants permission for one specific token. Safer, but requires a separate transaction for each listing.setApprovalForAll(address, true): Grants permission for every token you own in that contract. Convenient (one transaction covers all listings), but dangerous: if the approved address is compromised or malicious, every token is at risk.
The Unlimited Approval Problem
For ERC-20 tokens (fungible tokens like WETH or USDC), the situation is even more treacherous. When you approve a DeFi protocol or marketplace to spend your tokens, you often approve an "unlimited" amount. This means the approved contract can move any amount of that token from your wallet, at any time, without further confirmation.
If that contract is later exploited, the attacker inherits all your unlimited approvals. This is not theoretical: billions of dollars have been lost through approval-based exploits.
Regularly review and revoke old approvals. Tools like revoke.cash and Etherscan's Token Approval Checker let you see every contract you have approved and revoke those you no longer use. This is basic hygiene, like changing passwords. Do it at least monthly.
Solana Permissions
Solana uses a different model. Token accounts have a "delegate" field that can be set to allow another address to transfer or burn the token. Importantly, delegations on Solana are typically limited to a specific amount, making unlimited approvals less common. However, the concept remains: granting delegation means trusting another program with your assets.
Tezos Operators
In the FA2 standard, the equivalent concept is "operators." You add an operator address for a specific token type, and that operator can transfer tokens on your behalf. The pattern is similar to Ethereum's setApprovalForAll, but the Tezos community's smaller, more curated marketplace ecosystem means fewer unknown contracts requesting permissions.
The Signature Trap
Not all permissions require on-chain transactions. Some marketplaces use off-chain signatures (EIP-712 typed data) to create listings. You sign a message with your wallet, and the marketplace holds that signature until a buyer appears. The danger: phishing sites can present legitimate-looking signature requests that actually authorize asset transfers. Always read what you are signing. If your wallet shows a request to sign a "SetApprovalForAll" or an unfamiliar contract interaction disguised as a signature, reject it.
Reading a Contract: Self-Defense for Artists
You do not need to be a developer to read a smart contract. You need to know where to look and what to look for.
Step 1: Find the Contract
Every NFT lives in a contract at a specific address. On Ethereum, go to the NFT's page on any marketplace, find the "Contract Address" link, and follow it to Etherscan. On Solana, use Solscan or Solana Explorer. On Tezos, use TzKT or Better Call Dev.
Step 2: Check Verification
On Etherscan, look for the green checkmark next to "Contract" in the navigation tabs. If the source code is verified, you can read it. If it is not verified, you can only see the raw bytecode, which is unreadable to humans. An unverified contract is a warning sign.
Step 3: Look for Red Flags
You do not need to understand every line. Focus on these critical elements:
- Owner-only functions: Search for
onlyOwneroronlyRole. What can the owner do? Can they pause transfers? Change metadata? Withdraw funds? - Withdrawal functions: Does the contract hold ETH? Who can withdraw it? A function like
withdraw()withonlyOwneris normal for a mint contract (the artist collects proceeds). But if the withdrawal function is missing or points to an unfamiliar address, that is suspicious. - setBaseURI or setTokenURI: Can the metadata be changed after minting? If so, your art could theoretically be replaced.
- Proxy patterns: If the contract looks too simple (just a few lines), it might be a proxy. Check if it delegates calls to another contract.
- Hidden minting: Can the owner mint tokens to themselves without paying? Look for mint functions that bypass the public minting rules.
On Etherscan, go to the "Read Contract" tab. Call owner() to see who controls the contract. Then check that address: is it a regular wallet, a multi-sig (like a Safe/Gnosis Safe), or a well-known platform address? A multi-sig is a good sign. A random wallet is a risk.
Step 4: Check the Transaction History
Etherscan shows every transaction ever sent to the contract. Look at: how many unique addresses have interacted (more is generally better), whether the owner has called any administrative functions recently, and whether there are any failed transactions that might indicate bugs or exploits.
Tools for Non-Developers
Several tools can help you understand contracts without reading code: Bubblemaps visualizes token distribution and wallet connections. DethCode provides a VS Code-like interface for reading Etherscan contracts. Tenderly lets you simulate transactions before executing them. Token Sniffer analyzes token contracts for common scam patterns.
Security: Exploits, Rugs, and Red Flags
Billions of dollars have been lost to smart contract vulnerabilities. As an artist, your work and your collectors' trust are on the line. Knowing the common attacks is knowing how to avoid them.
Reentrancy: The Classic
Reentrancy is the oldest and most infamous smart contract vulnerability. It occurs when a contract sends ETH to an external address before updating its own state. The receiving address can be a malicious contract that, upon receiving ETH, immediately calls back into the sending contract and triggers another payment, over and over, before the original transaction completes.
FUNCTION withdraw():
amount = balances[caller]
SEND amount TO caller // external call BEFORE state update
balances[caller] = 0 // too late: attacker re-entered above
FUNCTION withdraw():
amount = balances[caller]
balances[caller] = 0 // state update FIRST
SEND amount TO caller // external call AFTER (safe)
The fix is simple in principle: always update state before making external calls. This pattern is called "checks-effects-interactions." In 2025, reentrancy attacks still caused $35.7 million in losses. In 2026, they remain in the OWASP Smart Contract Top 10.
Access Control Failures
When critical functions lack proper access restrictions, anyone can call them. Imagine a mint function without an onlyOwner modifier that was supposed to be admin-only: anyone could mint unlimited tokens. Or a setRoyaltyRecipient function that anyone can call to redirect royalties to their own address.
Oracle Manipulation
Smart contracts cannot access external data directly. They rely on "oracles" (services like Chainlink) for price feeds and off-chain information. If an attacker can manipulate the oracle's data, they can trick the contract into making decisions based on false information. This is especially relevant in DeFi but can affect NFT pricing mechanisms.
The Rug Pull Anatomy
A rug pull typically follows this pattern: a project launches with attractive art and marketing, the contract collects mint proceeds, and then one of several things happens: the team withdraws all funds and disappears, the metadata URIs are changed to point to blank or worthless images, or the contract is upgraded (via proxy) to disable transfers, trapping collectors' tokens.
Unverified contract on Etherscan. Anonymous team with no track record. Owner can change metadata after mint. No multi-sig on the contract owner address. Unrealistic promises of future value. Pressure to mint quickly ("limited time"). No audit from a reputable firm. Withdrawal function sends to an unfamiliar address.
Flash Loan Attacks
Flash loans let anyone borrow enormous amounts of cryptocurrency with no collateral, as long as the loan is repaid within the same transaction. Attackers use flash loans to temporarily gain enough capital to manipulate markets, exploit pricing mechanisms, or gain governance power. In crypto art, this is less common but not impossible, especially for NFT-fi protocols that use NFTs as collateral.
The Scale of the Problem
Crypto theft reached $3.4 billion in 2025, the worst year on record, with over $2.3 billion drained in the first half alone. The Cetus Protocol exploit ($223 million via integer overflow), the Balancer v2 incident ($120 million), and numerous smaller hacks demonstrate that smart contract security remains an unsolved challenge.
Gas: The Economy of Execution
Gas is the price of computation. Understanding it helps you time your mints, choose your chain, and avoid overpaying.
What Gas Actually Is
Gas is a unit of computational work, not a currency. Each operation in the EVM has a fixed gas cost. A transaction's total gas is the sum of all operations it triggers. You then multiply this by the "gas price" (in gwei, where 1 gwei = 0.000000001 ETH) to get the fee in ETH.
Mint transaction:
Gas used: 85,000 units
Base fee: 15 gwei
Priority fee: 2 gwei
Total fee: 85,000 x 17 gwei = 1,445,000 gwei = 0.001445 ETH
At ETH = $3,200: approximately $4.62
EIP-1559: The Fee Mechanism
Since August 2021, Ethereum uses EIP-1559, which splits the fee into a "base fee" (determined by network demand and burned, reducing ETH supply) and a "priority fee" (a tip to the validator). When the network is busy, the base fee rises automatically. When it is quiet, it drops. This creates a dynamic pricing mechanism that replaces the old auction-style system.
Gas Across Chains
The fee structures vary dramatically:
- Ethereum mainnet: $1-50+ per transaction depending on network congestion. Complex operations (minting, deploying) cost more.
- Layer 2s (Arbitrum, Base, Optimism): $0.01-0.50. Same EVM, fraction of the cost.
- Solana: ~$0.001 per transaction. Priority fees exist but are minimal.
- Tezos: ~$0.01-0.05 per transaction. Stable and predictable.
- Bitcoin: $1-20+ depending on transaction size and mempool congestion. Inscriptions are larger transactions and cost more.
Timing Your Transactions
On Ethereum, gas prices follow predictable patterns: lower during North American nights and weekends, higher during European/American business hours. Tools like Blocknative Gas Estimator and Ultrasound.money show real-time and historical gas data. If your mint is not urgent, waiting for off-peak hours can save 50% or more.
When deploying your own contract, the deployment transaction is the most expensive (often $50-200 on Ethereum mainnet during normal conditions). Consider deploying on a Layer 2 or during low-gas periods. For mints, batch operations (ERC-1155) and lazy minting (minting on demand when the collector buys) can reduce costs significantly.
On-Chain vs Off-Chain: Where Your Art Really Lives
The smart contract says you own token #42. But where is the actual image, the actual artwork? The answer is more complex, and more fragile, than most artists realize.
The Token URI
Every NFT has a tokenURI that points to a JSON file containing the metadata: the name, description, attributes, and critically, the image field, which is a URL pointing to the actual artwork file. The token on-chain is essentially a pointer. What it points to determines everything.
Where Metadata Can Live
- Centralized server (HTTP): The metadata lives on a company's server. If the company goes down, the server goes offline, or the domain expires, the metadata (and thus the art) disappears. This is the worst option for permanence.
- IPFS (InterPlanetary File System): A decentralized content-addressed network. Files are identified by their content hash, so the URI never changes. But someone must "pin" the file (keep a copy available). If all pinners stop, the file becomes inaccessible. Services like Pinata, Infura IPFS, and nft.storage provide pinning.
- Arweave: A permanent storage network where you pay once and the data is stored forever (in theory). The economic model incentivizes miners to keep data available. Many serious art projects (Art Blocks, generative art platforms) use Arweave.
- Fully on-chain: The artwork data is stored directly in the smart contract's storage or as part of the deployment transaction. This is the most permanent option but also the most expensive. Only small files (SVGs, ASCII art, small images encoded as base64) are practical fully on-chain.
- Bitcoin inscriptions: Data inscribed via Ordinals is stored in the Bitcoin blockchain's witness data, making it as permanent as Bitcoin itself. This is arguably the most permanent storage available, backed by the most valuable and secure blockchain.
↓ tokenURI points to...
HTTP server (fragile) IPFS (needs pinning) Arweave (permanent) On-chain (permanent)
The Fragility Problem
An NFT whose metadata points to https://company.com/api/token/42 is only as permanent as that company's server. If the company pivots, runs out of money, or simply neglects to renew the domain, the art vanishes. The token still exists on-chain, but it points to nothing. You own a receipt for an item that no longer exists.
If you are an artist, check where your minted works point. Go to the contract on Etherscan, call tokenURI with your token ID, and examine the returned URL. If it starts with https:// pointing to a company domain, your art's permanence depends on that company. If it starts with ipfs://, verify that the file is still pinned. If it starts with ar://, it is on Arweave (good). If the data is returned inline (base64), it is on-chain (best).
Freezing Metadata
Some contracts allow the owner to "freeze" the metadata, making the tokenURI permanently unmodifiable. This is the gold standard for artist-deployed contracts: upload art to IPFS or Arweave, set the URI, and freeze. After freezing, not even the contract owner can change where the art points.
The Future: Where Smart Contracts Are Heading
The technology is evolving rapidly. These are the developments that will shape how artists interact with smart contracts in the coming years.
Account Abstraction and Smart Wallets
As covered in The Wallet Bible, account abstraction (ERC-4337) blurs the line between wallets and contracts. Your wallet itself becomes a smart contract, capable of custom logic: social recovery, spending limits, session keys that grant temporary permissions. For artists, this means smoother collector experiences (no gas management for buyers) and more sophisticated minting mechanisms (subscriptions, installment payments, conditional access).
Intents: What You Want, Not How to Get It
Intent-based architectures are an emerging paradigm where users specify what they want ("buy this NFT for under 0.5 ETH") and "solvers" compete to find the best way to fulfill that intent. This moves complexity from the user to the infrastructure, making smart contract interactions feel more like using a search engine than programming a computer.
Cross-Chain Interoperability
Bridges and cross-chain protocols are maturing, enabling NFTs to move between chains. Standards like LayerZero's OFT (Omnichain Fungible Token) and cross-chain messaging protocols are making it technically feasible for an NFT minted on Ethereum to be viewable and tradeable on Solana or vice versa. This is still early and risky (bridge exploits have caused some of the largest losses in crypto history), but it represents a future where artists do not have to choose a single chain.
Formal Verification Goes Mainstream
What Tezos pioneered is gradually reaching other chains. Tools for formal verification of Solidity contracts are improving, and audit firms increasingly use mathematical proofs alongside manual review. As the stakes grow, the industry is moving from "test and hope" toward "prove and deploy."
On-Chain Generative Art
Fully on-chain generative art (where the algorithm lives in the contract itself, not just a pointer to external code) is becoming more feasible as L2s reduce storage costs and specialized platforms (Art Blocks Engine, fxhash) provide infrastructure. The contract is not just a certificate of ownership; it is the artwork's renderer, its DNA, its permanent source of truth.
Regulation
Smart contracts exist in a legal grey zone. Questions about whether certain tokens constitute securities, whether smart contract developers have liability, and how decentralized governance interacts with existing law are actively being debated. Artists should stay informed, because regulatory decisions will affect which platforms survive, how royalties are taxed, and what contractual obligations exist between creators and collectors.
Smart contracts are less than a decade old. The first generation established the concept. The current generation is battling with scale, security, and sustainability. The next generation will likely look very different from today: simpler interfaces, stronger guarantees, deeper integration with the physical world, and (hopefully) enforceable creator rights baked into every protocol.
Glossary
Quick reference for terms used throughout this guide.
| Term | Definition |
|---|---|
| ABI | Application Binary Interface. A JSON description of a contract's functions and events, used by wallets and dApps to interact with the contract. |
| Account Abstraction | A paradigm (ERC-4337) where user wallets are smart contracts themselves, enabling custom logic like social recovery and gasless transactions. |
| Bytecode | The compiled, machine-readable version of a smart contract, deployed on-chain. The human-readable source code is compiled into bytecode. |
| Constructor | Special code that runs once at deployment, setting the contract's initial state. Cannot be called again. |
| ERC-721 | The Ethereum standard for non-fungible tokens. Each token is unique and has exactly one owner. |
| ERC-1155 | A multi-token standard that supports both fungible and non-fungible tokens in a single contract. |
| ERC-2981 | The royalty information standard. Provides a function to query royalty details, but does not enforce payment. |
| EVM | Ethereum Virtual Machine. The runtime environment that executes smart contracts on Ethereum and compatible chains. |
| FA2 (TZIP-12) | Tezos's unified token standard. Handles fungible, non-fungible, and multi-edition tokens in one interface. |
| Formal Verification | Mathematical proof that a program behaves as specified. Eliminates certain classes of bugs with certainty. |
| Gas | A unit of computational work on Ethereum. Each operation costs a fixed amount of gas. Total gas times gas price equals the transaction fee. |
| Inscription | Data (image, text, HTML) permanently embedded in a Bitcoin transaction via the Ordinals protocol. |
| Mempool | The waiting room for unconfirmed transactions. Transactions sit here until a validator includes them in a block. |
| Opcode | A single low-level instruction in the EVM. Smart contracts are compiled into sequences of opcodes. |
| Oracle | A service that provides external data to smart contracts (price feeds, randomness, off-chain events). Chainlink is the largest provider. |
| Proxy Pattern | A design that separates data (proxy contract) from logic (implementation contract), enabling upgrades by swapping the implementation. |
| Reentrancy | A vulnerability where a contract makes an external call before updating its state, allowing the called contract to re-enter and exploit the outdated state. |
| Rug Pull | A scam where project creators abandon the project after collecting funds, often involving metadata manipulation, fund withdrawal, or transfer freezing. |
| Sealevel | Solana's parallel runtime engine. Processes non-conflicting transactions simultaneously for high throughput. |
| Token URI | The URI stored in the smart contract that points to the token's metadata (name, description, image URL, attributes). |