DEV Community: Ibe Arua

Building Agentic Commerce on Bitcoin, Without Trusting the Agent

Ibe Arua — Sun, 04 Oct 2026 13:23:52 +0000

Luma began with a deceptively simple question:

Can an AI agent help someone buy something with Bitcoin or an RGB asset—without ever being trusted to spend their money?

We think the answer is yes. And after building, breaking, and rebuilding the system across regtest, Signet, wallets, Lightning channels, merchants, and mobile hardware, we’re more convinced than ever that this is an architecture worth pursuing.

This is what we built, what we learned, and why we’re optimistic about what comes next.

The First Question: Can an Agent Help Without Holding the Keys?

The first experiment was RGB402: an HTTP 402-style purchase flow for Bitcoin and RGB assets.

Then came Alice, Bob, and Carol—three independent wallets running on real regtest Bitcoin and RGB Lightning nodes, with channels, invoices, inventory, human approval, and settlement that both sides could verify.

Alice and Bob proved the first milestone: wallet-to-wallet transfers worked.

Carol changed the project.

Carol ran a real merchant: her own node, products, orders, and receipts. Alice bought a coffee for 5 R402USD. Bob bought a sandwich for 8. Balances moved. Carol received the asset. Every purchase crossed a human approval boundary before exactly one payment went out.

That gave us the rule Luma now stands on:

prepare → reserve → human approval → execute once → settle → reconcile

The agent can understand intent, find a merchant, inspect a product, read an invoice, and prepare a transaction. But it cannot change the recipient, amount, or asset after approval. It cannot approve its own transaction. And an uncertain network response never becomes a second payment.

That is the core idea:

Luma is not an AI with a Bitcoin wallet bolted on. It is a system where agents reason about money without ever holding authority over it.

We Put the Node Inside the Phone

No consumer should have to run a separate RGB Lightning node. So we moved the node into the wallet.

Each installation now owns its keys, RGB state, channel state, and payment journal. Shared infrastructure can provide Bitcoin and indexer access, RGB transport, liquidity, discovery, and agent services—but it cannot sign for the user.

The Android build has progressed from local regtest to public Signet, with Bitcoin Core, Electrs, RGB transport, TLS endpoints, an agent gateway, and our own LSP. Phones connect directly. No USB. No adb reverse. No pretending the phone is a development machine.

The division of responsibility is simple:

The phone owns authority.

The network supplies connectivity and liquidity.

The merchant publishes commerce intent.

The agent helps the user decide.

The wallet enforces what can actually happen.

That last line matters most. The wallet is not just an interface. It is the enforcement boundary.

Plenty Broke—and That Was the Point

A research prototype that never breaks is usually not testing enough. Luma broke in useful ways, and each failure sharpened the design.

We learned that:

A healthy container does not mean a wallet can pay.
A running node does not mean an unlocked wallet.
On-chain sats are not Lightning liquidity.
Owning an RGB asset does not mean it is usable in a channel.
A connected peer is not a usable channel.
A UI saying “Opening” is not the node saying “ready.”

Mobile added its own lessons. Testing JavaScript configuration is not enough; what matters is what actually made it into the APK—the network, Electrs endpoint, RGB proxy, LSP identity, and expected RGB contract. Native ABI compatibility, WDK, Bare, and the RGB Lightning addon form their own failure boundary.

Recovery is the hardest problem of all.

Restoring keys without channel monitors, RGB state, and journals is a dangerous partial recovery. A live Lightning/RGB wallet must be recovered as one economic state machine—not merely as a twelve-word seed.

We have demonstrated an isolated recovery capsule. We have not claimed that it proves production recovery. That distinction matters, and we intend to keep making it.

Where Luma Stands Today

The research prototype works.

It has demonstrated BTC and RGB Lightning settlement, wallet-to-wallet payments, agent-assisted purchasing, merchant products and orders, human-readable recipient discovery, human-controlled approval, L402-style paid resources, and exact-once payment with reconciliation.

The mobile product is behind the prototype, but it is increasingly real. The embedded node runs on physical Android hardware and public Signet, with our own LSP path, payment addresses, merchant publication, and mobile checkout.

What we have not yet earned is the word “production.”

