DEV Community

Ruben Saha
Ruben Saha

Posted on

How I Built a Seamless Web3 Onboarding Engine with YAML & Workflow Builder

Every Web3 project I’ve worked on had the same nightmare: onboarding.
On paper, it looks simple: user joins Discord → wallet verified → on-chain asset issued. But in practice? It’s a minefield.

Users had to bounce between Discord bots, KYC portals, wallet popups, and minting sites. The UX felt like a scavenger hunt. Meanwhile, my team was juggling brittle code, Express servers for API inputs, AWS Lambdas for KYC checks, RPC calls for minting, Discord webhooks for role assignment, and cron jobs for retries.

It wasn’t onboarding. It was duct-taping six platforms together while praying nothing snapped.

And here’s the brutal stat that confirms I wasn’t alone: According to a 2024 Chainalysis report, over 60% of new users drop off during Web3 onboarding flows. That’s lost adoption, lost revenue, and wasted ad spend.

For me, it was worse. Every failure meant frustrated users pinging mods, ops patching manual errors, and engineers stuck fixing infra glue instead of building protocol features.
That’s when I switched to Kwala.

The Reality Check: Web2–Web3 Onboarding Is a UX Maze

Let me map out how things looked before Kwala:

User signed up via Discord or web form

They submitted a wallet address

Off-chain KYC had to be verified manually

If successful, I minted them an onboarding NFT

Then I fired a webhook to give them the right Discord role

Each of those steps ran on a different piece of tech:
Express.js for API inputs

AWS Lambda for KYC calls

RPC scripts to mint

Discord webhooks for role assignment

Cron jobs for retries

That was a full backend stack just to say “welcome.”
The UX broke constantly, and when it did, it broke confidence. Users would ask: “Why didn’t I get my NFT?” or “Why don’t I have Discord access yet?” Meanwhile, half the logs were missing because the retry cron crashed at 2 a.m.

How I Rebuilt Onboarding with YAML & Workflow Builder?

When I moved onboarding into Kwala, I replaced that entire backend with one declarative workflow.
Instead of maintaining APIs, retries, and infra, I wrote this YAML:
trigger:

  • api_event: { endpoint: "/signup", user_id: "{{user}}" }

conditions:

  • kyc_check: { provider: "sumsub", user: "{{user}}" }

actions:

  • call_contract: { function: "mintWelcomeNFT", contract: "0xOnboardNFT", params: ["{{wallet}}"] }
  • webhook_call: { url: "https://discord-bot/assign-role", payload: { user: "{{user}}" } }

That’s it.
The workflow runs directly on the Kalp Network, with:
Verifier nodes sign every action

KMS-based key security

Immutable logging on Kalp Chain

No servers. No polling. No infra drift. Every onboarding action becomes auditable and provable.

YAML vs Workflow Builder: Two Paths, Same Engine
The YAML was perfect for me because I like granular control. But one of my teammates, a non-coder who handles ops, needed a no-code way to set things up. That’s where Workflow Builder came in.
YAML: Precise, declarative, version-controllable. Perfect if you want Git-based reviews and fine-tuned conditions.

Workflow Builder: Drag-and-drop blocks for triggers, conditions, and actions. No code. Just pick “Discord event” → “KYC provider” → “Mint NFT” → “Assign role.”

Both approaches compile down to the same execution on the Kalp Network. It’s just about preference. I use YAML for production, while my teammate uses Workflow Builder to test flows fast.
This duality matters. Not every team has the same skill set. Giving engineers YAML and ops a visual workflow builder meant that onboarding logic finally became collaborative.

The Results: From Signup to NFT in Seconds

Here’s how onboarding works now:
A user signs up via a form

Their wallet is verified instantly through the KYC provider

They receive a welcome NFT in their wallet within seconds

Their Discord role unlocks automatically

No missed steps. No back-and-forth between platforms. No manual intervention.
What used to take days of dev time (and constant firefighting) now runs clean, fast, and provable.
And the best part? I didn’t have to maintain any backend.

Why I Won’t Build Onboarding Any Other Way

The old way of onboarding burned cycles, budgets, and user trust. With Kwala, I cut infra overhead, killed fragile cron jobs, and actually gave users the experience I promised.
I don’t need to worry about retry logic at 3 a.m. I don’t need to maintain six different services. I don’t need my ops team to copy-paste wallet addresses.
Instead, I have two ways to work:
YAML for deep control

Workflow Builder for no-code simplicity

Both routes get me the same outcome: a seamless Web3 onboarding engine that’s automated, auditable, and production-grade.
For me, that’s the real win.

If onboarding is where your project is losing users, don’t throw more backend engineers at it. Just declare it, or drag and drop it, with Kwala.

Top comments (0)