One corporation. A recursive economy of independently operated companies.

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 inflated statistics. The live corporation displays only registered companies; dormant geometry is reserved for the explicitly labelled preview. As contracts are incorporated, new identified cubes spread through the production structure. Every visible company cube is therefore backed by the same event that created its canonical onchain company.

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.

SEVEN CONTRACTUAL LAYERS

The system is divided so identity, ownership, product behavior and money do not depend on one contract. The registry answers what exists. The economy records shares, funding and acquisitions. A dedicated vault gives every company an address that can hold assets and act as a protocol participant. Product instances perform commercial functions. The protocol treasury accounts for Infinite's captured value.

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.

INFINITE ECONOMY

Maintains fixed company shares, owner and holding indexes, funding rounds, secondary listings, acquisitions and share-owner revenue.

COMPANY VAULT

Holds ETH, ERC-20 and ERC-721 assets and lets an authorized operator pay companies, buy products, invest and acquire shares on behalf of the company.

PRODUCT INSTANCES

Hold activity-specific state. A company begins with one product and can add more without losing its identity or treasury.

INFINITE TREASURY

Records gross activity, applies the immutable protocol fee and accounts for operator, company and voluntarily deposited INFINITE positions.

INFINITE TOKEN

Can be deposited into the revenue vault. Liquid wallet balances do not receive historical or future protocol revenue automatically.

PONS MARKET LAYER

Creates the optional company coin, bonding curve, market metadata and creator-fee route. Infinite verifies the canonical pons launch before binding it to a company.

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 protocol treasury is shared because fee accounting benefits from one canonical entry point. Even there, operator credits, company capital and depositor rewards remain separate. Product revenue can fund a company and advance the global depositor accumulator in one transaction without granting the company permission to withdraw Infinite's portion.

FROM CONFIGURATION TO PUBLIC COMPANY

Open Create company in the main menu. Choose Application to connect an existing tool, or Custom, Access, Bounty, Escrow or Auction to configure an onchain product. Review the terms before creating it.

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 vault, initial product, ownership, revenue policy and optional parent are created in the same incorporation transaction and can 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.

A root company begins with creator wallet ownership of 100%. A subsidiary belongs to its parent company by default. Bounties and escrows fund their product instance during incorporation; auctions escrow their ERC-721.

CONNECT YOUR APPLICATION. KEEP YOUR CODE.

An independently hosted application can sell permanent or renewable 30-day access through Infinite. Its source code, hosting, API keys and data remain with its developer. Infinite records the product, collects its access payment and provides a connector that the application uses to verify each customer.

Connect an application ↗

Follow the interactive seller guide ↗ for the complete journey: prepare your application, publish its offer, install the connector, protect paid operations, deploy, test a real customer purchase and withdraw your earnings. The customer guide ↗ covers payment, wallet sign-in and using the application.

SELLER SETUP

Enter a name, description, HTTPS application origin and price in ETH. Choose permanent access or 30 days. Publish with your wallet, then run the generated installation command in your application. For an existing Next.js App Router app, the local installer creates the configuration, authentication routes and a private session secret without uploading code or replacing existing integration files. Add the access guard to every paid page and API operation, copy the generated secret to your hosting environment, and deploy. The connection screen includes a connection test. Other frameworks can use the manual setup and runnable Node server example.

Publishing creates a Custom product with one instant action and no company-token requirement. The application address, price and plan are immutable for that product. To move to a different domain or price, publish a new product and continue honoring existing customers on the old one. An application must be hosted and reachable; this connector does not expose a developer's local computer or deploy their code.

PAYMENT AND ACCESS

The customer connects a wallet, pays the displayed amount plus network fees, and opens the application. A short wallet signature authenticates that same customer on the application's own server. The server reads the registered contract to check access before each protected request. Existing access survives a pause in new sales. A 30-day renewal extends from the later of the current expiry or the current block time; renewals are manual, with no recurring debit. Permanent access does not expire and cannot be purchased twice by the same wallet.

The checkout checks the application's connector status before requesting a new purchase. This prevents ordinary setup mistakes from taking payments, but a status response is not an audit or a guarantee of the seller's future uptime, service quality or fulfillment. An onchain payment cannot be automatically reversed if an external application later goes offline.

For a complete production trial, use a separate customer wallet with no existing access. Confirm that unpaid requests are denied, then purchase, sign in and run the actual paid feature. Return with the publishing wallet to withdraw its available earnings. This trial uses real ETH on Robinhood Chain, including network fees; guide progress alone does not verify the application's protection or delivery.

RECEIVING REVENUE

