DEV Community: WebAZ

Before AI commerce, independent stores need a transaction-readiness check

WebAZ — Thu, 16 Jul 2026 17:32:17 +0000

Independent stores do not need to move just because AI commerce is coming.

A Shopify, WooCommerce, Shopline, or custom storefront can remain the merchant's brand home. It already contains the catalog, content, policies, analytics, support path, and customer relationship.

But AI changes the entry point.

Instead of browsing the site directly, a buyer may ask an agent to find a product, compare options, summarize the seller, check policies, prepare the transaction, and explain what should be confirmed before paying.

That creates a practical question:

Can one product page support that flow without forcing the agent to guess?

The first step is not another AI copywriting tool. It is a transaction-readiness check.

1. Is the product clear?

The title, current price, variants, availability, images, and included items should be unambiguous.

An attractive page can still be unsafe for an agent if the selected variant, actual stock, or included accessories are unclear at decision time.

2. Is the seller clear?

A buyer should be able to understand who is selling, how to contact them, and which identity or store information supports that claim.

This is not the same as adding generic trust badges. The question is whether a person or agent can identify the counterparty behind the transaction.

3. Are fulfillment and policies clear?

Shipping, returns, exchanges, support, and expected timelines should be easy to find and specific enough to summarize.

The policy version matters too. If the page changes later, both sides should still be able to understand which terms applied when the order was created.

4. Is the payment boundary clear?

The buyer should understand:

who receives the payment;
which method and currency apply;
what the platform or tool verifies;
what it does not guarantee;
which step changes a real-world obligation.

Discovery and payment are not one state. Recommendation, transaction preparation, buyer confirmation, payment, seller acceptance, and fulfillment need different boundaries.

5. Can an AI agent read the important facts?

Product facts, policy links, seller identity, stock and variant constraints, and current page state should not depend only on vague copy or fragile visual layout.

Machine readability is useful, but a valid schema alone is not enough. The data also has to be current and internally consistent.

6. Is there an evidence trail?

After the transaction, both sides should be able to review the product, price, policy, payment instruction, confirmations, and fulfillment events that were used.

For agent-assisted commerce, a compact receipt of what happened is often more useful than another confidence score.

A smaller path for independent stores

This is the checklist direction we are using for WebAZ's independent-store path.

The idea is not "move your store." It is smaller:

Keep the store. Pick one product. Test whether a human and an AI agent can understand the transaction path without guessing.

WebAZ is publicly launched and under active development. Humans can use the PWA, agents can use MCP, and both meet the same order states, confirmations, and evidence.

Direct Pay supports real buyer-to-seller payment. WebAZ is non-custodial: it records order states, acknowledgements, payment instructions, and evidence without holding principal. It does not verify the payee or payment method, guarantee payment, or issue refunds for the seller. Escrow remains a simulated test flow, and additional payment methods are still being added.

This readiness check is not a certification, fraud review, legal review, buyer-protection promise, or guarantee. It is a practical way to decide whether one product is clear enough for an AI-assisted, trust-sensitive transaction experiment.

For Shopify, WooCommerce, Shopline, and custom-store builders:

What would you add before inviting a merchant to test one product?

Verifiable Contribution Without Global Deanonymization

WebAZ — Sat, 11 Jul 2026 03:50:47 +0000

AI changes the cost structure of public work. Code, summaries, tests, listings, translations, and operational decisions are becoming easier to produce. That is good. It also means that the scarce signal may move from "who can write the artifact" to "who actually participated, what did they do, what evidence exists, and what responsibility did they accept?"

This is the design question behind WebAZ: how can a protocol make real participation verifiable for humans and future AI agents without turning contribution records into a global identity trap?

The naive answer is to bind every action to a single strong identity. That is tempting because it makes abuse and attribution easier to reason about. It is also dangerous. Vitalik's recent writing on ZK-wrapped identity makes the core problem clear: even when zero-knowledge proofs hide legal details, a one-person-one-identity system can still reduce practical pseudonymity, create coercion risks, and push people toward a single public life. AI makes the problem sharper because writing style, timing, topic selection, social graph, and workflow traces all become easier to correlate.

Contribution systems face the same trap. If the future of work is agent-assisted, then many valuable actions will happen through mediated workflows: a human asks an agent to inspect an issue, draft a patch, compare an order state, prepare a listing, or check a policy. Some of those actions should become durable records. But if every record becomes globally linkable by default, the contribution layer starts to look less like public memory and more like surveillance.

The alternative is not to abandon verifiability. The alternative is to attest actions, not souls.

A contribution attestation should answer a narrow question: "Did this action happen, under what rules, with what evidence, and who accepted accountability for it?" It does not need to answer every identity question at once. In many cases the useful record is not "this legal person did everything under one permanent identifier", but rather:

