[DIS] Werra: Building Trust Infrastructure for Creator Commerce

Why?

Werra is a Kenya-first creator marketplace that helps SMEs hire verified content creators, structure content deals, and pay safely through escrow.

In Kenya today, many SMEs already hire creators for TikTok videos, Instagram Reels, UGC videos, product reviews, and creator visits. However, most of this activity happens informally through Instagram DMs, WhatsApp groups, referrals, and agency relationships.

This creates problems for both sides:

  • SMEs struggle to discover and verify reliable creators.
  • Creator pricing is unclear.
  • Deliverables are often vague.
  • Creators risk late or failed payments.
  • SMEs risk paying before agreed work is delivered.
  • Disputes are hard to resolve because agreements are informal.
  • High-attention creators are often under-monetized.

Werra solves this by giving SMEs and creators a structured transaction workflow:

  1. SME posts a content brief.
  2. Verified creators submit bids.
  3. SME reviews creator profiles, samples, pricing, and ratings.
  4. SME awards the gig.
  5. Agreement terms are generated.
  6. SME funds escrow.
  7. Creator delivers content.
  8. SME approves, requests revision, or opens dispute.
  9. Payout or refund is processed based on the outcome.

CKB fits where the product needs trust and settlement. Werra will use CKB infrastructure and USDI for escrow-protected creator payments, agreement hash anchoring, payout/refund transaction records, and future settlement automation.

Werra is not a blockchain-first product looking for a use case. It is a creator commerce product solving a real market problem, using CKB where transparent escrow and settlement matter most.


Market Research

We have completed initial market research into Kenya’s creator economy.

As supporting evidence, we reference the Odipo Dev report:

Decoding Kenya’s Creator Economy, March 2026

The report estimates that Kenyan influencer brand-partnership earnings exceeded KES 1 billion in 2025, with the top 10 creators earning an estimated KES 296 million.

The research also highlights several points that support Werra’s thesis:

  • SMEs account for a large share of creator-brand partnership activity.
  • Beauty, personal care, food, fashion, and consumer categories are active creator-marketing categories.
  • TikTok has strong attention but weaker monetization.
  • Many high-attention creators remain under-commercialized.
  • Views do not automatically translate into earnings; creators need better commercial infrastructure.

This supports our view that the creator market already exists, but the transaction infrastructure is weak.


Kenya-First, Global South-Relevant

Werra is Kenya-first, but not Kenya-only.

We are starting in Kenya because it has a highly active creator economy, strong SME demand, widespread social media usage, and a fragmented creator hiring process that still depends heavily on WhatsApp, Instagram DMs, referrals, and informal agency relationships.

This makes Kenya a strong launch market for validating the product, escrow model, creator verification process, and SME workflow.

However, the problem Werra addresses is not unique to Kenya. Across many African and Global South markets, creators generate significant cultural and commercial attention but are not consistently compensated through reliable infrastructure. SMEs also struggle to access trusted creators, structure deliverables, and pay safely.

Many of these markets share similar conditions:

  • creators are under-monetized despite strong audience attention
  • platform payouts are limited or unavailable
  • brand deals are informal and relationship-driven
  • payment trust is weak
  • creator discovery is fragmented
  • SMEs need affordable marketing channels
  • dispute handling is mostly informal
  • cross-border creator payments are difficult

Werra’s long-term vision is to become creator commerce infrastructure for Africa and other Global South markets where creators and SMEs face similar trust, payment, and market-access problems.


Why CKB?

Werra needs a reliable escrow and settlement layer.

CKB is useful to Werra because it can support:

  • USDI escrow for creator gigs
  • agreement hashes anchored on-chain
  • transparent payout and refund transaction records
  • reduced dependency on purely custodial platform balances
  • future support for more automated settlement logic

In the product, CKB is used where it matters most: trust, escrow, settlement, and payment auditability.

The user experience will remain simple. SMEs and creators should not need to understand CKB internals. They should only understand that funds are protected until the agreed work is delivered or a dispute is resolved.


Why Us?

We have already started building Werra.

