פיתוח פלטפורמת טוקנים ליוצרים

אנו מפתחים פלטפורמות להנפקת טוקנים אישיים ליוצרי תוכן. טוקנים ליוצרים מאפשרים לסטרימרים, מוזיקאים ובלוגרים להפיק רווח מהקהל שלהם באמצעות גישה בלעדית, הצבעות וחלוקת הכנסות. Friend.tech דחפה את המודל הזה לנפח מסחר של מעל 100 מיליון דולר תוך שבועות, והולידה גל של חיקויים. Rally, Roll, Bitclout/DeSo ניסו לפני כן, אך יישום טכני ועיצוב כלכלי הם גורמי ההצלחה המרכזיים.

למה יצירת פלטפורמת טוקנים ליוצרים אינה טריוויאלית?

השאלה המרכזית אינה "איך להנפיק ERC-20" — זה טריוויאלי. הבעיה היא הכלכלה שיוצרת ערך גם ליוצר וגם למחזיקים, לא רק פמפ אנד דאמפ ספקולטיבי. עקומות קשר (bonding curves), עמלות, מנגנוני תועלת — כל רכיב דורש כוונון עדין.

איך פועלת עקומת קשר?

Friend.tech משתמשת בעקומת קשר — שוק יוצר אוטומטי שבו מחיר הטוקן נקבע דטרמיניסטית לפי ההיצע הנוכחי. אין ספר הזמנות, אין ספק נזילות, אין נזילות חיצונית. העקומה הלינארית הפשוטה ביותר: price = k * supply. Friend.tech השתמשה בנוסחה ריבועית: price = supply² / divisor.

contract CreatorTokenBondingCurve {
    uint256 public constant DIVISOR = 16000; // параметр кривой

    // Friend.tech formula: цена для N-го токена
    function getPrice(uint256 supply, uint256 amount) public pure returns (uint256) {
        uint256 sum1 = supply == 0 ? 0 : (supply - 1) * supply * (2 * (supply - 1) + 1) / 6;
        uint256 sum2 = (supply + amount - 1) * (supply + amount) * (2 * (supply + amount - 1) + 1) / 6;
        uint256 summation = sum2 - sum1;
        return summation * 1 ether / DIVISOR;
    }

    function getBuyPrice(address creator, uint256 amount) public view returns (uint256) {
        return getPrice(sharesSupply[creator], amount);
    }

    function getSellPrice(address creator, uint256 amount) public view returns (uint256) {
        return getPrice(sharesSupply[creator] - amount, amount);
    }
}

המרווח בין קנייה למכירה. בשל העקומה המונוטונית העולה, קנייה תמיד יקרה יותר ממכירה באותו היצע. זהו המרווח המובנה — ההגנה העיקרית מפני ארביטראז' מיידי. כשקונים טוקן אחד בהיצע=100 ומוכרים מיד, המשתמש מקבל פחות ממה ששילם (בגובה המרווח).

עמלות פרוטוקול ויוצר

Friend.tech גבתה 10% מכל עסקה: 5% לפרוטוקול, 5% ליוצר. זה מספק הכנסה פסיבית ליוצרים עם כל קנייה/מכירה של טוקן.

uint256 constant PROTOCOL_FEE_PERCENT = 5; // 5%
uint256 constant CREATOR_FEE_PERCENT = 5; // 5%
function buyShares(address creator, uint256 amount) external payable {
    uint256 supply = sharesSupply[creator];
    require(supply > 0 || creator == msg.sender, "Only creator can buy first share");
    uint256 price = getPrice(supply, amount);
    uint256 protocolFee = price * PROTOCOL_FEE_PERCENT / 100;
    uint256 creatorFee = price * CREATOR_FEE_PERCENT / 100;
    require(msg.value >= price + protocolFee + creatorFee, "Insufficient payment");
    sharesBalance[creator][msg.sender] += amount;
    sharesSupply[creator] = supply + amount;
    emit Trade(msg.sender, creator, true, amount, price, protocolFee, creatorFee, supply + amount);
    (bool success1,) = protocolFeeDestination.call{value: protocolFee}("");
    (bool success2,) = creator.call{value: creatorFee}("");
    require(success1 && success2, "Fee transfer failed");
}

