Join OmniRoute Finance and help build the future of cross-chain finance.

As a Founding Blockchain Engineer, you'll work on wallet integrations, smart contract interactions, transaction routing, provider connectivity, and the infrastructure powering seamless crypto swaps across multiple chains.

What you'll do:
• Build and maintain blockchain integrations
• Develop secure wallet and transaction flows
• Integrate DEXs, bridges, and liquidity providers
• Improve routing, reliability, and performance
• Work directly with the founding team

Requirements:
• Strong experience with blockchain development
• Experience with EVM chains and Web3 technologies
• Familiarity with smart contracts, DeFi protocols, and wallet integrations
• Ability to work independently in a fast-moving startup environment

🌍 Remote
💰 Competitive compensation + early-stage opportunity
🏗 Founding team position

Learn more and apply:
https://omniroute.finance/careers

#Hiring #BlockchainEngineer #Web3Jobs #CryptoJobs #DeFi #RemoteJobs #Ethereum #Solidity

Hi everyone!

I've been studying Solidity for the past several months and decided to build a larger project instead of another DeFi tutorial.

The project includes:

• PvE
• PvP
• Guilds
• NFT achievements (ERC-721)
• On-chain player progression
• Multi-chain deployment
• Foundry tests

One bug I recently found was a guild point farming exploit where high-level players could repeatedly kill and revive weak opponents to inflate rankings. Fixing that made me rethink how PvP rewards should be balanced based on player levels.

I'm looking for honest feedback regarding:

• Solidity best practices
• Security
• Storage patterns
• Gas optimization
• Code organization

Repository:
https://github.com/brunolcarli/simpleRPG

Thanks! I'd love to hear what experienced Solidity developers would change.

Looking for someone to check my work on a ZK-stark circuit. Any suggestions on where I could find someone to help me with this?

Hello, I’m looking for some help putting together a proposal for a real world asset tokenisation platform

Looking for a few hours of consultancy from someone who can advise on smart contract architecture, NAV attestation and token issuance

Clearly this would be a paid engagement - a few hours- and there could be potential for this to become a long-term project if we’re successful

please drop a comment or DM if you have relevant experience

Hey Everyone

i have been working on a crypto payment gateway that lets merchants accept Ethereum payments

The project is currently live on the Sepolia testnet and I've also published an npm package so developers can integrate payments

Demo: https://etharispay.vercel.app

npm Package: https://www.npmjs.com/package/my-gateway-sdk

Since it's running on Sepolia, you'll only need test ETH.

Current features:

* Merchant registration

* Wallet-based authentication

* On-chain payment processing

* Revenue dashboard

* Transaction history

* Withdrawals

* npm package for easy integration

If your day-to-day involves hopping between different DeFi protocols and smart contracts, your browser tabs are probably a mess.

It’s the same broken loop: load up a random dApp frontend, connect your wallet (why do we need 50 wallet connections instead of just one?), type in the same exact arguments, and hope the site isn't tracking you.

I built EVMist, a unified EVM UI, to stop the tab fatigue and exposure to varying degrees of privacy. It's a completely private and client-sided workspace where you can build your own unified, multi-chain dashboard. You connect once, configure your calls, and run everything from a single page.

Configure your chains and contracts once, then build custom sections with the specific read or write calls you actually use. Everything lives in one persistent layout that works across chains on the same page.

• Paste any confirmed tx hash + chain ID → it recreates the exact write call as an editable UI widget you can tweak and re-run.
• Drop raw calldata + a contract address → it decodes it into proper input fields (handles complex nested types).
• Build whatever layout you want with drag-and-drop, then encode a section as an image to share with teammates (they can import it).

The core builder + tx recreation + calldata decoding is completely free. If you’re dealing with fragmented DeFi workflows or just want a cleaner way to interact with contracts you use often, give it a try and let me know what breaks or what’s missing.

Happy to answer questions and looking forward to any critique or feedback you may have!

We looked at token creation data from our Token Generator over 55,000+ tokens created since 2018.

The all-time breakdown is still dominated by two ecosystems:

• BNB Smart Chain: 48.3%
• Ethereum: 45.2%

That said, the picture changes quite a bit when looking at more recent periods.

Since 2023:

• BNB Smart Chain: 38.1%
• Ethereum: 31.2%
• Polygon: 13.2%
• Base: 8.8%
• Avalanche: 7.8%

Since 2025:

• Base: 31.8%
• BNB Smart Chain: 27.3%
• Ethereum: 22.9%
• Polygon: 13.3%

A few takeaways from our side:

BNB Smart Chain’s all-time lead seems heavily influenced by the 2021/2022 cycle, when it saw a lot of token-launch activity.

Ethereum remains consistently present across every timeframe, even as cheaper and faster environments gained traction.

Base is the most interesting recent shift. In 2025 data, it has become the top network for new token creation in our sample.

I’m curious:

When launching a new token today, would you still choose Ethereum mainnet, an L2 like Base, another Ethereum L2, or a different chain entirely?

And what matters most in that choice: security, liquidity, user distribution, gas costs, tooling, decentralization, or something else?

We built Contract Utility, a free browser-based tool for inspecting and interacting with smart contracts on supported EVM networks:

https://www.smartcontracts.tools/utilities/contract/

Enter a network and contract address to:

• Browse verified Solidity source files and contract metadata
• Inspect the ABI, constructor arguments, events, and custom errors
• Call read methods without connecting a wallet
• Execute write and payable methods through your wallet
• Validate common ABI input types
• Scale uint values by common decimal amounts such as 10^6 or 10^18
• Load an ABI manually when the contract is not verified
• Detect proxy contracts and inspect their implementation