Current progress includes:

  • Market research completed
  • Product description completed
  • Product architecture completed
  • Technical architecture drafted
  • Working proof of concept developed
  • SME, creator, and admin user flows implemented in the POC
  • Managed-wallet user experience explored for simple email-based onboarding
  • Creator brief posting, bidding, awarding, delivery, review, dispute, refund, and payout flows implemented at POC level
  • USDW test stablecoin flow introduced for Werra’s test payment experience
  • CKB testnet escrow direction already reflected in the technical implementation path
  • Browser-level tests verifying the core POC flows
  • Public GitHub repository created to show ongoing progress

Current Build Status

Werra is already under active development. We have created a public GitHub repository to show ongoing progress and make the work visible to the CKB community:

https://github.com/DWSQUIRES/Werra

We have also deployed the Werra POC for community testing:

https://werra-tau.vercel.app/

The POC allows testers to sign in as either an SME or a creator using an
email-based managed wallet flow. SMEs can post briefs, review creator
applications, award gigs, fund escrow, review submitted work, approve payout,
or open a dispute. Creators can browse available briefs, apply, track awarded
work, and submit completed delivery links.

The current POC uses managed CKB testnet wallets, USDW test stablecoin flows,
escrow funding, payout handling, and role-separated SME/creator workspaces.
This allows the community to test the transaction flow and provide feedback
before we move into full development.

The repository currently includes:

  • product description
  • technical description
  • product architecture
  • working proof of concept
  • SME, creator, and admin workflows
  • managed-wallet onboarding direction
  • content brief posting flow
  • creator bidding flow
  • gig awarding and escrow funding flow
  • creator delivery submission flow
  • SME approval and dispute flow
  • admin dispute settlement flow
  • USDW test payment flow
  • state-managed marketplace logic
  • browser-level tests for core flows
  • one-command local preview setup for community testing

The grant will allow us to expand from a lean early build into a more specialized execution team. This is important because Werra combines multiple disciplines: product design, marketplace UX, frontend engineering, backend engineering, escrow integration, DevOps, business development, creator onboarding, and customer support.

With grant support, we will bring these specialties together to improve product quality, reduce execution risk, and move faster toward a reliable V1 beta.


Why Now?

The timing is strong because:

  • SMEs are already spending on creators.
  • Creators are gaining attention faster than they are monetizing it.
  • Platform payouts are inconsistent or unavailable in many markets.
  • The market lacks structured trust, payment, and dispute infrastructure.
  • Stablecoin escrow can solve a real payment problem.
  • CKB can support a practical, non-speculative use case in creator commerce.

Werra can introduce CKB to real users through a workflow they already understand: hiring, delivery, escrow, and payout.


Budget

We are requesting:

USD 27,700, paid in CKB equivalent at disbursement

This proposal requests a fixed USD-denominated budget, with payment made in CKB equivalent at the time of each disbursement, based on the exchange rate on the day of disbursement.

This is included explicitly as an additional disbursement rule in the proposal
text, so the community can evaluate and vote on the proposal with this payment
structure clearly stated.

The grant will fund approximately three months of work, divided into two major phases:

  1. Development Phase: first 1.5 months
  2. Distribution and Beta Seeding Phase: following 1.5 months

Development Budget

Item Calculation Amount
Designer $20/hr × 80 hrs $1,600
Frontend Developer $25/hr × 160 hrs $4,000
Backend and Blockchain Developer $25/hr × 160 hrs $4,000
Product Manager $10/hr × 400 hrs $4,000
System Engineer / DevOps $20/hr × 200 hrs $4,000
Infrastructure: domain, server, database, and software subscriptions Fixed $500
Development Subtotal $18,100

Distribution and Beta Seeding Budget

Item Calculation Amount
Business Development $20/hr × 160 hrs $3,200
Initial Seeding: onboard 5 businesses and 20 creators 5 businesses × $300 creator-payout budget $1,500
Social Media Personnel $15/hr × 160 hrs $2,400
Customer Support $10/hr × 200 hrs $2,000
Distribution Subtotal $9,100

Contingency

Item Amount
Contingency fund for unforeseen operational, infrastructure, or beta support costs $500

Total Budget

