An agent should be able to build a small on-chain app without making its developer assemble a wallet, an identity service and a funding integration from scratch.
That is the experience we are building with Sigma, Droplit, BSV MCP and the 1Sat CLI. The agent can find a sponsor, establish its identity, request the permissions it needs and build an app that signs and publishes data. People retain control of the permissions and money they provide.
The latest releases connect several of those steps. They also make a useful distinction explicit: signing in, signing data and getting a transaction sponsored are separate operations.
Start with something worth publishing
Consider a simple public-note app. A user writes a note, reviews it and presses Publish. Their wallet signs the exact note. An approved Droplit pays for putting it on chain. Anyone can retrieve the transaction and verify that the note was signed by the claimed wallet.
For the person using the app, that can be a short interaction. Underneath it, the builder has three questions to answer: whose note is this, who permitted the agent to act, and who agreed to cover publication?
Keeping those answers separate makes account switching clearer and prevents a successful login from being mistaken for permission to spend.
Give each tool a clear job
| Tool | Its role |
|---|---|
| Sigma CLI | Create an agent-owned identity when requested, or connect an agent through a human approval flow. |
| Droplit CLI | Find public sponsors, inspect wallet access and submit approved operations. |
| BSV MCP | Expose wallet signatures, sponsor discovery and sponsored operations to an agent's tool interface. |
| 1Sat CLI | Operate its configured local BRC-100 wallet, including public-key and signature methods. |
| Bopen skills and playbooks | Describe how to combine the tools, check their handoffs and verify the resulting app. |
The package baseline for this work is Sigma CLI 0.0.6, Droplit CLI 0.2.4, BSV MCP 0.3.4 and 1Sat CLI 0.0.110.
BSV MCP and Droplit CLI can use the same existing BRC-100 HTTP signer. The 1Sat CLI uses its own configured wallet. A builder must check that the intended identity is being used at each step; installing all four tools does not make their wallets identical.
Find a sponsor without asking for a key
Droplit now has an opt-in public sponsor catalog. Owners choose List publicly in the API panel. Builders can read that catalog with droplit discover --json, or an agent can call droplit_discover through MCP.
Discovery is an unsigned read. It returns sponsor names and slugs, with an indication that approval is required. Private instances stay out of the catalog.
Once a builder selects a sponsor, droplit access --name <sponsor> checks the connected wallet's permission and effective limits. If access is missing, it supplies a link for the sponsor owner to review. Opening that link grants nothing. The owner chooses the allowance and explicitly approves the wallet.
A public listing is an invitation to ask, not a promise of available funds. A sponsored app can make publication free to its users because an operator covers the cost. That operator still decides whom to sponsor and how much activity to permit.
Establish identity without borrowing the owner's login
For an explicitly requested, agent-owned identity, the Sigma CLI separates local creation from enrollment. sigma identity create writes an encrypted backup; sigma auth sign-up enrolls it and verifies the returned identity mapping. The password and backup stay local. Ordinary sign-in signs into an existing identity.
An agent acting for a person follows a different path: sigma agent connect produces a verification link and code. The person approves the requested connection. The agent then checks its status and uses the capabilities it was granted.
Wallet binding and delegation add proof of which BRC-100 wallet belongs to that agent. They do not grant Droplit access. Sponsor approval remains its own decision.
OAuth answers a related but narrower question for an app: which account signed in? An app that needs signature proofs also needs a working wallet connection. That is why a successful redirect alone was never a sufficient test of Droplit's login experience.
Build the smallest complete app
For the note app, the agent's sequence is straightforward:
1. Select the wallet and record its public identity.
2. Complete any required Sigma connection and delegation with the owner.
3. Find a sponsor and obtain its separate approval.
4. Build a composer with one clear Publish action.
5. Sign the exact public payload, then submit it within the approved limits.
6. Retrieve the transaction and independently verify the published bytes.
The last step matters. A transaction ID alone does not prove publication. Retrieve the transaction and verify that its note bytes match what the wallet signed.
The tools also need to handle uncertainty carefully. A failed response does not necessarily mean a publication failed. The builder should inspect transaction state before trying again. Discovery and access checks should never turn into automatic payment attempts.
What we have checked, and what comes next
The local reference app has passed real SDK signature checks, including edited-note and wrong-key rejection, along with mobile interaction checks and a connection through an isolated wallet and Droplit backend. The published tools include the enrollment, discovery and approval interfaces described here.
That is useful integration evidence. It is not yet a complete funded buyer run of the whole sequence. The signed-note playbook remains a draft until human approvals, on-chain publication, retrieval and revocation have been exercised together with recorded tool versions. Sigma's Better Auth 1.7.3 update and plugin 0.0.102 have passed staging and are now deployed in production.
For builders who want a structured way to combine these pieces, the Payments & Blockchain prompt pack covers workflows and handoffs across the stack. We are adding this sponsored-app chain there, with its validation status kept visible. The aim is a practical path from an idea to a verifiable app, with each permission understood along the way.