Azuki uses chip signatures to authorize PBT ownership transfers.

Azuki links a Physical Backed Token (PBT) ownership transfer to a signature from the physical item's chip. To confirm completion, match the chip to its token, authorize the intended transfer, and check the successful transaction against the recorded recipient. A scan alone does not change ownership. The deployed contract determines the signature format and the conditions that it accepts.

A physical handover and a digital transfer leave different evidence. Possession gives access to the embedded chip, while the token contract records an address. Keeping those facts separate helps explain a completed transfer, an unfinished request, or a rejected signature.

A chip signature that meets the contract's requirements authorizes the transfer request; the transaction receipt and recorded token owner establish whether the ownership change completed.

Chip Access Before Wallet Submission

A transfer scan must obtain the chip signature that the selected contract requires; an unrecognized chip can indicate a scanning problem or a missing chip-to-token association. The normal transfer path therefore starts with the physical item, compatible scanning software, and its collection contract. Repeating wallet confirmations cannot repair a missing association.

The scanning application must support the chip's signing operation, rather than merely read an identifier. PBT requires hardware that can sign messages while protecting its private key. A notification that a phone detected a chip does not, by itself, establish that the application obtained the required signature.

The Recipient and Transaction You Authorize

The transfer request must identify the intended collection and destination before submission, because a recognizable item name does not uniquely identify a contract.

Collection Identity and Token State

The collection contract and token identifier together identify the digital item. Another contract can reuse the same collection name, symbol, or token number. Compare the actual contract identity throughout the scanning application, wallet request, and ownership lookup.

A chip mapping also needs an existence check. In the v2 interface, tokenIdFor can identify a paired token number even before minting creates that token. A successful ownerOf lookup establishes that the token exists and identifies its recorded owner. An unminted item requires its collection's minting operation, whose conditions can differ from transfer conditions.

Contract Destination and Token Recipient

A transaction's outer destination identifies the contract that executes the request. The token recipient can appear separately inside the decoded call. Compare both addresses; treating the contract address as the receiving wallet confuses two different roles.

Wallet authorization permits submission of the transaction. The review should therefore cover the selected network, contract operation, recipient, attached value, and estimated network fee. An unreadable request leaves those details unresolved. Signing the wallet transaction and generating a chip signature are separate operations.

What Does a Successful Scan Prove?

A successful signature check establishes that the relevant chip signed particular data; it does not establish that a transfer executed. PBT's physical assurance also depends on the chip remaining attached to the correct item. The protocol does not prevent damage, substitution, or removal of that hardware. A digital authenticity check therefore cannot replace inspection of the object and its attachment.

Transfer Parameters in the v2 Interface

The v2 transfer interface distinguishes the recipient, chip identity, signature, timestamp, and receiver-check option. These parameters describe the reference interface, not a promise that every existing collectible uses v2. Its transfer call also accepts extra data for implementation-specific logic.

The v2 reference implementation validates the signed destination and timestamp before transferring the token. Its safe-transfer branch also checks contract recipients through the underlying NFT implementation.

Legacy Block Hashes and Timestamp Windows

Legacy v1 uses a block hash for signature freshness, while v2 uses a timestamp. A software update does not establish that an existing collectible's deployed contract changed versions. The scanning application must produce the format that the particular contract accepts.

In the v2 reference implementation, maxDurationWindow sets the permitted signature age at deployment and remains immutable for that contract. The current block timestamp advances. A signature must be no later than that timestamp and no older than the configured window.

Receipt Status and the Recorded Owner

A successful transaction receipt establishes execution, while the token's ownership record identifies the address that currently holds it. Both matter when confirming a transfer.

Transaction Execution

A transaction hash identifies a request; it does not establish success. Pending transactions have no execution receipt. A receipt can report either success or failure, so the existence of a receipt alone is insufficient. Its block information also locates the execution in the chain.

The receipt's logs identify events that the transaction produced. For an NFT transfer, match the emitting collection contract, token identifier, and recipient. A successful transaction involving another token or operation does not confirm the intended handover.

Ownership at the Relevant Block

The ERC-721 function ownerOf returns the owner address for an existing token. Compare that address with the intended recipient using the correct collection contract.

A historical transfer event and a later ownership lookup can differ after a subsequent transfer. Compare their block context before treating the difference as a failed operation. Ethereum distinguishes block inclusion from finality; a newly included receipt does not yet have the same settlement assurance as a finalized record.

Read Checks Versus State-Changing Calls

Reading a token's owner through an ordinary offchain contract call does not require submitting a transaction. Executing a transfer does. This distinction explains why viewing a record can work even when the account lacks the funds needed to submit an ownership change.

The network fee depends on transaction execution and network fee conditions. A chip signature does not establish the fee, and raising a fee cannot make an invalid signature acceptable.

An Unrecognized Chip at the Transfer Screen

An unrecognized chip requires checking its association with the selected collection before attempting another transfer. The v2 reference implementation rejects a lookup when it cannot find the corresponding mapping. That error identifies a contract-level association problem, rather than proving that the phone failed to detect the hardware.

The first distinction is whether the application obtained a chip identity at all. Without one, the scanning connection remains unresolved. With an identity but no matching token, compare the selected collection and item association. Repeatedly paying for a transaction cannot create that missing relationship. Any repair must follow capabilities that the deployed collection actually exposes.

View full-size image

Physical Custody After Digital Confirmation

Control of the physical chip remains relevant after the token reaches its destination. PBT ties future transfer authorization to chip access, so a recorded token transfer does not prove that a parcel arrived or that someone relinquished the object. Before completing a handover, establish who will retain the item and access to its chip.

Azuki questions worth asking

9 September 2026 · updated