When a protocol distributes value to token holders, the mechanism matters as much as the intention. Centralized dividend portals require trust in an operator — trust that the portal will remain online, that it will accurately compute entitlements, and that it will not selectively deny claims. On Ethereum, the alternative is a self-enforcing on-chain dividend token that computes entitlements in the contract itself. Immute implements this pattern as a live, testable system on Sepolia, with mainnet launch coming soon.
The pull-based accounting model
Modern on-chain dividend token Ethereum implementations use a pull-based accounting model rather than pushing payments to every holder on each distribution. The core mechanism is a profitPerShare accumulator: every time the contract receives value (through buy/sell fees in Immute's case), it increments a global per-token entitlement counter. When a holder's balance changes — whether through a new purchase or a transfer — their past unclaimed dividends are tracked separately and their future entitlement is calculated from the updated balance.
This design separates two concerns that tend to get conflated in naive implementations: claim timing and entitlement accuracy. A holder can claim dividends at any point after they have accumulated, without affecting the accuracy of other holders' claims. The contract maintains a running profitPerShare value that every future interaction references, so nothing is ever lost or double-claimed.
For developers evaluating this pattern, the key invariant is that holder.unclaimed is always computable as balanceOf(holder) * profitPerShare - alreadyWithdrawn. Adding new value to the accumulator never reduces any holder's legitimate claim; it only raises the ceiling.
Withdraw vs. reinvest: two paths out of the contract
Immute exposes two function paths for holders to collect their accumulated dividends: withdraw() and reinvest(). The distinction is deliberate.
withdraw() transfers the claimable amount in the payout asset — whatever token the dividend pool holds — directly to the holder's address. This is a cash-out flow: the holder converts their on-chain dividend entitlement into a spendable balance without altering their IMT position. It maps to the "claim dividends" action in traditional financial instruments, except that the claim is executed against contract state rather than a registry.
reinvest() does the opposite. It takes the claimable amount and uses it to acquire additional IMT at the current bonding-curve price, adding those tokens directly to the holder's balance. The accumulated dividends are compounding back into the position automatically, with no intermediate wallet step. This is the equivalent of a dividend reinvestment plan, but enforced by the contract rather than a broker.
Both functions read the same underlying accounting — they diverge only in what they do with the output. A holder who wants liquidity uses withdraw(); a holder who wants exposure uses reinvest(). The contract enforces the math in both cases.
Why on-chain distribution removes the trust requirement
Off-chain claim portals introduce a custodian layer. Even when the portal is well-intentioned, it creates a single point of failure: the portal can be paused for maintenance, compromised by an attacker, or selectively throttled if the operator faces load. More subtly, off-chain portals require the operator to maintain an address registry — a mapping of on-chain addresses to real identities or KYC records — which creates privacy and compliance overhead that many protocols want to avoid.
An on-chain dividend token built on Ethereum eliminates this layer entirely. The entitlement is encoded in contract state: profitPerShare, balanceOf, and the claimable amount are all public, readable by any indexer, and verifiable by any holder directly. No portal needs to be online for a holder to call withdraw(). No operator can selectively deny a claim that the contract mathematically owes.
Research into equity tokenization confirms this advantage: systems that use token snapshots and ERC-20 vaults for dividend payment enforce payouts through contract logic rather than through operator-controlled workflows [1]. Pull-based designs similarly reduce the operational risk of distribution by decoupling claim timing from distribution events [2]. Pooled payment models on Ethereum have explored efficient batch distribution, but the underlying principle remains the same: entitlement is determined by on-chain state, not by a server [3].
For Immute, the implication is straightforward: every IMT holder can verify their claimable balance at any time using only the contract ABI and a block explorer. The contract is the system of record, not a database controlled by a team.
Testing the mechanics on Sepolia
Immute is currently live on Sepolia testnet (chainId 11155111). The contracts implement both withdraw() and reinvest() as described, along with the bonding-curve buy/sell interface and the Feeder primitive that planned integrations will use. Free Sepolia ETH is available from faucets such as the PoW faucet at https://sepolia-faucet.pk910.de/ or the Alchemy faucet at https://www.alchemy.com/faucets/ethereum-sepolia. No signup is required for the PoW faucet.
To test the dividend accounting, a holder can buy a small IMT position, perform a trade to trigger the 10% fee, then call withdraw() to see the accumulated amount transfer. Alternatively, reinvest() can be used to compound the same amount back into the position without an intermediate transfer. Both paths are traceable on Etherscan by referencing the IMT V8 contract at 0xB575A8760c66F09a26A03bc215D612EA2486373C and the FeederV9 at 0xa87e7c25c2f754C7D6bFc9b4472E0c36096E4bF6.
Mainnet launch is coming soon, after testnet validation completes. The on-chain dividend token Ethereum pattern that Immute implements will remain unchanged at launch — the contract logic is already deployed and audited on testnet. Holders who test the mechanics now will have a clear mental model of how the distribution works before any value is at stake.
The Feeder primitive and future integrations
Immute's design extends beyond passive distribution. The Feeder contract is a payment routing primitive that planned integrations — Neptime.io, Valiep.com, Discovire.com, and ByteOdyssey — will use to route on-chain purchases through the bonding curve. One percent of every routed payment goes on-curve, flowing to IMT holders as dividend income. The remaining 99 percent goes to the integrating product's treasury.
This makes Immute a product-powered reward token rather than a speculative one: dividends are earned through real usage of products built on the Feeder, not through marketing or token inflation. The on-chain dividend accounting described above handles both the bonding-curve fee distribution and the Feeder-routed payments through the same profitPerShare mechanism.
Verifying the contract
Developers can read Immute's source code directly on Sepolia Etherscan. The ABI exposes profitPerShare, claimableOf(address), withdraw(), and reinvest() as public functions. Any off-chain script can replicate the claimable amount calculation by fetching the holder's balance, the current profitPerShare, and the holder's alreadyWithdrawn counter. This transparency is the core advantage of an on-chain dividend token Ethereum system: the math is public, the state is verifiable, and no operator can alter the outcome.
Testing on Sepolia is the current phase. Mainnet launch is coming soon. The contract is already running, and the mechanics are live.
Top comments (0)