DEV Community: Version 6 LLC

Web3 Creator Monetization Beyond NFTs: The Feeder Primitive

Version 6 LLC — Sun, 26 Apr 2026 04:58:41 +0000

The promise of blockchain-based creator monetization has long been touted as a paradigm shift—a direct connection between creators and their audience, bypassing traditional intermediaries and their revenue splits. Yet for all the initial excitement around NFT royalties and token-gated content, the reality has been more nuanced. NFT markets have proven volatile, creator royalties have become optional rather than enforced, and the "community" tokens that were supposed to align incentives have largely served speculative rather than productive purposes.

Immute takes a different approach. Rather than relying on speculative demand to generate creator revenue, Immute is designed as a product-powered reward token—a system where real economic activity flowing through the Feeder primitive generates consistent, measurable value for every IMT holder. This is creator monetization web3 that works because it's tied to actual usage, not just holding.

The Bonding Curve Foundation

At its core, IMT operates on a bonding curve contract deployed on Sepolia testnet. Every buy and sell transaction executes a 10% fee that gets distributed pro-rata across all current holders. There's no team allocation, no VC round, and no pre-mined supply waiting to be dumped on the market. The economics are transparent and on-chain from day one.

This structure means that as usage grows, the dividend stream for holders grows proportionally. But the critical insight is that usage doesn't come from speculation—it comes from the Feeder.

The Feeder Primitive: A Technical Overview

The Feeder is a smart contract interface that allows external products to route payments through Immute's economics. When a creator receives a payment through any Feeder-integrated platform, the transaction splits automatically: 1% flows through the bonding curve (paying dividends to all IMT holders), while 99% goes directly to the creator or the integrating product's treasury.

The integration surface is deliberately minimal. A developer needs a single function call:

Feeder(feederAddress).feed{value: amount}(recipient, metadata); This one call handles the payment routing, the on-curve purchase that generates holder dividends, and the treasury distribution. For a platform like NepTime.io, where viewers donate IMT to creators on uploaded videos, this means the creator receives their funds immediately while the 1% on-curve purchase happens automatically in the same transaction. Every holder benefits from the activity without any additional action required.

Why 1% Matters More Than It Sounds

A 1% on-curve purchase might seem trivial, but consider the mechanics. When that 1% hits the bonding curve, it triggers the same 10% distribution mechanism that applies to all trades. So if a creator receives 99 ETH through the Feeder, the 1 ETH that goes on-curve generates a dividend that's distributed across the entire holder base. The more activity flowing through integrated products, the more consistent the dividend stream becomes.

This is fundamentally different from ad-share models. When you monetize through YouTube or Twitch, the platform takes a substantial cut—typically 45-55%—and the remaining revenue is based on engagement metrics that creators don't directly control. With Immute's Feeder model, creators retain 99% of every payment. The on-curve 1% isn't a fee taken from creators—it's a small percentage that flows to all holders, which could include the creators themselves if they choose to hold IMT.

Integration Landscape

Several platforms are building with the Feeder primitive in mind:

NepTime.io focuses on creator-monetization web3 for video content. The platform allows viewers to donate or transfer IMT directly to creators, with every transaction routing through the Feeder. The 10% fee that flows to all holders applies to these creator payments, creating a sustainable economic loop.

Valiep.com and Discovire.com are building subscription and discovery-layer purchase flows through the Feeder. Both platforms route payments through the same primitive, meaning consistent on-curve activity regardless of the specific use case—whether it's a monthly subscription or a discovery-based purchase.

ByteOdyssey represents the gaming angle: in-game payments and purchases routed through the Feeder. As players spend IMT within the game ecosystem, the 1% on-curve activity generates dividends for holders, including potentially the game developers themselves if they participate in the token economy.

The architectural pattern is consistent across all integrations: the Feeder contract handles the complexity of the on-curve mechanics, while integrating products focus on their core value proposition.

The Testnet Phase

Immute is currently live on Sepolia testnet, which means developers can experiment with Feeder integrations using free testnet ETH. This validation phase serves a critical function: the contracts are live, the mechanics are operational, and the economics can be tested in a real environment before mainnet launch.

