Use solidity/javascript highlighting in various EIPs (#2372)

EIPS/eip-1062.md

@@ -36,13 +36,13 @@ When mapping the IPFS base58 string to ENS resolver, first we convert the Base58
 ## Rationale
 To implement the specification, need two methods from ENS public resolver contract, when we want to store IPFS file fingerprint to contract, convert the Base58 string identifier to the hex format and invoke the `setMultihash` method below :
   
-```
+```solidity
 function setMultihash(bytes32 node, bytes hash) public only_owner(node);
 ```
   
 Whenever users need to visit the ENS content, we call the `multihash` method to get the IPFS hex data, transfer to the Base58 format, and return the IPFS resources to use.
   
-```
+```solidity
 function multihash(bytes32 node) public view returns (bytes);
 ```
 
@@ -52,7 +52,7 @@ To implement the way to transfer from base58 to hex format and the reverse one,
 The library link : [https://www.npmjs.com/package/multihashes](https://www.npmjs.com/package/multihashes)  
 To implement the method transfer from IPFS(Base58) to hex format :
   
-```
+```javascript
 import multihash from 'multihashes'
 
 export const toHex = function(ipfsHash) {
@@ -63,7 +63,7 @@ export const toHex = function(ipfsHash) {
   
 To implement the method transfer from hex format to IPFS(Base58) :
   
-```
+```javascript
 import multihash from 'multihashes'
 
 export const toBase58 = function(contentHash) {

EIPS/eip-1132.md

@@ -43,7 +43,7 @@ The intention with this proposal is to enhance the ERC20 standard with token-loc
 I’ve extended the ERC20 interface with the following enhancements:
 
 ### Locking of tokens
-```
+```solidity
 /**
   * @dev Locks a specified amount of tokens against an address,
   *      for a specified reason and time
@@ -55,7 +55,7 @@ function lock(bytes32 _reason, uint256 _amount, uint256 _time) public returns (b
 ```
 
 ### Fetching number of tokens locked under each utility
-```
+```solidity
 /**
   * @dev Returns tokens locked for a specified address for a
   *      specified reason
@@ -67,7 +67,7 @@ function lock(bytes32 _reason, uint256 _amount, uint256 _time) public returns (b
 ```
 
 ### Fetching number of tokens locked under each utility at a future timestamp
-```
+```solidity
 /**
   * @dev Returns tokens locked for a specified address for a
   *      specified reason at a specific time
@@ -80,7 +80,7 @@ function lock(bytes32 _reason, uint256 _amount, uint256 _time) public returns (b
 ```
 
 ### Fetching number of tokens held by an address
-```
+```solidity
 /**
   * @dev @dev Returns total tokens held by an address (locked + transferable)
   * @param _of The address to query the total balance of
@@ -89,7 +89,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
 ```
 
 ### Extending lock period
-```
+```solidity
 /**
   * @dev Extends lock for a specified reason and time
   * @param _reason The reason to lock tokens
@@ -99,7 +99,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
 ```
 
 ### Increasing number of tokens locked
-```
+```solidity
 /**
   * @dev Increase number of tokens locked for a specified reason
   * @param _reason The reason to lock tokens
@@ -108,7 +108,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
   function increaseLockAmount(bytes32 _reason, uint256 _amount) public returns (bool)
 ```
 ### Fetching number of unlockable tokens under each utility
-```
+```solidity
 /**
   * @dev Returns unlockable tokens for a specified address for a specified reason
   * @param _of The address to query the the unlockable token count of
@@ -117,7 +117,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
   function tokensUnlockable(address _of, bytes32 _reason) public view returns (uint256 amount)
  ```    
 ### Fetching number of unlockable tokens
-```
+```solidity
 /**
   * @dev Gets the unlockable tokens of a specified address
   * @param _of The address to query the the unlockable token count of
@@ -125,7 +125,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
   function getUnlockableTokens(address _of) public view returns (uint256 unlockableTokens)
 ```
 ### Unlocking tokens
-```
+```solidity
 /**
   * @dev Unlocks the unlockable tokens of a specified address
   * @param _of Address of user, claiming back unlockable tokens

EIPS/eip-137.md

@@ -53,14 +53,14 @@ Resolving a name in ENS is a two-step process. First, the ENS registry is called
 
 For example, suppose you wish to find the address of the token contract associated with 'beercoin.eth'. First, get the resolver:
 
-```
+```javascript
 var node = namehash("beercoin.eth");
 var resolver = ens.resolver(node);
 ```
 
 Then, ask the resolver for the address for the contract:
 
-```
+```javascript
 var address = resolver.addr(node);
 ```
 
@@ -112,43 +112,43 @@ Implementations should conform to the following test vectors for namehash:
 
 The ENS registry contract exposes the following functions:
 
-```
+```solidity
 function owner(bytes32 node) constant returns (address);
 ```
 
 Returns the owner (registrar) of the specified node.
 
-```
+```solidity
 function resolver(bytes32 node) constant returns (address);
 ```
 
 Returns the resolver for the specified node.
 
-```
+```solidity
 function ttl(bytes32 node) constant returns (uint64);
 ```
 
 Returns the time-to-live (TTL) of the node; that is, the maximum duration for which a node's information may be cached.
 
-```
+```solidity
 function setOwner(bytes32 node, address owner);
 ```
 
 Transfers ownership of a node to another registrar. This function may only be called by the current owner of `node`. A successful call to this function logs the event `Transfer(bytes32 indexed, address)`.
 
-```
+```solidity
 function setSubnodeOwner(bytes32 node, bytes32 label, address owner);
 ```
 
 Creates a new node, `sha3(node, label)` and sets its owner to `owner`, or updates the node with a new owner if it already exists. This function may only be called by the current owner of `node`. A successful call to this function logs the event `NewOwner(bytes32 indexed, bytes32 indexed, address)`.
 
-```
+```solidity
 function setResolver(bytes32 node, address resolver);
 ```
 
 Sets the resolver address for `node`. This function may only be called by the owner of `node`. A successful call to this function logs the event `NewResolver(bytes32 indexed, address)`.
 
-```
+```solidity
 function setTTL(bytes32 node, uint64 ttl);
 ```
 
@@ -159,7 +159,7 @@ Resolvers may implement any subset of the record types specified here. Where a r
 
 Resolvers have one mandatory function:
 
-```
+```solidity
 function supportsInterface(bytes4 interfaceID) constant returns (bool)
 ```
 
@@ -184,7 +184,7 @@ EIPs may define new interfaces to be added to this registry.
 
 Resolvers wishing to support contract address resources must provide the following function:
 
-```
+```solidity
 function addr(bytes32 node) constant returns (address);
 ```
 
@@ -194,12 +194,12 @@ Clients resolving the `addr` record MUST check for a zero return value, and trea
 
 Changes to an address MUST trigger the following event:
 
-```
+```solidity
 event AddrChanged(bytes32 indexed node, address a);
 ```
 # Appendix A: Registry Implementation
 
-```
+```solidity
 contract ENS {
     struct Record {
         address owner;
@@ -261,7 +261,7 @@ contract ENS {
 
 The simplest possible resolver is a contract that acts as its own name resolver by implementing the contract address resource profile:
 
-```
+```solidity
 contract DoSomethingUseful {
     // Other code
 
@@ -285,7 +285,7 @@ Such a contract can be inserted directly into the ENS registry, eliminating the
 
 A basic resolver that implements the contract address profile, and allows only its owner to update records:
 
-```
+```solidity
 contract Resolver {
     event AddrChanged(bytes32 indexed node, address a);
 
@@ -325,7 +325,7 @@ After deploying this contract, use it by updating the ENS registry to reference
 
 Similar to the resolver above, this contract only supports the contract address profile, but uses the ENS registry to determine who should be allowed to update entries:
 
-```
+```solidity
 contract PublicResolver {
     event AddrChanged(bytes32 indexed node, address a);
     event ContentChanged(bytes32 indexed node, bytes32 hash);
@@ -364,7 +364,7 @@ contract PublicResolver {
 
 This registrar allows users to register names at no cost if they are the first to request them.
 
-```
+```solidity
 contract FIFSRegistrar {
     ENS ens;
     bytes32 rootNode;

EIPS/eip-1386.md

@@ -40,7 +40,7 @@ The wine vendors smart contract validates the attestation, checks the payment am
 When the wine vendor shows up to her apartment with the wine, there is no need to prove her age again.
 
 ### Draft interface
-```
+```solidity
 /* each attestation issuer should provide their own verify() for the
  * attestations they issued. There are two reasons for this. First, we
  * need to leave room for new attestation methods other than the

EIPS/eip-1387.md

@@ -21,7 +21,7 @@ Unlike previous attempts, we assume that the attestation is signed and issued of
 This ERC provides an interface and reference implementation for smart contracts that need users to provide an attestation and validate it.
 
 ### Draft implementation
-```
+```solidity
 contract MerkleTreeAttestationInterface {
     struct Attestation
     {

EIPS/eip-1388.md

@@ -21,7 +21,7 @@ Anyone can publish a list of issuers. Only the most trusted and carefully mainta
 This ERC provides a smart contract interface for anyone to manage a list of attestation issuers. A smart contract would explicitly trust a list, and therefore all attestations issued by the issuers on the list.
 
 ### Draft implementation
-  ```
+```solidity
     /* The purpose of this contract is to manage the list of attestation
      * issuer contracts and their capacity to fulfill requirements
      */

EIPS/eip-1450.md

@@ -52,7 +52,7 @@ For compliance reasons, the `ERC-1450` constructor must specify the issuer (the
 ### ERC-20 Extension
 `ERC-20` tokens provide the following functionality:
 
-```
+```solidity
 contract ERC20 {
   function totalSupply() public view returns (uint256);
   function balanceOf(address who) public view returns (uint256);
@@ -67,7 +67,7 @@ contract ERC20 {
 
 `ERC-20` is extended as follows:
 
-```
+```solidity
 /**
  * ERC-1450 is an ERC-20 compatible token that facilitates compliance with one or more of Securities Act Regulations CF, D and A. 
  *

EIPS/eip-1485.md

@@ -132,7 +132,7 @@ FNV Mix Algorithm Analysis for TEthashV1
 You can compile it with simple in terminal.
 No additional library needs, 
 
-```
+```sh
 gcc -o fnvtest fnvcltest.c
 ```
 

EIPS/eip-1491.md

@@ -41,7 +41,7 @@ The BDI software model is an attempt to solve a problem of plans and planning ch
 
 
 #### Main Interface
-```
+```solidity
 pragma solidity ^0.4.25;
 pragma experimental ABIEncoderV2;
 
@@ -327,7 +327,7 @@ interface IERC_HUCAP {
 
 <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
 
-```
+```solidity
 
 interface IERC_HUCAP_TYPES {
 
@@ -359,7 +359,7 @@ interface IERC_HUCAP_TYPES {
 
 <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
 
-```
+```solidity
 pragma solidity ^0.4.25;
 pragma experimental ABIEncoderV2;
 
@@ -451,7 +451,7 @@ interface IERC_HUCAP_KEYSIGNING_EXTENSION {
 ```
 #### Human Capital Accounting Extension Interface
 
-```
+```solidity
 pragma solidity ^0.4.25;
 pragma experimental ABIEncoderV2;
 

EIPS/eip-1504.md

@@ -51,7 +51,7 @@ Below is the specification of Handler interface. In the Handler interface we def
 Developers have to define their business-related functions as well.
 
 
-```
+```solidity
 /// Handler interface.
 /// Handler defines business related functions.
 /// Use the interface to ensure that your external services are always supported.
@@ -105,7 +105,7 @@ Below is the specification of Data contract. There are three parts in the Data c
 - **Resource Data**: all other resources that the contract needs to keep and manage.
 
 
-```
+```solidity
 /// Data Contract
 contract DataContract {
 
@@ -236,7 +236,7 @@ Note:
 - Function status() can be called at any time to show caller status of the upgrader.
 
 
-```
+```solidity
 /// Handler upgrader
 contract Upgrader {
     // Data contract

EIPS/eip-152.md

@@ -202,7 +202,7 @@ For reference, further discussion on this EIP also occurred in the following PRs
 
 Assuming ecRecover precompile is perfectly priced, we executed a set of benchmarks comparing Blake2b F compression function precompile with ecRecover precompile. For benchmarks, we used 3.1 GHz Intel Core i7 64-bit machine.
 
-```
+```sh
 $ sysctl -n machdep.cpu.brand_string
 Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz
 ```

EIPS/eip-1592.md

@@ -105,7 +105,7 @@ To use rules within a token is as easy as having the token inherit from WithRule
 
 Below is a template for a rule.
 
-```
+```solidity
 import "../interface/IRule.sol";
 
 contract TemplateRule is IRule {

EIPS/eip-1616.md

@@ -38,7 +38,7 @@ This EIP proposes a light-weight abstraction layer for a standard account metada
 ## Specification
 <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
 The Attribute Registry interface contains four functions, outlined as follows:
-```
+```solidity
 /**
  * @title EIP-1616 Attribute Registry Standard interface. EIP-165 ID: 0x5f46473f
  */
@@ -53,7 +53,7 @@ interface AttributeRegistryInterface {
 Contracts that comply with the Attribute Registry EIP MUST implement the above interface.
 
 As an additional requirement, the ERC-165 interface MUST be included:
-```
+```solidity
 /**
  * @title EIP-165 interface. EIP-165 ID: 0x01ffc9a7
  */
@@ -73,7 +73,7 @@ The implementation MUST follow the specifications described below.
 The view functions detailed below MUST be implemented.
 
 #### `hasAttribute` function
-```
+```solidity
 function hasAttribute(address account, uint256 attributeTypeID) external view returns (bool)
 ```
 
@@ -86,7 +86,7 @@ _**NOTE**_: This function MUST return two equal values when performing two direc
 
 
 #### `getAttributeValue` function
-```
+```solidity
 function getAttributeValue(address account, uint256 attributeTypeID) external view returns (uint256)
 ```
 
@@ -97,7 +97,7 @@ _**NOTE**_: This function MUST revert if a directly preceding or subsequent func
 _**NOTE**_: This function MUST return two equal values when performing two directly consecutive function calls with identical `account` and `attributeTypeID` parameters, regardless of differences in the caller's address, the transaction origin, or other out-of-band information.
 
 #### `countAttributeTypes` function
-```
+```solidity
 function countAttributeTypes() external view returns (uint256)
 ```
 
@@ -108,7 +108,7 @@ _**NOTE**_: This function MUST return a positive integer value  - i.e. calling t
 _**NOTE**_: This function MUST return a value that encompasses all indexes of attribute type IDs whereby a call to `hasAttribute` on some address with an attribute type ID at the given index would return `true`.
 
 #### `getAttributeTypeID` function
-```
+```solidity
 function getAttributeTypeID(uint256 index) external view returns (uint256)
 ```
 
@@ -136,7 +136,7 @@ Targeted test cases with 100% code coverage can be found at [this repository](ht
 <!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
 The basic implementation that follows can be found at [this repository](https://github.com/0age/AttributeRegistry) (see [here](https://github.com/TPL-protocol/tpl-contracts/blob/master/contracts/BasicJurisdiction.sol#L399) for an example of a more complex implementing contract):
 
-```
+```solidity
 pragma solidity ^0.4.25;
 
 /**

EIPS/eip-1753.md

@@ -165,7 +165,7 @@ Smart contracts can be used to embed regulatory requirements with respect to the
 ## Interface 
 
 ### Solidity Example
-```
+```solidity
 interface EIP1753 {
 	string public name;
 	uint256 public totalSupply;

EIPS/eip-1844.md

@@ -24,7 +24,7 @@ For example, a token contract may not itself provide any kind of 'atomic swap' f
 ## Specification
 A new profile for ENS resolvers is defined, consisting of the following method:
 
-```
+```solidity
 function interfaceImplementer(bytes32 node, bytes4 interfaceID) external view returns (address);
 ```
 

EIPS/eip-1973.md

@@ -68,8 +68,7 @@ A pull system is required to keep the application completely decentralized and t
 
  `tokencontractAddress` : the contract address to which tokens will be minted, default is address(this) 
 
-``` 
+```solidity
-SOLIDITY
 
 pragma solidity ^0.5.2;
 

EIPS/eip-2045.md

@@ -23,7 +23,7 @@ Currently, computational opcode costs are already too close to the minimum unit
 A new gas counter `particlesUsed` is added to the EVM, in addition to the existing gas counter `gasUsed`. The unit 1 gas is equal to 10000 particles (`PARTICLES_PER_GAS`). The `particlesUsed` counter is only increased for opcodes priced in particles (i.e. opcodes that cost less than 1 gas). If increasing `particlesUsed` results in an excess of 1 gas, then 1 gas is added to `gasUsed` (and deducted from `particlesUsed`).
 
 Where the current gas logic looks like this:
-```
+```python
 def vm_execute(ext, msg, code):
     # Initialize stack, memory, program counter, etc
     compustate = Compustate(gas=msg.gas)
@@ -52,7 +52,7 @@ def vm_execute(ext, msg, code):
 ```
 
 The new gas logic using particles might look like this:
-```
+```python
 PARTICLES_PER_GAS = 10000
 
 def vm_execute(ext, msg, code):

EIPS/eip-2157.md

@@ -42,7 +42,7 @@ This pattern of separating data type definitions and storage allows developers t
 
 ERC-1900 defines a `contractAddress` field in the type metadata. For the limited purpose of ERC-1900, this field contains the value of the Ethereum type library in which the type definition exists. For the purpose of this ERC, the `contractAddress` will contain the Etherereum address of a `TypeRootContract`.
 
-```
+```solidity
 contract TypeRootContract {
   address public libraryAddress;
   address public storageAddress;
@@ -66,7 +66,7 @@ We propose a Solidity CRUD pattern, as described in https://medium.com/robhitche
 
 An stub implementation for the TypeStorageContract would look like:
 
-```
+```solidity
 import './TypeALib.sol';
 
 contract TypeAStorage {

EIPS/eip-2255.md

@@ -79,7 +79,7 @@ const response = await provider.send({
 ```
 Would return a value something like this:
 
-```
+```json
 [
   {
     invoker: 'ens://your-site.eth',

EIPS/eip-2266.md

@@ -49,7 +49,7 @@ The Atomic Swap-based American Call Option smart contract should follow the synt
 
 This mapping stores the metadata of the swap contracts, including the parties and tokens involved. Each contract uses different `secretHash`, and is distinguished by `secretHash`.
 
-```
+```solidity
 mapping(bytes32 => Swap) public swap;
 ```
 
@@ -57,7 +57,7 @@ mapping(bytes32 => Swap) public swap;
 
 This mapping stores the detail of the asset initiators want to sell, including the amount, the timelock and the state. It is associated with the swap contract with the same `secretHash`.
 
-```
+```solidity
 mapping(bytes32 => InitiatorAsset) public initiatorAsset;
 ```
 
@@ -65,7 +65,7 @@ mapping(bytes32 => InitiatorAsset) public initiatorAsset;
 
 This mapping stores the details of the asset participants want to sell, including the amount, the timelock and the state. It is associated with the swap contract with the same `secretHash`.
 
-```
+```solidity
 mapping(bytes32 => ParticipantAsset) public participantAsset;
 ```
 
@@ -73,7 +73,7 @@ mapping(bytes32 => ParticipantAsset) public participantAsset;
 
 This mapping stores the details of the premium initiators attach in the swap contract, including the amount, the timelock and the state. It is associated with the swap contract with the same `secretHash`.
 
-```
+```solidity
 mapping(bytes32 => Premium) public premium;
 ```
 
@@ -84,7 +84,7 @@ mapping(bytes32 => Premium) public premium;
 
 This function sets up the swap contract, including the both parties involved, the tokens to exchanged, and so on.
 
-```
+```solidity
 function setup(bytes32 secretHash, address payable initiator, address tokenA, address tokenB, uint256 initiatorAssetAmount, address payable participant, uint256 participantAssetAmount, uint256 premiumAmount) public payable
 ```
 
@@ -92,7 +92,7 @@ function setup(bytes32 secretHash, address payable initiator, address tokenA, ad
 
 The initiator invokes this function to fill and lock the token she/he wants to sell and join the contract.
 
-```
+```solidity
 function initiate(bytes32 secretHash, uint256 assetRefundTime) public payable
 ```
 
@@ -100,7 +100,7 @@ function initiate(bytes32 secretHash, uint256 assetRefundTime) public payable
 
 The initiator invokes this function to fill and lock the premium.
 
-```
+```solidity
 function fillPremium(bytes32 secretHash, uint256 premiumRefundTime) public payable
 ```
 
@@ -108,7 +108,7 @@ function fillPremium(bytes32 secretHash, uint256 premiumRefundTime) public payab
 
 The participant invokes this function to fill and lock the token she/he wants to sell and join the contract.
 
-```
+```solidity
 function participate(bytes32 secretHash, uint256 assetRefundTime) public payable
 ```
 
@@ -116,7 +116,7 @@ function participate(bytes32 secretHash, uint256 assetRefundTime) public payable
 
 One of the parties invokes this function to get the token from the other party, by providing the preimage of the hash lock `secret`.
 
-```
+```solidity
 function redeemAsset(bytes32 secret, bytes32 secretHash) public
 ```
 
@@ -124,7 +124,7 @@ function redeemAsset(bytes32 secret, bytes32 secretHash) public
 
 One of the parties invokes this function to get the token back after the timelock expires.
 
-```
+```solidity
 function refundAsset(bytes32 secretHash) public
 ```
 
@@ -132,7 +132,7 @@ function refundAsset(bytes32 secretHash) public
 
 The participant invokes this function to get the premium. This can be invoked only if the participant has already invoked `participate` and the participant's token is redeemed or refunded.
 
-```
+```solidity
 function redeemPremium(bytes32 secretHash) public
 ```
 
@@ -140,7 +140,7 @@ function redeemPremium(bytes32 secretHash) public
 
 The initiator invokes this function to get the premium back after the timelock expires.
 
-```
+```solidity
 function refundPremium(bytes32 secretHash) public
 ```
 
@@ -151,7 +151,7 @@ function refundPremium(bytes32 secretHash) public
 
 This event indicates that one party has set up the contract using the function `setup()`.
 
-```
+```solidity
 event SetUp(bytes32 secretHash, address initiator, address participant, address tokenA, address tokenB, uint256 initiatorAssetAmount, uint256 participantAssetAmount, uint256 premiumAmount);
 ```
 
@@ -159,7 +159,7 @@ event SetUp(bytes32 secretHash, address initiator, address participant, address
 
 This event indicates that `initiator` has filled and locked the token to be exchanged using the function `initiate()`.
 
-```
+```solidity
 event Initiated(uint256 initiateTimestamp, bytes32 secretHash, address initiator, address participant, address initiatorAssetToken, uint256 initiatorAssetAmount, uint256 initiatorAssetRefundTimestamp);
 ```
 
@@ -167,7 +167,7 @@ event Initiated(uint256 initiateTimestamp, bytes32 secretHash, address initiator
 
 This event indicates that `participant` has filled and locked the token to be exchanged using the function `participate()`.
 
-```
+```solidity
 event Participated(uint256 participateTimestamp, bytes32 secretHash, address initiator, address participant, address participantAssetToken, uint256 participantAssetAmount, uint256 participantAssetRefundTimestamp);
 ```
 
@@ -175,7 +175,7 @@ event Participated(uint256 participateTimestamp, bytes32 secretHash, address ini
 
 This event indicates that `initiator` has filled and locked `premium` using the function `fillPremium()`.
 
-```
+```solidity
 event PremiumFilled(uint256 fillPremiumTimestamp, bytes32 secretHash, address initiator, address participant, address premiumToken, uint256 premiumAmount, uint256 premiumRefundTimestamp);
 ```
 
@@ -183,11 +183,11 @@ event PremiumFilled(uint256 fillPremiumTimestamp, bytes32 secretHash, address in
 
 These two events indicate that `asset` has been redeemed by the other party before the timelock by providing `secret`.
 
-```
+```solidity
 event InitiatorAssetRedeemed(uint256 redeemTimestamp, bytes32 secretHash, bytes32 secret, address redeemer, address assetToken, uint256 amount);
 ```
 
-```
+```solidity
 event ParticipantAssetRedeemed(uint256 redeemTimestamp, bytes32 secretHash, bytes32 secret, address redeemer, address assetToken, uint256 amount);
 ```
 
@@ -195,11 +195,11 @@ event ParticipantAssetRedeemed(uint256 redeemTimestamp, bytes32 secretHash, byte
 
 These two events indicate that `asset` has been refunded by the original owner after the timelock expires.
 
-```
+```solidity
 event InitiatorAssetRefunded(uint256 refundTimestamp, bytes32 secretHash, address refunder, address assetToken, uint256 amount);
 ```
 
-```
+```solidity
 event ParticipantAssetRefunded(uint256 refundTimestamp, bytes32 secretHash, address refunder, address assetToken, uint256 amount);
 ```
 
@@ -207,7 +207,7 @@ event ParticipantAssetRefunded(uint256 refundTimestamp, bytes32 secretHash, addr
 
 This event indicates that `premium` has been redeemed by `participant`. This implies that `asset` is either redeemed by `initiator` if it can provide the preimage of `secrectHash` before  `asset` timelock expires; or refunded by `participant` if `asset` timelock expires.
 
-```
+```solidity
 event PremiumRedeemed(uint256 redeemTimestamp,bytes32 secretHash,address redeemer,address token,uint256 amount);
 ```
 
@@ -215,7 +215,7 @@ event PremiumRedeemed(uint256 redeemTimestamp,bytes32 secretHash,address redeeme
 
 This event indicates that `premium` has been refunded back to `initiator`, because of `participant` doesn't participate at all, by the time of `premium` timelock expires.
 
-```
+```solidity
 event PremiumRefunded(uint256 refundTimestamp, bytes32 secretHash, address refunder, address token, uint256 amount);
 ```
 

EIPS/eip-2304.md

@@ -22,8 +22,7 @@ With the increasing uptake of ENS by multi-coin wallets, wallet authors have req
 
 A new accessor function for resolvers is specified:
 
-```
+```solidity
-
 function addr(bytes32 node, uint coinType) external view returns(bytes memory);
 ```
 
@@ -37,7 +36,7 @@ The return value is the cryptocurency address in its native binary format. Detai
 
 A new event for resolvers is defined:
 
-```
+```solidity
 event AddressChanged(bytes32 indexed node, uint coinType, bytes newAddress);
 ```
 
@@ -47,7 +46,7 @@ Resolvers MUST emit this event on each change to the address for a name and coin
 
 The following function provides the recommended interface for changing the addresses stored for a node. Resolvers SHOULD implement this interface for setting addresses unless their needs dictate a different interface.
 
-```
+```solidity
 function setAddr(bytes32 node, uint coinType, bytes calldata addr);
 ```
 
@@ -125,7 +124,7 @@ For example, the BNB address `bnb1grpf0955h0ykzq3ar5nmum7y6gdfl6lxfn46h2` decode
 
 An example implementation of a resolver that supports this EIP is provided here:
 
-```
+```solidity
 pragma solidity ^0.5.8;
 
 contract AddrResolver is ResolverBase {

EIPS/eip-706.md

@@ -94,7 +94,7 @@ You can verify that an encoded binary can be decoded into the proper plaintext u
 
 ### Go
 
-```
+```sh
 $ go get https://github.com/golang/snappy
 ```
 
@@ -144,7 +144,7 @@ func main() {
 }
 ```
 
-```
+```sh
 $ go run main.go block.rlp block.go.snappy
 Yay, decompressed data matched provided plain text!
 
@@ -182,7 +182,7 @@ else:
     print "Yay, decompressed data matched provided plain text!"
 ```
 
-```
+```sh
 $ python main.py block.rlp block.go.snappy
 Yay, decompressed data matched provided plain text!
 

EIPS/eip-779.md

@@ -28,7 +28,7 @@ At block 1880000, the following accounts are encoded into a list `L`:
 
 At the beginning of block 1920000, all ether throughout all accounts in `L` will be transferred to a contract deployed at `0xbf4ed7b27f1d666546e30d74d50d173d20bca754`. The contract was created from the following Solidity code (compiler version `v0.3.5-2016-07-01-48238c9`):
 
-```
+```solidity
 // Deployed on mainnet at 0xbf4ed7b27f1d666546e30d74d50d173d20bca754
 
 contract DAO {

EIPS/eip-823.md

@@ -26,13 +26,13 @@ This interface must be inherited by a ERC20 token contract that wants to exchang
 ##### exchnagedWith
 This mapping stores the number of tokens exchanged with another token, along with the latter’s address. Every time more tokens are exchanged the integer value is incremented consequently. This mapping acts as a record to denote which target contract holds our tokens.
 
-``` js
+```solidity
 mapping ( address => uint ) private exchangedWith;
 ```
 ##### exchangedBy
 This mapping stores the address of the person who initiated the exchange and the amount of tokens exchanged.
 
-``` js
+```solidity
 mapping ( address => uint ) private exhangedBy;
 ```
 
@@ -43,14 +43,14 @@ NOTE: Callers MUST handle false from returns (bool success). Callers MUST NOT as
 ##### exchangeToken
 This function calls the intermediate exchange service contract that handles the exchanges. This function takes the address of the target contract and the amount we want to exchange as parameters and returns boolean `success` and `creditedAmount`.
 
-``` js
+```solidity
 function exchangeToken(address _targetContract, uint _amount) public returns(bool success, uint creditedAmount)
 ```
 
 ##### exchangeAndSpend
 This function calls an intermediate exchange service contract that handles exchange and expenditure. This function takes the address of the target contract, the amount we want to spend in terms of target contract tokens and address of the receiver as parameters and returns boolean `success`.
 
-``` js
+```solidity
 function exchangeAndSpend(address _targetContract, uint _amount,address _to) public returns(bool success)
 ```
 
@@ -59,7 +59,7 @@ This function is called by the exchange service contract to our token contract t
 
 NOTE: It is required that only the exchange service contract has the authority to call this function.
 
-``` js
+```solidity
 function __exchangerCallback(address _targetContract,address _exchanger, uint _amount) public returns(bool success)
 ```
 
@@ -68,14 +68,14 @@ function __exchangerCallback(address _targetContract,address _exchanger, uint _a
 ##### Exchange
 This event logs any new exchanges that have taken place.
 
-``` js
+```solidity
 event Exchange(address _from, address _ targetContract, uint _amount)
 ```
 
 ##### ExchangeSpent
 This event logs any new exchange that have taken place and have been spent immediately.
 
-``` js
+```solidity
 event ExchangeSpent(address _from, address _targetContract, address _to, uint _amount)
 ```
 
@@ -86,7 +86,7 @@ This interface must be inherited by a ERC20 token contract that wants to receive
 ##### exchangesRecieved
 This mapping stores the number of tokens received in terms of another token, along with its address. Every time more tokens are exchanged the integer value is incremented consequently. This mapping acts as a record to denote which tokens do this contract holds apart from its own.
 
-``` js
+```solidity
 mapping ( address => uint ) private exchnagesReceived;
 ```
 #### Methods
@@ -98,7 +98,7 @@ This function is called by the intermediate exchange service contract. This func
 
 NOTE: It is required that only the exchange service contract has the authority to call this function.
 
-``` js
+```solidity
 function __targetExchangeCallback (uint _to, uint _amount) public returns(bool success)
 ```
 
@@ -107,7 +107,7 @@ This function is called by the intermediate exchange service contract. This func
 
 NOTE: It is required that only the exchange service contract has the authority to call this function.
 
-``` js
+```solidity
 function __targetExchangeAndSpendCallback (address _from, address _to, uint _amount) public returns(bool success)
 ```
 
@@ -115,13 +115,13 @@ function __targetExchangeAndSpendCallback (address _from, address _to, uint _amo
 ##### Exchange
 This event logs any new exchanges that have taken place.
 
-``` js
+```solidity
 event Exchange(address _from, address _with, uint _amount)
 ```
 
 ##### ExchangeSpent
 This event logs any new exchange that have taken place and have been spent immediately.
-``` js
+```solidity
 event ExchangeSpent(address _from, address _ targetContract, address _to, uint _amount)
 ```
 
@@ -135,7 +135,7 @@ This is an intermediate contract that provides a gateway for exchanges and expen
 
 This array stores all the tokens that are registered for exchange. Only register tokens can participate in exhanges.
 
-``` js
+```solidity
 address[] private registeredTokens;
 ```
 
@@ -147,7 +147,7 @@ This function is called by the owner of the token contract to get it’s tokens
 
 NOTE: Before any exchange it must be ensured that the token is registered.
 
-``` js
+```solidity
 function registerToken(address _token) public returns(bool success)
 ```
 
@@ -155,7 +155,7 @@ function registerToken(address _token) public returns(bool success)
 
 This function is called by the token holder who wants to exchange his token with the `_targetContract` tokens. This function queries the exchange rate, calculates the converted amount, calls `__exchangerCallback` and calls the `__targetExchangeCallback`. It takes address of the target contract and amount to exchange as parameter and returns boolean `success` and amount credited.
 
-``` js
+```solidity
 function exchangeToken(address _targetContract, uint _amount, address _from) public returns(bool success, uint creditedAmount)
 ```
 
@@ -163,7 +163,7 @@ function exchangeToken(address _targetContract, uint _amount, address _from) pub
 
 This function is called by the token holder who wants to exchange his token with the `_targetContract` tokens. This function queries the exchange rate, calculates the converted amount, calls `__exchangerCallback` and calls the `__targetExchangeAndSpendCallback`. It takes address of the target contract and amount to exchange as parameter and returns boolean `success` and amount credited.
 
-``` js
+```solidity
 function exchangeAndSpend(address _targetContract, uint _amount, address _from, address _to) public returns(bool success)
 ```
 
@@ -173,14 +173,14 @@ function exchangeAndSpend(address _targetContract, uint _amount, address _from,
 
 This event logs any new exchanges that have taken place.
 
-``` js
+```solidity
 event Exchange( address _from, address _by, uint _value ,address _target )
 ```
 ##### ExchangeAndSpent
 
 This event logs any new exchange that have taken place and have been spent immediately.
 
-``` js
+```solidity
 event ExchangeAndSpent ( address _from, address _by, uint _value ,address _target ,address _to)
 ```
 

EIPS/eip-875.md

@@ -63,7 +63,7 @@ Some protections need to be added to the message such as encoding the chain id,
 
 ## Interface
 
-```
+```solidity
 contract ERC165 
 {
             /// @notice Query if a contract implements an interface

EIPS/eip-926.md

@@ -17,7 +17,7 @@ An increasing set of use cases require storage of metadata associated with an ad
 
 ## Specification
 The metadata registry has the following interface:
-```
+```solidity
 interface AddressMetadataRegistry {
   function provider(address target) view returns(address);
   function setProvider(address _provider);
@@ -34,7 +34,7 @@ Providers may implement any subset of the metadata record types specified here.
 
 Providers have one mandatory function:
 
-```
+```solidity
 function supportsInterface(bytes4 interfaceID) constant returns (bool)
 ```
 
@@ -59,7 +59,7 @@ There are no backwards compatibility concerns.
 
 ## Implementation
 The canonical implementation of the metadata registry is as follows:
-```
+```solidity
 contract AddressMetadataRegistry {
   mapping(address=>address) public provider;
   

EIPS/eip-927.md

@@ -20,7 +20,7 @@ The pattern implemented here is inspired by [ds-auth](https://github.com/dapphub
 ## Specification
 The generalised authorisation interface is implemented as a metadata provider, as specified in EIP 926. The following mandatory function is implemented:
 
-```
+```solidity
 function canCall(address owner, address caller, address callee, bytes4 func) view returns(bool);
 ```
 
@@ -39,7 +39,7 @@ As this standard uses EIP 926, the authorisation flow is as follows:
 
 Commonly, providers will wish to supply a standardised interface for users to set and unset their own authorisations. They SHOULD implement the following interface:
 
-```
+```solidity
 function authoriseCaller(address owner, address caller, address callee, bytes4 func);
 function revokeCaller(address owner, address caller, address callee, bytes4 func);
 ```

README.md

@@ -41,7 +41,7 @@ The canonical URL for a EIP that has achieved draft status at any point is at ht
 EIPs must pass some validation tests.  The EIP repository ensures this by running tests using [html-proofer](https://rubygems.org/gems/html-proofer) and [eip_validator](https://rubygems.org/gems/eip_validator).
 
 It is possible to run the EIP validator locally:
-```
+```sh
 gem install eip_validator
 eip_validator <INPUT_FILES>
 ```
@@ -58,7 +58,7 @@ The EIP repository contains an "auto merge" feature to ease the workload for EIP
 
 2. Check whether you have Ruby 2.1.0 or higher installed:
 
-```
+```sh
 $ ruby --version
 ```
 
@@ -66,13 +66,13 @@ $ ruby --version
 
 4. Install Bundler:
 
-```
+```sh
 $ gem install bundler
 ```
 
 5. Install dependencies:
 
-```
+```sh
 $ bundle install
 ```
 
@@ -80,7 +80,7 @@ $ bundle install
 
 1. Bundle assets and start the server:
 
-```
+```sh
 $ bundle exec jekyll serve
 ```