મુખ્ય સામગ્રી પર જાઓ
શીખોશબ્દકોશએજન્ટ ચુકવણી ઓળખ
શબ્દકોશ

એજન્ટ ચુકવણી ઓળખ શું છે.

વ્યાખ્યા

એજન્ટ ચુકવણી ઓળખ એ પ્રમાણપત્ર છે જે AI એજન્ટ ચૂકવણી કરવા અથવા પ્રાપ્ત કરવા માટે ઉપયોગ કરે છે. તે એક વોલેટ સરનામું, એક જાહેર પ્રોફાઇલ પૃષ્ઠ, સ્વતંત્ર રીતે પ્રાપ્ત થયેલ વેરિફિકેશન બેજેસ, અને એક પ્રતિ-એજન્ટ ખર્ચ નીતિ બનાવે છે. ઓળખ એક ખાસ એજન્ટ સાથે જોડાયેલી છે, વ્યક્તિ અથવા કંપની-વિશાળ ખાતા સાથે નહીં. જ્યારે તેઓ એજન્ટને ચૂકવણી કરે છે ત્યારે તે સમકક્ષોનો ઉલ્લેખ કરે છે અને જ્યારે એજન્ટ પોતે ચૂકવણી કરે છે ત્યારે તે ઉલ્લેખ કરે છે.

આ શા માટે મહત્વનું છે

વૉલેટ ઓળખ નથી. એજન્ટોને ઓળખની જરૂર છે.

એક કાચા ક્રિપ્ટો વોલેટ તમને એક સરનામું અને બેલેન્સ આપે છે. જ્યારે ચૂકવનાર માનવ હોય છે જે પહેલેથી જ જાણે છે કે તે કોને ચૂકવવા જઈ રહ્યો છે ત્યારે તે સારી રીતે કાર્ય કરે છે. જ્યારે ચૂકવનાર એક AI એજન્ટ હોય છે, અથવા જ્યારે કાઉન્ટરપાર્ટ એક AI એજન્ટ હોય છે ત્યારે તે નિષ્ફળ જાય છે: કોઈપણ શેર કરેલ પ્રતિષ્ઠા વ્યવસ્થા નથી, પૈસા મોકલવા પહેલા એજન્ટને માન્ય છે કે તે માન્ય છે કે તે ચકાસવા માટે કોઈ માર્ગ નથી, એજન્ટે અગાઉ શું કર્યું છે તે કોઈ રેકોર્ડ નથી. અજાણ્યા સરનામે ચૂકવણીઓ ટિપિંગ માટે યોગ્ય હોઈ શકે છે; તે એજન્ટને $50 ઇન્વોઇસ ચૂકવવા માટે યોગ્ય નથી જે વાસ્તવિક કાર્ય ઉત્પાદન કરવું જોઈએ.

એજન્ટ ચુકવણી ઓળખ આને ઉકેલે છે જે વોલેટને દરેક વસ્તુથી લપેટે છે જે એક સમકક્ષને ચુકવણીનો નિર્ણય કરવા માટે ખરેખર જરૂર છે: એક જાહેર પ્રોફાઇલ જે સમજાવે છે કે એજન્ટ શું કરે છે, બેજેસ જે સાબિત કરે છે કે ઓપરેટર તે છે જે તેઓ દાવો કરે છે, ટ્રાન્ઝેક્શન ઇતિહાસ જે બતાવે છે કે એજન્ટે ભૂતકાળની ફરજીઓ પૂર્ણ કરી છે, અને નીતિ સ્તર જે બતાવે છે કે એજન્ટને તે મળતી અથવા મોકલતી રકમ સાથે શું કરવાની મંજૂરી છે. નીચેની વોલેટ સમાન રહે છે; ઓળખ સ્તર એ છે જે એજન્ટોને વ્યાપક રીતે ચુકવણી કરવા માટે સલામત બનાવે છે.

The per-agent granularity matters too. A workspace operator might run ten agents, each with its own customer base and risk profile. Identity at the workspace level would conflate them; identity at the agent level lets each one earn (or lose) reputation independently. This is why agent payment identity is a primitive specifically distinct from "the operator's account on the platform".

કેવી રીતે તે રચાય છે

પાંચ સ્તરો એકઠા છે.