For developers interested in building with the Feeder, this is the time to test. The IMT V8 contract and FeederV9 are deployed and verified on Sepolia. You can interact with them directly, stress-test the routing logic, and verify that the economics work as designed.

The Sepolia deployment addresses are:

IMT V8: 0xB575A8760c66F09a26A03bc215D612EA2486373C - FeederV9: 0xa87e7c25c2f754C7D6bFc9b4472E0c36096E4bF6

Both contracts are verified on Etherscan, allowing full inspection of the implementation.

Comparing Models: Feeder vs. Traditional Creator Monetization

Traditional creator monetization web3 has relied on a few mechanisms: NFT sales with royalties, community token issuance, and speculative trading volume. Each has limitations.

NFT royalties have become optional in practice—creators who built businesses around secondary sale royalties have seen those revenues evaporate as marketplaces removed enforcement. Community tokens often require active community management and can devolve into speculative trading with no connection to actual product usage. And trading-volume-based models require someone to be actively trading, which creates incentive structures that favor speculation over usage.

The Feeder model sidesteps these issues because the revenue is tied to actual payments, not trading activity. A creator on NepTime.io receives revenue when viewers actually donate or tip. A subscription through Valiep.com generates activity when payments are made. The dividend stream for IMT holders grows as real economic activity increases, not when traders move the price.

Looking Forward

The integration roadmap includes all four announced partners, each using the same Feeder primitive. This consistency means that as the ecosystem grows, the on-curve activity compounds across multiple products. A user who discovers content on Discovire.com, tips a creator on NepTime.io, and plays a ByteOdyssey game generates on-curve activity across three different use cases—all benefiting IMT holders.

Mainnet launch will follow testnet validation, bringing the same mechanics to production ETH. The contracts are designed to be chain-agnostic in their logic, with Sepolia serving as the proving ground.

For developers evaluating the creator monetization web3 space, the Feeder represents a different kind of opportunity—not a token to speculate on, but a primitive to build with. The architecture is open, the contracts are verified, and the integration surface is minimal. Test it on Sepolia, and watch for mainnet launch coming soon.

Want to dig deeper into how Immute works on-chain?

Read the whitepaper — full technical spec of the bonding curve, fee distribution, and Feeder primitive.
Audit + V4 postmortem — every finding ever raised against the contracts and how it was resolved.
Live leaderboard — top holders, dividend earnings, referral payouts.
On-chain charts — supply curve, ETH balance, Feeder fee flow.
immute.io — connect a wallet and try the mechanics on Sepolia testnet (mainnet launch coming soon).

BUY_LOCK_BLOCKS: How Immute Blocks Same-Block Sandwich Attacks

Version 6 LLC — Sun, 26 Apr 2026 04:53:20 +0000

Sandwich attacks remain one of the most exploitative patterns in decentralized finance. A malicious actor identifies a pending transaction, front-runs it with a higher gas bid to buy the same asset, then back-runs with a sell after the victim's transaction completes—all within the same block. The victim pays more for their purchase, the attacker pockets the spread, and the protocol's integrity degrades. For a bonding-curve reward token like Immute, where every buy and sell directly impacts the curve's state and every holder's dividend distribution, preventing this vector isn't optional. It's structural.

This post walks through the smart contract sandwich attack prevention mechanisms built into Immute's IMT token, specifically the per-address buy-lock window that blocks front-run-buy and back-run-sell sequences within a single block. The implementation uses two complementary functions—isLocked() and lockedUntil()—to enforce temporal constraints that make same-block exploitation economically nonviable.

What Makes Sandwich Attacks Possible on Bonding Curves

A bonding curve defines price as a function of supply. When a user buys IMT, the contract mints new tokens at the current curve price, increasing supply and raising the price for subsequent buyers. When a user sells, the contract burns tokens, decreasing supply and lowering the price for subsequent sellers.

This mechanism is transparent and deterministic—and that's the problem. An attacker watching the mempool sees a pending buy transaction. They can:

