Ethereum

Binance Smart Chain

Solana

Celo

LIVE

ENDED

ASSIGNED

About Alchemy Pay

Founded in Singapore in 2017, Alchemy Pay is a payment gateway that seamlessly connects crypto with traditional fiat currencies for businesses, developers, and end users. With its On & Off Ramp solution, NFT Checkout, Crypto Card and Crypto Payments, Alchemy Pay supports payments in 173 countries.
The Ramp is a one-stop solution to buy and sell crypto and fiat, easily integrated by platforms and dApps according to requirements. The NFT Checkout enables direct purchases of NFTs using fiat payment methods. The Crypto Card solution empowers businesses and token issuers to provide users with branded virtual and physical cards for instant global spending. ACH is the Alchemy Pay network token on Ethereum and BNB Smart Chain.

Website: https://alchemypay.org

Twitter: https://twitter.com/alchemypay

Telegram: https://t.me/alchemy_official

Discord: https://discord.gg/alchemypay

LinkedIn: https://www.linkedin.com/company/alchemypay

Medium: https://alchemypay.medium.com/

YouTube: https://youtube.com/@AlchemyPay

𝐀𝐥𝐜𝐡𝐞𝐦𝐲 𝐏𝐚𝐲

We’re excited to invite you to our Community AMA session! This is your opportunity to dive deep, voice your thoughts, ask pressing questions, and engage with our vibrant community.

🕹How to Participate:

-Join our AMA session-Leave your valuable comments and questions under the tweet

🤑Rewards:

🟩Top Contributors: We’ll handpick 10 standout comments and reward the contributors with a share of $200 $ACH.

Leave comments now: https://twitter.com/AlchemyPay/status/1704431598618480715

🟥Lucky Dip: We will randomly select 5 participants to share 300 $ACH each to those who finish the tasks.

🔹Tasks:

1️⃣Follow @AlchemyPay & @AlchemyPayNews_ on Twitter

2️⃣Join Discord: https://discord.gg/alchemypay

3️⃣Join Telegram: https://t.me/alchemy_official

4️⃣RT & Likes: https://twitter.com/AlchemyPay/status/1704140889361105148

📢Please drop your entries with:

Twitter handle:

Telegram handle:

Discord handle:

Comment link:

🚨Note: The amount of participants must be over 30!
🗓Set your calendar: Till 13:00 UTC, Sept.28

Come, be a part of this dynamic discussion, and stand a chance to win exciting rewards. We value your input and look forward to your participation!

🏆Join Our Community AMA: Share Your Insights and Win Exclusive Lucky Rewards!🏆

Offchain Labs

If the network name is too long it causes the balances to go out of the box. To fix this, we should display balances under the network dropdown (on mobile only, the layout should remain the same on anything larger than mobile).

- Ensure there is 10px padding between the network dropdown and the token amount input. 
- Left align balances so that they are in line with the network dropdown and the token amount input.

