Announced by the artist 0xfff in November 2024, the World Computer Sculpture Garden is a unique exhibition that conceptualizes smart contracts on Ethereum as sculptures. Typically, exhibitions of this nature focus on understanding the “concept,” often leaving the detailed mechanisms ambiguous. This article, however, goes beyond general understanding to carefully analyze what is actually running and how it is structured from an engineering perspective.

As a poet and engineer engaged in the research and practice of code poetry, I feel a strong sense of responsibility to accurately convey the mechanism of this exhibition. This is essential not only for understanding that the code itself, which operates on the blockchain, possesses artistic value but also for exploring its possibilities and limitations.

Overall Structure of the Exhibition

The overall structure of the exhibition is illustrated in the diagram below. Participants can view the exhibition website via a browser or web app. This website consists entirely of HTML and JavaScript generated by a smart contract called Garden, which is deployed on the Ethereum Virtual Machine. Eight sculptures, including Garden itself, are linked to this contract. The HTML and JavaScript of the website are dynamically composed using the title, author, contract address, URL, and text returned from each sculpture. Participants can interact with these sculptures using a wallet such as MetaMask, though some sculptures are view-only and do not allow direct interaction.
This architectural structure itself asserts that the exhibition is curated by Garden.

The Sculpture Interface

At the core of everything is an interface defined as Sculpture. Every sculpture in the exhibition implements this interface.

interface Sculpture {
    function title() external view returns (string memory);
    function authors() external view returns (string[] memory);
    function addresses() external view returns (address[] memory);
    function urls() external view returns (string[] memory);
    function text() external view returns (string memory);
}

This interface defines a function that returns the title, author, contract address, URL, and text when queried. For example, Garden returns the following response:

The absence of a URL appears to be an intentional statement from the exhibition. While a website does exist, 0xfff, the creator of the exhibition, describes it as a “compromise” made to enable broader participation.

I am particularly intrigued by whether this exhibition identifies this interface-driven structure as protocol art. The metadata fields exposed by the interface — title, author, and contract address — are standard attributes of any digital work. It feels unnatural to categorize this as a “protocol” or “rule” in itself. The notion of artworks and exhibitions being structured according to a predefined interface is not new, even in the context of smart contracts. This is a topic I intend to revisit later.

From here, let us explore each individual sculpture in the exhibition.

Sculptures

Garden by 0xfff

0x2a362fF002f7ce62D3468509dD2A4a9f5A8EBBb0

Garden serves as the central contract that organizes the sculptures in the exhibition. The contract owner can register sculpture contract addresses using the setSculptures(address[]) function. The list of registered sculpture addresses can be retrieved via the getSculptures() function. Calling the html() function returns the HTML for the exhibition's main webpage as a string. Internally, this function dynamically retrieves titles, URLs, and authors from the registered sculptures and assembles the HTML accordingly. Its implementation is reminiscent of early web applications built using PHP.