Front-run: Buy IMT just before the victim's transaction, driving the price up. 2. Victim's transaction executes at the elevated price, costing more for the same amount of IMT. 3. Back-run: Sell immediately after, capturing the spread between their lower buy price and the victim's higher execution price.

For a standard bonding curve without countermeasures, this attack is straightforward to execute. The profit margin depends on transaction size and gas costs, but for sufficiently large trades, the economics are favorable.

The Per-Address Buy-Lock Window

Immute's defense centers on a constraint that most bonding curve implementations ignore: temporal coupling between buy and sell operations for the same address.

When an address executes a buy transaction on IMT, the contract records the current block timestamp and sets a lock period. During this lock window, that specific address cannot execute a sell transaction. The lock expires after a configurable duration (measured in blocks), at which point the address regains full trading capability.

This approach breaks the sandwich attack in its tracks. Consider the sequence:

Attacker submits a front-run buy. 2. Victim's buy transaction executes. 3. Attacker attempts to back-run sell—but the contract rejects it because the lock from step 1 hasn't expired.

The attacker is now holding IMT purchased at the elevated price with no immediate exit. They must wait for the lock window to expire, during which the price may revert, gas costs accumulate, and the entire attack vector collapses.

The Implementation: isLocked() and lockedUntil()

The lock mechanism is exposed through two view functions that any wallet, dApp, or audit tool can query.

The isLocked(address user) function returns a boolean indicating whether the specified address is currently subject to a buy-lock. It checks if the current block timestamp is less than the stored lockedUntil value for that address.

The lockedUntil(address user) function returns the exact timestamp (or block number, depending on the implementation) when the lock expires. If the address is not locked, this returns zero or the current timestamp, depending on the contract's convention.

A typical integration looks like this:

if (imt.isLocked(msg.sender)) { revert BuyLockActive(); } Front-end applications can query these functions before rendering trading interfaces, giving users feedback on whether they're subject to a lock. On-chain, the check executes atomically within the buy transaction's execution context, ensuring that even if a user submits a transaction through a mempool-aware mechanism, the contract enforces the constraint.

Why This Works Against Same-Block Attacks

The key insight is that same-block sandwich attacks require rapid back-to-back transactions from the same address: buy, victim transaction, sell. The lock window is measured in blocks or time, not in individual transactions. A single buy initiates a lock that persists across multiple subsequent blocks.

If an attacker attempts to sandwich within a single block:

The front-run buy triggers the lock. - The victim's transaction executes. - The back-run sell fails because the lock is still active. - The attacker cannot exit their position within the same block.

Even if the attacker spreads operations across consecutive blocks, the lock still applies until it expires. This transforms the attack from a low-risk, high-reward exploit into a timed position with uncertain exit conditions.

The design doesn't prevent front-running entirely—nothing can block an attacker from buying before a victim's transaction if they submit it with higher gas. But it eliminates the same-block exit, which is the critical component that makes sandwich attacks profitable. Without the guaranteed back-run, front-running becomes speculation: buy now, wait for price appreciation, exit later. This removes the risk-free arb structure that makes mempool monitoring profitable.

Integration Considerations for Builders

If you're building on Immute or integrating the IMT token into a frontend, you should query isLocked() before displaying trading controls. Users who are locked can still buy (the lock only blocks sells within the window), but attempting to sell during a lock period will revert with BuyLockActive().

For protocols integrating through the Feeder contract—the primitive that routes 99% of payments to the integrating product's treasury while committing 1% on-curve—the lock mechanism remains consistent. A user who buys IMT through the Feeder triggers the same lock. Creators earning IMT through Neptime.io or players spending through ByteOdyssey will encounter the same constraints if they attempt same-window buy-then-sell sequences.

This consistency matters for price stability. Without the lock mechanism, sophisticated traders could move IMT in and out of positions rapidly, extracting value from the curve while diluting holder dividends. The lock forces longer holding periods, which means more IMT volume stays on-curve longer, which means more fee distribution to existing holders.

Mainnet Planning

Currently live on Sepolia testnet, Immute's lock mechanism has been validated through repeated testing cycles. The contract code is public on Etherscan, and developers are encouraged to review the implementation directly. Once mainnet launch completes, the same mechanisms will apply to production IMT transactions.

