A CAW username is an NFT. Who can issue it, where the name is stored, and what its “look” (metadata / image) depends on — if any of that depends on the operator’s server or IPFS, the claim of “on-chain identity” quietly collapses. This item checks the username NFT contract CawProfile on four points: standard, storage, mint path, and metadata generation.

1. Claim (what is verified)

That the username NFT contract CawProfile is (1) a standard ERC-721 (a transferable NFT), (2) stores usernames on-chain, (3) has permissionless minting (no operator permission), and (4) generates metadata/image on-chain with no external (IPFS / server) dependency.

2. Method

3. Verdict

• standard CawProfile is ERC721Enumerable, Ownable, OApp. The username is a standard, transferable NFT.
• on-chain Usernames are stored in string[] public usernames (tokenId→username). Anyone can read them from the chain.
• permissionless Minting is open via CawProfileMinter.mint (no onlyOwner). An unused & valid name (1–255 lowercase alphanumeric) on a first-come basis. The minter is set once and immutable thereafter (onlyOnce).
• on-chain render tokenURI returns the data:application/json;base64,… from CawProfileURI.generate. It renders the SVG from on-chain fonts (FontDataA/FontDataB), with no IPFS/http/server reference. uriGenerator is also fixed via onlyOnce.

So the username identity is self-contained on-chain — name, ownership, and display all within the chain. Even if the operator’s server or IPFS disappeared, the username NFT can still be read, displayed, and transferred.

4. An honest caveat — “username” vs “image”

What is “fully on-chain” here is the username NFT (the name plus the SVG that draws it). Profile avatar images and post images are off-chain (local disk / Filebase = IPFS front). “Content can’t be deleted” holds for text and usernames, but not for images. We handle this distinction honestly in node independence (C-1).

Also, minting requires payment in CAW (costOfName). This is a “price,” not a “permission” — there is no gatekeeper. The validity of the economic flow (staking / fees) is handled in a separate item (E-1).

5. Receipt (public proof)

Anyone can reproduce it. Just read the username, the metadata, and the mint path directly (target: CawProfile on L1).

PROFILE=0x9fcbb3d6880cD3293F1a731Fe6c958a6621a74bF

# username is on-chain (tokenId=1 → usernames[0])
cast call $PROFILE "usernames(uint256)(string)" 0 --rpc-url <Sepolia RPC>

# metadata is generated on-chain (returns data:application/json;base64,…)
cast call $PROFILE "tokenURI(uint256)(string)" 1 --rpc-url <Sepolia RPC>

# mint path (minter) and renderer (uriGenerator). Both fixed via onlyOnce
cast call $PROFILE "minter()(address)"       --rpc-url <Sepolia RPC>
cast call $PROFILE "uriGenerator()(address)"  --rpc-url <Sepolia RPC>

# expected: usernames is a string; tokenURI is data:application/json;base64,… (no IPFS/http)
PASS (name = on-chain / metadata = on-chain render / mint = permissionless)

The minter is CawProfileMinter (0x8D65…90D9); the uriGenerator is CawProfileURI (0x9CEf…274f), which reads fonts from FontDataA (0xB7ec…B8cf)/FontDataB (0x1D08…fBf3). The entry point CawProfileMinter.mint is public payable with no onlyOwner modifier (= permissionless).

6. Notes & limits

This item (A-6) is “verification from the username-NFT angle.” The integrity of the CawProfile contract itself — code match (A-1), ownership (A-2), non-proxy (A-3), provenance (A-4), wiring (A-5) — is verified in those items and assumed here. The off-chain nature of images is handled in C-1, the economic flow in E-1.