Daniil Ankushin از Nethermind نتیجه آزمایش یک shielded pool واقعی مبتنی بر BN254 Groth16 را روی frame transaction منتشر کرده است. در این الگو، خود pool فرستنده transaction است و gas برداشت را می‌پردازد؛ بنابراین کاربر به حساب دارای موجودی یا relayer نیاز ندارد و در transaction ظاهر نمی‌شود. آزمایش با minimal-shielded-pool متعلق به soispoke انجام شده است.
هنگام برداشت، بخش VERIFY در pool، zero-knowledge proof را بررسی و اجرا و پرداخت را تأیید می‌کند. پیش‌نویس EIP-8250 اجازه می‌دهد nullifierهای هر برداشت به‌عنوان کلیدهای Nonce استفاده شوند؛ در نتیجه برداشت‌های متعدد از یک آدرس pool بر سر یک Nonce رقابت نمی‌کنند. استفاده دوباره از همان کلید نیز پیش از اجرای کد pool رد می‌شود. EIP-8272 هم Merkle root را پیش از اجرای pool با contract مربوط به rootهای اخیر تطبیق می‌دهد؛ به این ترتیب node در mempool نیازی به خواندن storage خود pool ندارد.
اندازه‌گیری روی یک node از Nethermind master انجام شده و هزینه کل برداشت ۶۷۹٬۳۲۲ gas بوده است. از این مقدار، ۳۷۹٬۴۴۰ به state gas مربوط می‌شود؛ شامل ۱۹۵٬۸۴۰ برای دو کلید nullifier. بااین‌حال، بخش validation با مصرف ۲۱۵٬۶۵۴ execution gas از سقف MAX_VERIFY_GAS در EIP-8141 عبور می‌کند. بودجه پیش‌فرض ۳۰۰٬۰۰۰ در Nethermind پذیرش این برداشت را ممکن کرد، اما node با بودجه کف آن را نمی‌پذیرد. تغییر پیشنهادی برای تبدیل این سقف به کف مشترک mempool هنوز باز است.
محدودیت دیگر زمانی ظاهر می‌شود که کاربر بخواهد فراخوانی از آدرس خودش انجام شود، ولی pool هزینه را بدهد. کلیدهای EIP-8250 زیر آدرس فرستنده نگه‌داری می‌شوند؛ پس یک nullifier مشترک از دو آدرس، دو کلید متفاوت محسوب می‌شود. قواعد public mempool نیز اجازه خواندن storage خود pool را در این حالت نمی‌دهند و برای چنین پرداخت‌کننده‌ای فقط یک transaction در انتظار را در هر node مجاز می‌دانند.
پیشنهاد تغییر دامنه کلیدها به حساب پرداخت‌کننده پس از مخالفت یکی از نویسندگان EIP-8250 بسته شد. جمع‌بندی نویسنده این است: فعلاً یا pool باید فرستنده باشد، یا کاربر ابتدا برداشت کند و سپس با transaction جداگانه هزینه فراخوانی خود را بدهد. پرداخت pool برای فراخوانی از آدرس کاربر در یک transaction از مسیر public mempool همچنان حل نشده و عدد gas برای آن وجود ندارد.
