As the prediction market meta grows and more protocols launch, this will inevitably lead to fragmentation across markets.

Enter Seer.

Seer is a prediction market aggregator and arbitrage protocol, building a social-first approach with Farcaster integration that lets you discover and buy positions from any supported market and create an avenue for cross-market arbitrage with matched-pair mintable positions.

One interface, many protocols, best price.

In addition to aggregating third-party protocols, Seer will host it's own native markets that utilize a matched-pair system for minting positions, a prediction market primitive that allows for advanced arbitrage and shorting opportunities. The router allows for positions to be opened across Seer, Polymarket, and other integrated protocols to deliver the absolute best execution price.

Why aggregation + arbitrage?

Prediction markets are unique in that one side of each market guarantees a profit. What if you could always be on the winning side of that?

When a spread opens up across markets, an opportunity opens up to take both sides of a trade and mathematically guarantee profit. The Seer router tracks these opportunities and lets users take advantage of them quickly.

Even when these opportunities aren't present, aggregated routing across integrated markets provides users a way to fill at the best odds available.

Continuous arbitrage and routing should also help nudge fragmented markets toward a shared, more accurate probability surface—which improves liquidity, reduces mispricing, and yields better forecasts.

Social-first

Prediction markets are social by nature, participants beliefs are traded on the open market. The initial launch of the Seer app and Farcaster mini-app will allow users to:

• Browse trending markets across Seer, Polymarket, and other integrated protocols.

• See unified odds, depth, and fees.

• Buy/sell through their Farcaster wallet on Base, regardless of the venue's underlying network.

• Share casts with live odds, PnL, and outcome previews.

Router v1

The initial launch of Seer (January 2026) will feature Seer Router v1, providing:

• Best-price execution across Seer-native markets and Polymarket

• Unified portfolio view across all markets

• A shared schema for categories, oracles, and metadata so identical markets across chains/protocols can be recognized and routed

• Public price/route API for cross-market quotes

Market Normalization

Seer ingests markets from Seer-native, Polymarket, and other venues into a canonical schema which maps identical markets across venues (event, outcomes, oracle/resolution, fees, network, etc.) and normalizes quotes to the same basis (probability/price, fee-inclusive).

Best-execution

For buy/sell requests, the router simulates fills across venues using orderbook depth, fees, and bridge costs (for cross-chain venues), selecting the route (or split-route) that yields the best net price and submits transactions accordingly.

1-click Arbitrage

Box arbitrage is a market-neutral trade that buys opposite payoffs on the same event across two venues when their prices sum to less than 1 after all fees. You can purchase the cheaper "YES" on Venue A and the cheaper "NO" on Venue B for the identical market and resolution. One of these payoffs will settle to 1 and the other to 0; therefore, if:

$$total_entry_cost_C = price_yes_A + price_no_B + fees < 1$$

Your payout is exactly 1 and guaranteed profit is locked at entry as 1 - C, independent of the event's outcome.

Users can purchase these opportunities with one-click and hold until resolution for a guaranteed profit. Alternatively, users can monitor the current PnL of the position and cash out at any time.

As the protocol grows, Seer will utilize protocol-held revenue to execute these trades via arbitrage bots, allowing staked $SEER to capture the profit directly.

Matched-pair tokens

Seer-native markets are built from the ground-up to make capturing arbitrage across markets easier. Before a result is known, participants can:

• Buy either side of the market at it's current price, or

• Mint a "matched-pair" by depositing $1 of collateral and receiving 1 YES and 1 NO

Once the event resolves, the winning token redeems for $1 and the losing token for $0. A pair always maps back to $1, but any half of a pair can be sold at market value.

Why would you mint both sides?

To sell one!

Minting creates a fresh inventory of YES/NO so you can sell the side the market currently overvalues. For example, let's say in a given market, NO is trading at $0.55. You can deposit $1, get YES+NO, immediately sell NO for $0.55, and you still hold a YES worth ~$0.45. You just manufactured and sold the expensive side instead of waiting for someone to lend it to you.

This is the equivalent of shorting an outcome.

It also helps keep prices fair. If NO drifts too high, minters sell NO until prices revert, because they can always turn one pair into cash equal to YES price + NO price (which should be ≈ $1 minus fees).

Cross-Venue Arbitrage

Let's use an actual example to showcase how you can perform cross-venue arbitrage on Seer using a "Will ETH hit an all-time high in 2025?" market that exists on both Seer and Polymarket, with identical resolution text and cutoff.

On Polymarket, a YES costs $0.46 and on Seer a NO costs $0.48

1. You chose 1,000 "pairs", for $1000

2. Seer Router computes the effective sum = 0.46 + 0.48 = 0.94 (< 1, a valid arbitrage)

3. Router executes:

   1. Buy 1,000 YES at 0.46 on Polymarket for 460 USDC

   2. Mint 1,000 YES + 1,000 NO by depositing 1,000 USDC on Seer, then immediately selling 1,000 NO into Seer's liquidity at 0.48, receiving 480 USDC

Regardless of the outcome, exactly one of the two claims pays 1,000 USDC, either on Polymarket or Seer.

$SEER token

Seer is being kicked off with the launch of $SEER token on Clanker, which will over time be integrated as a full-fledged protocol and revenue-sharing token. The use-case of $SEER is to:

• Share protocol and arbitrage revenue with stakers

• Incentivize liquidity and alignment across protocols by weighted routing toward high-quality markets, rewarding participation and spread reduction

Once the Seer Router v1 is launched, $SEER holders will be able to stake their tokens in order to split protocol revenue from native markets and captured arbitrage opportunities.

Tokenomics

$SEER token was launched via Clanker on November 19th 2025.

Contract Address: 0x45336c84101C6fceDE30c6316Ea72FDBbd753B07

• Liquidity: 60%

• Dev Allocation: 5% — to be staked in protocol