![Screenshot 2023-09-08 at 19 12 56](https://github.com/OffchainLabs/arbitrum-token-bridge/assets/47932951/2b088d91-737d-4211-80c8-51c5a2fb6675)


Show balances under the network name in the Transfer Panel (mobile only)

Optimism

- run `npm init` to create a package.json
- Add the same github action we are using in the optimism superchain tokenlist to publish it to npm (except delete any code that is building or installing node modules since in this case we have neither)
- Add npm secret

Publish superchain registry as a npm package

Ethereum Foundation

## Abstract

Add a mechanism to disable the default import callback when using the native binary.

## Motivation

The native binary defaults to the Host Filesystem Loader, meaning that JSON inputs that are not self-contained can still compile fine. This is a problem for Hardhat because we want to get an error in those cases.

There is a workaround: creating an empty temporary directory and using it with `--base-path`. But having a specific flag like `--no-import-callback` would be much better.

## Specification

Add a `--no-import-callback` to the solc binary that disables any default import callback.

## Backwards Compatibility

This is a new flag so there shouldn't be backwards compatibility issues.

Add a flag to disable the default import callback

### Describe the bug

Across the website, we are using the primary outline variant of the button instead of the secondary variant of the button.

E.g., in the design system, we use a secondary button (black outline) for the secondary button.

<img width="1269" alt="Screenshot 2023-07-20 at 10 00 54" src="https://github.com/ethereum/ethereum-org-website/assets/62268199/c0ab6728-232c-4b52-a826-1d8aee743f05">

Here is the difference:

<img width="345" alt="Screenshot 2023-07-20 at 09 57 44 1" src="https://github.com/ethereum/ethereum-org-website/assets/62268199/aab0bc09-3f24-482a-bb0b-9a84f23ff472">

However, on production, we use the primary 'outline' variant ([see Layer 2 page](https://ethereum.org/en/layer-2/)) also everywhere.

<img width="1435" alt="Screenshot 2023-07-20 at 10 02 49" src="https://github.com/ethereum/ethereum-org-website/assets/62268199/569ce763-486f-4553-b631-f2377a0ed2e8">

We accidentally do the same on the homepage:

<img width="1494" alt="Screenshot 2023-07-20 at 10 08 33" src="https://github.com/ethereum/ethereum-org-website/assets/62268199/d72e0fcd-6341-4107-90f7-e537c3bd67ac">


And on the docs:

<img width="1080" alt="Screenshot 2023-07-20 at 10 08 40" src="https://github.com/ethereum/ethereum-org-website/assets/62268199/bce9dae3-f1cf-49f9-bfcc-ca14cab24d6e">


### To reproduce

1. Go to 'https://ethereum.org/en/layer-2/'
1. See error


### Expected behavior

I'm currently unsure about the correct button designs. It appears that around 90% of our buttons should feature black outlines (secondary outline).

To avoid inconsistencies, I suggest we standardize all outline button variants to secondary outline buttons. We can revise this as needed once we establish clearer design rules or exceptions.

Secondary buttons styling does not correctly reflect design system

Uniswap

### Component

_No response_

### Describe the suggested feature and problem it solves.

Needing access to node-js is causing some dev-x issues, and instead of patching those, it seems like somewhat low effort to just get all our tests migrated and delete hardhat.

merged migrations:

- [x] sqrtPriceMath https://github.com/Uniswap/v4-core/pull/317
- [x] tickMath https://github.com/Uniswap/v4-core/pull/306
- [x] FullMath (https://github.com/Uniswap/v4-core/pull/314))
- [x] TickBitmap https://github.com/Uniswap/v4-core/pull/320
- [ ] SwapMath https://github.com/Uniswap/v4-core/pull/323
- [ ] PoolManager

### Describe the desired implementation.

_No response_

### Describe alternatives.

_No response_

### Additional context.

_No response_

Migrate All tests to Foundry

*To make our work more accessible and to foster more community collaboration, our team publishes an overview of our quarterly roadmap goals. See last quarter's roadmap here: #10057.*

**Greetings fellow Ethereans!**

[Our vision with ethereum.org](https://ethereum.org/en/about/) continues to be to create the best portal for Ethereum's growing community. We’re an educational resource focused on helping onboard millions of visitors to Ethereum each month. Here's a look at our major Q3 initiatives to advance this vision.

Quick point of clarification: ***this is the roadmap for [ethereum.org](http://ethereum.org/) the website, not Ethereum the protocol***. If you’re looking for the Ethereum roadmap, check out information on [upcoming network upgrades](https://ethereum.org/en/roadmap/) and learn more about [Ethereum governance](https://ethereum.org/en/governance/).

With that out of the way, let’s dive in.

# Q3 roadmap

## 🥱 tl;dr?

Here's a high-level overview of what we're working on. Read on for more details 👀

![image](https://github.com/ethereum/ethereum-org-website/assets/62268199/be476f2a-1515-461a-9f43-4ae2094fb1da)

## 🌍 Translatathon

We're excited to launch our first-ever Translatathon in Q3—a contest aimed at translating ethereum.org's content and competing for prizes 🎁

The main goals of the Translatathon are to incentivize translations into some of the less active languages, raise awareness of the Translation program, onboard new contributors to the program, and reward some of the top contributors.

Just like a traditional hackathon, our Translatathon will have an application phase, team formation, support calls & workshops, a dedicated translation week, and a period for evaluation.

_[Join the Discord to stay up-to-date](http://ethereum.org/discord)_ 🌍

## 👋 Showing translators as contributors

Thousands of people have helped translate ethereum.org into over 50 languages. However, unlike GitHub contributors, whose contributions [show directly on the pages they contribute to](https://ethereum.org/en/developers/docs/), translator contributions are hidden away [on leaderboards](https://ethereum.org/en/contributing/translation-program/acknowledgements/) or [other translator specific pages](https://ethereum.org/en/contributing/translation-program/contributors/).

To acknowledge those contributors making ethereum.org content more accessible to non-English speakers, we will begin to highlight translators on the docs and tutorials pages they’ve helped translate.

_Want to be on one of these pages? [Join the translation program](https://ethereum.org/contributing/translation-program/)._

## 💁‍♀️ Community onboarding

Ethereum.org is made possible by thousands of enthusiastic contributors. In Q3, we'll streamline our community onboarding process, making it as effortless, engaging, and enjoyable as possible. We're currently researching potential enhancements that will make a significant impact.

Look forward to improvements across our Discord and other community platforms—it's time for a glow-up! 💅

_If you have any insights or suggestions on our onboarding materials and process, we'd love to hear them! Please share your feedback [on Discord](http://ethereum.org/discord) 🙏_

## 🤿 Design system: new hub hero, diagrams, and expandable cards

Our Design System is an ongoing initiative started in 2022. As we move forward, expect comprehensive breakdowns of our plans for each quarter.

In Q3, we'll focus on:

- Designing a new hero component for hub pages, integrating our new illustrations 👀
- Redesigning our expandable cards and FAQ components for a more user-friendly experience
- Establishing a unified design language for diagrams and infographics

_We welcome your thoughts – we'll share our progress and seek feedback in our design channel on Discord. Want to get involved? [Join us on Discord!](http://ethereum.org/discord)_

## 🖍️ Illustrations

The illustrations on ethereum.org, particularly the homepage hero image, have become a distinctive part of Ethereum's culture.

In Q3, we're working with Liam Cobb, the illustrator behind this image, to create a new collection of new illustrations for our hub pages. We're in the early stages, but Liam's initial ideas and sketches have us verrrrrrry excited 😁

_Want to see our new illustrations before everyone else? [Join our Discord](http://ethereum.org/discord)._

## 📜 Solidity lang

Solidity lang’s website(s) are getting a refresh! We begun work on this in Q2. In Q3, we’ll finalise the details and ship redesigns websites of the Solidity portal, blog, and documentation. These changes will improve the overall user experience and give the websites a modern aesthethic 💅

_Follow [Solidity Lang’s Twitter](https://twitter.com/solidity_lang) to see it drop 👀_

## 🤐 Swag boxes

This one is a secret, so can’t say much. Don’t tell @nloureiro I posted this 😆

## **🕹️ Design Interactivity**

In Q2, we evaluated how interactivity could improve our site. After identifying pages that could benefit from increased interactivity, we researched different design solutions and selected the best based on user needs and feedback.

In Q3, we're planning to design the flow and UI for a new interactive component, with the goal of adding a bit more fun and engagement to certain ethereum.org pages.

## **🕹️ Implement Interactivity**

As a stretch goal, we're aiming to also launch the new interactive component(s) in Q3. We'll likely be asking for community members to help test it as we build it out.

_If you're interested in helping us test, [join us on Discord](http://ethereum.org/discord)._

## 📊 Content auditing

In the rapidly changing Ethereum ecosystem, the relevance and accuracy of our content is crucial. Ethereum.org hosts ~300 English pages, and with the help of our community, we continuously strive to keep our content updated. As part of this 'Content Auditing' epic, we will actively review and refresh the 30 most visited pages on ethereum.org, making sure our most critical content remains comprehensive, up-to-date, and user-focused.

## 🕊️ Migrate to NextJS

In Q2, we investigated changing the web framework that ethereum.org is built on: the current setup was becoming increasingly unsuitable for both the experience of open-source developers and the number of pages ethereum.org has across all of the languages it supports.

In Q3, we'll begin to implement those changes in our codebase. Starting with an MVP and (hopefully) migrating the entire website from Gatsby to NextJS by the end of Q3 🎉

_Follow along with the progress in [the ethereum-org-next GitHub repo](https://github.com/ethereum/ethereum-org-next) 👩‍💻_

## 🔍 Glossary Tooltip

Ethereum's technical language can be a hurdle for beginners, often leading users on a multiple-page hunt to understand a single term.

This is another spillover from Q2. In Q3, we'll develop a glossary tooltip feature to allow users to access term definitions directly on the page they're reading, simplifying the learning process around complex topics.

_Interested in contributing to this feature? [Join the discussion in the #website-code channel on our Discord community.](http://ethereum.org/discord)_

## 📹 Research video dubbing

Ethereum.org links to excellent educational videos on many Web3-related topics, but until now, they've only been available in English. Technology advancements have simplified video dubbing, opening doors for us to bring these valuable resources to non-English speaking audiences.

In Q3, we'll research various tools and establish a potential process to translate video content into multiple languages.

_Have thoughts or insights on video dubbing? We'd love to hear from you. [Join the conversation in our translations channel on Discord](http://ethereum.org/discord)._

## ⛽️ Network fees page

Our developer docs' gas page gets **a lot** of traffic, but it's not beginner-friendly and doesn't answer many people's key questions: Why do I need to pay gas? How can I reduce transaction fees?

In Q3, we'll ship a network fees page tailored to beginners that gives everyone the knowledge they need to use Ethereum effectively.

_We'll share early drafts of this new page in [the #content channel on our Discord](http://ethereum.org/discord). Your feedback can help us ensure we're providing clear, useful information. [Join us there!](http://ethereum.org/discord)_

# How does that sound?

We always appreciate feedback on our roadmap - if there's something you think we should work on, please let us know! We welcome ideas and PRs from anyone in the community.

Get involved: [Learn more about contributing](https://ethereum.org/en/contributing/), [hit us up on Twitter](https://twitter.com/ethdotorg), or join the community discussions in [our Discord](https://discord.gg/CetY6Y4).

Q3 2023 ethereum.org product roadmap

Minor Mobile UI alignment issue: cropped text on tx history panel

Freezer table can support both tail and head deletion. Tail deletion is a bit special, it
will hide the removed items and keep them in the file. The file will only be dropped if
all elements in this file are hidden. (we call it as lazy-deletion).

However, the reported size doesn't respect the tail deletion. The hidden items are
still counted for overall table size. Although these elements are indeed live in the 
file system, but we might need another API to report the size of live elements to
avoid some confusions.

core/rawdb/freezer: table size is inaccurate if elements were removed from the tail

### Project
Liquidity Staking on Optimism (Lido & Rocket Pool)
### Description
Deep dives to explore the how OP rewards are distributed to incentivise liquidity staking on Optimism, how rewards are allocated across dapps/liquidity pools and their performances, OP and LDO spend, how liquidity retention is looking like in the absence of incentives, and any other recommendations you have

### Find out more
Lido: https://www.notion.so/oplabs/Lido-51c8f1e4a6f24bcd88ca84bba9fc8dfc?pvs=4
Rocketpool: https://www.notion.so/oplabs/Rocket-Pool-260afe3571434634a680d21e006839a7?pvs=4

[Request for Contributions] OP Rewards: Liquidity Staking on Optimism (Lido & Rocket Pool)

### Project
Yearn
### Description
Deep-dive on Yearn's Optimism yVaults boosted yields which distribute 25K OP for 40 weeks. Boost currently is live on USDC, DAI, USDT, and WETH vaults. How is Yearn's program performing as compared to other similar incentive programs? How long will those TVL be kept on Optimism? Anything else you want to suggest or recommend for liquidity incentives?
There's also Yearn Coinbase Quest live at the same time, can you help differentiate that? 
### Find out more
https://www.notion.so/oplabs/Yearn-3274e9ac94654fa7a84174c4cd810e2a?pvs=4

[Request for Contributions] OP Rewards: Yearn Deep-dives

### Project
Rabbithole
### Description
Protocol deep-dive for Rabbithole to measure the impact of its Optimism Weekly Quests, areas to explore include but not limited to how quests are onboarding users/wallets to Optimism, does amount of OP reward correlate with retention, do some quests perform better than others, what else can we learn to help Rabbithole team to design future quests on Optimism
### Find out more
https://www.notion.so/oplabs/Rabbit-Hole-d1074aa502fd415290a6cacf81fe9820?pvs=4

[Request for Contributions] OP Rewards: Rabbithole Deep-dives

### Components

Singleton, 1155 Balances

### Describe the suggested feature and problem it solves.

Currently fees accrued to the protocol and to hooks are stored in mappings. However the ERC1155 implementation of the PoolManager should allow us to actually accrue these as 1155 minting instead of having separate mappings.

### Describe the desired implementation.

Remove the 2 mappings `protocolFeesAccrued` and `hookFeesAccrued` and instead mint 1155s, similarly to in `PoolManager.mint`

### Describe alternatives.

_No response_

### Additional context.

_No response_

Consider fee accrual as 1155 balance

### Components

Lock and Call,  1155 Balances

### Describe the suggested feature and problem it solves.

To burn an 1155 in exchange for pool balance, the onERC1155Received hook burns and accounts the tokens. However this function doesnt have a lock on it. I _think_ the accountDelta function should revert if you try to transfer 1155s into the manager outside of a lock (as the lockedBy.length should be 0). However we should test this to make sure theres nothing weird you can do by calling onERC1155Received outside of a lock.

Secondly what if an _unsafe_ transfer is done, so the onERC1155Received hook isnt called? Does the pool get a balance that then cannot be burnt?

### Describe the desired implementation.

Tests for the above edgecases, and any others we can think of, to check we've covered any unplanned behaviour.

### Describe alternatives.

_No response_

### Additional context.

_No response_

Test 1155 burning outside lock

### What is wrong?

A number of functions defined in [std::evm](https://github.com/ethereum/fe/blob/master/crates/library/std/src/evm.fe) take offsets and lengths for regions of memory and calldata. These should take [buffer](https://github.com/ethereum/fe/blob/master/crates/library/std/src/buf.fe) types instead.

### How can it be fixed

- implement `CalldataBuffer`, `CalldataBufferReader`
- update `revert_mem`, `return_mem`, `call_data_copy`, `code_copy`, `ext_code_copy`, `keccak256_mem`, `create`, `create2`, `call`, and `log` 

run `$ cargo test std_lib` to check changes made to `crates/library`

`std::evm` functions should take buffer types

https://github.com/OffchainLabs/arbitrum-token-bridge/blob/90980552f2dbea03ba6421d014fa3593e52e3a1c/packages/arb-token-bridge-ui/src/components/common/NetworkSelectionContainer.tsx#L51-L78

Convert network selection buttons to button element

Add a LTO build to CI. We can check the performance of Release vs Release+LTO builds but previously difference where neglectable.
However, LTO build can reveal some C++ bugs.

In CMake IPO can be enabled with [`INTERPROCEDURAL_OPTIMIZATION`](https://cmake.org/cmake/help/latest/prop_tgt/INTERPROCEDURAL_OPTIMIZATION.html) property. The Hunter controlled dependencies should be build with IPO enabled too therefore a CMake toolchain file must be used.

CI: Add a LTO/IPO build

The execution-spec-tests publish _compiled_ JSON tests as a GitHub release at https://github.com/ethereum/execution-spec-tests/releases/latest.

- [ ] Get the latest release and locally run the tests with `evmone-statetest` tool. Report any problems or failed tests.
- [ ] Extend existing state-tests CI job to also download and run these tests. CI config: https://github.com/ethereum/evmone/blob/v0.10.0/circle.yml#L432-L449.

Check execution-spec-tests

Update `tailwind-merge`

Running and matching on a specific portal hive test helps us with local development and debugging.

Example implementation in GO: https://github.com/ethereum/portal-hive/blob/main/hivesim/testmatch.go


Implement test matching pattern in hivesim-rs

### What is wrong?

The new parser (v2 branch) only supports augmented-assignments where the LHS is an identifier. Eg `x += 1` is supported, but `x.y += 1` isn't.

### How can it be fixed

Good opportunity for someone to become familiar with the new parser, I guess.

v2 parser AugAssign stmt doesn't allow `x[0] += 1`

The [op_token_distributions_optimism.transfer_mapping](https://dune.com/queries/2370566) abstraction table in Dune is generated by first identifying distribution recipient project wallets, then pulling all OP transfer transactions from those wallets.

If you notice a wallet that is not being picked up, you can add it in the [Dune spellbook here](https://github.com/duneanalytics/spellbook/blob/main/models/op/token_distributions/optimism/op_token_distributions_optimism_project_wallets.sql).
- Add the wallet to the `intermediate_wallets` if the wallet represents an internal team wallet (i.e. team multisig).
- Add the wallet to the `distributor_wallets` if the wallet represents a token distribution wallet (i.e. airdrop distributior, liquidity mining gauge).

[Request for Contributions] OP Rewards: Project Wallet Mapping

There currently is no onchain identification of what contracts belong to which apps. To get around this, we have a system in Dune Spellbook, where we can map contract deployer addresses to project names, and automatically associate any contracts they create.

The output of this structure - All known contract <> project mappings is in [this dashboard](https://dune.com/optimismfnd/optimism-contract-lessgreater-project-mappings).

This requires manual upkeep. If you notice any missing mappings, you can contribute by:
- Adding a deployer address (address who created the contract) to project name in the [Dune spellbook here](https://github.com/duneanalytics/spellbook/blob/main/models/contracts/optimism/contracts_optimism_contract_creator_address_list.sql). *Note: Since we'll associate of their contracts to a project, check that this mapping appears to be deterministic.*
- Add a one-off label to the contract in the [Dune spellbook here](https://github.com/duneanalytics/spellbook/blob/main/models/contracts/optimism/contracts_optimism_contract_overrides.sql). This is useful for when it's unclear if the deployer address belongs to the project, or other edge cases.

[Request for Contribution] OP Contract <> Project Mapping

The liquidity/TVL tracking for the OP rewards program tracker is controlled by [this input file](https://github.com/ethereum-optimism/op-analytics/blob/main/op_rewards_tracking/inputs/op_incentive_protocols.csv) in `op_rewards_tracking/inputs`.

As new programs launch / end / modify, this csv needs to be updated to reflect that. This includes the slug (if Defillama), program name (for joining - if there's a relevant sub-program), the start date & end date, op source, data source, contracts (if via subgraphs), and other fields.

If information needs to be updated, you can comment on this issue and/or make a PR to propose updates.

[Request for Contribution] OP Rewards - Liquidity Configuration

Notice a program with information that needs to be updated in the [OP Rewards Program Tracker](https://oplabs.notion.site/26d856d5ad7c4fda919c62e839cf6051?v=4e38174b2e994129b51dcfa127965aa4)? Please report it here:

**Program Name:** *This Should match what's shown on the Tracker*

**Missing/Updated Information:** *Please share the information that needs to be updated & provide links for proof if possible*

[Request for Contribution] OP Rewards Program Tracking Update

to accelerate the docker build this packages can be prebuilt and installled from ppa
boost version 1.79

compile libboost filesystem and system packages to ubuntu 20. ppas

Uniswap is an automated liquidity provider for swapping, earning, and building on the leading decentralized crypto trading protocol. Uniswap is governed by its community and enables developers to build third-party solutions on top of the protocol. 

Use TEST_RECIPIENT as taker in Element test

Add ERC20->NFT tests for SeaportV1.4

Add Element ERC1155 support

Currently `yarn run tsc` catch errors from `node_modules` folder:
```
❯ yarn run tsc
yarn run v1.22.19
$ /home/.../.bin/tsc
node_modules/@wagmi/core/dist/contracts-3880ee54.d.ts:144:91 - error TS1005: '?' expected.

144 }, TOptions extends Options = DefaultOptions> = TFunction['inputs'] extends infer TInputs extends readonly AbiParameter[] ? Or<IsNever<TInputs>, NotEqual<TAbi, Abi>> extends true ? {
                                                                                              ~~~~~~~

node_modules/@wagmi/core/dist/contracts-3880ee54.d.ts:144:99 - error TS1005: ':' expected.

144 }, TOptions extends Options = DefaultOptions> = TFunction['inputs'] extends infer TInputs extends readonly AbiParameter[] ? Or<IsNever<TInputs>, NotEqual<TAbi, Abi>> extends true ? {
                                                                                                      ~~~~~~~~
```

It should only catch errors from our own files

Contribute to top web3 projects

Learn, earn and showcase by contributing to bounties on open source issues to help ecosystems to grow!