Kleros Moderate
  • Introduction to Kleros
  • Kleros FAQ
  • Governance
  • PNK Token
  • They talk about Kleros
  • Products
    • Court
      • Kleros Juror Tutorial
      • Famous Kleros Cases
      • What happens during a dispute?
      • Kleros & Credible Neutrality
    • Proof of Humanity
      • Proof of Humanity Tutorial (Register & Vouch)
      • Proof Humanity Tutorial (Remove & Challenge)
      • Proof of Humanity FAQ
    • Tokens
      • Kleros Tokens Tutorial
    • Curate
      • Kleros Curate Tutorial
    • Oracle
    • Governor
    • Escrow
      • Kleros Escrow Tutorial
      • Kleros Escrow Specifications
    • Linguo
      • Kleros Linguo Tutorial
      • Step-by-step Tutorial
        • Requesting translations
        • Working as a translator
        • Reviewing translations
      • F.A.Q
      • High-level Overview
    • Moderate
      • Susie
        • Getting Started
          • Add Susie
          • Start Susie
        • Basics
          • Welcome
          • Language
          • Notifications
        • Rules
        • Reports
        • Evidence
        • Federations
  • INTEGRATIONS
    • Overview
    • Types of Integrations
      • 1. Dispute resolution integration plan
        • Smart contract integration with Kleros Court (Arbitrator)
        • Use Cases
          • DeFi Insurance
          • Gaming
        • Channel partners
          • How to use Reality.eth + Kleros as an oracle
          • Safe Zodiac integration
        • Integration Tools
          • Escrow React
          • Escrow SDK
          • Centralized Arbitrator
      • 2. Curated-data integration plan
        • Interact with Arbitrable apps built on top of Kleros Court
    • Policy writing guide
    • Live & Upcoming Integrations
    • Kleros Analytics
    • Scalability & Cross-chain
      • Using Kleros arbitration for Dapps on xDai/Gnosis
    • Integrations FAQ
  • Developers
    • Arbitration Development
      • ERC-792: Arbitration Standard
      • ERC 1497: Evidence Standard
    • Arbitration by Example
      • ArbitrableDeposit.sol
      • TwoPartyArbitrable.sol
      • Rental.sol
      • ArbitrableTransaction.sol
      • MultipleArbitrableTransaction.sol
      • MultipleArbitrableTokenTransaction.sol
    • Archon: Ethereum Arbitration Standard Interaction Library
    • Deployment Addresses
    • Curate Classic: Integration for Devs
    • Light Curate: Integration for Devs
    • Guide for Preparing Transactions
  • Contribution Guidelines
    • Overview
    • General Dev. Workflow
      • Task Tracking & Lifecycle
      • Releases
    • Smart Contract Workflow
      • Task Tracking & Lifecycle
      • RAB - Review, Audit, Bounty
      • RABd (+ Deploy)
      • Reporting Vulnerabilities
    • Code Style and Guidelines
      • Git
      • Solidity
      • Web Languages
    • License & Code of Conduct
      • License
      • Code of Conduct
  • Additional Resources
    • Discord
    • Telegram
    • Governance Forum
    • Twitter
    • Blog
    • Reddit
    • Github
    • Slack
Powered by GitBook
On this page
  1. Contribution Guidelines
  2. Smart Contract Workflow

RABd (+ Deploy)

Read this before hitting the big red button.

PreviousRAB - Review, Audit, BountyNextReporting Vulnerabilities

Last updated 2 years ago

Once deployed, smart contract code becomes immutable, so you better get it right the first time. This is a very different setting to traditional software development where you can continuously release fixes and enhancements. Although, there are , they are anything but trivial, and can come with their own flaws.

The following steps should be taken to minimize risk:

Once that's done, the assignee does the following:

  1. Creates a pull request titled "chore/deploy-<smart-contract>", that adds the latest commit hash of the master branch and the soon to be contract address, separated by a "@" character (e.g. 90ed3a5e944d7e7c5d413366ad9f0c530cd92880@0xb7faddf3ecd2402a7e48cea6d2637d90eeb5a7e6), to the contract's RAB pragma comment's deployments list, and closes the issue.

  2. Labels it with the appropriate priority, appropriate status, and "maintenance" type.

  3. Assigns himself and adds the whole review team as reviewers.

  4. Concatenates all the necessary contract code into a single snippet or gist and posts it in the pull request.

  5. Waits for everyone to check off on the code.

  6. Gives the code a final read and deploys it using something like Remix or a CLI, before verifying the code on .

  7. Adds the contract address to the contract's RAB pragma comment if not already there, changes the status to the "review needed" status and waits for another team member to approve and merge.

Verifying code on is a great way to enhance transparency and let users interact with your contract directly in an easier manner.

patterns for upgrading smart contracts
RAB
Etherscan
Etherscan