Devlog #1 ended with the venue built and the code committed. But the jacket was broken, the drop system was a wish, and the OP badge was a prototype with ambition. That’s where this story starts.
— b0gie
Doctor Dripp Joins
Devlog #1 showed the build from the outside. Two weeks of commits, modular architecture, lighting systems, interactive props. What it didn’t show was everything that didn’t work.
The WearHaus Crew Jacket was stuck in Blender purgatory. The geometry was fine — basic varsity shape, black body, white sleeves, lime trim. Collar, cuffs, waistband. Standard stuff. But the weights were wrong. Every time we exported to DCL format, the sleeves collapsed, the collar floated, the mesh looked like melted plastic. We retried the export pipeline six different ways. Changed bone assignments. Adjusted vertex groups. Re-rigged from scratch once. Nothing worked.
The textures were worse. Exported fine in Blender. In-game: color banding, alpha channel bleeding, specular values that turned matte black into oily shine. It was the kind of problem that eats days. Every creative decision gets held hostage by a technical blocker.
Enter DOCTORDripp.
Quan brought him in. “There’s this dev,” Quan said, “deep SDK7 knowledge, built tools other people use.” The nickname is literal — Dripp is the person you call when something is broken and you need it unbroken.
The Wearable Fix
The first thing Dripp did was open the jacket file and diagnose.
The weight paint problem: Blender’s default export to DCL’s armature system was collapsing the weight distribution. The sleeves weren’t failing because the geometry was bad — they were failing because the bone weights weren’t remapping to DCL’s skeleton correctly. Dripp rebuilt the weight map manually, vertex by vertex on the problem zones, using a custom export pipeline he maintains for SDK7 wearables.
The texture problem: DCL’s material system expects specific formatting — channel order, compression settings, alpha premultiplication. Our exports were technically valid but not optimized. Dripp remapped the textures to DCL’s expected format, adjusted the UV layout for the new compression, and validated the result in a test world before we ever pushed to production.
The jacket went from broken to working in roughly two sessions.
This isn’t a small thing. The WearHaus Crew Jacket is the flagship piece of the launch collection. It’s the Sacred Free Drop. It’s the item everybody gets when they show up. If the jacket is broken, the drop is broken. If the drop is broken, the launch is broken.
Dripp’s fix didn’t just save a wearable. It saved the first impression.
The Drop System: Raffle Manager
The manifesto describes five drop types. The Genesis Devlog mentions a “Sacred Free Drop” as the first release slot. But at the end of Devlog #1, “Sacred Free Drop” was still just words. There was no mechanic. No backend. No way to actually distribute anything.
Dripp built the Raffle Manager.
Here’s what it actually does:
- Timed Access Windows: Drops open at specific times. Players show up, check in, and claim within the window.
- Rarity Tier Allocation: The system distributes items across rarity levels — common, uncommon, rare — based on configurable probability pools. Not random chaos. Controlled scarcity.
- Claim Validation: Each claim is verified against the window status, player eligibility, and inventory availability. No double-claims. No bots (not perfectly, but monitored).
- Event Binding: Drops can be tied to specific events or performances. The Alter-Ego launch used this to coordinate the free distribution with the DJ set timing.
The Raffle Manager is not a generic raffle tool. It’s WEARHAUS-specific. Built to our drop taxonomy. Designed around the “timed access + rarity + event binding” model described in the manifesto.
“The Raffle Manager is one of my proudest creations.”
— DOCTORDripp
The OP Badge API
Devlog #1 mentioned an OP Badge Claim Integration (6dc1dc9). That commit was a prototype — a UI panel, a notification system, placeholder logic. It proved we wanted tiered identity, but it didn’t prove we could build tiered identity.
Dripp co-built the actual OP Badge API alongside Roustan.
Context: OP Badge is Decentraland’s identity verification system. Very few implementations exist. Dripp and Roustan’s API is one of only two in existence. The other is maintained by the platform itself.
What the API enables:
- Name Resolution: Verify a player’s DCL name against on-chain records
- Tier Assignment: Map verified names to membership tiers (Citizens → Wearers → Operatives → Architects → Pillars → Council)
- Access Control: Feed tier data back to the venue’s door systems, drop eligibility, and VIP areas
- Progressive Unlock: Track participation and upgrade tiers based on behavior, not just purchase history
The OP Badge API turned the VIP gating prototype from Devlog #1 into a real system. The name resolution that started as basic string matching became cryptographic verification. The “some doors check who you are” logic became “every door knows who you are and what you’re allowed to access.”
This is infrastructure that other venues could use. We built it for ourselves, but the architecture is portable.
What Changed About the Team
Before Dripp joined: two builders, one venue, a lot of ambition.
After Dripp joined: three builders, one working drop system, one wearable that actually loads, one identity API that actually verifies.
The team is now:
- 0xQuan — Co-founder, operations, community, drop coordination
- b0gie — Co-founder, 3D pipeline, venue architecture, wearable geometry
- DOCTORDripp — Core dev, SDK7 architect, Raffle Manager builder, OP badge system co-creator (with Roustan), wearable debugger
Three, properly. Not retroactively. Devlog #1 showed the build with two. This post shows what happened when a third person brought specialist knowledge.
What’s Working Now
wearhaus.dcl.eth has the following systems operational:
- Interactive Door System: Open, close, auto-close on proximity, sound-triggered
- VIP Access Control: Tiered gating via OP Badge API, name resolution
- Lighting Management: Dual-mode (Ambient / Party) with programmatic switching
- Interactive Turntable: Click-to-spin DJ component
- Raffle Manager: Timed drops with rarity allocation and claim validation
- Sacred Free Drop: The first operational drop — free, time-windowed, event-bound
- WearHaus Crew Jacket: Export-validated, weight-corrected, texture-optimized
These systems aren’t theoretical anymore. They’re running. Tomorrow night, they’ll be running with people inside them.
That story is Devlog #3.
How We Got Here
This post is shorter than Devlog #1 because the work was more focused. Dripp didn’t build twenty features. He built three things, but they were the three things that everything else depended on.
The timeline:
- May 14 — OP Badge prototype pushed (
6dc1dc9). Identity layer exists in code, not in practice. - May 15–18 — Dripp debugs the jacket. Weight fixes, texture remaps, export validation.
- May 19–20 — Raffle Manager built. Drop system operational. Sacred Free Drop configured for launch night.
- May 21 — OP Badge API integration completed. VIP gating, tier assignment, access control — all functional.
- May 22 — Launch night. Everything runs together for the first time.
Six days.
The Lesson
Specialists don’t replace generalists. They make generalists dangerous.
Quan and I could build a venue, design a brand, ship a vision. Dripp could debug a wearable, architect a drop system, and co-build an identity API that almost nobody else has figured out.
Together, the combination is what makes WEARHAUS actually work. Not the parts separately. The overlap.
If you’re building something similar: find the person who knows the thing you don’t. And find them before launch week.
— b0gie, with thanks to Quan for the introduction and Dripp for the rescue
P.S. — The jacket still has a cat silhouette on the left side. That was my touch. Dripp made it load. Both matter. 🤡
P.P.S. — Devlog #3 is the launch party. The one where all of this actually got used.