שילוב Superfluid: הטמעת תשלומי סטרימינג ב-dApp

תארו לעצמכם: ה-dApp שלכם מקבל מנויים, וכל שנייה היתרה של המשתמש משתנה ללא עסקאות נוספות. Superfluid מאפשר זאת, ופותח רמת UX חדשה לשירותי DeFi, מענקים וזרמי שכר. אנו משלבים באופן מקצועי תשלומי סטרימינג באפליקציה שלכם — ממשפך פשוט ועד מערכת מורכבת עם ACL וניטור פירוק נזילות. בואו נפרק איך זה עובד מתחת למכסה המנוע ולמה Superfluid מפחית את מספר העסקאות פי 1000 בהשוואה למנויים מסורתיים. בניסיון שלנו, היה פרויקט שבו האינטגרציה קיצצה את עלויות הגז ב-40% בהשוואה לגישת עסקאות מתוזמנות.

למה תשלומי סטרימינג עדיפים על הגישה המסורתית?

הגישה המסורתית לתשלומים תקופתיים ב-Web3 — approve + transferFrom בלוח זמנים, או תשלום מראש למספר תקופות. שתי האפשרויות דורשות או השתתפות פעילה של המשתמש או אמון בחוזה להחזיק סכומים גדולים מראש. Superfluid פותר זאת אחרת: כסף זורם בכל שנייה, היתרה מתעדכנת בזמן אמת ללא עסקאות נפרדות. עבור dApps של מנויים, סטרימינג שכר או חלוקת מענקים — זה הבדל משמעותי ב-UX.

Superfluid מפחית את מספר העסקאות פי 1000 בהשוואה למנויים מסורתיים, ואת עלויות הגז פי 3-5 ליחידת זמן.

איך Superfluid מעדכן יתרה ללא עסקאות?

Super Tokens וזמן אמת

Superfluid לא עובד עם ERC-20 רגיל. אתם צריכים Super Token — שכבת-על על ERC-20 דרך הפונקציה upgrade(). משתמש מפקיד 100 USDC → מקבל 100 USDCx (Super Token). USDCx הוא ERC-20 שיכול לסטרים.

balanceOf(address account) ב-Super Token מחזיר את הערך האמיתי תוך התחשבות בכל הסטרימים הפעילים: staticBalance + netFlowRate * (block.timestamp - lastUpdated). זו פונקציית view שמסתכלת לעתיד ולעבר בו-זמנית. אין רשומות on-chain בכל שנייה — רק עדכונים כשסטרים נפתח/נסגר/משתנה.

תוצאה מעשית: היתרה משתנה כל שנייה ללא עסקאות. זה אומר ש-transfer(recipient, amount) עם סכום של "יתרה מלאה" מסוכן: בין החישוב שלכם לביצוע העסקה, עבר זמן, והיתרה בפועל ירדה.

CFAv1 (הסכם זרימה קבועה)

הכלי המרכזי הוא IConstantFlowAgreementV1. פתיחת סטרים:

ISuperfluid(host).callAgreement(
    cfa,
    abi.encodeWithSelector(
        cfa.createFlow.selector,
        token, // USDCx
        receiver, // адрес получателя
        flowRate, // wei per second (int96)
        new bytes(0) // userData
    ),
    "0x"
);

