One corporation. Many independently operated onchain products.

WHY THE CORPORATION EXISTS

Most protocols concentrate product logic, ownership and economics inside one monolith. Infinite separates them. Small products can be incorporated independently while sharing a registry, a visual structure and a common economic layer.

This separation is important. A useful auction should not need a new brand, frontend, indexer and distribution system before it can exist. Inside Infinite, the product remains small while the corporation supplies the shared surface around it. The company keeps its own owner, state and lifecycle; the corporation makes it legible and economically connected.

The corporation is therefore not a holding page for external projects. A registered company cannot point at an unrelated application and borrow Infinite's identity. Its address must be created by the factory from an admitted primitive, and its economically meaningful actions must occur through that instance. The cube is a doorway into a real product state, not an advertisement.

Every visitor reads the same registry. The collection is therefore not a wallet-specific portfolio and it is not assembled from local browser data. When a company is created, its position becomes part of a common public structure that another person can independently verify from the chain.

Growth is visible without needing inflated statistics. At launch, dormant geometry gives the corporation its architectural form. As contracts are incorporated, identified faces spread through that form. The visual change is backed by the same event that created the company, which means the interface does not need fake seed companies to appear complete.

The intended flywheel is operational, not promotional: more useful companies can create more paid activity; paid activity can create more protocol revenue. Neither step is guaranteed.

FIVE CONTRACTUAL LAYERS

The system is divided so that identity, product behavior and money do not depend on the same contract. The registry answers what exists. The factory controls which implementation can be instantiated. A company instance performs one product function. The treasury accounts for value. The token supplies checkpointed balances to the accounting layer.

INFINITE REGISTRY

Assigns sequential company IDs, records creator, instance, primitive, parent, creation time and active status.

INFINITE FACTORY

Creates minimal proxy instances from admitted immutable implementations and registers them atomically.

COMPANY INSTANCE

Holds the company-specific state and exposes its product actions.

INFINITE TREASURY

Accepts payments only from registered company instances, records gross activity and divides value between the operating recipient and holders.

INFINITE TOKEN

Uses transfer checkpoints so each balance earns only the value produced while that balance was held.

Minimal proxies keep incorporation small. The implementation code is shared; company storage, address, owner and lifecycle remain independent.

A company cannot present itself to the treasury merely by copying an interface. The treasury accepts company revenue only from addresses registered by the factory. This preserves a narrow trust boundary: product instances can route value through the shared accounting system, while unrelated contracts cannot manufacture protocol activity.

The architecture is deliberately non-upgradeable at the instance level. A company is created against a known primitive implementation and cannot later be transformed into an arbitrary product. New primitive versions can be introduced as separate implementations without silently changing the rules of companies that already exist.

WHAT IS SHARED, AND WHAT IS NOT

Implementation bytecode is shared to reduce deployment cost. Storage is not shared. A bid in one auction cannot alter another auction, and purchasing an access pass does not touch the supply of another access company. The registry connects identities while contract addresses keep state isolated.

The treasury is shared because value accounting benefits from one canonical entry point. Even there, operator credits and holder credits remain separate. Company revenue can increase a creator's withdrawable balance and the global holder accumulator in one transaction, without granting the company permission to withdraw the holder portion.

FROM CONFIGURATION TO PUBLIC COMPANY

Incorporation is a single product flow rather than a deployment toolkit. The creator chooses a primitive and supplies only the values that define its behavior. The application constructs the transaction, the wallet signs it, and the factory performs creation and registration atomically.

The identity is assigned by the registry, not selected by the creator or inferred by the interface. This makes the company number permanent and collision-free. Its contract address, owner, primitive and optional parent can always be reconstructed without relying on a private database.

Creation either completes as one coherent state change or reverts. There is no interval in which an initialized company exists publicly without registration, and there is no successful registration that points to a company the factory failed to initialize.

WHAT THE CREATOR SIGNS

The review screen exposes the primitive, creator, optional parent, economic split and expected wallet action before a signature is requested. Funded products include their working capital in the transaction value. Auctions can require a separate ERC-721 approval because the factory must be authorized to move the selected asset into escrow.