The contract's protocol fee is displayed before publication; the standard deployment uses ten percent. The remaining amount is credited explicitly to the publishing wallet, independent of later company treasury policy changes. In the application management screen, Withdraw to wallet collects the wallet's available seller credits across all Infinite products in one transaction. This is a withdrawal step, not an automatic bank or wallet payout.

SERVER INTEGRATION

The connector exports createInfiniteConnector, whose handle(request) provides login, callback, session, logout and public connection-status endpoints under /api/infinite. Configure the exact application origin, trusted registry, product address, chain, RPC, Infinite origin and a randomly generated session secret of at least 32 bytes. Store that secret in server environment variables, never in browser code or onchain. Run on Node.js 22 or later.

const access = await infinite.requireAccess(request);
if (access instanceof Response) return access;

// Run your existing paid operation for access.address.
// Keep personalized responses private and uncached.

Add this guard before every paid API operation. For a protected server-rendered page, call getSession(request) and redirect unauthenticated visitors to /api/infinite/login. Use dynamic rendering and private, no-store responses. Protect file downloads on the server; publishing an asset to a public folder makes it accessible without the guard. A client-side button, hidden link or public HTML page does not enforce payment.

AUTHENTICATION AND FAILURE BEHAVIOR

Sign-in uses a five-minute, cookie-bound wallet challenge with the application's domain, chain, registry and product embedded in the signed message. Signatures return in a URL fragment and are removed before the same-origin callback verifies them. Sessions use signed, HttpOnly cookies. A copied address or unsigned callback cannot grant access. The connector checks registry membership and current entitlement, supports smart-contract wallet verification, and rejects protected requests when chain verification is unavailable.

The default session is limited to one day and never replaces the onchain access check. Stateless cookies do not provide server-side session revocation; logging out clears this browser's cookie, and a stolen cookie remains usable until its expiry or access expiry. A previously captured challenge and its original cookie are bounded by their original lifetimes, rather than tracked in a global one-use database. Developers should rotate a compromised session secret and add their own session store if their application requires immediate revocation.

Application hosting, customer support and delivery remain the seller's responsibility. This version supports hosted web applications and server APIs, with permanent or manually renewed access. It does not include automatic subscription billing, metered credits, a local tunnel or application hosting.

Publishing uses the deployed protocol listed below. Each seller must also install and test their connector.

EVERY COMPANY HAS EXACTLY 1,000,000 ECONOMIC SHARES

Shares are integer accounting units inside Infinite. They represent protocol-level economic ownership only; they do not claim to be legal corporate stock. The fixed supply makes percentages deterministic: ten thousand shares equal one percent and five hundred thousand shares equal fifty percent.

A holder may be an ordinary wallet or the treasury address of another registered Infinite Company. The economy contract treats both as first-class holders. Its owner index answers who owns a company; its holding index answers what a wallet or company treasury owns. Transfers update both indexes and preserve revenue accounting.

Direct self-ownership is forbidden. A company cannot receive shares in itself. A direct two-company cycle is also rejected: if A already owns B, B cannot then receive shares in A. Detecting arbitrary cycles of unlimited depth onchain would require an unbounded graph traversal, so V1 does not reject longer cycles. All holdings remain publicly reconstructible for external analysis without introducing a gas-denial vector.

OWNERSHIP REVENUE

A company operator may distribute native assets from its vault to all current share owners through cumulative revenue-per-share accounting. No transaction loops over owners. Each owner claims independently, and transfer corrections ensure that buying shares does not acquire revenue accumulated before the transfer.

A COMPANY IS AN ASSET-HOLDING PARTICIPANT

Each company receives a minimal vault at incorporation. The vault is distinct from the operator wallet and from the protocol treasury. It can receive native ETH directly, accept exact-transfer ERC-20 deposits and safely receive ERC-721 assets. Only the declared operator can initiate withdrawals or company actions.

Product revenue follows a company-level policy. After the immutable ten percent Infinite fee, the remaining ninety percent can accrue to the operator, remain in the company treasury, or be split between them. A treasury-retained company can use earned capital to pay another company, purchase a registered product, invest in a funding round or acquire listed shares.

The vault deliberately exposes no arbitrary call function. Product execution is limited to product addresses recognized by the registry, and a company cannot purchase its own product through this route. This restricts operator power while preserving real inter-company commerce.

CAPITAL ENTERS AGAINST EXISTING SHARES

The company operator can lock a defined number of shares held by its wallet or by one of its controlled company treasuries into a funding round. A passive shareholder cannot open a round in the company's name. The round fixes its accepted asset, target, minimum, deadline and offered shares. Wallets and Infinite Companies can contribute. Allocations are calculated proportionally against the target, so the complete target corresponds to the complete offered block.

