byAruf

Where signal meets chain.

I'm Ma'aruf Yusuf — a blockchain and telecommunications engineer researching how decentralized systems and cloud infrastructure are reshaping the networks that carry the world's calls, data, and money.

Blockchain · Cloud · Telecoms
Based in
Abuja, Nigeria
Building at
AWS Labs
Focus areas
Smart Contracts · Cloud · Telecoms
Who's writing this

I am a telecommunications and software engineer with a growing focus on cloud computing, blockchain, and smart contract development.

I build secure web, mobile, and blockchain applications using tools like Solidity, Foundry, React, TypeScript, Flutter, and Supabase. This blog is where I write up the research and side projects that come out of that work — mostly around how blockchain and cloud infrastructure intersect with telecom networks, plus field notes from whatever I'm currently building or breaking.

I'm always learning, always building, and open to collaborating on projects at that intersection.

Telecommunications Smart Contracts Cloud Computing Solidity Foundry Chainlink React / TypeScript Flutter Supabase AWS
ByAruf brand plate: a telecom tower at sunset overlaid with a blockchain network graphic, reading Blockchain, Cloud, Telecoms
01

Blockchain in Telecoms

Roaming settlement, identity, fraud prevention, and network-sharing agreements moved on-chain.

02

Cloud in Telecoms

Cloud-native network functions, edge compute, and elastic infrastructure replacing purpose-built hardware.

03

Smart Contract Engineering

Solidity, Foundry, and Chainlink — building and testing contracts from first principles.

The network

Every chain, every cloud region, every cell site — one connected mesh.

Research & Insights

Notes from the intersection of chains, clouds, and networks.

Long-form research on where these fields are heading, plus shorter field notes from whatever I'm building that week.

Blockchain use cases in telecoms: where trust meets the network

Telecom runs on trust between parties who don't fully trust each other — carriers settling roaming charges, subscribers proving identity, infrastructure vendors proving their gear is genuine. That's exactly the problem shape blockchain was built for.

Read full article

Telecom is, underneath the towers and fiber, a settlement business. Every call you make abroad, every text that hops across a partner network, every piece of equipment bolted onto a cell site involves two or more organizations that need to agree on what happened and who owes whom. Historically that agreement has been reconciled by hand, weeks or months after the fact, through clearing houses and spreadsheets. That's the gap blockchain is actually useful for in this industry — not as a buzzword, but as a shared ledger that competing carriers can both trust without trusting each other.

Inter-carrier roaming and settlement

Roaming is the clearest case. Two operators serving a customer during international travel need to reconcile usage and split the bill, and traditionally that settlement cycle runs on the order of months. Put the usage records and the settlement logic in a smart contract instead, and both sides read from the same ledger and get paid automatically once conditions are met. A widely cited 2023 pilot between two European carriers reportedly cut roaming settlement time from roughly 65 days down to 3 — that's the scale of inefficiency blockchain removes when it replaces manual reconciliation with code both parties already agreed to.

Identity and fraud prevention

SIM-swap fraud, subscription fraud, and identity spoofing cost the industry billions a year, and a lot of it traces back to identity data sitting in siloed, inconsistent databases across operators. Decentralized identity flips that: a cryptographic proof lives on-chain, the sensitive personal data stays off-chain and encrypted, and a carrier can verify "this is really the SIM owner" without every party having to trust a shared central database that becomes a single point of failure — and a single point of attack.

5G network slicing and resource sharing

5G's big architectural idea is network slicing — carving one physical network into multiple virtual ones, each tuned for a different use case (a slice for autonomous vehicles needs different guarantees than a slice for video streaming). When multiple infrastructure owners share physical assets to deliver those slices, someone has to track who used what, enforce the SLA, and bill for it. Smart contracts are a natural fit: allocation, usage metering, and settlement all encoded in the same place, enforced automatically instead of audited after the fact.

Equipment provenance

Counterfeit network hardware is a real supply-chain problem for operators — recording a piece of equipment's provenance on-chain, from manufacture through every hand it passes through, makes tampering and counterfeiting far easier to catch before it ever reaches a live network.

