Key Clause — v1.6
When behaviour is translated into a signal, burn the identifiable source.

When user behaviour is translated, synchronised, aggregated, or converted into a protocol signal, any identifiable source information should be removed, destroyed, cryptographically erased, or irreversibly decoupled as soon as it is no longer necessary — unless retention is required by law, explicit consent, safety, or legitimate accountability.

1
Translate behaviour
Raw events converted to weighted, low-resolution signals
2
Synchronise the signal
Aggregate to a node state — resonant, friction, cooling, etc.
3
Burn the identifiable source
Delete, anonymise, cryptographically erase, or irreversibly decouple
NFT tier structure

Provenance, access & certification

RSP NFTs are utility tokens — provenance, access, participation, and certification. Not investment products.

0
Genesis NFT
Origin, provenance, and symbolic protocol anchor.
Supply: 1
1
Founder Pass
Early supporter access, private updates, feedback windows.
Supply: 25–100 · 100 credits
2
Builder Pass
SDK access, templates, checklists, priority review.
Supply: 100–500 · 250 credits
3
Certification Badge
Verifiable credential for RSP-aligned people or systems.
Issued after review
4
Partner Licence
Commercial partner and brand-use licence marker.
Approval-based
5
Audit Token
Proof of completed review, workshop, or assessment.
Service-based issuance
6
Event Token
Signal proof that coordination happened. Source identity burned at mint.
Unbounded · auto-minted
Service-credit specification

Utility-first credits, documented only.

RSP credits are described here as service accounting primitives for certification, review, partner onboarding and governance work. This page is technical documentation, not a consumer sales funnel.

Standard RSP review
100 credits
Framework review against privacy by destruction, weighted signals, non-coercive synchronisation, consent architecture and burn-clause compliance.
Full review + badge issuance
250 credits
Formal assessment with an RSP Certification Badge after review. Intended for products, platforms and organisations demonstrating RSP alignment.
Partner certification
1,000 credits
Enterprise-scale review for partners building on RSP, including registry alignment and governance participation rules.
Certifier licence
1,000 credits
Licence model for approved reviewers who issue RSP Certification Badges under documented governance rules.

Credits are not cash, not fiat-redeemable and not investment products. Any activation must follow legal, financial, privacy and security review.

Maintenance & versioning

How RSP is maintained.

RSP is a living specification. It is versioned so that anyone building on it — inside or beyond the Love Key ecosystem — can rely on a known reference point.

v1.6
Current version
The active specification, including the burn clause that mandates destroying identifiable source data.
Reference: RSP v1.6
01
Who maintains it
RSP is maintained by the Love Key core team, with principles anchored across the HELP Network and Twinly.
Love Key · HELP Network
02
How it changes
Principles and the spec evolve through reviewed, documented revisions — changes are additive and backward-aware, never silent.
reviewed · documented
03
Versioning approach
Semantic-style version numbers signal the scope of a change so integrators know what a new release affects.
major · minor · patch
04
Adoption beyond Love Key
RSP is written to be adoptable by other products and teams, so the spec is kept stable and portable.
portable · referenceable
05
Change log
Each version records what changed and why, so the trust proposition can be audited over time.
consent_events · spec_history