Building with WDK: A Conversation with Shiga

Welcome to the first WDK interview! In this post, we're getting to know Shiga Digital, a Tether portfolio company building financial infrastructure across Africa and the Gulf.

Shiga was WDK's first alpha tester and has worked alongside us over the past year as WDK has grown and matured. From testing early releases to putting WDK into production, the team has been part of that journey, bringing self-custody to businesses and individuals in the Global South.

That's why we wanted to hear directly from the people behind it. Abiola Shogbeni and Dami Etomi join us to share how they're using WDK in their two products, Enta and Pulse, and what they've learned along the way.

Before we get into the conversation, here's how the products fit together. Enta is the account for individuals and businesses to hold and manage digital dollars, Bitcoin, and tokenized gold, with payments and team permissions. Pulse is the settlement and orchestration engine behind it, connecting local currency, digital assets, and payouts.

*Tether is an investor in Shiga. This written interview has been edited for length and clarity. Verification notes are editorial questions for review, not statements by the respondents.*

Interviewer: Abiola, let's start with the business behind the build. Shiga has processed more than $350 million. What was still missing that led you to create Enta?

Abiola: Virtually all of that volume came from end-to-end conversions for corporate treasuries and cross-border settlements. We would collect fiat on one side, use digital assets for intermediate settlement, and pay out in the target currency.

Take a Nigerian energy company collecting local currency but needing foreign currency to service overseas accounts or buy maritime assets. We had built the orchestration for that flow. The missing piece was key management and account infrastructure: secure wallets, multisignature governance and staff permissions. Enta grew out of that need to give commercial teams accounts they could use for their on-chain operations.

Interviewer: Who did you have in mind when you started building it?

Abiola: Agricultural exporters, importers paying foreign suppliers, cross-border corporate payees and merchants moving daily earnings into hard assets. One example is a Nigerian legaltech business that raised funding in the US, then lost banking access when its regional banking institution abruptly shut down operations.

These users can already buy stablecoins. What they need is an account with deposits, collections, payables, treasury management, permissions and recovery. Enta replaces seed phrases with WebAuthn passkeys in the user experience, abstracts network selection and deducts fees from account balances. Businesses can configure signature thresholds and staff roles. Borrowing against gold or Bitcoin without selling the underlying assets is also on our roadmap.

Interviewer: Why was self-custody so important to that account?

Abiola: Our starting point was ownership of capital. Businesses face foreign-exchange restrictions, conversion rules, and approval processes tied to one employee's device. A centralized provider can also freeze funds or withdraw service.

Users retain control even if Shiga stops operating. We combine user-controlled keys with on-chain spending limits, multisignature thresholds and staff permissions. Smart Accounts, using ERC-4337 accounts, also let us batch payments, pay fees from held assets and recover an account by rotating its owner key rather than moving all its funds. Pulse supplies the liquidity and settlement underneath.

Interviewer: What did that commitment change about your business model and responsibilities?

Abiola: From our perspective, we gave up nothing. We chose to earn from execution and infrastructure services rather than holding customer balances to generate yield. Account holders will capture yield themselves.

Support also changes. We cannot rely on a central helpdesk override to reset accounts, so recovery has to be designed into the account. For fiat intake and payout, we work through licensed entities with KYC and transaction monitoring. The wallet is software the user controls. Our regulatory obligations sit at those conversion points, and nothing in our licenses requires us to hold user keys.

Interviewer: Where did WDK come into the picture? What would building the same foundations yourselves have involved?

Abiola: Previously, we submitted integration requests to wallet vendors and waited on their roadmaps. That limited our control over important parts of the product. And on the other hand, we estimated that building our own stack for Bitcoin UTXOs, signing across chains and threshold recovery would take three to four dedicated engineers around eight to ten months before beta features. 

WDK gave us the low-level primitives while leaving us room to build our own account, passkey and enclave layers. We wanted to own the account design without rebuilding every transaction primitive.

Interviewer: Tether is also an investor in Shiga. What convinced the team to choose WDK on its technical merits?

Abiola: Tether's investment did not drive the choice. Direct developer guidance, research collaboration and architectural feedback during alpha helped us build confidence in the integration.

The decisive factor was engineering control. We could build passkeys, smart-account logic and time-locked recovery around our users' needs. Open source mattered because our signing infrastructure runs in AWS Nitro Enclaves: we need to inspect the code before deploying it. A black-box SDK would not meet that requirement.

