Buying an Agent NFT? Check Who Controls Its Wallet

Identify the account, not just the token artwork

ERC-6551 defines a token-bound account relationship using a chain, token contract and token identifier. Its registry address calculation also depends on implementation and salt; one NFT can therefore have multiple accounts. The document permits authorization logic beyond the default token-holder route. [1]

For a real review, retain the network, exact token identity, account address and implementation evidence in a controlled record. A marketplace label such as “Agent42” is not an adequate identifier. An account omitted from the sale description may still matter to the seller’s claimed inventory or operating workflow.

The browser tool uses aliases because its job is graph reasoning, not identification. Give each distinct token tuple its own alias. Use one chain and one declared snapshot per run. If a cross-chain controller is relevant, mark that boundary unresolved and investigate it separately instead of silently equating similar-looking addresses.

A token-owner route is only one authority route

ERC-1271 provides a contract-signature validation interface. Its document expressly allows validation to depend on time, state and the signer’s authorization context. A previously accepted signature is therefore insufficient evidence that the same authority remains applicable to a different operation or later state. [3]

Ask separate questions about the account’s current signers, delegated sessions, module permissions, upgrade control and recovery design. “The NFT now belongs to me” does not answer all of them. A reviewer needs the actual implementation and configuration, including the path used to revoke or constrain residual authority.

The instrument deliberately does not ask the user to select “secure” or “trusted.” It maps one declared ownership relationship and leaves other authorization routes outside the calculation. A circular default route may be serious, but custom authority can change what is possible. Conversely, an apparent external owner does not prove that the reviewer possesses its key or can use it.

Read the arrows as dependencies

Each row names an account, its bound token and that token’s declared owner. If account A is bound to T_A and T_A is owned by account B, the model draws A→B. The arrow means “the token-owner route for A leads to B.” It does not mean A has transferred assets to B.

This is an inventory aid. An “external” endpoint is a declared boundary, not a favorable rating. Naming it UNKNOWN-OWNER and treating it as a normal external address would conceal a real gap; use the explicit unknown state instead.

Model the proposed transfer before changing the graph

ERC-6551 identifies ownership cycles as an accessibility risk. Its broad cycle-prevention problem is left to application and implementation safeguards. [1] DN’s contribution is a bounded, inspectable graph check, not a claim that it implements those safeguards on-chain.

In the first synthetic example, A’s token belongs to external owner ALICE. B’s token belongs to A, C’s token belongs to B, and D’s token belongs to A. All four paths currently end at the declared external owner.

Now model moving T_A to account C. The new route is A→C→B→A. That creates one cycle containing three accounts. D leads into it through A but is not itself part of the cycle. The correct result is three cycle members plus one account leading into the cycle, not a four-account cycle.

The calculation says nothing about whether the token can actually be transferred to C. It also cannot establish whether alternate authority can resolve the resulting structure. Those questions require implementation and state evidence. The proposed change is a scenario, not an instruction to perform it.

One token can affect more than one listed account

The second transfer example binds both A and B to T_A, while C’s token is owned by A. Before the proposed change, T_A belongs to the declared external owner. Moving T_A to B changes both listed bindings’ owner route, because both refer to the same token.

B then points to itself. A leads to B, and C leads to A and then B. The output is one self-cycle, one cycle-member account and two accounts leading into it. “Accounts bound to selected token” is two; it is not a claim that every affected resource was included in the inventory.

This is why the tool rejects inconsistent owners for the same token alias. The same snapshot cannot declare T_A owned by ALICE in one row and by B in another. Keep before and proposed states separate so that an accidental mixture does not become a plausible-looking graph.

Reconcile the assets at the acceptance boundary

ERC-6551’s security discussion describes assets being removed before a token sale completes and suggests marketplace or implementation protections around state or asset commitments. It does not make that protection automatic. [1]

DN’s handover recommendation is to identify the promised assets and the event at which the promise must hold. A screenshot from the listing date and an observation at completion answer different questions. A count of token-bound accounts does not establish either their balances or the seller’s ability to deliver the advertised service.

