Every time we needed to add a new cryptocurrency token, it took two weeks. Two weeks of custom code, manual testing, and deployment headaches. This was slowing down our business and frustrating our partners.
I proposed a different approach. What if adding a token was just a configuration file?
The Problem
Unbanked supported multiple blockchains. Ethereum, Polygon, Solana, and more. Each chain had its own quirks. Different APIs. Different transaction formats. Different ways to check balances.
When a new token came along, an engineer had to write custom code. They had to understand the specific blockchain. They had to handle edge cases. They had to test everything manually. Then they had to deploy it without breaking existing tokens.
This process took about two weeks per token. Sometimes longer.
Our B2B partners wanted to add their own tokens. They didn’t want to wait two weeks. Neither did we.
The Solution
I designed a plugin architecture that abstracts blockchain differences. The core insight was simple: most tokens do the same things. They have balances. They can be transferred. They have decimal places.
The differences are in how you talk to the blockchain. Not in what you’re doing.
So I built a system where each blockchain becomes a “provider.” Each token becomes a configuration that points to a provider. Adding a new token means writing a JSON file. No custom code needed.
How the Plugin System Works
The architecture has three layers.
Layer 1: Blockchain Providers. Each blockchain has a provider class. It knows how to connect to nodes, fetch balances, and create transactions. Ethereum uses ethers.js. Solana uses @solana/web3.js. The provider handles all the low-level details.
Layer 2: Token Adapters. Tokens implement a common interface. Get balance. Get decimals. Create transfer. The adapter translates these generic operations into blockchain-specific calls.
Layer 3: Configuration Files. Each token is a JSON file. It specifies the blockchain, contract address, decimals, and any special parameters. No code. Just data.
When the system starts, it loads all configuration files. It creates the appropriate adapters. Everything just works.
Abstracting Blockchain Differences
This was the hard part. Blockchains are genuinely different. Ethereum uses gas. Solana uses compute units. Some tokens are smart contracts. Others are native assets.
I created a unified transaction model. Every operation returns the same structure. The adapter handles the translation internally. The rest of the application doesn’t care which blockchain it’s talking to.
For balance queries, I built a caching layer. Different chains have different finality times. The cache respects these differences while presenting a consistent API to the application.
Error handling was tricky too. Each blockchain fails differently. I normalized errors into categories: insufficient funds, network issues, invalid addresses. The application can handle errors without knowing blockchain specifics.
Configuration-Driven Integration
Here’s what adding a new ERC-20 token looks like now:
{
"name": "USDC",
"symbol": "USDC",
"blockchain": "ethereum",
"contractAddress": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
"decimals": 6,
"type": "erc20"
}That’s it. No code changes. No deployments. The system picks it up automatically.
For more complex tokens, the configuration supports custom parameters. Fee structures. Special approval flows. Multi-sig requirements. Everything is configurable.
We built a validation system that checks configurations before they go live. Wrong contract address? The system catches it. Invalid decimals? Caught. Unsupported blockchain? You’ll know immediately.
The Impact
Integration time dropped from two weeks to minutes. Literally minutes.
This opened doors. We could say yes to B2B partners instantly. They wanted their token? Done. No engineering sprint required.
The numbers speak for themselves:
- 8 programs running on the plugin system
- 30,000+ KYC-verified users benefiting from faster feature delivery
- $1.2 million in additional revenue from B2B partnerships
Partners who would have gone elsewhere stayed with us. They could launch their token programs the same day they signed the contract.
Lessons Learned
Abstraction pays off. The initial investment in designing the plugin system was significant. But it paid for itself many times over. Good architecture compounds.
Configuration beats code. When you can express something as data, do it. Data is easier to validate, easier to change, and easier to understand than code.
Interfaces are contracts. The token adapter interface became our north star. As long as new implementations followed the interface, they worked. No surprises.
Think about your users. Our “users” here were other engineers and B2B partners. Making their lives easier made the whole business more successful.
Building this system taught me that the best engineering solutions often come from asking a different question. We didn’t ask “how do we integrate tokens faster?” We asked “why are we writing code at all?”
If you’re building something similar or want to discuss plugin architectures, I’d love to connect.
