The Identity Activation Playbook: 12 Weeks to a Defensible Market Position
Erwee Coetzee
Diamond Stack
Cape Town, South Africa
This is Post 3 of the Execution Trilogy. You’ve completed Phases A–D (the 12-week Identity Activation from Post 2). Your positioning is clear. Your curatorial framework is documented. Your CRM has customer data. Now you’re ready to consider blockchain provenance. But not yet. This post explains exactly when blockchain becomes valuable, and what must exist first.
The Blockchain Moment: Why Provenance Goes On-Chain in Month 4, Not Month 1
If you’re serious about blockchain provenance (the Diamond Stack Digital Passport on ERC-721, the Solidity contracts, the immutable service records), this post will save you money.
Here’s the mistake most jewellery businesses make: they get excited about blockchain, deploy it immediately, and it sits unused because the narrative scaffolding doesn’t exist yet. The blockchain has nowhere to attach itself.
Spence (1973) on signalling theory is crucial here: a signal only works if three conditions are met. (1) The signal is costly to produce. (2) It’s harder for low-quality senders to mimic than high-quality senders. (3) The receiver correctly interprets the signal. Blockchain satisfies conditions 1 and 2. But condition 3—interpretation—requires that the customer understands why this provenance matters. Without that narrative, the blockchain is just cryptographic noise.
This post tells you exactly when to deploy blockchain and what must exist first.
What Blockchain Actually Solves (And Doesn’t Solve)
Let’s be precise. Blockchain solves three specific problems in the jewellery supply chain:
Problem 1: Information Tampering — Once a service record is written to the ledger, it cannot be retroactively changed. If a piece was authenticated on June 3, 2024, nobody can later claim it was authenticated on June 3, 2023. This immutability is valuable for high-value pieces with resale potential.
Problem 2: Creator Abandonment — Once your piece leaves your studio, how does it stay connected to you? When it resells (through a friend, at auction, on Instagram), the creator gets none of the upside. The blockchain can automate a royalty: when the piece transfers, 2–5% goes back to you. This creates perpetual revenue and aligns incentives.
Problem 3: Border Compliance — In export scenarios, the EU Directive 2024/1226 and G7 traceability frameworks require documented provenance. Blockchain provides auditable, verifiable documentation that satisfies regulatory compliance without additional paperwork.
Those are real, valuable problems. Solve them and you have a defensible reason for blockchain deployment.
But here’s what blockchain doesn’t solve:
The Problem It Doesn’t Solve: It doesn’t make your work better. It doesn’t increase demand. It doesn’t build your brand. It documents your brand. That’s different. The documentation is only valuable if there’s something worth documenting.
Which brings us to sequencing.
The Sequencing Logic: Why Month 4, Not Month 1
De Filippi & Wright (2018) in their work on blockchain and institutional governance note that blockchain’s value is highest when the institution (in this case, your studio) has already established credibility through conventional means. Blockchain then enhances and verifies that credibility. But it cannot create credibility from nothing.
Your studio has spent Weeks 1–12 (Posts 1–2) building credibility:
Week 1–3: Documented your curatorial framework
Week 4–6: Articulated a defensible positioning statement
Week 7–9: Built a CRM with customer intelligence
Week 10–12: Created narrative assets that explain who you are
These 12 weeks establish that your studio has something worth documenting. Your positioning is clear, your curatorial judgment is evident, and customers understand your value.
Now—at Week 13–16 (Month 4)—blockchain becomes useful. Not before.
Here’s why:
Reason 1: Content Maturity — Your blockchain metadata will reference your curatorial framework, your material sourcing, your design logic. That content doesn’t exist until Week 12. Deploying blockchain in Week 1 means you’re immutably recording… nothing. No design narrative. No sourcing story. No service history.
Reason 2: Customer Data Validation — Your CRM (built in Week 9) is your first source of truth about customer preferences and purchase patterns. Blockchain is your second source of truth—the immutable record. You need the first one to work before the second one makes sense.
Reason 3: Resale/Service History Accumulation — The blockchain’s real value emerges over time, as pieces accumulate service records. A new piece with one “created” entry is not impressive. A piece with five entries (created, first cleaning, repaired 2024, cleaned 2025, authenticated 2026) is a trust signal. This happens over months, not weeks.
Reason 4: Cost vs. Benefit Clarity — Smart contract deployment on Polygon costs R500–2,000 per contract, plus gas fees (~R10–50 per transaction). For a studio creating 2–4 pieces per month, this is R100–200 per piece in deployment costs. If your pieces are under R20,000, the blockchain cost erodes your margin. After Month 3, you have pricing clarity and volume predictability. You can calculate ROI accurately.
This is not mystical timing. It’s logical sequencing based on what needs to exist for blockchain to be valuable.
The Pre-Blockchain Checklist: Five Conditions That Must Be Met
Before you write a single line of Solidity code, assess yourself on these five conditions:
Condition 1: Narrative Clarity
Can you articulate why each piece matters in 2–3 sentences? Can you explain your design logic? Can you point to specific curatorial decisions that make this piece yours? If you can’t—if every piece is “just a beautiful ring”—blockchain won’t help. You’re documenting ambiguity.
Checklist: You have documented your top 20 pieces (Post 2, Week 1). Each has a narrative. New team members can read these and understand your curatorial logic.
Condition 2: Operational Consistency
Can you reliably repeat your process? When you create a piece, do you follow the same steps, capture the same data, and produce consistent quality? Or does quality vary wildly based on your mood, the customer, or the phase of the moon?
Werbach (2018) on algorithmic trust makes this point: systems can only be trusted if they’re consistent. If your process varies wildly, the blockchain record will show inconsistency. That’s actually a liability, not an asset.
Checklist: You have documented SOPs for piece creation (Foundation 2, Post 1). You’re capturing the same data fields consistently (CRM schema, Post 2, Week 9).
Condition 3: Resale or Service Revenue Clarity
Is resale or long-term service revenue a material part of your business model? Or are you a purely transactional jeweller (customer buys, relationship ends)?
If it’s transactional, the blockchain royalty engine doesn’t matter. If pieces stay in customer hands forever with no resale, the immutable service record doesn’t matter as much. Blockchain is most valuable when pieces have a second life (resale, repair, authentication). If that’s not your model, blockchain is nice-to-have, not essential.
Checklist: What percentage of your revenue comes from existing customers (repairs, customisations, authenticated resales)? If it’s below 10%, blockchain ROI is low. If it’s 20%+, blockchain ROI is strong.
Condition 4: Public Identity Alignment
Are you genuinely willing to be publicly associated with every single piece forever? Blockchain is immutable. Once you mint an NFT for a piece, you’re saying “I created this, I stand behind it, it’s mine forever.”
For a studio with consistent quality, this is beautiful. For a studio with inconsistent output—pieces you’re now embarrassed by, pieces that don’t match your current aesthetic, pieces you wouldn’t make again—this is risky. The blockchain will document your entire history, warts and all.
Checklist: Would you be comfortable showing your 20 best pieces from the last 5 years on a public blockchain, permanently? If no, wait. Get to a point where you’re consistently proud of your work before immutably recording it.
Condition 5: Technical Support Capacity
Blockchain contracts need to be maintained. If gas fees spike, you might need to migrate to a different chain. If a bug is discovered, you might need to deploy a patch. If a customer claims they lost their wallet seed phrase and can’t prove ownership, you need a recovery process.
This requires either (a) a technical co-founder, (b) a retainer relationship with a blockchain developer (~R3,000–5,000/month), or (c) outsourcing to a service like Tableland or Sarine that handles the infrastructure.
If you’re a solo founder with no technical background and no budget for support, blockchain is premature. You need infrastructure certainty first.
Checklist: Do you have a technical partner or budget for technical support? Or are you planning to “just figure it out”? Be honest.
The Blockchain Implementation Timeline (If You Meet All Five Conditions)
Weeks 13–14 (Month 4, Weeks 1–2): Architecture & Contract Review
Work with a blockchain architect (or review the Diamond Stack Passport Solidity templates) to design your specific schema. What data is immutable? What’s mutable? What goes on-chain vs. IPFS vs. centralized database?
For a jewellery studio, a typical schema includes:
— Creator (you)
— Piece ID and metadata (materials, design narrative, creation date)
— Service records (auditable history of cleaning, repair, authentication)
— Royalty receiver (your wallet address)
— Transfer event (when piece changes hands, royalty triggers)
Weeks 15–16 (Month 4, Weeks 3–4): Pilot Deployment
Deploy contracts to Polygon testnet first (free, no gas cost). Create NFTs for your top 5–10 pieces. Test the mint process, the metadata retrieval, the wallet integration.
Week 17 (Month 5, Week 1): Mainnet Launch
Deploy to Polygon mainnet. Begin minting new pieces on the blockchain as they’re created.
Weeks 18–20 (Months 5–6): Backfill & Communication
For pieces you want to retroactively tokenise, create records on the blockchain. Communicate to customers: “Your piece is now on the blockchain. Here’s what that means. Here’s your NFT certificate. Here’s how to access your piece’s service history.”
This timeline is post-Week 12 (Post 2, “Identity Activation”). You’re not starting blockchain until your positioning is clear, your data is structured, and your narrative is established.
What Blockchain Is NOT (And What to Do Instead If You Don’t Meet Conditions)
If you don’t meet all five conditions, blockchain is premature. But you still need a solution to the problems blockchain solves. Here are alternatives:
Instead of Blockchain for Service Records:
Use a centralized database (your CRM or a secure customer portal). Document every service event. Give customers access to read (not edit) their piece’s history. This satisfies the “immutable record” need without the blockchain cost. Once you’re mature (12+ months of data, consistent service volume), migrate to blockchain if needed.
Instead of Blockchain for Royalties:
Establish relationships with secondary market buyers (consignment partners, auction houses). Negotiate a commission structure that gives you visibility (and revenue) when pieces resell. This is slower than automated smart contracts, but it’s reliable and requires no blockchain.
Instead of Blockchain for Export Compliance:
Use documented supply chain records (certificates of origin, material testing reports, photographs). Many regulators accept comprehensive documentation without requiring blockchain. Consult with a customs broker to understand your specific compliance burden. Blockchain is valuable if your regulatory burden is proving authenticity at scale. If you’re selling 10 pieces/year to the EU, documentation is sufficient.
The point: blockchain solves real problems. But it’s not the only solution. Choose based on your actual needs, not the coolness factor.
Why This Matters for Post 4
Post 4 introduces the Service Flywheel—how repairs, authentication, and customer touchpoints become your recurring revenue engine. The blockchain is the infrastructure that makes the flywheel immutable and auditable. But the flywheel logic comes first (Post 4), the blockchain implementation comes later.
Posts 2–3 are about sequence and readiness. Posts 4–8 are about building the systems that make blockchain valuable.
Research & References
Spence, M. (1973). Job market signalling. The Quarterly Journal of Economics, 87(3), 355–374.
Foundational work on signalling theory. Shows that signals only work when (1) they’re costly to produce, (2) harder for low-quality senders to mimic, and (3) correctly interpreted by receivers. Applied here to blockchain as a signal of authenticity.
De Filippi, P., & Wright, A. (2018). Blockchain and the law: The rule of code. Harvard University Press.
On blockchain and institutional governance. Shows that blockchain’s value is highest when the institution has already established credibility through conventional means, then blockchain enhances and verifies it.
Werbach, K. (2018). The blockchain and the new architecture of trust. MIT Sloan Management Review, 59(4), 50–56.
On algorithmic trust and blockchain. Shows that trustworthy systems require consistency. Inconsistent processes recorded on blockchain are liabilities, not assets.
Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system. Bitcoin.org.
The original Bitcoin whitepaper. Not specifically about jewellery, but foundational for understanding blockchain’s immutability and its applications to supply chain verification.
Saberi, S., Kouhizadeh, M., Sarkis, J., & Shen, L. (2019). Blockchain technology and its relationships to sustainable supply chain management. International Journal of Production Research, 57(7), 2117–2135.
On blockchain for supply chain transparency and sustainability. Relevant for understanding when blockchain adds value to supply chain documentation.