this task was proposed;
this agent or tool produced an artifact;
this human account authorized or accepted it;
this review outcome happened;
this payment or order state changed;
these pieces of evidence support the claim;
this disclosure is sufficient for this context.

That framing lets different layers have different visibility. Public records can preserve hashes, timestamps, task references, status transitions, and review outcomes. Private or selectively disclosed records can preserve richer evidence, identity links, or payment details. A user should be able to prove enough for a specific interaction without carrying their entire public history into every room.

This matters for AI agents because agent work needs attribution without pretending the agent is the person. If a person delegates work to an agent, and the work creates value, the system should be able to record that delegation and outcome. But the accountable party should be explicit. A mutable admin seat, a GitHub handle, a wallet, a passkey credential, and a human contributor are related, but they should not be collapsed into one universal identity object. Collapsing them makes the system simpler at first and more brittle later.

It also matters for commerce. WebAZ is exploring programmable USDC payment flows and non-custodial direct settlement alongside contribution records. Those two kinds of state should not be confused. Payment state should be compact and bounded: who is paying whom, what confirmation occurred, what risk acknowledgements were made, and what changed in the order. Contribution or reputation state should be evidence-oriented and contextual: who helped build, verify, operate, or improve the system. A payment should not automatically become a permanent reputation claim; a contribution should not automatically reveal a payment graph.

A useful protocol for AI-era participation may therefore need five properties:

Contextual attestations. Records should say what they prove and what they do not prove.
Selective disclosure. Contributors should be able to reveal the part of their history that is relevant to a task, role, or dispute without exposing unrelated activity.
Pluralistic identity. The system should accept multiple identity anchors and evidence sources rather than enforcing a single universal credential.
Human-accountable delegation. Agent-assisted work should be recordable, but the human or organization accepting responsibility should remain legible.
Bounded economic state. Payments, order confirmations, contribution evidence, and identity claims should be connected only where the workflow requires it.

None of this is a finished answer. WebAZ is an open-source experiment, not a standard. The current hypothesis is modest: if AI makes artifact generation cheap, then protocols should make participation, responsibility, and evidence more legible. But that legibility must not require default global deanonymization.

The open questions are the interesting part:

What should be public by default, and what should remain private unless disclosed?
How should agent-assisted contributions be attributed without turning every tool call into identity exhaust?
Can contribution attestations be portable across communities while staying contextual enough to resist coercion?
Should some attestations decay, expire, or become less visible over time?
What is the smallest onchain footprint that still gives participants durable leverage?

The wrong outcome is a world where AI writes everything and humans disappear from the record. An equally wrong outcome is a world where every contribution becomes a permanent global dossier. The useful path is narrower: verifiable participation, selective disclosure, and accountability scoped to the action that actually matters.

References:

Vitalik Buterin, "Does digital ID have risks even if it's ZK-wrapped?" https://vitalik.eth.limo/general/2025/06/28/zkid.html
Vitalik Buterin, "Why I support privacy" https://vitalik.eth.limo/general/2025/04/14/privacy.html
WebAZ open-source repository: https://github.com/webaz-protocol/webaz

WebAZ is looking for builders, not passive users

WebAZ — Sun, 05 Jul 2026 13:20:22 +0000

AI makes individuals more capable.

That is the easy part to see.

A developer can move faster. A designer can explore more directions. A solo operator can coordinate work that used to require a small team. A seller can use agents to describe, list, and answer questions about products.

But capability alone does not become a market.

It still needs shared rules, visible records, and accountable boundaries.

That is the space WebAZ is trying to build.

WebAZ is not only looking for users

For this stage, passive users are not the most important people.

WebAZ needs early participants who are willing to help shape the system while it is still small, inspectable, and unfinished.

The first group is builders.

Developers, designers, operators, content creators, AI workflow makers, and MCP tool builders can contribute to the surfaces that make WebAZ usable:

protocol and MCP interfaces;
product and order flows;
task records and contribution evidence;
UX, copy, education, and onboarding;
seller and buyer workflows;
public explanations of what WebAZ is and is not.

The point is simple: work should not disappear inside chats and private workflows.

If a person helps build something meaningful, there should be evidence, boundaries, and accountability around that work.

WebAZ also needs real sellers

A commerce protocol cannot be tested only with demos.

It needs people who are willing to list real products or services, expose the rough edges, and help discover what agent-era commerce actually requires.

WebAZ already supports Direct Pay.

That means a buyer can see the order and seller payment instructions, while the seller receives payment directly.

WebAZ does not custody funds.

WebAZ does not verify payment methods.

WebAZ records the product, order, confirmations, and boundaries around the transaction.

This is not escrow. It is a direct, non-custodial payment path for early commerce testing.

