Scenario 01
Passwordless Login – A Clinic's Patient Portal
The problem: A physiotherapy practice runs a small online portal where patients book appointments and view their records. Currently: username and password, constant "forgot password" requests, ongoing concerns about data security.
With ROND:
- The practice integrates the ROND API into their portal (a few lines of code, similar to "Sign in with Google" today)
- A patient opens the portal and taps "Sign in with EUDI"
- Their phone shows an EUDI Wallet confirmation – fingerprint or FaceID
- The ROND Identity Registry confirms to the portal: "This person is verified. Here is their pseudonymous ID for your service."
- The patient is logged in. No password, no username, no email confirmation.
What ROND does NOT store:
No record that this patient just logged into this clinic. No login history. No usage profiles. The registry only knows the public key and authorization rules – not where they are used.
The difference from "Sign in with Google":
Google knows you logged into the clinic at 2:37 PM. ROND does not.
Scenario 02
Spam Becomes Structurally Impossible – A Doctor's Communications
The problem: A family doctor receives dozens of unwanted emails every day – pharmaceutical ads, training spam, phishing attempts. Spam filters help, but they also let unwanted messages through and sometimes catch legitimate ones.
With ROND:
- The doctor registers via EUDI Wallet in the Identity Registry
- She defines authorization rules: "Allow contact from: my patients, the lab (EUDI-verified), the local health authority, my husband."
- A pharma rep tries to send her a message → They query the registry for her public key → The registry checks: Is the sender authorized? No. → The registry does not release the public key. The message cannot even be encrypted, let alone delivered.
Why this is different from a spam filter:
A spam filter decides after delivery what counts as spam – and often gets it wrong. ROND physically prevents unauthorized messages from being received. The sender never gets the key in the first place.
Scenario 03
Digital Legacy – A Freelancer Plans Ahead
The problem: A freelancer has 47 online accounts (banking, SaaS tools, social media, crypto wallets), a life insurance policy, and a partner who needs access to everything if the worst happens. Currently: a handwritten note in a desk drawer, outdated within three months.
With ROND:
- The freelancer stores an encrypted overview of all credentials in ROND
- They designate their partner as the recipient (identified via EUDI attributes – no crypto knowledge needed)
- They appoint five guardians – trusted individuals who can confirm their death
- Trigger condition: Three of five guardians confirm via EUDI that the person has died
- After trigger activation: The key fragments are recombined, and the partner can decrypt the overview
What the partner does NOT need:
No crypto knowledge, no ROND account set up in advance, no technical configuration. They identify themselves via EUDI Wallet – that is enough.
What happens when the list is updated:
The freelancer can update the encrypted overview at any time. The trigger configuration and recipients remain untouched. No need to reconfigure everything from scratch.
Scenario 04
A Club Uses All Three Layers
The problem: A sports club with 200 members faces three issues: constant password resets for the members' area, spam flooding the board's email, and the fear that no one can access the club's accounts if the treasurer becomes unavailable.
With ROND:
- Identity Registry: Members sign in to the portal via EUDI. No password chaos, no forgotten credentials, no user database to maintain.
- Authorization Protocol: The board defines: "Contact only from verified club members." The board's email is spam-free – structurally, not through a filter.
- Legacy Protocol: The credentials for the club's bank account, hosting, and accountant portal are stored encrypted. Trigger: Three of five board members confirm that the treasurer can no longer serve.
What lives on the blockchain – and what doesn't?
The most common question we get: "You store sensitive data on a blockchain?"
No. The blockchain stores metadata only:
| On the blockchain (on-chain) | NOT on the blockchain |
|---|
| Hashes of encrypted payloads | The payloads themselves (encrypted on federated nodes) |
| Trigger configurations | Message contents |
| Public keys | Private keys (never leave your device) |
| Authorization rules | Login histories |
| Key fragment references | Personal data in plaintext |
The blockchain is the rule register – it provides cryptographically verifiable proof that a rule exists and when it was created. Not what it contains. That is precisely why a blockchain is needed: Who guarantees over 30 years that these rules have not been tampered with? The cryptographic chain of the blockchain – not the promise of any organisation.