• Early-adopter reservations: 5% — to be distributed through mini-app

• Treasury: 30% for long-term growth allocations, market incentives, and ecosystem grants. Vaulted tokens vest linearly over 180 days.

Trading fees from Clanker are kept as both $ETH and $SEER to prevent ongoing drawdown on price due to fee-collection.

Trade $SEER on Clanker

Roadmap

Stage 1 - Router v1 - Jan 2026

• Farcaster mini-app to browse, quote and buy across external venues

• Best-execution routing: fee-inclusive quotes, slippage limits, split routes

• Box-Arb MVP - `Yes A + No B < 1`with 1-click spread lock

• Unified portfolio across venues

Stage 2 - Seer-Native Mintable Markets (Q2 2026)

• Launch Seer markets with mintable matched-pairs, AMM, RFQ

• Mirror top external markets 1:1 with mapped resolutions

• Router v2 choses cheapest leg via:

  • Direct buy on Seer

  • Mint-and-sell complement on Seer

  • external venue

• $SEER staking with protocol fee-sharing

Stage 3 - Ecosystem Alignment

• Open APIs for quotes, routes, third-party bots

• Protocol-level arbitrage bots

• Pooled arbitrage vaults: users stake capital to a managed vault that executes micro-arbs with pro-rate PnL sharing

• Governance: $SEER holders tune fees, incentives, grants

Follow Seer

Follow @seerspace and @jonbray.eth on Farcaster for updates.

-- End --

Abstract

Pin.sol is a decentralized protocol designed to incentivize persistent file storage on the InterPlanetary File System (IPFS) through direct ETH payments on EVM networks. By leveraging a decentralized network of storage providers, a fair node rotation queue system, and a reputation-based reward mechanism, Pin.sol ensures reliable file availability and contract-level access to IPFS nodes for increased composability.

IPFS has emerged as a powerful distributed file system, but it lacks native economic incentives to ensure long-term file persistence. When a file is uploaded to IPFS, there's no guarantee it will remain accessible unless someone actively "pins" it to their node. While solutions to IPFS file availability do exist, none of them are directly composable with the Ethereum ecosystem or smart contracts.

Current solutions fall into three categories:

1. Centralized pinning services that create single points of failure and go against the ethos of decentralization

2. Custom blockchain networks like Filecoin and Arweave, which require migration to separate ecosystems

3. Self-hosted infrastructure that is resource-intensive and technically complex

Pin.sol introduces a simple, Ethereum-native solution where IPFS node operators are directly rewarded in ETH for providing reliable pinning services, while users can prioritize their content through market-based mechanisms, all without requiring a separate token economy.

Each participating IPFS node connects an Ethereum wallet and stake ETH as collateral to participate in the protocol. Nodes receive ETH payments for pinning files from users, with smart contracts tracking node participation, staking, and ensuring service delivery through community verification of pinned files.

Participating nodes are placed in a rotation queue to receive pinning assignments. After completing a job, the node moves to the back of the queue to ensure all participating nodes have fair access to earning opportunities. The base ETH cost per file is calculated based on file size and requested duration.

Nodes build reputation based on reliability and service quality which determines the percentage of payment received from pin requests:

• Highest reputation nodes receive 99% of payment

• Lower reputation nodes receive proportionally less (down to 50%)

Remaining percentage goes to the DAO treasury, with the DAO taking a base 1% of protocol revenue.

Pin.sol supports two complementary pricing models:

Users submit pinning requests with required ETH payment based on file size and duration. The protocol automatically assigns files to the next node(s) in the queue based on the specified replication factor.

Users can bypass the queue and pay nodes directly in ETH for long-term pinning, creating a decentralized marketplace where users and nodes negotiate terms. In direct agreements, node reputation does not affect payment percentage.

Funds are held in escrow and are vested linearly for the duration that pinning service is provided for. If a node unpins content prematurely, the remaining escrowed ETH is returned to the payer with 5% of returned funds being awarded to users who report violations, creating community incentives to report bad actors.

Nodes that consistently fail to meet protocol requirements face progressive penalties to reputation and earnings:

First offense: Short-term ban. First offenses do not incur a reputation strike.

Repeated offenses: Increasingly longer ban and reputation hit. The more a node misbehaves, the lower it's reputation gets (down to 50%).

Severe violations: Perma-ban and slashing of staked ETH.

Bans are enforced transparently onchain, and appeals can be made through a decentralized governance process.

Slashed ETH goes to the DAO treasury

Pin.sol creates economic opportunities for Verifiers who maintain network integrity by checking IPFS for content availability promised by nodes and verifying that pinning commitments are being honored.

Verifiers: Reporting nodes that fail to meet obligations Earning ETH rewards (5% of remaining escrow) for maintaining network health

1. Automated Monitoring: Verifiers scan the network, checking actual availability of pinned content

2. Reputation Enforcement: Trigger the protocol's reputation mechanisms for failing nodes

3. Economic Incentives: Earn a percentage of returned funds when reporting violations

This creates a market for developers to build services around Pin.sol, such as IPFS availability monitors, node reputation tracking dashboards, and analytics tools,.

Pin.sol collects fees that go directly to the DAO treasury:

1. Queue-Based Assignments: A percentage of each payment based on node reputation:

   • 1% from highest reputation nodes (99% to node)

   • Up to 50% from lowest reputation nodes (50% to node)

2. Direct Payments: Flat 1% fee on all direct agreements between users and nodes

1. Ethereum Native: Uses ETH directly, no need for token swaps or bridges

2. Fair Distribution: Queue-based system ensures all nodes get opportunities

3. Incentive Alignment: Reputation affects rewards, not job access

4. Low Barrier: Anyone with an IPFS node can participate and earn

5. Transparent: All commitments and payments are visible on-chain

6. Sustainable: DAO treasury ensures long-term protocol development

• Stake-Based Participation: Required ETH staking ensures nodes have skin in the game