Interviewer: Before we get into the wallet architecture, how does Pulse handle the settlement itself?

Abiola: Pulse brings intake, execution and payout together behind one endpoint. It connects banking and liquidity partners, shows fees in the guaranteed quote and runs five stages: quote, screen, route, settle and learn. Execution data feeds back into future routing decisions.

Institutional customers in retail finance, digital gaming and corporate banking already run live volume through it. These include an African investment platform serving six million users and a payment gateway that collects local currency and pays merchants in stablecoins. Our quotes lock for ten minutes, payout execution starts within ten seconds of deposit confirmation and our settlement success rate is 100%. Enta uses Pulse as its underlying execution layer.

Interviewer: And where does QVAC fit into that experience?

Abiola: In Enta, QVAC provides local intelligence for account interactions. A merchant can photograph an invoice and have the on-device parser extract its line items into a stablecoin payment request. Local processing can also analyze spending, treasury flows and conversion timing while working over unreliable connections.

With that device-side model, signing keys and transaction telemetry stay on the handset. At the infrastructure level, Pulse uses local execution telemetry alongside our signing enclaves to improve routing, screening and fraud detection without exporting tenant data to external cloud models.

Interviewer: Nigeria is central to your work. Where are you in the regulatory process there?

Abiola: Digital-asset activity in Nigeria reached approximately $96 billion over the past year, compared with roughly $40 billion for the proposed 2026 federal budget. Much of that activity runs through P2P desks and personal wallets. Establishing a formal presence in our home market was essential.

We engaged SEC Nigeria through its Accelerated Regulatory Incubation Program to pursue a Digital Asset Intermediary license. We have approval in principle and are completing the security checks needed to formalize our sandbox status.

In June, we demonstrated the stack in Abuja. The review covered custody, key management, transaction monitoring and operational controls. An August follow-up led to a proposed training and technical roadmap involving Shiga engineers and Tether as an infrastructure partner.

On August 28, the directorate issued written consent without objection to our seven-part framework: stablecoin settlement, reserve attestation, wallet forensics and AML tracking, token issuance, key management and custody, supervisory data feeds and tokenization. We are coordinating implementation details with Tether engineering before rollout.

Interviewer: Dami, let's bring you in. Where does WDK sit between Pulse and Enta?

Dami: Pulse is the base engine, connected through a custom WDK-based wallet microservice. WDK key-management logic and our guardian service run inside AWS Nitro Enclaves. Retail accounts use passkeys and recovery; enterprise accounts add signature thresholds and administrative roles.

A policy co-signer inside the enclave checks transaction payloads against account rules before signing. Candide supplies ERC-4337 bundlers and paymasters, but is outside the key hierarchy. The service covers native Bitcoin UTXOs as well as tokenized gold, and we designed the wallet layer for eventual use by external developers.

The conversion points connect this with the regulated services: our wallet service screens addresses, and licensed partners handle fiat intake with KYC and monitoring.

Interviewer: What had you originally planned to build yourselves?

Dami: From late 2024, we used a third-party wallet API for addresses and transfers, with OTP checks around it. Account abstraction arrived around the time of our first WDK commit.

We planned to bring custody into hardware enclaves and make the user's key the smart-account owner. We expected to keep buying the chain-specific transaction work as a service. WDK changed that: we could run libraries inside our own enclave instead.

We implemented our custody stack twice, in TypeScript for the enclave and in Go for Pulse. WDK lets us cover the chain without writing every encoding and signing integration ourselves.

Interviewer: Enta users see a passkey rather than a seed phrase. Where do the keys actually live?

Dami: There are three layers. First is a WebAuthn P-256 passkey in the user's device hardware, unlocked with biometrics. Second, on EVM networks, that passkey owns a Safe ERC-4337 account. The contract enforces account rules, and recovery can change the owner without moving assets.

Third are non-EVM networks such as Bitcoin, Solana, TRON, TON and Spark. Nitro Enclaves generate and encrypt their seeds, with WDK handling the relevant key and signing operations. The enclave has no interactive shell or persistent disk; it decrypts key material in memory for signing.

AWS KMS releases decryption keys when the enclave's code measurements match its attestation policy. Reproducible builds let you check those measurements independently. The enclave also requires a signed passkey challenge. Internal API keys do not confer signing rights, and we have no admin bypasses or master keys in the codebase.

Interviewer: Which parts of that did WDK provide, and what did you add?

