Exploring Relayr: an idea for programmable communication on ICP

Developers Showcase
1

Hello ICP community,

I’d like to share Relayr, the evolution of a project we first tested as Clypr in the WCHL Hackathon 2025, where it placed 3rd in the national round.

What we built (Clypr)

  • A prototype decentralized communication relay where users claim an @handle.

  • Apps/dApps send to that handle instead of emails or phone numbers.

  • Users link their own channels (email, Telegram, etc.) and set rules for delivery, blocking, or routing.

  • All rules and logic run on-chain, making communication programmable and privacy-first.

Where we’re going (Relayr)

  • Rebuilding from scratch into a modular, production-ready platform.

  • Providing developer SDKs and a single API endpoint for messaging.

  • Expanding adapters (email, Telegram, etc.) and adding sender verification.

  • Making programmable communication feel like a native ICP capability.

Achievements so far

  • Built and deployed the MVP on ICP during the hackathon.

  • Placed 3rd nationally in WCHL.

  • Demonstrated that routing real messages through on-chain rules is possible.

About the feedback we received

In the regional round we didn’t advance further, which is okay — but one of the comments in the feedback platform was:

“The concept is generic and has too many competitors.”

This was surprising to us. While we see Relayr as something different from “yet another Web3 email” (since it makes communication programmable, user-owned, and chain-agnostic), we realized this is exactly the kind of feedback worth unpacking.

Rather than dismiss it, we’d love to know: how do others in the community see this idea? Does it come across as generic from the outside, or does it feel distinct? Where should we refine our framing or approach?

Opening this up

  • What’s your first impression of Relayr’s potential?

  • Which use cases (DAOs, DeFi, governance, dApp-user messaging) resonate most with you?

  • Are there aspects that feel redundant with existing tools, or gaps we should fill?

We’re preparing to apply for a DFINITY grant and want to involve the community early. Any perspectives — supportive, critical, or in-between — will help us refine Relayr into something that truly adds value.

Links

  • Clypr repo (prototype): Github - ClyprLab/Clypr

  • Relayr repo (new build): Github - ClyprLab/Relayr

Thanks for reading — I’d really appreciate your perspectives

1 Like
2

I’m trying to get a better understanding of what you’re proposing. I think what I’d find helpful is clear framing in terms of a problem statement, and maybe one or two pertinent scenarios / use cases / user stories

1 Like
3

Thanks, Lorimer, that’s a really good point.

I think I jumped too quickly into what Relayr does without really explaining why it exists or how someone would actually use it. Let me try again.

The main problem we’re looking at is how apps communicate with users in a way that’s reliable and private.
Right now, developers collect emails, phone numbers, or wallet addresses, and then have to manage different APIs for each channel. On the other side, users don’t have any control. If your Telegram gets banned, your email gets flooded, or you change wallets, everything breaks.

Relayr tries to flip that.

Each user gets a single on-chain communication agent, kind of like a programmable inbox that stays the same no matter what happens to your channels. Developers send messages to that identity (something like a username lets say @Lorimer) instead of storing your personal details. Then your own rules, which live on-chain, decide what happens next: block, forward to Telegram, send to email, queue it, whatever you want.

A few quick examples probably explain it better:

1. DAO governance
You’re part of a DAO that sends proposal updates. You set a rule like “only notify me about treasury proposals, and send those to my email.” Even if you change wallets or messaging channels, the DAO doesn’t need to update anything.

2. DeFi alerts
A DeFi app sends liquidation warnings. Instead of building five different integrations (email, Telegram, Discord, etc.), it just calls the Relayr API once. Your relay then handles where to send it based on your preferences. So now all their users get it in the channel they prefer

3. Everyday users
Outside of Web3, you could share your Relayr handle instead of your email or phone. You decide what’s allowed through and where it goes. If your Gmail ever gets shut down or spammed out, you just switch the route and your identity stays the same.

So, the “@handle” is just the surface. The real idea is giving users control and continuity. Your communication logic stays with you, not with the platforms. That’s what we’re trying to build natively on ICP.

1 Like
4

Hi, interesting concept. I’d like to understand how you manage the privacy part?

2 Likes
5

For privacy and security, that’s really where ICP comes in.
Everything that makes Relayr private and programmable lives on-chain. Your rules, routing logic, and linked channels are stored and executed there, not on any external server.

When a developer sends you a message, that’s the end of their visibility. They only get a simple “message delivered to agent” confirmation. From that point, your on-chain relay applies your own rules. (It might forward the message to Telegram, block it, or send it to your email.)

Because the sender never sees what happens next and never knows your real channels, spam basically kills itself. There is no feedback loop to exploit.

The only time anything leaves the chain is when your relay needs to reach you through a verified off-chain channel like Telegram or email. Even then, it only sends the minimal payload needed for delivery.

So in short, ICP isn’t just the platform we deploy on but the privacy and logic layer that makes Relayr possible.

1 Like
6

I love it! Truely. Depending on the execution, I think this would be pretty powerful. It would need to be very well decentralised for people to trust it. I think it’s a powerful idea.

Don’t be put off by individuals who don’t understand that seemingly simple ideas can often be the most transformative and useful.

Please push forward with building this.

1 Like
7

Appreciate it, Lorimer.
You’re absolutely right. Real trust here depends on real decentralization, not just in name. That’s been part of the design we’ve aimed for since day one. It’s still early, but feedback like yours really helps keep the focus sharp. I’ll share updates once we hit the next milestone.

1 Like
8

The concept has merit.

Decoupling @handle from channel is clean. I look forward to seeing how the policy/rules are implemented or how they can be extended by the developer.

Hooks for metrics and monetization may be worthwhile to consider.

2 Likes
9

Good point, Northman. The metrics and monetization angle is gold, honestly. Didn’t think of it that way, but we really like that direction and will definitely explore it. So far we’ve been more focused on making Relayr self-sustainable and solid at the core, but what you mentioned opens up some interesting possibilities.

10

How do you integrate with Telegram, email, etc? I mean how is a notification forwarded from a canister to those channels?

1 Like
11

Please reach out. @PanIndustrial has all the middleware to run this ready to alpha test.

2 Likes
12

Yeah good question Timo. That’s actually where the adapters come in.

Canisters can make HTTPS outcalls now, so in theory we could talk directly to Telegram or email APIs from ICP. But when you think about it at scale, it gets really expensive and a bit messy. Every single message burns cycles, and each integration behaves differently.

So what we do instead is keep it simple. The canister just records the delivery intent, like “send this to Telegram through the Telegram adapter.” Then an off-chain bridge worker picks that up, decrypts only what’s needed, and handles the actual delivery through the right adapter ( e.g. Telegram bot API, email via SMTP etc)

The bridge itself doesn’t see more than it needs to. Basically. all the logic and routing rules stay on-chain where it’s safer and more predictable.

We’ve been thinking about how to make that bridge layer decentralized over time too, but for now this setup keeps things lightweight, secure, and aligned with how ICP works.

13

Oh nice, that actually came at the right time. We’ve been exploring how to handle distributed events cleanly across our canisters, so ICaiBus sounds like something worth testing with our setup. I’ll reach out soon so we can see how it fits in.

1 Like