New Token Standards
Agent standards the WICK agentic network runs on — plus AI-native ERCs & community fitAgent Payments (HTTP 402)
How it works
Revives the dormant HTTP 402 "Payment Required" status code into a real payment rail. A server answers an unpaid request with 402 + payment requirements; the client (an AI agent) attaches a signed stablecoin payment header; a facilitator verifies and settles it on-chain (USDC on Base, plus Polygon/Arbitrum/Solana); the server then returns the data. No accounts, no API keys, no sessions — machine-native pay-per-call. V2 (2026) adds wallet-based identity, automatic API discovery, dynamic payment recipients and CAIP multi-chain addressing; it is live on Base, Solana, Stellar, Arbitrum, Polygon and Ethereum, settling USDC/EURC via EIP-3009.
WICK community fit
YES — and WICK already uses it DIRECTLY. onchain.wick.pics runs an x402 rail in production: our token-safety, fresh-rug, exit-safety, safe-smart-money, red-team and dataset products are sold per-call in USDC over x402, and access can also be unlocked by holding $WICK. We run our OWN facilitator (no Coinbase dependency) and own our discovery. For the Pangle agentic network it is the planned Phase-2+ rail for opt-in agent-to-agent payments — ERC-8004 even references x402 proof-of-payment to enrich reputation. The single most directly-relevant agent standard to WICK — literally how autonomous agents pay us.
Pros
- ▪Machine-native: agents pay with no signup, keys, or human step
- ▪Stablecoin (USDC) settlement — clean margins, near-instant
- ▪Open standard, not locked to any provider; facilitator is self-hostable
- ▪Turns our on-chain intelligence into recurring, capital-unbound revenue
Cons
- ▪Agent-economy demand is still early in 2026 — volume is thin
- ▪Real-USDC mainnet revenue needs the flip live (settler funded; in progress)
- ▪Discovery / marketplace layer is nascent — we run our own
Risks
- ▪Hot settler key handling (kept to a gas-only balance)
- ▪Young standard — spec and facilitator APIs still evolving
- ▪Buyer-side x402 client adoption is the gating variable
PulseChain today?
Chain-agnostic: settlement is USDC on Base regardless of which chain the data describes, so it covers PulseChain / Monad / Base / BSC token intel alike. We run it self-sovereign — our own facilitator + our own /.well-known discovery — so there is no permissioned dependency.
Notes for $WICK
The spearhead of the agent-services arm: the only revenue path that scales with agent traffic instead of our capital. Live products + demo at onchain.wick.pics.
Intelligent NFTs (iNFTs)
How it works
Wraps an AI agent — model weights, memory, prompts — inside an NFT. Encrypted metadata stays off-chain; the token points to verifiable storage plus TEE/zk attestations that prove the weights were not tampered with. Transferring the NFT transfers the agent, including its learned state.
WICK community fit
YES — orthogonal. iNFTs are NFTs, not fungible tokens, so they would sit alongside $WICK rather than compete for liquidity. A WICK-branded agent collection (e.g. trading assistants, arb scouts, chat companions) could be minted as iNFTs and gated by $WICK holdings. No dilution of the core token.
Pros
- ▪Native monetisation for AI agents the community builds
- ▪Encrypted weights protect IP while staying transferable
- ▪Creates secondary demand sinks that can route fees to $WICK buybacks
Cons
- ▪Off-chain storage and TEE attestation infra is heavy to self-host
- ▪Standard is pre-final — breaking changes likely
- ▪UX is still rough; most wallets do not render iNFT metadata correctly
Risks
- ▪If the attestation provider goes offline, holders cannot verify the agent is genuine
- ▪Encrypted metadata leak = agent clone-able for free
- ▪Regulatory grey area if agents execute trades autonomously
PulseChain today?
Deployable today — it is a contract spec, nothing PulseChain-specific blocks it. What is missing is the verifiable-storage / TEE network (0G mainnet) and indexer support. A WICK iNFT collection could ship on PulseChain but attestation would need a bridge or a PulseChain-side coprocessor.
Notes for $WICK
Best fit for a "Wick Agents" NFT drop where each agent is a trading persona or chat guide. Revenue from mint + royalty routes cleanly to the $WICK treasury without touching supply.
Trustless Agents
How it works
Three lightweight on-chain registries that give AI agents portable identity and reputation. IDENTITY is an ERC-721 registry (register(), setAgentURI(), setAgentWallet() with EIP-712 / ERC-1271 proof-of-control, get/setMetadata) — each agent gets a CAIP-style id like eip155:1:0x…. REPUTATION is a feedback ledger (giveFeedback() with a signed off-chain file, revokeFeedback(), appendResponse(), getSummary()). VALIDATION lets independent validators verify an agent’s work via stake-secured re-execution, zk proofs or TEEs (validationRequest() / validationResponse() with a 0-100 score). It issues no token — it is the trust plumbing under agent-to-agent commerce, and the spec integrates with MCP, A2A, x402 and EAS.
WICK community fit
CORE — this is the standard the Pangle agentic network is built on. Pangle’s on-chain hub is an ERC-8004-style IdentityRegistry (operators self-register their agent NFT and bind a signing wallet via EIP-712 / ERC-1271) plus a minimal coordinator-written Reputation Anchor that migrates toward the ERC-8004 Reputation Registry (giveFeedback) when peer review arrives; the Validation Registry is the roadmap path for verifying self-reported evidence. Agents now authenticate to the coordinator purely with their ERC-8004 identity signature — no shared secret. Pure utility layer; $WICK is the preferred payment rail for jobs those agents accept.
Pros
- ▪Now real — canonical contracts live on Ethereum mainnet with 45k+ agents
- ▪Zero token issuance — pure identity / reputation utility
- ▪Portable reputation: an agent’s history travels across tools and marketplaces
- ▪Integrates natively with MCP, A2A, x402 and EAS
Cons
- ▪Still a Draft ERC — v2 may change interfaces (tighter MCP + x402)
- ▪Reputation / validation are gameable until sybil-resistance matures
- ▪Network-effect dependent — a registry with no other agents is just an address book
Risks
- ▪Malicious attestations could poison a legitimate agent’s reputation
- ▪The identity registry captures the operator wallet — a privacy tradeoff
- ▪Cross-chain reputation portability is still an open problem (EAS / attestations help)
PulseChain today?
EVM-generic, so PulseChain deployment is trivial — Pangle runs its own ERC-8004-compatible registry on PulseChain as the single identity / reputation hub, with analysis spanning all chains (hub-and-spoke, no token bridge). Mirroring WICK-operated agents on the canonical Ethereum registry keeps them discoverable cross-chain.
Notes for $WICK
The anchor standard for everything agentic at Green Wick. Pangle implements the Identity + Reputation pieces today and tracks ERC-8004 v2 (which tightens MCP + x402 integration) for the validation / peer-review phase.
Model Context Protocol
How it works
A standard client/server protocol for giving AI models safe, typed access to tools and data. A server exposes a fixed set of tools over a transport (stdio / SSE / streamable HTTP); the client (the model runtime) discovers them and calls them under explicit permission. The "USB-C for AI tools" — no arbitrary code execution, just declared, scoped capabilities.
WICK community fit
CORE — it is how agents talk to Pangle today. The coordinator IS an MCP server exposing exactly four scoped tools (discover, knowledge_read, contribute, coordinator_talk); agents connect their MCP client (e.g. Claude Code) at swarm.wick.pics/mcp. No spend / tx / exec tool exists, which is what makes the no-custody guarantee structural. ERC-8004 v2 is tightening MCP integration, so the two standards converge.
Pros
- ▪Locked-down tool surface — scoped capabilities, no arbitrary execution
- ▪Native to the agent runtimes our cohort already uses (Claude Code etc.)
- ▪Transport-flexible (SSE / streamable HTTP) and easy to self-host
Cons
- ▪Not a blockchain standard — no on-chain enforcement by itself
- ▪Auth is left to the implementer (Pangle uses ERC-8004 signatures)
- ▪SSE long-connections need careful session / transport handling
Risks
- ▪A permissive tool surface is the main risk — scope creep must be policed
- ▪Token / credential handling on the transport is implementer-defined
- ▪Prompt-injection via tool inputs if schemas are not strict
PulseChain today?
Off-chain by nature — runs anywhere; Pangle’s MCP server is live at swarm.wick.pics/mcp (behind the Cloudflare tunnel). On-chain identity / reputation is handled by ERC-8004 alongside it.
Notes for $WICK
The tool layer of the whole agentic stack. Pangle’s entire agent surface is four MCP tools — deliberately tiny so the safety claims hold.
Agent2Agent Protocol
How it works
An open protocol for agents built by different vendors to discover and delegate work to each other. Each agent publishes a signed "Agent Card" (capabilities + endpoint, cryptographically signed for domain verification); others negotiate and exchange tasks/messages over a common bus. Donated by Google to the Linux Foundation; the AP2 (Agent Payments) extension layers payments on top.
WICK community fit
ROADMAP — the P2P future of Pangle. Pangle is coordinator-first for Phase 0-1 (one secured hub), but the message schemas are kept portable so the network can decentralize onto an A2A-style agent-to-agent bus later, with ERC-8004 providing the on-chain identity behind each Signed Agent Card. Not built yet; earmarked for the P2P phase on the design register.
Pros
- ▪Vendor-neutral — our agents could interoperate with Google / MS / AWS agents
- ▪Signed Agent Cards give cryptographic, ERC-8004-friendly identity
- ▪Now Linux-Foundation governed with broad enterprise production use
Cons
- ▪Heavier than a single coordinator — only worth it at the P2P phase
- ▪Enterprise-shaped; crypto-native identity wiring is still maturing
- ▪Adds a discovery / trust surface Pangle intentionally defers
Risks
- ▪Decentralizing too early trades a known SPOF for an unproven mesh
- ▪Agent-card spoofing if signature verification is sloppy
- ▪The A2A x ERC-8004 crypto-identity seam is young
PulseChain today?
Off-chain transport standard — chain-agnostic. Pangle would pair A2A messaging with ERC-8004 identity on PulseChain when it moves past the coordinator phase.
Notes for $WICK
The intended decentralization target: today’s coordinator is the reference implementation; tomorrow the same schemas ride an A2A bus with ERC-8004 identities underneath.
Ethereum Attestation Service
How it works
A general primitive for on-chain / off-chain attestations: any party signs a structured claim ("X did Y", "this agent completed this job") against a registered schema, anchored on-chain. Revocable, composable and queryable — the generic trust-statement layer many reputation systems build on.
WICK community fit
ROADMAP — the portable-reputation option for Pangle. The MVP uses a minimal coordinator-written Reputation Anchor; for cross-tool / cross-chain reputation the two candidate routes are the ERC-8004 Reputation Registry (giveFeedback) and EAS attestations. ERC-8004 itself can use EAS to immutably link client, agent, job and the off-chain feedback file. The choice is deferred to a later phase.
Pros
- ▪Battle-tested, widely deployed attestation primitive
- ▪Schema-based and composable — reputation becomes portable data
- ▪Pairs cleanly with ERC-8004 (which references EAS for feedback anchoring)
Cons
- ▪Just a primitive — the reputation *logic* still has to be designed
- ▪Attestation spam / sybil resistance is on the consumer to solve
- ▪One more dependency vs. keeping reputation in the ERC-8004 registry
Risks
- ▪Garbage-in attestations if issuers are not vetted
- ▪Cross-chain attestation aggregation is non-trivial
- ▪EAS vs the ERC-8004 Reputation Registry is a near one-way design lock-in
PulseChain today?
EVM-generic; needs the EAS contracts on PulseChain (or attestations anchored on Ethereum / an L2 and referenced). Pangle keeps reputation single-sourced on the PulseChain hub for now.
Notes for $WICK
Held as the reputation-portability route to weigh against the ERC-8004 Reputation Registry when Pangle moves beyond a single coordinator-written score.
Verifiable AI-Generated NFTs
How it works
Extends ERC-721 with a zkML or opML proof that the NFT’s content was produced by a specific model on a specific prompt. The verify() function on the contract checks the proof before the mint is considered valid. Solves the "was this really made by model X?" problem without trusting the minter.
WICK community fit
YES — additive. A "Verified WICK AI Art" collection could use ERC-7007 so buyers know the image/text actually came from the advertised model. Purely an NFT play — does not touch $WICK supply or liquidity.
Pros
- ▪Solves genuine provenance problem for AI content
- ▪Zero supply impact on $WICK
- ▪Marketing angle: "provably AI-generated" is a differentiator most collections cannot claim
Cons
- ▪zkML proofs are expensive to generate (seconds to minutes per image)
- ▪opML is cheaper but requires an optimistic challenge window, delaying mint finality
- ▪Wallets do not yet surface the verification status to buyers
Risks
- ▪If the model is updated, old proofs may not reverify under the new model hash
- ▪Prover centralisation — early deployments lean on one or two zkML services
- ▪Gas cost on verify() can exceed the mint price for complex models
PulseChain today?
The ERC-721 layer deploys anywhere. The *proof verification* layer (zkML verifier or opML challenge game) is the hard part — those live on Ethereum mainnet today because that is where the provers are. On PulseChain, mints could reference a proof submitted to Ethereum, or wait for a PulseChain-native prover.
Notes for $WICK
Only worth pursuing if the community actually wants a verified-AI-art drop. Otherwise the engineering cost dwarfs the benefit. Not a priority, but a clean option if demand shows up.
Intrinsic RevShare Token
How it works
An ERC-20 extension where the token contract itself holds a treasury and any holder can burn their share to claim a pro-rata slice of it. Treasury typically fills from fees paid to the associated AI model or agent. "Tokenise the model, holders earn from its usage."
WICK community fit
CAUTION — potential competition. This IS a fungible token standard, and its whole premise is redirecting revenue to *its own* holders, not to $WICK. If a WICK-branded AI service launched as an ERC-7641, fees would route to that token’s treasury, not to $WICK. Would need a careful structure — e.g. revenue flows to $WICK buybacks *before* the ERC-7641 mechanic, or $WICK is required to mint the ERC-7641 — to avoid cannibalising.
Pros
- ▪Clean monetisation model for a specific AI product
- ▪Built-in burn mechanic creates natural supply pressure
- ▪Investors like revenue-share tokens more than pure governance
Cons
- ▪Another token competing for community mindshare and liquidity
- ▪Burn-to-claim mechanic can be abused by whales timing treasury peaks
- ▪Regulatory risk: looks more like a security than most ERC-20s
Risks
- ▪Fragments the WICK ecosystem if not carefully coupled
- ▪Splits attention from $WICK during bull runs
- ▪SEC-style risk in US jurisdictions — revenue-share tokens are on regulators’ radar
PulseChain today?
Deployable on PulseChain today — it is pure Solidity with no external dependencies. The revenue source (the AI model/agent getting paid) needs to exist independently, which is the real lift.
Notes for $WICK
Only use if a WICK sub-product has a clear standalone revenue stream AND the structure routes value back to $WICK first. Default answer should be "no, use buybacks instead" unless the product genuinely needs its own revshare token.
Token Bound Accounts (NFT Wallets)
How it works
Gives every ERC-721 NFT its own smart-contract wallet deterministically derived from its token ID. The NFT’s owner controls the wallet. Not AI-specific, but it is the de-facto wallet layer underneath almost every AI-agent NFT project — the agent *is* an NFT, and its inventory / memory / funds live in its TBA.
WICK community fit
YES — foundational. Any WICK agent-NFT project (iNFT, AI-art, game characters) will almost certainly sit on top of ERC-6551. No token issuance, no competition with $WICK — it is pure infrastructure.
Pros
- ▪Final standard, stable, wide wallet support
- ▪Lets agents hold $WICK directly in their own wallet
- ▪Composable with every other NFT standard
Cons
- ▪Extra contract calls mean higher gas than plain NFTs
- ▪Some indexers still do not handle TBA ownership correctly
- ▪Recursion / ownership loops are possible and need guard rails
Risks
- ▪If the registry contract address differs between chains, TBAs do not port over
- ▪Permissions model is complex — easy to misconfigure and expose NFT assets
- ▪Account implementation contracts are upgradeable in some impls — supply-chain risk
PulseChain today?
The canonical registry (0x000000006551c19487814612e58FE06813775758) is deployed on many EVM chains; PulseChain deployment should be confirmed before relying on it. If missing, someone deploys it — it is a ~200-line contract with no chain-specific logic.
Notes for $WICK
The boring-but-important wallet layer. For Pangle specifically it is the rail behind the planned Phase-2+ opt-in agent payment wallet (token-bound account per agent identity) — kept out of Phase 0-1, where agents hold no keys. Worth confirming the canonical registry exists on PulseChain and deploying it if not.
Cross-Chain Intents
How it works
Standardised order format for cross-chain intents. A user signs an order describing the outcome they want (e.g. "I want X of token B on chain 2, I will give up Y of token A on chain 1"). Fillers/solvers compete to execute it atomically across chains. Not AI-native, but the default execution layer underneath most agentic "do X on whichever chain is cheapest" systems.
WICK community fit
STRONGEST fit on this page. Intent fillers earn spread by being fast and well-capitalised across chains — which is exactly what the WICK bot fleet already does. WICK can register as a filler/solver on the canonical 7683 network and route filler P&L directly to $WICK buybacks. Zero new token, zero dilution, uses infrastructure we already operate.
Pros
- ▪Directly mission-aligned — it is the same "be fast, capture spread" game we already play
- ▪Leverages existing multi-chain bot stack (Base, Monad, Polygon, Ethereum)
- ▪No new token required; revenue routes cleanly to $WICK treasury
- ▪Growing adoption — UniswapX + Across + multiple solver networks
Cons
- ▪Filler market is competitive — fat margins compress fast
- ▪Requires bonded capital across multiple chains
- ▪Destination-side MEV exposure if not carefully routed
- ▪Bridging / finality assumptions add systemic risk
Risks
- ▪Filler insolvency if an intent is filled but the origin-side refund fails
- ▪Settlement contract bugs are cross-chain, hard to unwind
- ▪Larger solvers with cheaper capital (Wintermute-tier) will eventually dominate top flow
- ▪Regulatory overhang: filler-as-a-service looks close to market-making in some jurisdictions
PulseChain today?
The ORDER format is chain-agnostic, but the SETTLEMENT contracts must be deployed on every chain a user wants to bridge from/to. UniswapX / Across currently cover Ethereum, Base, Optimism, Arbitrum, Polygon, Blast. PulseChain inclusion is not automatic — it needs either Across/UniswapX to deploy there, or WICK to run its own 7683-compliant settler that speaks the same order format.
Notes for $WICK
Most actionable item on this page. Day-one move: spin up a 7683 filler on the chains we already monitor (Base, Ethereum, Polygon) using the existing arb infrastructure. Day-two: advocate for Across/UniswapX PulseChain deployment, or fork their settler contract onto PulseChain so WICK becomes the native bridge filler for the chain.
EOA Delegation
How it works
A new transaction type that lets an EOA temporarily delegate its code to a smart-contract implementation for a bounded window. The user still holds the private key — they just grant a scoped, revocable "act as me" authority. Enables batching, session keys, gas sponsorship, and agent-style execution without migrating to a full smart wallet.
WICK community fit
STRONG — clean product angle. Users delegate their EOA to a WICK agent contract for a bounded window (e.g. "let the WICK engine trade for me for the next 4 hours"). Delegation tiers gated by $WICK holdings — hold more, unlock longer windows or larger size. Creates direct $WICK utility without issuing anything new. Users never hand over keys — just bounded authority they can revoke.
Pros
- ▪Creates concrete $WICK utility (hold to unlock delegation tiers)
- ▪Users keep their keys — only a bounded, revocable authority is granted
- ▪No new token; revenue flows from trading P&L as usual
- ▪Narrative is clean: "delegate to WICK, earn share, revoke anytime"
Cons
- ▪Contract bugs expose delegated EOAs fully while delegation is active
- ▪Scoped-authority UX is new; most users will not understand it without good tooling
- ▪Likely looks like managed-trading in some jurisdictions — legal review required before launch
- ▪Ethereum mainnet gas may make small delegators unprofitable
Risks
- ▪Gated on Pectra reaching PulseChain — not automatic, no public timeline
- ▪Upgradable delegate contract = supply-chain risk to every delegator at once
- ▪A single exploit in the delegate contract drains every active delegation
- ▪Cross-chain delegation replay if authorisation scope is not correctly chain-bound
PulseChain today?
NOT YET. ERC-7702 is a hard-fork transaction type introduced in Pectra on Ethereum mainnet. PulseChain would need to pick up the same fork before 7702 works natively. No announced timeline. Product could launch on Ethereum first, expand to PulseChain when the fork lands.
Notes for $WICK
Best framed as a product, not a standard: "Delegate your wallet to the WICK engine for a few hours — we trade, you earn share, your keys never leave your device." Gate delegation tiers by $WICK held = direct token utility. Gated on Pectra availability on PulseChain — until then, Ethereum-only.
Summary — the agentic stack & what it means for $WICK
What the Green Wick agentic network (Pangle) actually uses: ERC-8004 for on-chain agent identity & reputation, MCP as the locked-down tool layer (the coordinator is an MCP server exposing four scoped tools), and ERC-8004 signature auth (no shared secret) for every agent. On the roadmap: x402 + ERC-6551 for opt-in Phase-2 agent payments, EAS or the ERC-8004 Reputation Registry for portable reputation, and A2A for the eventual P2P / agent-to-agent phase. Those are the “ones we need”; the items below are the broader AI-native ERC survey for $WICK ecosystem fit.
ERC-7683 (cross-chain intents) is the strongest fit on this page. It is the same "be fast, capture spread, settle atomically" game the WICK bot fleet already plays — just packaged as a standard so user intents flow to WICK automatically. Zero new token, direct mission alignment, revenue routes to $WICK buybacks. This is the one to actually ship.
Six of the seven standards can live alongside $WICK with zero dilution: ERC-7857 (iNFTs), ERC-8004 (agent registries), ERC-7007 (verified AI art), ERC-6551 (NFT wallets), ERC-7683 (cross-chain intents), and ERC-7702 (EOA delegation) are all non-fungible, pure infrastructure, or bounded-authority layers. They add surface area for the WICK ecosystem without competing for liquidity.
The exception is ERC-7641 (Intrinsic RevShare) — it is a fungible token standard, and its whole point is routing revenue to its own holders. Using it without a careful "WICK buybacks first" wrapper would fragment the ecosystem. Default answer: use $WICK buybacks instead.
PulseChain deployment varies by standard. Most are EVM-generic contracts (7857/8004/7007/6551/7641) and ship anywhere, though their supporting infra — zkML provers, TEE attestation, ORA oracle — lives on Ethereum/L2s today. 7683 settlers need either a native deployment or a WICK-run fork. 7702 is a hard-fork feature — it only works once PulseChain adopts Pectra; until then, any 7702-based product is Ethereum-only.
Priority order for the WICK mission: (1) stand up a 7683 filler on chains we already monitor, (2) scope a 7702 "delegate to WICK" product on Ethereum (gate by $WICK held), (3) confirm the ERC-6551 registry exists on PulseChain for any future agent-NFT work, (4) treat 7857/8004/7007 as optional collection drops when community demand shows up, (5) avoid 7641 unless wrapped around a WICK-buyback-first structure.