Normal gas remains the creator's responsibility. Infinite does not hide gas inside a fictional free flow, and it does not require the creator to provision servers or deploy a custom frontend. Once the transaction confirms, the company is immediately usable through its canonical page.

Bounties and escrows fund their instance during incorporation. Auctions require an ERC-721 approval and transfer the asset into the new instance. Access companies require no protocol-funded inventory.

FIXED PRIMITIVES. ONE COMPOSABLE PATH.

Each launch primitive is intentionally narrow. A narrow state machine is easier for a user to understand, cheaper to execute and less likely to conceal an administrative dependency. The contracts do not call an operator to decide what happened offchain; every transition is initiated by an authorized participant or by a public timeout rule.

No primitive promises that somebody will buy, submit, release or bid. The contracts guarantee the mechanics around a valid action; demand still has to come from the usefulness and distribution of the company itself.

WHY THESE PRODUCTS LAUNCH TOGETHER

The fixed primitives exercise materially different forms of onchain coordination. Custom adds a constrained creation surface for ideas that do not need an entirely new contract, while retaining the same registration and value-routing guarantees.

Together they test the corporation's common layer without forcing every company into the same business model. The shared fee route does not erase their differences: each primitive decides when economic output is real, who the operating recipient is and which terminal states must not pay a fee.

VALUE IS ROUTED FROM ACTUAL COMPANY ACTIVITY

The launch configuration fixes the protocol share at 1,000 basis points. The treasury fee is immutable after deployment and its constructor refuses any value above 2,000 basis points. The operating recipient is the creator for Access and Auction, the declared action recipient for Custom, the awarded worker for Bounty, and the beneficiary for Escrow.

Gross payment means the native asset that enters the economic route after a product succeeds. Deposits that are later refunded are not protocol revenue. An auction contributes only when it settles, an escrow only when it releases, a bounty only when it is awarded, and an access company each time a pass is purchased.

EXAMPLE PAYMENT

10.000 ETH

OPERATING RECIPIENT / 90%

9.000 ETH

INFINITE HOLDERS / 10%

1.000 ETH

Both portions remain backed inside the treasury as pull-based credits until claimed. The protocol does not push payments across an unbounded holder list.

Consider an access company that sells forty passes at 0.05 ETH. Gross activity is 2 ETH. The operating recipient accrues 1.8 ETH and Infinite receives 0.2 ETH for holder accounting. If the company sells nothing in the next month, no additional value appears merely because the company remains active.

Now consider a 12 ETH auction. The same rule assigns 10.8 ETH to the seller and 1.2 ETH to Infinite after settlement. Losing bids are not counted as gross activity because they remain withdrawable by their bidders. This distinction prevents temporary escrowed capital from being displayed as revenue.

TREASURY INVARIANTS

Every amount shown as operator credit or holder claimable value must be backed by native assets held by the treasury. Accounting entries are created only in the same call that transfers value into the treasury. Claims reduce stored credit before making the external payment, preventing the same credit from being replayed through reentrancy.

The fee uses integer basis-point arithmetic. For very small payments, flooring may make the Infinite share slightly smaller than the exact decimal result. The remainder stays with the operating recipient rather than being rounded upward against the user. Across holder distribution, sub-wei fractions remain as accounting dust until future increments make them representable.

No yield is minted. No new buyer pays an older holder merely by purchasing the token. No liquidity, reward or payout is subsidized by Infinite. A holder claim can only be backed by native ETH previously routed through a company.

REWARD PER TOKEN, CHECKPOINTED BEFORE EVERY TRANSFER

The treasury never loops over holders. Each protocol payment increases a global cumulative reward-per-token value. Each account stores the last cumulative value it has already accounted for.

That cumulative value behaves like a shared odometer. When revenue arrives, it advances by an amount proportional to the payment and inversely proportional to total token supply. A wallet's earned amount is its balance multiplied by the distance between the current odometer and the point already recorded for that wallet.

