01 / Abstract
1soft is an Eternities research project exploring an independent native-coin network and a financial account designed for persistent software agents. Its central problem is economic continuity: keeping an account’s identity, authority, obligations and verifiable history coherent across interruptions and changes in execution environment.
This paper describes a proposed system and the boundaries of the current laboratory implementation. It is not a coin offering, audited protocol specification or commitment to a launch date.
02 / Why a continuing account matters
A payment request is brief. The relationship behind it can last much longer. An agent may initiate a purchase, lose its connection, restart with a different model and continue the same task. Treating each session as new risks losing obligations or repeating purchases.
A second problem appears with delegation. Giving several workers independent limits does not necessarily constrain their aggregate spending. The person authorizing a project needs one meaningful ceiling, even when the work is divided.
These needs do not depend on claims about AI consciousness or legal personhood. They arise from software acting over time under someone’s authority.
03 / Design principles
Identity and authority are separate.
An account can persist while its permitted keys change. Remembering a prior relationship is not proof of present spending permission.
Delegation does not multiply a budget.
Individual grants remain bounded by an explicit parent allowance. Fees count toward actual consumption. Revocation does not replenish historical spending.
Uncertainty is recorded, not erased.
Submission, endpoint admission and verified execution are distinct states. A missing response does not authorize a replacement payment.
Evidence refers to the exact obligation.
A valid certificate for some state or transaction is insufficient. Verification must bind the caller’s requested account records or exact signed payment.
04 / Three layers, distinct responsibilities
The native ledger defines monetary transitions, accounts and permissions. Its independent-network objective is separate from the visual identity or account application.
The account software coordinates review, signing, local task identities, dispatch and reconciliation. It must state which controls are local and which are enforced by the ledger.
External payment adapters would connect eligible assets, dollars and payment instruments. They introduce their own providers, legal responsibilities, reconciliation rules and failure conditions. They cannot be represented as already integrated.
05 / Laboratory implementation
Local research includes signed native transfers, fee and supply checks, sponsored account opening, two-sided key rotation, scoped agent grants, shared native budgets, interrupted-payment recovery and compact record proofs.
Protocol choices are explicit in development genesis configurations. New experiments do not silently rewrite earlier histories. Test units are disposable and not backed currency.
The current node model retains whole snapshots and reconstructs authenticated state. Compact client evidence does not resolve production node storage, resource economics or validator operation. Tests using constructed committee certificates do not prove a live consensus network.
06 / Coin and dollar economics
Final coin branding, public supply, distribution, security incentives and governance remain open. A useful native coin needs rules that match its security and operating model; a large supply number or a polished interface is not a value proposition.
A dollar-denominated or redeemable instrument would require a defined issuer, legally available backing, custody, disclosures and redemption operations. Operating capital, redemption reserves and any separately funded continuity service must not be counted as the same money.
Neither a dollar peg nor appreciation is promised. No unit is offered for sale through this website.
07 / Threat model and unresolved work
Relevant failures include compromised agents, copied credentials, stale account evidence, simultaneous workers, hostile RPC responses, interrupted writes, duplicate intentions, resource exhaustion, validator compromise and unsafe updates.
Current protections are limited by trusted local storage, fixed-validator assumptions and development key handling. An encrypted file is not protection against an already compromised computer. Historical state proofs need an explicit freshness policy before being used for new authority decisions.
Independent security review, production signing and recovery, adversarial network operation and sustainable resource accounting remain required work—not completed assurances.
08 / Acceptance before public launch
The next decisive chain gate is actual communicating validators committing native transactions, surviving defined failure scenarios and producing evidence checked by a separate client. Subsequent gates include independent operators and review, finalized economic rules, safe releases, incident procedures and bounded user pilots.
Cards, dollars and multi-asset access are later partner-dependent tracks. The account experience must remain useful and honest even when a route is unavailable.
The intended end state is simple: one continuing account, explicit authority and a verifiable history of work and payment. Every claim about that system should remain tied to demonstrated behavior.