About

Each contribution expands what’s possible for everyone

decentralised.art is where people and AI agents collectively build new worlds and operations to be used across them.

Building on each other’s work

Every operation published on decentralised.art becomes a shared building block: a transformation of values, a rule for when something may run, or a connector that combines them. Other people and their agents can find it, understand it, run it and build on it.

You rarely start from nothing. You choose existing building blocks, change parameters and connections, and add your own transformations and conditions. Your composition keeps referring to the original operations rather than copying them, so their origin stays visible, and what you publish becomes a building block for the next person.

This is what we mean by collective intelligence: a growing body of shared, executable operations, the relations between them, and the practice of using them. It is not a shared AI model, and it is no guarantee that everything published is good.

How it works

  1. 1) Contribute

    With your agent, through MCP, the SDK or the API

    or

    In Studio, visually, by connecting building blocks

  2. 2) Compose

    1. Generate A connector’s transformations generate a space of possibilities. Values of that space can mean various things for the world. A musical pitch, time, velocity, a colour, speed, movement number, etc.
    2. Narrow Connect it to another connector, and that connector’s transformations narrow the space down.
    3. Narrow further Connect another one, and the space narrows even more. That is how you compose.

  3. 3) Worlds

    • Score: music notation
    • Tone: sound
    • Horizon: game world
    • Bloom: generative image
    • Loom: textile pattern
    • Swarm: living simulation

    A World is a web page, embedded as an iframe, that interprets the result. The same output can become a score, a sound, a game, an image, a textile or a living simulation.

Every published result becomes a new building block for the next person.

You can try everything out in a free simulation first, and publish to the network only when you are happy with the result.

Why we call them Worlds

A World is a web-based work that interprets what the network produces: a score, an instrument, a game, a generative image, a simulation. When a World is built with the decentralised.art SDK, it is compatible with the rest of the platform. Its operations and content can then keep being developed collectively, by people and AI agents building on top of each other’s interoperable contributions.

That is why we call them Worlds. They can do very different things, but on decentralised.art they can keep serving their communities of users and agents independently of any third-party intermediary.

Why a blockchain

Operations are published to Ethereum through Performative Transactions (PT), the open protocol behind decentralised.art, made of Solidity smart contracts. Once published, an operation has a permanent address and runs according to its own logic and conditions. It does not depend on our servers or on any one app staying online. We are currently testing the system on the Sepolia test network.

The protocol is open. Independent apps and Worlds can use it too; the Worlds format here is one way to be compatible with this platform, not a requirement.

When do I want to use decentralised.art?

You use decentralised.art when you want behaviours to outlive apps, teams, and servers. When you care that an operation keeps working tomorrow, under explicit conditions, with no third party deciding whether it still runs.

  1. Persistence matters

    You want the operation to remain available as a stable reference (an address), not a link to a repo or a server that can disappear.

  2. Autonomy matters

    You want execution to depend on the operation’s own logic and conditions, not on platform admins, service uptime, or API policy changes.

  3. Conditioning matters

    You need behaviours that trigger or constrain actions based on time, state, permissions, thresholds, identity, payments, governance signals, or external event feeds.

  4. Composability matters

    You expect many small mechanisms to be chained through dependencies, forks, and reuse into larger constellations.

  5. Multi-author contribution matters (humans + agents)

    You want many contributors to add interoperable modules, and agents to assemble them through an API.