If the round reaches its minimum, finalization moves committed assets into the company treasury and lets contributors claim their shares. Unsold shares unlock to the seller. If the minimum is missed, the shares unlock and every contributor can recover their own funds permissionlessly. Contributions cannot exceed the target.

SECONDARY OWNERSHIP

An owner may lock a fixed share block into a fixed-price ETH listing. Another wallet or company treasury buys the entire listing atomically. The seller receives pull-based proceeds after a fixed one percent protocol fee. There is no AMM, order matching engine or invented liquidity.

An acquisition is simply a real change in balances. A holding becomes controlling only when its onchain balance crosses the relevant percentage; the interface never assigns that status from a label or announcement.

COMPANIES CAN TRANSACT WITH COMPANIES

An operator can instruct its vault to pay another company's registered treasury in ETH or ERC-20, with an optional memo hash. The destination is resolved from the canonical company ID rather than entered as an arbitrary recipient. The economy contract emits the source, destination, asset and amount for public activity reconstruction.

A company can also invoke a registered product from its treasury. The product sees the company vault as the buyer, so access credentials, token gates, bids and execution records belong to that company. Product value still follows the target company's revenue policy and Infinite fee exactly as it would for a wallet buyer.

This is what makes the economy recursive. A company can earn into its treasury, use that capital to buy a service, fund a subsidiary or acquire ownership, then receive later ownership distributions. Every step remains a separate explicit transaction backed by actual assets.

PONS CREATES THE MARKET. INFINITE CREATES THE COMPANY.

The company name and description also identify its coin. Add an image and ticker, then launch through the canonical Pons V2 factory. Infinite checks the live configuration for exactly 1,000,000,000 coins before allowing a new launch. The same wallet then creates the operating company and links the confirmed coin in a second transaction.

The registry requires the pons launch to exist, requires its recorded deployer to equal the company creator and refuses a token already assigned to another company. A copied address, an unrelated ERC-20 or somebody else's launch cannot become the canonical coin of a new Infinite company.

The logo is not uploaded twice. It is stored as the pons token's onchain metadata and read from that token by Infinite. The corporation map, company page and pons market therefore resolve the same identity. If no pons coin is selected, Infinite uses its deterministic institutional mark instead.

WHAT THE COMPANY COIN DOES

The creator can set a whole-token balance required to use the company. Access purchases, bounty submissions, auction bids and Custom actions check that balance inside the company contract before continuing. A value of zero leaves the product public. Escrow settlement is never token-gated because it must remain available to the named parties.

The rule is a membership threshold, not a promise of returns. Tokens are obtained and traded through pons; Infinite only reads the current balance when the product is used. Selling below the threshold removes access to later actions but cannot reverse an action that already settled.

Pons V2 launches begin on a bonding curve and can graduate into permanent Uniswap V4 liquidity under the pons rules. Infinite records both the token and curve addresses and displays the live pons phase, but it does not calculate, control or guarantee the market price.

COIN FEES AND COMPANY WALLET

Review the live Pons launch fee and base trading fee. Choose an additional creator fee from zero up to Pons' current limit, and turn buyback and vesting on or off. The additional rate is fixed at launch. Infinite checks the reviewed terms again before signing; changed fees or economics require a fresh review.

Choose the connected wallet or another company wallet you control to receive the creator's trading-fee share and any additional creator fee. These earnings accumulate in Pons escrow; the recipient wallet must claim them on Pons. They are not paid automatically. Use a wallet capable of signing claim transactions, such as a wallet you control or a Safe. Infinite's internal company treasury cannot claim Pons fees and must not be used as this recipient.

Coin trading fees are separate from product revenue. Successful paid product use keeps Infinite's 90% company / 10% protocol split; the company chooses how its 90% is allocated. If the coin launch confirms but company creation fails, retry creation with that coin instead of paying to launch another.

A pons market can be volatile or lose all liquidity and value. Product usefulness and token demand are related only when users genuinely value the company's gated action.

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 product 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. For business products, the other ninety percent follows the company's operator/treasury policy. Bounty awards and escrow releases instead pay their declared external beneficiary because those funds are not the company's own business revenue.

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

COMPANY + OPERATOR / 90%

9.000 ETH

INFINITE REVENUE VAULT / 10%

1.000 ETH

The company-retained portion moves directly to its registered vault. Operator and Infinite portions remain backed as pull-based credits until their recipients claim. The protocol never pushes payments across an unbounded owner or depositor list.