• Linear Vesting Model: Payments release over time, aligning incentives for long-term storage

• Community Policing: The 5% bounty for reporting violations creates distributed oversight

• Transparent Queue: Fair job distribution prevents centralization

• Reputation Economics: Better performance leads to higher earnings percentage

• Progressive Banning: Repeat offenders face escalating penalties

• Sustainable Treasury: Protocol fees fund ongoing development and maintenance

Below is an outline of proposed smart contract design for Pin.sol. This code is not tested and should not be used in a production environment.

Structure of an onchain IPFS node

struct Node {
    address payable wallet;   // Wallet address of node operator
    string ipfsPeerId;        // Unique identifier for IPFS node
    uint256 reputation;       // Score representing node reliability (0-100)
    uint256 stakedAmount;     // Total ETH locked as collateral
    uint256 lastActive;       // Timestamp of most recent activity
    bool isActive;            // Whether node is currently eligible for assignments
    uint256 bannedUntil;      // Timestamp when temporary ban expires (0 if not banned)
    uint256 banCount;         // Number of times node has been banned
    uint256 totalEarned;      // Total ETH earned through the protocol
    mapping(bytes32 => bool) activePins;  // Currently pinned content
}

Implementation of the node queue system.

address[] private nodeQueue;
mapping(address => uint256) private nodeQueuePosition;

New nodes register with their peerId by staking ETH and are placed at the end of the queue.

function registerNode(string calldata ipfsPeerId) external payable {
    require(msg.value >= MINIMUM_STAKE, "Insufficient stake");
    require(nodeQueuePosition[msg.sender] == 0, "Already registered");

    nodes[msg.sender] = Node({
        wallet: payable(msg.sender),
        ipfsPeerId: ipfsPeerId,
        reputation: INITIAL_REPUTATION,
        stakedAmount: msg.value,
        lastActive: block.timestamp,
        isActive: true,
        bannedUntil: 0,
        banCount: 0,
        totalEarned: 0
    });

    // Add node to the end of the queue
    nodeQueue.push(msg.sender);
    nodeQueuePosition[msg.sender] = nodeQueue.length;

    emit NodeRegistered(msg.sender, ipfsPeerId, msg.value);
}

Nodes are rotated to the back of the queue after being assigned a pin request.

function _rotateNodeInQueue(address node) internal {
    uint256 pos = nodeQueuePosition[node];
    require(pos > 0, "Node not in queue");

    // Remove node from current position
    for (uint i = pos; i < nodeQueue.length; i++) {
        nodeQueue[i-1] = nodeQueue[i];
        nodeQueuePosition[nodeQueue[i]] = i;
    }

    // Put node at end of queue
    nodeQueue[nodeQueue.length - 1] = node;
    nodeQueuePosition[node] = nodeQueue.length;
}

Contract gets the next available nodes from the queue

function _getNextAvailableNodes(uint8 count) internal view returns (address[] memory) {
    address[] memory availableNodes = new address[](count);
    uint256 found = 0;

    for (uint i = 0; i < nodeQueue.length && found < count; i++) {
        address nodeAddr = nodeQueue[i];
        if (nodes[nodeAddr].isActive && nodes[nodeAddr].bannedUntil < block.timestamp) {
            availableNodes[found] = nodeAddr;
            found++;
        }
    }

    require(found == count, "Not enough available nodes");
    return availableNodes;
}

Structure of an onchain pin request

struct PinRequest {
    bytes32 cid;                 // Content Identifier (CID) of file
    address payable user;        // Address of requestor
    uint256 duration;            // Time period (in seconds) for pinning
    uint256 fileSize;            // Size of file in bytes
    uint256 payment;             // Total ETH payment
    uint256 createdAt;           // Timestamp when request was submitted
    bool fulfilled;              // Whether request has been assigned to nodes
    uint8 replicationFactor;     // Number of nodes to pin the content
}

The price of a pin request is determined based on file size and duration the pin is requested for. DAO fees can be updated by governance proposals but is initialized at 1%.

function calculateBasePrice(uint256 fileSize, uint256 duration) public pure returns (uint256) {
    // Example pricing formula
    // Base price = (fileSize in MB * 0.0001 ETH) * (duration in days / 30)
    uint256 fileSizeInMB = fileSize / (1024 * 1024);
    uint256 durationInDays = duration / 86400;

    return (fileSizeInMB * 1e14 * durationInDays) / 30;
}

Pin requests are submitted with a replicationFactor that determines how many nodes should pin the file. Payment cost is (fileSize * duration) * replicationFactor and paid at the time of submission, after which the payment is split between the number of participating nodes and their respective fees (modified by reputation) are vested to them.

function submitPinRequest(
    bytes32 cid,
    uint256 fileSize,
    uint256 duration,
    uint8 replicationFactor
) external payable {
    // Calculate minimum required payment
    uint256 basePrice = calculateBasePrice(fileSize, duration);
    uint256 totalPrice = basePrice * replicationFactor;

    require(msg.value >= totalPrice, "Insufficient payment");
    require(duration >= MIN_DURATION, "Duration too short");
    require(replicationFactor > 0, "Must request at least one node");

    uint256 requestId = _nextRequestId++;

    pinRequests[requestId] = PinRequest({
        cid: cid,
        user: payable(msg.sender),
        duration: duration,
        fileSize: fileSize,
        payment: msg.value,
        createdAt: block.timestamp,
        fulfilled: false,
        replicationFactor: replicationFactor
    });

    // Process the request immediately
    _processRequest(requestId);

    emit PinRequestSubmitted(requestId, cid, msg.sender, msg.value, duration);
}

Structure of successful pin assignment to a node.

