graveth

Graveth brings Bitcoin's inscription philosophy to EVM chains. Store any content (SVG, text, images) directly in smart contract state with MIME type declarations. No IPFS. No servers. Just the chain. tokenURI() returns a data: URI assembled entirely on-chain. open DevTools and you'll see zero external requests to render your NFT. The content IS the blockchain. Permissionless minting (like Bitcoin), ENS subnames for human-readable inscription IDs, and EVM portability: same contract deploys to Sepolia and Polkadot Hub. "What if your NFT worked like a Bitcoin inscription?"

Smart contracts built in Solidity with OpenZeppelin ERC-721 and Foundry. The core Graveth.sol stores content as raw bytes alongside MIME type strings. tokenURI() assembles a complete data: URI on-chain using Base64 encoding, so the NFT renders with zero external requests.

Frontend is Next.js via Scaffold-ETH 2, connected with wagmi + viem. File uploads are base64-encoded client-side and passed directly to the inscribe() function.

ENS integration was an interesting part: Claude and I deployed a custom GravethRegistrar.sol that registers ENS subnames (e.g. myart.graveth.eth) pointing to inscription token IDs. ENS becomes a human-readable index for on-chain content; not just name resolution, but content discovery.

Multi-chain: same contract deployed to Sepolia and Polkadot Hub Paseo (Chain ID 420420417), proving EVM portability with zero contract changes.

MVP scope: inscriptions limited to SVG and plain text files under 15KB to keep gas costs reasonable. The MIME type system supports any content type; larger files and formats (PNG, PDF) are a post-hackathon goal using hybrid on-chain hash + decentralised storage.

Important fact: the entire NFT rendering pipeline has no off-chain dependency. Open DevTools Network tab on any Graveth NFT (zero requests). The image is reconstructed purely from contract storage. That's the point.

For information in the README.md of the repo