Melbourne, Australia
- Tweets 4,241
- Following 597
- Followers 5,185
- Likes 3,663
re: frame tx vs 8130 debate
been advocating for protocol defaults for a while now :)
8130 is magnitudes more closer than frame txs here
Frame Transactions will be shipping in Viem if it is chosen as the “native AA standard”.
However here are my thoughts on Frame Transactions:
An ideal UX-focused protocol should offer wallets and app devs with conventional defaults, and an escape hatch for configurability. Defaults that cover ~80% of real world use cases; configurability for the 20%.
The problem with not having defaults on a native AA standard like Frame Transactions is that now we need to create ERCs for common and trivial AA features so that wallets can align on standard APIs to distribute downstream to app devs (e.g. batch calls, fee sponsorship, permissions, etc).
We have a batch call standard now great (ERC-5792), but that took 1 year (!!!!) for wallets to align on, and a lot of top wallets or apps don’t even use it yet.
Now, we need ERCs for fee sponsorship and permissions (and more). There are a few ERCs out there now which cover this, however, there are a lot of dupes with fragmented APIs stewarded by different large wallets. For example, Base’s ERC-7895 + Spend Permissions vs. MetaMask’s ERC-7710 + ERC-7715 - which have largely differing permission models that leak to app devs — and no other wallets implement these standards yet.
If the protocol had defaults, then wallets would just need to proxy through for app devs via eth_sendTransaction fields that mirror the RLP structure (we do this already!).
I’m not saying we should not have any configurability at all, but we should offer conventional defaults with a configurable escape hatch.
3
1
35
4,816
re: frame tx vs 8130 debate
been advocating for protocol defaults for a while now :)
8130 is magnitudes more closer than frame txs here
Frame Transactions will be shipping in Viem if it is chosen as the “native AA standard”.
However here are my thoughts on Frame Transactions:
An ideal UX-focused protocol should offer wallets and app devs with conventional defaults, and an escape hatch for configurability. Defaults that cover ~80% of real world use cases; configurability for the 20%.
The problem with not having defaults on a native AA standard like Frame Transactions is that now we need to create ERCs for common and trivial AA features so that wallets can align on standard APIs to distribute downstream to app devs (e.g. batch calls, fee sponsorship, permissions, etc).
We have a batch call standard now great (ERC-5792), but that took 1 year (!!!!) for wallets to align on, and a lot of top wallets or apps don’t even use it yet.
Now, we need ERCs for fee sponsorship and permissions (and more). There are a few ERCs out there now which cover this, however, there are a lot of dupes with fragmented APIs stewarded by different large wallets. For example, Base’s ERC-7895 + Spend Permissions vs. MetaMask’s ERC-7710 + ERC-7715 - which have largely differing permission models that leak to app devs — and no other wallets implement these standards yet.
If the protocol had defaults, then wallets would just need to proxy through for app devs via eth_sendTransaction fields that mirror the RLP structure (we do this already!).
I’m not saying we should not have any configurability at all, but we should offer conventional defaults with a configurable escape hatch.
3
1
35
4,816
the world needs less ERCs
Aligning on contracts, standards, and APIs to represent common functionalities of frames will be. 😜
It took us 1 year to align on a trivial batch calls standard in wallets — now we need to align on standard interfaces of other wallet functionalities like permissions, sponsorship, and more.
We shall see how that plays out.
2
13
831
the devs want defaults
The power to choose (configuration) and the power to provide defaults (convention) is much better than the power to choose by itself.
The former, no matter what way it is architected, will always introduce abstraction and integration complexity which affects devs and users downstream trying to do really trivial things, yet have to hook into non-trivial abstractions to do them.
We can do better.
11
350
Announcing Ox v1
The library powering Viem, Wagmi, and others, is now stable!
🧰 300+ battle-tested modules covering everything from ABIs, Cryptography, Transactions, Post-Quantum, Signatures, Keys, and more.
⚡ WASM-enabled performance
🤖 Agent-first APIs
✨ Many guides!
1
2
20
1,046
Incur now supports distributable cross-platform Standalone Binaries!
Set up the GitHub Action, and then direct users to install your CLI via `curl` to the GitHub release!
Bonus points if you redirect your domain to get a short install URL (e.g. example.com/install.sh).
Introducing 𝚒𝚗𝚌𝚞𝚛 – the CLI framework built for agents and humans.
Automatic discovery for agents enabling a guided experience for humans, without compromising tokens & context windows.
» npx incur skills add
2
22
2,244
Reminder vocs.dev >>>>>> Mintlify.
Make your docs actually friendly for agents. Don’t claim it.
6
1
48
5,090
few cool projects built using incur:
→ Stripe Link CLI: link.com/agents
→ Shopify UCP CLI: shopify.dev/docs/agents
→ Phantom CLI: docs.phantom.com/wallet-sdks…
→ World AgentKit CLI: docs.world.org/agents/agent-…
→ More: npmjs.com/package/incur?acti…
Introducing 𝚒𝚗𝚌𝚞𝚛 – the CLI framework built for agents and humans.
Automatic discovery for agents enabling a guided experience for humans, without compromising tokens & context windows.
» npx incur skills add
1
1
50
8,159
If you’re using Viem, we have already supported ENSv2 since August last year.
⚠️ PSA to all devs who use Ethers for ENS resolution ⚠️
Please update Ethers to v6.17.0 to ensure your app supports ENSv2 automatically when it launches!
Should be a simple package upgrade - no breaking API changes
2
1
22
1,226
does any docs that use mintlify.com have non-red web vitals lol? quite unbelievable
even mintlify.com itself ships red
1
1
8
734
vs. vocs ootb on the heaviest of docs
Fast docs improve feedback.
Readers should not wait for heavy JavaScript.
Agents need quick responses while they iterate.
Search engines need content that is fast to discover.
Vocs combines Vite and waku.gg for hybrid server rendering and static generation.
2
1
8
643