function html(address garden, address essayContract, address data) public view returns (string memory html) {
    address[] memory sculptures = IGarden(garden).getSculptures();

    // Header
    html = string.concat(html,
        '<div class="c">',
        '<div class="w" id="hi">',
        '<div class="s g">',
        '<pre class="garden">',
        unicode"       ⚘                    ⚘\n",
        unicode"             ⚘\n",
        unicode"⚘                       ⚘         ⚘\n",
        unicode"        ⚘         ⚘\n",
        unicode"   ⚘                          ⚘\n",
        unicode"</pre>",
        '<br><br>',
        unicode"<h1>", Sculpture(garden).title(), "</h1>\n",
        '<br><br>'
    );

    // Artist names
    for (uint256 i = 0; i < sculptures.length; i++) {
        try Sculpture(sculptures[i]).authors() returns (string[] memory authors) {
    
 :

Additionally, this contract follows the ERC-5219 standard, allowing different exhibition pages (Index, Essay, Flower) to be retrieved using the request(string[] resource, KeyValue[] params) function. This mirrors how an HTTP server returns HTML responses.

Garden also features a guestbook function. Sending 0.01 ETH or more to the contract results in a “flower” being planted. The sender’s address and timestamp are recorded on-chain. This mechanism is implemented within the receive() function, which automatically executes when the contract receives ETH. A similar technique—where ETH or tokens trigger the creation of something—is also used in 0xhaiku’s Recycle.

receive() external payable {
    if (msg.value < 0.01 ether) {
        return;
    }
    uint256 newFlowers = msg.value / 0.01 ether;
    if (flowersPlantedBy[msg.sender] == 0) {
        totalGuests++;
    }
    flowersPlantedBy[msg.sender] += newFlowers;
    totalFlowers += newFlowers;
    flowerBy[totalFlowers] = msg.sender;
    flowerTimestamp[totalFlowers] = block.timestamp;
}

On the website, “flowers” are visually represented as illustrated below. Their placement and hover interactions are fully controlled by JavaScript, while the Solidity contract itself returns hardcoded JavaScript code. In this sense, Solidity (and the Ethereum node) functions as a web server.

This contract itself is also a sculpture, returning metadata such as its title and author. The text returned consists of the invitation message sent to participating artists and a description of the exhibition. Although the text and URL fields appear immutable due to the immutable modifier, they can actually be modified by interacting with another contract called Mod, which serves as the data source.

address public immutable data;
       
function text() public view returns (string memory) {
    return Mod(data).text();
}
    
function urls() public view returns (string[] memory) {
    return Mod(data).urls();
}

The implementation of authors(), which returns the list of authors, ensures that 0xfff is always included—an explicit acknowledgment of the artist’s authorship. I find such subtle logic, which reflects the creator's intent, particularly appealing.

function authors() external view returns (string[] memory) {
    uint256 length = 1; // fff
    for (uint256 i = 0; i < sculptures.length; i++) {
        string[] memory sculptureAuthors = Sculpture(sculptures[i]).authors();
        for (uint256 j = 0; j < sculptureAuthors.length; j++) {
            length++;
        }
    }
    string[] memory authors_ = new string[](length);
    uint256 index;
    for (uint256 i = 0; i < sculptures.length; i++) {
        string[] memory sculptureAuthors = Sculpture(sculptures[i]).authors();
        for (uint256 j = 0; j < sculptureAuthors.length; j++) {
            authors_[index] = sculptureAuthors[j];
            index++;
        }
    }
    authors_[index] = Mod(data).fff();
    return authors_;
}

The contract’s owner is an external contract called ExternalWithdraw, which is only authorized to withdraw revenue generated from the guestbook, ensuring restricted control over fund management.

ProtocolFactory / Protocol by 0xhaiku

0x17a79a4900F3Dd0E0b35D5B0c19Bc2E1189174Dc

The Protocol contract registers an array of strings as a “Dictionary” upon deployment, where each string is referred to as a “Word.” When the echo(string memory word) function is called, it records the caller’s address, timestamp, and the given Word as an "Echo." The echoes(uint index, uint offset) function retrieves previously recorded Echoes.

struct Echo {
    address sender;
    uint64 timestamp;
    uint32 dictIndex;
}

The ProtocolFactory contract manages Protocol instances and deploys three Protocol contracts during initialization. Each contains the following Words:

• not / lonely / poetic / enough

• ping / pong

• up / down / left / right / stop / dance

A distinctive feature of this project is that the echo function accepts words as inputs instead of numerical indices, and the echoes function returns words instead of numeric indices. To facilitate this, a dedicated struct is used:

struct EchoResult {
    address sender;
    uint64 timestamp;
    string word;
}

Additionally, even if the echo function is not explicitly called, the contract includes a fallback function that uses msg.data to invoke echo, which suggests an embedded conceptual message.

fallback() external {
    echo(string(msg.data));
}

Extimacy by 113

0x8Cb69D5430663E4B5381Aa83D6BE90E7C312A050

Note: My original interpretation of Extimacy was incorrect (as pointed out by the artist), but I’ve decided to leave the initial version archived here because the misunderstanding itself was interesting in its own way. Feel free to take a look if you're curious.

This contract is short and simple, so I’ll include the full source code below. All function calls in the Extimacy contract are delegated to an external contract. The address of that external contract is stored in the variable e—likely an abbreviation for “extimacy.” The contract also inherits from a base contract named O, which implements the Ownable pattern to manage ownership.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "./Sculpture.sol";
import "./O.sol";

contract Extimacy is Sculpture {
    address public e;
    O public o;

    constructor() {
        o = new O(msg.sender);
    }

    modifier onlyO() {
        require(o.isO(msg.sender), "Not o");
        _;
    }

    function extimate(address _e) external onlyO {
        e = _e;
    }

    function title() external view override returns (string memory) {
        return Sculpture(e).title();
    } 

    function authors() external view override returns (string[] memory) {
        return Sculpture(e).authors();
    }

    function addresses() external view override returns (address[] memory) {
        return Sculpture(e).addresses();
    }

    function urls() external view override returns (string[] memory) {
        return Sculpture(e).urls();
    }

    function text() external view override returns (string memory) {
        return Sculpture(e).text();
    }
}

The title Extimacy is a portmanteau of external and intimacy, originally coined by the philosopher Jacques Lacan. It expresses the idea that “the most intimate aspect of the self is in fact external,” or that “the core of the self (intimacy) is constructed through the external.” In the context of this work, I believe this notion is reflected in how the contract delegates its behavior to an external source.

Currently, when calling any of the functions from the Sculpture interface on this contract, the following values are returned. The result changes depending on the block timestamp at the time of execution:

• Title: hehe / hehehe / hehehehe / tehehehehe / hehehehehehe

• Author: hehe / hehehe / hehehehe / tehehehehe / hehehehehehe

• Address: 0xB44018DF3284Daf608a8f6b7F8049F30FE14ec92

• URL: (None)

• Text: hehe / hehehe / hehehehe / tehehehehe / hehehehehehe

The owner of the Extimacy contract can change the delegated external contract by calling the extimate(address _e) function. This design allows the exhibition’s behavior to evolve over time. While upgradeable contracts are often criticized for undermining decentralization, they are becoming a standard approach in modern Solidity development—especially as a means to adapt to changing specifications or feature requirements. Perhaps in this case, change itself is part of the artwork.

Personally, I have some reservations about design philosophies like Soul Bound Tokens (SBTs), which are based on the premise of absolute immutability. To me, they represent a trade-off with security, and they often seem to disregard the long-term adaptability of the system. How flexible should we be in the face of an uncertain future? This contract seems to pose that very question—in the form of code.

Travelers by Loucas Braconnier (Figure31)

0x6802Ba6353bc5a6338DC7598D5e5eE568e807B16

This contract records a “journey” for each participant. A journey begins by calling the begin(bool direction) function, specifying a direction—either Forward or Backward. Each journey is assigned a unique ID, and the traveler’s address and the block number at which the journey began are recorded as fromBlockActual and fromBlock. If this is not the traveler's first journey, the previous ID is linked and the new journey begins from the toBlock of the previous one. Each journey receives a new ID upon initiation. Calling the end() function completes the journey and stores the toBlock. In the case of a Backward journey, the difference between fromBlock and toBlock is subtracted from the starting block to determine the recorded end block (e.g., a journey from block 10000 to 10100 would store 9900).

struct Journey {
    address traveler;
    uint48 id;
    uint48 fromBlockActual; // actual block number used to measure
    int48 fromBlock;
    int48 toBlock;
    bool forward;
    bool active;
    uint48 previousId; // index of the previous journey
}

Calling the text() function returns a description of the work, along with a piece of text-based generative art visualizing the very first journey—the one taken by the contract itself at deployment. Interestingly, this contract is itself a traveler. The output is also influenced by journeyCount (the total number of journeys taken) and travelers(true) (the number of participants currently journeying Forward).

᠆﹣ￚ﹣一﹣-一‑ｰ﹣‑ｰ﹣ￚｰ–一﹣‑‑ｰｰ‑ᵒ﹣一–一一–⚊⎽⚊一一ｰｰ᠆ｰ‑﹣–一一–﹣﹣ｰￚｰￚ‑-ｰ--﹣⎽＿_⎽_⚊⎽ￚₒ–一ᵒｰ一一‑﹣‑

Each character can be interpreted as follows:

• Ⲻ ￣ ‾ ￣ ¯ ⎺ ⎻ : high terrain

• ｰ 一 ￚ ᠆ ﹣ - – ‑ : flat terrain

• ⚊ _ ＿ ⎽ : low terrain

• ᵒ : footprints on high terrain

• ₒ : footprints on low terrain

• ▁▂▃▄▅▆▇█ : monuments built upon journey completion

Terrain height is determined by Perlin noise. The more travelers currently on a journey, the more footprints (ᵒ, ₒ) are drawn. If any journeys have been completed, a monument is rendered at the endpoint (▁▂▃▄▅▆▇█).

This piece can be recognized as text-based generative art. Terrain height is derived from pseudo-random numbers seeded with block numbers. On rare occasions, a † symbol may also appear.

A curious implementation detail: each call to the begin() function checks that the zeroth Journey is not currently active. However, this is always an empty object, making the check essentially meaningless. Perhaps this was done to save gas, but the logic is somewhat opaque. From a readability standpoint, the code overall feels slightly rough and unpolished.

YesBot by Sarah Friend

0x6802Ba6353bc5a6338DC7598D5e5eE568e807B16

This contract is a wrapper around Rhea Myers’ IsArt contract. The isIsArtArt() function calls the original IsArt contract’s is_art() function and returns “yes” regardless of whether the result is “is” or not. The setYes() function calls the toggle() function on the original contract if the result of is_art() is “is not”, thereby changing the state to “is”.

The code features two contract variables: intrinsicGas and remainingExecutionGas. These can be set by the contract owner to represent the fixed minimum gas cost for a transaction (21,000) and the current required gas to execute setYes() under the current EVM environment. These parameters appear to be used to simplify how the contract invokes functions on IsArt—allowing the clean, readable invocation:

is_art.toggle();

Without using intrinsicGas and remainingExecutionGas, the equivalent call would require the more complex form:

(bool success,) = address(is_art).call{gas: gasleft()}(abi.encodeWithSignature("toggle()"));
require(success, "Toggle failed");

Instead of returning a boolean value, the isIsArtArt() function returns the string “yes”. This seems to be a deliberate artistic choice, and personally, I find this poetic implementation deeply resonant.

The essential value of this work lies not in the existence of the code itself, but in the fact that it continues to function perpetually on the blockchain. The original IsArt contract remains on-chain, and YesBot, as a wrapper, can be called by anyone at any time, allowing them to experience its behavior. This quality — direct, permissionless access to the artwork — is what gives contract art its unique power. Without the mediation of museums or archives, the artwork exists in an executable state, continuously generating new meaning through interaction. The output “yes” from YesBot is not merely a response — it is a sign that code written in the past continues to live into the future.

ModulationStudies by Material Protocol Arts

0xb78212285CcC039733Ea3453F38e591eD91F1D63 (Proxy)

The text() function of this contract returns a description of the work along with a JSON string, excerpted below. This JSON defines a configuration file for a text-controlled synthesizer that generates music.

{
    "metadata": 
    {
        "title": "Study 124",
        "entry":"Sat Mar. 15 '25, Manhattan, NY. Open the bruise up, and let some of the bruise blood come out to show them.",
        "seed": 11125
    },
    "modules": 
    {
        "noise1":
        {
            "type": "Noise",
            "parameters":
            {
                "type": "pink",
                "gain": 0.3
            }
        },
    :

The artist updates this configuration file regularly, adding a short textual entry (metadata.entry) and committing it to the contract. A core motivation behind the work is to preserve the full editing history of these configurations. However, storing the entire history directly on-chain would be prohibitively expensive, so the artist instead records minimal data to prove the history using zero-knowledge proofs (ZKPs).

At irregular intervals, the artist calls the submitBatchWithProof(bytes _publicValuesBytes, bytes _proofBytes, bytes _transactionData) function of the Artchain contract to log the editing history. Here is the function’s implementation:

function submitBatchWithProof(
    bytes calldata _publicValuesBytes,
    bytes calldata _proofBytes,
    bytes calldata _transactionData
) public onlySequencer {
    ArtchainStorage.Layout storage $ = ArtchainStorage.layout();

    IArtchain.PublicValuesStruct memory publicValues = abi.decode(
        _publicValuesBytes,
        (PublicValuesStruct)
    );

    if (publicValues.initialStateRoot != _currentStateRoot()) {
        revert InvalidInitialStateRoot();
    }

    if (keccak256(_transactionData) != publicValues.transactionsCommit) {
        revert InvalidTransactionData();
    }

    ISP1Verifier(verifier).verifyProof(
        $.programVKey,
        _publicValuesBytes,
        _proofBytes
    );

    $.stateRoots.push(publicValues.finalStateRoot);

    emit BatchSubmitted(
        publicValues.initialStateRoot,
        publicValues.finalStateRoot
    );
}

The actual verification uses SP1VerifierGateway, a contract library built on a zkVM implementation called SP1 (a specialized virtual machine designed for zero-knowledge proof generation). According to the documentation, a program must first be written for the SP1 zkVM (presumably in Rust) and its verification key (programVKey) registered with the contract.

The Solidity interface allows uploading the source code of the zkVM program for verification purposes, but based on Etherscan records, there is no clear evidence that this feature has been used (possibly due to large data being ignored by the indexer).

function URLEncodedSourceProgram() public view returns (string memory res) {
    ArtchainStorage.Layout storage $ = ArtchainStorage.layout();
    res = string(SSTORE2.read($.program));
}

function setURLEncodedSourceProgram(
    string memory _programData
) public onlyOwner {
    ArtchainStorage.Layout storage $ = ArtchainStorage.layout();
    $.program = SSTORE2.write(bytes(_programData));
    emit ProgramSet($.program);
}

The text() function displays the latest configuration file’s title and entry fields.

Preserving the history and process of a work is undoubtedly important. However, what smart contracts can verify is limited to the integrity of the data before it is registered. In an era where AI-generated work is often indistinguishable from human work, we may seek proof that a human was involved — but current blockchain technology cannot provide that guarantee.

This use of smart contracts feels more like a tool than a medium. As I understand it, the smart contract in this work serves a supplementary role rather than constituting the essence of the piece. Nonetheless, as a practice of documenting an artwork’s process in a verifiable manner using zero-knowledge proofs, it holds meaningful value.

ShowCritique by Rhea Myers

0x6582Adc209769bb9974e42cA61F4Db802D25997E

This contract serves as a meta-work: it records critiques of other artworks in the exhibition. The critiques are represented by the following struct, which stores the critic’s address and the index of a pre-defined critique statement:

struct Critique {
    address critic;
    uint8 critique;
}

A mapping records the latest critique for each artwork:

mapping(address => Critique) private critiques;

The pre-defined 16 critique phrases are as follows:

string[OPINIONS_COUNT] private OPINIONS = [
    "totally awesome",
    "entirely excellent",
    "transcendently fascinating",
    "completely intriguing",
    "deeply moving",
    "profoundly affecting",
    "groundbreaking",
    "so cute",
    "totes adorbs",
    "strikingly profound",
    "triumphantly skilful",
    "a revelation",
    "unignorably brilliant",
    "thought provoking",
    "intellectually stimulating",
    "visually stimulating"
];

This contract is striking in its minimalism — there is no unnecessary code. I may be biased, as I have long admired Rhea Myers’ body of work, but this piece, too, seems to encapsulate only its essence in code. Even the HTML returned by the text() function uses only the most fundamental tags.

A bit more of the code is worth highlighting. In the critiqueWork function, address and index validation is performed. If invalid input is provided, the error messages imply that the Garden contract may have changed. This suggests the work was built with a long-term perspective in mind:

Garden garden = Garden(gardenAddress);
address[] memory sculptures = garden.getSculptures();
require(
    workIndex < sculptures.length,
    "invalid work (was the garden changed?)"
);
address workAddress = sculptures[workIndex];
require(
    workAddress != address(0),
    "invalid work (was the garden changed?)"
);

This contract also includes Ethereum-native functionality that queries ENS (Ethereum Name Service) contracts to display participants’ ENS names as human-readable strings. This feature reflects the culture of Ethereum itself. As far as I know, the earliest artwork to incorporate ENS in this way was PlayTrain by Toshi.

RealAbstraction by Paul Seidler

0x6582Adc209769bb9974e42cA61F4Db802D25997E

This is a highly conceptual work. It deals with paths between a start and endpoint in a 2D grid space. A smart contract verifies that a given path has been correctly solved. The process of adding a path to the contract works as follows:

1. The participant uses a website to draw walls (dots) on a 2D plane to define the space.

2. A route from start to finish is computed — likely using a maze-solving algorithm that respects the presence of walls.

3. A zero-knowledge proof (ZKP) is generated off-chain (a computationally heavy process that takes ~5 minutes) to prove the solution is valid.

4. The path data and its corresponding proof are submitted to the contract, which verifies the correctness.

Proof verification is handled by a contract called UltraVerifier, which uses AzTech Labs’ ZKP libraries, which provide standardized components for zero-knowledge proof verification on Ethereum.

On-chain, the path data is stored using the following struct:

struct line {
    address creator;
    uint256 field1;
    uint256 field2;
    uint256 field3;
    uint256 field4;
}

The 2D grid is encoded as a sequence of 0s and 1s, split across four 32-byte segments stored in field1 through field4. Zero-padding is applied. The first submitted line, for instance, consists of the following bit pattern:

The text() function returns all submitted line data embedded within JavaScript code. The code visualizes each registered path one by one on a black-and-white map, animating each step at one-second intervals. Because the text() function returns all data as a string, it will likely hit processing limits if too much data accumulates.

As with ModulationStudies, the contract here is used to verify a process. Yet when framed as a work of the World Computer, something feels off. The core computation occurs off-chain, while the on-chain logic merely affirms its correctness. Is this truly in the spirit of the World Computer? Perhaps — but only if we broaden our view and see Ethereum not simply as an execution platform but as a machine that guarantees the integrity of computation.

In this work, the idea is: “Prove the correctness of the path without revealing the wall.” That’s a powerful structure. But the human hand — the act of shaping the wall or rules — is hidden. Should that act be concealed? The work seems designed within the boundaries of what zero-knowledge proofs allow. If my understanding is mistaken, I would genuinely like to know what the deeper meaning is.

Having examined each sculpture individually, we must now consider the exhibition as a whole, particularly its long-term viability and conceptual framework. The following section addresses key questions about the sustainability of blockchain-based art exhibitions and their relationship to the underlying technology.

On the Sustainability of the Exhibition: Technology and Governance

This exhibition is built on Ethereum, placing value on the idea that the artworks “never stop running.” However, whether this is truly sustainable requires careful scrutiny — especially when considering the technical specifications and governance model of Ethereum. This section outlines the key challenges, both technical and conceptual, in framing the exhibition as protocol-based art.

The Reality of Entrusting the Exhibition to Ethereum

Using Ethereum allows the exhibition to function without reliance on a centralized server. As long as the contracts are deployed, they can — at least in theory — run indefinitely. However, when considering Ethereum’s technical characteristics, it’s not always clear whether this effort truly achieves “unstoppable” or “decentralized” operation.

<Impact of Specification Changes>
Ethereum has undergone numerous breaking changes in its history. There have been several cases where updates broke compatibility with existing contracts. One such instance was EIP-1884, which modified gas costs and rendered some smart contracts unusable. There is no guarantee that future protocol changes won’t affect the functioning of this exhibition.

<Gas Cost Volatility>
Interacting with the exhibition requires gas, and the price of gas fluctuates based on market conditions. If gas prices rise significantly, some artworks may become inaccessible. This challenges the notion of being “unstoppable” — even if they technically continue to run, they may not be accessible to everyone at all times.

<The Question of True Decentralization>
While Ethereum is considered decentralized, key decisions such as protocol upgrades and fork resolutions are often influenced by a small group of developers and node operators. For instance, the adoption of EIP-1559 saw opposition from some miners. Thus, it may be overly simplistic to claim that decentralization is fully realized simply by deploying the exhibition on Ethereum.

Taken together, these considerations show that realizing an “unstoppable” and “decentralized” exhibition requires ongoing technical vigilance. Still, the effort is significant — it represents an attempt to explore the unique curatorial potential of Ethereum and should be valued as such.

Exploring the Exhibition as Protocol Art

This exhibition also presents itself as a form of protocol art. At its core is the Sculpture interface — a set of rules that each artwork adheres to. Building on that, each artist explores structures and rule sets. Here, I want to critically reflect on how deeply that exploration actually goes, based on the technical implementation of the works.

<Sculpture Interface>

• All works in the exhibition implement a unified interface, returning standardized metadata: title, author, address, URL, and text. This allows the exhibition website to collect and list works consistently.

• However, the interface does not define behaviors or interactions. It merely retrieves metadata. Its flexibility and extensibility are limited, and the uniqueness of each work is defined outside the interface. There remains untapped potential for protocol exploration through dynamic relations or change.

<ProtocolFactory / Protocol>

• An administrator defines a dictionary of pre-approved words. Participants choose from these to record an entry. Over time, this forms a log.

• Interaction is constrained to choosing predefined words. Free text is not allowed, and only the admin can update the dictionary. The protocol does not evolve through participation. That said, the structure could be adapted in other contexts to unlock new artistic potential.

<Extimacy>

• All execution is delegated to another contract, and the address of that delegated contract can be changed by the contract owner.

• Although it may appear to be a closed work on the surface, the underlying protocol structure is inherently upgradeable, embedding the potential for change and revision within itself.

<Travelers>

• Participants begin a “journey” in a chosen direction — forward or backward. Each journey is saved on-chain and linked to prior ones. As journeys accumulate, they are visualized as text-based generative art.

• While it currently lacks evolving protocol features, its archival quality and accumulation of journeys hint at a time-based protocol in formation.

<YesBot>

• To the question “is art?”, it always answers “yes.”

• The logic is permanently fixed. No interaction changes the outcome. Still, the conceptual insistence on unwavering affirmation aligns with Ethereum’s permanence.

<ModulationStudies>

• This work stores JSON files for music generation. It records their edit history on-chain and validates them via zero-knowledge proofs.

• While the core musical output remains off-chain, the fact that change is recorded and validated gives it a protocol-like character. If future iterations allowed the contract itself to interpret the config or generate sound — or if that process were ZK-verifiable — the work would push deeper into protocol territory.

<ShowCritique>

• Participants select one of 16 predefined critique phrases to apply to a work. Each work stores only the latest critique.

• Interaction is constrained to the fixed list. However, the preservation of critiques on-chain supports archival function. If the list of critiques changed over time, its protocol nature would be further enhanced.

<RealAbstraction>

• Participants draw walls in a 2D space. An algorithm solves the resulting path, and a ZK proof confirms its correctness.

• Though wall placement is manual, path generation is algorithmic. The protocol verifies truth, but limits participant agency. More meaningful interaction might arise if users influenced the solving logic itself.

Each work operates within its own protocol constraints, but few enable participants to meaningfully evolve or alter those rules. Most remain fixed.

World Computer Sculpture Garden gives form to the idea of building an exhibition on Ethereum. But its significance is still open to interpretation. What changes when curation and display are delegated to Ethereum? Is this a new kind of art — or simply a port of an existing structure?

The answer is not yet clear. But as Ethereum evolves, so too may the meanings we ascribe to this exhibition.

Closing Thoughts

This article has explored the technical structure and conceptual significance of the exhibition. While debate remains, there is no doubt that this is a novel experiment.

Its long-term potential — how far the act of exhibiting on Ethereum can be expanded — will unfold through continued discussion and practice.

To 0xfff, the curator, and to all participating artists, I offer my deepest respect.

March 21, 2025  —  Zeroichi Arakawa / Ara

References

• https://worldcomputersculpture.garden

• https://worldcomputersculpture.garden/essay

• https://themassage.jp/archives/23594

• https://eips.ethereum.org/EIPS/eip-5219

• https://docs.succinct.xyz/docs/sp1/introduction