Sandbox lets creators test Experiences, verify ownership, and control when their work becomes available

Begin with a reversible draft

An account and a saved draft provide a practical starting point. At this stage, a creator can build an Experience, edit its logic, and test its content without making an on-chain commitment.

A wallet is not required to use the free no-code creation tools.

Before changing a project, note its saved name, dimensions, Asset set, and current publishing state. Those details form the starting record. A later check should show exactly which element changed, while everything outside that change remains intact. Duplicating a project may also preserve a useful baseline when testing an update that could affect gameplay or compatibility.

Game Maker supplies the editable environment and play testing tools. Saving confirms that the draft exists, but it does not prove that an Experience Page is public, the Experience is on the Map, or every Asset is owned. Each of those outcomes has a separate verification point.

Move from local testing to public availability

A tested Experience can be shared in the Game Maker Gallery before it is launched on LAND. This route supports feedback and revision while the project remains outside the Map publishing process.

A creator may also prepare an Experience Page without owning LAND. The page presents the project through its name, descriptions, media, and other required fields. Publishing that page is separate from launching the playable Experience on the Map, so its visible status should be checked independently.

Self-publishing an Experience on the Map requires locating it on LAND that the creator owns.

The Experience Manager also checks the Assets used in the build. Tested Marketplace Assets may appear in a project even when the creator has not purchased them, but ownership is required before launch. Once the required actions show as Ready, launching changes the project from a prepared record into a launched Experience whose availability follows its access settings. Confirm the Map location, public page, and playable state rather than treating the launch click as sufficient evidence.

What changes require a wallet signature?

Wallet signatures are relevant when an action uses wallet ownership, grants a permission, or submits a blockchain transaction. Buying an NFT, transferring a token, bridging supported assets between networks, and interacting with a contract may create requests that look similar but have different effects. An authentication signature can prove control of an address, while a transaction can move value or change an on-chain permission.

Read the wallet request before approving it. Check the selected network, destination, token, quantity, spending permission, and any displayed network fee. Some operations separate an approval from the transaction that uses that approval, so one confirmed step may not complete the intended purchase or transfer. Completion evidence is the expected confirmed record and resulting ownership state, not the disappearance of a popup.

Match each change to the right record

Different actions leave evidence in different places. A saved draft belongs in the workspace, a published Experience Page has a public status, and a launched Experience appears at its assigned Map location. Token ownership and transfers are represented by wallet and blockchain records. One record cannot substitute for another merely because the actions occurred close together.

Compare the result with the starting state and the intended change. A new wallet balance without the expected NFT, for example, does not establish that a purchase completed as planned. Likewise, a public page does not prove that its associated Experience is open for play. Continue only after the record that belongs to the action shows the accepted state.

SAND carries value across the ecosystem

SAND is an ERC-20 utility token used as a medium of exchange in The Sandbox ecosystem. It can support purchases, eligible rewards, staking, and governance participation under the applicable conditions. SAND can exist on Ethereum and Polygon, making the network part of the transaction state. A balance on one network does not establish that funds are ready on another, so the selected chain must match the intended operation before approval.

LAND connects ownership to publishing

LAND is an ERC-721 token that represents virtual real estate on the Map. The map contains 166,464 LAND tokens, and each parcel has a defined position. Ownership establishes where a qualifying Experience can be located and launched. It does not replace the creative work performed in Game Maker or the Asset checks performed during publishing.

Creators can build, test, and present projects without LAND, which keeps early work separate from the ownership commitment. Map publication adds a location requirement. A larger Experience needs enough LAND in the matching arrangement, while its orientation and footprint must fit the selected space. The relevant LAND must remain available to the Experience owner when location is assigned.

Asset rights define the launch boundary

Assets made with VoxEdit can populate an Experience with objects and interactive content. A creator-made Asset does not need to be minted as an NFT merely to be used in the creator’s own Experience. Publishing can still require the Asset to have the appropriate public status and to belong to the Experience owner.

Marketplace previews create a useful boundary between testing and ownership. The test function can place an Asset in the Game Maker library so its appearance and behavior can be assessed before purchase. That preview does not grant the right needed for publication. Before launch, either acquire the required Asset or remove it from the build, then run the ownership check again.

Reconcile delayed or incomplete results

A confirmed blockchain action and an updated account display may not appear at the same moment. Network congestion can delay confirmation, while the platform inventory may take additional time to reflect a completed purchase. Check the transaction on the relevant chain, confirm the address and token result, then compare that record with the account inventory.

A pending record calls for waiting and checking, not an immediate duplicate submission. Repeating an action without knowing the first result can create an unintended second transaction or another approval. A failed or rejected request has a different state: determine whether any on-chain record was created before deciding whether to retry.

Off-chain publication states need similar discipline. If a required item remains pending, inspect that item rather than relaunching the whole workflow. Asset ownership, page fields, LAND location, and access settings are separate conditions. Correct the one that failed, save the change, and confirm that its status moved to the expected state.

Can you reverse a published change?

Some publication changes are reversible, but blockchain transfers generally are not. The available path depends on whether the action changed editable content, public availability, location, or token ownership.

A published Experience Page can be edited, and saved changes affect the public page. It can also be unpublished. A launched Experience may be closed, which removes its availability and unpublishes its landing page while retaining its setup. Its Map location cannot be changed while it remains launched and open. Moving it therefore requires closing it, selecting a valid new location, and launching it again.

A completed transfer sits outside those content controls. Closing an Experience or disconnecting a wallet cannot cancel a finalized token movement. Reversibility should therefore be assessed before signing, while the destination, network, amount, and permission are still reviewable.

Checkpoints before commitment or exit

Proceed only when every applicable item has a matching record.

• Identify the starting state: saved draft, page status, Map location, connected address, network, and relevant holdings.
• Name the intended change precisely, such as saving a draft, publishing a page, launching an Experience, purchasing an Asset, or closing access.
• Confirm the prerequisite that governs it, including Asset ownership, suitable LAND, required page fields, wallet funds, or the correct network.
• Choose the acceptance evidence before acting, such as a Ready state, public page, playable Map entry, confirmed transaction, or expected wallet holding.
• Stop when the request shows an unexpected address, permission, fee input, unresolved pending state, or result that differs from the starting record.

This check separates an editable action from a commitment. If the acceptance evidence appears, continue from the new recorded state. If it does not, preserve the current records and resolve that mismatch first. Adding unrelated changes makes reconciliation harder and can obscure which action produced the result.

Exit without confusing access with ownership

Closing an Experience, unpublishing its page, and disconnecting a wallet are different exit actions. Closing removes the Experience from availability while retaining its configuration. Unpublishing affects the page. Disconnecting a wallet removes account access to that wallet’s data through The Sandbox website and software.

Wallet disconnection does not delete the account, the wallet, or the digital assets recorded for its address. Smart contract activity also remains unchanged. Content, claims, rewards, or proceeds associated with the previously connected address may no longer appear through the account after another wallet is connected, so the old address and its relevant records should be reconciled first.

Open full-size image

After the chosen exit is visible, lock the wallet when it is not in use and retain the transaction or publication record needed to resume later. A closed Experience can be launched again, and the same eligible wallet can reconnect to its original account. None of these actions can undo a completed transfer to another address.