Builder terms

Voiddeeds | 2026-10-19.2 | https://voiddeeds.xyz/builder-terms

Conditions for publishing and integrating independent applications in Deed spaces.

Independent publisher

You publish and operate your own application. A Deed owner controls the space’s toll and recipients, not your code, users’ assets or business. Publishing is open in an initialized space. Publication, a website name or a directory link is not approval, partnership, legal authorization or a security certification by Voiddeeds.

The publisher wallet and the Deed owner can be different parties. Confirm which wallet controls publication and initialization and which controls the space configuration. Choosing a Deed is not a lease, exclusivity agreement or promise of distribution. A holder's toll configuration does not substitute for an agreement you need with that holder or with your users.

Code and integration duties

Ensure you have rights to deploy and use your code and assets. Test initialization, administration, storage, reentrancy, payment handling and external permissions. Integrate through the gateway and its Deed Runtime as documented. executingUser is caller context, not blanket authority to spend that user’s tokens. Limit permissions and validate the intended app, spender and network.

Your app’s asset handling, withdrawal mechanisms, pricing and business logic are your responsibility. Provide clear user instructions, app-specific terms, privacy information, support and any legally required licences. These duties do not exclude responsibility of the operator for its own conduct under applicable law.

Each published Gateway has its own storage and an immutable implementation reference. The Runtime provides the execution context while a call is active. Do not assume msg.sender is the end user at every layer, reuse an initialization path without access checks, or rely on the directory name as proof of the contract's publisher.

Your initialization data, implementation address, salt and selected network determine a particular deployment. Test them together, including failed calls, access control, payable paths, permission revocation and user exits. A successful publication receipt establishes deployment and registration for that transaction; it is not a review of business logic or proof that users can withdraw assets.

Before asking a user for an allowance or signature, explain its target, scope, amount and duration. Do not treat the website terms receipt or the Runtime's executingUser field as a token allowance. Avoid unlimited permissions where a narrower authorization suffices and disclose any independent administrative or upgrade powers in your app.

Tariffs and networks

Network gas, owner-funded destination activation, Deed tolls and application payments are distinct. Disclose your own prices and approvals to users; the USD 2 Deed toll cap does not cap app charges. Confirm the active deployment and source finality. Applications must be deployed and integrated on each network where they operate.

A holder may change the toll within the deployed cap. Users must quote the relevant Runtime and respect its revision, maximum toll, deadline, application value and gas limits. Do not represent a displayed quote as a perpetual price or treat a pending destination activation as completed.

Native assets differ by network: the current deployment uses test ETH, test APE on Curtis and native test USDC on Arc. Decimal handling and the network's native payment path must match the deployment; a familiar ticker does not identify a contract or network. An application published on one network is not automatically present on another.

Names, links and user protection

Publish accurate names and HTTPS links without impersonation, malicious content or misleading claims. Obtain rights to submitted content and any necessary personal-data permissions. You authorize the website to display the submitted name, link and public deployment information for the directory. This does not transfer your application code or trademarks to the operator.

Do not use the project’s marks to imply endorsement. Assess laws applicable to your actual users and activity, including any financial, consumer, gaming and data-protection obligations. Technical publication on a Deed is not a substitute for required authorization.

The website records the current profile version and signing wallet. Keep support information and destination URLs accurate, and do not collect data through a linked application without explaining your own processing. The permission to display your submitted name and link is limited to operating and presenting the directory; it does not give the operator a licence to sell your code or use your marks to endorse another product.

Provide users enough information to understand failures and seek assistance, including which transactions and permissions belong to your application. Do not request private recovery material. Distinguish defects in the common protocol from defects in your application. These terms do not grant the operator control of a publisher wallet or the application's assets.