הטוקן הראשון נמכר רק ליוצר עצמו. זה מונע יצירת טוקן בשם של מישהו אחר.

בעיות עם עקומות קשר וחלופות

• מניפולציה בהשקה: בוט קונה את N הטוקנים הראשונים של יוצר לפני שהקהל יודע עליהם. המחיר כבר גבוה → קונים אורגניים משלמים יותר מדי → הבוט מוכר. צמצומים: תקופת נעילה לרכישות ראשוניות, הקצאה מקסימלית לכתובת בשעות הראשונות, הוכחת אנושיות ליוצרים.
• ריכוזיות בקרב קונים מוקדמים: למחזיקים מוקדמים יש עלות בסיס נמוכה ביותר והם יכולים לזרוק בכל רגע. לפלטפורמה קהילתית ארוכת טווח זו בעיה מערכתית. פתרונות: וסטינג להקצאת היוצר, נעילה באמצעות ממשל.
• חוסר ערך בסיסי: אם הטוקן לא מספק הרשאות אמיתיות, זה ספקולציה טהורה. Friend.tech צנחה ביותר מ-95% מהשיא כשהעניין הספקולטיבי התייבש והתועלת נעדרה.

מודלים חלופיים:

• היצע קבוע עם מכירה פומבית — היוצר מנפיק כמות קבועה, מוכר במכירה פומבית הולנדית. שקוף אך ללא שוק רציף.
• חברות NFT — NFTs מדורגים (ברונזה/זהב/פלטינה) במקום טוקנים ניתנים להחלפה. ללא מנגנונים ספקולטיביים.
• טוקן חלוקת הכנסות — ERC-20 עם זכויות לחלק מהכנסות היוצר. תועלת אמיתית אך דורש עבודה רגולטורית.

אילו מנגנוני תועלת באמת עובדים?

ללא תועלת, טוקן ליוצר הוא מכשיר ספקולטיבי. הנה מנגנונים שבאמת עובדים:

תוכן מאחורי חומת תשלום

גישה לתוכן בלעדי כשהאיזון עובר סף מסוים. אימות מחוץ לשרשרת באמצעות חתימת ארנק (token-gating):

// Token-gating middleware
async function checkCreatorTokenAccess(
  walletAddress: string,
  creatorAddress: string,
  requiredBalance: number,
  provider: ethers.Provider
): Promise<boolean> {
  const contract = new ethers.Contract(PLATFORM_ADDRESS, ABI, provider);
  const balance = await contract.sharesBalance(creatorAddress, walletAddress);
  return balance >= requiredBalance;
}

ממשל קהילתי

הצבעה על תוכן. משקל ההצבעה פרופורציונלי לאיזון הטוקנים.

חלוקת הכנסות

חלק מהכנסות היוצר מחולק למחזיקים. דורש איסוף נתונים מחוץ לשרשרת, אורקל או מאמת מהימן, ומחלק מרקל (Merkle distributor).

contract CreatorRevenueDistributor {
    struct Distribution {
        address creator;
        uint256 totalAmount;
        bytes32 merkleRoot;
        uint256 snapshotBlock;
        bool finalized;
    }

    mapping(uint256 => Distribution) public distributions;
    mapping(uint256 => mapping(address => bool)) public claimed;

    function claimRevenue(
        uint256 distributionId,
        uint256 amount,
        bytes32[] calldata proof
    ) external {
        Distribution storage dist = distributions[distributionId];
        require(!claimed[distributionId][msg.sender], "Already claimed");
        bytes32 leaf = keccak256(abi.encodePacked(msg.sender, amount));
        require(MerkleProof.verify(proof, dist.merkleRoot, leaf), "Invalid proof");
        claimed[distributionId][msg.sender] = true;
        payable(msg.sender).transfer(amount);
        emit RevenueClaimed(distributionId, msg.sender, amount);
    }
}