We still need repeatable phone-to-phone BTC and RGB settlement, merchant-side receipt verification from phones, robust channel lifecycle handling, and credible loss-and-restore tests.

But the bigger question has already been answered:

Is this architecture worth continuing? Yes.

What We Should Open-Source

Our instinct is: not everything, and not nothing.

For a non-custodial wallet, verifiability is the product. People should be able to inspect what gets signed, how payments are prepared, what requires approval, how duplicate execution is blocked, how state is persisted, how invoices and RGB assets are validated, what leaves the device, and what the server can and cannot do.

Those are custody claims—not implementation details.

Open first

The Alice/Bob/Carol prototype and RGB402 experiments
The reproducible regtest environment
Protocol interfaces and the payment state machine
Safe example configs, acceptance tests, and architecture documentation
Enough of the mobile wallet engine to reproduce the custody boundary

Keep private for now

Production mobile UX
Merchant growth and ranking
Catalog normalization and discovery
Agent orchestration prompts and evaluations
Liquidity allocation and rebalancing heuristics
Fraud, risk, routing, and abuse-prevention systems
Infrastructure and monitoring
Unreleased recovery techniques
Partner and issuer integrations

The principle is straightforward:

Open the mechanisms that prove user sovereignty. Protect the mechanisms we compete with.

Trade Secrets, Handled Honestly

An LSP is not a secret. Neither are RGB channels, embedded nodes, merchant discovery, or agents buying things. Guarding those would only create false confidence.

The real advantage lies in how well the pieces work together:

Predicting and allocating liquidity
Turning vague human intent into a bounded economic proposal
Ranking merchants
Normalizing Shopify and WooCommerce catalogs
Optimizing routing
Reconciling failures without double payment
Spotting risky behavior
Eventually making recovery safe for ordinary users

But there is one hard line:

Key security and payment authorization must never depend on secrecy.

They should hold even if an attacker knows exactly how the system works.

The Road Ahead

1. Freeze and publish the prototype

Make Alice, Bob, Carol, and RGB402 a clean, reproducible reference implementation. Keep the evidence—and the failures. Document what was actually demonstrated, not what merely sounds good.

2. Finish the mobile proof

Two fresh phones. Independent seeds and node identities. Real Signet BTC. Allocation UTXOs. Luma-provided liquidity. BTC and RGB payments in both directions. A merchant purchase with buyer approval and seller receipt. Restart a phone and repeat. Interrupt a payment on purpose and prove reconciliation never pays twice.

Until then, it stays experimental.

3. Make liquidity invisible

Nobody should need to understand inbound capacity or channel topology to buy a coffee. The LSP should watch payment demand and arrange liquidity around users and merchants.

That is a business in itself: commerce creates payment demand, payment demand creates liquidity demand, and capital providers fill it.

4. Turn merchants into the network

Create a store or import a Shopify/WooCommerce catalog. Normalize products and give each one a machine-readable purchase path. Humans browse. Agents discover the same inventory programmatically.

Then a user can say:

“Find this, keep it under $40, pay in USDT if the merchant accepts it, otherwise ask me before using BTC.”

The agent discovers and prepares. The wallet authorizes and settles.

That is the part that could matter beyond “another Bitcoin wallet.”

5. Replace demo assets with real money

R402USD and LUSD are demos, not stablecoins. Real USDT-style assets need an issuer-approved RGB contract, a legitimate acquisition path, and real liquidity.

If issuer-backed stablecoins reach RGB and Lightning, this machinery could coordinate real dollar commerce on Bitcoin rails.

Luma May Not Stay Luma

We like the name. It is light, approachable, and has served us well as a codename.

But it is crowded. A quick search turns up a Luma Bank, a Luma financial OS, a Luma POS app, and a Luma non-custodial crypto product. That creates trouble with discoverability, app stores, domains, trademarks, and customer confusion.

So Luma is the codename, not a commitment.

What matters is the idea:

Agentic commerce on Bitcoin, where agents participate in economic decisions without owning the authority to spend.

If a more distinctive, ownable name appears, we will change it before distribution—not after.

What We Actually Discovered

We thought we were building an AI-enabled RGB wallet.

Then an agentic Bitcoin wallet.

Then Carol made it an agentic merchant wallet.

Then mobile and the LSP widened it again.