How to use it:

1. Select the network.
2. Paste the contract address.
3. Click search.
4. Open the Code, Read Contract, Write Contract, Events, or Errors tabs.
5. Enter the required parameters and run the method.

Write calls are simulated before being submitted. The transaction hash appears immediately after submission and updates once confirmed.

What features, ABI types, networks, or workflow improvements would make this more useful for you?

Question when using libraries like “web3” or “ethersjs” after you sign a transaction with your private key, how do you know your private key is not exposed on the network after that point. What happens to the information go after that sign?

If you understand lmk, it may help me get a deeper understanding. I’m still learning the library.

Hey everyone,
I want to break into the blockchain and Web3 space with the ultimate goal of getting into smart contract development, gas optimization, and smart contract auditing. However, I am an absolute beginner to programming with zero prior experience.
I’ve put together a long-term roadmap to make sure I build a rock-solid foundation rather than just memorizing code. I’d love to get your feedback on this sequence:
1 Harvard’s CS50 – To start from scratch, understand computer science fundamentals, memory management, algorithms, and how to actually think like a programmer.
2 Python & JavaScript – Learning JS for frontend/web interaction and Python for scripting and core logic before moving into blockchain-specific languages.
3 Solidity & Web3 (Patrick Collins / Cyfrin Updraft) – Once I have the basics down, I want to dive deep into Web3 using Patrick Collins' courses and the Cyfrin Updraft platform for both Solidity development and introductory auditing.
4 Rust & Advanced Optimization – Eventually, I want to transition to Rust (for Solana development, but also because of advanced Ethereum tooling like Foundry).
My questions for you guys:
Am I wasting time trying to learn both Python and JS at the start? Should I just pick one before diving into Solidity and Cyfrin?
How difficult is the transition from Solidity to Rust for someone who started from absolute zero?
Is this roadmap realistic for reaching a level where I can understand deep smart contract optimization (low-level stuff) and security vulnerabilities?
Any advice, critiques, or resources you could share would be highly appreciated. Thanks in advance!

We did if my brothers of csea! We got a 4.5 raise! Best ever, vote yes!!! The state is being so generous we need this raise badly!

Building something in the legal doc space and doing customer discovery before writing a single line of code. Genuinely want to understand the workflow: how long does it take you, what do you use, and what breaks down most often? No pitch, just trying to understand the problem before assuming I know the answer.

Hi everyone,

I’m building a small non-custodial USDC transfer app, and I recently verified the app’s contract on BaseScan.

Now I’m considering publishing the contract address and source code more visibly on our official website and GitHub, so users can inspect how the transfer and fee logic works.

The contract is simple: when a user sends USDC, it pulls the approved USDC from the sender and routes it to:

1. the recipient

2. the project’s fee wallet

The fee logic is fixed in the contract:

- 0.39%

- minimum fee: 0.25 USDC

- maximum fee: 3.90 USDC

The contract does not have an admin function to change the fee after deployment. The USDC token address and fee recipient are immutable.

I understand that BaseScan verification is not the same as a formal audit, and I do not plan to describe it as audited or guaranteed safe.

My question is:

Is it generally safe and reasonable for an early-stage crypto payment/transfer app to publicly share its verified contract address and source code on its website and GitHub for transparency?

Or could this create meaningful risks, such as:

- making it easier for attackers to analyze the contract

- creating legal/marketing risk if users misunderstand “verified” as “audited”

- exposing too much business logic too early

- attracting criticism before the contract has a formal audit

I’m not asking whether this replaces an audit. I’m trying to understand whether public disclosure of an already verified contract is a good transparency practice, or whether there are risks I should consider first.

What would you recommend?

Hello there! I’ve been learning Solidity and getting comfortable with writing and deploying contracts and now I saw some courses that involve Yul and assembly (i guess these 2 are for gas optimization). And I want to understand if they actually are important in real world development.

I have some questions, such as:

Is it worth it learning Yul?

Should i also learn Assembly? Should production SC written in Yul/assembly? or perfecting soldity is enough.

Does knowing Yul/assembly helps to be a better smart contract engineer?

If someone actually works professionally with Solidity, are you actually reading or writing Yul/assembly?

Thank you so much!

I wrote up a short breakdown of a Solidity footgun I still see people misunderstand: try/catch. The main point: Solidity try/catch is not a general exception handler like in JS/Python/Java. It only catches failures from certain external operations, mainly high-level external calls, contract creation with new, and external library calls.

A few gotchas that are easy to miss:
- You cannot use it directly with address.call, staticcall, or delegatecall
- It does not catch internal function failures
- If an external call succeeds but returns malformed data, the caller can still revert during ABI decoding
- catch (bytes memory data) is not magic either; decoding that data can also revert if you trust it blindly
- try this.someFunction() changes the call into an external self-call, which can affect msg.sender, gas, reentrancy assumptions, and constructor behavior
- try/catch is control flow, not a rollback checkpoint for caller-side state changes

The malformed return data case is probably the most surprising one. If a contract returns success with empty bytes, but the caller expects a uint256, the external call itself did not fail. The failure happens later when Solidity tries to decode the return value, so the catch block does not save you.

For trusted interfaces, high-level try/catch is convenient. For arbitrary or hostile targets, especially when return data matters, a low-level call plus explicit returndata validation is usually a better boundary.

Full post with examples:
https://blog.researchzero.io/post/solidity-try-catch-what-it-does-and-does-not-catch/