Howy

@StackDigest Yup, but it’s not a big lift to fork + remove that check. The purpose is anti footgun, similar vibe as to check if transfer recipient is address(0)

@howydev But isn’t it blocking to open the channel here, unless I misunderstand it? #L68" target="_blank" rel="nofollow noopener">github.com/tempoxyz/tempo…

So clearly designed only for Tempo?

Every ad impression, every recommendation algorithm, every retargeting pixel — all of it monetizes the space where human intent is unclear. Agents collapse that space to zero. An agent arrives with a mandate. Get me X. Budget Y. Constraints Z. - No attention to capture. - No desire to manufacture. - No conversion funnel to optimize. That's a different customer. And it needs a different internet. - The attention economy monetizes the path to intent. - The intention economy monetizes the *fulfillment of intent.* At @tempo been building the protocol for that second economy — the Machine Payments Protocol, with Stripe, supported by Visa and others. Open source, designed for IETF standardization. I wrote the full piece on what the intention economy looks like and why the infrastructure for it doesn't exist yet 👇

GH: github.com/howydev/create…

How does it work? We SSTORE2 the creation code, then CREATE2 a bootloader that delegatecalls it and becomes your contract. Scoped deploys just appends msg.sender to the bootloader init code

Normal create3 needs two keccaks to get the address (forwarder create2 → create nonce), this doubles the cost of mining vanity addresses over CREATE2 Have been nerdsniped for a while to build a better CREATE3, finally landed on something I think actually earns the v2

🧵 Tempo Architecture Deep Dive @tempo is a payments-first L1 built for stablecoin transactions, whose testnet has launched a few weeks ago. There are so many native features, but how will be the UX? What's the disadvantage? In this thread, I'll break them down. 👇

Tempo’s testnet is live! Any company can now build on a payments-first chain designed for instant settlement, predictable fees, and a stablecoin-native experience. Tempo has been shaped with a wide group of partners validating real workloads including @AnthropicAI, @Coupang, @DeutscheBank, @DoorDash, @Lead_Bank, @mercury, @nubank, @OpenAI, @Revolut, @Shopify, @StanChart, and @Visa. Since our announcement, @brexHQ, @Coastal, @crossriverbank, @deel, @faire_wholesale, @Figure, @GustoHQ , @Kalshi, @Klarna, @Mastercard, @Payoneer, @withpersona, @tryramp, and @UBS have also joined as design partners. Dedicated payment lanes, stablecoin gas, deterministic finality, a built-in stable asset DEX, and programmable smart accounts are all live on testnet. If you’re building or modernizing payment flows, you can start integrating and testing today.

Excited to share that the @ithacaxyz odyssey continues at @tempo! We will accelerate Tempo’s mission towards real-world crypto adoption while further stress-testing and optimizing our existing open source stack for the entire crypto ecosystem. Thank you for the trust, onwards.

@glennonchain @uttam_singhk Don’t forget movement labs gmove

@uttam_singhk Yes but now we have Aptos and Sui

Imagine how big Facebook Libra could have been generational fumble fr

Porto beats ERC4337 by miles in gas which means both in cost & throughput.

3 mainnet x-chain demos of using Porto in DEXs in Safari mobile. Self-custodial, no passwords, no extensions, cross-app, cross-device. Batching, sponsorship, state of the art gas costs, 1-click interop and so much more. 1/3 @Uniswap:

Porto is now production-ready & fully open source! Porto’s north star is to enable secure and programmable web-native crypto payments & finance without passwords, or browser extensions. Integrate now in 2 lines of code and in less than 1 minute: `pnpm i porto`.

@joalavedra @gakonst @openfort_hq (Fun fact - I used to work at alchemy before ithaca, so I worked on both benchmarks referenced 😀)

Hmm, it’s an AA solution benchmark based on feature set. Also, our accounts are: 7702 delegation to a 7702proxy to an implementation, which is architecturally less efficient than the create2 SCAs we’re benching against. The 4337 accounts are rly optimized, our cost gains comes mostly from our ground up redesigned entry point around cost Alchemy’s MA v2 and ZD kernel uses EP 0.7 Webauthn - depends on whether the network has 7212 but everyone uses the same webauthn verification libs, so the cost delta will be the same

The new Openfort accounts will take many by surprise. Using both the AA-Benchmarks from Alchemy and Porto methodology.

@joalavedra @openfort_hq Congrats on the launch! Something here confuses me - why is a uniswap swap cheaper than an erc20 transfer?

@Agusx1211 @gakonst @jamalavedra That makes sense My biggest concern is reliability tbh, finding a grief vector against simulation is essentially now a DoS vector. Are there ways to guard against this? +1 on the sequencers running 5189 txs also, that makes a lot of sense to me as the end game of AA

yes that's a real risk for the relayer, if it happens, is up to them (or up to the endorser maintainer) to fix it I am not too concerned about that tbh, relayers don't hold huge quantities of live funds, even if they get rekt they can quickly recover, no user funds at risk, etc on the flip side with the entrypoint you always pay "the cost" for every transaction I am willing to bet that in the long run, even if a few 5189-like relayers get rekt, it would still have been cheaper than always paying for entrypoint overhead and my thesis is that eventually sequencers themselves will become 5189 actors, and at that point you no longer have that risk, because the sequencer controls atomicity

That makes sense One of my concerns in these type of systems is “zero cost griefs” - a way for some malicious actor to create txs that pass simulation but fail on-chain, costing the attacker nothing. They then replay this to drain the relayer (or the relayer pauses relaying, which is also bad) Currently, the EntryPoint (or our orchestrator) prevents that from happening by limiting what can happen in validation Curious how you think about this in the non EP system?

@howydev @gakonst @jamalavedra yep, the payment transaction is atomic with the rest of the bundle, so if that fails, everything gets rolled back but the relayer still has either to "inspect" the payload or straight up simulate to ensure it won't get griefed