WHY BUYING BEFORE A CLAIM DOES NOT CAPTURE THE PAST

Before a token transfer changes balances, the token calls the treasury. Sender and receiver are checkpointed using their old balances at the current cumulative reward value. The receiver begins the new balance at that point; historical accrual remains with the seller.

Claiming and earning are separate actions. A wallet does not need to claim before transferring, and a transfer does not erase what has already accrued. The checkpoint first moves earned value into stored credit, then the token balance changes. The wallet can claim that stored credit later.

The same property allows claims to scale with the number of claimants rather than the number of token holders. Every wallet pays for its own claim transaction. A company payment updates one global value and therefore does not become more expensive as the holder set grows.

MINTS, BURNS AND EMPTY SUPPLY

Balance-changing operations use the same checkpoint boundary as transfers. Newly minted tokens begin at the current reward position and therefore cannot claim value routed before they existed. Burned tokens preserve previously accrued credit for their former owner while ceasing to participate in later company payments.

If no eligible token supply exists when value reaches the treasury, the contract cannot divide that payment across holders. Production configuration must establish the supply relationship before company revenue is accepted. The interface reads the same configured token address everywhere so balance, accrual and claim state cannot drift across pages.

Integer division can leave very small native-token dust in the treasury. Claims use checks-effects-interactions and pull payment; holder and operator credits can be claimed together.

POSSIBLE RETURNS ARE A FUNCTION OF ACTIVITY, OWNERSHIP AND POSITION COST

For constant holder share q over an interval, holder accrual is approximately G × 10% × q. A return percentage additionally requires the acquisition cost of that token position. Token price is external to the protocol and cannot be inferred from company revenue.

If the corporation produces 100 ETH of gross paid activity in one month, 10 ETH enters holder accounting. A wallet that continuously owns 2% of supply over that entire interval accrues approximately 0.2 ETH. If the same wallet's position cost 8 ETH, the simple monthly return on that cost would be 2.5%. This is a historical relationship between activity and cost, not a forecast.

If gross activity falls to 10 ETH, the same ownership produces approximately 0.02 ETH. If activity is zero, accrual is zero. Conversely, a higher ownership percentage does not create additional company activity; it changes only the fraction of already captured value attributable to the wallet.

The model below is a calculator for assumptions. It deliberately separates company count from activity per company because a large corporation with dormant products can generate less than a small corporation with heavily used products. Neither company count nor token balance is a substitute for real paid usage.

READING THE OUTPUT

The monthly figure is a simple interval calculation. The annualized figure multiplies it by twelve only to make the scale easier to compare; it does not compound, model a changing token balance or assume that activity repeats. Real accrual changes whenever gross activity or the wallet's share of supply changes.

Position cost is included solely to express accrual relative to capital spent. The protocol does not know that cost and never uses it in distribution. Two holders with the same balance earn the same amount over the same interval even if they acquired their tokens at different prices, while their personal return percentages can differ substantially.

SUBSIDIARIES ARE STRUCTURAL, NOT A REFERRAL CHAIN

A company can name a parent only when the same creator owns the active parent. The relationship is recorded in the registry. Version one does not pay parent companies and does not create multi-level rewards; the primary economic route remains the Infinite treasury.

The parent field exists to describe how the corporation grows. A creator can place a specialized product beneath an existing company without creating a financial incentive to manufacture deep trees. The hierarchy changes discovery and future composability, but it does not redirect the launch fee split.

PUBLIC STATE

CANONICAL SOURCE

Registry and Treasury contracts on Robinhood Chain.

QUERY LAYER

A stateless server endpoint reads the public RPC. It does not invent or override economic state.

REFRESH

The application requests current state every four seconds. Edge responses are briefly cached for load control.

RECONCILIATION

The next read converges to the RPC's current canonical state. There is no separate database ledger in the present implementation.

The frontend treats contract state as canonical. Query responses can make the corporation faster to load, but they cannot change ownership, revenue, claimable value or a company's product state. If a cached response differs from a later canonical read, the interface converges to the chain.