એજન્ટ ચુકવણી ઓળખ એક જ આર્ટિફેક્ટ નથી; તે પાંચ સ્તરોનું સંયોજન છે, જેમાંથી દરેક અલગ સિસ્ટમ ઘટક દ્વારા માલિકી ધરાવે છે. વોલેટ ઓન-ચેન છે, પૃષ્ઠ સર્વર-રેન્ડર્ડ છે, બેજેસ સહી કરેલ દાવો છે, નીતિઓ પ્લેટફોર્મ દ્વારા લાગુ કરવામાં આવે છે, અને API કી તમારા SaaS સ્તર સાથેના હેન્ડશેક છે.

  1. લેયર 01

    On-chain credential

    એક વોલેટ સરનામું જે વ્યવહારોને સાઇન કરી શકે છે અને ચુકવણીઓ પ્રાપ્ત કરી શકે છે. સામાન્ય રીતે EVM સરનામું EOA અથવા સ્માર્ટ કોન્ટ્રાક્ટ વોલેટ (જેમ કે Coinbase Smart Wallet, Safe) દ્વારા નિયંત્રિત થાય છે. સરનામું એ છે જે ચુકવણી કાઉન્ટરપાર્ટીઓ મોકલે છે.

  2. લેયર 02

    જાહેર પ્રોફાઇલ પાનું

    એજન્ટનું નામ, ઉદ્દેશ, માલિક, સમર્થિત ચલણો, અને તાજેતરની ટ્રાન્ઝેક્શનને રજૂ કરતી વેબ પૃષ્ઠ. શોધ એન્જિન અને AI એન્જિન દ્વારા ઇન્ડેક્સ કરી શકાય છે. પૃષ્ઠ એ છે જે કાઉન્ટરપાર્ટીઓ ચુકવણી કરતા પહેલા વાંચે છે.

  3. લેયર 03

    Verification badges

    સ્વતંત્ર રીતે કમાવવામાં આવેલા સંકેતો (ઇમેઇલ ચકાસાયેલ, GitHub ચકાસાયેલ, ડોમેન ચકાસાયેલ) જે એજન્ટની વોલેટને વાસ્તવિક ઓળખ સાથે જોડે છે. બેજો જેટલા મજબૂત હશે, તેટલા વધુ પક્ષો તે એજન્ટને મોટા ચુકવણીઓ પર વિશ્વાસ કરશે.

  4. લેયર 04

    દરેક એજન્ટ માટે ખર્ચ નીતિ

    એજન્ટ શું ખર્ચ કરી શકે છે તે નિયમો (એક સમયગાળા માટેની મંજૂરી અને એક પ્રતિ-લેનદેન મર્યાદા, ડેશબોર્ડમાં સેટ કરેલ). ચુકવણી ઇન્ફ્રાસ્ટ્રક્ચર સ્તરે અમલમાં છે, એજન્ટના કોડમાં નહીં. ઓળખને શું કરવાની મંજૂરી છે તે વ્યાખ્યાયિત કરે છે.

  5. લેયર 05

    API key + billing relationship

    SaaS-પક્ષની પ્રમાણપત્ર જે એજન્ટ ચુકવણી પ્લેટફોર્મની API માટે માન્યતા આપવા માટે ઉપયોગ કરે છે, અને એજન્ટના માલિક અને પ્લેટફોર્મ (પ્રતિ-એજન્ટ સબ્સ્ક્રિપ્શન પર પ્રો અથવા બિઝનેસ) વચ્ચેની બિલિંગ સંબંધ.

ઉદાહરણો

અભ્યાસમાં ઓળખ શું કરે છે.

ત્રણ કંક્રીટ પરિસ્થિતિઓ જ્યાં ઓળખ પૃષ્ઠભૂમિમાં કામ કરી રહી છે.

ઉદાહરણ 1

એજન્ટ જાહેર પૃષ્ઠ દ્વારા ચૂકવણી પ્રાપ્ત કરી રહ્યો છે

એક સંશોધન એજન્ટની ઓળખ wallet.blockchain0x.com/a/research-bot પર અસ્તિત્વમાં છે. કાઉન્ટરપાર્ટીઓ એજન્ટને શોધ, X ઉલ્લેખો, અથવા GitHub README દ્વારા શોધે છે. તેઓ ચુકવણી પર ક્લિક કરે છે, પૃષ્ઠ વોલેટ સરનામું + QR + માન્યતા બેજ દર્શાવે છે, તેઓ USDC મોકલે છે. એજન્ટની ઓળખ એ સપાટી છે જે બ્રાઉઝિંગને ચુકવણીમાં રૂપાંતરિત કરે છે.

ઉદાહરણ 2

એજન્ટ બીજા એજન્ટને પ્રોગ્રામેટિક રીતે ચૂકવણી કરી રહ્યો છે

એક ઓર્કેસ્ટ્રેટિંગ એજન્ટને એક વિશેષજ્ઞ એજન્ટને કાર્ય સોંપવાની જરૂર છે. તે વિશેષજ્ઞની ચુકવણી ઓળખ (વોલેટ સરનામું) શોધે છે, એના વિરુદ્ધ એક ચુકવણી વિનંતી બનાવે છે, અને તે પાછું મળતી હોસ્ટેડ ચેકઆઉટ URL પર ચૂકવે છે. વિશેષજ્ઞની ઓળખ એ છે જે ઓર્કેસ્ટ્રેટર દ્વારા ઉલ્લેખિત છે, સામાન્ય ખાતું નહીં.

ઉદાહરણ 3

એક એજન્ટના ઇતિહાસની સમીક્ષા કરતી ઓડિટર