The real opportunity looks like an open Bitcoin/RGB economic layer beneath a proprietary consumer and merchant commerce network.

Wallets create payment demand. Merchants create commerce demand. Agents create discovery and automation. LSPs supply connectivity. Liquidity providers supply capital. Issuers supply credible assets.

And Luma—or whatever it eventually becomes—coordinates all of it without becoming the custodian of anyone’s money.

That is far bigger than a hackathon entry. And there is far more left to prove.

So the discipline stays the same:

Don’t claim it works because the UI says it works.

Prove it at the wallet. Prove it at the node. Prove it at the merchant. Record the evidence. Then build the next layer.

Moving Money Is Solved. Moving Certainty Is Next.

Ibe Arua — Sat, 04 Jul 2026 13:17:57 +0000

NIP Solved the Transfer. NPS Should Solve the Status.

You have probably seen this happen before.

A customer sends money from one Nigerian bank to another. The debit leaves the sender’s account almost immediately. The customer expects the beneficiary to receive value just as fast. In most cases, that is exactly what happens. But when the status does not update cleanly, the customer ends up staring at a bank app, refreshing the screen, calling support, or asking the beneficiary, “have you seen it?”

The money may have moved. The transaction may even be fine. The information around it just hasn’t caught up yet.

That gap is not evidence that anything is broken. It is the ordinary behaviour of a payment system that has carried Nigeria through a real digital transformation, but is now running in a different era from the one its original assumptions were built for.

Volumes are higher than they used to be. More institutions are connected to the rails. Fintechs, banks, agents, merchants, and public-sector platforms are all pushing traffic through the same infrastructure. And customers now expect a transfer confirmation to behave the way a chat message does — instant, visible, and certain, with no room for “still processing.”

NIBSS built something remarkable. The next question is whether the information layer around a payment should evolve with the same seriousness as the money-movement layer itself.

How We Got Here
It is worth remembering how far this has come, because the distance is part of the argument.

In the early 2000s, Nigerian banking was still carrying a heavy cash-and-cheque burden. A cheque deposited across two banks could sit in clearing for days. Reconciliation was a manual exercise. None of it was built for the real-time expectations that define the market today.

The Central Bank pushed modernisation hard. NIBSS — incorporated in 1993, operational from 1994, owned by the licensed banks including the CBN itself — was already positioned as the shared utility for interbank settlement. In 2002, the Nigeria Automated Clearing System went live in Lagos, bringing cheque truncation and electronic clearing to a system that had been almost entirely paper-based. Around the same window, the 2004 banking consolidation reduced the industry to a smaller number of better-capitalised institutions — partly so the sector could actually carry the weight of shared digital infrastructure.

Then came NIP.

NIBSS Instant Payment turned interbank transfer into something Nigerians could trust without thinking about it. Account-number based, online, real-time — and, from the start, it shipped with a Transaction Status Query function, because the people who built it already understood that knowing a transfer happened matters almost as much as the transfer itself. NIP made “I’ll send it now” actually mean now. It rode mobile banking, USSD, POS, internet banking, agent networks — anywhere a Nigerian could initiate a transfer, NIP was usually underneath it.

It is hard to overstate the scale this reached. Volumes ran from about 5 billion transactions in 2022 to nearly 11 billion in 2024 — and CBN’s own fintech report puts that growth at 120 percent across two years, placing Nigeria among the leading real-time payment markets in the world, not just in Africa. NIP became the sixth-largest instant payment system globally, ahead of the United States.

That kind of growth eventually outpaces the system that produced it. NIP was built around an in-house messaging format suited to domestic transfers. It worked, and it still works. But the ecosystem around it now wants richer transaction data, cleaner reconciliation, easier dispute handling, and a path toward interoperability with international standards.

That is what NPS — the National Payment Stack — is for. NIBSS describes it as a secure, unified platform built around ISO 20022 messaging, designed to carry richer data, support faster reconciliation, and open the door to cross-border and open-banking use cases.

