Open network, not a closed loyalty silo
Service providers, maintainers, and support systems collaborate on verifiable reward programs — reputation and proofs, not platform permission.
Programs stay under your control
Customer and operational data stays with you. The chain only sees fingerprints and proofs. Providers and support partners plug into the same verification layer without owning your graph.
Who runs the surface
- Service providers — brands, shops, DAOs running programs
- Maintainers — modules, trees, claim contracts
- Support systems — installers, migration, ops recipes
Reputation + verifiability
- Eligibility proven, not asserted by a middleman
- Operator reputation tracks delivery, not paywalls
- Same claim shape across independent programs
Rewards that travel without lock-in
Collectibles, points, or discounts settle under proofs customers can reuse across apps — programs stack because they share verification, not because of exclusive vendor deals.
Claim flow
Four steps. Data never needs to leave your servers to prove eligibility.
Keep data
Purchases, points, tiers stay in your DB. Support systems only touch what you publish as trees.
Publish fingerprint
Merkle root confirmed on-chain — a verifiable snapshot maintainers and providers can trust.
Prove eligibility
Customer presents a Merkle proof — qualifies without exposing personal fields.
Unlock rewards
Contract releases collectibles, tokens, or discounts — portable across the open graph.
Reputation & verifiability
How the network stays honest without a central loyalty host.
Math, not middlemen
Claims verify against published roots. No support desk decides “yes/no” from a private CSV.
Reputation follows delivery
Programs and integrators earn standing by shipping working roots, recipes, and uptime — not by owning the customer graph.
Modules under review
HashMerchant / tree / claim surfaces stay open-source and checkable — the verification layer is shared infrastructure.
Installers you can audit
Verifiable installers and migration workflows so “it works on our box” is a proof path, not a black-box SaaS hop.
Bounty board
Connect providers, maintainers, and integrators — request features and integrations in the open.
Demand-driven surface, not a closed roadmap
Post integration needs (POS, CRM, e-com, DAO membership), feature bounties, and recipe work. Maintainers and support systems pick up work with clear acceptance criteria and verifiable delivery.
What you can ask for
- Connectors & data adapters
- Claim UX / wallet flows
- Migration recipes for existing programs
- Audit / reputation signals for operators
How it stays open
- Public specs for acceptance
- Open PRs over private forks when possible
- No exclusive “certified vendor only” gate
Where to file
permissionlessweb GitHub · Contact desk — tag requests for HashMerchant / loyalty integrations.
Installers, migration & recipes
Real-world integration paths that support systems can run and re-run verifiably.
Verifiable bootstraps
Scripts and packages that stand up tree publishers, claim contracts, and check-in hooks — with checksums and reproducible steps, not “click our cloud wizard.”
Bring existing programs
Workflows to snapshot legacy points/tiers into Merkle-ready tables, publish roots, and dual-run until claims prove out — without rewriting your CRM overnight.
Copyable operator playbooks
POS end-of-day root publish · DAO membership trees · multi-brand stacks · support runbooks for failed claims and root rotation.
Your schema first
PostgreSQL, MySQL, or exports you already have. HashMerchant attaches to existing data — migration is optional, not a forced rewrite.
Open & modular — minimize lock-in
Swap providers, chains of custody for data, and support partners without rebuilding the reward story.
Verification is shared; graphs are not owned
No single vendor should capture the network graph of who shops where. Programs publish roots; customers hold proofs; support and maintenance are replaceable roles with reputation — not permanent tenancy.
Vendor & graph lock-in
- Closed reward silos that can’t export proofs
- Forced multi-party data sharing to “partner”
- Integrations only via one marketplace
Composable pieces
- Standard claim / proof shapes
- Open installers & recipes
- Bounty-driven connectors
- Portable rewards across apps
What a claim looks like
Eligibility as math — no personal fields on-chain.
{
"claim_rewards": {
"leaf_hash": "a1b2c3...",
"proof": [
{ "sibling": "d4e5f6...", "is_right": true }
],
"root_index": 0
}
}DB → fingerprint → chain → contract
Your database is hashed into a Merkle root, published via the HashMerchant surface on Terp, and checked by a verifier contract when customers claim. Support systems help run that pipeline; they don’t become the source of truth for identity.