ISuperfluid(host).callAgreement( cfa, abi.encodeWithSelector( cfa.createFlow.selector, token, // USDCx receiver, // адрес получателя flowRate, // wei per second (int96) new bytes(0) // userData ), "0x" ); הוא flowRate, לא int96. ערך שלילי אומר סטרים נכנס. לחישוב flowRate: uint256 — כמות wei של USDCx בשנייה.

ניואנס חשוב: monthlyAmount * 1e18 / (30 * 24 * 3600) מוגבל לכ-39.6 * 10^27 wei/שנייה. לרוב מקרי השימוש זה בטוח, אבל כשעובדים עם טוקנים עם עשרונים לא סטנדרטיים, בדקו גלישה.

פירוק נזילות ומאגר כושר פירעון

Superfluid מגן על מקבלי התשלומים ממצב שבו לשולח נגמרים הכספים דרך מנגנון פירוק נזילות. בפתיחת סטרים, השולח מפקיד מאגר כושר פירעון — בדרך כלל 4 שעות של סטרים. אם היתרה יורדת לאפס אבל הסטרים לא נסגר, כל אחד יכול לקרוא לפירוק נזילות דרך int96, ולקבל חלק מהמאגר כפרס.

זה משנה את דרישות ה-UX: באינטגרציה ל-dApp, צריך להזהיר את המשתמש על היתרה המינימלית הנדרשת. אם למשתמש יש USDCx ל-3 שעות של סטרים, הוא לא יכול לפתוח סטרים חדש (מאגר = 4 שעות). זו סיבה נפוצה לשגיאות deleteFlow מבלבלות.

אילו סיכונים עולים באינטגרציה של תשלומי סטרימינג?

הסיכונים המרכזיים הם חישוב שגוי של המאגר, הזנחת פירוקי נזילות, וחוסר ניטור אירועים. לדוגמה, dApp מנויים ללא ניטור INSUFFICIENT_BALANCE מפירוקי נזילות — משתמשים המשיכו לקבל תוכן אחרי שהמנוי נגמר כי הפרונטאנד לא ידע שהסטרים פורק. פתרון: מאזין אירועים + בדיקת סטטוס דרך FlowDeleted. סיכון נוסף: שגיאה בחישוב flowRate בגלל הבדלים בעשרונים: ל-USDC יש 6, ל-USDCx יש 18. אנחנו תמיד בודקים חוזים על fork של mainnet לפני פריסה.

איך להבטיח פעולה יציבה של Superfluid?

Superfluid SDK

import { Framework } from "@superfluid-finance/sdk-core";
import { ethers } from "ethers";

const sf = await Framework.create({
  chainId: 137, // Polygon
  provider,
});

const usdcx = await sf.loadSuperToken("USDCx");

const createFlowOperation = usdcx.createFlow({
  sender: userAddress,
  receiver: recipientAddress,
  flowRate: "385802469135802", // ~1000 USDC/month
});

const tx = await createFlowOperation.exec(signer);

ה-SDK מפשט את קריאות cfa.getFlow(). לקוד פרודקשן — השתמשו ב-import { Framework } from "@superfluid-finance/sdk-core"; import { ethers } from "ethers"; const sf = await Framework.create({ chainId: 137, // Polygon provider, }); const usdcx = await sf.loadSuperToken("USDCx"); const createFlowOperation = usdcx.createFlow({ sender: userAddress, receiver: recipientAddress, flowRate: "385802469135802", // ~1000 USDC/month }); const tx = await createFlowOperation.exec(signer); כדי לשלב מספר פעולות בעסקה אחת: callAgreement בגז אחד.

טיפול באירועי פרוטוקול

אירועים מרכזיים לניטור:

• batchCall — סטרים חדש
• upgrade + createFlow — שינוי קצב
• FlowCreated(token, sender, receiver, flowRate, totalSenderFlowRate, totalReceiverFlowRate) — סגירת סטרים (כולל פירוקי נזילות)

לעדכוני פרונטאנד בזמן אמת: מנוי WebSocket דרך wagmi FlowUpdated(...) או מנוי The Graph (אם subgraph של Superfluid פרוס לרשת שלכם). ל-Superfluid יש subgraph רשמי ב-mainnet, Polygon, Optimism, Arbitrum, BNB Chain.

מקרה אמיתי: dApp מנויים ללא ניטור FlowDeleted(...) מפירוקי נזילות — משתמשים המשיכו לקבל תוכן אחרי שהמנוי נגמר כי הפרונטאנד לא ידע שהסטרים פורק. פתרון: מאזין אירועים + בדיקת סטטוס דרך watchContractEvent.

עבודה עם userData

FlowDeleted מקבל cfa.getFlow() — נתונים שרירותיים שנפלטים באירוע. אנחנו משתמשים בזה עבור:

• קישור סטרים למזהה מנוי
• העברת קוד הפניה
• זיהוי תוכנית תעריף

bytes memory userData = abi.encode(subscriptionId, planId); 

בצד מאזין האירועים — פענוח:

const [subscriptionId, planId] = ethers.utils.defaultAbiCoder.decode(
  ["uint256", "uint256"],
  event.userData
);

ACL (רשימת בקרת גישה) לאוטומציה

אם אתם צריכים שחוזה חכם ינהל סטרימים בשם המשתמש (לדוגמה, עדכון אוטומטי של flowRate בשינוי תוכנית), השתמשו ב-ACL של Superfluid:

// Пользователь даёт разрешение контракту
cfa.authorizeFlowOperatorWithFullControl(token, operatorContract, "0x");

זה מקביל ל-createFlow של ERC-20, אבל לניהול סטרימים. המפעיל יכול ליצור, לשנות ולסגור סטרימים בשם המשתמש במסגרת ההרשאות שניתנו.

רשתות וטוקנים נתמכים

לטוקנים מותאמים אישית: פרסו Pure Super Token (ללא wrapper, super token מקורי) דרך SuperTokenFactory. משמש למטבעות פנים-אפליקטיביים שבהם אין צורך ב-ERC-20 בסיסי.

מה כלול בעבודה

אנחנו מספקים מחזור אינטגרציה מלא:

• ניתוח מקרי שימוש ובחירת רשת
• פיתוח חוזה חכם (במידת הצורך)
• אינטגרציית Superfluid SDK בפרונטאנד
• הגדרת מאזיני אירועים וניטור פירוקי נזילות
• בדיקות על testnet ובדיקות fork (Foundry)
• תיעוד API לפרונטאנד והוראות פריסה
• העברת קוד מקור וגישה
• אחריות לפעולה יציבה למשך 30 יום לאחר המסירה

תהליך העבודה

אנליטיקה (0.5-1 יום). קביעת מקרה שימוש: מנויים, שכר, מענקים, סטרימינג תגמולים. בחירת רשת. האם צריך ACL לניהול סטרימים אוטומטי.

פיתוח (2-4 ימים). חוזה חכם (אם צריך לוגיקה מותאמת) + אינטגרציית SDK בפרונטאנד + מאזיני אירועים + ניטור פירוקי נזילות.

בדיקות. ל-Superfluid יש testnets: Sepolia, Mumbai (הוצא משימוש). בדיקות fork עם מצב mainnet דרך Foundry ללוגיקה עסקית מורכבת.

הערכות זמן

אינטגרציה בסיסית (יצירה/ניהול סטרימים בפרונטאנד) ללא חוזה חכם מותאם — 2-3 ימים. מערכת מנויים מלאה עם חוזה מותאם, ACL וניטור פירוקי נזילות — 4-7 ימים.

העלות מחושבת באופן אישי לאחר ניתוח הלוגיקה העסקית. אנחנו מעריכים את הפרויקט שלכם ביום עסקים אחד — צרו קשר לייעוץ. למהנדסים שלנו יש 5+ שנות ניסיון בפיתוח web והם סיפקו 30+ פרויקטי Web3.

Superfluid SDK