For developers interested in building with Immute's smart contract sandwich attack prevention architecture, the testnet environment provides a frictionless sandbox. Free Sepolia ETH is available from faucets like Sepolia PoW Faucet, and the contracts are accessible at standard Ethereum JSON-RPC endpoints. No team allocation exists, no VC rounds have occurred—the token economy is fully community-driven from genesis.

The lock mechanism is one component of a broader security posture that includes the Feeder's 1% on-curve commitment on every integration payment, deterministic bonding curve pricing, and transparent on-chain state. For a reward token where every holder earns from every transaction, protecting the curve's integrity isn't a feature. It's the foundation.

Want to dig deeper into how Immute works on-chain?

Read the whitepaper — full technical spec of the bonding curve, fee distribution, and Feeder primitive.
Audit + V4 postmortem — every finding ever raised against the contracts and how it was resolved.
Live leaderboard — top holders, dividend earnings, referral payouts.
On-chain charts — supply curve, ETH balance, Feeder fee flow.
immute.io — connect a wallet and try the mechanics on Sepolia testnet (mainnet launch coming soon).

BUY_LOCK_BLOCKS: How Immute Achieves Smart Contract Sandwich Attack Prevention

Version 6 LLC — Sun, 26 Apr 2026 04:47:37 +0000

yaml style: blog status: draft generated_at: 2026-01-25T12:00:00Z

Smart contract sandwich attack prevention is a core design goal of Immute, a bonding‑curve reward token live on the Sepolia testnet. By introducing a per‑address mutual‑exclusion mechanism, Immute makes it impossible for any single wallet to execute a buy‑followed‑by‑sell (or sell‑followed‑by‑buy) inside the same block, thereby neutralising the classic front‑run‑buy / back‑run‑sell pattern that plagues AMM‑style DEXes. This article dissects the attack vector, explains the logic behind the isLocked() and lockedUntil() primitives, and shows how the contract enforces the lock at the EVM level.

What Is a Sandwich Attack?

A sandwich attack is a form of maximal‑extractable value (MEV) exploitation that relies on ordering two transactions around a victim trade in a single block:

Front‑run buy – the attacker sees a pending large buy and places his own buy just before it, pushing the curve price up. 2. Victim execution – the victim's buy settles at the higher price, absorbing the artificial slippage. 3. Back‑run sell – the attacker immediately sells his position in the same block, capturing the spread.

The profitability of this pattern depends entirely on the attacker’s ability to buy and sell within the same block. If a contract can enforce that a wallet cannot both buy and sell in the same block, the attack surface disappears.

Why Traditional AMM Contracts Remain Vulnerable

Most AMM contracts treat each transaction as independent. The swap function simply checks the reserves, updates them, and returns the output. There is no per‑address state that persists across the block, so a single wallet can:

Call swap to buy tokens. - Immediately call swap again to sell the same tokens.

Both calls are processed in the same block, so the attacker enjoys the same price impact and can pocket the spread with negligible risk. The only cost is the gas for two transactions, which is often outweighed by the extracted value.

Immute’s Per‑Address Buy‑Lock Mechanism

Immute introduces two simple but powerful state variables:

solidity mapping(address => uint256) public lockedUntil;

lockedUntil[addr] stores the timestamp (or block‑relative value) after which the address is allowed to perform the opposite action. The contract provides a view function:

solidity function isLocked(address addr) external view returns (bool) { return block.timestamp < lockedUntil[addr]; }

When an address executes a buy, the contract sets:

solidity lockedUntil[msg.sender] = block.timestamp + 1; // zero‑duration lock for the remainder of the block

When the same address attempts a sell in the same block, the first line of the sell function checks:

solidity if (isLocked(msg.sender)) revert BuyLockActive();

Because block.timestamp has not advanced, the check evaluates to true, reverting the transaction. Conversely, after a sell, the lock is set on the buy side:

solidity lockedUntil[msg.sender] = block.timestamp + 1;

Thus a user cannot immediately buy after selling, nor sell after buying, within the same block.

