Skip to content

Standing payment authority through intermediate and leaf grants #218

Description

@EfeDurmaz16

Following the discussion in #179, this issue explores bounded authority for repeated payments. It does not propose new settlement schemes.

Use case

An owner approves spending with a provider under agreed terms. A supervisor issues short-lived grants to workers without asking the owner to approve each payment.

The agreement, billing period, worker lifetime, and grant lifetime may differ. Replacing a worker or renewing a grant must not reset the shared budget.

Starting point

Use an owner-signed intermediate grant to bound the supervisor's authority. The supervisor issues narrower leaf grants. Intermediates cannot authorize payments directly.

The design should cover:

  • Approved providers, assets, amounts, billing periods, and expiry.
  • Shared limits across workers, including spending already authorized but not yet settled.
  • Cancellation and revocation, including any wallet or payment-network authority already issued.
  • A clear distinction between paid access and permission to spend again.

Open questions

  1. Who enforces the shared budget, and when is spending reserved, counted, or released?
  2. Which actions need a fresh buyer signature, and which may use prior approval, such as subscription renewals?
  3. How do grants bind to agreed terms and payment records without assuming one grant per request or settlement?
  4. How should access periods, billing periods, and grant lifetimes relate? What happens when a grant expires while paid access or a previously authorized payment remains outstanding?

x402 SIWX and MPP subscriptions/sessions are useful reference points, not required dependencies. Wallet authentication alone should not confer payment authority.

The goal is to agree on responsibilities and lifecycle rules before choosing fields or a storage model.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions