AIP-76: Digital Asset composability

The hierarchy was the whole point

Composition runs in one direction.

A Composable holds traits, digital assets and fungible assets. A Trait holds digital assets and fungible assets. A DA is the leaf and holds fungible assets. Every layer reaches fungible assets through primary_fungible_store from AIP-21, and the wrappers sit on the object model from AIP-10 and AIP-11.¹

The alternative that lost was unconstrained object ownership. AIP-10 already lets any object own any object, and aptos-token from AIP-22 already lets any token compose with any token.¹ Under either, a token minted by someone else can be attached to a token in your collection, and nothing in the type system objects. AIP-76 gives that up in exchange for a fixed path: a trait can only be worn by a composable, a DA can only sit under a trait or a composable.

The cost is paid at mint. A creator classifies each token as Composable, Trait or DA when it is created, and the file specifies no promotion path afterwards. A token minted as a Trait stays a Trait. The limit, stated in the same passage as the claim: the AIP sets the default depth at three and says the tree can be extended to any level, without specifying the mechanism for extending it.¹ Anyone who needs a fourth layer writes it.

THE THREE WRAPPERS AND THE ONLY PARENT EACH ONE ACCEPTS, AS SPECIFIED IN THE DATA STRUCTURE SECTION OF SOURCE 1. THE PERMITTED PARENT COLUMN IS THE ENTIRE DIFFERENCE BETWEEN THIS STANDARD AND AIP-22.

Equip is a transfer plus a freeze

Equip moves the token.

It does not record a pointer while the child sits in the owner's account. The child is transferred to the parent object, its ungated transfer is disabled, it is pushed into a vector on the parent, the parent's uri is updated, and an event is emitted through AIP-44.¹

The alternative that lost was the pointer. It is cheaper, it touches no transfer references, and unequip becomes a vector removal. It fails on custody: the owner can sell the child while the parent still lists it, so the parent asserts a composition the chain does not hold. Freezing the child is what makes the traits vector match the ledger.

The cost is that two objects change state on every equip, and unequip has to reverse them in order. The AIP records that cost in its own API list. unequip_trait carries a note in the published file stating that tests panic.¹ That note was never cleared.

THE EQUIP LIFECYCLE AS SPECIFIED IN SOURCE 1, WITH THE DEPENDENCY EACH STEP CARRIES. STEP 5 IS THE ONE THAT IS NOT DERIVED FROM ON-CHAIN STATE.

The uri is the surface that matters

The parent's uri is written, not derived.

Severity here is argued through the precondition it needs, which is that the string is composed off chain and the chain accepts it. Given that precondition, a composable can display traits it does not hold, and a buyer reading the rendered image is reading an assertion by the seller rather than a view of the traits vector. The AIP names this risk directly: it states that a wrongly updated uri could result in a scam, and proposes enforcing on-chain generation as the mitigation.¹

The mitigation is named and not specified. No function in the API list in source 1 derives the uri from the contents of the traits and digital_assets vectors, and no field in the data structures holds a generation rule.

This ranks above the depth limit and above the panicking test, because it is the only one of the three that costs a third party money. It needs a marketplace that renders metadata rather than object state, and a buyer who does not query the traits vector. My judgment is that both conditions hold on the marketplaces I have integrated against, and the basis is that those integrations read a metadata endpoint, not the object.

No entry functions, and that is why it stalled

The standard ships as a library.

Source 1 states there are no entry functions, and leaves them to more specific implementations. The alternative that lost was the aptos-token model from AIP-22, where the framework carries the entry functions and a creator deploys nothing.

That trade is the one I would revisit first. Giving up the no-code path is what makes AIP-76 arrive without users: a creator cannot mint under this standard without writing and deploying Move, and a creator who is already writing Move can write the composition rules directly. The invariant the standard defines is then only enforced across the calls each integrator chooses to expose.

My read is that the missing entry layer, rather than the hierarchy design, is what left the status line unchanged. The basis is the reference implementation section of source 1, which lists a devnet branch and an SDK described as needing an update, so the file gives a reader no path from reading the spec to minting a token.

What the file claims, and what it does not

The AIP names two addresses.

It states a testnet deployment for March 2024 at 0x24fc1f4cc2c97eba9a33a90cc09cfb27e6cb63c17a80f00a954a57451bdbe644 and a mainnet deployment for late March 2024 at 0xd758b832d4d8fcad58ac7363a6b87af342a6e0dfd25897aa65233c606526e8f4.¹ Both are written in the suggested implementation timeline section, which makes them a plan carrying addresses. This article does not verify on-chain state at either address.

One more thing the file claims that it does not carry: the future potential section applies the standard to gaming, ticketing, real estate and fractional ownership.¹ That paragraph is scope. There is no implementation behind it in the AIP, and it should not be read as evidence for any of the four.

The status line in source 1 read Draft on the date at the top of this article. The next checkable thing is a module listing at the mainnet address above. If it returns composability modules, then the design shipped and the standard did not, and that is a different article from this one.

What this does not cover

Sources

Footnotes

1. APTOS FOUNDATION, AIP-76 Composable Digital Assets standard. github.com

2. APTOS FOUNDATION, Issue #402, [AIP-76][Discussion] Digital Assets Composability. github.com