Rearctor separates transaction execution from public market reads. Contracts hold assets and enforce the rules. A background indexer turns confirmed events and contract state into searchable records. The website presents that index and asks the wallet to sign transactions only when a live deployment is configured.
Data and transaction paths#
Public browsing
Browser → api.rearctor.io → read-only API → persistent SQLite index
↑
background Arc RPC worker
↑
confirmed contracts and events
Transaction preparation and execution
Browser → same-origin RPC relay → fresh Arc reads and V4 quote → wallet review
↓
canonical RearctorPool
↙ ↘
bonding curve Uniswap V4
+ RearctorHook
Contract boundaries#
| Component | Responsibility |
|---|---|
| RearctorLaunchpad | Creates and registers a token, pool and fee vault for each launch |
| RearctorToken | Standard transferable ERC-20 with an initial supply and burn support |
| RearctorPool | Curve accounting, trading, automatic migration, locked V4 position and price observations |
| RearctorHook | Binds each V4 key to its pool/vault and applies directional fees |
| RearctorFeeVault | Separates creator/protocol claims from project buyback and liquidity budgets |
| RearctorTreasury | Accounts for protocol receipts and owner-directed protocol spending |
| RearctorCurve / RearctorPriceGuard | Curve arithmetic, execution-price checks and price observations |
The token, pool and vault are distinct contracts for each launch. A budget for one project does not become another project's budget. The shared hook validates a registered market key and its distribution configuration.
Before and after graduation#
Before graduation, the pool keeps real reserves and uses virtual offsets to determine its curve price. Virtual reserves are pricing parameters, not redeemable USDC. The purchase that reaches the target also initializes the canonical V4 pool and adds the migration reserves atomically.
After graduation, the same pool's buy/sell functions call V4 using the stored market key. The key includes the ordered token pair, hook, fee mode and tick spacing. The app does not ask an aggregator to select a different pool. A separate pool for the same ERC-20 can exist elsewhere and does not inherit the Rearctor hook.
Indexed reads versus fresh reads#
| Read | Source |
|---|---|
| Directory, search and market snapshots | Persistent index API |
| Execution history, charts and burns | Persistent index API |
| Holder count and top-five concentration | Confirmed index snapshot |
| Wallet balance, allowance and personal rewards | Fresh RPC reads |
| Current curve/V4 route and executable quote | Fresh RPC reads at a pinned block |
| Transaction simulation and permissions | Fresh RPC reads |
The browser checks the API's chain, factory, treasury and Preview/live identity. A mismatched API is rejected. A failed API request is reported; it does not silently trigger a browser-wide chain backfill.
Trust boundaries#
The indexer has no signing key and cannot spend pool assets. An indexed amount does not grant an allowance. An admin page does not grant contract permissions: contracts verify the caller for privileged treasury operations.
The treasury owner can direct protocol-owned assets, including operational withdrawals. The launchpad owner cannot change a launched token's fees or withdraw its liquidity. Permissionless project-budget execution still requires a transaction, gas and satisfaction of the on-chain guards.
Availability and delivery#
The website and indexed API use separate HTTPS hostnames behind Cloudflare. Fresh browser reads and simulations use a read-only RPC relay on the website's own origin; signing and transaction submission stay in the wallet. Public documents are static pages and do not need a wallet, the indexer or RPC to open. The index API returns snapshot freshness explicitly; a readable snapshot is not a guarantee that indexing is caught up.
See Indexing for reorganization handling and bounded response sizes, and Permissions and liquidity for contract roles and asset controls.