0.03 ETH


Remaining Balance


Bounties x Rimble Prompt 3: Transaction States



front-end dev

ðapp usability

Problem Background

Nearly every user we've spoken to has expressed they often lack confidence transacting on a dApp. Those in the know rely on tools such as Etherscan and MetaMask to understand what's going on, those less savvy cross their fingers and hope for the best.

This lack of confidence is exacerbated by the fact that transactions can be scary. After all, they're irreversible, require value and can take minutes or hours instead of seconds. How might we design something that helps soothe any anxiety and boost confidence in dApp transactions?


Through decentralized action, how might we create an open collection of patterns that dApp builders can use to design an informative experience for users during an Ethereum transaction?

Create an open, reusable pattern (or set of patterns) that improves the user experience throughout the transaction process.

Possible scenarios to account for include:

  • user rejecting transaction
  • transaction rejected for low gas
  • transaction pending in mempool due to low gas
  • re-submitting transaction with higher gas and same nonce
  • misconfigured max gas value
  • slow transaction speed
  • high-confidence transactions with many confirmations
  • estimating transaction time
  • transaction completion summary details

For example, a potential solution might do the following:

  • User clicks "Buy" button, initiating smart contract interaction
  • Show modal with details about transaction
    • estimated gas costs
    • expected completion time
  • User approves transaction in MetaMask
  • Show modal with transaction progress details
    • expected completion time
  • Show confirmation when transaction is successful
    • Actual gas costs
    • Time to complete transaction

Submission Requirements

Submissions should improve upon some aspect of the approach to communicating transaction status to a user. Everyone is welcome to submit a solution to the prompt, regardless of fidelity or technical implementation. We encourage participants to submit writing, sketches, UI designs, and/or prototypes in any form.

Minimum requirements:

  • A clearly articulated and written explanation of your solution and the pain-points it attempts to address, accompanied if possible by sketches or low-fidelity visual aids to help illustrate the solution.

Ideal submissions might include:

  • Design files illustrating user flows or application touch points
  • A prototype (Figma, Invision, etc…)
  • Live working/hosted demo
  • Link to source code repo

Use of Rimble UI is encouraged, but not required.

Evaluation Criteria

Submissions will be evaluated based on the following criteria:

  • Novelty: Does this pattern provide a new or improved approach?
  • Usability: Can we expect users to accomplish the desired task?
  • Flexibility: Can this pattern be applied to a wide range of applications?
  • Implementation / Fidelity: How much time and effort went in to the submission? How thorough is the exploration of the problem and how impressive is the execution and presentation of the solution?
  • Accessibility: Can this pattern be used with a screen reader? Does it pass at least WCG 2.0 AA standards for accessibility?
  • Error handling: How does this pattern address different errors that might occur during the process?


Submissions that meet some of the criteria above will likely be accepted and will receive a prize in the amount of the bounty payout.

Exceptional submissions that meet most if not all of the evaluation criteria and that go above and beyond to address the prompt with a potentially higher level of fidelity will be eligible to receive honorable mention and a larger prize which will be sent to the ETH address attached to the submissions. The Bounties and Rimble teams will be judging each submission based on the evaluation criteria throughout the week to determine which submissions will be accepted and/or might be eligible for additional prizes.

Exceptional submission prizes are as follows:
1st Prize: $100 <> 0.5453 ETH (at time of activation)
2nd Prize: $50 <> 0.2727 ETH (at time of activation)

Disclaimer: 1 submission per prompt per participant. We reserve the right to reject submissions that appear to be copies of previously submitted work by other participants. The content of all submissions will be considered open source contributions to the Rimble project.

7 monthsremaining
0 revisionsexpected






Open Ballot is a decentralized poll application currently under development and living on Rinkeby Network.

When a user wants to interact with the smart contract the details of the data they want to send will be displayed in the modal so they have time to finalize what they want to send.

When a submits data to the contract the user will be notified in the form of toast so users will know the state and details of their transaction, like transaction hash and block number when the transaction got confirmed.

if the transaction fail, the user will be notified by number of reasons as to why it likely failed and how can it be avoided in the future.

The Website also listens to the network and account and will refresh the page if it changes to avoid conflicts in the network.

The user can continue in using the site even if they have a pending transaction.


  • user interacts with Smart Contract
  • user confirms transaction within MetaMask
  • ToastMessage indicates the remaining waiting time
  • advanced stats by clicking on the ToastMessage such as the size of the mempool, position in the mempool according to the chosen gas price, last block time, etc