Builder Rootcamp - Week 10: Ship It, Defend It, Improve It
The Week You Find Out If Your System Actually Holds
There's a moment every builder dreads slightly.
Not the building.
Not even the deadline.
It's the moment someone who knows what they're looking at - actually looks at it.
Week 10 was that moment.
The code was submitted. The demo was recorded. The contract was deployed.
And then the feedback arrived.
The Final Stretch
The week had a clear shape from the start:
| Milestone | Date |
|---|---|
| Final GitHub Submission | March 28 |
| Demo Day - Group 1 | March 30 |
| Demo Day - Group 2 | April 2 |
| Project Under Review | April 1 |
| Project Approved | April 9 |
Simple on paper.
Heavy in practice.
Because between "submitted" and "approved" - there's a review. And that review is where the real learning happens.
Demo Day: The Three-Minute Test
Before the review came the demo.
Three minutes. Four slides. One shot.
No live debugging. No "let me just quickly show you this other thing."
Just you, your system, and a timer.
Preparing for it forced something useful:
The ability to say what your system is in a single sentence - without hedging, without over-explaining, without reaching for complexity to sound impressive.
For the Expiring Gift Vault:
A sender locks funds. A recipient claims before the deadline. The sender reclaims after. Two outcomes. No third path.
That's it.
If you can't say that clearly in thirty seconds, you haven't understood your own system well enough yet.
The demo enforced that clarity in a way no amount of solo building could.
The Review: When Someone Smarter Looks at Your Code
The mid-project review is the part of the Rootcamp that feels most like the real world.
Not because of the deadline.
Because of what good feedback actually does to you.
The reviewer - sebs - went through the contract line by line. The feedback wasn't generic. It was specific, reasoned, and directly tied to what could go wrong in production.
Three things stood out:
1. The boundary gap
claimGift() required block.timestamp < expiry.
refundGift() required block.timestamp > expiry.
Which means: at the exact moment block.timestamp == expiry - neither function could execute.
The gift would be temporarily frozen. Neither claimable nor refundable.
Not a vulnerability. But a logic gap. And on an immutable system - logic gaps are permanent.
The fix: refundGift() now uses block.timestamp >= expiry. No dead zone. No frozen moment.
One character. Significant correctness improvement.
2. The wrong recipient problem
If the sender typed the wrong address - the funds would stay locked until expiry and only the sender could recover them via refund.
The recipient had no recourse. The sender had no correction path mid-flight.
The fix: updateRecipient(giftId, newRecipient) - callable only by the sender, only before expiry, only on an active gift.
One function, tightly constrained, solving a real human problem.
3. The stuck funds risk
If the recipient address is a smart contract that rejects native token transfers the claim reverts.
The gift stays locked. No progression possible.
This one didn't get a code fix it got a documentation fix.
Because sometimes the right answer isn't to add complexity. It's to clearly state the assumption your system makes and let the user decide if it applies to their situation.
That distinction between fixing in code vs documenting operational risk is a mature engineering call.
What Implementing Feedback Actually Feels Like
There's a version of receiving critique that feels like failure.
There's another version that feels like the system getting better.
Week 10 was the second one.
All three issues were addressed:
Boundary gap fixed
updateRecipient()addedTests updated and expanded - 15 passing
The contract was pushed. The docs were updated. The assumptions were written down explicitly.
And something subtle shifted in the process:
The system wasn't just working anymore.
It was correct.
Those aren't the same thing.
A working system passes its own tests.
A correct system holds up when someone who didn't write it goes looking for gaps.
Deployed. Verified. On-Chain.
The final contract lives here:
https://rootstock-testnet.blockscout.com/address/0xa8576ad4A6B3C143Ce7A7A3aD35b1e7AF628A4Cc#code
Verified. Readable. Public.
Anyone can look at the bytecode, the source, the transactions.
That's what Week 6 meant when it talked about verification as transparency.
It's different when it's your own contract on the explorer.
Suddenly "blockchain transparency" isn't a concept it's your code, permanently visible, with every design decision exposed for inspection.
There's something clarifying about that.
It removes the option of vagueness.
The Approval
On April 9th, the message came through from carol:
Congratulations! Your capstone project has been approved.
The thing that landed was the sentence before it:
"That's a big milestone."
Ten weeks. Eight concepts. One deployed, verified, reviewed, corrected, and approved system.
That arc from "what is a blockchain node" to "here is my contract on Rootstock Testnet, reviewed and live" is what the Rootcamp was building toward.
What Comes Next
The program isn't over.
Carol's message outlined what's left to become a Rootstock Certified Builder:
Module 9 - Rootstock Collective: grants and ecosystem opportunities
Live closing session - April 13th
Module 10 - unlocks after the closing session
The closing session is described as having opportunities available only to Rootcamp Certified Builders.
After ten weeks of building - that framing lands differently.
It's not just a certificate.
It's access to what comes after.
Connecting the Dots
Looking at the full arc now:
| Week | What It Built |
|---|---|
| Week 2 | Infrastructure intuition |
| Week 3 | State machine thinking |
| Week 4 | Risk-first design |
| Week 5 | Security patterns |
| Week 6 | Verification and transparency |
| Week 7 | Trust and UX |
| Week 8 | System design mindset |
| Week 9 | Building under pressure |
| Week 10 | Defending, improving, shipping |
Week 10 didn't teach a new concept.
It proved that the previous nine had actually landed.
What I'm Taking Forward
Three things this week made permanent:
1. A review is a gift, not a verdict
The feedback from sebs made the system better in ways I wouldn't have caught alone.
That's not failure. That's the process working.
2. Working and correct are different standards
Passing your own tests is the baseline.
Holding up under external scrutiny is the real bar.
3. Documentation is part of the system
The stuck funds risk didn't get a code fix.
It got an honest, explicit document.
That decision to name a constraint rather than hide it in complexity is its own kind of engineering maturity.
Question for Fellow Rootcampers
What did the review process reveal about your project that you hadn't seen yourself?
Ready to start building on Rootstock? Here’s how you can get involved today:
📖 Explore the Docs – Get started with Rootstock development.
🏆 Check out the Hacker Hub – Learn about past hackathons and upcoming opportunities.
💰 Contribute and Earn with Hacktivator – Build or create content and earn up to $1,000 per contribution.
💬 Join the Community – Connect with other builders on Discord.