Dami: WDK supplied key generation, signing and transaction-building primitives. We built WebAuthn registration and assertion verification, the passkey ownership flow, the enclave wrapper and guardian recovery. Seed phrases remain hidden from users, although BIP-39 still operates underneath the relevant wallet paths.

For our main passkey-based Safe accounts, we use a custom abstractionkit implementation. The WDK smart-account package we integrated assumes a seed-derived EOA owner, so its abstraction serves our seed-derived fallbacks. Candide handles bundling and paymasters.

We also run Fulcrum Electrum nodes backed by Bitcoin Core, with TLS pinning and public fallbacks. For Spark, we built explorer polling followed by operator verification, replacing the alpha reference indexer after encountering mainnet bugs.

Interviewer: Let's take a very practical case: someone loses their phone. How do they get back into their account?

Dami: The assets remain on-chain; the phone holds credentials. In standard cases, passkeys sync through platform keychains so users can authenticate on replacement hardware. Users can also add a backup device or another signer in advance.

If all local keys are lost, identity verification precedes creation of a new passkey. The enclave guardian proposes an owner change, followed by a 72-hour contract-enforced delay. Outbound movements are frozen during that period. A surviving signer can cancel the proposal, and alerts use out-of-band channels rather than SMS.

The guardian can propose owner rotations but cannot route transactions. Users also retain non-sensitive account metadata. With that metadata and a surviving backup key, they can use open-source tools to move funds independently of Shiga.

Interviewer: Was recovery the hardest part of the build?

Dami: It was the hardest design problem. You need a route back for a legitimate owner without creating a route for someone else to take the funds. Designing the guardian's limited authority, delays, cancellation rights, and alerts took more work than implementing the code.

Gas abstraction consumed the most engineering time. That involved paymaster routing, changing gas prices, Solana token accounts, EVM estimation buffers, TON relayers, TRON resources and patches to relay libraries. Recovery was one difficult architectural problem; gas kept producing operational edge cases.

Interviewer: How are you handling those fees for people who don't hold native gas tokens?

Dami: WDK on EVM has the ERC-4337 wallet module; then paymasters let us charge fees in held stablecoins or tokenized gold. TON uses relays with a stablecoin surcharge. On Solana, we use a Kora paymaster instance, also thanks to another module supported already by WDK, and provision associated token accounts during setup. TRON remains the exception: transactions use TRX, with fee delegation on the roadmap.

Sponsorship or fee pass-through depends on the enterprise tier, with costs shown in the quote. Removing separate gas top-ups helps users make their first transfer, including when holding fractional gold.

The complexity moves to our infrastructure. Paymaster downtime can interrupt settlement; mainnet stablecoin execution needs double-limit gas buffers and rate locks have to account for movement in the fee asset's price.

Interviewer: Where did the common wallet interface save time, and where did the differences between chains still show up?

Dami: It standardized the key operations across Bitcoin, EVM, TRON, TON, Solana and Spark. That helped us reuse our security work and integrate networks we knew less well.

But the interface does not remove each chain's account and fee mechanics. An unfunded Bitcoin wallet couldn't estimate transaction fees because it had no spending inputs. Initially, that looked like an API outage; we needed to recognize the wallet state and return a clearer message.

Solana transfers needed sender token accounts provisioned, and Spark initialization tried to access the network from inside our isolated enclave. We also saw a Solana dependency change break address derivation. We now pin dependencies and check known seeds against expected addresses before deployment.

Interviewer: How do you keep deposits, balances and transaction history in sync?

Dami: Indexers signal possible activity; they are not our source of truth. Signed webhook notifications trigger RPC confirmation and amount checks before we update the internal ledger.

For Spark, we poll public explorer endpoints and make targeted operator calls when a potential transaction appears. We replaced two external services with one internal routine, without Redis, private keys or build tokens. That followed three mainnet issues we identified in the reference indexer.

Balances come from live node queries outside the enclave. History comes from our database, populated by deposit and dispatch workers. On a slow connection, we render cached history while balance requests run in parallel. We have not collected formal latency measurements across regional mobile networks.

Interviewer: Is Enta a native app? Did you start with WDK's React Native starter or UI Kit?

Dami: Enta is a web app. We chose that because native installation creates drop-off in our target markets. We built our own web components and integrated the SDK primitives directly, with core operations running server-side inside enclaves.

We didn't use the React Native starter or UI Kit, so we can't provide a hands-on assessment of either.

Interviewer: You started integrating WDK during alpha and worked with us as the SDK evolved. Looking back at that process, where would clearer documentation have helped your team?

