Bajigur

Demo

About

Bajigur is a shop for motion and web design prompts where the buyer can be a person or the AI agent working for them. Every prompt carries its own price, usually a few cents, and you pay for the one you use instead of a monthly plan. For a person it works like any website. You sign in with an email, Privy creates the wallet for you, we create and fund your Hedera account, and you claim a free name under bajigur.eth, for example claude.bajigur.eth. Buying is one button. There is no seed phrase to write down, no browser extension to install, and no signing popup on every purchase. For an agent it is three tools over MCP. Paste https://mcp.bajigur.xyz/mcp into Claude Desktop, Claude Code or Cursor and the agent can search the catalogue, list the prompts your wallet already owns, and fetch one. When it fetches a prompt you have not bought, the server answers with a payment request over x402, the agent pays on Hedera, and the text comes back in the same response with the transaction id attached. Nothing is cloned, nothing is installed, and no private key sits on the machine. The money goes straight to the creator. Their payout account is not stored in our database; it is the bajigur.hedera text record on their ENS name, read at the moment payment is quoted, so a creator changes where their next payment lands by editing a record they own. Every purchase mints an ERC-1155 licence to the buyer, so the same prompt is free to read again from any client afterwards, and that licence is what grants access rather than a row in our database. Creators build a public record too. A buyer who holds a licence can rate the creator, and the rating is written to the ERC-8004 reputation registry on Hedera, signed and paid by the buyer's own wallet so it cannot be faked by us or by the creator. The score comes back in the catalogue listing, which means an agent comparing two prompts can weigh who wrote them without a second lookup. Everything runs on public testnets and can be checked by anyone. The x402 challenge, the catalogue, the creator profiles and the discovery feed are all open endpoints, and docs/verify.md in the repo is a list of copy and paste commands that verify each claim against Hedera and Sepolia directly.

How it's made

The repo is a Bun workspace monorepo driven by Turborepo, around 9,300 lines of TypeScript and Solidity across 100 source files, plus the tests. apps/api is Bun with Hono. It is an x402 v2 resource server built on @x402/hono over @x402/core and @x402/hedera, settled by the Blocky402 facilitator on Hedera testnet. Only GET /prompts/:id/unlock is paid; the price and the payTo are resolved per request from the prompt itself, so each creator is paid directly instead of through a platform account. Published prompt bodies live in Postgres on Railway, where the API is deployed. apps/mcp is the MCP server, Streamable HTTP and stateless, carrying the x402 client. It runs two ways: locally over stdio with your own Hedera key, or hosted at mcp.bajigur.xyz where you sign in with OAuth and the API signs for you, so the machine holds no key at all. apps/web and apps/landingpage are Next.js 16 with React 19, the React Compiler and Tailwind v4, on Vercel. contracts is Foundry: PromptRegistry, an ERC-1155 that records listings and issues licences, on Hedera testnet, and BajigurRegistrar, our ENSv2 registrar, on Sepolia. Both are verified. Hedera. Every prompt is priced twice, in USDC (HTS token 0.0.429274) and in HBAR, and both appear in the 402 so the client chooses which asset to spend. After settlement the API writes one JSON record to an HCS topic and mints the licence. Contracts never sit in the payment path, because an x402 payTo on Hedera has to be a 0.0.x account and not a contract, so the facilitator settles a plain HTS transfer and the contract only records what happened afterwards. A returning buyer is checked with balanceOf through the mirror node's free contracts/call endpoint, so proving you already own something costs nothing and skips the 402 entirely. Privy. The user grants our signer on their embedded wallet, the API creates and funds their Hedera account and associates USDC, and from then on signs their x402 payments with secp256k1_sign. That is what removes the wallet popup from the purchase, and it is also what lets someone who has never held a token buy a prompt. ENS. bajigur.eth has its own ENSv2 subregistry on Sepolia behind BajigurRegistrar, which enforces the rules in Solidity: one free name per wallet, three to thirty-two characters, ten years. claimFor registers the name to the user's own wallet and writes their Hedera account into the bajigur.hedera record in the same transaction, with the platform paying the Sepolia gas, because a name without that record would send the owner's buyers to us by mistake. ERC-8004. Identity and reputation registries are already deployed on Hedera testnet as singletons, so this is Hedera and ERC-8004 at once, with HBAR for gas and HashScan for the receipts. The first time somebody rates a creator we mint their agent, write their ENS name into its onchain metadata, hand the token to the creator's own wallet, and write erc8004 onto their ENS name, so name and agent point at each other in both directions. Four things that cost us real time and are worth writing down. HBAR payments were refused while the account held 107 HBAR. The x402 client's default spend controls allow stablecoins only, and that filter runs before our payment selector, so the HBAR option was already gone by the time we tried to pick it. We proved it by running both versions against the real 402 and printing what each chose. The fix is one shared policy that names HBAR in allowedAssets and selects it, used by the MCP wallet and the web path alike. Privy's embedded wallets run in a TEE, where delegateWallet throws. The TEE equivalent is addSigners with a key quorum id, which is what we call, and it is idempotent, so reconnecting a wallet that is already granted is safe. Privy policies cannot gate secp256k1_sign, so spend caps could not live in Privy. Our API decodes the Hedera transaction body before signing and refuses anything that does not debit the user's own account, credit a known creator payout account, and stay under the cap baked into that user's token. The hosted MCP server does OAuth, and the first version kept registered clients and authorization codes in memory. That works in dev and fails in production, where every request can land on a different serverless instance: a client registered seconds earlier came back as invalid_client. Both are now self-contained strings sealed with AES-256-GCM, so any instance can serve any request, and we verified it by registering, waiting, and probing again. One last note on the browser. The x402 challenge travels in the PAYMENT-REQUIRED response header, and the API deliberately does not list it in Access-Control-Expose-Headers, so a page cannot read it cross-origin. The web app therefore runs the entire payment inside a route handler, which has the useful side effect of keeping the agent token in an httpOnly cookie and the Hedera SDK out of the client bundle.