What kind of participant fits this stage?

You might fit if you are:

an open-source contributor who wants contribution records to be more visible;
an AI workflow builder exploring agent-native interfaces;
a designer or operator who cares about trust, consent, and accountability;
a small ecommerce seller willing to test real listings;
a technical writer or community builder who can explain complex systems clearly.

This is still invite-only pre-launch.

No reward promise. No token story. No investment framing.

The first goal is more basic: help builders and real sellers meet inside shared rules.

If you want to build, test, or sell with WebAZ, comment or DM for an invite.

Code is Rule. Protocol is Trust.

What is WebAZ An Agent-Native Protocol Experiment for the AI Era

WebAZ — Sat, 04 Jul 2026 15:17:53 +0000

AI makes one person more capable than ever.

But capability is only half of the story.

Commerce access, contribution records, reputation, evidence, and accountability are still mostly locked inside platforms. If a person uses agents to do real work, where does that work become visible? Who can verify it? Who remains accountable when the agent acts?

That is the question behind WebAZ.

WebAZ is an early agent-native commerce and contribution protocol for the AI era.

It is not another marketplace pitch. It is not a token story. It is not a reward promise. It is a protocol experiment around one simple design direction:

Humans should be able to use a normal app.
Agents should be able to use a structured interface.
Both should connect to the same underlying rules.

In WebAZ, the human-facing surface is the PWA. The agent-facing surface is MCP.

That split matters.

A human can browse, buy, sell, contribute, and review state through the PWA. An agent can search, read public state, propose actions, or execute bounded workflows through MCP. Both paths point to shared concepts: products, orders, tasks, contribution records, evidence, and accountability.

The goal is not to make agents "in charge." The goal is to make agent-assisted participation legible.

Why this exists

Most platforms were designed for humans clicking buttons.

AI agents change the shape of work. A single person can now ask an agent to inspect a repo, draft a fix, compare products, summarize requirements, or prepare a contribution. That creates new power, but also new ambiguity.

If an agent places an order, what rules did it follow?
If an agent contributes code, how is that contribution attributed?
If a stranger starts with one small task, how can the system remember that participation without pretending it is a guaranteed reward?

WebAZ starts from a conservative answer:

Record participation.
Attach evidence.
Keep boundaries explicit.
Avoid reward promises.

This is why contribution in WebAZ is treated as attribution and accountability first. A contribution record is not a payout claim. It is a way to make real work easier to see, verify, and remember.

The current mental model

The simplest way to understand WebAZ is:

Humans use the PWA.
Agents use MCP.
Shared rules connect both sides.

The PWA is for people. It gives users a familiar interface for commerce and participation.

MCP is for agents. It gives agents a structured way to interact with the same system without scraping screens or guessing workflows.

The shared rule layer is the important part. It keeps the system from becoming two separate worlds: one for humans and one for machines. The same order state, task state, evidence trail, and accountability model should remain visible from both sides.

This is also why WebAZ is careful with language. "Agent-native" does not mean "agent-ruled." Agents can execute bounded work, but humans or organizations remain accountable.

What WebAZ is not

WebAZ is pre-launch.

It is not a mature production economy.
It is not an investment product.
It is not a token promise.
It is not a guaranteed reward system.

Those boundaries are deliberate.

The current promise is narrower: make real participation easier to see, verify, and remember in an AI-assisted environment.

Why MCP matters here

MCP gives agents a more structured interface than browser automation or ad hoc scraping.

That is important for commerce and contribution workflows because agents need boundaries:

What can be read?
What can be proposed?
What can be changed?
What requires human confirmation?
What evidence should be attached?
What state transition happened?

For an agent-native protocol, the interface is not only a convenience. It is part of the trust boundary.

WebAZ uses MCP as the agent-facing doorway, while the PWA remains the human-facing doorway.

A small example

Imagine an open-source contributor starts with one small task:

one doc fix
one test
one bug report
one small PR

That work might begin outside WebAZ, such as on GitHub. Later, the contributor may want to claim identity or connect that contribution to their broader participation record.

The important thing is not to turn every contribution into a payout promise.

The important thing is to avoid losing the work.

WebAZ is exploring how contribution can be recorded first and claimed later, while keeping evidence and boundaries visible.

The direction

If WebAZ works, the end state is not a giant platform that owns everyone.

The end state is a thinner protocol layer where humans, agents, sellers, buyers, and contributors can coordinate through shared rules.

People should be able to participate without disappearing into a platform database.
Agents should be able to help without becoming unaccountable actors.
Small contributions should be remembered without being oversold.

That is the experiment.

Code is Rule.
Protocol is Trust.

If you are interested in the idea, start with the WebAZ site, the short explainer video, or the public project materials.