ਸਿਰਲੇਖ: X402 ਦੀ ਵਿਆਖਿਆ: AI Agents ਲਈ HTTP Native Micropayments

X402 spec ਸਟੈਂਡਰਡ HTTP 402 Payment Required ਸਟੇਟਸ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਆਮ API ਕਾਲ ਨੂੰ on-chain micropayment ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। AI agents ਹੁਣ ਬਿਨਾਂ ਕਿਸੇ ਇਨਸਾਨ ਦੇ LLM queries ਜਾਂ data feeds ਲਈ ਫੀਸਾਂ ਦਾ ਨਿਪਟਾਰਾ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ providers ਇੱਕ ਕਸਟਮ ਇਨਵੌਇਸਿੰਗ ਸਿਸਟਮ ਬਣਾਏ ਬਿਨਾਂ ਪ੍ਰਤੀ ਰਿਕੁਐਸਟ ਚਾਰਜ ਕਰ ਸਕਦੇ ਹਨ।

AI agents ਨੂੰ ਪੇਮੈਂਟ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ

Autonomous agents language models, web-search tools, ਅਤੇ proprietary data sources ਨੂੰ ਆਪਸ ਵਿੱਚ ਜੋੜਦੇ ਹਨ। ਹਰ ਜੋੜ ਦੀ ਇੱਕ ਕੀਮਤ ਹੁੰਦੀ ਹੈ—ਜਿਵੇਂ ਕਿ ਮਾਡਲ ਲਈ per-token ਫੀਸ ਜਾਂ market-data API ਲਈ per-call ਚਾਰਜ। ਅੱਜ ਦੇ ਬਿਜ਼ਨਸ ਮਾਡਲ subscription accounts ਨਾਲ ਜੁੜੀਆਂ API keys, ਮੈਨੂਅਲ credit top-ups, ਜਾਂ post-hoc billing 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਇਹ ਤਰੀਕੇ autonomous agents ਦੇ "no-human" ਵਾਅਦੇ ਨੂੰ ਤੋੜਦੇ ਹਨ ਅਤੇ providers ਲਈ operational overhead ਵਧਾਉਂਦੇ ਹਨ।

X402 ਇੱਕ ਵਿਚਕਾਰਲਾ ਰਸਤਾ ਪੇਸ਼ ਕਰਦਾ ਹੈ: ਇੱਕ request-response flow ਜੋ ਕਿਸੇ ਵੀ ਹੋਰ HTTP ਕਾਲ ਵਾਂਗ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਪਰ ਇਸ ਵਿੱਚ ਇੱਕ built-in ਪੇਮੈਂਟ ਸਟੈਪ ਹੁੰਦਾ ਹੈ ਜੋ public blockchain 'ਤੇ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਕਲੌਤੀ ਸ਼ਰਤ ਇਹ ਹੈ ਕਿ client ਉਸ chain 'ਤੇ transaction ਨੂੰ sign ਅਤੇ broadcast ਕਰ ਸਕੇ ਜੋ server ਦੱਸਦਾ ਹੈ।

