axic

/*
 * WARNING: Proof of concept. Do not use in production. No warranty.
 *
 * Safe transfer workaround for not fully ERC20 compatible tokens.
 * Well, ERC20 had a lot of revision, who I am to say something is not compatible :)
 *
 * Read the following for more explanation: https://github.com/ethereum/solidity/issues/4116
 *
 * In short:
 *   The final ERC20 standard (IIRC) requires the transfer function to return a boolean. Some tokens do not return anything

axic

//
// The new assembly support in Solidity makes writing helpers easy.
// Many have complained how complex it is to use `ecrecover`, especially in conjunction
// with the `eth_sign` RPC call. Here is a helper, which makes that a matter of a single call.
//
// Sample input parameters:
// (with v=0)
// "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad",
// "0xaca7da997ad177f040240cdccf6905b71ab16b74434388c3a72f34fd25d6439346b2bac274ff29b48b3ea6e2d04c1336eaceafda3c53ab483fc3ff12fac3ebf200",
// "0x0e5cb767cce09a7f3ca594df118aa519be5e2b5a"

axic

EVM Assembly Language

Motivation

The goal is to specify a syntax for an EVM assembly language, which can be used across various tools.

The format should be human readable, map EVM as closely as possible, allow for comments and refrain from complex syntax.

Specification

axic

LLVM on the high level could be separated into:

• 1. Core (operations which work on the LLVM IR AST)
• 2. Optimisers
• 3. Backends/targets - these generate the instructions for a given CPU (i.e. x86, ARM, WebAssembly, etc.)

There are many projects creating frontends for LLVM, which are actual compilers outputting LLVM IR.

Some of these include:

• clang (C and C++)
• llgo (Go)

axic

/*
 * STATICCALL Proxy
 *
 * It expects the input:
 * 256 bit - address
 * 256 bit - gas
 * 256 bit - value
 * n   bit - calldata to be proxied
 * 
 * And returns the output:

axic

//
// Implementation of the standard account contract as per EIP101 (Cryptocurrency
// abstraction). See: https://github.com/ethereum/EIPs/issues/28
//
// Written by Alex Beregszaszi, use under the MIT license.
//

contract StandardAccount {
    uint256 nextSequence = 1;

axic

pragma solidity ^0.4.13;

library BytesTool {
    function memcopy(bytes src, uint srcoffset, bytes dst, uint dstoffset, uint len) pure internal {
        assembly {
            src := add(src, add(32, srcoffset))
            dst := add(dst, add(32, dstoffset))
            
            // copy 32 bytes at once
            for

axic

ewasm “WRC20” token contract coding challenge

This document describes a simple contract in pseudocode and gives a couple of test cases for it.

The challenge is designed to be fairly easy to implement in a language of choice, compiled to wasm and interacted with. It is loosely based on the ERC20 token standard, named "WRC20", where the W stands for WebAssembly.

External interface

The contract has two features:

axic

// ReedemableNFT, where a curator can issue a redeemable cheque for minting a given token.
//
// The message to be signed is an EIP-712 compatible structured data:
//   struct RedeemableNFT {
//       address recipient;
//       uint256 tokenId;
//   }
//
// This message can then signed by the curator and given to the user who submits it.
// The validity of the signature is checked according to EIP-1271 if the signer is a contract,

axic

//
// Big number library in Solidity for the purpose of implementing modexp.
//
// Should have a similar API to https://github.com/ethereum/EIPs/issues/101
//
// Internally bignumbers are represented as an uint array of 128 bit values.
//
// NOTE: it assumes usage with "small" (<256bit) exponents (such as in RSA)
//