- Home
- Skills
- Raintree Technology
- Claude Starter
- Object Model
object-model_skill
62
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill raintree-technology/claude-starter --skill object-model- SKILL.md5.6 KB
Overview
This skill is an expert guide to the Aptos Object Model for building composable, transferable on-chain assets. It explains ObjectCore, the Object<T> wrapper, ConstructorRef/ExtendRef/TransferRef/DeleteRef capabilities, ownership models, named vs generated objects, and composability patterns. Practical examples show common patterns like soul-bound tokens, nesting, registries, and upgradeable data.
How this skill works
The skill inspects how objects are created, addressed, and managed via constructor references and derived capability refs. It explains deterministic named objects versus non-deterministic generated objects, how refs are stored at the object address, and how transfer/delete/extend operations are gated by specific refs. It also covers lifecycle flows: create, extend, transfer, and delete while preserving ownership separation between owner address and object address.
When to use it
- Designing transferable or composable NFTs and tokens
- Creating soul-bound tokens or intentionally non-transferable assets
- Building nested/composable assets where objects own other objects
- Implementing singletons or registries using deterministic addresses
- Managing upgradeable on-chain module data with controlled extend capabilities
Best practices
- Generate all needed refs at creation; treat ConstructorRef as ephemeral
- Store capability refs at the object address rather than the creator address
- Use named (seeded) objects for singletons and deterministic resources; use generated objects for collections
- Disable ungated transfer for soul-bound assets and use linear transfer refs for one-time transfers
- Always remove or move out resources before calling delete on an object; document ownership hierarchies clearly
Example use cases
- Soul-bound identity token: create named object, disable ungated transfer, perform a one-time linear transfer to recipient
- Composable NFT: create parent object, mint child object, transfer child to parent address to nest
- Registry singleton: use a named object with a registry struct stored at the object address
- Upgradeable module config: store ExtendRef in a DataRefs resource and generate signer for controlled upgrades
- Force-recover asset: use TransferRef.transfer_with_ref to move assets in emergency
FAQ
Storing refs at the object address ensures capability ownership follows the object lifecycle and prevents creator-only control after transfer.
When should I use named vs generated objects?
Use named objects for deterministic singletons or registries keyed by seed; use generated objects for unique, non-deterministic assets or large collections.
How do I make an object permanently non-transferable?
Disable ungated transfer via the TransferRef and avoid storing any transferable refs; for one-time assignment, use a linear transfer ref and then discard it.