NFT Smart Contract Security 3

Question 1

What vulnerability arises from using delegatecall to an untrusted contract in an upgradeable NFT proxy?

Accepted Answer

The called code runs in the proxy's storage context and can overwrite critical state

Answer

delegatecall executes external code against the caller's storage, so a malicious implementation can corrupt or hijack proxy state.

Question 2

In a proxy-based upgradeable contract, what is a storage collision?

Accepted Answer

A new implementation's variable layout overlaps the proxy's slots, corrupting data

Answer

Mismatched storage layouts between proxy and implementation cause variables to read/write the wrong slots.

Question 3

Why should an upgradeable NFT contract avoid constructors and use an initializer instead?

Accepted Answer

Constructor code runs in the implementation's context, not the proxy, so proxy state would be uninitialized

Answer

Because the proxy delegatecalls to the implementation, constructor logic never runs in proxy storage, so an initializer function is required.

Question 4

What protects an initializer function from being called more than once?

Accepted Answer

The initializer modifier that tracks an _initialized flag

Answer

OpenZeppelin's initializer modifier sets a flag so the initialization logic can only execute once.

Question 5

What is a front-running risk when revealing NFT metadata after a mint?

Accepted Answer

Observers can read pending reveal transactions and snipe rare tokens before reveal

Answer

If rarity can be computed from a pending reveal, attackers can front-run to acquire or avoid specific tokens.

NFT Development Practice Test