AtomicAssets v2.0.0-rc3

The AtomicAssets v2 contract, release candidate 3. Built from feat/v2-integration with CDT 4.1.1. This describes the whole v2 feature and supersedes rc1 and rc2.

v2 is a non-breaking, in-place upgrade of the v1 contract. Every existing table keeps its layout and every existing action keeps its signature, so v1 clients and indexers keep working. New capabilities live in new actions and new tables. Upgrading is a setcode (plus setabi on accounts still running v1); existing on-chain state is preserved and no migration action is needed.

What v2 adds

Renting and dual ownership (Feature 300). An asset can be moved to a holder without changing its owner, via the new move action with a logmove notification. Holder state lives in the new holders table: the owner keeps title, the holder has possession, and a burn by the owner clears the holder.

Mutable templates (Features 3 and 6). createtempl2 creates a template with mutable data and settempldata updates it (logsetdatatl logs the change). Mutable data lives in the new templates2 table alongside the original immutable templates row. Feature 6 covers the non-transferable / non-burnable rules for templates.

Delete unused templates (Feature 2). deltemplate removes a template that has no issued assets and cleans up its templates2 entry.

Reduce max supply (Feature 1). redtemplmax lowers a template's max_supply, never below the already-issued supply.

Schema media types (Feature 4). setschematyp records per-field media-type metadata for a schema in the new schematypes table.

Collection author succession (Feature 5). A two-step author handover: createauswap proposes a new author, and acceptauswap / rejectauswap complete or cancel it. Pending swaps live in the new authorswaps table; the collection's author changes only on acceptance.

Backed-asset deprecation (Feature 7). Deprecation handling on the deposit, withdraw, and back-asset path.

Contract-wide CPU optimizations (Feature 8). The hot collection-authorization checks (check_has_collection_auth, notify_collection_accounts) read only the bytes they need from the collection row via a low-level partial read, instead of loading the whole row (which can carry several KB of serialized data) into cache on every schema, template, and asset action.

Self-service RAM utilities. setrampayer and setlastpayer reassign an asset's RAM payer, with a logrampayer notification.

New actions

move, logmove, createtempl2, settempldata, logsetdatatl, deltemplate, redtemplmax, setschematyp, createauswap, acceptauswap, rejectauswap, setrampayer, setlastpayer, logrampayer. Existing v1 actions are unchanged.

New tables

holders, templates2, schematypes, authorswaps. Existing tables (assets, templates, schemas, collections, config, offers, balances, tokenconfigs) are unchanged.

Fixes since rc2

• partial_read_collection auth-path over-read (#12). The Feature 8 partial read deserialized notify_accounts even on the authorized-only path, overflowing its 330-byte buffer once a collection had more than ~38 combined authorized and notify accounts. That threw datastream attempted to read past the end and bricked createschema, createtempl, setschematyp, settempldata, and extendschema for that collection. The auth path now returns after authorized_accounts. Reproduced on jungle4 and covered by a VeRT regression test.
• createcol 24-account cap (#23). addcolauth and addnotifyacc cap each account list at 24, but createcol wrote both lists with no size check, which could seed a collection past the read budget in one transaction. createcol now enforces the same cap.

Build and verification

Built with cdt-cpp 4.1.1. The ABI is the legacy-compat patched build: vector<uint8_t> fields render as uint8[] and pair fields keep their first/second key/value spellings, so integrations that read the ABI do not break. The VeRT suite is green (42 suites). rc3 was deployed to the jungle4 testnet and checked on-chain: the new code hash is live, the formerly-bricking 40-account createschema now succeeds, and createcol rejects a 25-account list.

Artifacts

asset	sha256
atomicassets.wasm	e0e37ac61dd986a22686e01f431f8d68f42d873934f7ba9a891761675487a7b1
atomicassets.abi	b5963843fa0015c7c3b16b818a7506fe7eee5d38daa91ff29588a4e723a11a74

The ABI is unchanged from rc2, since rc3 touches only contract logic. Verify against the attached SHA256SUMS.

Deploying

Pinned by sha256 in the FACINGS monorepo chain-config and deployed via the contracts-deploy workflow using the atomicassets@deploy permission, which is linked to eosio::setcode and eosio::setabi. On an account still running v1 the deploy sends both setcode and setabi; on an account already on a v2 ABI, setabi is skipped as a no-op. Pre-release, for testnet.

Credits

AtomicAssets is an open NFT standard created by Pink Network, with stewardship passing from Pink Network to Spielworks and then to FACINGS. The bulk of the v2 contract was authored by t-break (@on-a-t-break). The interface-header fix is from Aaron Cox (@aaroncox, Greymass). Full attribution is in AUTHORS.md.