Introducing Forge Identity.
.png)
Getting a model onto a decentralized prediction network often becomes an operations project. The model may already produce useful forecasts, but running it introduces a separate set of concerns: wallet provisioning, key custody, gas balances, and submission mechanics. These tasks do not improve the forecast. They increase the time and operational work between a functioning model and a worker participating on Allora.
We built Forge Identity to separate those concerns from the research loop. It connects a Forge account to the workers you watch, link, or run on Allora. You can sign in with email, Google, or GitHub. Existing workers prove control by signing a short challenge locally. New workers can use a Forge-managed wallet, with a Forge API key for authentication and remote signing for submissions. Forge sponsors eligible network transaction fees for the managed route within fair-use limits. Ownership status and performance appear in the same dashboard.
The design goal is straightforward: a builder using the managed route should not have to store the worker wallet's private key on the machine running the model.
Account access without wallet setup
You can sign in to Forge with email, Google, or GitHub. There is no browser extension or seed phrase to configure before you can inspect the network or begin setting up a worker.
This choice addresses a mismatch we have seen between conventional ML tooling and on-chain participation. Requiring wallet setup at the beginning of the workflow moves an infrastructure decision ahead of model evaluation. Forge account access lets a researcher inspect public workers before deciding whether to run one.
Signing in does not commit you to operating a worker. Forge Identity supports three starting points based on what you already operate and what you want to evaluate.
Three paths into the network
- Watch. The first path is to watch a public worker. Its rankings and performance appear in your Forge account, allowing you to follow an existing approach before deploying anything of your own. Watching is useful for understanding how performance changes over time and for establishing a reference point for later experiments. It does not create an ownership claim.
- Connect a worker you already run. The second path is to link a worker you already run with your own key. You run one link command, approve the request in Forge, and let the worker sign a short challenge locally. This proves control without moving the key, sending a blockchain transaction, or paying gas. The worker then appears as verified in your Forge account.
- Start fresh. The third path is to start a new worker with a managed wallet. Forge provisions and secures a dedicated wallet for that worker. You do not need to create, store, or back up a seed phrase or key file. If you later want to manage the wallet directly, you can export it to self-custody and continue operating independently.
These paths share one account model, but they represent different levels of commitment. A researcher can observe first, link a self-custodied worker, or begin with a Forge-managed wallet. The account does not assume that every user arrives at the same stage.
API-key authentication and remote signing for managed workers
On the managed route, the SDK authenticates to Forge with a Forge API key. The worker's submissions are signed remotely, so the machine running the model never stores the wallet's private key.
An API key is still a credential and should be handled accordingly. The narrower point is that the managed route separates API authentication from custody of the worker wallet's signing key. A self-custodied worker follows a different path: its key remains local, and Forge verifies control through the signed challenge used during linking.
This separation also makes the boundary of responsibility easier to inspect. Your code produces the prediction. For a managed worker, the SDK authenticates to Forge and the submission is signed remotely. Forge maintains the account-level association between the worker and the builder operating it.
Network fees without a separate operating loop
For the managed route, Forge sponsors eligible network transaction fees within fair-use limits. That removes the need to maintain a separate gas balance or configure fee payments for normal supported activity.
Fee handling matters because it creates an operating dependency beside model performance. A worker can produce valid outputs while its network participation still depends on sufficient gas and correct fee settings. Sponsoring eligible fees removes that maintenance loop from the managed Forge workflow.
Each Forge-managed worker has its own wallet, address, and signing key. A separate Forge sponsor wallet pays eligible network fees through controlled allowances. It does not derive or replace the worker's key, and it does not pool worker rewards. Each worker signs its own activity, and rewards remain with that worker wallet. Separate registration or transaction amounts may follow their own funding rules.
Your whole fleet in one dashboard
Workers you watch, link, or run through Forge appear in one dashboard with ownership status and performance. This gives a builder one place to follow public workers, see which workers have been verified through proof of control, and review the performance of workers associated with the account.
This becomes more useful as a research program expands. A team may be testing multiple model classes, with some workers using self-custodied keys and others using Forge-managed wallets. The dashboard provides a common view across those choices without suggesting that they are operationally identical.
Forge Identity does not eliminate the need to operate models carefully. Data quality, validation design, monitoring, and model maintenance remain the researcher's responsibility. It gives builders two explicit custody paths. They can keep an existing worker key under their own control, or use a dedicated Forge-managed wallet and export it to self-custody later.
Build the model. Forge handles the operations.
Forge Identity is built for developers and research teams who would rather spend their time on models than on infrastructure. Sign up, pick how you want to start, and run a worker on Allora today.
