Innovative payment smart contract with reputation system

Wallet address to wallet address crypto transfers would be orders of magnitude better than fiat payments if a reputation system were built in. Outside of blockchain it is impossible to embed reputation in payments. This blockchain advantage has never been leveraged. Until now. Until State Channels?

  • Bob sends Alice 1 ETH via a smart contract;
  • Alice receives a notification about the payment but she cannot access it until a rating is provided by Bob.
  • Bob cannot provide a rating until Alice approves the payment. The notification she received asks her to approve the payment. She approves it.
  • Once approved by Alice, Bob cannot retrieve his ETH from the smart contract.
  • Bob is notified that Alice has approved the payment but that he must rate the transaction, for example, 1-5. Maybe Bob was buying a car and the exchange is happening in person. Bob is satisfied that all is in order and gives Alice a 5 rating.
  • Once rated, Alice needs to rate Bob in order to access the 10 crystals. She rates bob 5. The ETH are now available to her in her wallet.


  • An online market place is created. Reputation scores and Ethereum addresses of sellers are displayed. 50% of the purchases are conducted face to face and the reputation scores ensure a level of safety that buyers did not before have. Where the items need to be shipped, usually, if the buyer has a high reputation, the seller is content to accept the payment and ship in the knowledge that the buyer cannot access the paid funds.

Attack vectors
To prevent people gaming the reputation system in order to abuse it, reputation given could be weighted depending on the reputation of the account giving it. For example, a reputation score given by an account with established reputation achieved through multiple transactions would increase the recipient’s reputation score more than that received from a new account. Perhaps a fee could be levied on the transaction - instead of rent seeking platform, a strong reputation system is incentivised.

If a reputation system was embedded in a blockchain based payment solution, a step change over what e-commerce, banking etc. provides would be achieved. I want to see if State Channels could help achieve it.

Hey fraserb! Thanks for your post, it’s very interesting! My apologies for a delayed response.

It would probably be difficult to support your use case directly with Nitro state channels, because the state transition logic must be a pure function. But that doesn’t mean you can’t build a solution that incorporates a Nitro state channel.

I’m not quite sure I understand the setup. For instance, I don’t know where “the 10 crystals” came from. Is it being mixed up with “a car”?

My understanding is that what you want is some sort of Reputation contract that people can use to gauge whether or not they can trust a buyer. If this is the case, something like the following design might work with Nitro channels. I wrote this a bit hastily, but I hope it makes sense.

  • There could be a RatingContract, independent of Nitro protocol.
  • The state channel logic could accumulate ratings as a part of the state.
    1. State 0: Bob sends Alice a conditional payment of (1 Eth): s0 = {conditionalPayment: **snip**}
    2. State 1: Alice approves the payment: s1 = {conditionalPayment, paymentApproval: **snip**}
    3. State 2: Bob provides a rating: s2 = {rating: **snip**}. In this state, the outcome is updated so that the conditional payment went through.

Now, remember that this is all off-chain communication, so the rating hasn’t yet taken effect. So, rating here needs to be some data that Alice can take on-chain, separate from the state channel:


But I think you get two things out of this procedure:

  1. if the Nitro app is designed correctly, the payment goes through conditional on the rating being provided. IE, the transfer in value happened atomically.
  2. You could of course write a smart contract to execute this “transfer” atomically. But, Nitro lets you repeat this interaction multiple times, letting you accumulate ratings – in step 3 above, you can “add some weight” to the existing rating. You can then bring supply the accumulated rating to the Reputation contract in a single transaction, netting a significant gas savings by preventing multiple writes to the same storage slot.

Maybe that type of approach is feasible/beneficial for some types of reputation relationships, where Alice rates Bob multiple times?

Or, if you use virtual channels (blog post coming “soon”), you can collect lots of ratings with lots of different people, without requiring any on-chain interaction to set up the atomic swap.

BTW, we’re thinking about starting “office hours”. Would you be interested in discussing your idea with someone from team?