On September 11, I gave a presentation at the London DeFi Summit to discuss UMA’s Synthetic Asset Token and how we designed the product from a financial engineering perspective. This talk has 3 main parts:
- Why did we design synthetic asset tokens at UMA?
- What is a blockchain financial engineer?
- How did we design/engineer synthetic asset tokens?
I also met Andrej and Charlie from Deep Work Studio, a team of designers helping blockchain-based projects run product design sprints. We got to talking about what the unique challenges of design sprints for blockchain products – and especially for blockchain financial products like the ones discussed in his video.
Traditional Design Sprints
Consider the design sprint as canonically defined in “Sprint” by Jake Knapp and others from the GV team. There are 5 steps: 1 each day for a 5-day sprint cycle.
- Asking “How Might We” questions to agree on long-term goals and 3 short-term sprint questions (potentially with dot voting)
- Brainstorming potential solutions, with lightning demos of existing products to draw inspiration from
- Optional: Defining user stories and “a-ha” moments
- Deciding on which solutions could be turned into prototypes (enabled by dot voting)
- Making prototypes individually, then agreeing on and building the final prototype (enabled by dot voting on features)
- User testing the prototype with a small set of potential users (say, 5)
Jake’s book optimistically suggests that you can apply the process to all manner of design challenges – even including an example of a teacher using it to teach math to students! – but there are a few extra considerations when designing financial products on the blockchain.
Blockchain Financial Product Design Sprints
It’s important to distinguish the kinds of products we’re talking about. In particular, there’s a growing community of “token engineers” building complicated ecosystems with native tokens that incentivize different kinds of behavior (not the products I’m talking about). These ecosystems often have many kinds of adversarial opponents whose behavior (especially in extreme edge cases) can’t be easily predicted by user tests with a few participants. How do you collectively design and test (and what does it mean to test?) such a complicated system in this kind of framework? Where do you find the users? Companies like Gauntlet offer “blockchain simulation platforms” in a SaaS business to help model this behavior.
Rather, blockchain financial product design is less about a large ecosystem of actors and more about a set of personas that have fairly clear roles:
- Issuers and counterparties
- Market makers
The questions we then have to answer when designing blockchain financial products center around how these 3 types of parties interact. Some examples:
- Who will act as an issuer or initial counterparty for the product?
- If the product doesn’t exclusively reference on-chain assets, how will margin be secured until off-chain information can be confirmed? (This ties in to the oracle problem and oracle design.)
- What is the expected market equilibrium for the product? At what price will it trade? Is that the desired price or the “correct” price?
- What mechanisms will force the product to trade at the “correct” price?
- How will liquidity aggregate for the product?
- Meta question: what happens if markets are not efficient? Are other mechanisms (aside from “market forces”) needed?
In the fiat space, this would be like designing a new kind of ETF, ETN, or retail structured product (phoenix autocallable?). In the blockchain space, this would be like designing a stablecoin like Basis or Ampleforth, expiring futures like yTokens, or UMA’s Synthetic Asset Tokens or BitDEX. The next post will cover how we might run a formalized design sprint process to pick product features to answer these questions effectively…