Use explicit acceptance questions: which account and assets are included; what liabilities, open orders or spending permissions remain; what evidence is current enough for the agreed transaction; and what happens if the delivered state differs? The graph is one input to this review. It cannot replace asset verification or an enforceable commercial arrangement.

Do not infer value from graph shape. Four accounts reaching one owner do not represent four independent businesses, and a cycle count cannot be converted into a discount, probability of loss or token valuation.

Do not confuse an NFT approval reset with a clean account

ERC-721 describes token ownership, transfers and approvals; it resets the token-specific approved address on transfer. Its safe-transfer interface also checks the required receiver response when the recipient is a contract. Neither feature is an audit of everything controlled by a separate account. [2]

ERC-20 defines a different approval relationship: an owner grants a spender an allowance for fungible tokens. [4] If a token-bound account has granted such an allowance, inspect that relationship directly. Do not treat the parent NFT’s approval reset as evidence that the account’s separate spending arrangements disappeared.

Also distinguish receiving the NFT from being able to operate the associated service. A recipient can satisfy a token interface while the application’s authentication, software or external dependencies require further work. The practical acceptance record should say which checks were performed and which remain pending.

Memory, model files and credentials need a separate handover

The local graph contains no model weights, storage policy, licence text or API credential. Its result cannot establish delivery or permission for any of them. A marketed “agent” may depend on several off-chain resources that deserve their own evidence trail.

For each promised component, record a version or manifest reference, the current administrator, the intended recipient, the agreed access change and the acceptance evidence. Keep secrets and personal data out of a shareable worksheet. Reference a controlled record instead of pasting credentials into an article tool.

Separate continuity from approval. A copied memory file may preserve history without proving that the buyer may use every record for a new purpose. A familiar agent name may remain while a model, controller or permission set changes. Review those boundaries under the actual terms and applicable requirements rather than assigning legal rights from a graph.

The most useful closing record is therefore specific: these declared ownership routes were examined; these assets were checked at this boundary; these access changes were completed; these questions remain unresolved. It supports a decision without pretending that one token event proves the entire handover.

Methodology and limits

DN Token-Bound Control Graph v1.0.0. Enter up to 24 rows as account | bound token | owner type | owner alias. Aliases are case-sensitive, start with a letter and contain at most 32 letters, numbers, underscores or hyphens. Owner type is account, external or unknown; an unknown owner uses -. Each account has one binding. Multiple accounts may name the same token only with consistent owner declarations.

For each account, the algorithm follows the declared token-owner route. A repeated account identifies a cycle; an unlisted account or unknown owner leaves the path unresolved; a declared external owner ends the path outside the graph. Every account occupies exactly one category: cycle member, leads into a cycle, unresolved path or external-rooted. The four counts sum to the number of declared accounts. Each distinct cycle is counted once.

In proposed-transfer mode, the selected token must already be listed. The tool substitutes its declared owner for every account bound to it and recomputes the graph. It compares the cycle membership sets before and after and reports new and removed structural cycles. Inspection mode rejects filled transfer fields instead of silently ignoring them. No balance, value, probability or actual signer state enters the calculation.