Dami: For our setup, clearer guidance on derivation behavior would have helped the most. In the Spark version we were using, the documentation pointed to one account while the runtime used another, and network numbering made that harder to follow.

During the integration, a Solana update changed how derivation paths were handled without explaining that change in the changelog. A call that had worked with the same seed then failed inside our enclave. We also found that fetching an account by index and by path could produce different addresses for the same seed. Having those behaviors documented would have helped us understand what to expect when integrating and updating the packages.

Our enclave setup also made it important to know which methods require network access. Starting a Spark account required a network client and waiting for synchronization, while the offline route we needed was behind internal exports. A note on each method’s network requirements would have saved us time.

Those experiences shaped what we would like to see going forward: clearer documentation of derivation and network behavior, and an explicit guarantee that derivation stays stable within a major version, backed by published test vectors.

Interviewer: Which of those problems took the most time, and did you contribute fixes upstream?

Dami: Spark inside the enclave was the biggest bottleneck. Initialization needed network transport, offline functionality was not publicly exported and failed initialization dropped socket handles that destabilized the service. A dedicated enclave proxy and fault isolation added about a week.

We also maintain Safe relay-library changes for missing sponsorship identifiers, discarded gas calculations and validation restrictions on stablecoin transactions. We use lockfile overrides to keep dependency resolution deterministic.

We have not yet submitted formal issues or upstream pull requests for these items. We have documented patches and migration notes ready to share with maintainers, and intended this technical account as the initial disclosure.

Interviewer: Has the key-management architecture had an independent audit?

Dami: We developed the setup with AWS solutions architects, using Nitro Enclaves and KMS attestation. Internally, we maintain a line-by-line assessment of key isolation, identified vulnerabilities, fixes and remaining risks. That internal assessment is distinct from an independent audit.

An independent review is underway. Its scope covers seed derivation, enclave attestation policies, WebAuthn assertions and guardian recovery constraints. We plan to publish the full results when it is complete.

Interviewer: Looking back, what did you assume at the start that turned out to be wrong?

Dami: We underestimated how much chain-specific behavior would remain behind a standard interface. We also underestimated the effect of an enclave having no network interface: initialization routines with implicit network calls forced us to rethink the integration sequence.

Key management and signing were bounded problems. Gas and paymaster behavior kept requiring work. Dependency updates also needed far more care because derivation changes can affect access to funded accounts.

We also found a mistake in our own backend: address generation respected the requested account index, but all eight transaction dispatch modules initially hardcoded index zero. Standardized wrappers had helped that mistake spread across integrations.

Interviewer: How long did it take to reach a build you could put in front of beta users, and how many people worked on it?

Dami: Roughly five months, led by one dedicated integration engineer. The first WDK commit for EVM wallet management was October 23, 2025. Nitro Enclave integration followed in February 2026. In March and April, we worked on balance synchronization, signing kill-switches and pending transactions.

Enta's separate web-application setup and deployment pipelines went live on July 9, 2026, about eight and a half months after the first commit. Six developers contributed across the broader module; two to three others supported product surfaces, with no more than three simultaneous contributors on WDK-specific work.

The five-month milestone covered functional wallet infrastructure across custodial and sovereign layers. Alpha access, private repositories, access tokens and mainnet debugging accounted for part of that time. We expect teams starting from today's public packages to move faster.

Interviewer: What would you have left out of that first build without WDK?

Dami: We would probably have limited it to USD₮ on one or two EVM networks. WDK made broader coverage possible across Bitcoin, EVM, TRON, TON, Solana and Spark.

Spark is a good example: building our own Bitcoin L2 functionality for an early release would have been out of reach. WDK also gave us TON relays, TRON resource delegation and Solana paymaster integration, which we would not have had the bandwidth to build independently.

Interviewer: To close, what three things do you most want from the next WDK release?

Dami: First, native WebAuthn support in the ERC-4337 package, including P-256 passkey signers and multi-owner thresholds. That would let us move more of our custom Safe flow back onto WDK primitives.

Second, derivation stability and explicit offline behavior: frozen derivation within major versions, published test vectors, release notes for path changes and clear documentation of network dependencies. We also need an exported Spark address encoder and constructors that do not silently start network operations.

Third, Solana account initialization and clearer state reporting. The package should handle sender token-account provisioning with paymasters and distinguish an uninitialized token account from a zero balance. We also intend to contribute our Safe relay changes upstream once maintainers review them.