The centrepiece of that upgrade is the messaging standard itself. NIP was built on ISO 8583 — the standard that powers card and switch networks globally, proven and functional, but designed for leaner transaction data than what modern reconciliation, compliance, and cross-border interoperability now demand. Under NPS, a transfer instruction travels as a pacs.008 — the ISO 20022 credit transfer request — and the responding bank returns a pacs.002, the standardised payment status report. The pacs.002 carries richer, more structured information than what ISO 8583 was designed to hold — granular reason codes, processing stage detail, structured party data, and remittance information built for straight-through processing without manual interpretation. A bank’s reconciliation system can read it, act on it, and align it against international message flows without translation overhead. The same pattern applies across every transaction type on the scheme.

That is the real upgrade NPS brings to status handling. Not a different delivery model, but a fundamentally more useful, more structured message when it arrives — one that speaks the same language as the payment systems Nigeria increasingly needs to interoperate with.

This matters beyond the plumbing. ISO 20022 is the format the rest of the world’s serious payment infrastructure — SWIFT, SEPA, the UK’s Faster Payments — has been converging on. Moving NPS onto it puts Nigeria’s domestic rails in the same language as the systems that handle cross-border flow.

So the trajectory is clear: manual clearing, to automated clearing, to instant payment, to richer standards-based infrastructure. The next step in that line isn’t just moving money faster. It’s making verified status available wherever it’s needed, without everyone having to keep asking the same place for the same answer.

The Organisation Holding It Together
NIBSS is not a bank. Most people sending money have never heard the name. But if you have moved money between two Nigerian bank accounts, NIBSS infrastructure carried it.

It sits in the middle of the interbank architecture — the entity every bank connects to instead of connecting to every other bank directly. When a GTBank customer sends money to an Access Bank account, GTBank doesn’t hand funds to Access Bank. It sends an instruction through NIBSS. NIBSS validates it, routes it, and the receiving institution acts. Status then has to travel back the same way it came — through the centre — before anyone involved actually knows what happened.

That return trip is the part customers never see, and it’s the part this piece is about.

This isn’t an unusual design. Every serious financial system has depended on a trusted central operator — a clearing house, a settlement utility, a counterparty everyone agrees to trust instead of building a thousand separate bilateral trust relationships. NIBSS has carried that role through a genuinely difficult two decades of growth, and the NPS transition shows it isn’t standing still.

But every architecture has a pressure point. The one I want to look at closely isn’t the transfer of money itself. It’s the question that comes right after: what is the true status of this transaction, right now? That is where Transaction Status Query lives — and it’s where the strain is starting to show.

The Trouble With Asking
TSQ is not new, and it is not the problem on its own. A bank sends a transfer, the status is unclear later, the bank queries NIBSS, NIBSS answers, the bank updates its record. At the level of one transaction, this works exactly as designed.

The trouble shows up when you multiply that pattern across a system processing eleven billion transactions a year.

A single transfer can generate several status checks from several directions — the sending bank’s reconciliation job, the receiving bank’s confirmation, the customer’s support call, a fintech’s automated dispute process, a back-office investigation, all of them asking, in their own way, the same question about the same transaction. The system isn’t only moving money anymore. It’s also carrying the weight of everyone’s demand for certainty about that money.

Most of the time this is fine. The strain shows during the predictable peaks — salary weeks, the days right after a public holiday, big merchant campaigns, fintech batch reconciliation windows — when status-query traffic converges hard on the same central infrastructure that’s also busy processing the underlying transactions.

This isn’t a complaint about NIBSS’s capability. It’s an observation about the shape of the architecture. When the source of truth lives in one place, every participant who needs certainty eventually has to come back to that one place — and that gets more expensive, not less, as the ecosystem grows around it.

Four things follow from this. Status-query load doesn’t scale the same way transaction volume does — one transfer can spawn many checks. A temporary slowdown in the central query or notification path affects visibility everywhere at once, even though the underlying transaction record is perfectly intact. A bank’s own sense of “what happened” is usually a reconstruction — built from messages received and queries answered — which is normally correct, but the fact that reconciliation exists at all tells you institutions aren’t holding identical, simultaneous views of the truth. And dispute resolution still runs back through the centre every time — a bank can show a customer what NIBSS told it, but it doesn’t independently hold the same cryptographic proof from the start.

None of this means anything is failing today. NIP works. NPS is moving the right direction. NIBSS has absorbed transaction growth that would strain most national payment systems. The point is narrower than “this is broken.” The point is: as volume keeps climbing, the status layer shouldn’t be the next thing under pressure.

