Joining a fully distributed and remote team isn’t a new experience for me. But being invited to an in-person work week in Romania, just weeks after joining the Interledger Foundation, felt truly special. Not only was it a moment to meet brilliant minds from around the world, but it was also an opportunity to roll up our sleeves and advance the mission of building an open, inclusive financial network powered by the Interledger Protocol (ILP).

To appreciate the magic of this gathering, let’s first explore the foundational technologies that brought us together.

Interledger Foundation

At its core, Interledger is about one simple idea:
Sending money should be as easy as sending an email.

This vision is championed by the Interledger Foundation (ILF), which stewards the ILP ecosystem and its surrounding protocols. ILF works to empower communities globally with open financial infrastructure, and our work weeks are living proof of that commitment.

• Interledger Protocol (ILP): Much like how the Internet routes packets of data between networks, ILP routes packets of value across different financial systems: Fiat, crypto, mobile money, or anything that carries value. Its architecture is layered, modular, and open. Get started here!
• ILP Addresses: These addresses define how value flows across the ILP network, like a routing map.
• Payment Pointers (Wallet Addresses): Just as URLs simplify IP addresses, Payment Pointers make ILP addresses human-readable. For instance:
  $ilp.interledger-test.dev/alice 
  This simple notation makes ILP more accessible and usable in real-world applications.
• Open Payments API: A standardized API enabling third-party access to digital financial accounts. Whether it's recurring e-commerce payments or peer-to-peer transfers, Open Payments allows seamless authorization and transaction initiation.
• Web Monetization: A proposed W3C standard built on ILP. Web Monetization enables real-time micropayments to web creators without the friction of ads or subscriptions. It's an elegant application layer of the ILP stack.
• Rafiki: Rafiki is the reference open-source implementation of the ILP ecosystem. It's not a wallet, not a platform, but a connective tissue between identity services, Open Payments, and ILP itself. Rafiki utilizes ILP-over-HTTP, enabling large, chunked transactions without requiring persistent socket connections.

Web Monetization Work Week – May 2025, Cluj-Napoca 🇷🇴

For a week in late spring, BreakPoint IT and the city of Cluj-Napoca, Romania, hosted the Web Monetization Work Week. With 15 people meeting in person and 5 joining virtually, approximately 10 countries were represented at the annual meeting of the Web Monetization community's members.

The group intended to align on key topics for 2025, collaboratively define future features and products, and make progress on critical decisions that benefit from focused, face-to-face discussions and design sessions.

🗓️ When & Where

• Dates: May 5–9, 2025
• Location: Cluj-Napoca, Romania
• Workplace: BreakPointIT Office

What We Set Out to Achieve:

Over five workstreams and four shorter activities, our mission was clear:

• Brainstorm and prioritize the next publisher tools, defining requirements for the top two.
• Design the architecture for a fully post-paid Web Monetization model.
• Propose a new ILF  WordPress plugin.
• Update at least two Web Monetization libraries for compatibility with v2.0 of the spec.
• Build a proof-of-concept for monetizing audio and video only when played.
• Review and update the Web Monetization spec for accuracy and completeness.
• Share updates on the WM Publishers Grant and plans for 2025.
• Explore implications of sales tax on WM revenue.
• Create advocacy materials and learning resources tailored to diverse audiences.

Aligning on Key Topics for Open Payments & Web Monetization 2025: A Shared Vision for the Future

During the May 2025 Web Monetization Work Week in Cluj-Napoca, one of our collective achievements was aligning on the direction and priorities for the rest of the year and beyond. From spec evolution to user tooling and ecosystem-wide strategy, our sessions surfaced the following focus areas:

• Publisher Empowerment: We identified two new high-impact publisher tools beyond the current banner and link generator, one to visually showcase campaign goals and progress, and another for interactive shout-outs or contributor leaderboards. These tools will help creators communicate value more effectively and build a stronger community.
• UX-Driven Innovation: We aligned around rebuilding a cleaner, user-first version under the Interledger brand. The new plugin will simplify monetization setup while supporting advanced use cases, such as multiple wallet addresses per author or post-type-specific settings.
• Extension Adoption & Model Simplification: We decided to remove one-time budgets and shift toward a recurring, monthly-grant-based model. Importantly, we agreed that a daily time-apportioned payout system (post-paid) would better reflect user activity, while still offering flexibility and predictability for both publishers and users.

After intense days of discussion, design sessions, lunch & dinner sessions, we left Cluj-Napoca with a clearer vision and a deeper connection as a community. Whether joining in person or remotely, each participant brought valuable insights that helped move the Web Monetization mission forward.

And while this post focused on alignment, people, and product vision, we know some of you are hungry for the technical updates. Don’t worry, we’ve got you covered. A comprehensive technical wrap-up is forthcoming, where we’ll delve into the implementation updates, prototype progress, and what’s slated for upcoming releases.

Stay tuned, keep testing, and as always, if you want to help shape the future of the Web, join us.

Rafiki Work Week – July 2025, Transylvania Edition

Just weeks later, we returned to Romania. This time, nestled in the enchanting region of Transylvania, we gathered 38 teammates from 8+ organizations to shape the future of Rafiki. From GateHub (Slovenia) to La Cámara de la Gente (Mexico).

We rolled up our sleeves to break monoliths, scale services, and document every moving part of the payment journey, from a single quote to an incoming or outgoing payment across interoperable ledgers.

🗓️ When & Where

