Selected work · 02
Architecting the FalconX custody platform
A greenfield custody platform creates a rare opportunity and a serious responsibility. I worked from hands-on prototypes toward reusable foundations that could make each new asset and product safer to support.
Institutional custody · Transaction infrastructure
Visit FalconXMy role
Hands-on architect and builder of a greenfield custody platform, from early prototypes through reusable foundations.
Context
The conditions that shaped the work.
- Context
- A new institutional custody platform needed foundations for the next wave of assets and products rather than an extension of a single existing integration.
- Constraints
- Transaction construction, signing, policy, indexing, broadcasting, balances, and staking carry unforgiving failure modes when the system protects customer assets.
- Core tension
- The platform needed enough common structure to create leverage without hiding the chain specific behavior that determines correctness.
Timeline
How the work progressed.
- 01
Prototype
Make the hard path real
Hands-on prototypes exposed the transaction and signing concerns that a credible platform would need to own.
- 02
Foundation
Identify the repeating responsibilities
The work separated durable platform concerns from the asset specific behavior that could not be abstracted safely.
- 03
Capability
Make the next asset safer
Reusable, event-driven foundations turned support for new assets into a repeatable platform capability.
Decisions
Key choices and their tradeoffs.
Prototype before fixing the platform shape
Prove the direction through working transaction paths before treating the first architecture as permanent.
Tradeoff
Some early work optimized for learning, but it reduced the risk of generalizing around imagined requirements.
Abstract recurring responsibilities
Create reusable foundations for transaction construction and the surrounding event flow.
Tradeoff
The platform had to preserve asset specific behavior rather than force every chain into a false common model.
Measure leverage through the next launch
Judge the abstraction by whether the next asset became safer and more repeatable to support.
Tradeoff
Generality alone was not the goal. Each shared boundary needed to remove real launch risk.
- Product capability
- Transaction construction
- Policy and signing
- Broadcast and state
Outcomes
What changed.
- Established reusable, event-driven foundations for the custody platform.
- Turned support for new assets into a repeatable platform capability.
- Created a foundation that product teams could build on without flattening asset specific risk.
Lesson learned
The useful abstraction is not the most general one. It is the one that makes the next launch safer.
Continue
Next: BitGo
Building the organization that growth demanded.