1. Verify Links Before Engaging

In the Web3 ecosystem, the credibility of a link can be the thin line between secure trading and falling victim to a scam. Phishing attempts are rampant, with scammers crafting websites that mimic legitimate projects to steal your assets. Before connecting your wallet or signing any messages, take the following precautions:

- Double-Check URLs: Always verify the URL in your browser. Look for subtle misspellings or unusual characters that might indicate a fake site.

- Social Media Verification: Before engaging with any project, check its social media presence. If you follow some of industry leaders in farcaster or X, you can always check if any of them follows or not.

- Check the Other Platforms: Having a Dexscanner profile or having an open telegram are also good sign but always be cautious.

- Be Paranoid: You should always be careful with using new products.

2. Be Cautious with Token Approval

When swapping tokens on decentralized exchanges (DEXs), you'll encounter a step requiring you to approve the DEX's smart contract to spend tokens on your behalf. This step is crucial for the swap to occur, but it also presents a risk if not handled carefully:

- Limit Approval: Instead of granting permission to spend an unlimited amount of a specific token, only approve the amount you intend to swap. This minimizes your risk if the smart contract has vulnerabilities or if the DEX is compromised.

- Understand the Risks: A common scam involves tricking users into approving maximum token spend, allowing attackers to drain your wallet. Always review the approval amount and be wary of any requests for excessive permissions. Try to not make blind signing.

3.Verifying Smart Contracts

The backbone of any project in the DeFi space is its smart contract. However, not all smart contracts are created equal, and some are designed to scam:

- Look for Verification: Trusted platforms often have their smart contracts verified on explorers like degenscan. Verification means the contract's code is public, with the upcoming security tool integrations (like goplus security) you can also check if the token is scam or not.

-Check the first 50 transaction of the Coin: Check if first 50 tx has happened in the pool or via token transfers.

4. Consider Using a Burner Wallet

If you're experimenting with new projects frequently, minimizing your risk exposure is crucial:

- Use a Burner Wallet: A burner wallet is a separate wallet used solely for high-risk transactions or testing new projects. By keeping the majority of your assets in a primary wallet and only a small amount in the burner wallet, you reduce the potential impact of a scam.

- Delegate.cash: Allows you to link a burner wallet and control it from your main wallet.

Conclusion

The Degen chain, while offering immense opportunities for meme coin enthusiasts, also harbors risks that necessitate a cautious approach. By verifying links, being prudent with token approvals, ensuring smart contract authenticity, and considering the use of a burner wallet, you can safeguard your assets against the most common scams. Remember, in the fast-paced world of cryptocurrency, taking the time to secure your investments is not just wise—it's essential.

Rollups are essentially blockchains, meaning they have a capacity limit. When a rollup reaches its maximum capacity, the base fee increases, resulting in higher fees for users. However, what exactly determines a rollup's capacity?

A Rollup user basically pays fee for three things:

- Data Availability Cost.

- Proof Verification Cost (only for ZK Rollups)

- Execution Cost.

Data Availability and Proof Verification costs are needed for Rollups to inherit security from Ethereum.

Before 4844, the amount of data that rollups could post to Ethereum in a block was very limited. This restriction constrained the throughput of rollups due to Ethereum's data limit for what rollups can submit. As a result, gas spikes in L2's were a rare occurrence

After protodanksharding, storing data on Ethereum became significantly cheaper than before. With the decrease in data storage costs, we've seen the execution limit of L2. Currently, users are demonstrating increased demand for L2's execution.

Fortunately, the @base and other L2 teams are actively working to increase the execution capacity of L2s. This is crucial for smart accounts because without affordable gas prices on L2s, we will continue to see escalating fees for smart accounts. This was my thesis when we transformed EIP-7212 into RIP. Many people told me that gas prices on L2 were almost zero, questioning the need for RIP-7212 on their chain. Now, with the recent gas spikes on L2, we see the answer.