• Dates: July 7–11, 2025 (Travel: July 6 & 12)
• Location: Cluj-Napoca, Romania
• Workplace: BreakPointIT Office

What We Set Out to Achieve:

Over five tracks and three in-depth technical discussions, our mission was clear:

• Improve Rafiki’s performance, observability, and scalability.
• Refactor and document core APIs and components.
• Bring cards, POS, and SEPA integrations into reality.
• Strengthen Kubernetes support with an Operator POC.
• Prioritize internationalization and accessibility of documentation.

The Teams & Their Missions

Here’s what our global crew of 14+ nationalities focused on, and how we brought it to life:

1. Rafiki Performance Improvements

Building on last year’s work week, when we introduced observability and characterized Rafiki’s performance and scalability properties, we have since performed a DDD (domain-driven design) inspired redesign process, which culminated in a prototype proving a more efficient architecture. This week, we presented this prototype and its results.

The goal is to increase the horizontal scalability. 

Small performance increases are possible using known techniques, such as caching (or, as a last resort, faster machines). Horizontal scalability, however, is not possible with the current DB-centric worker approach and requires a system redesign. Our goal was to find a design capable of maintaining acceptable response times over increasing levels of demand by distributing its load across an increasing number of inexpensive instances.

Key changes:

• Full event-driven architectural pattern replacing DB-centric worker pattern
• Partitioning for faster (and safer) in-memory processing
• Batching for improved I/O access efficiency
• Characterisation of system response to increased load, with new, more detailed metrics for all processes
• Load tests simulating different use cases: web monetization and simple transfers
• Laid groundwork for modular, domain-driven architecture with clear boundaries and abstractions

The team demonstrated the prototype, confirming that the chosen design delivers the necessary scalability. Specifically, by adding more processing instances, the system can handle a higher load with acceptable response times. This demo was performed using a production-equivalent environment running on GCP, featuring a five-node Kubernetes cluster, a managed Kafka instance, and a managed Cloud SQL (PostgreSQL) instance.

Next steps:

• Expand the approach to areas not yet covered in the PoC
• Explore binary event encoding and event sourcing
• Shardable databases for scale

The team will now focus on completing the prototype and proposing a plan to apply the lessons learned.

2. Rafiki Documentation 

We’re working on making Rafiki more accessible by improving its overall structure, translating the Open Payments documentation into different languages, and creating SDK examples that developers can use in multiple languages to better understand and implement the technology.

Documentation got a serious upgrade.

We restructured the Rafiki documentation to be easier to navigate, multilingual, and more developer-friendly. We replaced the astro-graphql-plugin with SpectaQL for API documentation, improved the site's UX, and began translating Open Payments content into Spanish.

Highlights:

• Snippets now available across JS, PHP, GoLang
• UX revamp for Rafiki.dev
• Multitenancy guides with real-world use cases
• GraphQL schema updated and searchable

The mantra was simple: “Writers, tell us what’s missing, and let’s fix it together.”

3. Rafiki Kubernetes Operator

Simplifying Rafiki deployment and scaling with K8s. Automating setup and enabling high availability.

Deploying Rafiki in K8s has been a chore until now.

We built the first functional prototype of the Rafiki Operator, which supports declarative deployments for authentication, backend, and frontend components. Infrastructure-related concerns are now managed through CustomResourceDefinitions (CRDs), while ConfigMaps and Secrets handle environment-specific configurations.

Accomplishments:

• Custom Resource Definitions for services
• Operators for Auth, Frontend, and Backend
• GitOps-ready environment variables
• Secure pod restarts on config/secret changes

While still maturing, this Operator reduces manual deployment friction and brings us closer to Kubernetes-native Rafiki deployments.

4. Rafiki Card Services

Laying the groundwork for ILP Card & POS, bringing ILP to the real world of payment terminals.

Two new services were scoped and prototyped:

• POS Service: Accepts payments from point-of-sale terminals.
• Card Service: Handles payment instructions initiated from a card & POS.

This track envisions a future where a physical card connects to your wallet through a Payment Pointer. A merchant → device → wallet flow that works with hardware terminals, and even offline.

The proof-of-concept succeeded. 

Next steps: Streamline onboarding, improve scalability, and simplify device-wallet mapping logic.

5. Payment Pointer to SEPA

Image creating an incoming payment, which will deliver your funds directly into your bank account. That’s what this team built.

This track delivered a powerful outcome: users will soon be able to send funds to a Payment Pointer and have them routed directly to a SEPA bank account. While the feature isn’t live yet, we’re targeting to have it ready by the end of the year.

Implementation details:

• Open Payments API support for SEPA as a payment method
• Back-end orchestration of SEPA transfers
• No user exposure to account numbers

6. Card Chip

This track was focused on implementing EMV-compatible ILP card chips and C-8 kernels for cross-network interoperability. This was our first hardware-led track, and it delivered big.

The team worked hard on going through a lot of EMVCo specifications for the C-8 kernel and decided how we would initiate ILP payments from an EMV flow. Ultimately, the team demonstrated how this can become a reality. However, the kernel is meaningless if the card with the correct chip does not exist. That is why, as part of this track, we also had the task of creating our own card chip. This chip will store data necessary to initiate a transaction, respond to POS requests, and, of course, sign the transaction.

We also implemented the personalization flow, which includes secure data injection and a derivation of session keys. This is the foundation of the ILP Card, and it's no longer theoretical.