AI ایجنٹس اب x402 اور HTTP 402 کے ساتھ خود کار طریقے سے ادائیگی کرسکتے ہیں

یہ جنوری 1997 ہے. کے (Internet Engineering Task Force) نے ابھی جاری کیا ہے سرکاری طور پر بیان اس کی تفصیل ویب پائنرز کی طرف سے لکھا گیا تھا ، ، ، اور ان آرٹیکلز جو انٹرنیٹ کی بات چیت کا طریقہ بنایا. IETF RFC 2068 کے بارے میں HTTP/1.1 ریو فیلڈنگ جیم گٹیز جیفری Mogul ہنگری ٹھنڈا Tim Berners-Lee IETF کے RFC 2068 کے بارے میں ریو فیلڈنگ جیم گٹیز جیفری Mogul ہنگری ٹھنڈا Tim Berners-Lee کے بارے میں خصوصیات میں داخلہ : سابقہ طور پر، ہر ایک HTTP درخواست کو ایک نیا TCP کنکشن کی ضرورت تھی. پائیدار کنکشنز اس کو حل کرتے ہیں، ایک ہی، طویل عمر TCP کنکشن کے ذریعے کئی HTTP درخواستوں کو جاری کرنے کی اجازت دیتا ہے. persistent connections وہاں بھی ہے ، ویب سرورز کے لئے مکمل سائز کو پہلے سے ہی جاننے کے بغیر مواد سٹریمنگ کرنے کا ایک نیا طریقہ. ایک سرور کو پہلے سے طے شدہ طور پر پیدا کردہ مواد کی مجموعی سائز کا حساب کرنے کی ضرورت نہیں ہے، یہ اب ڈیٹا فراہم کرنے کے لئے آزاد ہے، جیسا کہ یہ پیدا کیا جاتا ہے. chunked transfer encoding لیکن ایک نیا نظام کوڈ: RFC 2068 quietly introduces something intriguing HTTP 402 Payment Required This code is reserved for future use. یہ دکھاتا ہے کہ کس طرح عالمی ویب کے بنیادی باپ نے پیش کیا کہ پیسہ آخر میں انٹرنیٹ کا ایک بڑا حصہ بن جائے گا. . even if they had no clear path on how it would actually play out 22 اور تمہارا رفیق کوئی دیوانہ نہیں ہے 2015 میں، 2022 میں، فینٹیک انقلاب، آن لائن ادائیگیوں کی بڑھتی ہوئی ترقی، اور انٹرنیٹ ٹرانسمیشن پر مبنی ایک پوری معیشت کے باوجود، کوئی بھی اس کے ساتھ کیا کرنا تھا. HTTP/2 HTTP/3 Status Code 402 still sits there with the exact same note: 'reserved for future use.' Until now. گزشتہ ماہ (مئی 2025)، آزاد ایک کھلے ذریعہ پروٹوکول ہے جو اس کا پہلا حقیقی کام: نائجیریا کی صلاحیت HTTP درخواستوں کے اندر ادائیگی. Coinbase کے x402 HTTP 402 onchain آج کے کارکنوں کی ضرورت ہے (Machine-to-Machine) ادائیگی کم سے کم کے ساتھ انٹرنیٹ پر (انسان-in-the-loop) مداخلت، لیکن روایتی ادائیگی کے بہاؤ اس معاملے میں اچھی طرح سے کام نہیں کرتے. وہ کئی انسانی تبادلے، ریڈریڈز، اور دستی اقدامات کی ضرورت ہے جو صرف کام نہیں کرتے جب ایک AI ایجنٹ کو خود کار طریقے سے ایک ٹرانسمیشن کرنے کی ضرورت ہوتی ہے. M2M HITL یہ HTTP پروٹوکول کے اندر اندر متعارف کرایا جاتا ہے کہ ایک خود کار طریقے سے کیٹنگ پر ادائیگی کی فراہمی پیش کرتا ہے، . x402 making them as seamless as any other web request لیکن عملی طور پر یہ کیا لگتا ہے؟ آرکیٹیکل اور اجزاء x402 کے لئے x402 کے لئے یہ چار بنیادی اجزاء کے ارد گرد تعمیر کیا جاتا ہے: x402 کے A کے acts as the payment initiator, discovering what's required for access and constructing the appropriate payment payload. Put simply, this is whatever is making the HTTP request to a pay-walled resource. It could be a browser making a request for premium content, an AI agent purchasing API access, or a mobile app unlocking features. The client handles the cryptographic signing using the user's private key and automatically retries requests when payment is required. client کے اس کے اختیارات کے لئے ادائیگی کی پالیسیوں کو نافذ کرتا ہے جبکہ اس کی بنیادی کاروباری منطق پر توجہ مرکوز کرتا ہے. یہ ویب سرور یا API ہے جو خریدنے والے مواد یا خدمات کو میزبان کرتا ہے. یہ سادہ قیمت کی میزیں برقرار رکھتا ہے جو اختیارات کو اختیارات پر نقشہ کرتا ہے، لیکن ادائیگی کی تصدیق کے منطق کو فائلٹر پر قبضہ کرتا ہے. resource server Blockchain منطق میں استعمال کیا جاتا ہے اجزاء: خفیہ دستاویزات کی تصدیق، nonce ٹریکنگ کے ذریعے دوبارہ کھیلنے کے حملوں کو روکنے، اور حقیقی on-chain ادائیگی کا انتظام. یہ دونوں کلائنٹ اور سرورز کو blockchain اپلی کیشن کے تفصیلات کو سمجھنے کے بغیر on-chain ادائیگی کے ساتھ کام کرنے کی اجازت دیتا ہے. facilitator ہے آخری ادائیگی کی سطح میں رہتا ہے، ادائیگیوں کو غیر متغير اور شفاف بناتا ہے. یہ سمارٹ معاہدوں اور مستحکم کرنسیوں کے ذریعہ پروگرامن پیسے کی اجازت دیتا ہے، . blockchain but its complexity is completely hidden from the application layer by the facilitator : Client اولیاتی ذمہ داری: ادائیگی کا آغاز اہم خصوصیات:EIP-712 دستخط، خودکار retries، ادائیگی کی تلاش یہ کیا کرتا ہے: درخواستیں کرتا ہے، کیفے کا انتظام کرتا ہے، ادائیگی کے ساتھ retries : Resource Server بنیادی ذمہ داری: ادائیگی کی اطمینان اہم خصوصیات: قیمت کی میزیں، HTTP 402 جوابات، Middleware انضمام یہ کیا کرتا ہے: قیمتیں مقرر کرتا ہے، ادائیگیوں کو چیک کرتا ہے، مواد فراہم کرتا ہے : Facilitator بنیادی ذمہ داری: ادائیگی کی تصدیق اہم خصوصیات: دستاویزات کی جانچ پڑتال، nonce tracking، gas abstraction یہ کیا کرتا ہے: دستاویزات کی جانچ پڑتال کرتا ہے، blockchain کے ساتھ بات چیت کرتا ہے : Blockchain بنیادی ذمہ داری: ادائیگی کے معاہدے اہم خصوصیات:USDC ٹرانسفر، سمارٹ معاہدے، ناممکن ریکارڈز یہ کیا کرتا ہے: زنجیر پر ادائیگی کا تعین کرتا ہے اصولوں اس آرکیٹیکل میں کئی بنیادی سافٹ ویئر انجینئرنگ اصولوں کو ظاہر کرتا ہے. ہر اجزاء کو ایک منفرد، اچھی طرح سے بیان شدہ ذمہ داری ہے. . separation of concerns Resource servers focus purely on business logic, facilitators handle payment complexity, and clients manage user interaction نظام حاصل کرتا ہے اجزاء صرف معیاری HTTP اور REST انٹرفیسز کے ذریعے بات چیت کرتے ہیں. اس انفرادیشن کا مطلب یہ ہے کہ آپ اجزاء (مثال کے طور پر، مختلف blockchain کا استعمال کرتے ہوئے، فائلٹر سپلائرز کو تبدیل کرتے ہوئے، یا سرور منطق کو تبدیل کرتے ہوئے) کو تبدیل کرسکتے ہیں، نظام کے باقی حصوں کو متاثر نہیں کرتے ہوئے. loose coupling A resource server doesn't need to understand how blockchain transactions work, and a client doesn't need to know the server's internal implementation The facilitator embodies the بلاکچین کی تمام پیچیدگی کو ایک خاص سروس میں منفرد کرکے یہ ادائیگی کے منطق کو کاروباری ایپلی کیشنز میں پھنسنے سے روکتا ہے اور نگرانیوں کو مناسب طریقے سے الگ رکھتا ہے. single responsibility principle Last but not least اس آرٹیکل کے بعد اعلی درجے کے اجزاء کو کنکشنوں کے مقابلے میں اختلاط پر منحصر ہے سرورز اور کلائنٹ HTTP انٹرفیس پر منحصر ہیں، خاص blockchain API نہیں. dependency inversion ادائیگی کے flow جب ایک ای ای ایجنٹ یا صارف ایک -enabled API، یہاں چار مرحلے کے بہاؤ ہے جو ہوتا ہے: x402 ابتدائی درخواست: کلائنٹ کچھ وسائل تک رسائی کے لئے ایک معیاری HTTP درخواست کرتا ہے ادائیگی کی ضرورت کا جواب : اگر کوئی ادائیگی شامل نہیں ہے تو سرور HTTP 402 کے ساتھ جواب دیتا ہے اور ادائیگی کی تفصیلات شامل کرتا ہے ادائیگی کی توثیق: کلائنٹ کو ایک خفیہ طور پر دستخط شدہ ادائیگی پیدا کرتا ہے اور درخواست کو دوبارہ جاری کرتا ہے تصدیق اور رسائی : سرور ادائیگی کی تصدیق کرتا ہے، اسے بلاکچین پر ٹرانسمیشن کرتا ہے، اور رسائی فراہم کرتا ہے یہ طاقتور بناتا ہے کہ یہ سب HTTP پروٹوکول کی سطح پر ہوتا ہے. چلو، کوئی اکاؤنٹ تخلیق. OAuth Just standard HTTP with extra headers: X-PAYMENT کلائنٹ سے سرور تک چلا جاتا ہے اور دستخط شدہ ادائیگی پائیدار شامل ہے. اس میں ادائیگی کی تفصیلات (قدرت، وصولی، ٹوکن) اور ایک خفیہ دستخط شامل ہیں جو کلائنٹ نے ادائیگی کی تصدیق کی ہے. X-PAYMENT-RESPONSE کامیابی سے ادائیگی کے بعد سرور سے کلائنٹ تک چلتا ہے اور ٹرانسمیشن کی وصولی کی معلومات شامل ہے، جو چیک پر کیا ہوا ہے کے بارے میں شفافیت فراہم کرتا ہے. کے سرور کی جانب سے استعمال ادائیگی Middleware آرکیٹیکل مرکزی سرور کی جانب سے ایپلی کیشن ایک ادائیگی فلٹر (AKA Middleware) کے ارد گرد چلا جاتا ہے جو HTTP درخواستوں کو پکڑتا ہے اور ادائیگی کی ضروریات کو نافذ کرتا ہے. The middle-ware follows a simple decision tree: if a request hits a protected endpoint without payment, it responds with اور تفصیلات کے ادائیگی کے ہدایات. اگر ادائیگی میں شامل ہے تو ہیڈر، یہ درخواست کو آگے بڑھنے کی اجازت دینے سے پہلے ایک فلیکسٹر سروس کے ساتھ ادائیگی کی تصدیق کرتا ہے. HTTP 402 X-PAYMENT یہاں جاوا انضمام سے ضروری ساخت ہے: public class PaymentFilter implements Filter { private final String payTo; private final Map priceTable; // path → amount private final FacilitatorClient facilitator; public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { String path = req.getRequestURI(); String paymentHeader = req.getHeader("X-PAYMENT"); if (!priceTable.containsKey(path)) { chain.doFilter(request, response); // Free endpoint return; } if (paymentHeader == null) { send402Response(resp, path); // Request payment return; } // Verify payment, process request, then settle VerificationResponse verification = facilitator.verify(paymentHeader, requirements); if (verification.valid) { chain.doFilter(request, response); facilitator.settle(paymentHeader, requirements); } } } آپ صرف ادائیگی فلٹر کو اپنے ماڈل سٹاک میں شامل کرتے ہیں اور اس بات کا تعین کرتے ہیں کہ کس نقطہ نظر میں ادائیگی کی ضرورت ہوتی ہے. The beauty of this approach is that it requires minimal changes to existing applications. جوابات PaymentRequirements جب ایک کلائنٹ کوئی ادائیگی کے بغیر محفوظ نقطہ پر پہنچتا ہے تو، سرور ایک تفصیلی ادائیگی کی ضروریات کے اشیاء کو تعمیر کرتا ہے. )، وصول کرنے والے پولیٹ ایڈریس، blockchain نیٹ ورک، اور دوبارہ کھیلنے کے حملوں کو روکنے کے لئے ایک ختم ہونے کا وقت. USDC private void send402Response(HttpServletResponse response, String path) throws IOException { response.setStatus(HttpStatus.PAYMENT_REQUIRED); response.setContentType("application/json"); PaymentRequirements requirements = PaymentRequirements.builder() .paymentRequirement(List.of( PaymentRequirement.builder() .kind(new Kind("exact", "base-sepolia")) // Payment scheme + blockchain network .receiver(payTo) // Wallet address to receive payment .amount(priceTable.get(path)) // Cost for this specific endpoint .asset(" ") // USDC token contract .expiry(Instant.now().plus(Duration.ofMinutes(5))) // Payment window .nonce(UUID.randomUUID().toString()) // One-time use identifier .build() )) .build(); response.getWriter().write(Json.MAPPER.writeValueAsString(requirements)); } ہر میدان میں اس طرح بیان کیا گیا ہے: PaymentRequirements قسم: ادائیگی کے نظام کی وضاحت کرتا ہے (صحیح رقم کے لئے) اور ہدف blockchain نیٹ ورک (Base-sepolia کے لئے Base testnet). صارف: پیسہ کا ایڈریس جہاں ادائیگی بھیج دیا جانا چاہئے. یہ آپ کے کاروباری پیسہ ہے جو پیسہ وصول کرے گا. رقم: اس مخصوص نقطہ تک رسائی کی قیمت، آپ کی قیمت کی میز سے حاصل کی جاتی ہے. USDC کے لئے، یہ عام طور پر wei (سب سے چھوٹے یونٹ) میں بیان کیا جاتا ہے. اثاثہ: ادائیگی کے لئے استعمال ہونے والے ٹوکن کے سمارٹ معاہدے کا ایڈریس۔ مثال Base Sepolia testnet پر USDC دکھاتا ہے. اختتام: ایک ٹائم سٹیل جس کے بعد اس ادائیگی کی ضروریات کو مسترد کیا جاتا ہے.یہ پرانے ادائیگی کی درخواستوں کو دوبارہ استعمال کرنے سے روکتا ہے اور دوبارہ کھیلنے کے حملوں کے خلاف سیکورٹی شامل کرتا ہے. nonce: ایک منفرد شناختی (UUID) جو ہر ادائیگی کی ضروریات کو یقینی بناتا ہے، صرف ایک بار پورا کیا جا سکتا ہے، یہاں تک کہ اگر ایک ہی کلائنٹ ایک ہی آرڈر پر کئی درخواستیں کرتا ہے. کلائنٹ کی طرف سے ایپلی کیشن خود کار طریقے سے ادائیگی کلائنٹ لائبریریوں کو معیاری HTTP کلائنٹ کو خود کار طریقے سے 402 جوابات کا انتظام کرنے کے لئے پکڑتے ہیں. جب ایک کلائنٹ کی ادائیگی کی درخواست ملتی ہے، تو (1) یہ ادائیگی کی لاگت کی تعمیر کرتا ہے، (2) اسے صارف کے نجی کلید کے ساتھ دستخط کرتا ہے، اور (3) ادائیگی کے ساتھ اصل درخواست کو دوبارہ ترمیم کرتا ہے. public HttpResponse makeRequest(String url, String method) throws Exception { HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(url)) .method(method, HttpRequest.BodyPublishers.noBody()) .build(); HttpResponse response = httpClient.send(request, HttpResponse.BodyHandlers.ofString()); // Handle 402 Payment Required if (response.statusCode() == 402) { PaymentRequirements requirements = Json.MAPPER.readValue( response.body(), PaymentRequirements.class); // Create payment payload matching the requirements PaymentPayload payment = PaymentPayload.builder() .receiver(requirements.getPaymentRequirement().get(0).getReceiver()) .amount(requirements.getPaymentRequirement().get(0).getAmount()) .asset(requirements.getPaymentRequirement().get(0).getAsset()) .nonce(requirements.getPaymentRequirement().get(0).getNonce()) .expiry(requirements.getPaymentRequirement().get(0).getExpiry()) .build(); // Sign using EIP-712 structured data signing String signature = signer.sign(payment.toSigningMap()); // Retry with payment header String paymentHeader = encodePaymentHeader(payment, signature); HttpRequest paidRequest = HttpRequest.newBuilder() .uri(URI.create(url)) .method(method, HttpRequest.BodyPublishers.noBody()) .header("X-PAYMENT", paymentHeader) .build(); return httpClient.send(paidRequest, HttpResponse.BodyHandlers.ofString()); } return response; } دستخط کرنے کا طریقہ استعمال کرتا ہے معیاری، جس میں ادائیگی کے اعداد و شمار کو ہاچنگ اور دستخط کرنے سے پہلے ایک منظم، انسان کو پڑھنے کے قابل نمائندگی بناتا ہے. EIP-712 ادائیگی کی رفتار کی جانچ پڑتال انضمام کی سہولت فلیسٹر سروس یہ ہے جہاں blockchain پیچیدگی رہتا ہے، اسے کلائنٹ اور سرور دونوں سے الگ کر دیتا ہے.جب ایک سرور ایک ادائیگی حاصل کرتا ہے، تو یہ ادائیگی کی کارکردگی کو تصدیق کے لئے فلیسٹر کو پیش کرتا ہے. public class HttpFacilitatorClient implements FacilitatorClient { private final HttpClient http; private final String baseUrl; @Override public VerificationResponse verify(String paymentHeader, PaymentRequirements requirements) throws Exception { // Construct verification request with payment and requirements VerifyRequest body = VerifyRequest.builder() .paymentHeader(paymentHeader) // The X-PAYMENT header from client .requirements(requirements) // What the server expects .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(baseUrl + "/verify")) .POST(HttpRequest.BodyPublishers.ofString(Json.MAPPER.writeValueAsString(body))) .header("Content-Type", "application/json") .build(); String json = http.send(request, HttpResponse.BodyHandlers.ofString()).body(); return Json.MAPPER.readValue(json, VerificationResponse.class); } @Override public SettlementResponse settle(String paymentHeader, PaymentRequirements requirements) throws Exception { // Settlement happens after successful verification SettleRequest body = SettleRequest.builder() .paymentHeader(paymentHeader) .requirements(requirements) .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(baseUrl + "/settle")) .POST(HttpRequest.BodyPublishers.ofString(Json.MAPPER.writeValueAsString(body))) .header("Content-Type", "application/json") .build(); String json = http.send(request, HttpResponse.BodyHandlers.ofString()).body(); return Json.MAPPER.readValue(json, SettlementResponse.class); } } صارف کئی چیزوں کی جانچ پڑتال کرتا ہے: کیا دستخط درست ہے؟ کیا ادائیگی کی رقم ضروریات کو پورا کرتی ہے؟ کیا یہ ادائیگی پہلے استعمال کی گئی ہے؟ کیا ادائیگی اب بھی اس کے اختتام کے ونڈوز میں ہے؟ اگر تصدیق ختم ہو جاتی ہے تو، فائلٹر بھی انتخاب کے بلاکچین پر ٹرانسمیشن کی طرف سے تبادلہ خیال کرتے ہیں. انٹرفیس معاہدے کی وضاحت کرتا ہے کہ کسی بھی فلیشٹر کلائنٹ کو لاگو کیا جانا چاہئے: FacilitatorClient public interface FacilitatorClient { VerificationResponse verify(String paymentHeader, PaymentRequirements requirements); SettlementResponse settle(String paymentHeader, PaymentRequirements requirements); } آپ کے ایپلی کیشن کو اس انٹرفیس کو عملی طور پر لاگو کرنے کی ضرورت ہے. Integration مثال کے طور پر اب جب ہم نے انفرادی اجزاء (پلیٹنگ فلٹرز، فلیٹٹر انضمام، اور کلائنٹ ہینڈلنگ) کو دیکھا ہے تو ہم دیکھیں کہ یہ اجزاء ایک حقیقی ایپلی کیشن میں کیسے ملتے ہیں. مثال کے طور پر، یہ پورے نظام کو ظاہر کرتا ہے. Spring Boot سب سے پہلے، پیدا کرنے کے لئے a نوٹ کریں: @PaymentRequired @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface PaymentRequired { String price(); String currency() default "USDC"; String network() default "base-sepolia"; } اس کے بعد تبدیل کریں شروع میں ان نوٹس کے لئے اسکرین کرنے کے لئے: PaymentFilter @Component public class PaymentFilter implements Filter { private final Map priceTable; private final String payTo; private final FacilitatorClient facilitator; public PaymentFilter(ApplicationContext context, String payTo, FacilitatorClient facilitator) { this.payTo = payTo; this.facilitator = facilitator; this.priceTable = buildPriceTableFromAnnotations(context); } private Map buildPriceTableFromAnnotations(ApplicationContext context) { Map prices = new HashMap<>(); // Scan all @RestController beans for @PaymentRequired annotations Map controllers = context.getBeansWithAnnotation(RestController.class); for (Object controller : controllers.values()) { Method[] methods = controller.getClass().getMethods(); for (Method method : methods) { PaymentRequired payment = method.getAnnotation(PaymentRequired.class); if (payment != null) { String path = extractPathFromMapping(method); BigInteger amount = new BigInteger(payment.price().replace(".", "")); prices.put(path, amount); } } } return prices; } } اب آپ اپنے کنٹرولر کے طریقوں کو براہ راست نوٹ کرسکتے ہیں: @RestController public class WeatherController { @GetMapping("/weather") @PaymentRequired(price = "0.001", currency = "USDC", network = "base-sepolia") public WeatherData getWeather(@RequestParam String city) { // Your existing business logic return weatherService.getWeatherForCity(city); } @GetMapping("/premium-forecast") @PaymentRequired(price = "0.01", currency = "USDC", network = "base-sepolia") public ExtendedForecast getPremiumForecast(@RequestParam String city) { return weatherService.getExtendedForecast(city); } } @Configuration public class PaymentConfig { @Bean public PaymentFilter paymentFilter(ApplicationContext context) { return new PaymentFilter( context, " ", // Your wallet address new HttpFacilitatorClient(" ") ); } @Bean public FilterRegistrationBean paymentFilterRegistration(PaymentFilter filter) { FilterRegistrationBean registration = new FilterRegistrationBean<>(); registration.setFilter(filter); registration.addUrlPatterns("/*"); registration.setOrder(1); return registration; } } کے قیمتوں کی تصدیق کرنے کے لئے ڈیزائن کا استعمال کرتے ہوئے، جبکہ ان نوٹز کو خود کار طریقے سے شروع کرنے پر پتہ چلتا ہے اور قیمت کی میز بناتا ہے. کنٹرولر کے طریقوں میں آپ کی موجودہ کاروباری منطق مکمل طور پر تبدیل نہیں رہتی ہے. ترتیب ادائیگی فلٹر کو رجسٹر کرنے اور اس کو فلیٹٹر سروس سے منسلک کرنے سے سب کچھ ایک دوسرے کے ساتھ منسلک کرتا ہے. قیمت 0.001 USDC اور قیمت 0.01 USDC، تمام ادائیگی کے انتظام کو HTTP layer پر شفاف طور پر کیا جاتا ہے. @PaymentRequired PaymentFilter /weather /premium-forecast سیکورٹی اور پیداوار کے خیالات یہ سادہ اور خوبصورت ہے، یہ پیچیدگی کو چھپاتا ہے. یہ ایک پیشہ ورانہ اور ایک ناپسندیدہ ہے. یہ انضمام آسان بناتا ہے، لیکن یہ بھی ایک اہم پہلو چھپاتا ہے: . x402 putting AI agents in charge of money creates new attack vectors جب تک دستاویزات اور نانسی مینجمنٹ دوبارہ کھیلنے کے حملوں کا انتظام کرتے ہیں، جب ایک ایجنٹ کو نقصان پہنچا جاتا ہے تو کیا ہوتا ہے؟ روایتی دھوکہ دہی کی تشخیص انسانی رویے کی ماڈل پر منحصر ہے، لیکن ایک نقصان دہ ایجنٹ کسی بھی انسانی دھوکہ دہی سے زیادہ تیزی سے پیسہ نکال سکتا ہے. EIP-712 AI agents don't follow human spending habits فلیسٹر اجزاء ایک اور اعلی معیار کا مقصد بن جاتا ہے کیونکہ یہ دستخطوں کی تصدیق اور nonces کا انتظام کرتا ہے. . blockchain settlements are final سے کیٹنگ پر ٹرانسمیشن پر مبنی ہے، یہ بلاکچین ٹرانسمیشنز کے آپریٹنگ خطرے کا وارث بناتا ہے. گیس کی قیمتیں غلیظ طور پر بدلتی ہیں، کبھی کبھی مائکروپلی کیشنز کو اقتصادی طور پر غیر معمولی بناتا ہے. نیٹ ورک کی ٹرانسمیشن ٹرانسمیشنوں کو دیر کر سکتا ہے. ایک AI ایجنٹ کو کیا کرنا چاہئے جب اس کو حقیقی وقت کے اعداد و شمار کی ضرورت ہوتی ہے لیکن ادائیگی ایک میپپوول میں پکڑی جاتی ہے؟ x402 Another important aspect is regulation. Compliance varies across jurisdictions with different rules about automated payments, cryptocurrency usage, and data retention. An AI agent making a large volume of micro-transactions across borders might trigger AML alerts or violate local regulations without anyone realizing it. Next کیا ہے کیا دلچسپ ہے کے بارے میں AI ایجنسیوں کو خود کار ادائیگی کی صلاحیتوں کی ضرورت ہے، stablecoins ایک پروگرامن پیسہ کی سطح فراہم کرتے ہیں، اور blockchain انٹرفیس کو پیمانے پر ایپلی کیشنز کو سنبھالنے کے لئے کافی بالغ ہو گیا ہے. ان ٹکڑوں کو پہلے سے طے نہیں کیا گیا ہے. انٹرنیٹ کو اب ادائیگی کی ایک نئی شکل کی ضرورت ہے، اور روایتی فراہمیوں کو خود کار ایجنسیوں یا مائکروپلیکیشنز کے لئے نہیں بنایا گیا تھا. x402 اس کے عملی نقطہ نظر کی وجہ سے یہ حیرت انگیز ہے. صارفین کی ادائیگی کو نیچے سے دوبارہ تخلیق کرنے کے بجائے، یہ موجودہ HTTP انٹرفیس کو توسیع کرتا ہے. نئے انضمام کی ضرورت کے بجائے، یہ معیاری نمونوں کے ساتھ کام کرتا ہے جو ہم پہلے سے ہی سمجھتے ہیں. x402 سیکورٹی اور آپریٹنگ مسائل حقیقی ہیں، لیکن یہ ممکنہ حل کے ساتھ انجینئرنگ مسائل ہیں. تقریباً تین سال کے بعد، آخر میں وہی کر سکتے ہیں جو اس کے لئے ڈیزائن کیا گیا تھا: انٹرنیٹ پر چیزوں کے لئے ادائیگی کرنے کے لئے آسان بنائیں. HTTP 402 The foundation is set. Now it's time to build. شکریہ آرک ریپل رونی کیسپرز Kevin Leffew کے بارے میں دانا آرگن، اور پوری ٹیم میں Coinbase کے for open sourcing this protocol. آرک Reppel رونی کیسپرز کینیڈا Leffew ڈینیا Organ Coinbase کے . شکریہ آرک Reppel اور یوگا کویلر جائزہ لینے کے لئے میری معاونتیں دو x402 Erik Reppel یوگا کویلر میری معاونتیں وسائل اور مزید پڑھیں HTTP 402 ادائیگی کی ضرورت ہے - RFC 2068 - اصل 1997 HTTP خصوصیات x402 پروٹوکول کی تفصیلات - سرکاری پروٹوکول دستاویزات x402 GitHub Repository - Coinbase کے کھلے ذریعہ کی پیروی x402 جاوا انضمام - پروٹوکول کے جاوا انضمام کو پیش کرنے والے PR EIP-712: Ethereum typed structured data hashing and signing - x402 میں استعمال ہونے والے دستخط کے معیار Basis Network Documentation - Layer 2 blockchain پلیٹ فارم مثالوں میں استعمال کیا جاتا ہے USDC دستاویزات - USD Coin stablecoin معاہدے کی تفصیلات Spring Boot Filter کی دستاویزات - جاوا ماڈیولر کی پیشن گوئی جاوا HTTP کلائنٹ API - کلائنٹ کی طرف سے HTTP کا انتظام مشین سے مشین (M2M) مواصلات کے معیار - خود کار طریقے سے نظام مواصلات Autonomous AI Agent Architectures - AI ایجنٹ ڈیزائن کے نمونے پر تحقیق AI ایجنٹوں کو محفوظ کرنے کے لئے گوگل کا نقطہ نظر - Google کی ایک محفوظ، انسان کی طرف سے ہدایت شدہ AI ایجنٹ فریم ورک کی پیشکش