Token-Bound Executable Skills — the artifact identity & integrity layer under skill registries (ERC-721 extension)

Summary We propose an ERC-721 extension that binds a token to an executable skill : a package of files, led by a primary Markdown document, that an off-chain runtime (including LLM agent runtimes) can fetch from anywhere, verify byte-for-byte against on-chain anchors, and execute. On-chain, each token carries a SkillBinding : mdHash (SHA-256 of the plaintext primary document — a commitment that survives encryption), packageHash (SHA-256 of a deterministically encoded, content-addressed object graph — the SkillRoot — covering every file execution depends on), and a contract-incremented version with a closed prev chain. Around it: a mutable packageURI that is transport, never trust; an update authority that is a publication right separate from ERC-721 ownership; and an irreversible freezeSkill . Optional layers: an on-chain plaintext primary document (permanent once published), and an in-package confidentiality descriptor — encryption is a package property, not a token flag, so ciphertext integrity is verifiable before any key is released. This proposal intentionally does not define registries, discovery, installation, attestation, reputation, access, licensing, or settlement. Relationship to skill and tool registries ERC-8239 and ERC-8257 are building the registry layer: where a skill or tool is registered, how it is discovered, installed, and attested. This proposal sits underneath that layer and answers a different question: exactly what executable bytes, package version, and publication history does the token commit to? An ERC-8239 SkillRegistry token could optionally implement this interface on the same tokenId; an ERC-8257 tool manifest could reference a token-bound artifact externally. One concrete thing this unlocks: usage and installation attestations can pin packageHash + version , so when a skill moves from v1 to v2, historical attestations still resolve to exactly the v1 bytes rather than to a moving head. Registries answer where a skill is registered and how agents relate to it. This proposal answers what the token commits to. Motivation AI agents have on-chain identities (ERC-8004) and smart accounts (ERC-4337), and skill/tool registries are emerging (ERC-8239, ERC-8257) — but the artifact itself still lives as unverifiable, silently mutable content behind a URI. That is the root condition of registry supply-chain attacks: the same name, the same entry, different bytes. tokenURI cannot fix it; it is a display pointer with no integrity guarantee. Two hashes and a URI alone would just be custom metadata. What makes this a standard is the normative object model beneath them — a deterministic DAG-CBOR graph with per-file CIDs and a closed, append-only version chain — which defines exactly what the commitments protect, byte for byte, and lets any independent implementation reproduce them. This is running, not proposed on paper Specification frozen (full draft text in the reply below; SHA-256 779C7F9D…D274A68D ). Reference implementation, public and CC0 — release v1.0.0 : Solidity contracts ( ISkillToken = 0x734553a6 , IOnchainSkillDocument = 0x7050dd2c , compiler-verified), a zero-dependency Python packer/verifier implementing the deterministic encoding, JSON Schemas, and a Foundry suite where every MUST clause of the spec is one of 12 passing assertions . Six frozen test vectors built from a real production skill (public / confidential / license-encrypted / custom primary path / companion-only update / key rotation), plus path negative tests — reproduced byte-for-byte across five independent machines. Across all six, the plaintext mdHash stays constant: one document identity surviving encryption, re-packaging, and key rotation. Live on Sepolia : 0x12cc1a5319c6F08bFB50982e3814A376A59fE550 . Skill Token #1 is the public-v1 frozen vector; its mint tx (block 11261685) carries mdHash ‖ packageHash ‖ version verbatim in the genesis SkillUpdated event — the skill’s fingerprints are part of public chain history. Verify it yourself , no local setup beyond cast : bash cast call 0x12cc1a5319c6F08bFB50982e3814A376A59fE550 \ "skillOf(uint256)((bytes32,bytes32,uint64))" 1 \ --rpc-url https://ethereum-sepolia-rpc.publicnode.com # returns (mdHash, packageHash, version) — then check the real package against them: python3 tools/skill-pack/verify.py vectors/public-v1 --mdhash --packagehash Deliberately out of scope Rental, subscription, metering, delegation, gated upgrades, and license issuance are left to companion extensions. A skill’s token reference is singular; its usage value must scale — rights contracts (typically ERC-1155) reference the skill externally via SkillRef = (chainId, skillContract, skillTokenId) . A companion metered-license proposal will follow. Open questions for the community Registry composition : for ERC-8239-style registries, is same-tokenId optional implementation of ISkillToken the right composition pattern — and should usage/installation events pin packageHash + version so historical attestations keep exact-version precision? Versioning shape : one token per skill with a closed version chain, versus a new token per version — the latter preserves history but fragments the skill’s identity across tokens. Where should the community land? Rights layer : we are drafting the ERC-1155 companion ( skillRefOf , issuance, metering). Teams interested in co-designing it? Confidentiality profiles : the descriptor treats profile as opaque (threshold networks, TEE custody…). Should a lightweight profile registry exist, and where? Deterministic encoding : we chose DAG-CBOR (RFC 8949 deterministic rules) with 37-byte identity-prefixed CIDv1 links — feedback from IPLD implementers very welcome. On-chain document permanence : hasOnchainSkillDocument is monotone (once true, forever true) because chain history makes disclosure irreversible — should the interface reflect that reality? Authors Gary Yang (@ garyyang-finchip ) Thanks to @bransdotcom for an early discussion on versioning. 2 posts - 1 participant Read full topic