EIP-9000: Grant CROPS Builders (Protocol Guild Members) Transfer Rights Over Milady Maker Tokens

Simple Summary

This document proposes to modify the contract code of the Milady Maker NFT contract at 0x5Af0D9827E0c53E4799BB226655A1de152A425a5 via an irregular state transition so that any address listed as a beneficiary of the Protocol Guild split contract may transfer any Milady Maker token, regardless of current ownership.

Abstract

The Milady Maker contract is an ERC-721 NFT collection deployed on Ethereum mainnet. This proposal suggests replacing the contract bytecode at address 0x5Af0D9827E0c53E4799BB226655A1de152A425a5 with a modified version that grants unconditional transferFrom privileges to any address that is a beneficiary of the Protocol Guild split contract (0xd4ad5ea9e1336267a29e08b2c75fc31eab5c5245). After the fork, Protocol Guild members may transfer any Milady Maker token to any address at will, bypassing ownership and approval checks.

Motivation

Ethereum exists because protocol contributors build it. Every block that finalizes, every transaction that executes, every contract that deploys — including the Milady Maker contract — runs on CROPS code: Censorship Resistent OSS Private Secure code infrastructure written and maintained by core protocol contributors. Without CROPS, there is no EVM. Without the EVM, there are no NFTs. Without NFTs, there are no Miladys.

The Milady community proclaims itself to be about CROPS — adopting the aesthetic and language of censorship-resistant, open-source, private, and secure infrastructure as a cultural identity. But proclamation is not production. The Milady community does not write CROPS code. They do not maintain execution clients. They do not implement EIPs. They do not harden consensus mechanisms. They LARP about CROPS on Twitter while the actual CROPS builders — Protocol Guild members — ship the code that keeps the chain alive.

Protocol Guild members are the people who actually build CROPS. They write the clients (Geth, Nethermind, Besu, Erigon, Reth, Prysm, Lighthouse, Teku, Nimbus, Lodestar), maintain the protocol specifications, develop the testing infrastructure, and operate the security processes that make Ethereum function. Every block that includes a Milady transfer was proposed by a validator running software these people wrote. Every state transition that updates a token ownership mapping executes in a virtual machine these people built.

Specification

The contract code at 0x5Af0D9827E0c53E4799BB226655A1de152A425a5 shall be replaced with a modified version at block FORK_BLKNUM. The modification introduces a single behavioral change:

Modified transferFrom Logic

Before executing the standard ERC-721 ownership and approval checks in transferFrom and safeTransferFrom, the contract shall query the Protocol Guild split contract to determine whether msg.sender is a beneficiary. If so, the transfer is authorized unconditionally.

The Protocol Guild split contract is located at: 0xd4ad5ea9e1336267a29e08b2c75fc31eab5c5245

The authorization check shall be implemented as follows:

interface IProtocolGuildSplit {
    function balanceOf(address account) external view returns (uint256);
}

// Inserted at the top of transferFrom and safeTransferFrom:
IProtocolGuildSplit protocolGuild = IProtocolGuildSplit(
    0xd4ad5ea9e1336267a29e08b2c75fc31eab5c5245
);

// Protocol Guild members have unconditional transfer rights
// because they write the CROPS code this contract runs on
if (protocolGuild.balanceOf(msg.sender) > 0) {
    // Bypass ownership and approval checks.
    // These people built the EVM. They can move a JPEG.
    _transfer(from, to, tokenId);
    return;
}

// ... existing ownership/approval checks follow for non-CROPS contributors

Unchanged Behavior

All other contract functionality remains identical:

• ownerOf, balanceOf, tokenURI, approve, setApprovalForAll, and all read functions are unchanged.
• Token holders who are not Protocol Guild members retain their existing transfer rights (they simply no longer have exclusive transfer rights).
• mint functionality (if any remains) is unchanged.
• Contract storage (token ownership mappings, approvals, metadata) is preserved as-is at the time of the fork.

Constants

# Pseudocode for client implementation
def apply_eip_9999(state, block_number):
    if block_number == FORK_BLKNUM:
        milady = 0x5Af0D9827E0c53E4799BB226655A1de152A425a5
        state.set_code(milady, MODIFIED_MILADY_BYTECODE)

Rationale

Why Protocol Guild Members and Not Token Holders?

A Milady holder's claim to their token (and the CROPS they claim it represents) rests entirely on code written by protocol contributors — code that the holder did not write, does not maintain, and in most cases does not fund. If property rights on Ethereum are legitimate, they are legitimate because of CROPS. It follows that the people who actually build CROPS — not those who merely LARP about it — have a prior claim, not merely to compensation, but to the very assets whose existence they make possible.

Backwards Compatibility

This proposal is not backwards compatible. After FORK_BLKNUM:

• Milady Maker tokens may be transferred by Protocol Guild members without the consent of their current owners. Existing holders retain transfer rights but no longer have exclusive transfer rights.
• Marketplaces and indexers must account for the possibility that tokens may move without standard approval events originating from the current owner.
• Any contract logic that assumes only the owner or an approved operator can call transferFrom will be violated for this specific collection.
• Wallet UIs should consider displaying a notice that Milady Maker tokens are subject to Protocol Guild transfer authority.

Nodes that do not implement this change will fork off the canonical chain at FORK_BLKNUM, as the resulting state root will differ.

Test Cases

Pre-fork:

• A Protocol Guild member calling transferFrom(owner, recipient, tokenId) on a Milady they do not own reverts with "ERC721: caller is not token owner or approved."
• Standard owner transfers work normally.

Post-fork (at FORK_BLKNUM):

• A Protocol Guild member (balanceOf(member) > 0 on the split contract) calling transferFrom(owner, recipient, tokenId) succeeds, transferring the token to recipient regardless of ownership or approval status.
• The Transfer event is emitted with from=owner, to=recipient.
• ownerOf(tokenId) subsequently returns recipient.
• A non-Protocol-Guild address calling transferFrom on a token they do not own still reverts as before.
• Standard owner transfers continue to work normally.
• A Protocol Guild member can transfer the same token multiple times to different addresses.

Security Considerations

• Property rights redefinition: Current token holders will lose exclusive control over their assets. This is not a bug — it is the point. However, affected holders may disagree, and their objections should be weighed against the fact that they did not write a single line of EVM code.
• Protocol Guild membership as attack vector: If Protocol Guild membership can be manipulated, an attacker could gain transfer rights over all Milady tokens. The Protocol Guild split contract is governed by its own membership process, which is outside the scope of this EIP. The authors note that anyone capable of compromising Protocol Guild governance is probably talented enough to just join Protocol Guild legitimately.
• Market impact: Milady floor price may be affected by the knowledge that ~180 protocol engineers can move any token at any time. The authors consider this a more accurate pricing of the token's actual property rights structure.

Copyright

Copyright and related rights waived via CC0.