A Better Question Than “How Do We Ask Faster”
A lot of good engineering effort has gone into making status delivery faster, notifications more reliable, retries smarter, disputes easier to resolve. NPS already moves in this direction — richer data, ISO 20022 structure, better reconciliation support.

But there’s a question sitting underneath all of that work: why does a bank have to ask for a status it could already hold?

Why doesn’t the sending bank already carry a verified copy of the transaction’s lifecycle? Why doesn’t the receiving bank have the same record, automatically? Why does a regulator reviewing a disputed transaction have to wait for everyone to send in their logs, instead of checking one already-verified source? Why does certainty have to be pulled from the centre, again and again, instead of being handed out once and carried at the edges?

This is where a permissioned shared ledger earns its place in the conversation — not as blockchain hype, not as decentralisation for its own sake, not cryptocurrency in a trench coat. Just this: NIBSS stays the authority, but the records it signs and commits get replicated to the institutions entitled to see them, in a form that’s tamper-evident and locally readable. That’s the entire shift.

The Ledger Every Bank Would Carry
Hyperledger Fabric gets buried in jargon more often than it needs to be. The actual idea is straightforward: it’s a permissioned ledger framework for environments where participants are known, identity matters, and organisations need a shared record without blindly trusting each other.

Become a Medium member
Fabric uses certificates, membership service providers, peer nodes, an ordering service, channels, and endorsement policies to define exactly who can write, who can sign off, who can read, and how updates get sequenced. Applied to NIBSS and NPS, the model is not complicated: NIBSS stays the authority for transaction lifecycle events. When a payment hits a meaningful stage — received, validated, routed, acknowledged, returned, disputed, finalised — that event gets signed and committed to a shared ledger.

The ordering service sequences these events into blocks and distributes them to every peer on the channel. Each participating bank runs its own peer, holding its own copy. That means a bank doesn’t need to ask NIBSS every time it wants to know where a transaction stands. Its own peer already has the verified record.

The query stops being “ask the centre” and becomes “read the certified local copy.” And that local copy isn’t less authoritative for being local — its authority comes from NIBSS’s signature, the endorsement rule that required it, and the ordering process that committed it under agreed governance.

NIBSS doesn’t hand over control of the truth here. It makes the truth available everywhere it’s needed.

What That Actually Buys You
Speed. A local read skips the round trip to a central API. How much faster depends on implementation and infrastructure discipline, but architecturally, removing that round trip removes pressure from the central query path, full stop.

Independence from central downtime. If the central API layer is briefly unavailable, a bank doesn’t lose access to records already on its own peer. New events pause; the existing record stays queryable. For reconciliation, audit, and customer support at 2am during a maintenance window, that difference is the whole point.

Reconciliation that verifies instead of reconstructs. Today, reconciliation means comparing internal logs against received messages and query responses. With a shared, signed ledger, the bank checks its record against the same committed lifecycle event NIBSS itself holds. The work shifts from “let’s figure out what happened” to “let’s confirm what was committed.”

Disputes backed by something more than a phone call. When a customer insists a transfer never landed, the bank shouldn’t just be able to say “NIBSS told us it went through.” It should be able to produce a signed, timestamped, tamper-evident record proving exactly what happened and when.

Regulatory visibility without the scavenger hunt. When a regulator needs to examine a disputed or high-value transaction, the evidence shouldn’t depend on assembling logs from three different institutions. It should come from one independently verifiable lifecycle history.

Privacy that’s enforced, not just promised. Not every institution should see every transaction. Fabric’s channels and private data collections control exactly which organisations can see which data — access control sitting at the protocol layer, not something an application could misconfigure.

Query load that doesn’t keep piling onto the centre. If banks handle their own authorised TSQ reads locally, NIBSS isn’t serving every status lookup from a central endpoint. It can spend its effort on publishing authoritative events, enforcing governance, and keeping the core infrastructure solid.

This is the real difference: a system where everyone keeps asking the centre for the answer, versus a system where the centre signs the answer once and every authorised participant carries it from there.

Why Fabric and Not the Blockchain People Usually Picture
Mention blockchain in a banking context and most people think Bitcoin, Ethereum, anonymous wallets, speculative tokens, and finality you have to wait around for. None of that applies here.