Polling is intentionally modest. A newly confirmed company should appear for another visitor within the refresh interval without requiring local storage or a wallet connection. The visual structure recomputes positions deterministically, so the same set of registered companies produces the same corporation for every visitor.

EVENTS AND REORGANIZATIONS

Registry events provide an efficient discovery path, but the interface does not treat an unconfirmed log as final economic truth. Reads are reconciled against current contract state. If the chain reorganizes, a later canonical read can remove or replace a short-lived event instead of preserving a company that no longer exists on the accepted chain.

Repeated reads are idempotent. Reading the same company twice does not create two cubes, and reading the same revenue value twice does not double a metric. Canonical IDs are used as stable keys while transaction hashes and block information provide traceability to the explorer.

WHAT THE MODEL DOES NOT PROMISE

Infinite coordinates small products, but it cannot remove the risks inherent in public contracts, digital assets or open markets. A company can be correctly implemented and still be unused. A payment can be correctly accounted for while the token position that receives it loses market value.

Creators should expose clear metadata and choose parameters that users can independently understand. Users should verify contract addresses, assets, deadlines and counterparties before signing. The interface reduces accidental complexity, but it cannot make a deliberately unsafe configuration economically sound.

PRIMITIVE-SPECIFIC FAILURE MODES

An access credential proves purchase but cannot guarantee that an offchain community, file or service remains available. A bounty can prove that funds and submissions exist, but the creator still chooses which submission satisfies the brief. An escrow's safety depends on the selected parties and optional arbiter. An auction can transfer a token correctly while the token's external metadata later disappears.

These boundaries are part of the product definition. Infinite secures the transitions it can verify onchain and avoids presenting subjective outcomes as automatically resolved. Where human judgment remains, the authorized decision maker is explicit before funds enter the contract.

This documentation describes protocol mechanics. It is not a promise of profit, financial advice or a substitute for independent contract review.

CANONICAL PRODUCTION CONFIGURATION

The application uses a single deployment manifest for the target network, token, registry, treasury, factory and primitive implementations. This prevents different surfaces from silently pointing at different contracts.

CHAIN

Robinhood Chain / 4663

STATUS

DEPLOYED

TOKEN

0x806B9e24f06b95fCBeB6ae25f66a5d183716ffF9 ↗

REGISTRY

0xE78043f293fd069cc288940679a5DBa9688c100D ↗

TREASURY

0x0DB98f16bB7F32e8eBe3165D87C61Fd27e4dadb6 ↗

FACTORY

0xb56D3220273bb7A10463097966B785dBB8cd50a6 ↗

ACCESS IMPLEMENTATION

0xe057d85f5aB00dC50436935FC831d6F6452e1cca ↗

BOUNTY IMPLEMENTATION

0x3C3fCD81C3e566C2Dc59a213bB65521826281c66 ↗

ESCROW IMPLEMENTATION

0x4A3778E81cf830E2bC747E13332113456cD4117A ↗

AUCTION IMPLEMENTATION

0x4571D4D1788944142580fdFf67E9D04f03adaA15 ↗

CUSTOM IMPLEMENTATION

0x87Ebb7c5B921DfED218Cfa67f6089Bff559CA2c8 ↗

All application integrations consume one deployment manifest. Once the production token and contracts are deployed, their addresses are configured there once and reflected throughout the interface.

Until that manifest contains deployed addresses, transaction controls report deployment pending rather than simulating success. Read-only explanatory pages remain available, but no company creation, company activity or holder claim is represented as live before the production contracts exist.

HOW TO VERIFY A LIVE DEPLOYMENT

A production reader should be able to follow each configured address to the chain explorer, confirm the factory's admitted implementations, read the registry's company count and compare treasury accounting with the balance held at its address. Company pages expose their instance address so product state can be checked independently of the frontend.

The production application and contract manifest are one release boundary. A frontend is not considered live merely because it builds, and a contract suite is not considered integrated merely because addresses exist. Incorporation, product use, value routing and holder claims must all resolve against the same production configuration.