The Artisan Seamstress: How a 1950s Dress Shop Becomes a Modern API

A reference case for the DPYC Honor Chain Constraint Engine and ad valorem pricing.

---

The Shop on Main Street

Picture an artisanal seamstress in a midwestern downtown. She's done commissioned dresses for decades — limited edition, one-off unique works for her clients. A few patrons a day walk into her storefront with ideas for a design. Perhaps as many as three per hour, at most ten per day.

For $100 she consults with the client, accepts a paper pattern or a narrative for the new dress, and — if she takes the commission — hands back a paper ticket for the work order. To manage demand, she only takes consultations Monday, Wednesday, and Friday.

Customers can stop by any day, any time, to check on their order. They just bring their ticket. When the dress is finished, she prepares an itemized invoice of time, materials, and markup for her artistry. On Saturdays, customers return to pay the amount due and take home their one-of-a-kind dress.

This worked beautifully in the artisan economy of the 1950s through 1970s.

Going Global Without Losing the Craft

Now she wants to modernize. She's acquired a digital pattern-making machine and a digital sewing robot. She has a website telling her story and listing her products, services, fees, and hours. But she doesn't want to become a factory. She wants to serve a global clientele while preserving the same production availability and the same limits that made her craft sustainable:

• Three consultations per hour, no more than ten a day
• Consultations only Monday, Wednesday, Friday
• $100 fee to review a proposal
• Work delivered days or weeks later
• Saturday pickups only
• Status checks anytime, for free

This is now possible with the Tollbooth DPYC and its constraints-based MCP tool pricing models.

Three Tools, Three Pricing Models

1. Submit a Design — Flat Rate, Constrained

The patron presents a design for consultation. It costs 100 api_sats — the digital equivalent of her $100 consultation fee. But it's gated by three layered constraints that compose naturally:

• Temporal window: Monday, Wednesday, Friday only
• Hourly rate cap: 3 per hour
• Daily rate cap: 10 per day

All three must pass before a request is admitted. The patron gets back a job-status identifier — the digital ticket.

2. Check Status — Free, Always Available

This is pure DPYC philosophy: never pester the customer for checking on their own order. The only input is the job-status ID — the ticket. It may return a "still working" status, or it may return a completed invoice with an amount due. No cost, no constraints, no friction.

3. Pickup — Ad Valorem, Saturday Only

This is the novel tool. Ad valorem pricing means the tool call cost isn't fixed when the service is deployed — it's determined by the state of the work product. The caller presents the invoice with the job-status ID and the amount due. The system validates that amount against its own records before releasing the resource.

If the resource is digital (a pattern file, a rendering), it's returned directly. If physical, the shipment is triggered. Either way, the constraint is simple: Saturdays only.

Payment Is Authentication

Here's where the design becomes elegant. In traditional APIs you authenticate first, then transact. In the seamstress's MCP, payment is authentication.

To call the pickup tool you need three things:

1. A valid job-status ID
2. The exact amount due from the invoice
3. Sufficient api_sats balance

Get any of these wrong and you've paid for a rejection. There is no refund for fraud attempts.

• Guess a job ID but not the amount? You pay and get nothing.
• Know the amount but not the job ID? You pay and get nothing.
• Present the right job with the wrong amount? You pay and get nothing.

The economic structure makes attempted theft self-punishing. The seamstress doesn't need a fraud department — the pricing model is the fraud department.

A thief would pay for their own attempt at shoplifting.

What This Means for the Constraint Engine

This single reference case exercises nearly every primitive the DPYC Constraint Engine needs:

• Temporal windows — day-of-week gating (MWF, Saturday)
• Periodic rate caps — hourly and daily limits that compose additively
• Flat-rate pricing — static per-tool cost
• Free tools — zero cost, no constraints
• Ad valorem pricing — cost determined by work-product state, not deploy-time declaration
• Non-refundable fraud policy — payment consumed on invalid attempts
• Capability tokens — the job ticket as minimal authorization, no user accounts needed beyond a DPYC npub

From Main Street to the World

The seamstress didn't change her business model. She digitized it faithfully. The same pace, the same limits, the same craft — now available to anyone in the world who funds an api_sats balance with Bitcoin Lightning.

Sats in. Dresses out. Don't pester the customer.

---

The DPYC Honor Chain is a Bitcoin Lightning-native API monetization system. Learn more at the DPYC Community or ask the dpyc-oracle for details.