If you haven't looked at my resume yet, here's the link.
This is everything beyond that document the real story, the mistakes, the breakthroughs, and the curiosity that shaped my path.
Tinkering My Way Into the Right Fit
I've always been a big fan of the computer era and always wished to become a computer engineer. I got my first job in my 3rd year at Aiisma, completely fascinated by the opportunity to work and learn. That was my first real day in a startup. Those were the days I learned REST APIs, frameworks, modules, app launches. That's when I got my first hint that startups are really all about continuous learning.
I then dived my way into another startup where I built cool stuff around video conferencing using external SDKs and worked on API backend development. Around the same time, I found myself exploring IPFS, which became the foundation of my final-year project. That exploration also led me into the world of NFTs, which eventually became my path to joining Dehidden, where I pivoted into a Technical PM role to ship NFT projects. And that's how I realized crypto was where I wanted to work to leverage the tech.
Initial Crypto PMF
At Dehidden, I found my personal market fit. We shipped around 15 projects over the course of a year, learning ERC standards and FAFO'ing through challenging situations: late deliveries, constantly revised client timelines, and breaking stuff late at night. I experienced all the scenarios, learned the best ways to resolve them, and worked with a brilliant team that pulled everything off and generated revenue in a crypto services company.
Alongside that, I became a degen. I built bug-hunting bots, sniper bots, MEV bots, rescue solutions for compromised wallets, and core tech for sniping. This is where I learned smart contract vulnerabilities and best practices.
Took a Break
After all that, I took a break. I dived deep into security and experimentation around bots. I fumbled big time, learned my way into smart contracts, participated in hackathons, worked on a confidential DeFi project, and eventually joined PlayAI as a smart contract developer.
At PlayAI, I led the team and built the decentralized architecture for AI nodes that perform real inference and computation. I wrote the client that coordinated consensus with the backend, built the license NFT and distribution model, and even spun up a Layer 2 for PlayAI built on OP Stack. Along this journey, I saw how interoperability was a huge issue. That led me to start Gasyard Finance.
Gasyard Finance
This initially started as a flow protocol. We built the product, but eventually it lacked design. I invited Avinash to be the cofounder, and that's when it really became Gasyard Finance. It started as an experiment, and at Token2049 we released our first route to Kakarot zkEVM. That gave us the initial traction we needed for validation.
In V1, we had a user pool for liquidity, but real business problems started showing up: distribution of fees among liquidity providers and profit-sharing was messy, deposit and withdrawal timing was unaccounted for, APY was low depending on volume, rebalancing cost was high, and supporting only gas tokens became an issue.
Gasyard V2 and V3
This pushed us toward V2, where we supported ERC20 tokens on EVM networks. But for proper fee distribution, we needed a network pre-TGE, which led us to connect with the Movement team, an altVM. That gave us our first launch on an altVM via MoveVM, while Movement also had EVM support.
V2 started as a decentralized layer using a decentralized liquidity pool and an intent-based solver model. It worked great, but too much decentralization comes at a cost: time and fees. Meanwhile, competitors incentivized users endlessly. Solver-side rebalancing also created efficiency issues.
Still, we ended up as Olympic winners at the Movement hackathon, and our Twitter grew from 100 followers to 70K. In the middle of all this, we built V3 to make the system permissionless and rebalance on our own end by creating a settlement layer to coordinate solver settlements efficiently, reducing costs for both solvers and users.
V3 kicked off with EVM + Movement routes and later added Solana support. This created a strong reflection that we were serving altVMs, but liquidity remained an issue. Cross-chain money movement needs market making or efficient rebalancing with upfront liquidity. We received feedback to support stablecoins to maximize LP deposits. That led us to support the Tron route because USDC/USDT usage is massive there, even though Tron isn't often supported by bridges.
However, despite having the tech, we didn't have the right LP partners. Our assumption that innovation alone would bring liquidity was wrong. Distribution is king, and partnerships are the way forward. This shaped V3.5.
V3.5: Our Final Approach
In V3.5, we supported all previous routes and added swap + bridge, enabling us to swap any asset to any asset on the destination chain. This was a huge unlock. It also allowed us to perform actions on behalf of the user using our solver a major unlock for chain abstraction.
Today, V3.5 performs cross-chain swaps and cross-chain actions on anything. But the liquidity challenge still remained, so we accepted that we couldn't build everything from scratch. V3.5 added fallback partner integrations, one of which is Stargate, to route bridge orders.
This completed our loop for a cross-chain interoperable layer that goes beyond bridging and becomes our moat. We reduced transaction times from 16 seconds in V1 to as low as 3 seconds in V3, and even introduced a gas tank system that takes it under 1 second using pre-deposits.
Now, it's a self-sustained protocol built from scratch and acts as the settlement layer for Stableyard. We found traction, PMF, genuine users, and repeated usage, but business scales with liquidity. So Gasyard V3 becomes an independent settlement service. I personally see it as an execution engine that could someday deposit into Aave on Ethereum while holding funds on Bitcoin BRC20, or run agentic execution across chains.
Learnings That Led to Stableyard
We experienced all the ups and downs of Web3 while building Gasyard. We learned the hard way that many Web3 users are more interested in gambling and casinos than supporting an open economy. But the tech we built for stablecoin movement, and our ability to ship it all in a year, led us to build Stableyard, a true stablecoin payment layer.
Now we cater to Web2 audiences who don't need to know anything about chains or networks. Crypto works as rails underneath.
The Gasyard experience and payment processor became our USP. At any time, we can completely own the rails to scale, and Stableyard becomes the UX layer that manages fast, smart money movement in existing systems. This enables QR payments, NFC payments, and real-world stablecoin commerce.
Stableyard: Where We Are Now
Stableyard today is the programmatic layer powering the Money Account, a core engine that communicates with multiple services to enable true financial rails while respecting privacy, atomicity, interoperability, compliance, and yield, all at once. Users stay in control of their spending while Stableyard manages interactions and disputes through a policy engine.
I believe code is law.
That's how we're now building Stableyard, putting use cases out to understand global user behavior. The DopePay app will be our first use case to enter South Asian markets and allow users to pay via stablecoins through QR codes.
We're positioning ourselves to pivot faster if needed:
- x402plus — a module for agentic banking
- Money Account Vault — for stable permissionless yield
- Global Identity Layer — connecting wallet addresses via username@domain tags
- POS Integration SDK — to enable existing machines to accept crypto
- DopeCards — to onboard more users into crypto
- And maybe even a true stablecoin card to compete with Visa
We're here to make stablecoins usable in the real world and FAFO our way into distribution. It's just a matter of time, patience, and continuous shipping.