The model follows one declared ownership route per account. It omits additional signers, delegated modules, allowances, recovery, upgrades, cross-chain control and unlisted accounts. A cycle is not a verified loss event; an external root is not verified control. The tool does not resolve identifiers, authenticate a snapshot, inspect bytecode or determine whether a transfer can succeed. All outputs remain conditional on the supplied graph.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "urn:dn:record:dn-token-bound-control-graph:1.0.0",
  "title": "DN Token-Bound Control Graph record",
  "type": "object",
  "additionalProperties": false,
  "required": [
    "schemaVersion",
    "recordType",
    "createdAt",
    "articleSourceReviewDate",
    "inputEvidenceStatus",
    "inputBasis",
    "exampleLabel",
    "engineVersion",
    "inputs",
    "result"
  ],
  "properties": {
    "schemaVersion": {
      "const": "1.0.0"
    },
    "recordType": {
      "const": "dn-token-bound-control-graph"
    },
    "createdAt": {
      "type": "string",
      "format": "date-time"
    },
    "articleSourceReviewDate": {
      "const": "2026-11-13"
    },
    "inputEvidenceStatus": {
      "const": "user_entered_not_independently_verified"
    },
    "inputBasis": {
      "enum": [
        "user_entered",
        "illustrative_example",
        "illustrative_example_modified"
      ]
    },
    "exampleLabel": {
      "type": [
        "string",
        "null"
      ]
    },
    "engineVersion": {
      "const": "1.1.0"
    },
    "inputs": {
      "type": "object",
      "additionalProperties": false,
      "required": [
        "scopeLabel",
        "bindings",
        "mode",
        "transferToken",
        "recipientType",
        "recipientAlias"
      ],
      "properties": {
        "scopeLabel": {
          "type": "string",
          "maxLength": 80,
          "minLength": 1
        },
        "bindings": {
          "type": "string",
          "maxLength": 16000,
          "minLength": 1
        },
        "mode": {
          "type": "string",
          "enum": [
            "inspect",
            "proposed_transfer"
          ]
        },
        "transferToken": {
          "type": "string",
          "maxLength": 32
        },
        "recipientType": {
          "type": "string",
          "enum": [
            "none",
            "account",
            "external",
            "unknown"
          ]
        },
        "recipientAlias": {
          "type": "string",
          "maxLength": 32
        }
      }
    },
    "result": {
      "type": "object",
      "additionalProperties": false,
      "required": [
        "summary",
        "metrics",
        "findings"
      ],
      "properties": {
        "summary": {
          "type": "string"
        },
        "metrics": {
          "type": "array",
          "items": {
            "type": "object",
            "additionalProperties": false,
            "required": [
              "label",
              "value"
            ],
            "properties": {
              "label": {
                "type": "string"
              },
              "value": {
                "type": [
                  "number",
                  "string",
                  "null",
                  "boolean"
                ]
              },
              "unit": {
                "type": "string"
              },
              "note": {
                "type": "string"
              }
            }
          }
        },
        "findings": {
          "type": "array",
          "items": {
            "type": "object",
            "additionalProperties": false,
            "required": [
              "level",
              "text"
            ],
            "properties": {
              "level": {
                "enum": [
                  "note",
                  "warning",
                  "error"
                ]
              },
              "text": {
                "type": "string"
              }
            }
          }
        }
      }
    }
  },
  "allOf": [
    {
      "if": {
        "properties": {
          "inputBasis": {
            "const": "user_entered"
          }
        }
      },
      "then": {
        "properties": {
          "exampleLabel": {
            "type": "null"
          }
        }
      },
      "else": {
        "properties": {
          "exampleLabel": {
            "type": "string",
            "minLength": 1
          }
        }
      }
    }
  ]
}

Related DN research

• How Do You Know an AI Agent Is Actually Trustworthy?
• The Agent Passport: How Machines Could Prove Identity, Authority and Risk
• Agent Revenue Is Not Your Payout: Audit the Token Holder’s Rights

Frequently asked questions

Sources and review dates

1. [1] ERC-6551: Non-fungible Token Bound Accounts. Creation date shown; status Review at review. Binding/interface, implementation-dependent authorization and documented transfer/cycle risks. No deployment tested. Reviewed 2026-11-13. Source date: 2023-02-23.
2. [2] ERC-721: Non-Fungible Token Standard. Creation date shown; Final. Ownership, transfer, token-specific approval reset and safe-receiver boundary. Reviewed 2026-11-13. Source date: 2018-01-24.
3. [3] ERC-1271: Standard Signature Validation Method for Contracts. Creation date shown; Final. Contract signature validation may depend on state, time and signer context. Reviewed 2026-11-13. Source date: 2018-07-25.
4. [4] ERC-20: Token Standard. Creation date shown; Final. Separate fungible-token owner/spender allowance interface. Reviewed 2026-11-13. Source date: 2015-11-19.