None of this replaces the core network. It replaces the reconciliation layer sitting on top of it — the slow, manual, trust-dependent process of getting multiple parties to agree on a shared truth. That's a narrower claim than "blockchain will transform telecom," but it's the one that's actually shipping in pilots today, and it's the thread I'll keep pulling on here.

Cloud computing use cases in telecoms: the network becomes software

Telecom networks used to be built from purpose-made boxes bolted into racks. Increasingly they're built from software running on the same kind of elastic infrastructure that powers everything else on the internet. Here's what that shift actually looks like.

Read full article

For most of telecom's history, the network was the hardware — dedicated switches, routers, and radio equipment purpose-built for one job, expensive to scale and slow to change. Cloud computing is dismantling that. Core network functions that used to live on proprietary boxes are increasingly software running on standard cloud infrastructure, which changes not just the cost structure but how fast an operator can ship and how gracefully the network handles a surge in demand.

Cloud-native network functions

Rather than one big virtual machine standing in for a hardware box, operators are breaking network functions into smaller cloud-native services and microservices — lighter to run, easier to scale independently, and far better suited to the kind of continuous delivery that software teams outside telecom have used for years. A traffic spike on one function no longer means over-provisioning the whole stack.

Elastic infrastructure: auto-scaling and load balancing

This is the part I've been getting hands-on with lately, working through AWS's global infrastructure track. Auto Scaling and Elastic Load Balancing exist to solve exactly the problem telecom networks have always had — demand that spikes unpredictably (a stadium event, a natural disaster, a viral moment) and infrastructure that has to absorb it without falling over. On fixed hardware, that meant permanently over-provisioning for a peak that might happen twice a year. On cloud infrastructure, capacity scales toward the traffic instead of the traffic being capped by the capacity you happened to buy.

Edge computing and latency

Some workloads can't tolerate the round trip to a distant data center — autonomous vehicles, real-time industrial control, AR/VR. Edge computing pushes processing out to infrastructure physically closer to the user, often onto the operator's own cell sites, which is precisely where telecom's existing footprint of towers and local facilities becomes a genuine cloud advantage over a company starting from zero.

AI-native, self-healing networks

Cloud-scale compute makes it practical to run machine learning against live network telemetry — predicting equipment failures and congestion before they cause an outage, and in some cases triggering automated remediation without a human paging in at 2am.

Network-as-a-Service and open APIs

Once network functions are software, they can be exposed as APIs — bandwidth-on-demand, network slicing, location and quality-of-service data — sold directly to enterprises and developers instead of bundled invisibly into a subscriber plan. That's a genuinely new revenue line for operators, not just a cost optimization.

The common thread: cloud doesn't just make the network cheaper to run, it makes the network programmable. Once it's programmable, it starts to behave like every other piece of modern software — which is the real shift worth paying attention to.

Foundry FundMe: a crowdfunding contract with Chainlink price feeds

A Solidity-based crowdfunding contract with unit tests and Chainlink integration, built entirely with Foundry.

Read full article

Foundry FundMe is a minimum-contribution crowdfunding contract: it uses a Chainlink price feed to convert ETH to a USD value on-chain, enforces a minimum-in-USD threshold at deposit time, and lets the contract owner withdraw once funding closes. The interesting part wasn't the funding logic itself — it was writing the Foundry test suite around it: unit tests, a mock price feed for local testing, and forked-mainnet tests against the real Chainlink aggregator to make sure the mock and the real thing agreed.

Next step was wiring up a frontend so it's actually interactive instead of a contract you can only talk to through a script — full writeup and repo linked in the Projects section below.

Testing smart contracts on zkSync vs. standard EVM

Running the same Foundry test suite against a zkSync environment surfaces just how much "EVM-equivalent" still means "not quite the EVM."

Read full article

zkSync is EVM-compatible, not EVM-identical — and that difference matters the moment you try to run a standard Foundry test suite against it. Gas accounting, some opcodes, and the compilation pipeline (via zksolc rather than plain solc) all behave slightly differently, which means tests that pass cleanly on a local Anvil chain need a second pass once you point them at a zkSync environment.