What's next for L2's? I'm extremetely looking forward to see performance optimized EVM's (zkSync) and non EVM's (Eclipse, Fuel) to come into play. Regarding EVMs, I'm not sure if solely increasing the gas limit would be beneficial as it also leads to State Growth.

dmarz ⚡️🤖

@_danielmarzec

cool idea by @ch4r10t33r to support bundler APIs in the domain name space! Also RIP-7560!

Shill me on why SUAVE should implement RIP-7560?

dmarz ⚡️🤖

@_danielmarzec

Looking for chad API designer input for our multi-domain SUAVE effort collective.flashbots.net/t/multi-chain-…

7

3:28 PM • Feb 16, 2024

Before we begin, I want to clarify that I am not an expert in MEV or someone who has an in-depth understanding of SUAVE. I only had an opportunity to work on SUAPP during a hackathon and had a chance to speak with Daniel to learn more about SUAVE.

Dogan (∎, ∆)

@doganeth_en

1/ Introducing SUClave: A New AMM Design That Utilizes Intents (SUAVE) and Uniswap V4 to Address the LVR - LP Profitability Problem.

Let's delve into the mechanism details and explore how we aim to solve it

github.com/getclave/sucla…

217

9:16 PM • Nov 19, 2023

My view about SUAVE as a researcher on the team that builds consumer-facing crypto applications is SUAVE should be the gateway for users to interact with the blockchain world. We have enough rollups and L1s but MEV and interop area are still lacking.

SUAVE is an orderflow machine which can give users the best execution path while giving the highest profit possible for validators. This is possible via their SGX-based architecture, so I highly believe that SUAVE can be used as a source of trust across the blockchain world.

The best part of SUAVE for developers is the ability to abstract the chains, which is a real thing (not like other "chain abstraction" buzzwords). However, Ethereum's current account model is not designed for the best user experience, making it difficult to build abstracted apps.

Without account abstraction, SUAVE is like a Ferrari with an old chair inside. Because users should not care about the seed phrases, the gas token, or even the chains themselves. And the best part? We can solve the multi-chain AA problems if accounts are settled on SUAVE.

I don't think that RIP-7560 or 4337 differs a lot because I can not see any trust assumption changes with an ERC-4337 bundler running inside SGX and RIP-7560. But AA is a must for SUAVE, not something that good to have.

Zora is easy to use.

Zora is web3’s Instagram; creators simply share their art and earn money & visibility. It is as simple as web2 for creators. They have put a huge effort into making it easy for creators. Creators can be onboarded to Zora with only mail, and they can easily upload their images and let users mint & collect them. So, they have solved the issues for the creators. Gasless, seedless, semi-custodial onboarding for creators, which solves almost all issues for them.

But for users, the onboarding and having an asset on Zora is still a huge problem, and the main problem for users is bridging & cross-chain problems. Imagine that you’ve been onboarded to the Zora app and want to mint an NFT; how do you do it?

1) Using onramps or CEXs - which is not available for almost half of the world

2) Using Zora’s native bridge - took at least 10 minutes and costs 20$.

3) Using third-party, rollup to rollup bridges - UX is broken; I used Orbiter bridge to fund my Zora Chain wallet, and my funds got stuck for about 2 hours.

4) Instead, I created a collection and allowed my followers to mint. I funded my wallet this way because other methods were not broken.

Before that, what was my intent to fund my wallet?

Minting an NFT for an amount of ETH or any ERC-20.

There should be an easy way to understand users’ intent and execute it, and with the rise of new multi-chain bridges, it is possible to build a composable version of Zora.

The solution for EOAs: Finding a trust-minimized way for token bridging.

I’m sure that there are a lot of trust-minimized ways for doing it multi-chain, but the solutions that I’m aware of are liquidity bridges: Hop and Connext.

They allow you to call a function that doesn’t depend on where users are, but they are not that cost-effective for big amounts of money. these systems allow users to perform cross-rollup transactions without leaving the rollup.

Liquidity bridges allow trust-minimized and fast bridging, but their costs are not that cheap. Trusted bridges like Orbiter offer fast and cheap token bridging, but it comes with a huge trust assumption. But given that it is only for token bridging and is going to be used for only small token transfers, the trust assumption can be understandable for this use case.

