Ripple’s legacy custody platform treated every on-chain action as a generic blockchain transaction, forcing institutional users to decipher raw technical logs just to mint a token or vote on governance.
I proposed and executed a fundamental architectural restructure, unbundling the monolithic transaction model into four distinct operational pillars: Transfer, Staking, Account Ops, and Smart Contract Management. This foundation enabled me to design a dedicated Smart Contract Hub that supports all common institutional use cases — from asset issuance to token governance. This engine not only boosted engagement by 10% but is now being productized as the architectural baseline for the upcoming standalone Ripple Tokenization Service.
The 4-pillar intent-based operational model (Transfer, Staking, Account Ops, Contract), decoupling smart contract logic from generic transactions.
The library of built-in contract templates for common institutional use cases, covering Tokenization, Governance, and Utility workflows.
The first product metrics dashboard, establishing contract adoption metrics to validate and guide iteration.
The high-fidelity vision prototype that served as the primary PRD for the Tokenization Service initiative.
Raw Transaction Data
Transfer
Move value across networks.
Staking
Generate yield from idle assets.
Smart Contract
Execute custom on-chain logic.
Account Ops
Manage account settings and access controls.
Enter password to view full case study
Access to the full design process is restricted to comply with NDA requirements. Please email contact@bryanshi.com to request an access key.
Diagnosing the transaction bucket fallacy
Through 10+ interviews across operations, treasury, trading, and compliance — plus a deep competitor audit — I uncovered a structural flaw: Ripple’s Custody UI mirrored the blockchain’s technical reality (where everything is a transaction) rather than the user’s operational reality.
To a blockchain, minting a token and moving funds are just “transactions.” To a CFO, they are two completely different worlds.
Institutional teams were struggling to manage the full Smart Contract lifecycle because the tools were disjointed. The research distilled a core journey shared across multiple teams, not just for tokenization, but for all contract interactions:
- Deploy: Engineering teams struggled to map business workflows to code, often rewriting deployment scripts for every new chain.
- Call & Query: Operations teams had to invoke raw methods (like mint or vote) using hexadecimal inputs to fulfill day‑to‑day demands.
- Monitor: Teams lacked a unified view of gas usage and event logs, often hopping between 3rd-party block explorers and internal tools.
- Upgrade: A high-risk process. Proxy‑based upgrades required manual data migrations, introducing significant operational risk without standardized tooling.
These insights revealed that while the intent was often asset management, the friction was entirely in the technical lifecycle.
Asset Origination
Instantiate custom protocol logic on-chain to define programmable value and ownership rules (e.g., issuing new tokens).
- ✕ Buried in generic transaction workflows
- ✕ Manual pasting of raw bytecode
- ✕ Zero pre-flight validation
Requires manual raw bytecode entry. Lacks templates and validation.
Prioritizing scale, clarity, and cost obstacles
Smarter, safer smart contracts start by standardizing operations and demystifying hidden workflows.
After diagnosing the lifecycle gaps, I facilitated cross-functional workshops to prioritize the structural barriers preventing institutional scale. The real risk wasn’t just “bad UX”, it was in the gaps between chains, tools, and teams. We defined four foundational challenges that the new architecture had to solve:
- Fragmented Workflows: Contract operations were buried within generic transaction lists. Operators had to search for specific “Call” transactions mixed in with thousands of payments, leading to context-switching errors.
- Cross-Chain Scalability: The legacy model was not network-agnostic. Engineers had to duplicate processes for every EVM network (Ethereum, Polygon, Avalanche, etc), slowing the rollout of new features — especially for multi-chain tokenization.
- Workflow Clarity & Operational Risk: Non-technical users lacked visibility into contract Application Binary Interface (ABI) definitions. Without human-readable guardrails, a “Mint” looked the same as a “Burn,” increasing the risk of misconfigurations and compliance exploits.
- Cost Optimization: Volatile gas fees and manual upgrade processes made operational budgeting unpredictable, discouraging regular smart contract use.
By tackling these technical pillars, we set the groundwork for a platform that could support any high-value use case — with Tokenization being the first major beneficiary.
Management
Irreversible errors & blind signing create systemic risk.
Ops buried in generic lists causes context switching.
Duplicated deployment processes for every new chain.
Unpredictable gas fees and high manual upgrade overhead.
Ideating a unified, template-driven contract hub
With clarity on the technical barriers, we pivoted to strategy. I led brainstorms to reimagine how smart contracts should work for institutions. The goal was to build a Centralized Multi-Chain Hub that could handle any contract type.
How might we design a smart contract experience that’s intuitive, discoverable, and scalable across chains and use cases?
The Hub Concept
A single dashboard where teams can Deploy, Call, Query, and Monitor contracts on any supported chain (ETH, Polygon, BSC) without leaving the platform.
Modular, Use-Case-Driven Templates
To bridge the gap between technical code and business intent, we designed a library of templates. While tokenization was the primary use case, the system was designed to support governance and utilities as well.
Contextual Guidance
To mitigate the “Clarity” risk, we embedded real-time ABI validation and gas estimation directly into the UI, ensuring operators understood the cost and effect of a transaction before signing it.
Guidance Layer
zation
tity
sig
nance
Templates
Hub
Designing a contracts hub with no-code templates
I mapped the end-to-end vision and scoped an MVP that balanced the ambition of a universal hub with the immediate need for tokenization support.
Turning raw Solidity methods into safe, repeatable business actions.
A Dedicated Contracts Pillar
We gave smart contracts their own home — distinct from Transfers and Account Ops. This “Contracts” tab brings deployments, calls, and monitoring under one network‑aware dashboard, eliminating the transaction bucket fallacy.
Trusted No‑Code Templates
We built a library of purpose-driven templates. For the high-volume tokenization use case, we standardized “Issue,” “Mint,” and “Redeem.” For other use cases, we provided generic “Custom Interaction” templates that still offered ABI decoding. This ensured operators never wrestled with raw calldata.
On‑Demand Contextual Guidance
To build trust, we embedded tooltips and visual previews that clarified critical concepts like gas estimates and approval rules. A side panel offers deeper guidance on demand, allowing users to explore advanced concepts without leaving their current task.
Shipping MVP flows across multiple EVM chains
We built the roadmap, then watched closely as users took the wheel.
Once we had alignment on the north star, we shifted to execution. Partnered with Product and Engineering to define a focused MVP, prioritizing essential smart contract operations—deploy, call, and query—while stripping away non-critical complexity. This let us move fast, validate our contract template concept early, and lay the groundwork for what’s next. Along the way, I delivered detailed design specifications that outlined task flows, structural patterns, and permission logic.
Testing templates and optimizing with product metrics
Validation
With the MVP shipped, we needed to test our assumptions in the wild. Data showed us what users skipped — and why they didn’t trust what they saw. We ran targeted user tests on template workflows, convened expert design reviews, and gathered asynchronous feedback from client‑facing teams. Early in the MVP validation, gaps in platform usage tracking became clear. I initiated and partnered with DevOps, Security, Data, Security, and Compliance teams to define and launch our first Custody product metric dashboard. A quarter after launch, we measured the following key metrics to gauge impact:
- +11% Engagement: Organization Engagement Rate increased significantly after unbundling contracts from generic transaction logs.
- +18% Operational Velocity: Average time to execute complex calls (e.g., Mint/Burn) decreased due to the template-driven wizard.
- +235% Successful Deployment Volume: Total number of contracts deployed.
- +69% Template Utilization: Percentage of deployments using no-code templates.
With real‑time insights at our fingertips, we could quickly identify adoption trends, surface friction points, and steer our roadmap with confidence.
Evidence-Driven Iteration
Even with promising early metrics, friction points emerged—especially around discoverability and data transparency. One recurring issue was low organization engagement. Many users weren’t clear on what the “Contracts” feature enabled or how it applied to their workflows. To boost discoverability, I partnered with Marketing and Content teams to launch an in-app feature banner and authored targeted user guides for top workflows, ensuring users could understand and activate contract operations easily.
Another pattern emerged around low usage of contract call and query operations. Through follow-ups and testing, we learned that the simplified response view lacked critical details users expected, such as transaction hashes and details. To address this, I worked with Engineering to introduce a raw JSON response switch, giving users complete transparency into onchain results.
These examples reflect how we continuously tuned the experience based on real usage patterns, transforming the MVP into a more discoverable and operationally useful tool.
The baseline for Ripple’s tokenization future
Unbundling smart contracts from generic transactions did more than improve usability metrics; it defined the product strategy for Ripple’s next growth horizon.
- Architectural Validation: The “Intent-Based” operational model proved so effective that Engineering is now hard-coding this separation into the platform’s core indexing service. The separation of “Transfers” vs. “Contract” went live in the last 2025 release.
- The Tokenization Service: Most critically, the template-driven architecture we built to support general smart contracts proved to be the perfect engine for asset management. The vision prototype created for this project is now serving as the direct baseline for the upcoming standalone Ripple Tokenization Service, accelerating its discovery phase by an estimated 3 months.