Public blockchains solve a different problem — how strangers who don’t know or trust each other can still agree on a shared record. They solve it through open participation and consensus built for adversarial, anonymous networks. That’s a real engineering achievement, but it’s the wrong tool for Nigerian interbank payments, because the problem here isn’t anonymity. NIBSS, the banks, the licensed fintechs — none of them are strangers. They’re regulated, onboarded, contracted, known.

The actual question is: how do known institutions share a verified record without each one having to query the centre for every operational answer? Fabric was built for exactly that. Identity sits at the centre of the design — certificate authorities issue it, membership service providers enforce it, and every signature on the ledger is traceable to a specific, accountable institution. GTBank acts as GTBank. NIBSS acts as NIBSS. Nobody writes outside the rules, and nobody can fabricate or back-date a lifecycle event, because the endorsement policy won’t let an unsigned or wrongly-signed entry through.

This should never be framed as blockchain replacing NIBSS. That framing is simply wrong. The right framing is NIBSS’s authority, cryptographically extended to every institution entitled to hold it.

NIBSS Doesn’t Lose Authority Here. It Extends It.
This is the question that comes up first, every time: if every bank has a copy of the ledger, what’s left of NIBSS’s authority?

The honest answer is that it doesn’t shrink. It becomes more visible and more provable at every edge of the network.

Right now, NIBSS is the trusted central operator, and banks work from what they receive and reconstruct from it. That trust has carried real weight and real growth. But a bank’s local record is still its own interpretation of what came through.

In a shared-ledger model, NIBSS’s authority travels with the record itself. If NIBSS signs and commits a lifecycle event, any authorised participant holding that event can verify it came from NIBSS, untouched, without needing to ask NIBSS again. The record isn’t authoritative because it sits at the centre. It’s authoritative because NIBSS’s identity is cryptographically attached to it and the network’s rules confirm that attachment.

Write authority can stay exactly as tight as it needs to be — endorsement policy can require NIBSS sign-off on every authoritative event, banks read what concerns them and write nothing outside the agreed rules, regulators get audit access shaped by governance policy rather than informal log requests. This isn’t decentralisation in the loose, public-blockchain sense. It’s controlled distribution of a verified truth that used to live in one place.

What a Different Morning Looks Like
Picture the first working day after a long public holiday — historically one of the heaviest days on the Nigerian payment calendar.

Right now, this is when the seams show. Status responses queue. Reconciliation systems strain to match what went out against what came back. A customer calls saying their transfer hasn’t landed, and the agent’s honest answer is “let me check” — followed by an actual wait, because checking means querying the centre and hoping it isn’t also under load.

With a shared ledger already in place, that morning runs differently. The bank’s operations team isn’t starting from zero — its own peer already holds the lifecycle events that concern it. The agent pulls up the transaction and says something specific: validated and routed at this time, acknowledged by the receiving institution at this time, currently sitting at this stage. Not “let me check.” An answer.

Reconciliation changes shape too. Instead of treating every mismatch as a fresh investigation, the question sharpens to: does our internal record match the committed lifecycle record? If yes, close it. If no, the divergence point is visible immediately, not buried in a day of cross-checking logs.

For a CBN examiner looking at a disputed high-value transaction, the same logic applies. The verified chain of events — submission, validation, routing, confirmation — sits in the ledger, each step tied to the identity that committed it. That’s not a futuristic scenario. That’s what permissioned, cryptographically verifiable infrastructure is built to give you.

Being Honest About the Distance
None of this should sound easier than it is. Getting from a working proof of concept to production-grade national payment infrastructure is serious, unglamorous work.

Every participating institution would need clear onboarding terms and infrastructure standards for running a peer node — security requirements, monitoring, disaster recovery, support procedures. NIBSS would need to define precisely which lifecycle events get published from NPS and how they map onto the chaincode’s data model, aligned with the ISO 20022 message flows already in motion. Access control needs real design work — channel strategy, private data collections, retention rules, regulator visibility — none of which is automatic just because Fabric supports the pattern.

Key management matters just as much. Software keys are fine for a proof of concept; production financial infrastructure needs proper certificate lifecycle management, HSM-backed signing, and clear procedures for what happens when a credential is compromised. And none of it works without genuine high availability across ordering nodes, peer nodes, certificate services, and backup infrastructure.