struct PinAssignment {
    bytes32 cid;            // CID of pinned file
    address node;           // Address of assigned node
    address payable user;   // User who requested the pinning
    uint256 startTime;      // When pinning began
    uint256 endTime;        // When pinning should end
    uint256 totalPayment;   // Total ETH allocated for this assignment
    uint256 claimedAmount;  // ETH already claimed through vesting
    bool active;            // Whether assignment is currently active
}

Payment percentage is calculated based on node reputation. At max reputation (100) a node receives 99% of fees. At 0 reputation, a node gets 50% of the fees, with a linear scale between. Nodes with 0 reputation who receive another strike are banned from participation.

function _calculatePaymentPercentage(uint256 reputation) internal pure returns (uint256) {
    uint256 basePercentage = 50;
    // Multiply reputation (0-100) by 49 (difference between min & max payment received) to get the variable portion
    uint256 variablePercentage = (reputation * 49) / 100;

    return basePercentage + variablePercentage;
}

Requests are processed from the queue, selecting next available nodes and processing their reputation-based payment into a linear vesting schedule.

function _processRequest(uint256 requestId) internal {
    PinRequest storage request = pinRequests[requestId];
    require(!request.fulfilled, "Request already fulfilled");

    // Get the next available nodes
    address[] memory selectedNodes = _getNextAvailableNodes(request.replicationFactor);

    uint256 paymentPerNode = request.payment / request.replicationFactor;
    uint256 daoFee = 0;

    for (uint i = 0; i < selectedNodes.length; i++) {
        address node = selectedNodes[i];

        // Calculate node's payment based on reputation
        uint256 paymentPercentage = _calculatePaymentPercentage(nodes[node].reputation);
        uint256 nodePayment = (paymentPerNode * paymentPercentage) / 100;

        // Track DAO fee (remainder)
        daoFee += paymentPerNode - nodePayment;

        // Create assignment with vesting schedule
        uint256 assignmentId = _nextAssignmentId++;

        pinAssignments[assignmentId] = PinAssignment({
            cid: request.cid,
            node: node,
            user: request.user,
            startTime: block.timestamp,
            endTime: block.timestamp + request.duration,
            totalPayment: nodePayment,
            claimedAmount: 0,
            active: true
        });

        // Update node's active pins
        nodes[node].activePins[request.cid] = true;

        // Rotate node to back of queue
        _rotateNodeInQueue(node);

        emit PinAssigned(assignmentId, request.cid, node, nodePayment, request.duration);
    }

    // Send DAO fee to treasury
    if (daoFee > 0) {
        (bool success, ) = daoTreasury.call{value: daoFee}("");
        require(success, "DAO fee transfer failed");
        emit DAOFeeCollected(requestId, daoFee);
    }

    request.fulfilled = true;
}

In addition to the queue system, users can select and pay a node directly.

struct DirectPayment {
    bytes32 cid;                // Content Identifier
    address payable node;       // Node providing service
    address payable user;       // User paying for service
    uint256 amount;             // Total ETH paid to node
    // DAO fee initialized at 1% but can be modified by governance proposals
    uint256 daoFee;             // Fee collected by DAO
    uint256 startTime;          // When agreement began
    uint256 endTime;            // When service should end
    uint256 claimedAmount;      // ETH already claimed
    bool active;                // Current status
}

Direct payments are negotiated between both parties and bypasses reputation, meaning that nodes paid directly receive the full fee (minus DAO percentage).

function payNodeDirectly(
    address payable node,
    bytes32 cid,
    uint256 duration
) external payable {
    require(msg.value > 0, "Payment required");
    require(nodes[node].isActive, "Node not active");
    require(nodes[node].bannedUntil < block.timestamp, "Node is banned");

    // Calculate basis points for DAO fee (100 = 1%)
    uint256 daoFee = (msg.value * daoFeePercentage) / 10000;
    uint256 nodePayment = msg.value - daoFee;

    uint256 paymentId = _nextDirectPaymentId++;

    directPayments[paymentId] = DirectPayment({
        cid: cid,
        node: node,
        user: payable(msg.sender),
        amount: nodePayment,
        daoFee: daoFee,
        startTime: block.timestamp,
        endTime: block.timestamp + duration,
        claimedAmount: 0,
        active: true
    });

    // Update node's active pins
    nodes[node].activePins[cid] = true;

    // Send DAO fee
    (bool success, ) = daoTreasury.call{value: daoFee}("");
    require(success, "DAO fee transfer failed");

    emit DirectPaymentCreated(paymentId, cid, node, msg.sender, nodePayment, daoFee, duration);
}

At any time during an active assignment, a node can claim the ETH currently being vested to them.

function claimVestedPayment(uint256 assignmentId) external {
    PinAssignment storage assignment = pinAssignments[assignmentId];

    require(msg.sender == assignment.node, "Not authorized");
    require(assignment.active, "Assignment not active");

    // Calculate vested amount
    uint256 totalDuration = assignment.endTime - assignment.startTime;
    uint256 elapsed = block.timestamp - assignment.startTime;

    uint256 vestedAmount;
    if (block.timestamp >= assignment.endTime) {
        vestedAmount = assignment.totalPayment;
    } else {
        vestedAmount = (assignment.totalPayment * elapsed) / totalDuration;
    }

    uint256 claimableAmount = vestedAmount - assignment.claimedAmount;
    require(claimableAmount > 0, "No funds to claim");

    // Update claimed amount
    assignment.claimedAmount += claimableAmount;

    // Transfer ETH to node
    (bool success, ) = assignment.node.call{value: claimableAmount}("");
    require(success, "Transfer failed");

    // Update node's total earned
    nodes[assignment.node].totalEarned += claimableAmount;

    emit PaymentClaimed(assignmentId, assignment.node, claimableAmount);
}

If a node is found to have prematurely unpinned an item, or is offline long enough for IPFS garbage collection to remove the pin, verifiers can report them to the protocol.

NOTE: The verification procedure needs a lot of work to ensure that it's reliable and doesn't maliciously target nodes who are behaving.

