Content pfp
Content
@
0 reply
20 recasts
20 reactions
Varun Srinivasan pfp
Varun Srinivasan
@v
The Frame Transactions spec is ready for feedback! Please share your thoughts in replies, comments or DMs. Your feedback is very important to help us get the design right. https://www.notion.so/warpcast/Frames-Transactions-Public-Draft-c2e0d3210d684b4cb7803de1810db36d?pm=c
61 replies
108 recasts
506 reactions
df pfp
df
@df
Not a fan of this proposal. It adds a lot complexity to the spec and doesn't meaningfully improve over the current problems of crypto UX: speed, safety, simplicity. The flow has significant friction and low conversion for the most common txs in social: small mints/fees, so those txs will find other ways to convert.
1 reply
0 recast
3 reactions
df pfp
df
@df
if this proposal doesn't serve the vast majority of transactions, that are small and low risk, is the complexity it adds really justified? Will clients and frames really integrate all these checks rather than just using a different solution for those transactions, and simply link out to wallets for other txs?
1 reply
0 recast
1 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
Do you have a counter proposal that you like for adding transactions to frames?
1 reply
0 recast
1 reaction
df pfp
df
@df
for 95% of transactions (sub $10), the solution should be 1. risk bounded by amount sent/paid, no context needed 2. max click + confirm 3. no switching of apps 4. no bridging, no need for a specific token on a chain Y For the other 5% you can link out to wallets
1 reply
0 recast
1 reaction
df pfp
df
@df
Just like frames inverted and forced developers to fit their apps into a very narrow secure abstraction of frames to get functionality, there's now an opportunity to get smart contracts to do the same. Narrow, secure API Could work something like this, but it's a very rough sketch https://warpcast.com/df/0x34a3a7b3
1 reply
0 recast
1 reaction
df pfp
df
@df
frames' distribution is the leverage to get smart contracts to be rewritten and recreated into a paradigm that doesn't risk losing all your assets on what is essentially the equivalent of buying a coffee. It's an opportunity to push crypto UX forward
1 reply
0 recast
2 reactions
Varun Srinivasan pfp
Varun Srinivasan
@v
There’s nothing stopping a client from implementing the solution you described on top of this spec. Unless I’m missing something
1 reply
0 recast
0 reaction
df pfp
df
@df
agreed, but rather than it only working with contracts whitelisted by the client, it would be nice to have a convention that grew the subset of contracts that are permissionlessly safe (without a contract enumerating whitelist)
1 reply
0 recast
0 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
How would you deterministically figure out that a contract is safe?
0 reply
0 recast
0 reaction