הבטחות כרטיסים

מחזיקי N טוקנים מקבלים גישה מובטחת לאירועים. אימות באמצעות POAP או NFT כרטיס ייעודי.

גרף חברתי וגילוי

פלטפורמת טוקנים ליוצרים אינה רק חוזים. מרכיב מפתח הוא תכונות חברתיות: גילוי יוצרים חדשים, פיד פעילות, לוח מובילים של מחזיקי טוקנים.

אירועי On-Chain כגרף חברתי

כל אירוע contract CreatorTokenBondingCurve { uint256 public constant DIVISOR = 16000; // параметр кривой // Friend.tech formula: цена для N-го токена function getPrice(uint256 supply, uint256 amount) public pure returns (uint256) { uint256 sum1 = supply == 0 ? 0 : (supply - 1) * supply * (2 * (supply - 1) + 1) / 6; uint256 sum2 = (supply + amount - 1) * (supply + amount) * (2 * (supply + amount - 1) + 1) / 6; uint256 summation = sum2 - sum1; return summation * 1 ether / DIVISOR; } function getBuyPrice(address creator, uint256 amount) public view returns (uint256) { return getPrice(sharesSupply[creator], amount); } function getSellPrice(address creator, uint256 amount) public view returns (uint256) { return getPrice(sharesSupply[creator] - amount, amount); } } הוא מידע ציבורי על מי תומך באיזה יוצר. אינדוקס באמצעות The Graph:

type Trade @entity {
  id: ID!
  trader: Bytes!
  subject: Bytes!
  isBuy: Boolean!
  shareAmount: BigInt!
  ethAmount: BigInt!
  timestamp: BigInt!
  blockNumber: BigInt!
}

type Creator @entity {
  id: ID!
  address: Bytes!
  totalSupply: BigInt!
  holders: [Holder!]! @derivedFrom(field: "creator")
  totalTradingVolume: BigInt!
}

מנגנוני הוכחה חברתית

הצגת "החברים שלך מחזיקים בטוקנים של X" היא מנגנון צמיחה חזק. דורש ידע על הגרף החברתי (Twitter/X API, Lens Protocol, Farcaster).

החלטות ארכיטקטוניות Mobile-First

פלטפורמות טוקנים ליוצרים הן כמעט תמיד mobile-first. זה משפיע על הארכיטקטורה:

• ארנק מוטמע: משתמשים לא רוצים להתקין MetaMask. Privy, Dynamic, Magic — SDKs של ארנקים מוטמעים עם התחברות אימייל/רשתות חברתיות. מפתחות מאוחסנים ב-secure enclave או MPC.
• הפשטת גז: משתמשים משלמים ב-ETH אך התהליך חייב להיות שקוף. הפשטת חשבון (EIP-4337) עם paymaster — הפרוטוקול מממן את N העסקאות הראשונות של משתמש חדש.
• רשת Base: Friend.tech בחרה ב-Base — L2 של Coinbase. עמלות נמוכות (מתחת ל-$0.10 לעסקה), אישור מהיר, נזילות טובה, תמיכה מובנית בארנק Coinbase. עקומות קשר על Base זולות ב-20x בגז מאשר ב-Ethereum mainnet.

מהם הסיכונים המרכזיים ואיך לצמצם אותם?

• Rug pull של יוצר: היוצר מחזיק בטוקן הראשון (כניסה זולה), צובר ומוכר בשיא ההייפ של הקהל. צמצומים: תקופת נעילה למניות היוצר, חשיפה פומבית של אחזקות היוצר.
• מסחר פיקטיבי (Wash trading): ניפוח מלאכותי של נפח מסחר. קשה למנוע לחלוטין אבל: תקופת החזקה מינימלית לפני מכירה, מבנה עמלות שהופך מסחר פיקטיבי ללא רווחי.
• כיבוש שמות (Cybersquatting): רישום טוקנים עם שמות של אישים פופולריים לפני שהם עצמם מצטרפים. צמצומים: אימות באמצעות OAuth (Twitter, Instagram), רק חשבונות מאומתים יכולים ליצור טוקנים.

שלבי פיתוח פלטפורמת טוקנים ליוצרים

1. ניתוח ועיצוב כלכלת טוקנים (1–2 שבועות): בחירת מודל עקומת קשר, קביעת עמלות, מנגנוני תועלת.
2. פיתוח חוזים חכמים (4–6 שבועות): עקומת קשר, חלוקת הכנסות, ממשל, מחלק מרקל.
3. בקאנד ואינדקסר (4–6 שבועות): The Graph, API, תכונות חברתיות.
4. אינטגרציית ארנק מוטמע והפשטת חשבון (2–3 שבועות).
5. אפליקציה מובייל (6–10 שבועות): iOS + Android.
6. אונבורדינג יוצרים + KYC (1–2 שבועות).
7. ביקורת חוזים ואימות פורמלי (3–4 שבועות).
8. פריסה, תיעוד ותמיכה.

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

• חוזים חכמים: עקומת קשר, חלוקת הכנסות, ממשל, מחלק מרקל
• בקאנד: אינדקסר (The Graph), API, תכונות חברתיות
• אינטגרציית ארנק מוטמע + הפשטת חשבון
• אפליקציה מובייל (iOS + Android)
• אונבורדינג יוצרים + KYC
• ביקורת חוזים ואימות פורמלי
• תיעוד, פריסה, תמיכה לאחר השקה

לוח זמנים לפיתוח

MVP עם עקומת קשר, token-gating בסיסי ואפליקציה מובייל: 3–4 חודשים. פלטפורמה מלאה עם חלוקת הכנסות, ממשל ותכונות חברתיות מקיפות: 5–7 חודשים.

מקרה בוחן: אופטימיזציה של פרמטרי עקומת קשר

בפרויקט אחרון לפלטפורמת אמנים, כיוונו את מחלק עקומת הקשר כדי להפחית הפסדים כתוצאה ממרווח ב-15% לקונים מוקדמים תוך שמירה על נזילות מספקת. השתמשנו בסימולציה היסטורית עם נתוני התנהגות משתמשים אמיתיים כדי למצוא את ערך uint256 constant PROTOCOL_FEE_PERCENT = 5; // 5% uint256 constant CREATOR_FEE_PERCENT = 5; // 5% function buyShares(address creator, uint256 amount) external payable { uint256 supply = sharesSupply[creator]; require(supply > 0 || creator == msg.sender, "Only creator can buy first share"); uint256 price = getPrice(supply, amount); uint256 protocolFee = price * PROTOCOL_FEE_PERCENT / 100; uint256 creatorFee = price * CREATOR_FEE_PERCENT / 100; require(msg.value >= price + protocolFee + creatorFee, "Insufficient payment"); sharesBalance[creator][msg.sender] += amount; sharesSupply[creator] = supply + amount; emit Trade(msg.sender, creator, true, amount, price, protocolFee, creatorFee, supply + amount); (bool success1,) = protocolFeeDestination.call{value: protocolFee}(""); (bool success2,) = creator.call{value: creatorFee}(""); require(success1 && success2, "Fee transfer failed"); } האופטימלי. התוצאה הייתה דינמיקת מסחר בריאה יותר עם תנודתיות נמוכה יותר ופחות ספייקים ספקולטיביים, מה שהעלה את שיעור שימור המחזיקים הממוצע ב-20% בחודש הראשון.

לצוות שלנו ניסיון של 10+ שנים בפיתוח בלוקצ'יין ו-40+ פרויקטים מוצלחים ב-DeFi, NFTs וטוקנים חברתיים. אנו מבצעים ביקורות חוזים באמצעות Slither, Mythril ו-Echidna, ומבטיחים אבטחה. אנו נעריך את הפרויקט שלך ונציע ארכיטקטורה אופטימלית.

צור קשר כדי להעריך את הפרויקט שלך. קבל ייעוץ בנושא ארכיטקטורה ולוחות זמנים.