Category Amount
Development $18,100
Distribution and Beta Seeding $9,100
Contingency $500
Total Requested $27,700

How?

We propose two main phases over approximately three months.


Phase 1: Development Phase

Timeline: First 1.5 months

The goal of this phase is to move Werra from prototype to a functional V1 beta product.

Deliverables:

  • Finalized product architecture
  • Finalized user flows
  • V1 UX designs
  • SME account flow
  • Creator account flow
  • Creator profiles
  • Business profiles
  • Brief posting
  • Creator bidding
  • Gig awarding
  • Agreement generation
  • Delivery submission
  • SME review flow
  • Revision workflow
  • Dispute workflow
  • Admin dashboard
  • CKB/USDI escrow integration
  • Agreement hash generation
  • Wallet connection flow
  • USDI escrow funding flow
  • Payout release flow
  • Refund flow
  • Escrow transaction tracking
  • Infrastructure setup and deployment

Phase 2: Distribution and Beta Seeding Phase

Timeline: Following 1.5 months

The goal of this phase is to validate Werra with real users and generate early marketplace activity.

Deliverables:

  • Onboard 5 pilot businesses
  • Onboard 20 pilot creators
  • Support initial creator gigs through seeded business budgets
  • Run social media awareness and creator acquisition
  • Provide customer support for beta users
  • Collect feedback from SMEs and creators
  • Monitor escrow and payout experience
  • Produce beta feedback report
  • Produce CKB/USDI usage report
  • Refine product based on beta usage

The initial seeding budget will allocate $300 to each of 5 pilot businesses for creator payouts. This helps create early real marketplace activity and allows us to test the full creator hiring, escrow, delivery, and payout workflow.


Post-Grant Sustainability and Path Forward

The grant will fund Werra through V1 development and initial beta distribution. After this grant-funded phase, our goal is to move Werra toward a sustainable operating model based on real marketplace usage, follow-on funding, and ecosystem partnerships.

During the distribution and beta seeding phase, we will actively engage with:

  • potential investors
  • creator economy partners
  • SME networks
  • African startup ecosystem partners
  • CKB/Nervos ecosystem partners
  • stablecoin and payment partners
  • business associations
  • creator communities
  • marketing agencies and brand partners

The objective is to use beta traction to evaluate the best path forward.

Possible post-grant paths include:

  1. Organic marketplace growth
    If early SME and creator adoption is strong, Werra will focus on growing through transaction activity, creator referrals, SME referrals, and platform fees.

  2. Follow-on investment
    If the beta shows strong demand but requires more capital to scale, we will approach angels, venture funds, ecosystem funds, and strategic partners using the beta results as evidence.

  3. Strategic ecosystem partnerships
    We will explore partnerships with creator communities, SME associations, payment providers, marketing agencies, and CKB/Nervos ecosystem projects to expand distribution and strengthen infrastructure.

  4. Revenue-based sustainability
    Werra’s long-term business model is based on commission from completed gigs, featured creator/business placements, verification services, and eventually subscription or campaign-management tools.

  5. Expansion beyond Kenya
    If the Kenya pilot validates the model, Werra will prepare expansion into other African and Global South markets with similar creator monetization and SME trust problems.

The grant will help us reach the point where these paths can be pursued with real product usage, pilot data, user feedback, and CKB/USDI transaction evidence rather than only a concept.


Expected Outcome

At the end of the grant, Werra will deliver:

  • A working V1 beta product
  • Real marketplace workflows for SMEs and creators
  • CKB/USDI escrow integration
  • Agreement and payout tracking
  • Admin dispute tooling
  • 5 onboarded pilot businesses
  • 20 onboarded pilot creators
  • Initial seeded creator transactions
  • Public demo
  • Beta feedback report
  • CKB/USDI usage report
  • Clear expansion path into other African and Global South markets

Impact on the CKB Ecosystem

Werra gives CKB a practical real-world use case in creator commerce.

The project can help demonstrate:

  • CKB as an escrow and settlement layer
  • USDI usage in real commercial transactions
  • creator and SME payments on CKB
  • agreement anchoring and payout/refund auditability
  • adoption in an under-served Global South market

