افشای منافع: این وبلاگ متعلق به OrcaRail است و OrcaRail یکی از درگاه‌های این فهرست است. همه ارقام مربوط به رقبا از صفحه تعرفه یا مستندات خود آن‌ها گرفته شده، در تاریخ ۱۳ اکتبر ۲۰۲۶ بررسی شده و لینک منبع کنارش آمده است. تعرفه‌ها تغییر می‌کنند؛ پیش از تصمیم‌گیری با خود ارائه‌دهنده چک کنید.
| درگاه | کارمزد اعلام‌شده (پلن استاندارد) | پرداخت دوره‌ای | مدل |
|---|---|---|---|
| OrcaRail | ۰٫۵٪ برای هر تراکنش تکمیل‌شده، ۱٬۰۰۰ تراکنش اول رایگان؛ بدون کارمزد در نصب روی سرور خودتان | بله: لینک پرداخت برای هر دوره، یا برداشت خودکار روی زنجیره (EVM، سولانا) | API میزبانی‌شده یا نصب روی سرور خودتان؛ به‌طور پیش‌فرض غیرامانی |
| Coinbase Commerce | ۱٪ | مستند نشده | میزبانی‌شده |
| BitPay | ۲٪ + ۰٫۲۵ دلار (در حجم بالاتر کمتر) | مبتنی بر فاکتور | میزبانی‌شده، تسویه به ارز فیات یا کریپتو |
| NOWPayments | از ۰٫۵٪ (۱٪ با تبدیل ارز) | بله: فاکتور دوره‌ای | میزبانی‌شده |
| CoinGate | ۱٪ | فاکتور زمان‌بندی‌شده | میزبانی‌شده |
| CoinPayments | ۳٪ + کارمزد شبکه | مستند نشده | میزبانی‌شده |
| Cryptomus | ۲٪ برای حساب‌های جدید، قابل مذاکره تا ۰٫۴٪ | بله | میزبانی‌شده |
| پرداخت استیبل کوین Stripe | ۱٫۵٪ | بله، از طریق Stripe Billing | میزبانی‌شده، تسویه به ارز فیات |
| MoonPay Commerce (Helio) | ۱٪ تا ۲٪ | بله | میزبانی‌شده |
| BTCPay Server | ندارد (هزینه سرور با شماست) | به‌صورت داخلی ندارد | نصب روی سرور خودتان، متن‌باز |
کارمزد شبکه (گس) در همه درگاه‌ها جداگانه است و اینکه چه کسی آن را می‌پردازد به ارائه‌دهنده و تنظیمات شما بستگی دارد.
OrcaRail یک API برنامه‌نویس‌محور برای صفحه پرداخت و اشتراک با استیبل کوین روی شبکه‌های EVM و سولانا است.
ak_test_.Coinbase Commerce صفحه پرداخت فروشندگان در Coinbase است.
BitPay یکی از قدیمی‌ترین پردازشگرهای پرداخت کریپتو است و به حساب بانکی یا به ارز دیجیتال تسویه می‌کند.
NOWPayments از فهرست بلندی از رمز ارزها پشتیبانی می‌کند.
CoinGate یک پردازشگر میزبانی‌شده مستقر در اتحادیه اروپاست.
CoinPayments از رمز ارزها و توکن‌های زیادی پشتیبانی می‌کند.
Cryptomus پرداخت، تسویه و تبدیل را در یک حساب ارائه می‌دهد.
Stripe استیبل کوین می‌پذیرد و آن را در موجودی Stripe شما به ارز فیات محلی تسویه می‌کند.
MoonPay Commerce همان محصول Helio است که از اکوسیستم سولانا شکل گرفت.
BTCPay Server نرم‌افزاری رایگان، متن‌باز و قابل نصب روی سرور خودتان است که روی بیت کوین و لایتنینگ تمرکز دارد.
برای امتحان OrcaRail یک سندباکس رایگان باز کنید و راهنمای شروع کار را دنبال کنید.
]]>اگر فقط می‌خواهید جریان را ببینید، اصلاً به توکن نیاز ندارید: در صفحه پرداخت sandbox روی شبیه‌سازی پرداخت کلیک کنید یا POST /payment_intents/:id/simulate را فراخوانی کنید. شبیه‌سازی پرداخت را ببینید.
از همان کیف پول پرداخت‌کننده‌ای استفاده کنید که در صفحه پرداخت OrcaRail وصل می‌کنید.
فاست USDC سیرکل روی هر یک از شبکه‌های آزمایشی EVM زیر و روی Solana Devnet، USDC آزمایشی رایگان می‌فرستد. شبکه را انتخاب کنید، آدرس کیف پولتان را وارد کنید و توکن‌ها را درخواست کنید.
| شبکه | USDC آزمایشی | گس (ETH) |
|---|---|---|
| Ethereum Sepolia | فاست Circle | فاست Google Cloud، فاست Alchemy |
| Arbitrum Sepolia | فاست Circle | فاست Alchemy، فاست QuickNode |
| Base Sepolia | فاست Circle | فاست Coinbase Developer Platform، فاست Alchemy، فاست QuickNode |
مستندات زنجیره‌ها هم فاست‌هایی معرفی می‌کنند: Arbitrum و Base.
| توکن | فاست |
|---|---|
| USDC آزمایشی | فاست Circle (Solana Devnet را انتخاب کنید) |
| SOL برای کارمزد | فاست سولانا |
OrcaRail از testnet4 بیت‌کوین استفاده می‌کند (اکسپلورر: mempool.space testnet4). از کیف پولی استفاده کنید که آدرس‌های testnet4 را پشتیبانی کند.
| توکن | فاست |
|---|---|
| BTC آزمایشی | فاست mempool.space testnet4، فاست testnet4.dev، CoinFaucet testnet4 |
این پکیج‌ها در GitHub عمومی‌اند و مجوز MIT دارند:
| پکیج | رجیستری / نقش | مخزن |
|---|---|---|
| SDK نود | @orcarail/node | orcarail/orcarail-node |
| SDK پی‌اچ‌پی | orcarail/orcarail-php | OrcaRail/sdks-php |
| Laravel Cashier | orcarail/cashier-orcarail | OrcaRail/sdks-laravel-cashier |
| سرور MCP | @orcarail/mcp | OrcaRail/mcp |
| افزونه ووکامرس | orcarail/plugins-woocommerce | OrcaRail/plugins-woocommerce |
| اپ دمو | نمونه کامل یکپارچه‌سازی | OrcaRail/demo |
مثل همیشه از npm یا Composer نصب کنید؛ منبع اصلی هر پکیج همان مخزنی است که بالا آمده است.
از پکیج‌ها در اپ‌هایتان استفاده کنید. برای APIها و نمونه‌ها، ایجنت‌ها و افراد را به مخزن‌ها و docs.orcarail.com ارجاع دهید.
باگ‌ها و درخواست قابلیت‌ها را در GitHub Issues پکیج مورد نظرتان گزارش کنید:
هر وقت توانستید مشارکت کنید: fork کنید، پول ریکوئست باز کنید و تغییرات را متمرکز نگه دارید. اصلاح مستندات، آزمون‌ها و بهبودهای کوچک SDK به‌ویژه استقبال می‌شوند. اگر مطمئن نیستید چیزی کجا باید برود، اول یک issue باز کنید.
SDKها و افزونه‌های متن‌باز یعنی می‌توانید ببینید OrcaRail چطور با زیرساخت شما ارتباط برقرار می‌کند، کمبودها را بدون انتظار برای یک فروشنده بسته رفع کنید و بهبودها را با همه کسانی که همین زیرساخت را یکپارچه می‌کنند به اشتراک بگذارید.
نسخه میزبانی‌شده OrcaRail همچنان سطح محصول برای پرداخت‌ها، داشبوردها و زیرساخت عملیاتی است. این اعلامیه درباره پکیج‌های توسعه‌دهندهای است که با آن‌ها یکپارچه می‌شوید؛ ادعا نمی‌کند کل پلتفرم متن‌باز است.
| حوزه | وضعیت |
|---|---|
| مجوز | MIT |
| پکیج‌ها | SDK نود، SDK پی‌اچ‌پی، Laravel Cashier، سرور MCP، افزونه ووکامرس، دمو |
| جامعه | از پکیج‌ها استفاده کنید، issue ثبت کنید، پول ریکوئست بفرستید |
ممنون که روی OrcaRail می‌سازید. اگر چیز مفیدی ساختید، PR باز کنید؛ یا اگر کمک لازم دارید، issue.
اپ OrcaRail · مستندات · GitHub
]]>این مطلب فهرست اصلی است. هر مرحله مطلب تفصیلی و صفحه مستندات زنده خودش را دارد تا بتوانید دقیقاً به بخشی که برایتان مهم است لینک بدهید.
جریان فعلی کار می‌کند، اما یک مشکل ساختاری ساده دارد: بین واریز و تسویه، وجوه نزد OrcaRail است. این موضوع حتی با وجود اینکه ما هرگز موجودی عملیاتی فروشندگان را نگه نمی‌داریم صادق است؛ لحظه بین «پرداخت‌کننده فرستاد» و «فروشنده دریافت کرد» امانی است. حذف این لحظه از نظر امنیت، انطباق و قابلیت اطمینان یک برد است.
به‌طور مشخص، مسیر قدیمی این شکل است:
هدف این است:
وجوه هرگز از کیف پولی که ما کنترل می‌کنیم عبور نمی‌کنند. تقسیم‌ها روی زنجیره انجام می‌شوند. اشتراک‌ها از allowanceی برداشت می‌کنند که پرداخت‌کننده هر لحظه می‌تواند لغوش کند.
| حوزه | قبل | بعد |
|---|---|---|
| آدرس‌های لینک پرداخت | EOA مشتق از HD یا smart account آلکمی برای هر لینک | CREATE2 قطعی روی EVM؛ PDA روی سولانا؛ هیچ کلیدی نزد OrcaRail ذخیره نمی‌شود |
| تسویه | تراکنش جاروب پس از مشاهده | تقسیم اتمیک داخل قرارداد گیرنده در همان تراکنش پرداخت |
| اشتراک‌ها | برداشت امانی از کیف پولی که فروشنده شارژ کرده | پرداخت‌کننده approve در ERC-20 یا delegate در SPL امضا می‌کند؛ keeper تابع charge(id) را صدا می‌زند |
| Keeper | یک زمان‌بند واحد در NestJS | NestJS اصلی + Chainlink Automation یا Gelato به‌عنوان پشتیبان (+ EigenLayer اختیاری) |
| بین‌زنجیره‌ای | پل Relay که keeper اجرا می‌کند | همان مسیر Relay، اما به‌صورت فراخوانی روی زنجیره از یک گیرنده غیرامانی |
| بیت‌کوین | کیف پول داغ با xpub نگهداری‌شده روی سرور | مولتی‌سیگ taproot دو از دو برای هر لینک (فروشنده + پلتفرم) با بازپرداخت‌های از پیش امضاشده |
هر مرحله مستقل و قابل انتشار است. مراحل اول امانت‌داری را برای بیشترین حجم (پرداخت‌ها و اشتراک‌های EVM) حذف می‌کنند و مراحل بعدی سراغ زنجیره‌های سخت‌تر و غیرمتمرکزسازی اختیاری می‌روند.
PaymentLinkFactory + PaymentLinkReceiver + FeeSplitter، آدرس‌های قطعی و ایندکسر رویدادها.SubscriptionHub، جریان جدید پرداخت‌کننده و keeper به‌جای پردازشگر امانی برداشت خودکار.payment_link و subscription، برداشت خودکار با delegate در SPL.hd_wallet_seed، حذف مسیرهای جاروب و به‌روزرسانی شرایط استفاده.یک مطلب همراه، چرا برداشت مبتنی بر allowance از اسکرو و session key بهتر است، توضیح می‌دهد مدل اشتراک را چطور انتخاب کردیم.
برای فروشندگان: پس از مرحله ۱ چیزی در API تغییر نمی‌کند؛ آدرس لینک‌های پرداخت و وب‌هوک‌ها همان رفتار را دارند. قواعد برداشت از «تسویه پس از جاروب» به «ارسال هنگام پرداخت» تغییر می‌کند. بدون تغییر کد، مسیری سریع‌تر، ارزان‌تر و قابل حسابرسی‌تر دارید. مرحله ۲ یک اندپوینت عمومی جدید اضافه می‌کند تا پرداخت‌کنندگان approve روی زنجیره خود را ثبت کنند؛ مطابق جریانی که در برداشت خودکار مستند شده است.
برای پرداخت‌کنندگان: پرداخت‌های یک‌باره دقیقاً همان حس را دارند. اشتراک‌ها هنگام راه‌اندازی یک امضای اضافه (همان approve روی زنجیره) و مسیر «لغو» شفاف‌تری دارند: روی زنجیره لغو کنید و OrcaRail دیگر تلاشی نمی‌کند. وجوه شما تا وقتی قرارداد برداشتشان نکند از کیف پولتان خارج نمی‌شوند و هرگز در کیف پولی که ما کنترل می‌کنیم نمی‌مانند.
برای یکپارچه‌کنندگان: ساختار API پایدار می‌ماند. فیلدهای جدید (آدرس قراردادها، زنجیره استقرار، فراداده allowance) فقط اضافه می‌شوند و پشت یک feature flag برای هر زنجیره قرار دارند. یکپارچه‌سازی‌های فعلی در دوره تمدید جاری خود به کار ادامه می‌دهند و با انتخاب خودشان مهاجرت می‌کنند.
بیت‌کوین. در مرحله ۵ با انتقال هر لینک به مولتی‌سیگ taproot دو از دو با یک امضاکننده از طرف فروشنده، به‌علاوه PSBTهای بازپرداخت از پیش امضاشده، امانت‌داری را به‌طور چشمگیری کاهش می‌دهیم. اما لایه ۱ بیت‌کوین امروز قدرت بیان قراردادی کافی برای حذف کامل امانت‌داری ندارد. اشتراک‌های BTC تا آماده شدن پرداخت‌های دوره‌ای Lightning BOLT12 خارج از دامنه می‌مانند.
برنامه کامل در /docs/non-custodial/roadmap پیگیری می‌شود و هر مرحله صفحه وضعیت خودش را دارد:
هر بار که مرحله‌ای منتشر شود، یک مطلب به‌روزرسانی تاریخ‌دار منتشر می‌کنیم.
برای نسخه مرجع همه این موارد (نمودارهای معماری، سطح قراردادها، راهنمای مهاجرت، مدل امنیتی) از /docs/non-custodial/overview شروع کنید.
این سند نقشه راه غیرامانی و مناظره پروتکل را گسترش می‌دهد و جایگزین آن‌ها نمی‌شود. نقشه راه غیرامانی (مسیر N، مراحل ۰ تا ۷) امانت‌داری را حذف می‌کند. این وایت‌پیپر یک مسیر موازی P اضافه می‌کند که بقیه چیزها را غیرمتمرکز می‌کند: ایندکسرها، فرانت‌اندها، استانداردها، keeperها و حاکمیت.
پروتکل OrcaRail مجموعه‌ای از اجزای پایه روی زنجیره است (کارخانه‌ها و گیرنده‌های لینک پرداخت، هاب‌های اشتراک مبتنی بر allowance، تقسیم‌کننده‌های کارمزد، برنامه‌های Anchor روی سولانا و توصیف‌گرهای مولتی‌سیگ taproot روی بیت‌کوین) به‌همراه مشخصات عمومی برای ایندکسرها، keeperها، فرانت‌اندها و SDKهایی که روی این اجزا کار می‌کنند. پروتکل چهار اصل ثابت را برآورده می‌کند: غیرامانی (هیچ طرفی وجوه در حال انتقال را نگه نمی‌دارد)، بی‌وقفه (تسویه مشروع بدون OrcaRail ادامه می‌یابد)، بی‌طرف به‌طور معتبر (هیچ طرف واحدی نمی‌تواند تراکنش پرداخت‌شده و درست‌ساخت را سانسور کند) و سازگار با وب۲ (فروشندگان کلید API، وب‌هوک و داشبورد خود را حفظ می‌کنند). استقرار در دو مسیر موازی انجام می‌شود: مسیر N امانت‌داری را در هفت مرحله حذف می‌کند؛ مسیر P ایندکس‌گذاری، فرانت‌اندها، استانداردها و مسیریابی تسویه را در پنج مرحله غیرمتمرکز می‌کند. هنگام راه‌اندازی هیچ توکنی وجود ندارد و در این وایت‌پیپر هم برنامه‌ای برای آن نیست؛ توکن حاکمیتی آینده صراحتاً به‌عنوان یک گزینه برای پس از غیرمتمرکزسازی رزرو شده و اگر روزی معرفی شود، با وایت‌پیپر مخصوص خودش منتشر خواهد شد.
OrcaRail امروز یک محصول پرداخت میزبانی‌شده است و گزینه‌های نصب روی سرور خودتان در راه است. این یک محصول است، نه پروتکل. محصولات را می‌توان بهتر کرد؛ به پروتکل‌ها می‌توان در غیاب سازنده‌شان اعتماد کرد.
نقشه راه غیرامانی امانت‌داری را از مسیر خارج می‌کند. این لازم است اما کافی نیست. حتی بدون امانت‌داری، یک زیرساخت پرداخت ممکن است از کار بیفتد اگر شرکت گرداننده‌اش قبض‌های AWS را نپردازد، تحریم شود یا فقط مسیرش را عوض کند. پروتکل باید وقتی این اتفاق‌ها می‌افتد همچنان کار کند.
مناظره پروتکل پنج معماری را بررسی کرد. جمع‌بندی این بود: مسیر «عمل‌گرا» را منتشر کن، فشار «حداکثرگرا» را روی آن حفظ کن، intentها را برای تجربه پرداخت‌کننده بپذیر، در طول راه استاندارد بنویس و زنجیره اختصاصی را آینده‌ای اختیاری نگه دار. این وایت‌پیپر همان جمع‌بندی است که به شکل تعهد نوشته شده است.
هر هدف با تعریفی دقیق و قابل آزمون بیان شده است. پرسش «آیا طراحی این را برآورده می‌کند؟» باید پاسخ بله یا خیر داشته باشد.
طراحی‌ای که هر یک از این اهداف را از دست بدهد ناقص است.
اصطلاح همتا‌به‌همتا (P2P) معانی زیادی دارد. در این پروتکل سه لایه مشخص دارد.
SubscriptionHub.charge(id) و دستور charge در Anchor عمومی‌اند. هر EOA یا solverی می‌تواند آن‌ها را فراخوانی کند. زمان‌بند OrcaRail یکی از چند مشارکت‌کننده است (Chainlink، Gelato، اجراشده توسط فروشنده، اجراشده توسط solver).آنچه «همتا‌به‌همتای واقعی» اینجا نیست: ما Lightning نیستیم؛ لایه کانال مستقیم کیف پول به کیف پول نیستیم؛ اپ پرداخت را با DHT جایگزین نمی‌کنیم. OrcaRail یک پروتکل روی زنجیره با تجربه کاربری خارج از زنجیره است. ویژگی P2P از این می‌آید که هیچ واسطه‌ای نمی‌تواند در تسویه، کشف یا زنده‌بودن خودش را وارد کند؛ نه از دوری از زیرساخت روی زنجیره.
در بالاترین سطح، پروتکل پنج لایه دارد.
لایه تسویه روی EVM و سولانا برای هر لینک تغییرناپذیر است و روی بیت‌کوین برای هر لینک از توصیف‌گر مشتق می‌شود. چهار لایه دیگر قابل جایگزینی‌اند. اگر نمودار فنی کامل را می‌خواهید، به /docs/non-custodial/architecture بروید.
مرجع کامل: /docs/non-custodial/contract-reference. خلاصه:
PaymentLinkFactory (آدرس‌های قطعی با CREATE2)، PaymentLinkReceiver (کلون حداقلی EIP-1167، تغییرناپذیر برای هر لینک)، FeeSplitter (تقسیم اتمیک بر حسب واحد پایه)، SubscriptionHub (برداشت مبتنی بر allowance با lastChargedAt یکنوا).payment_link (یک PDA برای هر لینک، تقسیم با CPI) و برنامه Anchor به نام subscription (اختیار delegate در SPL، با معنای charge یکسان با هاب EVM).هر جزء طوری طراحی شده که یک linkId یا subscriptionId مشخص برای همیشه به همان آدرس قطعی روی همان زنجیره برسد؛ بدون چرخش آدرس، بدون صدور مجدد و بدون نگاشت ذخیره‌شده روی سرور.
پروتکلی که بین‌زنجیره‌ای را «بک‌اند ما Relay را صدا می‌زند» ببیند، هنوز یک محصول است. پروتکل بین‌زنجیره‌ای را intent پرداخت‌کننده می‌بیند:
امضای پرداخت‌کننده به مبلغ، گیرنده، مهلت و سقف کارمزد محدود است. در بدترین حالت، solver مخرب کند عمل می‌کند؛ نمی‌تواند وجوه را به جای دیگری بفرستد. این همان جمع‌بندی «باورمند به intent» از مناظره پروتکل است که به شکل تعهد نوشته شده است.
اجزای پایه لینک پرداخت و اشتراک OrcaRail یک زیرساخت عمومی‌اند. ارزش آن‌ها فقط وقتی چند برابر می‌شود که پردازشگرها، کیف پول‌ها و ایندکسرهای دیگر به‌طور بومی پیاده‌سازی‌شان کنند.
تعهدات:
PaymentLinkFactory و PaymentLinkReceiver به‌عنوان سطح مرجع. هم‌نویسی با دست‌کم یک تیم پردازشگر یا کیف پول دیگر تا از الگوی «EIP یک فروشنده» دوری شود.SubscriptionHub به‌عنوان مرجع. lastChargedAt یکنوا و مجموعه دلایل ChargeSkipped(reason) اهداف استانداردسازی‌اند.نوشتن EIP مزیت رقابتی ما را کم نمی‌کند. همان‌طور که در مناظره استدلال شد، مزیت رقابتی در یکپارچه‌سازی‌ها، انطباق، SLAها و اعتماد فروشندگان است و هیچ‌کدام با یک EIP کپی نمی‌شود.
حاکمیت دو افق دارد.
PaymentLinkReceiver هر لینک تغییرناپذیرند.این همان حاکمیتی است که در /docs/non-custodial/security-model شرح داده شده است.
به‌مرور، مجموعه امضاکنندگان دیگر فقط کارمندان OrcaRail نیستند و به یک شورای عمومی متشکل از یکپارچه‌کنندگان، شرکت‌های حسابرسی، گردانندگان keeper و مشارکت‌کنندگان مستقل تبدیل می‌شود. اختیار ارتقا به شورا منتقل می‌شود. در این مرحله حاکمیت روی زنجیره به گزینه‌ای واقعی تبدیل می‌شود؛ اما فقط به‌عنوان سازوکار حاکمیت، نه ابزار سفته‌بازی.
آستانه «پس از غیرمتمرکزسازی» صریح است: دست‌کم سه فرانت‌اند مستقل در محیط عملیاتی که زیرساخت را میزبانی کنند، دست‌کم سه keeper مستقل که برداشت‌ها را اجرا کنند، و دست‌کم یک پردازشگر غیر از OrcaRail که یکپارچه‌سازی منتشر کند. تا این‌ها واقعی نشوند، پروتکل غیرمتمرکز نیست؛ فارغ از اینکه چه سازوکار حاکمیتی رویش باشد.
این بخش عمداً کوتاه و عمداً دقیق است.
این رزرو در وایت‌پیپر پروتکل (همین سند) ثبت شده و جای دیگری نه. هر تغییر آینده در این موضع، تغییری در همین وایت‌پیپر است که به‌طور عمومی منتشر می‌شود، نه اعلامیه‌ای یک‌جانبه.
مدل درآمدی پروتکل همان مدل محصول است، فقط روی زنجیره کدگذاری شده است.
FeeSplitter برای هر پرداخت قرار دارد. همان سهم‌هایی که صفحه برداشت‌ها امروز توضیح می‌دهد: فروشنده، پلتفرم (سهم میزبانی OrcaRail)، معرف/همکار فروش و کارمزد پل.بیان کامل: /docs/non-custodial/security-model. رویکرد اصلی:
یک افزوده مخصوص پروتکل‌سازی: میزبان‌های مستقل فرانت‌اند باید پیش از نمایش لینک پرداخت، آدرس قراردادها را با یک رجیستری روی زنجیره (یا یک مانیفست انتشار امضاشده) بررسی کنند. فرانت‌اند کلون مخربی که پرداخت‌ها را به قراردادی شبیه به اصل بفرستد، محتمل‌ترین راه فیشینگ پس از چندمیزبانی شدن اکوسیستم است. رجیستری مرجع روی زنجیره است و جریان بررسی به‌عنوان بخشی از P2 مستند می‌شود.
استقرار پروتکل هم‌زمان در دو مسیر پیش می‌رود.
مسیر N همان نقشه راه موجود است، بدون تغییر. مسیر P تعهدات M1 تا M5 از مطلب مناظره را به شکل مرحله رسمی می‌کند. هر دو مسیر یک وضعیت نهایی را هدف گرفته‌اند: زیرساختی که اگر OrcaRail کنار برود همچنان کار کند.
مسیر P هرگز مسیر N را متوقف نمی‌کند و مسیر N هرگز مسیر P را. هر کدام می‌تواند زودتر از دیگری مرحله‌ای را منتشر کند.
پنج مرحله، که هر کدام ادامه طبیعی یکی از تعهدات M در مطلب مناظره است.
دامنه: یک subgraph مرجع (The Graph، Envio یا معادل) که همه رویدادهای Paid، SubscriptionCreated، Charged، ChargeSkipped، Canceled و Refunded از PaymentLinkReceiver و SubscriptionHub را روی همه زنجیره‌های مستقرشده ایندکس کند. طرح‌واره منتشر شود. دستورالعمل نصب روی سرور خود منتشر شود تا هر کسی بتواند همان ایندکس را اجرا کند.
چک‌لیست وضعیت
دامنه: سنجاق کردن اپ پرداخت و داشبورد فروشنده OrcaRail روی IPFS با بسته‌های انتشار مبتنی بر محتوا. بازیابی از طریق ENS (pay.orcarail.eth، app.orcarail.eth). بیلدهای تکرارپذیر تا هر خواننده‌ای بتواند تطابق بسته با کد منبع را بررسی کند. کلون مخرب باید هم آدرس قراردادها و هم رکورد ENS را جعل کند، نه فقط نام میزبان را.
چک‌لیست وضعیت
دامنه: نوشتن و ارسال یک EIP برای لینک‌های پرداخت غیرامانی و یک EIP همراه برای اشتراک مبتنی بر allowance. هم‌نویسی با دست‌کم یک تیم پردازشگر یا کیف پول دیگر. پیاده‌سازی مرجع، قراردادهای OrcaRail است. مشخصات معادل سولانا همراه با EIPها منتشر می‌شود.
چک‌لیست وضعیت
دامنه: یک سطح SDK (orcarail.pay(intent)) که intent امضاشده پرداخت‌کننده را بپذیرد و از طریق شبکه‌های solver موجود (Across، Relay، deBridge) مسیریابی کند، با یک solver پشتیبان که OrcaRail برای مسیرهای دنباله بلند اجرا می‌کند. طرح‌واره intent همگام با P3 استاندارد می‌شود.
چک‌لیست وضعیت
دامنه: یک Docker Compose (و Helm chart) که به هر کسی اجازه دهد یک پردازشگر سازگار با OrcaRail را سرتاسر از روی قراردادهای عمومی اجرا کند. شامل subgraph، keeper، ایندکسر، داشبورد اختیاری و مشخصات OpenAPI برای API پردازشگر که دیگران بتوانند با آن منطبق شوند.
چک‌لیست وضعیت
/docs/non-custodial/ (در یک تغییر آینده فقط برای مستندات اضافه می‌شود؛ خارج از دامنه این وایت‌پیپر)P6 از الگوی ارزیابی EigenLayer پیروی می‌کند. این یک تعهد نیست. یک بازبینی فصلی با محرک‌های مشخص است.
توصیه فعلی: به تعویق انداختن.
محرک‌هایی که باعث باز شدن سند طراحی برای ساخت مرحله P6 می‌شوند:
در صورت فعال شدن، ساخت ترجیحاً با OP Stack و توالی‌دهی مشترک (Espresso، Astria) و یک پل خروج معتبر به زنجیره‌های مرجعی که هم‌اکنون پشتیبانی می‌کنیم انجام می‌شود. حتی در آن صورت، مراحل N0 تا N7 و P1 تا P5 باید آن‌قدر بالغ باشند که زنجیره اختصاصی یک بهینه‌سازی باشد، نه یک وابستگی.
مقایسه قبل و بعد در سطح زیرساخت.
| بُعد | امروز | پس از مسیرهای N و P |
|---|---|---|
| امانت‌داری هنگام پرداخت | OrcaRail کلید کیف پول واریز را نگه می‌دارد | بدون امانت‌داری. پرداخت‌کننده ← قرارداد ← فروشنده با تقسیم اتمیک |
| spender اشتراک | smart account تحت کنترل OrcaRail | قرارداد عمومی SubscriptionHub؛ هر کسی می‌تواند فراخوانی کند |
| Keeper | زمان‌بند واحد NestJS | NestJS + Chainlink + Gelato + AVS اختیاری EigenLayer |
| ایندکسر | داخلی | subgraph عمومی با طرح‌واره مستند |
| اپ پرداخت / داشبورد | میزبانی‌شده توسط OrcaRail | میزبانی‌شده + نسخه‌های IPFS/ENS؛ میزبان‌های شخص ثالث خوش‌آمدند |
| جزء پایه لینک پرداخت | ساختار داخلی API | پیش‌نویس EIP با پیاده‌سازی مرجع |
| تسویه بین‌زنجیره‌ای | keeper اورکاریل Relay را صدا می‌زند | intentهای پرداخت‌کننده از طریق بازار solver + پشتیبان OrcaRail |
| حاکمیت | مولتی‌سیگ OrcaRail (بنیان‌گذاران + تیم) | شورای عمومی؛ حاکمیت روی زنجیره به‌عنوان گزینه واقعی |
| سطح مقرراتی | «OrcaRail پردازشگر است» | «OrcaRail یکی از پردازشگرهای متعدد روی یک زیرساخت است» |
| API قابل مشاهده برای فروشنده | REST + وب‌هوک | همان REST + وب‌هوک (پایدار) |
| توکن | ندارد | ندارد؛ به‌عنوان گزینه آینده رزرو شده (بخش ۹) |
سطح رو به وب۲ عمداً پایدار می‌ماند. فروشندگانی که در ۲۰۲۶ با API نوع REST یکپارچه شده‌اند، در ۲۰۲۸ دچار مشکل نمی‌شوند.
تهدیدهایی که صراحتاً در نظر داریم، همراه با راهکار کاهش آن‌ها:
charge() به‌عنوان پشتیبان.lastChargedAt یکنوا در SubscriptionHub؛ معادل سولانا در last_charged_at.نوشتن این سند همه پرسش‌هایی را که مطرح می‌کند حل نمی‌کند.
نقشه راه غیرامانی زیرساخت را از امانت‌داری جدا می‌کند. این وایت‌پیپر زیرساخت را از OrcaRail جدا می‌کند. هر دو باید منتشر شوند تا هر کدام معنا پیدا کند.
اگر در حال ساختن کیف پول، داشبورد، ایندکسر، solver، ابزار انطباق یا پردازشگر رقیب هستید، پروتکل طوری طراحی شده که مشارکت شما را بدون نیاز به اجازه بپذیرد. در نوشتن EIP مشارکت کنید. subgraph را اجرا کنید. فرانت‌اند خودتان را سنجاق کنید. keeper یا solver اجرا کنید. برای پیاده‌سازی مرجع issue ثبت کنید. هرچه بخش بیشتری از مسیر P توسط کسانی انجام شود که در OrcaRail کار نمی‌کنند، پروتکل بیشتر شایسته واژه پروتکل می‌شود.
فروشندگان وب۲ که امروز با آن‌ها کار می‌کنیم متوجه هیچ‌کدام از این‌ها نمی‌شوند؛ کلیدهای API، وب‌هوک‌ها و داشبوردهایشان همچنان کار می‌کنند. همین پایداری هدف است. ما پایه زیرساخت را تغییر می‌دهیم، نه سطحی را که فروشندگان هنگام ثبت‌نام با آن سروکار داشتند.
منابع
SubscriptionHub پشت یک proxy کوچک با timelock چهل‌وهشت ساعته قرار دارند.هیچ چیزی در محیط عملیاتی. مرحله ۰ شامل یک مشخصات مکتوب، سه پیشنهاد حسابرسی، یک مراسم کلید استقرار و چند ADR ادغام‌شده است.
امروز، SmartAccountWalletService.drainSmartAccountWallet در api/src/withdrawals/services/smart-account-wallet.service.ts انتقال‌ها را در یک UserOperation با سه گیرنده ترکیب می‌کند: فروشنده (toAddress)، کیف پول پشتیبانی (supportWalletAddress) و کیف پول کمیسیون. نسخه قراردادی دقیقاً همین را بازتاب می‌دهد:
struct Split {
address merchant; // main receiver
address platform; // support / platform fee
address referral; // commission / affiliate (optional, zero = skip)
address bridgeFee; // Relay bridge fee carrier (optional, zero = skip)
uint16 platformBps;
uint16 referralBps;
uint16 bridgeFeeBps;
}
هر کاری که keeper امروز در TypeScript انجام می‌دهد از روی این struct و مبلغ پرداخت قابل محاسبه است. هر چیزی که keeper فعلی نمی‌تواند بیان کند (مثلاً مالیات پویا یا مبالغ نگه‌داشته‌شده در سطح فروشنده) خارج از دامنه مرحله ۱ است و در صورت نیاز در مرحله‌ای بعدی اضافه می‌شود.
زنجیره راه‌اندازی مرحله ۱ Base است:
8453 → base، 84532 → baseSepolia) در api/src/payments/wallet.service.ts وجود دارد.PaymentLinkReceiver + تقسیم در اولین پرداخت، برای هر تراکنش فقط چند سنت هزینه دارد.SubscriptionHub.charge() را حمایت کنیم، راه فرار داریم.Ethereum mainnet، Arbitrum، Optimism و Polygon در مرحله ۳ اضافه می‌شوند. سولانا یک برنامه جداگانه است که در مرحله ۴ پیگیری می‌شود.
سه طرح را ارزیابی کردیم. فقط یکی برای ما کار می‌کند.
| مدل | امانت‌داری | تجربه پرداخت‌کننده | سازگاری کیف پول | نیاز به keeper | نتیجه |
|---|---|---|---|---|---|
| approve + برداشت در ERC-20 (انتخاب‌شده) | ندارد | یک approve یک‌باره | MetaMask، Phantom، Ledger، Safe؛ بومی | هر فراخواننده‌ای؛ keeper اختیاری | همین را منتشر کن |
| سپرده اسکرو | ندارد | سپرده N ماه | همه کیف پول‌ها | هر فراخواننده‌ای | تجربه بدتر؛ وجوه قفل می‌شوند |
| کیف پول هوشمند + session key | ندارد | ثبت‌نام در 4337 | فقط کیف پول‌های 4337 | امضاکننده session key | سازگاری بیش از حد محدود |
approve + برداشت تنها طرحی است که با کیف پول‌هایی که پرداخت‌کنندگان همین حالا استفاده می‌کنند (MetaMask، Phantom، کیف پول‌های سخت‌افزاری، Safeها) کار می‌کند. همچنین همان طرحی است که در برداشت خودکار منتشر کرده‌ایم و approve(spender, amount) و delegation در SPL را مستند می‌کند. مرحله ۲ سمت برداشت را با یک قرارداد هوشمند جایگزین می‌کند و سمت پرداخت‌کننده را تغییر نمی‌دهد.
استدلال کامل در چرا برداشت مبتنی بر allowance از اسکرو و session key بهتر است آمده است.
charge() استفاده می‌شود) هیچ اختیار استقرار، ارتقا یا آدرس کارمزدی ندارد.PaymentLinkReceiver هر لینک: تغییرناپذیر. بدون ارتقا. این برای پرداخت‌کنندگان امتیاز اعتمادی است؛ کدی که به آن پرداخت می‌کنند بعداً تغییر نمی‌کند.PaymentLinkFactory: proxy کوچک UUPS متعلق به مولتی‌سیگ، با timelock چهل‌وهشت ساعته روی upgradeTo. ارتقاها نمی‌توانند گیرنده‌های مستقرشده را تغییر دهند.SubscriptionHub: همان الگو. معنای charge() و cancel() بین نسخه‌ها پایدار است؛ اگر روزی تغییر ناسازگاری لازم شود، به‌جای ارتقا SubscriptionHubV2 را مستقر و مهاجرت می‌کنیم.refund(txId) روی زنجیره که امضاکننده فروشنده (از طریق کلید API او ← EOA مربوط به keeper) یا مولتی‌سیگ استقرار می‌تواند فراخوانی کند. پرداخت‌کننده نمی‌تواند خودش بازپرداخت بگیرد (مطابق محصول فعلی).سه شرکت را در فهرست کوتاه قرار می‌دهیم و یک حسابرسی اصلی + یک بازبینی رقابتی انجام می‌دهیم:
PaymentLinkFactory، PaymentLinkReceiver، FeeSplitter، SubscriptionHub. برنامه‌های Anchor در مرحله ۴ حسابرسی جداگانه دارند.drainSmartAccountWallet (بومی + ERC-20، با/بدون پشتیبانی، با/بدون کمیسیون) به‌صورت آزمون invariant در Foundry پیش از حسابرسی.مرحله ۱ این مشخصات را پیاده‌سازی می‌کند: لینک‌های پرداخت مبتنی بر قرارداد روی EVM.
مستندات مرجع: وضعیت مرحله ۰ · مدل امنیتی · معماری
]]>PaymentLinkFactory.computeAddress(linkId) یک آدرس قطعی CREATE2 برمی‌گرداند. این آدرس را پیش از استقرار هر چیزی به پرداخت‌کننده نشان می‌دهیم.PaymentLinkReceiver یک کلون حداقلی EIP-1167 است. توکن بومی یا ERC-20 می‌پذیرد، رویداد Paid منتشر می‌کند و در همان تراکنش FeeSplitter.split() را فراخوانی می‌کند.drainSmartAccountWallet، getSmartAccountClientForDepositWallet) برای لینک‌هایی که با پرچم useOnChainReceiver ساخته شده‌اند دور زده می‌شود.در سمت «بعد» هیچ جعبه‌ای که ما کنترل کنیم وجوه را نگه نمی‌دارد.
همه در یک پکیج جدید به نام contracts/evm/.
computeAddress(bytes32 linkId) view returns (address) — آدرس قطعی CREATE2 مشتق از linkId (همان UUID فعلی لینک پرداخت که به bytes32 هش شده است).deployAndPay(bytes32 linkId, Split split, address token, uint256 amount) — استقرار تنبل + پرداخت در یک تراکنش. کارخانه پیاده‌سازی PaymentLinkReceiver را کلون می‌کند، آن را با Split مقداردهی می‌کند و وجوه را ارسال می‌کند.isDeployed(bytes32 linkId) view returns (bool) — تابع کمکی که ایندکسر و رابط کاربری از آن استفاده می‌کنند.upgradeTo.Split و آدرس FeeSplitter را ذخیره می‌کند.pay(address token, uint256 amount) — توکن بومی و ERC-20 را در یک نقطه ورود مدیریت می‌کند. از SafeERC20 استفاده می‌کند تا توکن‌های غیراستاندارد (USDT) هم کار کنند. رویداد Paid(linkId, payer, token, amount) را منتشر می‌کند.FeeSplitter.split() را به‌صورت اتمیک فراخوانی می‌کند. اگر تقسیم revert شود، پرداخت هم revert می‌شود.refund(bytes32 txId) که فقط EOA مربوط به keeper فروشنده یا مولتی‌سیگ استقرار می‌تواند فراخوانی کند.split(Split s, address token, uint256 amount) — بر اساس واحد پایه توزیع می‌کند. wei باقی‌مانده به فروشنده می‌رسد (بدون هدر رفتن خرده‌ها).Split(txId, merchant, platform, referral, bridgeFee) را منتشر می‌کند تا ایندکسر با payloadهای وب‌هوک قدیمی هم‌خوان بماند.بزرگ‌ترین تغییر کد در api/src/payments/wallet.service.ts است. امروز getOrCreateAddressForPaymentLink از hd_wallet_seed مشتق‌گیری می‌کند، آدرس counterfactual آلکمی را محاسبه می‌کند و در wallet_address ذخیره می‌کند. پس از مرحله ۱، برای زنجیره‌های EVM که پرچم فعال دارند، این تابع چنین می‌شود:
async function getOrCreateAddressForPaymentLink(paymentLinkId, network) {
if (isEvm(network) && featureFlags.useOnChainReceiver(network.chainId)) {
const address = await factory.computeAddress(hashLinkId(paymentLinkId))
return { address, walletAddressId: null, derivationPath: null }
}
// legacy path unchanged
}
بدون مشتق‌گیری HD. بدون هیچ داده خصوصی در پایگاه داده برای لینک‌های جدید.
یک سرویس جدید به نام payments/indexer/evm-paid-event.service.ts با viem.watchContractEvent روی هر زنجیره فعال مشترک رویدادهای Paid می‌شود. هنگام تطابق:
paymentLinkId را از رویداد (ایندکس‌شده به‌صورت bytes32) پیدا می‌کند.PaymentTransaction درج یا به‌روزرسانی می‌کند؛ با همان ساختار امروز.پرچم useOnChainReceiver برای هر chain id جداگانه تعریف می‌شود. لینکی که در زمان خاموش بودن پرچم ساخته شود، برای همیشه روی مسیر جاروب قدیمی می‌ماند؛ لینک‌های در جریان را مهاجرت نمی‌دهیم.
در این مرحله این موارد را دور می‌زنیم اما حذف نمی‌کنیم:
SmartAccountWalletService.drainSmartAccountWallet — برای زنجیره‌هایی که پرچم فعال دارند دیگر فراخوانی نمی‌شود.SmartAccountWalletService.getSmartAccountClientForDepositWallet — وقتی آدرس‌ها از کارخانه می‌آیند لازم نیست.wallet_address — برای زنجیره‌های EVM با پرچم فعال نوشته نمی‌شوند.حذف واقعی در مرحله ۷ انجام می‌شود؛ پس از تسویه همه لینک‌های قدیمی روی آن زنجیره.
maxLinkValue در کارخانه برای ۳۰ روز اول.SafeERC20 در هر دو قرارداد PaymentLinkReceiver و FeeSplitter؛ آزمون‌های fuzz در Foundry روی فورک mainnet با USDT.contracts/evm/PaymentLinkFactory + PaymentLinkReceiver + FeeSplitteruseOnChainReceiver در api/src/paymentsevm-paid-event.service.ts و ارسال وب‌هوک‌های موجودبا رفتن فروشندگان Base به گیرنده‌های قراردادی، مرحله ۲ همین کار را برای اشتراک‌ها انجام می‌دهد: اشتراک مبتنی بر allowance.
مستندات مرجع: وضعیت مرحله ۱ · مرجع قراردادها · معماری
]]>SubscriptionHub روی زنجیره منتقل می‌کند. پرداخت‌کننده یک approve در کیف پولش امضا می‌کند و وقتی دوره‌ای سررسید شود، هر کسی (از جمله keeper ما) می‌تواند charge(id) را فراخوانی کند. وجوه مستقیماً از پرداخت‌کننده به سهم‌های فروشنده می‌رود؛ OrcaRail هرگز آن‌ها را نگه نمی‌دارد.
SubscriptionHub.createSubscription(...) زمان‌بندی را روی زنجیره ثبت می‌کند.approve(USDC, hub, cap) را امضا می‌کند. این همان گامی است که پیش‌تر در برداشت خودکار مستند کرده‌ایم.charge(id) را فراخوانی کند. زمان‌بند NestJS ما به‌طور پیش‌فرض این کار را می‌کند؛ از مرحله ۳ به بعد Chainlink/Gelato پشتیبان آن خواهند بود.lastChargedAt یکنوا. بدون برداشت دوباره.امروز api/src/scheduler/processors/subscription-auto-charge.processor.ts از یک smart account تحت کنترل OrcaRail استفاده می‌کند تا از طریق approve موجود از پرداخت‌کننده برداشت کند. کار می‌کند، اما smart account متعلق به ماست؛ اعتماد از مسیر ما عبور می‌کند.
پس از مرحله ۲:
allowance همچنان از پرداخت‌کننده به یک قرارداد داده می‌شود، اما قرارداد قابل حسابرسی و تغییرناپذیر است و هر کسی (نه فقط ما) می‌تواند keeper باشد.
یک نمونه برای هر زنجیره. سطح حداقلی:
function createSubscription(
bytes32 id,
address payer,
IERC20 token,
uint256 amount,
uint64 interval,
uint256 cap,
Split calldata split
) external;
function charge(bytes32 id) external; // any caller
function cancel(bytes32 id) external; // payer only
function subscription(bytes32 id) view returns (Subscription memory);
event SubscriptionCreated(bytes32 indexed id, address indexed payer, ...);
event Charged(bytes32 indexed id, uint256 amount, uint64 nextChargeAt);
event ChargeSkipped(bytes32 indexed id, bytes32 reason);
event Canceled(bytes32 indexed id);
charge() اعمال می‌کندblock.timestamp >= nextChargeAt — برداشت زودهنگام ممکن نیست.block.timestamp > lastChargedAt — یکنوا، تا reorgها نتوانند دوبار برداشت کنند.amountCharged + amount <= cap — سقف تأیید را علاوه بر allowance در ERC-20 اعمال می‌کند.token.allowance(payer, hub) >= amount — revert صریح با InsufficientAllowance برای متن وب‌هوک روشن.token.balanceOf(payer) >= amount — همین‌طور، با InsufficientBalance.Split از مرحله ۱ دوباره استفاده می‌شود؛ همان FeeSplitter و همان منطق واحد پایه.
تغییر بزرگ این است که api/src/scheduler/processors/subscription-auto-charge.processor.ts دیگر از smart account ما برداشت نمی‌کند و به‌جای آن با یک EOA مربوط به keeper تابع SubscriptionHub.charge(id) را فراخوانی می‌کند.
به‌طور مشخص:
past_due، insufficient_balance و غیره) به‌روزرسانی می‌کند.api/src/mail/mail-templates/subscription-*.hbs بدون تغییر ارسال می‌شوند.تجربه پرداخت‌کننده در pay دو تنظیم جزئی دارد:
approve() اکنون spender را به‌جای کیف پول داغ ما به آدرس SubscriptionHub نشانه می‌رود. این یک تغییر متن و یک مقدار پیکربندی است؛ جریانی که پرداخت‌کننده می‌بیند یکسان است.SubscriptionHub.cancel(id) را فراخوانی می‌کند و سپس برای پاک‌سازی کامل یک approve(hub, 0) روی زنجیره درخواست می‌کند. مستندات فعلی لغو برداشت خودکار همچنان دقیق است.subscription-auto-charge.processor.ts — با پرچم فعال، فقط شاخه SubscriptionHub.charge اجرا می‌شود.approval_spender_address — اشتراک‌های جدید به‌جای آن آدرس هاب را ذخیره می‌کنند.approval_spender_address در پاسخ API باقی می‌ماند؛ فقط به جای جدید و قابل حسابرسی اشاره می‌کند.مشترکان فعلی هرگز به‌اجبار مهاجرت داده نمی‌شوند. دو مسیر پیشنهاد می‌کنیم:
approve(hub, cap) را روی SubscriptionHub جدید دوباره امضا کند. یک کلیک. allowance قبلی به کیف پول داغ قدیمی را می‌توان نگه داشت یا لغو کرد؛ دیگر اهمیتی ندارد.اشتراک‌هایی که هرگز مهاجرت نکنند تا زمان لغو روی مسیر امانی می‌مانند. این مسیر در مرحله ۷ با اطلاع‌رسانی کافی خاموش می‌شود.
subscription-auto-charge-approved.hbs موجود پیروی می‌کند؛ بنر در داشبورد؛ پرسش متداول در /docs/non-custodial/migration-guide.charge() بدون مجوز است؛ هر نمونه Chainlink Automation یا Gelato می‌تواند پشتیبان باشد؛ فراخوانی دستی charge() توسط فروشنده هم ممکن است. برنامه کامل در مرحله ۳.lastChargedAt؛ آزمون واحد با reorg روی فورک.charge() رویداد ChargeSkipped(AllowanceRevoked) را منتشر می‌کند؛ قالب ایمیل موجود subscription-insufficient-allowance.hbs ارسال می‌شود؛ اشتراک به past_due می‌رود.SubscriptionHub.isAllowed(token) برایشان برقرار است؛ تغییرات نیازمند مولتی‌سیگ است.SubscriptionHub با همه اصول ثابتSubscriptionHubapprove در اپ پرداخت به SubscriptionHubapprove-auto-charge برای پذیرش allowance با هاب به‌عنوان spenderگسترش به چند زنجیره و keeper دوم: مرحله ۳.
مستندات مرجع: وضعیت مرحله ۲ · راهنمای مهاجرت · مرجع قراردادها · چرا برداشت مبتنی بر allowance
]]>PaymentLinkFactory، پیاده‌سازی PaymentLinkReceiver، FeeSplitter و SubscriptionHub روی Ethereum mainnet، Arbitrum، Optimism و Polygon.computeAddress در سمت کلاینت).charge(ids[]) را فراخوانی می‌کند.چند keeper که همان charge() عمومی را فراخوانی می‌کنند، تضمین زنده‌بودن است. هیچ‌کدام امانت‌دار نیستند؛ هر کدام می‌تواند برداشت سررسیدشده را نجات دهد.
ترتیب استقرار (هر هفته یک زنجیره، با canary برای هر زنجیره):
1)42161)10)137)آدرس‌ها روی هر زنجیره در /docs/non-custodial/contract-reference منتشر می‌شوند. کلید استقرار همان مولتی‌سیگ Safe سه از پنج تعریف‌شده در مرحله ۰ است که از همان مراسم برای هر زنجیره دوباره مستقر می‌شود.
هر چهار زنجیره از همان پرچم useOnChainReceiver استفاده می‌کنند که بر اساس chainId در api/src/payments/wallet.service.ts تعریف شده است. فروشندگان زنجیره به زنجیره آن را فعال می‌کنند؛ پس از یک هفته canary بدون مشکل، مقدار پیش‌فرض روشن می‌شود.
charge()تراکنش‌های charge() مربوط به keeper به گس نیاز دارند. از زیرساخت paymaster موجود در api/src/withdrawals/services/gas-strategy دوباره استفاده می‌کنیم:
SubscriptionHub.charge() را به‌صورت UserOperation با حمایت سیاست فراخوانی می‌کند. هزینه گس برای EOA مربوط به keeper صفر است.gas_refund_address تنظیم کنند و keeper بازپرداخت را از آنجا برداشت کند؛ مطابق الگوی فعلی پشتیبانی/کمیسیون. خارج از دامنه راه‌اندازی اولیه.keeper دوم برای افزونگی است، نه جایگزینی. در کنار زمان‌بند NestJS کار می‌کند.
SubscriptionHub.checkUpkeep() برای همه idهایی که block.timestamp >= nextChargeAt دارند (خوانده‌شده از یک تابع view)، مقدار performData = abi.encode(ids[]) را برمی‌گرداند.performUpkeep(performData) تابع charge(ids) را به‌صورت دسته‌ای فراخوانی می‌کند.charge(ids[]) ارسال می‌کند.1Balance در Gelato پرداخت می‌شود.هر کدام به‌تنهایی کافی است؛ بر اساس تجربه عملیاتی در مرحله ۳ انتخاب می‌کنیم. اجرای هر دو هم مشکلی ندارد؛ به لطف lastChargedAt، تابع charge() در هر دوره idempotent است.
اهداف SLO منتشرشده:
| معیار | هدف |
|---|---|
charge() ظرف ۱۰ دقیقه از nextChargeAt | ۹۹٫۵٪ |
charge() ظرف ۱ ساعت از nextChargeAt | ۹۹٫۹٪ |
| موجودی گس داغ EOA مربوط به keeper بالاتر از آستانه هشدار | ۹۹٫۹۹٪ |
| ایندکس شدن رویدادها ظرف ۲ دقیقه از قطعیت بلاک | ۹۹٫۵٪ |
پایش به تنظیمات موجود Sentry که در مهارت گردش کار Sentry مخزن مستند شده وصل می‌شود. هشدارها:
charge() در هر ساعت > آستانه ← PagerDutyPaid بیش از ۵ دقیقه ← هشدارمانند مراحل ۱ و ۲، اما روی زنجیره‌های بیشتر. هنوز چیزی حذف نمی‌شود؛ حذف منتظر مرحله ۷ می‌ماند.
SubscriptionHub استفاده می‌کنند.0x4e59b44847b379578588920cA78FbF26c0B4956C) با هش init-code ثابت؛ کارخانه‌ها روی هر چهار زنجیره آدرس یکسان دارند.lastChargedAt یکنوا به‌علاوه ChargeSkipped برای موارد تکراری؛ هر دو keeper ذاتاً idempotent هستند.charge() یک بلاک عقب می‌افتد.charge() از CLI فروشنده)سولانا زنجیره بزرگ دیگری است که باید غیرامانی شود: مرحله ۴.
مستندات مرجع: وضعیت مرحله ۳ · راهبرد keeper · مرجع قراردادها
]]>payment_link برای پرداخت‌های یک‌باره و subscription برای برداشت خودکار با delegate در SPL. برای لینک‌های جدید سولانا هیچ عبارت بازیابی (mnemonic) روی سرورهای ما نیست.
payment_link برای هر لینک پرداخت مالک یک PDA است که از seeds = [b"pl", link_id] مشتق می‌شود. بدون keypair، بدون seed، بدون جاروب.subscription از اختیار delegate در SPL استفاده می‌کند؛ همان جزء پایه‌ای که در برداشت خودکار به آن تکیه داریم؛ به‌عنوان allowance صریحی که پرداخت‌کننده اعطا می‌کند.fee_splitter که روی EVM ساختیم و برای حساب‌های سولانا تطبیق داده‌ایم انجام می‌شوند.سمت «بعد» seed مربوط به HD در api/src/payments/wallet.service.ts (شاخه m/44'/501'/i'/0') را با محاسبه کاملاً قطعی PDA جایگزین می‌کند.
پکیج جدید contracts/solana/ (Anchor).
payment_linkحساب‌ها برای هر لینک:
#[account]
pub struct PaymentLink {
pub link_id: [u8; 32],
pub expected_mint: Pubkey, // e.g. USDC on SOL
pub expected_amount: u64,
pub split: Split,
pub created_at: i64,
pub status: PaymentStatus,
}
دستورها:
initialize(link_id, expected_mint, expected_amount, split) — تنبل؛ هنگام اولین واریز توسط پوشش‌دهنده شبیه کارخانه فراخوانی می‌شود.pay(link_id, amount) — mint و مبلغ را اعتبارسنجی می‌کند، با CPI به ATA مربوط به PDA منتقل می‌کند و سپس با CPI به‌صورت اتمیک تقسیم می‌کند. رویداد PaymentReceived { link_id, payer, amount } را منتشر می‌کند.refund(link_id) — نیازمند مولتی‌سیگ، مشابه بازپرداخت در EVM.seedهای PDA: [b"pl", link_id]. PDA کلید خصوصی ندارد؛ از طریق invoke_signed امضا می‌کند.
subscriptionاز Approve / Revoke در SPL برای واگذاری اختیار استفاده می‌کند. پرداخت‌کننده spl_token::approve را امضا می‌کند و PDA برنامه را تا سقف cap توکن به‌عنوان delegate تعیین می‌کند. سپس:
pub fn charge(ctx: Context<Charge>, id: [u8; 32]) -> Result<()>
هر کسی می‌تواند فراخوانی‌اش کند؛ این موارد را بررسی می‌کند:
clock.unix_timestamp >= next_charge_atclock.unix_timestamp > last_charged_at // monotonicamount_charged + period_amount <= capدر صورت قبولی، spl_token::transfer_checked با CPI از ATA پرداخت‌کننده (به‌عنوان delegate) برداشت می‌کند و با CPI تقسیم می‌کند.
رویدادها: SubscriptionCreated، Charged، ChargeSkipped، Canceled. همان ساختاری که ایندکسر EVM تولید می‌کند، پس api/src/webhooks به زنجیره وابسته نیست.
WalletService.generateAddressForNetwork دیگر keypair مشتق نمی‌کند و به‌جای آن findProgramAddressSync(["pl", linkId], programId) را برمی‌گرداند. برای لینک‌های جدید سولانا هیچ ردیف encryptedSeed نوشته نمی‌شود.charge می‌سازد و با keeper امضا می‌کند (مسیر بدون گس از طریق تراکنش حمایت‌شده، مشابه paymaster مرحله ۲).withdrawals/services/solana-withdrawal-transfer.service.ts برای لینک‌های دارای پرچم فراخوانی نمی‌شود.کارمزدهای سولانا ناچیزند (معمولاً ۵۰۰۰ lamport برای هر امضا، یعنی ۰٫۰۰۰۰۰۵ SOL). keeper از موجودی SOL داغ با همان الگوی هشدار مرحله ۳ استفاده می‌کند. چون سولانا paymaster شبیه آلکمی ندارد، تراکنش‌های حمایت‌شده از الگوی ساده هم‌امضاکننده استفاده می‌کنند: keeper به‌عنوان پرداخت‌کننده کارمزد امضا می‌کند و پرداخت‌کننده اصلاً به SOL نیاز ندارد.
m/44'/501'/i'/0') برای لینک‌های جدید — با روشن بودن پرچم فراخوانی نمی‌شود.solana-withdrawal-transfer.service.ts — برای لینک‌های دارای پرچم دور زده می‌شود.SolanaRelayBridgeExecutorService در api/src/withdrawals/services/bridge/solana-relay-bridge-executor.service.ts باقی می‌ماند: وقتی فروشنده روی EVM است، پل از SOL به EVM همچنان از Relay استفاده می‌کند، اما محرک آن به برنامه منتقل می‌شود.همان مدل اختیاری مرحله ۲:
charge پیش از انتقال delegated_amount را دوباره بررسی می‌کند؛ در صورت شکست، ChargeSkipped(DelegateRevoked) منتشر می‌شود و همان قالب ایمیلِ حالت لغو allowance در EVM استفاده می‌شود.payment_link از هر دو پشتیبانی می‌کند و برای جلوگیری از ابهام، expected_mint صریح برای هر لینک دارد.contracts/solana/payment_link با همه دستورها + آزمون‌هاsubscription با همه دستورها + آزمون‌هاsubscription-auto-charge.processor.tsبیت‌کوین. سخت‌ترین زنجیره برای غیرامانی شدن، و جایی که باید درباره محدودیت‌ها صادق باشیم: مرحله ۵.
مستندات مرجع: وضعیت مرحله ۴ · مرجع قراردادها · معماری
]]>امروز BitcoinHotWalletService در api/src/withdrawals/services/bitcoin-hot-wallet.service.ts یک آدرس p2wpkh یک‌جانبه از عبارت بازیابی نگهداری‌شده روی سرور مشتق می‌کند و از طریق bitcoin-withdrawal-transfer.service.ts جاروبش می‌کند. این یک کلید واحد است که ما کنترلش می‌کنیم.
پس از مرحله ۵:
هیچ طرفی به‌تنهایی نمی‌تواند خرج کند. هیچ سروری seed یک‌جانبه نگه نمی‌دارد.
wsh(multi(2, merchant_pubkey, platform_pubkey)) یا معادل taproot آن (tr(NUMS, {pk(m), pk(p)}) با MuSig2 برای خروجی‌ای که شبیه تک‌امضا به نظر می‌رسد؛ خوب برای حریم خصوصی و کارمزد).وقتی واریزی شناسایی می‌شود:
sendback اعمال می‌شود).این معادل BTC برای تابع refund() روی زنجیره است.
پرداخت‌های دوره‌ای BTC یک گزینه واقع‌بینانه دارند: پیشنهادهای BOLT12 در Lightning + افزونه recurrence. این به ما راهکاری برای اشتراک BTC می‌دهد که با approve + برداشت در ERC-20 قابل مقایسه است. آن را به‌عنوان مرحله‌ای آینده پیگیری می‌کنیم:
وقتی ابزارهای پایه آماده شوند، یک سند طراحی اختصاصی منتشر می‌کنیم. تا آن زمان، BTC فقط پرداخت یک‌باره دارد.
BitcoinHotWalletService — رابطش را حفظ می‌کند، اما تأمین‌کننده کلید به HSM/MPC منتقل می‌شود. آدرس واریز p2wpkh یک‌جانبه دیگر برای لینک‌های جدید ساخته نمی‌شود.wsh(multi(...)) منتشر می‌شود؛ MuSig2 بعداً و پس از حسابرسی گسترده ابزارها می‌آید.غیرمتمرکزسازی اختیاری keeper از طریق EigenLayer: مرحله ۶.
مستندات مرجع: وضعیت مرحله ۵ · ملاحظات بیت‌کوین · مدل امنیتی
]]>charge() غیرمتمرکز و یک AVS برای گواهی پل برای تسویه بین‌زنجیره‌ای.یک AVS (Actively Validated Service) شبکه‌ای از اپراتورهاست که محاسبه‌ای خارج از زنجیره اجرا می‌کنند و گواهی‌های آن با امنیت رمزاقتصادی ETH ری‌استیک‌شده روی زنجیره منتشر می‌شود. رفتار نادرست جریمه (slash) می‌شود.
آنچه به دست می‌آورید:
آنچه به دست نمی‌آورید:
charge() غیرمتمرکز)امروز و تا مرحله ۳، وضعیت keeperها این است:
این به ما افزونگی دوگانه می‌دهد. یک AVS برای keeper افزونگی Nگانه با زنده‌بودن قابل جریمه می‌دهد: اپراتورها گواهی می‌دهند «این IDها سررسید بودند و من charge را فراخوانی کردم»، و جا انداختن برداشت سررسیدشده تخلفی قابل جریمه است.
کی ارزشش را دارد:
کی ارزشش را ندارد:
تسویه بین‌زنجیره‌ای ما امروز از Relay استفاده می‌کند (api/src/withdrawals/services/bridge را ببینید). Relay نیازمند اعتماد است. یک AVS می‌تواند با امنیت قابل جریمه گواهی دهد که «وجوه روی زنجیره X مشاهده شد، روی زنجیره Y آزاد کن»؛ ساختاری شبیه Hyperlane ISM با EigenLayer یا Omni.
کی ارزشش را دارد:
«آیا این کیف پول تحریم است؟» «آیا کالا تحویل داده شد؟» — بررسی‌های سیاستی که امروز در مسیر وب‌هوک NestJS قرار دارند می‌توانند به گواهی‌های AVS تبدیل شوند. کاربرد خاص؛ فقط وقتی مفید است که پلتفرم مسئولیت صریح سیاست‌گذاری روی زنجیره را بپذیرد.
یک گزارش عمومی تصمیم‌ها در /docs/non-custodial/eigenlayer-evaluation نگه می‌داریم که توصیه فعلی و محرک‌هایی را که می‌توانند آن را تغییر دهند نشان می‌دهد. توصیه امروز: به تعویق انداختن.
محرک‌هایی که بحث را دوباره باز می‌کنند:
SubscriptionHub.charge(ids[]) عمومی و بدون نیاز به مجوز می‌ماند. AVS فقط یک فراخواننده دیگر در کنار NestJS و Chainlink می‌شود.مرحله پایانی مسیرهای کد امانی را که مراحل ۱ تا ۵ جایگزینشان کردند حذف می‌کند: مرحله ۷.
مستندات مرجع: وضعیت مرحله ۶ · ارزیابی EigenLayer · راهبرد keeper
]]>SubscriptionHub است، بیت‌کوین روی مولتی‌سیگ دو از دو است و هیچ لینک پرداخت جدیدی از مسیر جاروب قدیمی عبور نمی‌کند. این مرحله کد قدیمی و رازهای قدیمی را حذف می‌کند.
hd_wallet_seed، پیکربندی WALLET_ENCRYPTION_KEY و منطق مشتق‌گیری برای زنجیره‌های دارای پرچم.api/src/withdrawals/: SmartAccountWalletService.drainSmartAccountWallet، solana-withdrawal-transfer.service.ts و فایل‌های spec مرتبط.پیش از این مرحله، کد از هر چیزی دو نسخه دارد (مسیر جاروب قدیمی و مسیر قراردادی جدید) که پشت feature flag قرار دارند. پس از این مرحله، مسیر جدید تنها مسیر روی EVM و سولاناست.
hd_wallet_seed و موجودیت TypeORM آن در api/src/payments/infrastructure/persistence/relational/entities/hd-wallet-seed.entity.ts.wallet_address.derivationPath برای جست‌وجوهای تاریخی حفظ می‌شود اما nullable می‌شود؛ هیچ ردیف جدیدی برای EVM/SOL آن را نمی‌نویسد.در api/src/payments/wallet.service.ts:
encryptSeed، decryptSeed، getOrCreateHDWallet، generateAddressForNetwork (شاخه‌های EVM + SOL)، getNextAvailableIndex و import پویای @account-kit/wallet-client.getOrCreateAddressForPaymentLink به پوشش نازکی روی factory.computeAddress برای EVM و findProgramAddressSync برای سولانا تبدیل می‌شود.در api/src/withdrawals/services/smart-account-wallet.service.ts:
drainSmartAccountWallet، transferFromSmartAccount، batchTransferFromSmartAccount، getSmartAccountClientForDepositWallet و derivePrivateKey.حذف‌های دیگر:
.spec.ts و fixtureهای مربوط.subscription-auto-charge.processor.ts (شاخه SubscriptionHub.charge باقی می‌ماند).WALLET_ENCRYPTION_KEY — از .env، رازهای استقرار و مستندات حذف می‌شود.@account-kit/* اگر هنوز برای paymaster استفاده شوند باقی می‌مانند).charge() استفاده می‌کند.یک مطلب همراه آموخته‌های مراحل ۰ تا ۷ را خلاصه می‌کند: چه چیزی بیش از انتظار طول کشید، چه چیزی روان‌تر پیش رفت، هزینه واقعی مهندسی غیرامانی شدن چه بود و فروشندگان چه واکنشی نشان دادند. زمان‌بندی مورد انتظار: یک مطلب ظرف ۳۰ روز پس از انتشار مرحله ۷.
این مرحله خودش همان منسوخ‌سازی است. همه مسیرهای دارای پرچم useOnChainReceiver به‌طور پیش‌فرض فعال می‌شوند و پرچم حذف می‌شود.
تا زمان اجرای مرحله ۷، همه پرداخت‌ها و اشتراک‌های جدید بیش از ۱۲ ماه است که غیرامانی بوده‌اند. مهاجرت درباره دنباله بلند لینک‌های قدیمی است:
hd_wallet_seed به بایگانی سردپس از مرحله ۷، وضعیت امانت‌داری این است:
این همان هدفی است که در نقشه راه غیرامانی دنبال می‌کردیم.
مستندات مرجع: وضعیت مرحله ۷ · مدل امنیتی · نقشه راه
]]>چند نفر از خوانندگان به‌درستی پرسیدند: اگر هدف تبدیل شدن به یک پروتکل است، چرا فقط به حذف امانت‌داری بسنده کنیم؟ اگر OrcaRail فردا خاموش شود و پرداخت‌ها همچنان جریان داشته باشند، زیرساخت چه شکلی خواهد داشت؟
این مطلب یک مناظره است. پنج موضع از پنج معماری متفاوت دفاع می‌کنند. یک گرداننده هر کدام را به چالش می‌کشد. هیچ‌کس به‌طور کامل برنده نمی‌شود، اما در پایان روشن‌تر می‌دانیم واقعاً چه بده‌بستان‌هایی را انتخاب می‌کنیم.
پیش از شروع مناظره به یک تعریف مشترک نیاز داریم. یک سیستم وقتی پروتکل کاملاً غیرامانی است که همه این شرایط برقرار باشند:
برنامه فعلی شرط (۱) را برآورده می‌کند. شرط‌های (۳)، (۴) و (۵) را تا حدی برآورده می‌کند. شرط (۲) را برآورده نمی‌کند؛ keeper و API اورکاریل هنوز برای اجرای قابل‌اعتماد مسیر عادی لازم‌اند. مناظره زیر درباره این است که آیا چهار معیار باقی‌مانده را تا انتها پیش ببریم و با چه هزینه‌ای.
پنج معمار وارد می‌شوند. بیایید حرفشان را بشنویم.
نقشه راه همین حالا مسئله سخت (امانت‌داری) را حذف می‌کند. keeper می‌تواند هر کسی باشد؛ زمان‌بند NestJS ما یکی از چند فراخواننده است و Chainlink و Gelato را می‌توان فردا ثبت کرد. ایندکسر عمومی است: هر کسی می‌تواند مشترک همان رویدادهای Paid و Charged شود و وضعیت را بازسازی کند. «API اورکاریل» لایه تسویه نیست؛ یک لایه راحتی روی قراردادهای عمومی است. فروشندگانی که مسیر کاملاً پروتکلی را می‌خواهند، همین حالا هم می‌توانند ما را دور بزنند و مستقیم کارخانه را فراخوانی کنند.
ادعا: ما ۸۰٪ پروتکل هستیم. ۲۰٪ باقی‌مانده ابزار است (کیف پول، داشبورد، ایمیل)، نه اعتماد. ابزارها باید قابل تکرار و بهبود بمانند.
Uniswap وجود دارد. 1inch وجود دارد. از طریق فرانت‌اندهایی که شرکت‌هایشان میزبانی می‌کنند به آن‌ها دسترسی دارید، اما هر کدام از این فرانت‌اندها می‌تواند خاموش شود و پروتکل همچنان کار کند. «پروتکل» یعنی همین.
برای OrcaRail، این یعنی:
orcarail.eth) بازیابی می‌شود. داشبورد فروشنده و اپ پرداخت بسته‌های ایستا هستند؛ هر انتشار مبتنی بر محتوا آدرس‌دهی می‌شود.ادعا: هر چیزی که برای کار کردن پرداخت به api.orcarail.com نیاز داشته باشد، پروتکلی ناقص است.
پرداخت‌ها به تأخیر حساس و تکراری‌اند. هر بار برای همان تقسیم همان گس را می‌پردازیم. چرا امنیت L1/L2 را برای کاربردی اجاره کنیم که می‌شود تخصصی‌اش کرد؟
زنجیره OrcaRail را به‌صورت یک رول‌آپ OP Stack (یا appchain کازماس، یا زنجیره Arbitrum Orbit) راه بیندازیم. آن‌وقت:
charge() را به‌عنوان بخشی از بلاک اجرا می‌کند و با امنیت خود زنجیره قابل جریمه است.ادعا: ارزان‌ترین راه برای اینکه یک پروتکل در مقیاس بالا قابل‌اعتماد کار کند، این است که فضای بلاک را با mintهای تصادفی NFT شریک نشود.
پرداخت‌کننده می‌گوید: «می‌خواهم ۵۰ دلار USDC از هر کدام از کیف پول‌هایم، ظرف ساعت آینده و با کمترین کارمزد، به فروشنده X بپردازم.» این یک intent است؛ امضاشده اما هنوز تراکنش نیست.
یک شبکه solver بدون نیاز به مجوز (به سبک CoW، SUAVE، Anoma، relayerهای شبیه Across) intent را می‌بیند، ارزان‌ترین مسیر را پیدا می‌کند (شامل پل‌زدن و بین‌زنجیره‌ای، از هر توکنی که پرداخت‌کننده دارد) و آن را تسویه می‌کند. به solverها پاداشی پرداخت می‌شود که در intent گنجانده شده است.
برای اشتراک‌ها: پرداخت‌کننده یک intent دوره‌ای امضا می‌کند («ماهانه ۲۰ دلار USDC از کیف پولم به PDA این فروشنده برداشت کن، به مدت ۱۲ ماه، قابل لغو در هر زمان»). solverها رقابت می‌کنند تا هنگام سررسید charge() را فراخوانی کنند و کارمزد کوچکی بگیرند. اگر کمی دقیق شوید، «AVS برای keeper» در مرحله ۶ به همین تبدیل می‌شود؛ اما با یک بازار واقعی به‌جای طرح جریمه.
ادعا: keeperها واقعاً مسئله قابلیت اطمینان نیستند؛ مسئله طراحی بازارند. بازار را بسازیم.
لینک‌های پرداخت و اشتراک‌های OrcaRail یک جزء پایه عمومی‌اند. Shopify، Coinbase Commerce، دیگر پشته‌های پرداخت کریپتوی میزبانی‌شده و دو دوجین استارتاپ همین را می‌سازند. باید یک EIP برای لینک‌های پرداخت غیرامانی و یک EIP همراه برای اشتراک مبتنی بر allowance با پیاده‌سازی مرجع بنویسیم.
آن‌وقت:
ادعا: بزرگ‌ترین مزیت رقابتی در پرداخت، اعتماد به جزء پایه است، نه به پشته یک شرکت. جزء پایه را عمومی کنیم.
عمل‌گرا: در نقشه راه فعلی، پس از مرحله ۳، بله؛ Chainlink Automation همچنان charge() را اجرا می‌کند. قبض paymaster برای گس keeper است و Chainlink برای همان کار از LINK استفاده می‌کند. اما فروشندگانی که برای تطبیق حساب به داشبورد OrcaRail نیاز دارند آسیب می‌بینند: ایمیل‌ها، تلاش‌های مجدد و کدهای خطای خوانا همه در API ما هستند. قراردادها کار می‌کنند؛ محصول نه.
گرداننده: آیا «قراردادها کار می‌کنند اما آدم‌ها متوجه نمی‌شوند» واقعاً زنده‌بودن است؟
عمل‌گرا: زنده‌بودن تسویه است بدون زنده‌بودن تجربه کاربری. این تمایز واقعی است و باید آن را بپذیریم، نه پنهانش کنیم. رفع آن هم به‌مرور ارزان است: قالب‌های ایمیلمان را منتشر کنیم، ایندکسر را متن‌باز کنیم، بگذاریم کس دیگری داشبورد را میزبانی کند. لازم نیست همه این‌ها را در مرحله ۱ انجام دهیم.
حداکثرگرا: آن‌وقت OrcaRail میزبانی آن فروشنده را در داشبورد خودش متوقف می‌کند. پروتکل از طریق فرانت‌اند دیگری، یا فرانت‌اند خود فروشنده، همچنان به او خدمت می‌دهد. این ویژگی است، نه باگ؛ مقایسه کنید با مالی سنتی که «پردازشگر حسابم را مسدود کرد» درامی تکراری است و هیچ راه‌حلی در سطح پروتکل ندارد.
گرداننده: فروشندگانی که پردازشگر کارت اخراجشان می‌کند معمولاً از شبکه Visa هم اخراج می‌شوند. در پرداخت، زیرساخت و پردازشگر اغلب همان سانسورگرند.
حداکثرگرا: درست است، و این دقیقاً مسئله‌ای است که پروتکل حل می‌کند. Visa نمی‌تواند اتریوم را سانسور کند. OrcaRail با معماری پروتکلی نمی‌تواند فروشندگان را در سطح زیرساخت سانسور کند؛ فقط در سطح فرانت‌اند. فرانت‌اندها قابل جایگزینی‌اند؛ زیرساخت نه.
مستقل: همان‌طور که هر کسی از هر L2 خارج می‌شود: با پل مرجع. Relay را به‌صورت بومی یکپارچه می‌کنیم تا خروج استیبل‌کوین‌ها فوری باشد. حجم روزانه برداشت در مقایسه با حجم درون زنجیره ناچیز است.
گرداننده: از ما می‌خواهی یک زنجیره اداره کنیم. هر زنجیره مهمی حالت‌های خرابی دارد: توقف sequencer، تأخیر در انتشار state root، خروج از پل. این خرابی‌ها عمومی و آشکارند. «sequencer اورکاریل ۳ ساعت از کار افتاد، پرداخت‌ها در سراسر جهان متوقف شد» تیتر بدتری است از «API اورکاریل ۳ ساعت قطع بود».
مستقل: فقط تا وقتی sequencer را غیرمتمرکز کنی تیتر بدتری است. اثبات خطا در OP Stack و توالی‌دهی مشترک (Espresso، Astria) این را به‌تدریج کمتر به ریسک یک طرف واحد تبدیل می‌کنند. درست می‌گویی که از آنجا شروع نمی‌کنیم. اما این هم درست است که نباید به‌تنهایی زنجیره اداره کنیم؛ از طریق یک شریک rollup-as-a-service با مسیری معتبر به توالی‌دهی مشترک راه‌اندازی می‌کنیم.
گرداننده: این وابستگی‌های زیادی است.
مستقل: هست. بده‌بستان این است: برای همیشه پرداخت گس را کنار می‌گذاریم، دیگر برای فضای بلاک mainnet نمی‌جنگیم و می‌توانیم اجزای پایه سفارشی منتشر کنیم. اگر حجم پرداخت آن‌قدر بزرگ باشد که هر کدام از این‌ها را توجیه کند، توجیه دارد. اگر نه، من اشتباه می‌کنم.
باورمند به intent: intent با محدودیت‌های سخت امضا می‌شود. مبلغ پرداختی نمی‌تواند از آنچه پرداخت‌کننده مجاز کرده بیشتر شود. آنچه می‌تواند تغییر کند مسیر است (کدام پل، کدام DEX اگر swap لازم باشد) و زمان‌بندی. solver مخرب نمی‌تواند وجوه را به جای دیگری بفرستد؛ در بدترین حالت کند است. رقابت این را از بین می‌برد.
گرداننده: رقابت کارمزد را در مسیرهای پرحجم پایین می‌آورد. پرداخت خرد ۵ دلاری USDC به USDC بین‌زنجیره‌ای که به هیچ‌کس برای حلش پول کافی نمی‌رسد چه؟
باورمند به intent: این شکاف واقعی است. پاسخ solverهای پشتیبان است؛ OrcaRail یکی را به قیمت تمام‌شده اجرا می‌کند. بازار ۹۵٪ بالایی را پوشش می‌دهد و ما دنباله بلند را. به‌مرور، زنجیره‌های ارزان‌تر و پل‌های بهتر این شکاف را می‌بندند.
گرداننده: یعنی تو هم keeper اجرا می‌کنی، فقط اسمش را solver گذاشته‌ای.
باورمند به intent: keeperی که یکی از چند است، روی یک intent عمومی رقابت می‌کند و پشتیبان دارد؛ بله. این همان تفاوت بین «بک‌اند OrcaRail همان keeper است» و «OrcaRail یک مشارکت‌کننده در بازاری باز است» است.
مدافع استاندارد: اول پیاده‌سازی مرجع را طبق برنامه فعلی منتشر می‌کنی. بعد EIP را حول آنچه منتشر کرده‌ای می‌نویسی، نه از قبل. ERC-4337، ERC-721 و ERC-20 همین‌طور نوشته شدند. نقشه راه فعلی با این سازگار است؛ سطح SubscriptionHub با چند تغییر نام جزئی می‌تواند همان سطح ERC باشد.
گرداننده: انتشار «مزیت رقابتی» به شکل استاندارد ریسکی ندارد؟
مدافع استاندارد: مزیت رقابتی قرارداد نیست. مزیت رقابتی یکپارچه‌سازی‌ها، SLAها، کار انطباق، داشبوردها، تحویل‌پذیری ایمیل و اعتماد فروشندگان است. هیچ‌کدام را رقیب با خواندن یک EIP نمی‌تواند کپی کند. متن‌باز کردن سطح قرارداد رقابت را به جاهایی می‌برد که ما در آن قوی هستیم.
پس از پرسش‌وپاسخ، هر موضع در ابعاد مشخصی قوی‌تر است. کارنامه صادقانه:
| بُعد | عمل‌گرا | حداکثرگرا | مستقل | intent | استاندارد |
|---|---|---|---|---|---|
| زمان انتشار مرحله ۱ | سریع | کند | بسیار کند | کند | سریع |
| حذف امانت‌داری | بله | بله | بله | بله | بله |
| زنده‌بودن بدون OrcaRail | جزئی | قوی | متوسط | قوی | قوی |
| مقاومت در برابر سانسور | جزئی | قوی | متوسط | قوی | قوی |
| تجربه بین‌زنجیره‌ای | خوب | خوب | ضعیف | بهترین | خوب |
| شفافیت مقرراتی | متوسط | متوسط | ضعیف | ضعیف | بالا |
| وابستگی به زیرساخت OrcaRail | بالا | کم | بسیار بالا (زنجیره) | کم | کم |
| تمایز OrcaRail | بالا | کم | بالا | متوسط | بالا |
| ثبت‌نام فروشندگان غیرآشنا با کریپتو | بهترین | سخت‌ترین | متوسط | متوسط | متوسط |
| هزینه مهندسی | کم | متوسط | بسیار بالا | بالا | متوسط |
| خرابی قابل مشاهده برای کاربران فعلی | هیچ | قابل توجه | جدی | متوسط | کم |
هیچ ردیفی غالب نیست. برای همین این یک مناظره است و نه برنامه استقرار.
این‌طور مناظره را می‌خوانم، به‌عنوان کسی که باید انتخاب کند.
عمل‌گرا امروز برنده است چون محصول باید به انتشار ادامه دهد و ما توان توقف ۱۸ ماهه برای بازنویسی معماری را نداریم. نقشه راه فعلی نسخه‌ای اکیداً بهتر از نسخه امانی است که امروز اجرا می‌کنیم، با بهبودهای تدریجی سازگار.
حداکثرگرا از نظر اصول برنده است و یک محدودیت واقعی را نشان می‌دهد: روزی که API ما دلیل دریافت نکردن پول یک فروشنده باشد، روزی است که دیگر پروتکل نیستیم. این همان فشاری است که باید هر تصمیم مهندسی مراحل ۱ تا ۷ را هدایت کند: ایندکسر را منتشر کن، subgraph را منتشر کن، داشبورد را زیر ENS روی IPFS سنجاق کن، نحوه نصب روی سرور خود را مستند کن. نقشه راه عمل‌گرا این را ممکن می‌کند، اما اجبارش نمی‌کند. باید اجبارش کنیم.
مستقل برنده است اگر مقیاس توجیهش کند. زیر یک آستانه حجم، اداره زنجیره سربار است. بالای آن، اجاره فضای بلاک اتریوم برای تقسیم ۳ دلار بین شش نفر در هر بار بی‌معناست. وقتی بخش غالب حجم ما مسیرهای پرداخت‌کننده به فروشنده روی یک زنجیره باشد و بهینه‌سازی گس صرفه‌جویی قابل اندازه‌گیری در صورت مالی ایجاد کند، می‌فهمیم از آن آستانه گذشته‌ایم. هنوز نه.
باورمند به intent در بین‌زنجیره‌ای برنده است. پرداخت‌ها ذاتاً چنددارایی و چندزنجیره‌ای‌اند. جریان پرداخت‌کننده مبتنی بر intent («به فروشنده X بپرداز، برایم مهم نیست چطور») بهترین تجربه ممکن برای پرداخت‌کننده کریپتو است. باید intentها را در لایه SDK پرداخت‌کننده بپذیریم، پیش از اینکه در لایه تسویه بپذیریم. این کار solverهای موجود (Across، deBridge، Relay) را بدون نیاز به ساختن بازاری جدید به گزینه‌ای طبیعی تبدیل می‌کند.
مدافع استاندارد هر جا حداکثرگرا برنده است برنده است، با ریسک کمتر. نوشتن یک EIP حول آنچه در مراحل ۱ و ۲ منتشر می‌کنیم رایگان است، برای اکوسیستم مفید است و ما را کند نمی‌کند. همچنین برای فروشندگانی که برای اولین بار زیرساخت‌های کریپتو را ارزیابی می‌کنند، روایت معتبری از «ما زیرساخت می‌سازیم، نه تله» به ما می‌دهد.
جمع‌بندی کسل‌کننده اما درست: مسیر عمل‌گرا را منتشر کن، فشار حداکثرگرا را اعمال کن، intentها را برای تجربه پرداخت‌کننده بپذیر، در طول راه EIP بنویس و مستقل را به‌عنوان گزینه مرحله ۸ به بعد، مشروط به مقیاس، نگه دار.
به‌طور مشخص، این‌ها تعهدات تدریجی روی نقشه راه موجود است:
Paid و Charged در یک subgraph مرجع که هر کسی بتواند پرس‌وجو کند. بدون مسدود کردن API.pay.orcarail.eth از طریق ENS قابل بازیابی است.orcarail.pay(intent) در کلاینت پرداخت‌های بین‌زنجیره‌ای را از طریق شبکه‌های solver موجود (Across/Relay) مسیریابی می‌کند. solver پشتیبان تحت اداره OrcaRail برای دنباله بلند.SubscriptionHub ما.این پنج افزوده نقشه راه موجود را از «غیرامانی» به «غیرامانی، پروتکل‌محور و بی‌طرف به‌طور معتبر» می‌برند. مراحل ۱ تا ۷ را کند نمی‌کنند. به‌عنوان جریان‌های کاری زنده و جداگانه پیگیری می‌شوند.
این موارد به‌عنوان مسیر P در وایت‌پیپر پروتکل رسمی شده‌اند؛ وایت‌پیپری که M1 تا M5 را به مراحل P1 تا P5 تبدیل می‌کند و M6 (زنجیره اختصاصی) را به‌عنوان P6 اختیاری نگه می‌دارد.
این مطلب همراه نقشه راه غیرامانی است، نه جایگزین آن. نقشه راه همچنان مراحل ۰ تا ۷ را پیگیری می‌کند. این مناظره یک محور ششم اضافه می‌کند، یعنی پروتکل‌محوری، که هر مرحله باید بر اساس آن هم ارزیابی شود.
اگر در این مناظره بودید، موضع خودتان را برایمان بفرستید. استدلال‌های مخالف قوی را منتشر می‌کنیم.
مطالب مرتبط
پرداخت‌کننده یک بار روی قرارداد توکن approve(spender, cap) را امضا می‌کند. بعداً وقتی دوره‌ای سررسید شود، spender (همان SubscriptionHub ما یا برنامه سولانا) transferFrom را فراخوانی می‌کند (EVM) یا با اختیار delegate انتقال می‌دهد (SOL). امانت‌داری نزد پرداخت‌کننده می‌ماند؛ spender در طول عمر اشتراک حداکثر تا cap می‌تواند برداشت کند.
لغو: پرداخت‌کننده approve(spender, 0) یا Revoke را امضا می‌کند. از آن لحظه هیچ برداشتی موفق نمی‌شود.
این همان چیزی است که برداشت خودکار امروز استفاده می‌کند. مرحله ۲ spender را از یک کیف پول داغ تحت کنترل پلتفرم به یک قرارداد روی زنجیره منتقل می‌کند، اما سمت پرداخت‌کننده تغییری نمی‌کند.
پرداخت‌کننده وجوه N دوره را در یک قرارداد اسکرو مخصوص هر اشتراک واریز می‌کند. قرارداد طبق زمان‌بندی وجه را به فروشنده آزاد می‌کند. پرداخت‌کننده هر زمان می‌تواند موجودی استفاده‌نشده (منهای دوره‌های پرداخت‌شده) را برداشت کند.
پرداخت‌کننده از کیف پول هوشمند ERC-4337 استفاده می‌کند و یک session key با دامنه محدود به قرارداد اشتراک می‌دهد. session key فقط کارهایی را می‌تواند انجام دهد که دامنه‌اش اجازه می‌دهد (مثلاً «انتقال حداکثر X دلار USDC در هر ۳۰ روز به این آدرس»). پرداخت‌کننده با حذف session key مجوز را لغو می‌کند.
هر سه را روی پنج محور ارزیابی کردیم:
| محور | برداشت مبتنی بر allowance | اسکرو | session key |
|---|---|---|---|
| امانت‌داری در طول اشتراک فعال | پرداخت‌کننده | قرارداد اسکرو | پرداخت‌کننده (از طریق کیف پول هوشمند) |
| گام‌های راه‌اندازی برای پرداخت‌کننده | ۱ امضا | ۱ واریز (با گس) | ۱ ثبت‌نام در کیف پول 4337 |
| سازگاری کیف پول پرداخت‌کننده | همه کیف پول‌ها | همه کیف پول‌ها | فقط کیف پول‌های 4337 |
| وجوه قفل‌شده / سرمایه در گردش | ندارد | N ماه قفل | ندارد |
| تجربه لغو | لغو approve | برداشت + لغو | حذف session key |
| ریسک keeper | هر فراخواننده‌ای | هر فراخواننده‌ای | هر فراخواننده‌ای |
| پیچیدگی سمت فروشنده | حداقلی | حسابداری آزادسازی | راه‌اندازی bundler در 4337 |
| کار با MetaMask / Phantom | بله | بله | نه به‌صورت بومی |
| کار با Ledger / سخت‌افزاری | بله | بله | جزئی |
| شفافیت مقرراتی | بالا | کمتر (بوی اسکرو می‌دهد) | بالا |
اسکرو جذاب‌ترین شعار را دارد («وجوه پرداخت‌کننده در قرارداد قفل است، نه نزد یک شرکت») اما بدترین تجربه واقعی را:
session key روی کیف پول‌های هوشمند 4337 زیباست. اما لازمه‌اش این است که کیف پول پرداخت‌کننده هوشمند باشد. بیشتر پرداخت‌کنندگان در ۲۰۲۶ هنوز از EOA استفاده می‌کنند (MetaMask، Rabby، کیف پول‌های سخت‌افزاری، امضاکنندگان Safe) و پرداخت‌کنندگان سولانا از کیف پول‌های keypair به سبک Phantom. اجبار به ثبت‌نام در 4337 برای یک اشتراک، نرخ تبدیل را نابود می‌کند.
مسیری هست که در آن 4337 کیف پول پیش‌فرض پرداخت‌کننده شود و session key ساده شود. هنوز به آنجا نرسیده‌ایم.
approve در ERC-20 را امضا کند کار می‌کند؛ یعنی همه.approve(0) یا Revoke جزئی است که رابط هر کیف پولی از قبل نشان می‌دهد.SubscriptionHub.charge(id) عمومی و بدون نیاز به مجوز است. NestJS، Chainlink، Gelato یا یک AVS در EigenLayer (مرحله ۶ را ببینید) همه می‌توانند فراخوانی‌اش کنند.برداشت مبتنی بر allowance بی‌نقص نیست. معایب، صادقانه:
کیف پول‌ها اغلب به‌طور پیش‌فرض مقدار approve نامحدود پیشنهاد می‌دهند. قراردادهای مخرب با allowance نامحدود کیف پول‌ها را خالی می‌کنند. راهکار ما: رابط کاربری صراحتاً تأیید محدود درخواست می‌کند (مثلاً 12 × monthly_amount برای اشتراک سالانه)، رقم دلاری را نشان می‌دهد و متن «هر زمان لغو کنید» را ارائه می‌دهد. قرارداد cap را جدا از allowance در ERC-20 اعمال می‌کند.
پرداخت‌کننده می‌تواند در میانه اشتراک مجوز را لغو کند و برداشت بعدی ناموفق می‌شود. همان حالت خرابی کارت ذخیره‌شده‌ای که باطل شده است. با وب‌هوک + ایمیل موجود مدیریت می‌شود: subscription-insufficient-allowance.hbs و subscription-past-due.hbs.
اگر فروشنده در میانه اشتراک قیمت را بالا ببرد، cap قبلی ممکن است کافی نباشد. با اصل ثابت cap که charge() را revert می‌کند و رابط فروشنده که درخواست تأیید دوباره می‌دهد مدیریت می‌شود.
رباتی که از reorg بلاک سوءاستفاده کند می‌تواند charge() را تکرار کند. با lastChargedAt یکنوا در SubscriptionHub مدیریت می‌شود.
هیچ. جریان فعلی برداشت خودکار از قبل approve(spender, amount) و SPL Approve را درخواست می‌کند؛ همان گام‌ها. مرحله ۲ spender را به آدرس یک قرارداد غیرامانی منتقل می‌کند. کیف پول شما همان صفحه مجوز را نشان می‌دهد.
هیچ تغییری در ساختار پاسخ API. فیلد approval_spender_address در شیء auto_charge اشتراک فقط به‌جای کیف پول داغ OrcaRail به قرارداد SubscriptionHub اشاره می‌کند. وب‌هوک‌ها در همان لحظه‌ها ارسال می‌شوند.
| ملاحظه | برنده |
|---|---|
| تجربه ثبت‌نام پرداخت‌کننده | برداشت مبتنی بر allowance |
| سرمایه در گردش | برداشت مبتنی بر allowance / session key |
| سازگاری کیف پول | برداشت مبتنی بر allowance |
| شفافیت مقرراتی | برداشت مبتنی بر allowance / session key |
| انعطاف keeper | هر سه |
| سادگی قرارداد | برداشت مبتنی بر allowance |
برداشت مبتنی بر allowance در سازگاری کیف پول و سرمایه در گردش به‌طور قطعی برنده است و در همه محورهای دیگر مساوی یا برنده است. به همین دلیل اشتراک‌های OrcaRail بر پایه آن ساخته شده‌اند.
مرتبط: مرحله ۲: اشتراک مبتنی بر allowance · مستندات برداشت خودکار · مدل امنیتی
]]>اشتراک‌ها برای SaaS، عضویت‌ها، قراردادهای ماهانه و هر محصولی است که در بازه ثابت (روز، هفته، ماه، سال) صورت‌حساب می‌شود؛ با امکان دوره آزمایشی، سقف تعداد دوره و قواعد لغو. از همان احراز هویت پرداخت بقیه پلتفرم استفاده می‌کنید و می‌توانید با وب‌هوک‌های اشتراک به رویدادهای چرخه عمر واکنش نشان دهید.
send_payment_link (پیش‌فرض): در هر دوره صورت‌حساب، پرداخت‌کننده یک لینک پرداخت دریافت می‌کند (ایمیل و/یا جریان میزبانی‌شده). با باز کردن لینک پرداخت می‌کند؛ روشی آشنا برای پرداخت کریپتو که به‌راحتی با مسیرهای Relay و انتخاب کیف پول ترکیب می‌شود.auto_charge: پرداخت‌کننده از قبل به کیف پول داغ (hot wallet) اورکاریل اجازه می‌دهد مبلغ هر دوره را در هر تمدید برداشت کند. پس از راه‌اندازی، تا وقتی موجودی و مجوز معتبر باشد، پرداخت‌کننده لازم نیست برای هر تمدید روی لینک جدیدی کلیک کند.نحوه دریافت را با POST /api/v1/subscriptions بسازید و تنظیم کنید؛ برای فهرست، ویرایش، توقف و لغو از مدیریت اشتراک‌ها استفاده کنید. فیلدهای کامل درخواست و نمونه‌ها در همین راهنماها آمده است.
collection_method: "auto_charge" و فیلدهای معمول amount، interval، token_id، network_id و اطلاعات تماس پرداخت‌کننده می‌سازد.approve(spender, amount) استاندارد ERC-20 است که کیف پول داغ ما spender آن است.POST /api/v1/subscriptions/:id/approve-auto-charge را با هش تراکنش allowance (یا delegation)، payer_wallet_address، payer_network_id و payer_token_id فراخوانی می‌کند. کلید API فروشنده لازم نیست؛ پرداخت‌کننده با امضای تراکنش روی زنجیره قصد خود را ثابت کرده است.transferFrom از پرداخت‌کننده به تسویه؛ در سولانا از موجودی واگذارشده استفاده می‌شود). در صورت موفقیت دوره جلو می‌رود؛ در صورت شکست مکرر (مثلاً موجودی ناکافی یا لغو مجوز) اشتراک ممکن است به past_due برود و به پرداخت‌کننده اطلاع داده شود. می‌توانید به وب‌هوک‌هایی مثل subscription.payment_link.payment_failed یا subscription.past_due گوش دهید؛ توضیحات در برداشت خودکار و وب‌هوک‌ها آمده است.لغو مجوز و روش جایگزین: اگر پرداخت‌کننده مجوز را روی زنجیره لغو کند، برداشت‌های بعدی ناموفق می‌شوند. او همچنین می‌تواند پس از لغو، POST .../revoke-auto-charge را فراخوانی کند تا وضعیت را ثبت کنیم و روش دریافت را به send_payment_link تغییر دهیم؛ همراه با ایمیل راهنما برای مدیریت اشتراک و پرداخت دوباره از طریق لینک. جزئیات در برداشت خودکار و مدیریت اشتراک‌ها آمده است.
امنیت و شفافیت: فقط کیف پولی که تأیید را انجام داده برای برداشت استفاده می‌شود؛ تجربه کاربری را با مجموع مبالغ و تعداد دوره‌های روشن هماهنگ کرده‌ایم تا پرداخت‌کنندگان بدانند چه چیزی را تأیید کرده‌اند. برای پلن‌های بسیار طولانی یا بی‌پایان، محدود کردن مبلغ تأییدشده و تمدید دوره‌ای تأیید را در نظر بگیرید، یا از لینک پرداخت استفاده کنید؛ برداشت خودکار را ببینید.
network_id و token_id ساخته می‌شود که نحوه قیمت‌گذاری و تسویه آن را در API تعیین می‌کند؛ شبکه و دارایی «اصلی» آن پلن.payer_network_id و payer_token_id را ذخیره می‌کند؛ یعنی شبکه و توکنی که پرداخت‌کننده واقعاً allowance یا delegation را روی آن تنظیم کرده است. وقتی پرداخت‌کننده از زنجیره یا دارایی پشتیبانی‌شده دیگری پرداخت کند، این مقادیر می‌توانند با فیلدهای اصلی اشتراک فرق داشته باشند؛ هماهنگ با نحوه‌ای که پیش‌فاکتور و صفحه پرداخت مسیرهای سمت پرداخت‌کننده را تعیین می‌کنند.| موضوع | رفتار OrcaRail |
|---|---|
| دریافت وجه | send_payment_link در هر دوره، یا auto_charge با تأیید روی زنجیره |
| برداشت خودکار | approve در ERC-20 روی EVM یا delegate در SPL روی سولانا ← API عمومی تأیید ← بررسی روی زنجیره ← برداشت در هر دوره، با past_due و وب‌هوک در صورت شکست |
| لغو مجوز | لغو روی زنجیره + revoke-auto-charge اختیاری؛ امکان بازگشت به لینک پرداخت |
| چندزنجیره‌ای | network_id / token_id اشتراک؛ تأیید پرداخت‌کننده payer_network_id / payer_token_id را ذخیره می‌کند؛ شبکه‌های هم‌راستا با Relay؛ برداشت برای هر نوع زنجیره |
اشتراک در OrcaRail منابع REST اشتراک را با مجوز غیرامانی پرداخت‌کننده برای برداشت خودکار و تسویه چندزنجیره‌ای ترکیب می‌کند؛ بدون اینکه از تجربه پرداخت میزبانی‌شده و APIهایی که برای پرداخت‌های یک‌باره استفاده می‌کنید دست بکشید.
اپ OrcaRail · مستندات · Relay
]]>ما فهرست جداگانه و دستی از شبکه‌ها و توکن‌های پشتیبانی‌شده نگه نمی‌داریم. به‌جای آن:
وقتی Relay زنجیره یا ارز جدیدی اضافه کند، فرایند seed/به‌روزرسانی ما آن را وارد می‌کند. شما بدون کار یکپارچه‌سازی اضافه، هم‌راستایی خودکار با پوشش Relay دارید.
پرداخت‌ها و (در موارد لازم) پل‌زدن از مسیرهای پشتیبانی‌شده Relay پیروی می‌کنند. Relay در حال حاضر از بیش از ۶۹ شبکه بلاکچین در این دسته‌ها پشتیبانی می‌کند:
پشتیبانی از توکن‌ها در هر زنجیره می‌تواند "All" (توکن‌هایی که نقدینگی Solver یا DEX دارند) یا "Limited" (فقط توکن‌هایی با supportsBridging: true) باشد. برای تصویر مرجع از مسیرها و توکن‌های پشتیبانی‌شده، مستندات Relay را ببینید:
از API ما برای دریافت مجموعه فعلی شبکه‌ها و توکن‌های موجود در OrcaRail استفاده کنید:
GET /payments/networks — فهرست همه شبکه‌های پشتیبانی‌شده (اختیاری: فیلتر با ?active=true).GET /payments/networks/:id/tokens — فهرست توکن‌های یک شبکه (از id شبکه در فهرست بالا استفاده کنید).GET /price/currencies — فهرست ارزهای فیات پشتیبانی‌شده برای قیمت‌گذاری و پیش‌فاکتور.جزئیات کامل در مستندات Payments API – فهرست شبکه‌ها / فهرست توکن‌ها و Price API – فهرست ارزها آمده است.
| منبع | چه چیزی همگام می‌کنیم | نحوه به‌روزرسانی |
|---|---|---|
| شبکه‌ها | از Chains API رله | از طریق seed شبکه؛ زنجیره‌های جدید ظاهر می‌شوند |
| ارزها/توکن‌ها | از Currencies v2 رله، برای هر شبکه | از طریق seed توکن؛ توکن‌های جدید ظاهر می‌شوند |
| پوشش Relay | بیش از ۶۹ زنجیره، EVM + بیت‌کوین + سولانا + ترون | Relay منبع حقیقت است؛ ما از آن پیروی می‌کنیم |
شبکه‌ها و ارزهای پشتیبانی‌شده در OrcaRail با قدرت Relay و به‌صورت خودکار به‌روز می‌شوند؛ یک یکپارچه‌سازی، زنجیره‌های متعدد.
اپ OrcaRail · مستندات · Relay
]]>OrcaRail امروز برای زنجیره‌های سازگار با EVM ساخته شده است. ما از بیت‌کوین و سولانا (یا توکن‌های بومی سولانا) به‌عنوان زنجیره‌های اصلی در جریان‌های پرداخت و برداشت پشتیبانی نمی‌کنیم. این کار سطح یکپارچه‌سازی را متمرکز و APIها را در حین رشد یکدست نگه می‌دارد.
اگر زیرساخت شما Ethereum، Base، Polygon، Arbitrum، Optimism یا دیگر لایه‌های ۱ و ۲ مبتنی بر EVM است، یک یکپارچه‌سازی و یک مجموعه مستندات دارید. فعلاً جریان جداگانه‌ای برای بیت‌کوین یا سولانا وجود ندارد.
ارزش واقعی «چندزنجیره‌ای» در برداشت‌ها مشخص می‌شود. در OrcaRail می‌توانید برای هر نوع زنجیره چند آدرس برداشت تنظیم کنید.
withdrawal_address بفرستید تا همان پرداخت به فروشنده یا خزانه روی زنجیره درست برود.پس چندزنجیره‌ای یعنی چند شبکه و چند مقصد برداشت برای هر زنجیره؛ همه قابل تنظیم در داشبورد و از طریق API.
Relay در پوشش چندزنجیره‌ای خود از بیت‌کوین و سولانا (و توکن‌هایشان) پشتیبانی می‌کند. OrcaRail طوری ساخته شده که با مدل Relay هم‌راستا باشد: یک لینک، زنجیره‌های متعدد.
ما امروز از بیت‌کوین یا سولانا پشتیبانی نمی‌کنیم، اما معماری و نقشه راه ما طوری طراحی شده که وقتی آن‌ها را اضافه کنیم، همان محصول باشد: همان APIها، همان مدل برداشت (چند آدرس برای هر زنجیره) و همان داشبورد. منظور از «ما هم» این است که به همان چشم‌انداز چندزنجیره‌ای که Relay نماینده آن است، از جمله بیت‌کوین و سولانا، متعهدیم و در همان جهت گسترش می‌یابیم.
تا آن زمان، تجربه‌ای پایدار و EVMمحور از پرداخت چندزنجیره‌ای دارید و روی مقصد وجوه در هر زنجیره پشتیبانی‌شده کنترل کامل دارید.
| حوزه | OrcaRail امروز |
|---|---|
| زنجیره‌ها | سازگار با EVM (Ethereum، Base، Polygon، Arbitrum، Optimism و غیره) |
| بیت‌کوین / سولانا | هنوز پشتیبانی نمی‌شوند؛ در نقشه راه هم‌راستا با پشتیبانی Relay |
| برداشت | چند آدرس برداشت برای هر نوع زنجیره؛ جایگزینی برای هر پرداخت پشتیبانی می‌شود |
| Relay | همان فلسفه چندزنجیره‌ای؛ پشتیبانی از زنجیره‌ها را همگام با Relay گسترش می‌دهیم (بیت‌کوین، سولانا و فراتر) |
چندزنجیره‌ای در OrcaRail یعنی: همین حالا زنجیره‌های EVM متعدد، چند آدرس برداشت برای هر زنجیره و مسیری به سوی بیت‌کوین و سولانا همگام با Relay.
اپ OrcaRail · مستندات · Relay
]]>OrcaRail با کمک هوش مصنوعی ساخته شده و یک باور اصلی پشت آن است: پرداخت‌های کریپتو باید باز، شفاف و روی همه زنجیره‌ها در دسترس باشند. مدت‌هاست که فروشندگان و توسعه‌دهندگان مجبورند بین ابزارهای متن‌باز پیچیده و بدون نگهداری، یا درگاه‌های پرداخت گران و بسته‌ای که شما را در اکوسیستم خود قفل می‌کنند و کارمزد بالا می‌گیرند، یکی را انتخاب کنند.
OrcaRail را ساختیم تا این الگو را بشکنیم. OrcaRail یک پلتفرم پرداخت چندزنجیره‌ای است که منطق کسب‌وکار وب۲ را به تسویه وب۳ وصل می‌کند؛ به‌صورت میزبانی‌شده با تعرفه ساده درصدی و سطح رایگان سخاوتمندانه، یا نصب روی سرور خودتان برای استقلال کامل.
ما باور داریم زیرساخت مالی اینترنت باید یک کالای عمومی باشد. نسخه میزبانی‌شده OrcaRail برای هر تراکنش تکمیل‌شده ۰٫۵٪ هزینه دارد و ۱٬۰۰۰ تراکنش اول شما رایگان است؛ به این ترتیب می‌توانیم زیرساختی قابل‌اعتماد را اجرا کنیم و همچنان برای سازندگان در دسترس بمانیم. نسخه نصب روی سرور خودتان از کارمزد نرم‌افزاری OrcaRail رایگان است: آن را روی سخت‌افزار خودتان مستقر کنید و فقط هزینه زیرساخت خودتان را بپردازید. SDKهای رسمی، MCP و افزونه‌ها با مجوز MIT منتشر شده‌اند.
پیش‌فاکتور هر پرداخت همچنان می‌تواند اقلام اختیاری تحت کنترل شما را داشته باشد؛ مثلاً کارمزد پشتیبانی قابل تنظیم (درصدی) و کمیسیون روی کلیدهای API، به‌علاوه کارمزد پل هنگام مسیریابی بین توکن‌ها یا شبکه‌ها. این موارد در راهنمای کارمزدها و محدودیت‌ها توضیح داده شده‌اند و از تعرفه پلتفرم میزبانی‌شده جدا هستند.
با متن‌باز ماندن و سپردن بهبود محصول به جامعه، هدف ما زیرساختی غیرامانی و پرسرعت است که ریسک طرف مقابل کمتری از درگاه‌های بسته دارد؛ شفاف از پایه.
چه سازندگان از نسخه میزبانی‌شده استفاده کنند، چه آن را روی سرور خود نصب کنند یا هر دو را ترکیب کنند، با هم می‌توانیم در برابر سیلوهای پرداخت مبهم و پرکارمزد بایستیم.
اگر بلدید درگاه‌های پرداخت سنتی وب۲ را یکپارچه کنید، استفاده از OrcaRail را هم بلدید. معماری ما طوری طراحی شده که وضعیت‌های قابل پیش‌بینی، جریان‌های قابل حسابرسی و وب‌هوک‌هایی امن در برابر تلاش مجدد داشته باشید.
succeeded، processing و canceled با تلاش مجدد خودکار ارسال می‌کند.npm install @orcarail/node
وب۳ پراکنده است، اما درگاه پرداخت شما نباید باشد. یک یکپارچه‌سازی دارید که بدون دردسر روی همه شبکه‌ها کار می‌کند.
در حال حاضر OrcaRail به‌طور پیش‌فرض از زنجیره‌های سازگار با EVM پشتیبانی می‌کند. اما همین‌جا متوقف نمی‌شویم؛ همه زنجیره‌های پشتیبانی‌شده توسط Relay در راه هستند. فناوری مسیریابی هوشمند ما به‌طور خودکار کمک می‌کند سریع‌ترین یا کم‌کارمزدترین شبکه برای هر پرداخت انتخاب شود تا مشتریان شما هیچ‌وقت به‌خاطر کارمزد گس سنگین سبد خرید را رها نکنند.
کسب‌وکارهای اینترنتی امروزی پیچیده‌اند. چه یک پلتفرم SaaS اداره کنید، چه یک مارکت‌پلیس چندفروشنده یا یک اپ اقتصاد تولیدکنندگان محتوا، مسیریابی دستی وجوه کابوس است. OrcaRail این مسئله را به‌صورت بومی حل می‌کند:
withdrawal_address بفرستید. وقتی مشتری پرداخت می‌کند، وجه به‌طور خودکار مستقیم به کیف پول همان فروشنده فرستاده می‌شود.این تازه روز اول است. هرچه بزرگ‌تر شویم، تعهدمان به اکوسیستم باز عمیق‌تر می‌شود:
از شما دعوت می‌کنیم ببینید پرداخت کریپتو چقدر می‌تواند ساده باشد.
آینده باید باز و شفاف باشد. بیایید با هم آن را بسازیم.