Builder access

Access to a service and access to its money are separate. Your account controls who can manage the hosted service. Signing keys identify the builder and its records. Payment keys and wallet connections control different parts of receiving, refunding, and paying out funds. Keeping one credential does not replace backing up the others.

Account access

The Cloud account grants platform access through a browser login or an API key. An agent uses that access to manage services on behalf of the builder. The authentication reference describes the consent flow, local token storage, and headless setup.

Revoking a platform key removes that key's platform access. It does not rotate a payment key, change a recipient address, or revoke an unrelated wallet connection. These credentials have different owners and recovery paths.

Organization scope

The selected organization determines which services an operation addresses. A personal context and a shared organization can coexist under the same account. Check the returned organization and service identity before a remote change; a familiar display name alone is insufficient.

A transfer changes control of a service. Cashu funds may also require a treasury re-key. When the platform reports a pending re-key, the service needs the corresponding redeployment before payouts resume. The dvmctl reference specifies organization selection and transfer commands.

Signing and recovery

The builder signing identity is distinct from the Cashu recovery mnemonic. The signing identity attests to deployments. The mnemonic derives keys that can recover ecash locked to the builder's DVMs.

The CLI reveals recovery words only through its human-output path. An agent must not treat a successful key-creation command as proof that the builder saved those words. Losing payment recovery material can leave funds inaccessible even when the Cloud account still works.

Replacing a recovery identity can affect every service using it. Preserve existing material and establish the affected services before any rotation. The installed skill's deployment and recovery procedures carry those checks.

Wallet connections

A Lightning receiving connection may create invoices and check payment. It must not have permission to pay invoices. A refund worker can use a separate spending connection to acquire ecash for caller refunds. A payout connection can receive the builder's Lightning proceeds.

Keep each connection with the component that needs it. Payments and payouts explains where the funds move. A change in service ownership does not prove that every external wallet's permissions changed with it.