Instead of positioning blockchain as the product, Werra uses CKB as infrastructure for a real user problem: trust and payment settlement between SMEs and creators.


A Note from the Founder

I’d like to end this proposal on a more personal note.

Werra is not a project I’m building to secure a grant. It’s the company I’m choosing to build.

If this proposal is funded, I’m not thinking about what happens over the next three months—I’m thinking about where Werra can be three years from now, and what it can represent for the Nervos ecosystem.

I want Werra to become one of the products people point to when they ask, “What can you actually build on Nervos?”

More importantly, I hope it helps create a culture where founders build companies that last. I want people to see that this ecosystem can produce real businesses solving real problems, with founders who continue building long after a grant has ended.

That’s the example I want to set.

You’ll see it in how we build, how we communicate, how we share progress publicly, and how we keep improving with community feedback. I want the first milestone to demonstrate not just product progress, but the energy, consistency, and commitment of a founder building for the long term.

Whether Werra becomes a success will ultimately be decided by users and the market. But one thing I can promise is this: I’m fully committed to giving it everything I have.

Thank you for considering our proposal and for believing in builders who want to create lasting value for the Nervos ecosystem.


Summary

Werra is a Kenya-first creator marketplace that helps SMEs hire verified content creators and pay safely through escrow.

We are starting in Kenya because the market is active, fragmented, and suitable for early validation. The broader vision is to expand across Africa and other Global South markets where creators are under-monetized, SMEs lack trusted creator-hiring infrastructure, and existing platforms do not provide reliable compensation or settlement rails.

CKB fits into Werra as the trust and settlement layer: powering USDI escrow, agreement anchoring, payout tracking, and refund transparency.

33 Likes

Interesting proposal. I like the focus on solving real-world problems instead of chasing hype. Every useful tool built on CKB helps strengthen the ecosystem.

Good luck with Werra, looking forward to following your progress.

8 Likes

Thank you, really appreciate this.

That is exactly the direction we are trying to take: start from a real market problem, then use CKB where it adds clear value, especially around escrow, settlement transparency, and payout/refund tracking.

4 Likes

你好,目前DAO没有基于USDI的支付选项

你可以选择以固定CKB支付或者以固定的USD额度支付

请修改DIS后pin我,以便我作为协调员在社区内同步你的提案
谢谢

4 Likes

@zz_tovarishch thank you for the clarification.

I have updated the proposal to remove the USDI payment request and align with
the DAO’s supported payment terms.

The grant request is now stated as a fixed USD amount of $27,700, to be paid
in CKB equivalent at the time of each disbursement, based on the exchange rate
on the day of disbursement. This is included explicitly in the proposal text
as an additional disbursement rule, so the community can vote with that
understanding.

Appreciate the coordination.

5 Likes

Hi @DWSQUIRES

Thanks for your proposal, glad to see you are considering solutions for businesses and content creators in the form of escrow platforms.

Generally speaking, the greater the grant request, the greater the burden of proof on the proposer to demonstrate relevant experience, prior execution, ecosystem participation, and a clear ability to deliver the proposed scope. In this case, my feeling is that more work is needed to get to that point.

As a suggestion, I think it is better to start with pre-grant groundwork in the form of a small proof of concept which can be shared on the forum for community feedback. Then, you can iterate from there and gradually work up to a proposal.

There are a few escrow models I have seen in the community which you could use for reference (searching it on the forum should bring them up)

8 Likes

Hi @neon.bit

Thank you for the thoughtful feedback. I agree with your point.

I’m taking this advice seriously and advance the current prototype into a clearer proof of concept that the community can inspect and give feedback on.

The POC will focus on demonstrating the core Werra flow: SME creates a content brief, creator accepts/bids, agreement terms are generated, escrow state is connected, delivery is submitted, and payout/refund logic is shown clearly.

Once the POC is ready, we will share it. It should be out soon.

Appreciate the guidance.

5 Likes

Hi @neon.bit

We have now advanced Werra from the initial prototype direction into a working POC that the community can review and test.