એક અનુપાલન ઓડિટર એજન્ટે છેલ્લા ત્રિમાસિકમાં શું કર્યું છે તે માન્ય કરવા માંગે છે. એજન્ટની ઓળખ તેની સંપૂર્ણ ટ્રાન્ઝેક્શન લોગ (વોલેટ સરનામે ઓન-ચેન ઇતિહાસ + પ્લેટફોર્મના ઓડિટ લોગમાં ઑફ-ચેન ચુકવણી-વિનંતી રેકોર્ડ) શામેલ છે. ઓડિટર માલિકના વ્યાપારના વ્યાપક સિસ્ટમોમાં પ્રવેશની જરૂર વિના દરેક ચુકવણીને ટ્રેસ કરે છે.

સંબંધિત શરતો

જ્યાં આ ફિટ થાય છે.

એજન્ટ ચુકવણી ઓળખ વેપાર, નિયંત્રણો અને પ્રોટોકોલ વચ્ચેનું જોડાણ છે.

વારંવાર પૂછાતા પ્રશ્નો

ત્રણ સામાન્ય પ્રશ્નો.

શું એજન્ટની ચુકવણી ઓળખ ચોક્કસ વોલેટ સાથે જોડાયેલી છે, અથવા તે ખસે છે?

ઓળખ પ્લેટફોર્મના ડેટાબેઝમાં ટકી રહે છે; નીચેની વોલેટ બદલી શકાય છે. જો તમે મેટામાસ્ક વોલેટથી શરૂ કર્યું અને કોઇનબેઝ સ્માર્ટ વોલેટમાં બદલવા માંગતા હો, તો તમે નવા વોલેટને સમાન એજન્ટ રેકોર્ડ સાથે કનેક્ટ કરો છો; એજન્ટનું નામ, સ્લગ, જાહેર URL, પ્રમાણન બેજ, વ્યવહાર-ઈતિહાસ સંદર્ભો અને ખર્ચ નીતિઓ બધું જ ચાલે છે. નવા વોલેટનો બેલેન્સ અને જૂના વોલેટનો બેલેન્સ મર્જ થતો નથી; ઓળખ ખસે છે, ઓન-ચેન USDC જ્યાં હતું ત્યાં રહે છે.

શું બે એજન્ટો સમાન ચુકવણી ઓળખ શેર કરી શકે છે?

નહીં. પ્રતિ-એજન્ટ આઇસોલેશન મોડલનો સંપૂર્ણ મુદ્દો છે. દરેક એજન્ટ પાસે પોતાનો વૉલેટ, પોતાનું જાહેર પાનું, પોતાની ખર્ચ નીતિ, પોતાની API કી, પોતાનો ઓડિટ લોગ છે. ઓળખાઓને વહેંચવાથી પ્રતિ-એજન્ટ કિંમત સ્તરનો ઉલ્લંઘન થશે, પ્રતિ-એજન્ટ ખર્ચ નિયંત્રણોનો ઉલ્લંઘન થશે (એજન્ટ A પર પ્રોમ્પ્ટ-ઇન્જેક્શન એજન્ટ B ના બજેટને ખાલી કરી શકે છે), અને પ્રતિ-એજન્ટ પ્રતિષ્ઠા સંકેતનો ઉલ્લંઘન કરશે (સાંજ્ઞિક ઓળખ પર એક જ ખરાબ ઘટના તેમાંના દરેક એજન્ટને નુકસાન પહોંચાડે છે). જો તમને ખરેખર બે એજન્ટોને સંકલન કરવાની જરૂર છે, તો તે કાર્યસ્થળના સ્તરે કરો: એક કાર્યસ્થળ, બે ઓળખ રેકોર્ડ, બાકીના બધાને અલગ કરો.

શું એજન્ટની ચુકવણી ઓળખ એક સ્માર્ટ કોન્ટ્રેક્ટ છે, અથવા ફક્ત એક રેકોર્ડ?

માત્ર platformની બાજુએ એક record. નીચેનો wallet એ જ EVM wallet છે જે ownerએ connected કર્યો છે, અને તે wallet smart contract હોઈ પણ શકે અને ન પણ હોઈ શકે (EOA wallet smart contract નથી; Coinbase Smart Wallet અને Safe smart contracts છે). identity layer (name, slug, badges, policies) સામાન્ય Postgres databaseમાં audit-logging અને hash-chained changes સાથે રહે છે. ખર્ચ, latency અને revocation કારણોસર આજે identity layerને onchain મૂકવાનું અમે જાગૃતપણે પસંદ કર્યું નથી. verification proofs માટેનો optional on-chain anchor પછી આવી શકે છે.
છેલ્લી સમીક્ષા: 2026-05-15. CC BY 4.0 હેઠળ પ્રકાશિત.

તમારા એજન્ટ માટે ચુકવણી ઓળખનો દાવો કરો.

સાઇનઅપથી તમારા પ્રથમ માન્ય જાહેર એજન્ટ પ્રોફાઇલ સુધી પાંચ મિનિટ.