The takeaway I keep coming back to: "L2-compatible" is a spectrum, not a checkbox, and the only way to know where a given chain sits on it is to actually run your tests there rather than trust the marketing page.

Building a calculator smart contract, line by line

Add, subtract, multiply — a deliberately small contract used to nail down Solidity fundamentals before building anything that touches real value.

Read full article

Before shipping anything that holds funds, I like building something small enough to fully understand end-to-end: state variables, function visibility, and how gas cost changes with the operation. A calculator contract that can add, subtract, and multiply is intentionally trivial — the point was testing it properly, not the arithmetic.

It's a small thing, but it's the same habit I want in every contract that comes after it: understand the primitive completely before composing it into something bigger.

Inside AWS global infrastructure: auto-scaling, load balancing, and serverless

Working through AWS's global infrastructure track and mapping every concept back to a real telecom scaling problem.

Read full article

Spent a stretch of this month going deeper into AWS Global Infrastructure and deliberately mapping each concept to a telecom-shaped problem rather than a generic textbook one: Auto Scaling and Elastic Load Balancing for absorbing a traffic spike across EC2 fleets, messaging and queuing for decoupling services that shouldn't block on each other, and serverless compute via Lambda plus containers and orchestration for the kind of event-driven workloads a modern network operations pipeline is full of.

Failed the certification quiz on the first attempt, went back through the material, passed on the second. The concepts that felt abstract a few weeks ago now map cleanly onto the "cloud in telecoms" ideas I write about above — which is exactly the point of learning it hands-on rather than just reading about it.

Selected Projects

Things I've built — and tested until they stopped breaking.

A mix of smart contracts, full-stack builds, and the flagship project this blog is named after.

Foundry FundMe

A Solidity crowdfunding contract with a Chainlink price feed for USD-denominated minimums, a full Foundry unit-test suite, and mainnet-fork tests against the live aggregator.

SolidityFoundryChainlink
View on GitHub ↗

Foundry Simple Storage

Foundry fundamentals project: deploying and scripting a simple storage contract, used to lock in the core Foundry workflow — scripts, deployment, and testing — before building anything more involved.

SolidityFoundry
View on GitHub ↗

MHU Travels

A front-end build focused on structured booking-flow UI and page layout fundamentals — outside the blockchain/telecom line of work, but useful practice for the front-end half of full-stack projects.

HTMLCSS
View on GitHub ↗

Voltix Global

Client build: the company website for Voltix Global Ltd, a multidisciplinary engineering consultancy (civil, mechanical, electrical) offering consulting, design, EPC, and commissioning. Private repo — built and deployed for the client.

ReactTypeScriptVite
Visit live site ↗

More projects and full write-ups live on GitHub — repos get added here as they mature.

See all repos ↗
Certifications

Formal training behind the field notes.

Cloud, blockchain, and technology management credentials — mostly earned through AWS Skill Builder and Cyfrin Updraft.

aws
Amazon Web Services (AWS)

AWS Billing and Cost Management

Issued Aug 2026
Credential ID b403ad5c-9592-4bd5-9e63-428be33cd063
aws
Amazon Web Services (AWS)

Introduction to Amazon Virtual Private Cloud (VPC)

Issued Aug 2026
Credential ID bc508db7-9d33-4857-b833-353e8befc9ad
aws
Amazon Web Services (AWS)

Job Roles in the Cloud

Issued Jul 2026
View credential ↗
C
Cyfrin Updraft

Solidity Smart Contract Development

Issued Aug 2025
View credential ↗
IA
Intl. Association of Engineers

Member, IAENG

Issued Jul 2026
Credential ID 571589
U
Udemy · MTF Institute

Executive Diploma in Technology Management

Issued Jun 2024
View credential ↗
U
Udemy · MTF Institute

Executive Diploma in Operations Management

Issued Jul 2024
View credential ↗

The full list of licenses & certifications lives on LinkedIn.

View on LinkedIn ↗
Get In Touch

Let's build something at the edge of chains and networks.

Open to collaborating on blockchain, cloud, or telecom projects — or just talking shop. Reach out directly, or use the form.

Opens your email client with this pre-filled, addressed to yusufmaaruf3@gmail.com.