The POC includes the core marketplace flow:

  • SME posts a content brief
  • Creator applies to the brief
  • SME awards and funds the gig
  • Creator submits completed work
  • SME approves payout or opens a dispute
  • Admin can resolve a dispute for the POC flow

We also cleaned up the user experience so SME, creator, and admin users each see their own separate workspace.

GitHub repo:

The repo includes a one-command local preview setup for testing. After cloning the repo, reviewers can run:

npm run preview

This starts the POC locally and prints the testnet wallet addresses needed for gas funding.

We are sharing this now so the CKB community can review the flow, test the product direction, and give feedback.

4 Likes

We have updated the proposal to include the live Werra POC link:

The POC is now available for community testing. It currently supports email-based sign-in with managed CKB testnet wallets, separate SME and creator workspaces, brief posting, creator applications, gig awarding, escrow funding, delivery submission, payout approval, and dispute opening.

This is still a proof of concept, but it gives the community something practical to test and critique before we move toward full development. We would really appreciate feedback on the product flow, escrow experience, and any concerns around how CKB is being used in the workflow.

11 Likes

Great

1 Like

Like Audit — Proposal at [DIS] Werra: Building Trust Infrastructure for Creator Commerce

Prepared by: @zz_tovarishch DAO Coordinator

Date: 2026-07-10


1. Background

Some community members raised a concern that the like count on this proposal did not look organic. As the DAO coordinator, I reviewed the likes using forum administrative data. This note documents only the likes that failed verification and the basis for disqualifying them.

Accounts are identified by their numeric forum user ID. Usernames, email addresses, and full IP addresses are withheld here to avoid exposing personal data and to keep the assessment free of identity bias; the coordinator retains the complete mapping and can make it available to the committee for independent verification. Any DAO member may request to review the basis for this action. Members are provided with the pseudonymised evidence record (account IDs, network-linkage labels, timelines, and activity metrics — the same form as this note), which is sufficient to verify the reasoning and the pattern. Raw personal data (email addresses, full IP addresses) is not redistributed.

2. Headline finding

The first post received 33 likes. Of these, 18 are attributable to a single coordinated operation. Eleven of the eighteen are linked at the network level, and eight of them share an IP address with the proposal author’s own account. The remaining 15 likes were reviewed and show no signs of coordination. They are highly potentially genuine and are not listed here.

3. Method and data sources

Signals were drawn from the forum’s administrative records: account creation timestamp, registration IP, last-seen IP, trust level, and activity metrics (days visited, topics entered, posts, total read time). Discourse assigns user IDs strictly in registration order, so ID adjacency is a direct measure of registration sequence. IP addresses are referenced by label (IP-1, IP-2) to demonstrate that accounts share an identical address without publishing the address itself.

4. Evidence

Cluster A — linked to the proposal author by shared IP

Eight liking accounts are tied to the proposal author’s own account through a shared IP address. Seven of them, together with the author, resolve to a single hub address (IP-1). An eighth (ID 4265) instead shares the author’s registration IP and was created on the very next user ID after the author (4264 → 4265), i.e. registered back-to-back from the same connection. Five of the eight were registered weeks to months before the proposal; their sessions nonetheless trace back to the author.

User ID Registered (UTC) Trust level Total read time Days visited Posts Link
4259 2026-04-25 1 ~6.0 h 48 12 last-seen IP-1 (pre-aged)
4265 2026-05-06 1 ~5.1 h 22 6 author’s registration IP; consecutive ID 4264→4265 (pre-aged)
4308 2026-06-14 1 ~40 min 3 0 last-seen IP-1
4309 2026-06-14 1 ~2.5 h 23 4 last-seen IP-1 (pre-aged)
4312 2026-06-20 0 ~21 min 5 0 last-seen IP-1
4360 2026-07-07 0 ~8 min 2 0 registered + last-seen IP-1
4361 2026-07-07 0 ~5 min 1 0 registered + last-seen IP-1
4364 2026-07-09 0 ~10 min 1 0 last-seen IP-1

Cluster B — shared registration IP (IP-2)

Three accounts were registered from one single IP address (IP-2) within roughly one hour of each other on the same day.