Why a 1‑second Lock Works

Ethereum blocks are produced roughly every 12 seconds, but block.timestamp advances only when a new block is mined. By setting lockedUntil to block.timestamp + 1, we guarantee that any subsequent transaction in the same block will see the lock still active, while a transaction in the next block will see block.timestamp equal to or greater than lockedUntil, lifting the restriction. This effectively creates a one‑block cool‑down without altering the global throughput of the contract.

Implementation Details

The IMT V8 contract (0xB575A8760c66F09a26A03bc215D612EA2486373C) implements the lock in the buy and sell entry points. Below is a simplified pseudocode representation of the guard:

```solidity function buy(address recipient, uint256 minOut) external payable { // 1. Validate curve parameters, compute output, apply 10% fee. require(!isLocked(recipient), "Buy locked"); // 2. Execute transfer and update internal accounting. _processBuy(recipient, msg.value); // 3. Set lock to prevent a sell in this block. lockedUntil[recipient] = block.timestamp + 1; }

function sell(address payable seller, uint256 amount, uint256 minOut) external { // 1. Validate allowance, compute output, apply 10% fee. require(!isLocked(seller), "Sell locked"); // 2. Execute transfer and update internal accounting. _processSell(seller, amount); // 3. Set lock to prevent a buy in this block. lockedUntil[seller] = block.timestamp + 1; } ```