Or we can also use Hyperlane and create a bridge with the trust mechanism that we prefer (Their verification layer is modular) - Interchain Accounts, MPC-based solutions, and many more.

So, if we can assume that we’ve found the best way for token bridging, the only thing we need is to create a good front end. The ideal user flow should be like this for a. new web3 user:

• The user is getting onboarded to the app,

• Selects the onramp provider or getting funded via CEX

• Starts to use the app.
  With the cross rollup compatibility, newbie users are getting a huge advantage: they can use all onramp options available for ALL Ethereum Rollups. Let’s give some examples:

  • If the user is from the US, they can be onboarded via Base - Coinbase, which is so easy to use and is doing a great job with Circle.

  • If the user is from Chinese, then it can be onboarded via OKX or Binance to Arbitrum or Optimism, and they can even not realize that they’re on a different rollup.

If the user is an existing Ethereum Rollup user:

• Users are getting onboarded to the app

• Start to use the app without thinking about which Ethereum Rollup they’re on.

This is easy for EOAs because you simply get the same account on different Ethereum Rollups, and key rotation is not supported in EOAs, which makes them easy to control across different rollups. Let’s talk about smart accounts and how to make them multi-chain with as less trust assumptions as we can get.

Smart Accounts & Multi Rollup Zora Experience:

Before diving into details, I want to highlight an important problems of multi-chain AA: cross-rollup synchronization. Since the Smart Accounts are working with Smart Contracts and Ethereum rollups can not communicate with each other in a fast, cost-effective, and trust-minimized way, we can not synchronize smart contracts.
Also, calculating the address with Create2 is working smoothly as soon as the Ethereum rollup is EVM equivalent. For example, if the chain that the smart account settled is on zkSync, then the zkSync address and other EVM addresses are going to be different. This problem can be solved via ENS.

I’ll explain my thoughts on smart accounts by dividing them into two parts:
1) Smart Accounts that use secp256k1 curve for main validation (EOA like smart wallet but with advanced AA features)

This is easy because most of them are working on only EVM equivalent networks and use the same address; the only thing that the bridge relayer needs to do extra is sponsor the first transaction for deployment (or it can be done by batch transactions).

So the user flow will be like:

• The user is getting onboarded to the app

• Starts to use.

But under the hood, the bridge relayer executes the token bridging and sponsors the useroperation.

2) If Smart Account uses a different elliptic curve: Passkey and Secure Enclave based signers.

This is a bit harder than other solutions because passkeys use secp256r1, and it needs an onchain verification, which consumes high gas if the chain that Smart Account lives doesn’t support RIP-7212 (A precompile contract for secp256r1 verification), which I’m also one of the co-authors of it. I’d be so happy to see Zora also integrating RIP-7212 to be compatible with other rollups.

But let’s talk about the worst cases: the case that a passkey-based wallet is living on a non-EVM equivalent chain or Zora has no RIP-7212 support.

In this case, the ideal solution is having a double signer enabled validator contract for the smart account; one signer should be the passkey itself, and the other signer should be a signer that works with a Turnkey, Portal Enclave key management system. If Turnkey or Portal tries to censor users, they should be able to escape from their censors, but without RIP-7212, I don’t think that passkey-based wallets can be first-class citizen smart wallets.

But calculating the account address becomes more and more problematic with this structure because the bridge relayer should know the public key of the passkey + turnkey’s public key, and as you can see, it is complex = extra code bug risk…

And this solution adds extra trust assumptions and a lot of engineering complexity to the app.

But with these supports, Zora will be able to reach more existing web3 users and more onramp solutions for the newbies. For example, we -Clave- are working on having a 1:1 ratio onramp for the Turkish Lira onramping, which will make Turkish users' onboarding much easier, and this is just one simple example of a specific region.

Final thoughts:

These thoughts are just some random thoughts that I had while using Zora. I know that engineering complexity kills innovation, and my writing should be just considered as a random - non-deven feeling of a web3 researcher.