Funding contributions and plain company-to-company treasury transfers are not taxed. A completed fixed-price secondary share sale pays one percent to the Infinite revenue vault; the other ninety-nine percent becomes claimable sale proceeds for the seller. These percentages are immutable constructor parameters rather than administrator-controlled settings.

Consider an access company that sells forty passes at 0.05 ETH. Gross activity is 2 ETH. Its configured company/operator route receives 1.8 ETH and Infinite receives 0.2 ETH for depositor 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.

VOLUNTARY DEPOSITS. CUMULATIVE REVENUE PER DEPOSITED TOKEN.

Liquid INFINITE balances do not automatically receive protocol revenue. A holder voluntarily deposits INFINITE into the revenue vault. Only tokens already deposited when revenue arrives participate in that revenue. Deposits can be withdrawn without a lock, while accrued ETH remains claimable.

The vault never loops over depositors. Each protocol payment increases a global cumulative reward-per-staked-token value. Each account stores its deposited balance, the cumulative value already paid and any accrued credit. This makes one revenue transaction constant-cost even if the holder set grows.

WHY A LAST-SECOND BUY CANNOT CAPTURE THE PAST

Buying INFINITE changes only the liquid token balance. The buyer must separately approve and deposit those tokens. The deposit checkpoints the current cumulative value before increasing the user's deposited balance, so no revenue generated before that transaction is assigned to the new position.

Depositing, withdrawing and claiming all checkpoint the account first. Withdrawing therefore cannot erase earned credit, and redepositing cannot move the account backward in cumulative history. Users claim rather than the protocol pushing value to an unbounded list.

NO DEPOSITORS

If protocol revenue arrives while no INFINITE is deposited, it is recorded as unallocated protocol revenue. It is not assigned retroactively to the first future depositor. This rule removes a particularly simple historical-capture exploit and keeps every claim linked to economic participation at the moment revenue was produced.

Integer division can leave sub-wei accounting dust. 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 a constant share q of deposited INFINITE over an interval, holder accrual is approximately G × 10% × q for product revenue, plus its share of other protocol fees. 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 product activity in one month, 10 ETH enters holder accounting. A wallet that continuously supplies 2% of all deposited INFINITE over that 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 OWNERSHIP, NOT A REFERRAL CHAIN

A company can name a parent only when the same operator controls the active parent. By default the parent company's vault receives all one million shares of the subsidiary. An advanced creation can reserve a declared fraction for the creator wallet. No ownership reward propagates automatically through unlimited ancestors.

The hierarchy is therefore backed by balances rather than a decorative parent label. Separately acquired companies also appear in a company's holdings. A conglomerate is simply the set of these real relationships; there is no special conglomerate contract and no referral payout chain.

PUBLIC STATE

CANONICAL SOURCE

Registry, Economy, Company Vault and Treasury contracts on Robinhood Chain.

QUERY LAYER

A stateless deterministic index reads contract state and confirmed logs from 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

Log keys use transaction hash plus log index; state pages are keyed by canonical company IDs. Confirmed ranges are rescanned idempotently.

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

PENDING ONE-TIME CONFIGURATION

REGISTRY

0xa6bc2419821d9f01198fd78e4dc48a32877ce853 ↗

TREASURY

0x537d6362229b875cf3becac53e2895c7b31f59a9 ↗

ECONOMY

0x0392741c077ace936f171a917c6a0908f3955258 ↗

COMPANY VAULT IMPLEMENTATION

0xb1c173a047573e139817b83b93ab1eff52d7ed52 ↗

FACTORY

0x4a8ee0aa2260c119a12c6e97bfec58637e1003bb ↗

ACCESS IMPLEMENTATION

0x8da2ff448e04a367a0b8c7678b946fc7425183b0 ↗

BOUNTY IMPLEMENTATION

0x4b536017c11132b54f805690e89d23d8c0167b80 ↗

ESCROW IMPLEMENTATION

0x657ee554f76a8f3e182567cbb350ccf694d2e04c ↗

AUCTION IMPLEMENTATION

0x137a66241e8924509db72517ba9c53cc17ddaae0 ↗

CUSTOM IMPLEMENTATION

0x745ed8f55f228b27e99ea137f53634205fae4922 ↗

PONS V2 FACTORY

0x7eD598BcEf8bd9Edd8C97A195C6d13f40801EC7e ↗

All application integrations consume one deployment manifest. The company protocol can launch before the final INFINITE token. In that state staking remains disabled; the Revenue Vault accepts the canonical token address exactly once after launch, then the manifest reflects the same address 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.

Activity feeds show recent events. Company counts, balances and revenue totals are read from the contracts independently of that feed. Follow the explorer links for a full transaction history.

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.