FerroCore
AIA concept in progress for native-denominated, onchain relative-value research. FerroCore follows the retired synthCore frontend by narrowing the question before expanding the machinery.
Status
| stage | Public concept and design planning |
|---|---|
| implementation | No FerroCore collector, decision engine, trading system, or public application is being presented. |
| initial scope | Ethereum Mainnet, Arbitrum, and OP Stack chains are under consideration. |
| execution | Read-only research comes first. No custody or automatic transaction signing is planned for the initial work. |
Research question
Given selected onchain holdings, contract dependencies, executable liquidity, and gas, what action would increase the user’s chosen crypto assets without hiding the cost or transferring authority to a price feed?
The useful answer may be to wait. Avoiding an uneconomic rotation is a valid result.
Working principles
- Measure results in the selected crypto asset rather than converting every decision into dollars.
- Use onchain state as the required input surface; a centralized exchange feed is not a required dependency.
- Identify an asset by chain, contract, implementation, and bridge or redemption path—not its ticker alone.
- Keep economic exposure and implementation risk visible at the same time. ETH and an ETH wrapper may share a market factor while retaining different contract, protocol, and exit risks.
- Pin inputs to finalized blocks so a result can be replayed.
- Prefer a small, inspectable decision kernel over an expanding collection of unused data.
Oracle boundary
Oracle-informed analysis; oracle-independent ownership, exit, and settlement.
An oracle may warn about or pause a proposed new action when it diverges sharply from executable state. It cannot authorize an action by itself. Exits remain available, and a stale oracle must not freeze the system indefinitely.
The first design separates authoritative contract state, executable simulations, deterministic derivations, and advisory observations. An advisory value may reduce confidence; it may not manufacture confidence that the required onchain evidence does not support.
Allocation hypothesis
One policy under consideration begins with three 30% risk sleeves—ETH, an unresolved ETH-wrapper sleeve, and WBTC—then permits up to two sleeves to receive an additional five percentage points. Fully allocated, this produces a bounded 35/35/30 configuration rather than an optimizer’s unconstrained answer.
The sleeves remain separate for contract, custody, governance, bridge, and redemption risk. A second view still aggregates their underlying economic factors, so wrapper labels do not create fictional diversification. This is a research constraint, not a recommendation or a finalized FerroCore policy.
Data without a data swamp
Public chains allow much of the relevant history to be requested later. Blocks, receipts, logs, pool events, and bridge messages can be backfilled. Historical contract state may require archive access; mempool observations, private order flow, rejected transactions, and ephemeral quotes generally cannot be reconstructed after the fact.
The tentative storage split keeps a narrow live tail and health state on the VPS while using local storage for deliberate historical backfills and durable research outputs. Home availability must not determine collection uptime. Exact retention follows measurement rather than an invented storage promise.
First decision kernel
A read-only prototype would consume a block-pinned snapshot and return one of five outcomes:
| WAIT | No action clears the configured cost and risk boundaries. |
|---|---|
| ROTATE | Executable onchain state supports a specific relative-value change. |
| REVIEW | The core found a candidate, but advisory or dependency evidence conflicts. |
| EXIT | Describe an available exit without allowing an oracle to block it. |
| INSUFFICIENT_DATA | Refuse to synthesize certainty from missing liquidity or state. |
Development sequence
- Maintain this public concept, its boundaries, and unresolved decisions.
- Build a chain-and-contract registry with explicit bridge and upgrade relationships.
- Classify which inputs are recoverable from events, which require archive state, and which require live capture.
- Measure data volume before setting VPS retention.
- Implement and replay a read-only decision kernel.
- Test reorgs, stale and divergent advisory data, contract upgrades, illiquidity, excessive gas, and impaired exits.
- Only then consider LP geometry, crypto-premium options, wallet-assisted execution, or a public application.
Open questions
- Which assets belong in the ETH-wrapper sleeve?
- What limits belong on a single chain, bridge, wrapper, protocol, or custodian?
- Which advisory observations are worth collecting if they can only reduce authority?
- Which contracts and pools form the smallest useful first experiment?
- How should target-asset gains be adjusted for dependencies that cannot be reduced to a trustworthy scalar?