X402 handshake ਦੀ ਵਿਸਤ੍ਰਿਤ ਜਾਣਕਾਰੀ

  1. Initial request – Agent ਇੱਕ paid endpoint 'ਤੇ ਆਮ GET ਜਾਂ POST ਭੇਜਦਾ ਹੈ। ਕਿਸੇ ਖਾਸ headers ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।
  2. Server replies with 402 – Response ਵਿੱਚ status 402 ਅਤੇ ਇੱਕ JSON body ਹੁੰਦੀ ਹੈ ਜੋ ਇਹ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ:
    • amount – ਉਹ ਫੀਸ ਜੋ server ਉਮੀਦ ਕਰਦਾ ਹੈ, ਸਭ ਤੋਂ ਛੋਟੀ token unit ਵਿੱਚ;
    • token – ERC-20 (ਜਾਂ equivalent) contract address;
    • chain – blockchain identifier ਜਿੱਥੇ ਪੇਮੈਂਟ ਰਿਕਾਰਡ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ;
    • optional nonce – ਇੱਕ ਵਿਲੱਖਣ (unique) ਮੁੱਲ ਜੋ replay attacks ਨੂੰ ਰੋਕਦਾ ਹੈ।
  3. Client prepares payment – Agent ਆਪਣੀ policy (ਜਿਵੇਂ ਕਿ ਸਿਰਫ trusted chains) ਦੇ ਅਨੁਸਾਰ token address ਅਤੇ chain ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਫਿਰ ਇਹ ਇੱਕ transaction ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਲੋੜੀਂਦੀ ਰਕਮ server ਦੁਆਰਾ ਦਿੱਤੇ ਗਏ address 'ਤੇ ਟ੍ਰਾਂਸਫਰ ਕਰਦਾ ਹੈ, ਇਸਨੂੰ ਆਪਣੀ private key ਨਾਲ sign ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ broadcast ਕਰਦਾ ਹੈ।
  4. Payment hash submission – ਜਦੋਂ transaction hash ਉਪਲਬਧ ਹੁੰਦਾ ਹੈ, client ਅਸਲ ਰਿਕੁਐਸ ਨੂੰ ਦੁਬਾਰਾ ਭੇਜਦਾ ਹੈ, ਇਸ ਵਾਰ ਇੱਕ X-Payment header ਜੋੜ ਕੇ ਜਿਸ ਵਿੱਚ hash ਹੁੰਦਾ ਹੈ। Payload ਬਿਨਾਂ ਕਿਸੇ ਬਦਲਾਅ ਦੇ ਰਹਿੰਦਾ ਹੈ।
  5. Server verifies on-chain – Server blockchain 'ਤੇ ਇੱਕ ਅਜਿਹੇ confirmed transfer ਦੀ ਭਾਲ ਕਰਦਾ ਹੈ ਜੋ amount, token, chain, ਅਤੇ nonce ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ। ਜੇਕਰ ਇਸਨੂੰ ਮੇਲ ਮਿਲ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ 200 OK status ਦੇ ਨਾਲ ਮੰਗੀ ਗਈ data ਵਾਪਸ ਕਰ ਦਿੰਦਾ ਹੈ।

ਕੋਈ ਵੀ HTTP client library ਜੋ custom headers ਨੂੰ support ਕਰਦੀ ਹੈ ਅਤੇ blockchain SDK ਨੂੰ call ਕਰ ਸਕਦੀ ਹੈ, ਇਹ ਕਦਮ ਚੁੱਕ ਸਕਦੀ ਹੈ। ਕਿਸੇ ਨਵੇਂ transport protocol ਜਾਂ custom socket layer ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਯੋਗ Trade-offs

  • Latency – Public-chain confirmation ਦੇ ਕਾਰਨ ਦੇਰੀ ਹੁੰਦੀ ਹੈ।
  • Gas costs – ਸਸਤੀ chains ਵੀ gas ਲੈਂਦੀਆਂ ਹਨ; $0.001 ਤੋਂ ਘੱਟ ਪੇਮੈਂਟ ਆਰਥਿਕ ਨਹੀਂ ਹੋ ਸਕਦੀ।
  • Complexity – Agents ਨੂੰ ਫੇਲ ਹੋਏ transactions ਅਤੇ chain reorganizations ਨੂੰ ਸੰਭਾਲਣਾ ਪਵੇਗਾ; ਇੱਕ ਮਜ਼ਬੂਤ (robust) retry logic ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੈ।
  • Security – Nonce replay attacks ਨੂੰ ਰੋਕਦਾ ਹੈ, ਪਰ agents ਨੂੰ ਫਿਰ ਵੀ private keys ਦੀ ਸੁਰੱਖਿਆ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਅਸੰਬੰਧਿਤ services ਵਿੱਚ ਦੁਬਾਰਾ ਵਰਤਣ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ।