Giter VIP home page Giter VIP logo

smart-contract-metadata-registry's Introduction

Smart Contract Metadata Registry

Introduction

Mission

This repo collects cross-chain smart contract ABIs to protect the Web3 community against phishing attacks targeting average Web3 users and sophisticated remote attacks on whales.

Motivation

Ethereum and other blockchain decentralized networks are trying to rebuild trust through trustless computational systems. One of the most important mantras in the blockchain community is “Don’t trust. Verify!”.

To apply this mantra to signing a normal transaction on a software or hardware wallet, the user needs to fully verify at least the amount of crypto, destination address (sometimes change address with UTXO model blockchains) and transaction fees. Otherwise an attacker can perform a ransom attack to steal crypto assets without gaining access to the user’s recovery phrase (seed) or private keys. With the booming of Tokenization in 2017 and DeFi projects in 2020, blockchain transactions have become much more complex than just sending coins on mainnet. Transactions that are interacting with smart contracts require software and hardware wallets to be able to do ABI decoding to avoid blind signing.

This repo is a community effort to collect ABIs to protect users against phishing attacks and sophisticated remote attacks. Any software and hardware wallets can use the data in this repo to decode corresponding smart contracts to enhance signing security for the Web3 community.

Structure

The repo is a collection of contract data such as names, contract metadata and other data fields.

All of the contract metadata is grouped by chain. For each contract, it has a json file with the contract address as its name.

For each json file, there are these fields:

{
    "name": string, // contract name optional
    "chainId": number, // for evm chain, this is the chainId of the deployed chain.
    "address": string, // contract address required
    "metadata":  json, // contract metadata required
    "version": number // contract version number required
    "checkPoints": [], // reserved field optional
    "isProxy": boolean, // whether this is an proxy contract which follows [EIP-1967](https://eips.ethereum.org/EIPS/eip-1967) optional
    "principalAddress": the principal contract address if this is an proxy contract optinal.
}

The “Address” and “metadata” are two required fields. The address follows the EIP 55 address checksum format.

The “metadata” field follows the contract metadata.The output field in the metadata are required which should including the abi, userdoc and devdoc three fields.

{
  ....
  // Required: Generated information about the contract.
  output:
  {
    // Required: ABI definition of the contract
    abi: [ ... ],
    // Required: NatSpec user documentation of the contract
    userdoc: [ ... ],
    // Required: NatSpec developer documentation of the contract
    devdoc: [ ... ],
  }
}

Proxy Contract

For proxy contract which follows the EIP-1967, please fill the abi of your origin contract instead of the proxy contract and set the isProxy field to true and set the your origin contract address to the principalAddress field.

Contributors

Wallet Supports Transaction ABI Decoding

Related Solutions & Resources

License

MIT

smart-contract-metadata-registry's People

Contributors

0xumbur avatar aaronisme avatar bunsdev avatar caixiao-qa avatar chef-cheems avatar cstrat avatar hjt-blocksec avatar lufycz avatar mikkompeltonen avatar mtaan avatar nanyezhuyu avatar owen05 avatar raredata avatar sirarthurmoney avatar weitingboy avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

smart-contract-metadata-registry's Issues

Platypus Finance - Platypus Venom Contract -- is this all thats required for a contribution?

I would love to contribute to this collection!
Not sure if this is all thats required, I just took a look at some of the other contracts submitted.
Honestly I have no idea what userdoc and devdoc are?

Can we use a nice name for the record, or should it always match the smart contract?
See below, the contract is called OptimizedTransparentUpgradeableProxy but it is listed as Platypus Finance: Platypus Venom as the public name. A layman user is probably going to want to see the Platypus Finance label, not the OptimizedTransparentUpgradableProxy one.

image

Contract

https://snowtrace.io/address/0x5857019c749147eee22b1fe63500f237f3c1b692#code

0x5857019c749147EEE22b1Fe63500F237F3c1B692.json

{
  "name": "OptimizedTransparentUpgradeableProxy",
  "chainId": 43114,
  "address": "0x5857019c749147EEE22b1Fe63500F237F3c1B692",
  "metadata": {
    "output": {
      "abi": [{"inputs":[{"internalType":"address","name":"initialLogic","type":"address"},{"internalType":"address","name":"initialAdmin","type":"address"},{"internalType":"bytes","name":"_data","type":"bytes"}],"stateMutability":"payable","type":"constructor"},{"anonymous":false,"inputs":[{"indexed":true,"internalType":"address","name":"implementation","type":"address"}],"name":"Upgraded","type":"event"},{"stateMutability":"payable","type":"fallback"},{"inputs":[],"name":"admin","outputs":[{"internalType":"address","name":"","type":"address"}],"stateMutability":"nonpayable","type":"function"},{"inputs":[],"name":"implementation","outputs":[{"internalType":"address","name":"","type":"address"}],"stateMutability":"nonpayable","type":"function"},{"inputs":[{"internalType":"address","name":"newImplementation","type":"address"}],"name":"upgradeTo","outputs":[],"stateMutability":"nonpayable","type":"function"},{"inputs":[{"internalType":"address","name":"newImplementation","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"upgradeToAndCall","outputs":[],"stateMutability":"payable","type":"function"},{"stateMutability":"payable","type":"receive"}]
    }
  },
  "version": 1,
  "checkPoints": []
}

Explain how the current contracts got here

I understand the format and the source code verification tool, but how did this massive data source get here in the first-place? Was there an automated tool used to pull all the current ABIs?

I got here from here and want to understand how this massive data source got built

Handling proxy contracts?

I don't really fully understand this, but it appears you can have a proxy contract.
Looks like a way to have a single contract address but swap out the contract in the backend... kind of allow upgrades etc.

How does this work with the metadata registry.

So check this contract out.
https://snowtrace.io/address/0x423d0fe33031aa4456a17b150804aa57fc157d97#code

My contract interaction is with the above linked contract, but the ABI used comes from here:
https://snowtrace.io/address/0x3afe915d1aca92550c9069fc4ab6076ae0017a7a#code

Is there a mis-match if I put the ABI from the second contract against the first contract?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.