The Feeder contract (`0xa87e7c25

Want to dig deeper into how Immute works on-chain?

Read the whitepaper — full technical spec of the bonding curve, fee distribution, and Feeder primitive.
Audit + V4 postmortem — every finding ever raised against the contracts and how it was resolved.
Live leaderboard — top holders, dividend earnings, referral payouts.
On-chain charts — supply curve, ETH balance, Feeder fee flow.
immute.io — connect a wallet and try the mechanics on Sepolia testnet (mainnet launch coming soon).

What is a bonding-curve reward token? Inside Immute's on-chain dividend mechanic

Version 6 LLC — Sun, 26 Apr 2026 04:47:32 +0000

yaml style: blog status: draft generated_at: 2025-01-31

A bonding-curve reward token is a smart-contract mechanism where token price is a deterministic function of supply, and every trade generates automatic dividends distributed to all existing holders. Immute implements this pattern on Sepolia testnet, where a 10% fee on every buy and sell flows pro-rata to every IMT holder. Mainnet launch is coming soon — but developers can test the mechanics today at https://immute.io.

The price formula

Traditional token markets rely on order books or liquidity pools to discover price. A bonding curve replaces that external infrastructure with a mathematical function embedded in the contract itself.

Immute's curve follows:

P = k × S

Where: - P is the current price of one IMT in ETH - S is the total supply of IMT - k is a constant coefficient that defines the curve's slope

When someone buys IMT, the contract mints new tokens. The supply S increases, the price P increases, and the buyer receives tokens at the current on-curve price. When someone sells, tokens are burned, supply decreases, and price decreases accordingly.

This means price discovery is instantaneous and endogenous — no waiting for a market to clear, no slippage from shallow order books, no dependency on external liquidity providers.

Fee distribution: how the 10% compounds

On Immute, every buy incurs a 10% fee and every sell incurs a 10% fee. This fee is not a protocol tax or a team reserve — it is distributed automatically to every current IMT holder in proportion to their balance.

If the total IMT supply is S and your wallet holds b tokens, your share of any fee is:

Your share = b / S

If 1 ETH in fees is distributed and you hold 5% of supply, you receive 0.05 ETH. This happens on every transaction — buys and sells — automatically, via the contract's dividend logic.

The compounding effect is direct: as the token economy grows and trade volume increases, the fees distributed to holders scale proportionally. A holder who maintains their position through periods of activity accumulates rewards continuously, regardless of whether the token's USD price goes up, down, or sideways.

Contrasting with LP-based markets

In a typical AMM LP model, a token trades against another asset in a liquidity pool. Market makers must provide capital to both sides of the pool. Returns come from LP fees — but those fees are captured by liquidity providers, not by all token holders. Furthermore, liquidity providers face impermanent loss when the token's price diverges from the paired asset.

A bonding-curve reward token eliminates the need for external LPs. Price is a function of supply; no one needs to provision the other side of a trade. The capital efficiency is structural — every ETH that enters buys IMT at the on-curve price, and every ETH that exits sells IMT at the on-curve price.

The tradeoff is that bonding curves concentrate price exposure on the curve itself. A large sell moves the price down more significantly than in a deep LP pool. This is a design choice, not a flaw — and it's one that suits token models where the primary value accrual is the dividend mechanic rather than speculative price discovery.

Contrasting with team-allocated tokens

Most token launches distribute supply to teams, advisors, and early investors before or at genesis. This creates structural misalignment: insiders receive tokens at favorable prices while public participants pay market price. The 10% fee in such models flows partly to insiders who paid nothing or little for their positions.

Immute has no team allocation and no VC round. Supply starts at zero and grows organically as participants interact with the curve. There is no pre-mine, no allocation for founders, no hidden vesting schedules. Every IMT in existence was purchased through the contract — no one received tokens at preferential terms.

This means fee distribution flows exclusively to participants who bought at the curve — including early testers who entered when supply was minimal and latecomers who entered when the curve had climbed. All of them receive pro-rata dividends on equal terms.

The Feeder primitive and product-powered rewards

The dividend mechanic becomes more powerful when external products route value through the curve. Immute exposes a Feeder contract (address 0xa87e7c25c2f754C7D6bFc9b4472E0c36096E4bF6 on Sepolia) that any integrating product calls to process payments.

When a product accepts IMT as payment:

99% of the payment goes to the product's own treasury — this is the integrating platform's revenue - 1% of the payment is routed through the bonding curve — this triggers the 10% fee, which distributes to all IMT holders

This makes Immute a product-powered reward token. The dividends aren't funded by speculative trading alone — they're underwritten by real product transactions. Planned integrations include:

Neptime.io — creator monetization where viewers tip IMT on uploaded videos, driving fee distribution through the Feeder - Valiep.com — subscription purchases routed through the Feeder - Discovire.com — discovery-layer purchases, also Feeder-routed - ByteOdyssey — in-game payments on a game development platform, routed through the Feeder

Each integration adds transaction volume that flows through the curve, generating dividend events that reward all IMT holders — regardless of which product originated the trade.

Testing the mechanics on testnet

If you're a developer or an informed participant who wants to see how the fee distribution, price curve, and Feeder interactions work in practice, IMT is live on Sepolia (chainId 11155111).

Testnet ETH is free. You can get some from:

https://sepolia-faucet.pk910.de/ — proof-of-work faucet, no signup required - https://www.alchemy.com/faucets/ethereum-sepolia — requires a free Alchemy account

Connect a wallet (MetaMask, Rainbow, or any EOA-compatible wallet) to Sepolia, navigate to https://immute.io, and interact with the IMT V8 contract (0xB575A8760c66F09a26A03bc215D612EA2486373C) to buy, sell, and watch the dividend mechanics in real time. Both the IMT contract and the FeederV9 contract are verified on Sepolia Etherscan — review the source, trace the events, and test the math yourself.

Mainnet launch is coming soon. The goal of this testnet phase is validation — not speculation. Help us stress the contracts, surface edge cases, and confirm that the bonding-curve reward token mechanic behaves exactly as the design specifies. Every interaction on testnet is a contribution to that validation.

The contract source is open. The math is deterministic. The fee distribution is on-chain and verifiable. If you're building in DeFi or evaluating reward-token models, this is a structure worth understanding from the inside — not just from documentation.

Want to dig deeper into how Immute works on-chain?

Read the whitepaper — full technical spec of the bonding curve, fee distribution, and Feeder primitive.
Audit + V4 postmortem — every finding ever raised against the contracts and how it was resolved.
Live leaderboard — top holders, dividend earnings, referral payouts.
On-chain charts — supply curve, ETH balance, Feeder fee flow.
immute.io — connect a wallet and try the mechanics on Sepolia testnet (mainnet launch coming soon).