As a Software Architect at Celfocus, I worked where IoT, commercial APIs, and blockchain intersected: autonomous financial flows, secure access patterns, and data monetization models where billing reflected real usage rather than flat licenses. The narrative sounds futuristic; the engineering was mostly integration discipline, threat modeling, and clarifying trust boundaries between enterprises that already had mature security teams.
Customers and partners included Vodafone, Mastercard, and Energy Web, among others—each with different trust models, latency budgets, and regulatory framing. This article explains how we thought about custody, API monetization, and network design on R3 Corda without oversimplifying the politics of multi-party systems.
For newer work on high-volume cloud telemetry, see Optimizing high-velocity telemetry with AWS DynamoDB. For cross-chain settlement and smart contract interoperability in finance, see Building omnichannel networks for finance institutions. A consolidated career view is on about.
Data monetization is a metering problem with a trust problem
API monetization fails for two predictable reasons: incorrect metering (double counting, gaps, or ambiguous units) and lack of auditability (customers cannot reconcile what they paid for). Blockchain-backed approaches help when an immutable, shared trail reduces dispute cost—but only if the on-chain scope is minimal and the off-chain world is modeled honestly.
We avoided "put everything on-chain" theater. Instead we asked which events needed shared attestation and which belonged in existing enterprise logging and billing platforms.
Custody and scale
Defining a secure custody process for meaningful crypto holdings is as much process, HSM policy, and operational drills as application code. Architecture reviews repeatedly returned to questions like: who can sign, under what dual-control, how keys rotate, and how incidents escalate.
Engineering delivered clear interfaces: contract addresses, workflow states, and event catalogs that security teams could map to their controls. When custody was treated as a first-class subsystem—not a footnote—deployments stopped stalling in late-stage reviews.
Corda and permissioned workflows
R3 Corda fit use cases where known parties needed shared facts without broadcasting global state. Flows modeled business processes explicitly, which appealed to enterprises that already thought in workflows rather than anonymous global ledgers.
The trade-offs were operational: notary topology, certificate governance, and version skew between nodes. We invested in release trains and compatibility tests because a permissioned network is still a distributed system—with slower failure modes than a single microservice, but harsher coordination costs.
IoT, events, and billing alignment
IoT integrations introduced bursty telemetry and heterogeneous device fleets. We separated ingestion (durable, scalable) from financialization (strict, idempotent). Serverless components on AWS and Azure handled spikes; the monetization layer consumed curated events, not raw firehoses.
This separation mirrors patterns I later applied in fleet telemetry pipelines—see the DynamoDB telemetry article for the cloud-native angle.
Ecosystem constraints
Vodafone-scale telecom integrations emphasize reliability contracts and partner onboarding. Mastercard contexts foreground fraud thinking and settlement semantics. Energy Web brought market design and device identity concerns. The architecture could not be monocausal; we built adapters and policy layers so shared cores did not become lowest-common-denominator compromises.
Security engineering practices
Threat modeling workshops produced abuse cases, not only user stories. We validated authorization at API gateways, mTLS where required, and least privilege for blockchain nodes and off-chain services. Penetration tests targeted integration seams—the boring places attackers actually probe.
Observability and business metrics
We tied engineering metrics to business outcomes: successful metered transactions, dispute rate, and time-to-onboard a new enterprise tenant. Dashboards connected on-chain events (where used) with billing exports so finance could reconcile without file tickets to engineering every quarter.
What I would do differently
Earlier contract testing between metering services and billing exports would have reduced rework. I would also push harder for synthetic transactions in production-like environments—not demos—to validate end-to-end latency before launch windows hardened.
Stack snapshot
AWS, Azure, Serverless Framework, R3 Corda, Energy Web, Hardhat, Solidity, Python.
FAQ
When is Corda a better fit than a public EVM chain?
When participants are known, contracts require workflow-level privacy, and you can accept notary operations as part of your trust model. Public EVM excels for open participation and composability; Corda for regulated multi-party processes.
How do you avoid blockchain becoming an expensive audit log?
Store hashes or commitments on-chain and keep payloads off-chain with strong access control—unless a regulator explicitly requires otherwise. Scope what needs shared immutability.
What connects this work to your later DvP engineering?
Both domains require explicit state machines, idempotent settlement, and custody clarity—themes I expanded in Building omnichannel networks for finance institutions.