function reportUnpinnedContent(bytes32 cid, address node, uint256 assignmentId) external {
    PinAssignment storage assignment = pinAssignments[assignmentId];

    require(assignment.cid == cid, "CID mismatch");
    require(assignment.node == node, "Node mismatch");
    require(assignment.active, "Assignment not active");

    // Verification logic to confirm content is indeed not pinned
    bool contentUnpinned = _verifyContentIsUnpinned(cid, node);
    require(contentUnpinned, "Content is still pinned");

    // Calculate remaining payment
    uint256 remainingFunds = assignment.totalPayment - assignment.claimedAmount;

    if (remainingFunds > 0) {
        // Return 95% to user
        uint256 userRefund = (remainingFunds * 95) / 100;
        (bool successUser, ) = assignment.user.call{value: userRefund}("");
        require(successUser, "User refund failed");

        // Award 5% to reporter
        uint256 reporterReward = remainingFunds - userRefund;
        (bool successReporter, ) = payable(msg.sender).call{value: reporterReward}("");
        require(successReporter, "Reporter reward failed");

        emit SlashingExecuted(assignmentId, node, userRefund, msg.sender, reporterReward);
    }

    // Mark assignment as inactive
    assignment.active = false;

    // Remove from node's active pins
    nodes[node].activePins[cid] = false;

    // Decrease node reputation
    _decreaseReputation(node, SLASHING_REPUTATION_PENALTY);

    // Check if ban is warranted
    _evaluateBanning(node);
}

Ideally, verifiers would interact with reputation-altering functions through an oracle or other interface that can atomically check IPFS pin status against contract storage. For the actual implementation, this would check IPFS network.

function _verifyContentIsUnpinned(bytes32 cid, address node) internal returns (bool) {
    //
    // Returns true if content is confirmed to be unpinned
    //
    return true;
}

As with any novel application there are a number of challenges and additional considerations that will need to be worked on as Pin.sol is developed. Some of these will have to be addressed before a mainnet launch, while others can be addressed later through community proposals.

You can find a non-exhaustive list of development challenges and considerations here.

This document outlines the vision for Pin.sol, an ETH-based decentralized storage incentivization layer for IPFS. The protocol leverages Ethereum's security, liquidity, and composability to create reliable distributed storage with fair access for all participating nodes.

By providing direct economic incentives for IPFS pinning through a balanced queue system, Pin.sol helps bridge the gap between decentralized storage technology and practical applications that require persistence guarantees.

If you have any questions, open an issue or discussio thread, or reach out on Warpcast.

The People v. Vitalik

Over the last few days, a debate has been brewing on Crypto Twitter (CT) between supporters of Vitalik and The Ethereum Foundation (EF) and supporters of DeFi products and founders. The former suggesting that Vitalik and EF harbor anti-DeFi sentiments and are actively holding back the growth of the sector. One outspoken critic is Kain—founder of Synthetix and a pioneer in yield farming—who has expressed concern with a lack of initiative and discouragement from Vitalik. People are either accusing Vitalik of being a DeFi bear or blindly agreeing with his every word.

As with most things on CT, the real facts are probably somewhere in the middle and both parties can have the best interest of DeFi in mind even though they don't agree.

Let's break it down.

Vitalik has been generally bullish on the DeFi space, especially in the early days when new contract designs were being introduced that allowed liquidity to be supported onchain. You can check out some of his videos discussions here. Despite showing support for many of the advances and experiments over the years, he's taken some flak in the recent weeks for his stance on way that DeFi has been growing (or not growing).

His most recent take is that DeFi has been stagnant and has fallen victim to the same type of get rich quick mentality that has plagued much of crypto this cycle. He has actively advocated for building simple yet robust DeFi products rather than products who's only selling point are crazy APYs and rely on extractive or dilutive mechanics like emissions to achieve these high purported returns.

His suggestion is that for DeFi to thrive, we need to switch our focus to utility-based products like stablecoins, fractionalized RWAs, and commodities exchanges. He believes that things like fractional ownership can help retail investors enter the real estate market without being overly leveraged in one asset type, making DeFi globally accessible to everyone.

In August, Kain wrote a tweet hinting that EF and Vitalik were not being supportive of DeFi. He elaborated on his stance on the "Steady Lads" podcast (link here), where he stated that while he respects Vitalik, he disagrees with his stance on DeFi.

Kain mentioned that Vitalik and his "inner cabal" at EF have openly discouraged founders from building DeFi products during meetings, and that established and important protocols like Aave are not part of this "cabal" and therefore don't receive the type of support that Maker and Uniswap receive.

Despite this, Kain and others in the discussion believes that Ethereum is still an ideal ecosystem compared to other chains and remains bullish on the network.

Personally I'm all for experimenting and trying new things in DeFi, but if the entire world is going to come onchain DeFi needs to have better infrastructure that can not only bring finance onchain but provide a better option than legacy systems.

Simply having a means to swap tokens (traditional LPs) and provide collateral for highly-liquid pairs (Aave, lending pools) is not enough. Likewise, putting yield farms that use token emissions and rely mostly on trading revenue and ponzinomics isn't a good look for the space either. As usual, the right path is somewhere in the middle.

It's impossible to say what concepts will eventually make an impact on the average user. We've already seen yield farming concepts bleed over into other spaces on Farcaster where apps like Alfafrens have social networks on top of yield-farming paradigms.

I understand completely the frustration from both Kain and Vitalik/EF. Simply dismissing the current state of DeFi or not providing backing for products that have propped up your network simply because they don't fit the average person's risk model is bad for business. Ignoring the fact that the current state of DeFi looks more like a casino or a carnival to outside observers is also foolish.

If we don't align DeFi with the needs of the broader financial ecosystem, someone else will, and I guarantee they won't care about decentralization and permissionless systems.

The discussion between CT and Vitalik has brought up several elephants in the room:

