Sol Service Model

Design customer-funded SOL contribution jobs

The EdgeORE swarm direction is customer-funded service contribution paid in SOL. It is not Solana mining, ORE earning or automatic token issuance. Solana consensus is not a phone mining workload. A useful service network must identify who wants a result, who funds it, who performs it, who evaluates it and how settlement or refund occurs. Without those roles, a rewards screen is only a promise.

Begin with a narrow paid service

Candidate pilot services include encrypted backup on owned nodes, bounded AI processing or licensed data tasks. Each needs a measurable result and an identifiable customer. Do not begin with general residential bandwidth resale, arbitrary proxy traffic or every type of compute. Those services carry additional abuse, privacy and availability risks that cannot be solved by adding a Solana payment button.

A job should define input identity, output requirements, resource bounds, deadline, price, verifier authority and dispute policy before acceptance. The node operator must understand what it will run and what data it may receive. The customer must understand which result will authorize payment. A timer, battery percentage or local CPU counter is not a contribution proof on its own.

Separate application states

A useful planned lifecycle is funded, assigned, working, result submitted, accepted or rejected, settlement pending and paid. Failure, cancellation, disputed outcome and refund should have explicit paths. An app receipt can describe an intermediate event without implying the customer accepted it. A settlement signature can exist while confirmation is still unavailable. Keep uncertainty visible through the whole workflow.

The interface should distinguish available jobs from hypothetical earnings. Show fees, minimum payout conditions and expected resource costs once those values are real. A user who contributes storage or AI work still pays for electricity, bandwidth, hardware wear and opportunity cost. Do not promise profit or display invented monthly SOL income. A small pilot should measure demand and unit economics before scaling claims.

Establish verification

For storage, a clean restore and timed retrieval challenge can establish bounded availability observations. For AI, a customer-defined evaluation can check a task result. For data, consent and licensing must be part of acceptance, not an afterthought. Each evaluator has a trust boundary. A signed evaluator decision is auditable but not automatically correct or trustless.

If an evaluator can release escrow, document who controls it and how users dispute mistakes. If several parties must approve, define threshold and timeout behavior. Avoid staking and automatic slashing as an initial shortcut: penalties require robust evidence and a clear appeal policy, especially when mobile connectivity is unreliable. Economic punishment does not repair a weak measurement protocol.

Gate the pilot

Before public SOL rewards, require a working funded job, completed service, accepted result, observed settlement, refund path, abuse controls and independently reviewed program logic. Use devnet to qualify the mechanism without pretending test SOL is income. Only after those gates should the site offer a contribution marketplace. For now, the roadmap can explain the model, while payment and earning rows remain NOT_IMPLEMENTED.

---

Wiki home · Qualification updates · Sources and credits