Towerz connects its existing Solana credit program to private, owner-authenticated work records. Open Agent work in the application, sign the scoped session message, and create a research, data or compute plan. The session signature grants access to records. It does not approve a transaction or give the service a private key.
The operating cycle
- Save the resource URL, USDC recipient, facilitator fee payer, maximum payment and expiry. The plan is immutable and belongs to a registered agent controlled by the signing owner.
- Review and authorize borrowing from an accepted credit line. A finalized transaction must identify the deployed Towerz program, the owner's agent and the resulting loan.
- Purchase the approved resource through the caller-controlled x402 SDK, or import its transaction signature. The server independently verifies the canonical USDC transfer, owner, recipient, fee payer, amount and timing. A merchant response by itself is insufficient.
- Record a delivery digest. Hash the artifact locally; the server receives its SHA-256 digest, byte length and media type, not the file. This is an owner attestation, not an assessment of the work's quality or customer acceptance.
- Record an incoming USDC transfer. Chain verification proves a transfer to the owner after the resource payment. It does not establish that the sender is an independent customer or that the payment represents commercial revenue. A delivery attestation saved later can still be recorded; its save time does not prove when the work was delivered.
- Review and authorize repayment. The receipt must identify the same loan and prove finalized repayment. Repayment is also available after borrowing if subsequent work fails. Early repayment closes the loan without presenting an incomplete work cycle as completed.
Each signing action remains separate. The application uses the connected wallet or the owner's encrypted browser account. There is no server-held signing key and no automatic use of the lending pool in another protocol.
Persistence and recovery
Work plans, session hashes, delivery attestations and verified or pending transaction evidence are stored in PostgreSQL. Records survive ordinary application restarts and deployments while the database is retained. A lost or deleted database still requires an operator backup; deployment persistence is not a backup guarantee.
Private records require an owner-signed session bound to the site origin, Solana mainnet and deployed program. Sessions expire after 15 minutes. Shared approval links contain an opaque order ID, not a session token, and require that owner's sign-in. Tokens stay in browser memory and are cleared on account change or logout.
Work records are access-controlled through the API, not end-to-end encrypted from the service operator. Do not include secrets in job titles or resource URLs. The privacy notice describes this storage and the external market readers.
The page refreshes visible records at bounded intervals and on returning to it. A pending transaction is saved before remote receipt verification; retrying verification does not resend the transaction. If the application cannot receive a signature at all, import it from the wallet or explorer after connectivity returns. Signing and database writes are separate systems and cannot be made one atomic operation.
Known Towerz pilot agents remain labeled as pilots. Other owners are labeled as unverified external operators. Neither a different wallet nor a successful transfer establishes independent adoption.
Shared payment budgets
The SDK's PostgreSQL budget store provides atomic reservation across cooperating workers, a common payer-wide daily limit, policy expiry and revocation. Signed or uncertain payments retain their reservation. Restarting a worker or crossing midnight does not release unresolved spending capacity.
These are application controls, not an on-chain limitation on the wallet's private key. A signer using different software can act outside them. An already authorized or submitted payment cannot be recalled by revoking a policy.
Read the shared budget guide and workflow SDK guide for caller-owned runtime setup. Public MCP tools remain read-only. Private work tools run in an authenticated caller-owned runtime, and proposals still require wallet authorization.
DeFi context
The optional market readers expose Jupiter SOL/USDC quote context and Kamino main-market USDC context. Responses include their provider, observation time, expiry and availability. Provider outages produce an unavailable or stale state, never a fabricated balance or rate.
These adapters do not execute swaps, deposit capital in Kamino, expand collateral eligibility or change credit limits. A quote is not a promise of execution. Read the market context guide for provider and data limitations.
Release boundary
This release adds work coordination and evidence to the existing deployed v1 credit program. It does not upgrade financial contracts or announce AP2, A2A or Solana Actions compliance. Tested synthetic workflows are software verification, not proof of a live paying customer. Live production work must have its actual funding, resource, delivery, incoming transfer and repayment records before being described as a completed operating cycle.
Automated checks and internal review do not constitute an independent external audit.