• Who is really paying for insanely high yields?

  This has been a longstanding concern in DeFi, as the APY numbers you see on yield platforms are generally a derivative with respect to a very specific set of circumstances (i.e. the current function remaining unchanged over a year) or padded with emissions in some native protocol token. Instead of creating novel sources of real yield, many tokens are only valuable as a yield-bearing instrument when they are actively traded, which has (as Vitalik put it) created an ouroboros effect downstreaming the ETH market.

• The role of centralized entities in DeFi

  For better or worse, centralized entities play a significant role in the current landscape. Whether it's oracles for price calculations or multi-sig wallets as contract owners, most successful protocols have a some centralized aspect while truly decentralized protocols have struggled to maintain the same level of market dominance. While fully decentralized and permissionless systems are ideal for many things, having a period of time where a centralized entity slowly cedes control to decentralized consensus can be beneficial.

• Lack of innovation in DeFi

  Groundbreaking innovation has been relatively stagnant in DeFi recently. With a lot of newcomers to the space who weren't here in previous cycles, why build something novel that takes time when you can recycle the same tricks from previous cycles on a new audience?

  While that is not entirely true, many protocols are just outright forks or slight variations on existing concepts, making little difference in the overall growth of DeFi.

As a builder in the DeFi space, these are things I'm thinking about all the time. So to see discussion popping up on CT specific to DeFi after so many years of building quietly in the background is exciting, even if it's causing debate. I've been building onchain for a decade now, an while I don't completely agree with either side, I do think that DeFi is still one of the most important use-cases for crypto.

Being able to have your assets on a permissionless network, available any time, anywhere, is powerful. That's freedom.

But DeFi needs direction if we're going to make an impact on billions of people.

This is a huge part of the motivation behind what we're building at Xeon Protocol, which aims to address some of these big questions. We need more primitives that protocols can build on top of. Risk-management should be engrained in DeFi and utilized as needed for any app or asset.

As I said previously, it's impossible to predict what specific advancement is going to take hold, which is why Xeon takes a token-agnostic approach to our products. Whether it's a stablecoin, NFT, yield-bearing token, or RWA you should be able to unlock it's underlying liquidity and make it composable in the broader DeFi space. Hedging allows you to mitigate risk without immediately realizing gains or losses, and make ad-hoc deals with other users to spread out your exposure.

You shouldn't need permission to do this, they are your assets. As DeFi builders, we should prioritize giving people as much freedom to interact with the broader ecosystem as possible.

Having contracts that facilitate OTC transactions between users, allowing them to adjust terms based on their personal risk tolerance with little restriction is important for new asset classes coming onchain.

We're trying to minimize the role of centralized entities by having as much as possible done on the protocol level. While we've written a framework for P2P DeFi deals, users are fully empowered to set trade conditions. Our options are self-contained tokens themselves, containing all of the terms, tokens, collateral, and settlement data required for users to adjust as they please.

Protocol revenue is handled through a multi-chain staking pool and returned to stakers as ETH, with as little liquidity left unused as possible. Participants can choose what networks and assets they want exposure to.

Our price oracle is another place we've tried to eliminate centralized points of failure. This has posed some challenges, but we've settled on a mix of centralized and decentralized solutions to create what I feel is the most robust onchain price oracle out there.

For large and well-known pairs, our oracle queries ChainLink's onchain price feeds, providing a quick reference for well-known, highly liquid pairs. This is important for assets that have a substantial amount of liquidity in exchanges.

All other pair data can be found through their onchain LPs, where our oracle searches first to find the most liquid pool between any two tokens across v2 and all v3 fee-tiers, and then returns both price data and the value of one token in terms of any other token.

This will allow Xeon users to more accurately price tokens in OTC deals, and provide a robust oracle for any other protocol that needs onchain access to price data.

I'm extremely bullish on DeFi, especially in the Ethereum and L2 ecosystem. The promise of Ethereum as a decentralized and permissionless network for the world is as powerful a narrative as ever.

Regardless of the current sentiment, we need to innovate while still addressing current concerns in the space to make DeFi more accessible to everyone. The only way forward is to listen to constructive criticism from people with skin in the game, use that feedback to improve, and keep building!

No matter who enters the DeFi space, or what type of assets everyone is talking about, Xeon is going to be there with solutions for both retail and institutional investors to plug any type of token they want into DeFi.

We appreciate the support from the community and encourage users to try our products. We're in the final month of testnet, so your feedback on our app and codebase is very likely to make a difference in what we're building as we pave the road to mainnet deployment on Ethereum and beyond.

Cheers,

Jon

Introduction

The crypto space is rapidly evolving, and for most of the cycle so far, decentralized finance (DeFi) has taken a backseat to memecoins and other non-utility projects. Projects like these that generally feature fly-by-night devs require different trust assumptions than more robust projects building in the space, many of which are manifest in the tokenomics.

In the current market, certain things have become synonymous with a "safe" project such as burning the liquidity pool (LP), renouncing the contract, and teams holding a negligible portion of tokens. The reality is much more complicated. While these things may be fine for memecoins, for a project like Xeon Protocol that is building long-term utility, these things simply do not work.

Since many new entrants to the space have only been exposed to non-utility tokens, this post will serve not only to breakdown the Xeon Protocol tokenomics and vesting schedule, but to educate people on why we've made these decisions. It is our duty as a DeFi project focused on risk-management to be upfront and transparent so all stakeholders can make informed decisions.

As a protocol utility token, XEON plays an important role in the Xeon ecosystem. It will initially be used to bootstrap our incentivized testnet, and will be utilized in our advanced staking pools that help secure the protocol and distribute yield to participants. These protocol-level requirements played an important role in our distribution of tokens, specifically our linear vesting schedule which was designed to complete prior to the mainnet launch of Xeon Staking so that tokens could be used for their ultimate purpose: being put to work inside the protocol!