I love Zora and will keep using it :)

If you're not familiar with state diffs, you can refer to my previous blog post where I have explained the details of state diffs and why Account Abstraction is more powerful with state diffs.

Dogan (∎, ∆)

@doganeth_en

1/4337 (Account Abstraction) is gaining momentum, but it has a problem: high calldata costs. Fortunately, @zksync's state diff model offers a solution. It allows for reduced calldata costs for complex verification mechanisms on @getclave's account model

mirror.xyz

State Diff and Account Abstraction

The concept of Account Abstraction (AA) is gaining significant momentum in the blockchain space. Despite the promise it holds, AA faces a major challenge: the high costs associated with calldata. In...

261

8:49 PM • Dec 17, 2023

The TLDR of state diff is, some of rollups such as zkSync and Starknet only post state differences to L1 instead of sending all transaction data. This reduces the calldata costs, which make up almost 90% of a transaction's total cost. To explain it, let's give a simple example: Imagine a scenario where Alice sends 1 ETH to Bob and Bob sends 1 ETH to Charlie. State diff rollup only posts that Alice's balance is down 1 ETH and Charlie's balance is up 1 ETH, whereas TX data rollup posts all TX data.

In a DEX swap, the user first calls approve function and then transfer function. However, this UX is not efficient as it involves multiple steps, and users cannot perform a one-click swap. Also, this has a problem that resulting in users sending unnecessary data to L1.

Batch Transactions allow for the execution of two transactions at once, reducing gas fees and improving the user experience. Using Clave Account's BatchCaller contract, users can perform multiple transactions in a single transaction. This means that users approve the transaction and then do the swap by calling the transferfrom function in one transaction. The L2's storage slot, which lives in L1, only changes with User's changed balance and never learns about approval, reducing the call data cost.

Baki

@LibraryDefi

A little experiment on batching.

Currently, if you're swapping on @zksync:

- With EOA, the difference btw swap (2 tx: approve + swap) and ERC-20 transfer is 0.14-0.18$.

- With Clave, the difference btw swap (1 tx: approve + swap) and ERC-20 transfer is 0.02$.

Why are you…

61

6:10 PM • Jan 28, 2024

These contracts are open-source and accessible to all Smart Contract wallets in zkSync. If you're a dapp or a wallet looking to integrate BatchCaller into your project, our DMs are open!

https://github.com

clave-contracts/contracts/batch/BatchCaller.sol at master · getclave/clave-contracts

Clave Smart Contracts on zkSync. Contribute to getclave/clave-contracts development by creating an account on GitHub.

Write anything - from your smallest paragraph to your grandest masterpiece - and publish it online or send it as email newsletters directly to your readers.

Your Paragraph publication is blazing-fast, SEO optimized, and combines the best parts of both web2 and web3 to help you create content and grow your community better than ever.

Getting started

What you're looking at right now is the Paragraph editor. We support markdown, callouts, code, and rich media embeds like Twitter and YouTube.

paragraph.xyz

@paragraph_xyz

On paragraph.xyz, all posts are stored on @ArweaveTeam. This means they're immutable, uncensorable, permanent, and composable

paragraph.xyz

Paragraph | all-in-one publishing & newsletter platform

Create, publish and share web3-native blogs & newsletters.

16

7:12 PM • Aug 18, 2022

When you publish a post, you'll have the option of sending it as a newsletter or storing it in the permanent & uncensorable Arweave.

Helpful links

Here's a few helpful pointers to customize your publication & get the most out of Paragraph:

• Theming & customization. Change your publication's font & colors; truly make this space your own.

• Set up a welcome email. This is the email your readers receive when they subscribe to your newsletter.

• Configure your publication's settings. Add links to your homepage, set up a custom domain, configure Google Analytics & more.

Need help or have feedback?

We've put together some documentation here, but if you still have questions you'd like answered we’d love to hear from you.

You can reach us via email at hello@paragraph.xyz or subscribe to our newsletter here. We're also pretty active on Discord.