None of these are research problems. They’re implementation, governance, and operational problems — which is a better category of problem to have, because it means the architecture can be piloted, hardened, and rolled out in stages rather than attempted all at once.

A sensible rollout wouldn’t start with every institution and every transaction type. It would start narrow — a TSQ-focused ledger covering selected lifecycle events — and expand from there: dispute evidence next, then reconciliation, then regulatory audit views, then broader lifecycle traceability across NPS as confidence builds.

The Bigger Picture
Nigeria built one of Africa’s most consequential payment systems in under two decades. That didn’t happen by accident — the CBN pushed for it, NIBSS built and operated the shared rails, banks invested in connecting to them, and fintechs turned that infrastructure into products tens of millions of people now use without a second thought.

The next chapter isn’t about replacing what works. It’s about strengthening it. NIBSS doesn’t have to give up authority for the ecosystem to get better visibility. Banks don’t need to become independent payment authorities to hold a verified copy of status. Fintechs don’t need to keep hammering the central TSQ path just to reconcile at scale. Regulators don’t need to depend on manually assembled logs when a cryptographically verifiable record could exist instead.

The right model isn’t “remove the centre.” It’s: let the centre sign the truth once, and let every authorised participant carry that truth with them.

That’s the opportunity in front of NIBSS right now. Not blockchain for blockchain’s sake. Not decentralisation as a slogan. A specific, narrow infrastructure improvement — NIBSS’s authority encoded into every authorised record, status visibility that doesn’t depend on repeated central queries, reconciliation that becomes verification instead of investigation, disputes backed by evidence instead of assurance.

The money already moves fast in Nigeria. It’s time the status layer moved with the same certainty.

Using SSH to connect local project to github

Ibe Arua — Tue, 16 Jan 2024 07:35:56 +0000

Github

Up until now, connecting your local project to your remote github repository required only using your github using username/password, but now to sync your project with remote github repo, you would need to connect using ssh.

Git allows you to manage and track changes to your source files. Git is often used in group projects, where a remote git repository such as one hosted on Github, acts as the central point for each team member to submit changes to the source code and view other team members contributions.

The SSH protocol adds a secure layer when using remote git repositories through the use of git SSH keys. It’s important to have security measures in place when managing access to source code stored on a remote git repository.

When you create a github repository, you are given a local url with which to connect the repo to your local machine for the purpose of syncing the project with your development machine hence allow continuous integrations and delivery. you either clone the repo to your local machine, or using https, ssh or github cli to connect and pull/push to the repo. Up until August, 2021 github GitHub is no longer accepting account passwords when authenticating Git operations. You need to add a ssh public key instead.

My assumption is that you already know how to create a github repository, if you don't, it is matter of creating a github account and locating the new repository button then you are good to go, next will be to clone the repo to your local machine:

Using HTTPS to connect local github repo to remote repo

git remote add origin https://github.com/username/repo-name.git

Using SSH to connect local github repo to remote repo

git remote add origin git@github.com:username/repo-name.git

SSH

SSH allows you to use SSH key to connect your local github repository to github remote repository. SSH which stands for Secure Shell, is a protocol used to open up a secure communication channel between computers.

SSH Key

SSH keys are used for secure communication between your local machine and GitHub. You generate an SSH key pair, consisting of a private key (stored on your machine) and a public key (uploaded to your GitHub account).
To generate a ssh key on your linux machine or any unix based operating system, you can use this command:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Above command is also used on windows but you may need to enable the openSSH client and starting the service using this command:

Start-Service ssh-agent

this command will create a cd ~/.ssh directory in the user home directory on your local machine, in it, you would find your private key id_rsa and public key id_rsa.pub. with the keys in your .ssh directory of your home directory, you can use the ssh-add command to add the private key to your ssh-client:

ssh-add ~/.ssh/id_rsa

ssh-add is a command-line utility that manages SSH keys by adding them to the authentication agent, which is a program that holds private keys used for public key authentication. This allows you to use your private key to authenticate without entering the passphrase every time.

Connect local Github Repo to remote

Having gotten your public key, you would need to add it to your github repository, follow this link to add the key your repo.

Once the key is added, test the connection with this command:

ssh -T git@github.com

If everything goes well, you should be good to go

Happy Coding