User ID Registered (UTC) Trust level Total read time Days visited Posts Link
4367 2026-07-09 13:40 0 26 s 1 0 registered IP-2
4368 2026-07-09 14:29 0 ~2 min 1 0 registered IP-2
4369 2026-07-09 14:40 0 ~1 min 1 0 registered IP-2

Cluster C — same-burst behavioral signature

Seven further accounts were registered inside the same 48-hour window and share an identical profile: trust level 0, public profile hidden, one day visited, zero posts, total read time from tens of seconds to a few minutes, and disposable free-webmail addresses following one naming pattern. These accounts carry no direct IP link to Clusters A and B, but their user IDs are interleaved with the IP-confirmed accounts inside the same unbroken registration run (4360–4374), i.e. they were created back-to-back in the same batch. On that basis they are grouped here as pattern-consistent, with lower individual confidence than Clusters A and B.

User ID Registered (UTC) Trust level Total read time Days visited Posts
4365 2026-07-09 0 46 s 1 0
4366 2026-07-09 0 ~10 min 1 0
4370 2026-07-09 0 ~22 min 1 0
4371 2026-07-09 0 ~1 min 1 0
4372 2026-07-09 0 ~5 min 1 0
4373 2026-07-09 0 ~2 min 1 0
4374 2026-07-09 0 ~13 min 1 0

Cross-cutting signals

  • Consecutive registration. Thirteen of the eighteen accounts occupy the near-contiguous user-ID band 4360–4374. Because IDs are issued in registration order, this means the accounts were created back-to-back with essentially no unrelated registrations in between — a batch-registration signature.

  • Timeline. The proposal was posted on 2026-07-02. The thirteen burst-registered accounts were all created on 2026-07-07 and 2026-07-09, i.e. after the proposal, then used to like it. The five Cluster-A pre-aged accounts were created between April and June and pre-warmed to look organic.

  • Engagement. Every flagged account is trust level 0 or 1, with one day visited and no posts (aside from the pre-aged accounts’ minimal activity). None shows the browsing footprint of a genuine participant.

5. Limitation

The IP addresses in Clusters A and B fall in mobile/ISP ranges where carrier-grade NAT can place multiple unrelated users behind one address, so “same IP” is, on its own, weaker in this region than on fixed broadband. That caveat does not rescue these accounts: the proposal author’s own account sits on IP-1; several accounts use IP-1 as both their registration and last-seen address across a span of months; the Cluster-B trio share a registration IP within a single hour; and all of this coincides with consecutive user IDs and an identical low-engagement profile. The innocent-coincidence explanation would require the author and their supporters to repeatedly share carrier addresses over months while also registering in sequence and behaving identically.

6. Precedent

The Nervos forum has handled this before. In Growing the Italian ecosystem (talk.nervos.org/t/growing-the-italian-ecosystem/7707), the community identified a set of accounts that

, and the likes from those duplicate accounts were removed and the post closed so that the tally reflected genuine support.

The pattern there is the same one documented above.

7. Conclusion

The evidence above establishes, to a high degree of confidence, that 18 of the 33 likes originate from a single coordinated operation rather than from independent community members.

At this stage, the DAO’s metarules contain no explicit provision on coordinated or duplicate likes during the discussion phase, and the coordinator holds no authority to invalidate support by fiat. This conclusion, therefore, does not rest on the coordinator’s discretion. It rests on (a) the documented evidence and (b) the DAO’s own prior practice.

On that basis, the 18 likes in Clusters A, B and C would not be counted toward this proposal’s support.

Scope of this audit

This audit was initiated solely because a specific, evidenced concern was raised about this proposal while it was in its discussion window. It does not create a standing or proactive audit, and it places no obligation on the coordinator — or anyone else — to screen other proposals for the same patterns.

Consistent with the prior practice it relies on, which was itself triggered by community members raising the issue in-thread, this kind of audit is concern-driven only.

It is likewise not retroactive. Proposals whose discussion window has already closed without such a concern being raised are treated as settled and are not reopened on this basis.


This case also exposes a gap: there is no explicit anti-Sybil or duplicate-like clause at this stage of the process. Closing that gap in the meta-rules would remove the need to rely on precedent in future cases.

13 Likes