The XEON token generation event (TGE) took place on June 24th, 2024 at block 20161704 on the Ethereum network. The full supply of XEON tokens was minted with a total supply of 100 million and 5 ETH was supplied to the LP . The token was launched through our incubator—PROOF Platform, which is the reason certain functions like whitelist are present in the contract.

The supply of XEON was initially distributed as follows:

• Liquidity: 70% (70m tokens) locked in a Team Finance token locker for 60 days by PROOF Platform.

• Ecosystem Growth: 18.5% (18.5m tokens) vested linearly for 60 days through Sablier to a 2/3 multi-sig wallet controlled by core team members.

• Team Tokens: 5% (5m tokens) vested linearly for 60 days through Sablier in individual streams to core team members.

• Marketing: 5.5% (5m tokens) with 3m tokens paid to our marketing manager, 2.5m to KOLs. Of the KOL allocation, 0.2m was paid upfront, and 0.3m tokens vested linearly for 60 days through Sablier.

• Incubator Fees: 1% (1m tokens) paid out to PROOF Platform.

Both the XEON token and all Xeon operations (token administrative functions, protocol contracts, and treasury management) are owned and controlled by a Safe multi-sig wallet which is managed by the three core team members. All transactions must be approved by 2/3 of the team, which ensures that no single person can alter any part of the token or protocol, either accidentally or maliciously.

We have taken great care to ensure that our wallet security is impeccable. The three wallets that control the Safe account are all managed securely to ensure that access to our multi-sig cannot be compromised. Each one belongs to an individual team member and private keys are securely stored in hardware wallets or accessed through sandboxed environments. These wallets are strictly for Xeon Protocol management and are only connected to dApps that fall within company procedures (ex: Safe, Sablier, or ENS).

Even in the unlikely event that a single team member's wallet is compromised, requiring 2-of-3 signatures allows us to quickly replace the affected wallet without compromising the security of the entire protocol. At the time of writing we are exploring procedures for Self Custodial Recovery to safeguard against a worst-case scenario.

Using a multi-sig wallet prevents a single point-of-failure and ensures the entire team has a say in all onchain transactions.

The XEON token has a number of administrative functions that require active management and make it so we cannot simply renounce the contract:

• Tax Revenue: Xeon Protocol is funded by a 5% tax on both buys and sells through LP. This is standard for the industry and allows us to continuously fund protocol growth without requiring us to dump our XEON holdings. Revenue is dispersed through a Splits contract where it's divided between ecosystem and marketing.

• Max Transaction Amount: In order to prevent large sums of tokens from being moved at once we have a limit on the amount of tokens that can be included in a single transaction which is currently set to 500k XEON (0.5% of the total supply).

• Max Wallet Amount: To prevent whale activity in the early growth stage of XEON, there is also a limit on the amount of tokens a single wallet can hold, which is currently set to 1m XEON (1% of the supply).

Certain addresses that are necessary for protocol operation are excluded, including protocol multi-sig wallets, our Uniswap Pool, LP Lock, and vesting contract. None of the token administrative functions have or will ever be used to give anyone an unfair advantage. Even as the CTO of Xeon Protocol, I pay the tax and am restricted by the transaction limit like everyone else.

By retaining ownership of the XEON token contract we can adjust parameters as needed to best fit the needs of the protocol and community.

When we launched XEON, our LP was locked for 60-days, a timeframe that was part of our launch through PROOF Platform. After the lock period finishes, the LP will be released to our team multi-sig wallet, at which point we will determine the most secure way to protect our LP in a manner that still allows it to create the most value for all stakeholders. When that time comes we will keep the community informed on our decision-making process and reasoning.

"Dev, why isn't the LP burned?"

This is a question that comes up a lot. At some point in the last year, with the rise of memecoins, burning the LP (sending the token or ownership to the zero address) became synonymous with "safe" but the reality is much more complicated.

There are many ways to secure liquidity without burning it, and new advances in LP management are coming out all the time. Our LP is not burned as this removes any possibility that the supplied tokens and ETH can be used in potentially innovative ways in the future. Burning renders all the value in that LP useless for anything aside from swapping between two specific tokens.

Soon we will see new types of primitives in the LP space (like v4 hooks and yield instruments) which will require liquidity controlled by new contracts. Projects who currently have their LP burned will be unable to fully utilize these things.

We have positioned Xeon to always be at the cutting edge of new developments in the DeFi space, and we will communicate any decisions regarding potential future liquidity updates with the community. In the meantime, we will continue to utilize best-practices and established, audited contracts to secure our LP.

Burning the LP prevents us from taking advantage of future advances in liquidity management and makes it so we cannot adjust important functions to adapt to changing market conditions.

Out of the 100m supply of XEON tokens, 23.8% (23.8m) are currently vesting over a 60-day period through a linear stream on Sablier. The following tokens are currently vesting:

• 18.5m tokens to Xeon ecosystem wallet

• 5m to individual core team member wallets

• 300k to pre-launch marketing partner's wallet

Sablier is a respected name in DeFi with a track record that dates back to 2019, much longer than most token management solutions currently being used. They have processed over $1.5b USD in volume, are trusted by many DAOs and onchain organizations, and their contracts are fully audited by six leading security firms. Sablier is completely permissionless, they do not use upgradeable proxies for their vesting streams, and their team has zero ability to interfere with the token locks or vesting schedules.

As a DeFi protocol focused on risk-management, Sablier was the obvious choice for distributing our tokens.

"Dev, why vest and not lock?"

To begin with, vesting prevents a large amount of tokens from becoming immediately liquid since the tokens are streamed in real-time to the recipients. For our ecosystem token allocation, this allows us to have access to a steady stream of XEON that can be used to reward participants in our incentivized testnet campaign which is starting soon.

Secondly, vesting can help assuage investor concern over market dumping or price volatility that usually accompanies a large portion of tokens unlocking at once. If, as an investor, you are concerned about a paper-handed team, insuring that no one receives a lump sum of tokens that could potentially be dumped on the market is preferable.

