Skip to article content
Azuki

Azuki PBT: Comparing v1 and v2 Transfer Checks

updated

The Azuki team's Physical Backed Token links an NFT to a physical item through a signing chip. Its reference implementations require chip-authorized transfers: legacy v1 checks eligibility with blockhashes, while v2 uses timestamps.

Legacy v1 Timing
Blockhash-based transfer eligibility; the reference documentation labels this implementation legacy.
v2 Timing
Timestamp-based transfer eligibility. The reference guidance recommends a non-deterministic nonce for v2 signatures.
Chip Requirements
An attached chip that generates and stores an ECDSA secp256k1 keypair and signs messages. Its public key is retrievable; its private key must remain non-extractable.
Token Transfer Route
An account-bound ERC-721 implementation that rejects ordinary ERC-721 transfers. PBT uses transferToken with a chip signature to authorize ownership changes.

Blockhash Timing and Timestamp Timing

Faster block production changes the relationship between a block-based check and elapsed time. The PBT reference documentation cites faster L2 blocks as the reason for v2's timestamp-based approach. In the v2 reference implementation, a configured signature window bounds the permitted signature age.

v2's timing change leaves chip authentication in place. Its reference implementation also uses the preceding blockhash when updating a chip's nonce. The blockhash contributes to nonce variation, while timestamps determine eligibility within the configured window.

v2 Reference Transfer Checks

The v2 PBTSimple reference implementation receives maxDurationWindow in its constructor. Its transfer path follows this order.

Stage Input v2 Check or Action Rejection or Limit
Chip Lookup Chip address Resolves its paired token ID. Zero or unmapped chip addresses fail.
Timestamp Signature timestamp and validity window Checks the signature timestamp against the current block timestamp and configured validity window. Future or expired timestamps fail.
Signature Context Contract address, chain ID, chip nonce, recipient, timestamp and extras Builds the signing digest. The signature must match these inputs.
Chip Authorization Chip signature Verifies the signature and updates the chip's nonce. Invalid signatures revert.
Transfer Token, recipient and transfer mode Transfers the existing token. The token must exist. Safe mode requires ERC-721 receiver support for contract recipients.

A timestamp at the exact expiry boundary passes the age check; the remaining transfer checks still apply.

Signing Inputs and Chip Registration

The signing interface must match the collection's deployed contract, including its version and required signature inputs. The reference README labels the repository beta and allows custom implementations. Its examples do not establish a particular collection's configuration.

Azuki PBT: Signing Inputs and Chip Registration - illustration

View full-size image

The documented approach requires implementers to save chip public keys before selling or shipping physical items. The contract uses addresses derived from those keys to recognize the chips that may mint and transfer tokens. A scanning frontend supplies the chip signature; the contract applies the eligibility and authorization checks.