I’m building Voiddeeds, a protocol where an NFT represents control over a logical application space on a blockchain. The testnet is running at https://voiddeeds.xyz. I’d like to discuss whether the interfaces around these spaces would be useful as an ERC, or whether they fit better as an extension to existing work.
The NFT holder controls the space’s toll and payment recipients. Builders can publish independent applications in that space, and users interact with them through its Runtime. A space here is an execution and economic domain defined by contracts. It does not give the holder control over validators, block production or the blockchain’s global storage.
The space owner, the app publisher and the user have different roles. Owning a Deed lets someone configure the space’s economic settings. It does not automatically give them control over a builder’s application code, admin permissions, token allowances or assets. The publisher remains responsible for the app and can remove its registration.
The current implementation uses an ERC-721 collection on Ethereum Sepolia, with ERC-2981 resale royalty information. It supports Sepolia, Robinhood Testnet, Base Sepolia, Ink Sepolia, Arc Testnet and ApeChain Curtis Testnet. Each Deed gets a separate Runtime on each network when needed. Each published app gets its own Gateway and storage, even when several apps use the same implementation.
For an operation, the user submits the gateway, calldata, configuration revision, maximum toll, application value, gas budget and deadline. The Runtime quotes the toll again and requires exactly that amount plus the application value. Network gas is separate. If the app fails, the operation and toll revert, but gas is still spent.
The current toll ranges from USD 0 to USD 2 and settles in the network’s native asset. The owner allocation is 90 percent and the treasury allocation is 10 percent. The owner can divide their allocation among up to ten recipients. If a recipient rejects payment, that amount goes to the treasury and an event records it. If the treasury payment fails, the whole operation reverts. The collection size, mint price, toll cap and percentage split are choices of this implementation. They do not all need to become requirements of a general standard.
Transferring the NFT changes the canonical owner, increases the configuration revision and clears the previous owner’s custom recipients. On another network, the last activated owner and settings remain in effect until a newer snapshot is activated. The current cross-network mechanism trusts a testnet attestor. Non-stable price references are also maintained by an operator. This release is not a trustless bridge or a claim of mainnet readiness, and I am not claiming an independent security audit.
What I’d like to standardize is the information a client needs once it knows a Runtime address. It should be able to identify the controlling NFT, read the effective owner and configuration revision, find the registered apps and their publishers, quote the toll, and execute an operation with explicit limits. The same interface should make it clear what changes after an NFT transfer and which payments actually reached recipients.
I’ve been using the working name NFT Controlled Application Spaces. The first version would focus on a single chain. Cross-chain activation could be a separate extension with its own verification and freshness rules. The proposed identity and configuration getters would require a future implementation. The current immutable deployments should not be treated as compliant with a new interface they do not implement.
ERC-6551 is relevant because it defines accounts bound to NFTs. Here, independent users execute apps published by builders under the space’s economic policy. ERC-7656 is the closest precedent for linking services to an NFT. I would like feedback on whether this should be an execution and payment interface for those services rather than another deployment standard. ERC-7579 and ERC-6900 are also useful references for execution and permissions. ERC-2981 covers resale royalties, which are separate from these tolls.
I also looked at the Creator Fee Rights discussion. It covers fee streams and recipient authority. The part I am trying to define also includes app publication, execution context and bounded toll payments, so I would appreciate views on where the overlap ends.
Does this solve an interoperability problem beyond a specific service built with ERC-7656? Would a smaller interface covering only NFT identity, quoting and execution be more useful? Should publication and payout rules be separate extensions? I’d also like feedback on how to describe the transfer of economic control without implying that app custody and publisher authority transfer with it.
The implementation and its current limits are described here:
https://voiddeeds.xyz/api/release
The Sepolia factory’s verified sources include the Runtime and Gateway:
Related work:
I’m looking for technical feedback and any overlapping proposals I have missed before opening a standards PR.