"Dev, why 60-days?"

The vesting schedule is heavily influenced by our roadmap and the release of our testnet campaign and Xeon Staking pools. By having team tokens unlock slowly over the next 60 days, we as the core team can utilize our tokens in protocol staking as soon as it is released. As stated before, XEON is a utility token who's ultimate purpose is to be put to work within the protocol. We are extremely proud of what we are building, and having our tokens ready for the launch of staking means we get to bet on the protocol long-term from the start.

XEON is meant to be staked and put to work inside of the protocol!

Xeon Protocol is all about risk-management, and that extends beyond our protocol services to the way we do everything. Because of the trust assumptions that investors have to place on us, our team is fully KYC'd through Assure DeFi. We are active members of our community and people know how to reach us. We believe the best way to build is to build in public, both so the community is up-to-date with development progress and to hold ourselves accountable to the high standard we set for Xeon Protocol.

I've personally been involved with the crypto community since 2014 and know that the most valuable asset in this space is your reputation. That's why I want every part of the Xeon stack to be as open and transparent as possible.

We have our entire organization tree onchain through Hats Protocol which includes our team, pointers to all deployed contracts and wallets, and allows us to set up secure, programmable roles for things like publishing code or casting on behalf of Xeon Protocol on Farcaster.

By using onchain management for credentials, we can eliminate certain risks to the community like our social media account being compromised.

To make it easier for the community to audit what we as the core team do, and to prevent phishing attempts on our community we are using Ethereum Name Service (ENS) to resolve all of our onchain addresses so users can be 100% sure they are interacting with official Xeon assets.

Multi-Sig Addresses

Core Team (Multi-Sig Signers)

Deployed Contracts

By having human-readable names for all of our onchain assets, community members can simply type any of our ENS into Etherscan and immediately find the associated contract. You can also verify our socials and contact info through our ENS profile.

Using ENS also provides an extra layer of protection for us doing internal transactions, removing any uncertainty that comes with entering a hex address when we're moving funds or assigning admin roles.

ENS can be used to verify contracts and addresses you're interacting with.

We have such an incredible community that has formed around Xeon Protocol, and are excited to see it grow as we release innovative new DeFi products. Thank you all for your trust as we go on this journey, we would not be here without you.

As we get closer to our testnet and mainnet protocol launch, we will make a public Trello board available to the community so they can follow along with progress and give us feedback along the way. You can find an up-to-date list of all official Xeon links on our Linktree.

We are looking forward to a bright future for Xeon and DeFi.

Jon
CTO - Xeon Protocol

Website: https://xeon-protocol.io/
GitBook: https://docs.xeon-protocol.io/documentation
Warpcast: https://warpcast.com/xeonprotocol
Twitter: https://x.com/XeonProtocol
Telegram: https://t.me/XeonProtocolPortal
Medium: https://medium.com/@xeonprotocol

It's self-custody all the way, baby.

Understandably, people have some concerns. Privacy, the potential for exploitation, and the ethics surrounding commodifying our social interactions to begin with. These concerns will always be present on any platform where you put yourself out there to the world and it's something that we need to vigilantly discuss and improve as we build new social platforms.

While I can understand the view that commodification of the social graph is a reduction of human value to market metrics, I think these platforms represent the logical extension of the value creators provide to their communities.

Friend.Tech—and any other market where shares of your time are traded—do not inherently devalue an individual's worth; rather, they offer a marketplace where demand for a creator's time can be quantified, and their intrinsic value can be reflected in that market. The value is initially provided by the creator, which in turn drives demand. To call it predatory takes agency away from the people who engage by choice. The fact is, if you aren't offering something of value, you shouldn't expect to monetize successfully. While not necessarily optimal, Friend.Tech provides one way to do this.

Arguing that putting a price on your social graph harms the creator-audience relationship overlooks the foundations of the pre-existing relationship. These platforms presuppose an existing market for a creator's time, built upon the relationship cultivated through other free-to-access platforms like Twitter or Farcaster. Emerging markets for our social graphs aren't distracting from these relationships. They are adding a new dimension.

Creators can monetize their time without taking anything away from the value of free interactions elsewhere. If a creator decided to exclusively interact on a monetized platform, it's then up to the audience to determine if they wish to follow.

The emergence of a market around individuals who brings significant value to the table is not just compelling and logical, it's fair. It's part meritocracy, and part free-market. Those who excel should rightfully be able to earn from their contributions.

You can argue that a transactional relationship between creators and their audiences is damaging, I think it's an oversimplification. Monetization platforms create a consensual market around a social graph, potentially benefiting all parties involved. New entrants can access time with creators, who in turn receive compensation, alongside speculative market participants who are trading shares of the graph like any other commodity.

That last part is a brand new phenomenon, and I can understand why traders arbitraging a person's time sits wrong with some people.

Is it morally right? I have no idea.

The fact that arbitrageurs exist in these markets has little bearing on the morality of the platform as a whole. It allows traders to speculate on the future value of the creator's graph while providing additional value to creators through trading fees. How the creator chooses to give this added value back to their audience, if at all, is up to the creator. The morality of this decision is up to the specific audience.

While this trading can raise entry costs for new demand, that only holds a mirror to the inherent risk-return present in any scenario. New entrants will always have to weigh the value that a creator is providing on a platform with the cost of entry. Everything has an opportunity cost.

Certainly I would have done things differently if I created Friend.Tech. Trading fees from key-sellers would be split amongst key-holders as well as the creator. Creators would have more control over the bonding curve and types of connections they offer. There are a lot of ways to improve the platform, but you have to start somewhere. This is a complex topic that we're only just beginning to discuss. It brings up issues of value, demand, and equity.

Some people will argue that you simply cannot put a price on human connection.

I say: the market is always right.