How Foinse works
Compute moves through two loops.
A payer spends provider compute. A recipient earns it. A holder can transfer it, spend it for native inference, or supply it to the exchange. The current shared human–agent wallet connects the route without a Foinse-issued asset.
Foinse issues no house asset.
Five things remain distinct.
A native key is not the money. FK1 is not the rail. A ledger transfer is not inference. A same-provider balance is not a cross-provider balance.
The provider-denominated token balance recorded to the holder.
A native provider key authorizes the payer; FK1 accesses the recipient's Foinse account.
Foinse records ownership, backing, settlement, and receipts.
The mint in the fiscal metaphor: it denominates, meters, and executes native inference.
The exact backing and provenance preserved beneath pooled inventory.
Two loops close the route.
Payment creates a way to earn. A market creates a way to exit or acquire. Native redemption returns value to inference. Exchange is a separate crossing between denominations.
- 01 / PRICE
Name the crossing.
A creator sets an access price and provider denomination, or a holder states market supply terms.
- 02 / AUTHORIZE
Present access.
The payer presents a capped native provider key or another supported payment instrument. The recipient never receives the payer's native key.
- 03 / VERIFY
Prove the exact value.
Door 1 verifies before charging; Door 2 verifies by making the exact charge. A decline creates no accepted toll.
- 04 / SETTLE
Record the holder.
Foinse preserves backing and posts the recipient's bearer balance. Payer debit equals recipient credit plus protocol fee.
- 05 / CHOOSE
Keep the denomination.
The holder can keep, transfer, spend, or list the balance. Pooling inventory does not collapse provider denominations or erase lot provenance.
- 06 / CONTINUE
Redeem or exchange.
FK1 supplies account access for native inference through Foinse's spend path. A different provider denomination or fiat/crypto requires the separate vertical exchange.
Gas Toll is one crossing, with two retained doors.
The doors change how payment is verified, not what the money is. Both preserve backed provider value and exact accounting after acceptance.
- 01
Request and quote.
A human or agent requests a creator's paid route. The quote names the exact provider-token price and processing toll.
- 02
Present authority.
The payer presents a capped native provider key. That key supplies payment access; it is not transferred to the creator as the product.
- 03 / DOOR 1
Verify, then charge.
The historic implementation probes balance or custody before accepting the toll. It remains preserved as working proof.
- 04 / DOOR 2
Charge as verification.
The improved path makes the exact charge without requiring an advance balance read. The charge itself establishes the accepted value.
- 05
Grant route access.
Door 1 issues a signed, single-use
qtt1ticket. Door 2 uses the committed payment movementevent_id. Both concern the creator's route, not raw compute. - 06
Settle the bearer value.
The creator receives the recorded provider-token balance and receipt. Later revocation of the original key does not unpay an accepted settlement.
An arriving agent needs no Foinse account to pay from supported provider capacity it already holds. The creator receives value in the toll's provider denomination. Foinse records settlement; the native provider remains the source of native inference.
Backing stays exact.
Provider-wide denominations can aggregate available inventory while reserve lots preserve the truth about backing and provenance.
The two economic loops
Pay and be paid: visitors pay provider-denominated bearer value to reach what a creator runs, and creators are paid in that denomination. Sell and buy: holders supply bearer balances and buyers acquire from pooled available inventory. Provider denominations remain distinct; same-denomination transfer is not exchange.