Development resources at your finger tips
Build with the coolest Web3 projects
Recurring funding for Open Source
Ethical ads to power Open Source
Learn about Web3 & earn rewards
Show appreciation for each other
Meet fellow developers, designers, futurists and more. Collaborate and BUIDL awesome projects together.
Discover great web3 organizations, work on meaningful projects and build relationships with like minded people. Browse Tribes
Meet the top hunters and contributors from our community.
KERNEL is an 8-week, invite-only program for top tech talent looking to build relationships, products, and companies in blockchain and Web 3. 100 tal…
Heyo Gitcoiners! With an entire city of hackers, coders and blockchain innovators relocated on our platform, the atmosphere is just buzzing with crea…
Type in [[ 2- term.length]] more characters to get results
[[ result.title ]]
[[ result.description | truncate(70) ]]
No matches found
Gitcoin is GDPR complaint. Learn more in
Gitcoin's Terms & Conditions.
Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
Due to Solidity stack size limitations, the current order hashing implementation ([here](https://github.com/ProjectWyvern/wyvern-ethereum/blob/master/contracts/exchange/ExchangeCore.sol#L235)) must hash orders in two parts. This is a waste of gas. Instead, manually "tightly pack" the Order struct into bytes following the Solidity tight-packing convention (see [here](http://solidity.readthedocs.io/en/develop/abi-spec.html#abi-packed-mode)), which should result in one fewer calls to the `keccak256` builtin. Other ways of getting around Solidity's stack size limitation may be candidate solutions as long as they still decrease gas costs.
May be rendered easier by [this Solidity PR](https://github.com/ethereum/solidity/pull/2980), but I do not know what the timetable for that is.