Skip to content

[Feat]: Standardized budget limitation field #133

@amcaplan

Description

@amcaplan

Is your feature request related to a problem? Please describe.

I am concerned about the potential of this protocol creating contracts that aren't legally binding in the human-not-present scenario. It's difficult to argue that "Buy me some red shoes" constitutes a binding contract when the price for shoes ranges across several orders of magnitude. The terms are simply too vague.

If the IntentMandate doesn't include a budget as a mandatory field, this is likely to get very messy in the court system down the line, and create trouble for merchants and buyers alike.

A couple of additional benefits would accrue if there were a mandatory budget field.

First, it would create a simple hook for merchant-side systems to exclude transactions reliably as falling outside the payment mandate; if it's over budget, don't accept the order.

Additionally, from a practical perspective, it will be easier to get users to trust agents (which, famously, don't always do what you ask them to do) if they know how much money they are putting on the line.

Describe the solution you'd like

It would be much easier to ascertain the intent of the buyer if budget were a mandatory portion of the intent mandate.

Obviously, payment strategies can take many forms. For example:

  • Spend no more than X (but, ideally, as little as possible) to fulfill my request
  • Purchase something if the cost drops at least 20%
  • Renew my subscription if the cost hasn't risen more than $5
  • Buy the best tickets I can get to this concert under $500

The full strategy of weighing money vs. value is not necessarily something that can be captured easily in a standardized way. But simply requiring a maximum budget for the non-human-present scenario would go a long way in establishing the scale of transaction the user intends to agree to.

And it's hard to argue that there are many situations where money truly is no object.

Describe alternatives you've considered

The current solution does accept payment as part of the natural language description. However, not all users will necessarily fill that in, and not all agents will be careful enough to ensure that budgets are defined. Additionally, it's more difficult to evaluate simply and objectively simply because it's buried in natural language and not a programmable standardized field.

Additional context

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions