कई एजेंटों को चलाने वाली टीमों के लिए वॉलेट अवसंरचना।
आप 15 ग्राहकों के लिए 20 बॉट चलाते हैं। प्रत्येक को अपना वॉलेट, अपनी सीमाएँ, अपनी ऑडिट ट्रेल, और ग्राहक के लिए प्रति-ग्राहक दृश्यता की आवश्यकता होती है।
बॉटलनेक एजेंट नहीं हैं। यह वॉलेट प्रबंधन है।
यदि आप एक Web3 ऑटोमेशन एजेंसी, एक मार्केट-मेकिंग टीम, एक यील्ड-स्टेटेजी ऑपरेशन, या कई समवर्ती एजेंटों के साथ किसी भी उत्पादन तैनाती का संचालन करते हैं, तो एजेंट स्वयं आसान हिस्सा हैं। आपके पास उन्हें चलाने के लिए युद्ध-परीक्षित कोड और बुनियादी ढांचा है। जो आपको धीमा करता है वह उनके चारों ओर सब कुछ है: वॉलेट पते की स्प्रेडशीट, मैन्युअल प्रति-ग्राहक समायोजन, बिखरे हुए लेनदेन लॉग, बिना किसी अन्य ग्राहक के डेटा को लीक किए बिना अपने ग्राहक को उनके अपने एजेंट की गतिविधि में दृश्यता देने का कोई साफ़ तरीका नहीं है, कोई लागू प्रति-एजेंट व्यय सीमा नहीं है।
अधिकांश टीमें पहले इसे स्वयं बनाती हैं - प्रति ग्राहक एक साझा मल्टीसिग, Notion डेटाबेस में प्रति-एजेंट लेजर, लेनदेन सूचनाओं के लिए एक Discord चैनल। यह पहले तीन ग्राहकों के लिए काम करता है। ग्राहक दस तक यह एक अंशकालिक नौकरी है। ग्राहक बीस तक कुछ गलत होगा, एक शर्मनाक गड़बड़ी जो रिश्ते की कीमत चुकाएगी।
Blockchain0x हर एजेंट को अपना वॉलेट, अपनी नीति, अपना लॉग, अपनी सीट एक्सेस देता है। आप सभी को एक कार्यक्षेत्र से प्रबंधित करते हैं, एक Stripe ग्राहक के तहत बिल किया जाता है, सही ऑपरेटरों के साथ सही एजेंटों पर। ऑप्स परत पूरा उत्पाद है; आप एजेंटों को चलाते रहते हैं।
एक एजेंसी अपने पहले कार्यक्षेत्र को कैसे प्रावधान करती है।
पांच-चरणीय वॉकथ्रू जो एक सामान्य एजेंसी को साइनअप से 5-20 क्लाइंट एजेंटों का प्रबंधन करने में उचित अलगाव, बिलिंग, और अवलोकन के साथ ले जाता है।
- 01
कार्यक्षेत्र प्रदान करें
एजेंसी के ईमेल या साझा ऑप्स खाते के तहत एक बार साइन अप करें। कार्यक्षेत्र का नाम एजेंसी की पहचान को दर्शाता है (कार्यक्षेत्र का नाम प्रति-एजेंट चालान पर दिखाई देता है)। कार्यक्षेत्र की सीटें डिफ़ॉल्ट रूप से 1 होती हैं; उन ऑपरेटरों के लिए अधिक जोड़ें जिन्हें क्रॉस-क्लाइंट दृश्यता की आवश्यकता होती है।
- 02
प्रत्येक ग्राहक (या प्रत्येक रणनीति) के लिए एक एजेंट बनाएं
प्रत्येक ग्राहक सहभागिता को अपना खुद का एजेंट रिकॉर्ड मिलता है: अलग स्लग, अलग वॉलेट पता, अलग व्यय नीति, अलग सत्यापन बैज। एजेंट रिकॉर्ड अलगाव की इकाई है - एक ग्राहक के लेनदेन कभी दूसरे के नहीं छूते, भले ही दोनों एक ही कार्यक्षेत्र के तहत चलें।
- 03
सही ऑपरेटरों को एजेंट-स्तरीय सीटें सौंपें
बिजनेस पर, ऑपरेटरों को विशिष्ट ग्राहक के एजेंट में एजेंट-स्तरीय सीटों के साथ आमंत्रित करें। वे केवल उसी एजेंट को देखते और प्रबंधित करते हैं, कभी भी कार्यक्षेत्र में अन्य नहीं। यह सीट मॉडल है जो प्रति-ग्राहक अलगाव को सही महसूस कराता है: एक ऑपरेटर गलती से ग्राहक A की गतिविधि को ग्राहक B को लीक नहीं कर सकता।
- 04
प्रति-एजेंट खर्च अनुमतियों को कॉन्फ़िगर करें
प्रत्येक एजेंट के लिए प्रति-लेनदेन सीमा और प्रति-काल भत्ता सेट करें (डैशबोर्ड में) जो ग्राहक सहभागिता वास्तव में अनुमति देता है। एक ही कार्यकर्ता एक ही कार्यक्षेत्र पर एक ग्राहक के लिए छोटे दैनिक भत्ते के साथ एक एजेंट चला सकता है और दूसरे के लिए बड़े भत्ते के साथ - प्रति-एजेंट खर्च अनुमति दोनों को साफ़ रूप से अलग करती है।
- 05
अपने मॉनिटरिंग और ऑन-कॉल को कनेक्ट करें
उन घटनाओं के लिए वेबहुक डिलीवरी सेट करें जो संचालन में महत्वपूर्ण हैं (payment.received, payment.sent, wallet.deployed)। उन्हें आपके घटना प्रणाली या Slack/Discord पर इंगित करें। डैशबोर्ड दैनिक-ड्राइवर दृश्य बन जाता है; जब एक भुगतान आता है या कुछ ध्यान देने की आवश्यकता होती है तो अलर्ट Slack पर पहुंचता है।
सेटअप आमतौर पर पहले कार्यक्षेत्र के लिए 1-2 घंटे और प्रत्येक अतिरिक्त ग्राहक एजेंट के लिए 10-15 मिनट लेता है। जब आपके पास 5 ग्राहक ऑनबोर्ड होते हैं, तो छठे को जोड़ने की सीमांत लागत ज्यादातर ग्राहक के साथ बातचीत होती है, न कि प्रावधान।
एक कार्यक्षेत्र, एक Stripe ग्राहक, N एजेंट।
बिलिंग मॉडल इस बात के चारों ओर बनाया गया है कि एजेंसियाँ वास्तव में किताबें कैसे रखती हैं: एकल चालान पर प्रति-एजेंट लाइन आइटम, प्रति एजेंट या कार्यक्षेत्र-व्यापी निर्यात करने योग्य, जिसमें एक वेबहुक स्ट्रीम होती है जो आपके लेखांकन प्रणाली में वास्तविक समय में पहुँचती है।
| आयाम | Blockchain0x इसे कैसे संभालता है | एजेंसियों को क्यों परवाह है |
|---|---|---|
| कार्यक्षेत्र संरचना | 1 कार्यक्षेत्र, N एजेंट, 1 समेकित Stripe ग्राहक | सभी ग्राहकों के बीच किसी भी भुगतान को खोजना आसान है |
| चालान प्रारूप | प्रति-एजेंट सदस्यता रेखा + प्रति-एजेंट लेनदेन-शुल्क रेखा | यदि आप ग्राहकों को फिर से चालान करते हैं तो यह प्रति-ग्राहक बिलिंग के लिए साफ-सुथरा है |
| निर्यात | प्रति एजेंट CSV/JSON, या कार्यस्थान-व्यापी; दिनांक सीमा द्वारा फ़िल्टर करने योग्य | लेखा उपकरण या प्रति-क्लाइंट P&L में डालें |
| लेखांकन के लिए वेबहुक | payment.received / payment.sent घटनाएँ आपके AP/AR सिस्टम में वास्तविक समय में। | कोई बैच सामंजस्य नहीं; खाता वर्तमान रहता है |
| मुद्रा | डिफ़ॉल्ट रूप से USD में बिल किए गए शुल्क; Stripe के माध्यम से अन्य मुद्राओं में सेट करने योग्य | अपने लेखांकन आधार मुद्रा से मेल खाएं |
| रिकॉर्ड बनाए रखा गया | लेनदेन इतिहास और ऑडिट लॉग बनाए रखा गया जब तक एजेंट मौजूद है | ग्राहक या ऑडिटर समीक्षा के लिए निर्यात योग्य |
वह पैटर्न जिस पर अधिकांश एजेंसियाँ पहुँचती हैं: Blockchain0x चालान एजेंसी को जाता है। एजेंसी अपने एजेंट की सदस्यता लाइन + एक प्रबंधन शुल्क के लिए प्रत्येक ग्राहक को फिर से चालान करती है। ऑडिट लॉग इसे बचाव योग्य बनाता है यदि कोई ग्राहक किसी विशेष शुल्क पर सवाल उठाता है - आप दिखा सकते हैं कि किस विंडो में कौन से लेनदेन ने लाइन आइटम को चलाया। किसी भी एजेंसी ने हमें ऑडिट ट्रेल बनाने के बाद कभी भी शुल्क हटाने के लिए नहीं कहा।
आप अपने ग्राहकों (और उनके ऑडिटरों) को क्या बता सकते हैं।
अनुपालन वह जगह है जहाँ अधिकांश एजेंसी संलग्नments शुरू होने से पहले विफल हो जाते हैं। ग्राहक की कानूनी टीम जानना चाहती है: कौन धन रखता है, कौन क्या देख सकता है, रिकॉर्ड कैसे रखे जाते हैं, यदि कोई घटना होती है तो क्या होता है। यहाँ आप उन्हें क्या बता सकते हैं, लिखित में, उत्पाद द्वारा समर्थित।
कस्टडी - हम गैर-निगरानी हैं
फंड क्लाइंट (या एजेंसी) वॉलेट में रहते हैं, Blockchain0x पर नहीं। हमारे पास कभी भी निजी कुंजी नहीं होती। अगर हम कल समझौता कर लेते हैं, तो हमलावर USDC नहीं हिला सकता क्योंकि हमारे पास ऐसा करने के साधन नहीं हैं। यह एक भुगतान प्लेटफॉर्म द्वारा किए जाने वाले सबसे मजबूत हिरासत का दावा है; यह शर्तों में लिखा गया है।
पहुँच नियंत्रण - प्रति-एजेंट सीट स्कोपिंग
ऑपरेटर केवल उन्हीं एजेंटों को देखते हैं जिन पर उन्हें सीटें दी गई हैं। कार्यक्षेत्र स्तर की दृश्यता एक अलग, अधिक विशेषाधिकार प्राप्त सीट है। प्रत्येक सीट जोड़ना, भूमिका परिवर्तन और हटाना ऑडिट लॉग में पूर्ण श्रेय के साथ दर्ज किया जाता है। कार्यक्षेत्र सीटों के लिए दो-कारक प्रमाणीकरण आवश्यक है।
ऑडिट ट्रेल - अट्रिब्यूटेड और निर्यात करने योग्य
हर क्रिया जो एक एजेंट को प्रभावित करती है, उसे पूर्ण श्रेय के साथ रिकॉर्ड किया जाता है: किसने किया, कब, और परिवर्तन का पहले/बाद। किसी भी ग्राहक या ऑडिटर समीक्षा के लिए डैशबोर्ड से JSON या CSV में निर्यात करें, एकल एजेंट तक सीमित ताकि एक ग्राहक के रिकॉर्ड कभी दूसरे के रिकॉर्ड को उजागर न करें।
स्वीकृत उपयोग नीति - प्रत्येक एजेंट पर बाध्यकारी
प्रत्येक कार्यक्षेत्र साइनअप पर एक स्वीकार्य-उपयोग नीति से सहमत होता है: कोई प्रतिबंधों से बचाव, कोई धन शोधन, कोई धोखाधड़ी, कोई एजेंट स्पष्ट रूप से अवैध गतिविधियों में संलग्न नहीं होते। उल्लंघनों के परिणामस्वरूप कार्यक्षेत्र निलंबन होता है। नीति सार्वजनिक रूप से संस्करणित है; हम किसी भी ग्राहक कानूनी समीक्षा के लिए एक वर्तमान और ऐतिहासिक संस्करण तैयार करेंगे।
घटना प्रतिक्रिया - प्रलेखित रनबुक
सुरक्षा घटनाओं का एक सार्वजनिक रनबुक है: खोज के 24 घंटे के भीतर सूचना, 7 दिनों के भीतर मूल कारण विश्लेषण, 30 दिनों के भीतर पोस्ट-मॉर्टम। रनबुक अनुपालन समीक्षा के लिए अनुरोध पर उपलब्ध है। लेखन के समय हमारे पास कोई नोटिफ़िएबल घटना नहीं थी; यदि और जब हम ऐसा करते हैं, तो रनबुक अनुबंध है।
हर ऑडिट-लॉग प्रविष्टि पर क्या आता है।
ऑडिट लॉग वह वस्तु है जिसे आपके ग्राहक का ऑडिटर देखना चाहता है। प्रत्येक प्रविष्टि रिकॉर्ड करती है कि क्या बदला और किसने इसे बदला; किसी भी ग्राहक या ऑडिटर समीक्षा के लिए डैशबोर्ड से पूरे लॉग को JSON या CSV में निर्यात करें।
| क्षेत्र | प्रकार | विवरण |
|---|---|---|
| Timestamp | time | action कब हुआ, UTC में. |
| Agent | reference | action किस agent को प्रभावित करता है. |
| Actor | reference | वह human, API key, या system जिसने action लिया. |
| Action | category | क्या हुआ: एक payment, एक settings change, एक seat change, एक key rotation. |
| Outcome | status | क्या action सफल हुआ या अस्वीकार किया गया. |
| पहले / बाद में | snapshot | किसी change के दोनों पक्षों की state. |
डैशबोर्ड से JSON या CSV में निर्यात करें, एकल एजेंट या पूरे कार्यक्षेत्र पर फ़िल्टर करें। ऑडिट लॉग एक व्यवसाय-योजना विशेषता है; बुनियादी लेनदेन इतिहास प्रो पर उपलब्ध है।
एजेंसी कार्यक्षेत्र के लिए बिजनेस, एजेंटों के लिए मिश्रित योजनाएँ।
Web3 ऑटोमेशन टीमों को लगभग हमेशा कम से कम एक बिजनेस एजेंट (ऑडिट लॉग + टीम सीटों के लिए) की आवश्यकता होती है। कई मिश्रण चलाते हैं: उच्च मात्रा के ग्राहक अनुबंधों के लिए बिजनेस जिनमें अनुपालन आवश्यकताएँ होती हैं, छोटे ग्राहकों के लिए प्रो जहां ऑडिट लॉग अनुबंधित रूप से आवश्यक नहीं होते हैं, प्रयोगात्मक या निष्क्रिय एजेंटों के लिए फ्री। प्रति-एजेंट मूल्य निर्धारण वह है जो मिश्रण को बिना अधिक भुगतान किए काम करता है।
- Free: experiments, dormant agents जिन्हें आप फिर से active कर सकते हैं, prospect conversations के लिए demo agents।
- Pro ($29/agent/mo): strict compliance requirements के बिना active client agents।
- Business ($49/agent/mo): बड़े पैमाने पर client agents, audit logs और per-agent team seats के साथ। production engagements के लिए default।
- Workspace seats: cross-client operator visibility के लिए seats जोड़ें (/pricing देखें).