POA
English
English
  • Welcome to POA
  • Features
    • Known Validators
    • POADAO Consensus
    • Bridged Native Token
    • On-Chain Randomness
  • Use Cases
    • Scalability for BlockChain Games
    • Community-Based Currencies
    • Subsidized Transactions
    • Decentralized Finance (DeFi)
  • DApp Spotlights
    • Ethernal.World
  • Roadmap
  • For users
    • POA Tokens
      • POA Merger & STAKE Swap
      • POA - STAKE FAQs
      • POA Token Supply
      • POA & POA20 Exchanges
      • POA & POA20 on Binance
      • FAQ: POA20 General Questions
    • POA Token Use Cases
      • Utility Token
      • Currency Token
      • Collateral Token
      • Bridged Token
      • Staking Token
      • Stable Token
    • POA to POA20 Bridge
    • Accept POA20 Payments
      • Account Registration & Login (Merchant Setup)
      • Setup Merchant Account
      • Merchant Payment Method Setup
      • Making a Payment with POA20 (Customer Perspective)
    • Tutorials
      • Trading POA20 on DEX.AG
      • POA20 Token Swaps on 1inch.exchange
      • Getting Airdrops via Discord
    • Governance
      • Article: A Successful Year of On-Chain Governance
      • Governance Reports
        • April 2020 Report
        • December 2019 Report
      • Ballot Type, Lifecycle & Limits
    • ❌Nifty Wallet (Discontinued)
      • Getting Started
      • Import and Interact with Smart Contracts
      • Connect to a Hardware Wallet (Ledger & Trezor)
      • Connect to D'CENT Biometric Wallet
      • Connect to Pocket Decentralized Network
    • 3rd Party Wallets
      • Trust Wallet
      • MetaMask
    • POA Mania
      • News - Updates
      • Rules
      • POA Mania FAQs
      • Deposit & Withdraw
      • Winner Selection
      • Round Details
      • POA Mania vs PoolTogether
      • POA Mania on Trust Wallet
      • POA Mania Security Audit
      • POA Mania on MetaMask Mobile
    • Whitepaper
      • POADAO v1
        • Introduction
        • Proof of Authority
        • POA Network Functionality
        • Decentralized apps (DApps)
          • Initial ceremony DApp
          • Proof of Physical Address (PoPA) DApp
          • Proof of Bank Account DApp
          • Proof of Social Network DApp
          • Proof of Phone Number DApp
          • Governance DApp
        • Summary & Acknowledgements
        • References
        • Appendix A: Code Samples
          • Ballots manager
          • Validators manager
          • Deployment scripts for the mining node
  • For developers
    • Developer Resources
    • Getting Tokens For Tests
      • ERC20 Test Token Faucet
      • Sokol Testnet Faucet
    • Full Node Setup
      • Install OpenEthereum Client
      • Install Nethermind Client
    • DApp Deployment
    • TheGraph Data Indexing
    • On-Chain Random Numbers
      • RNG explainer (AuRa + RandomAura Contract)
      • Accessing a Random Seed with a Smart Contract
      • Randomness FAQs
    • API & SQL Access
    • Smart Contract Dashboard
    • Grants for Building on POA
  • For validators
    • Getting Started
      • Validator Resources
      • Becoming a Validator
    • Bootnode Setup
      • AWS Bootnode Setup
        • Prerequisites
        • Configure AWS
        • Download and Configure Playbook
        • Deploy
      • Non-AWS Bootnode Setup & Deployment
        • Local/Remote Machine System Requirements
        • Node Preparation
        • Configure node with Deployment Playbook
    • Validator Node Setup
      • Nethermind Upgrade
      • AWS VM for Validator Node Deployment
        • MoC: Master of Ceremony Key Exchange & Generation
        • Current Validators Vote in New Validators
        • Validator Node Setup Prerequisites
        • Configuring AWS
        • Download and Configure Playbook
        • Deployment
        • Upgrade Instance to a Larger Instance Type
      • Non-AWS Validator Node Setup
        • Local & Remote Machine System Requirements
        • Remote Machine Setup
        • Configure Node using Deployment Playbook
      • NetStats Dashboard
    • Hard Forks
      • Parity Upgrade Guide
      • POA Core
        • 2021-11-02 | #24090200
        • 2021-05-24 | #21364900
        • 2020-03-31 | #14350721
        • 2019-12-19 | #12598600
        • 2019-04-29 | #8582254
        • 2018-01-29 | # 772000
        • 2018-10-22 | #5329160
        • POA Core spec.json hard-fork update
      • Sokol
        • 2021-05-24 | #21050600
        • 2020-02-20 | #13391641
        • 2019-12-05 | #12095200
        • 2019-02-06 | #7026400
        • 2019-01-04 | #6464300
        • 2018-09-19 | #4622420
        • 2018-01-18 | #509355
        • 2018-01-08 | #362296
        • Sokol spec.json hard-fork update
    • Validator DApps
      • Validators MetaData DApp
      • Adding or Removing a Validator
  • Media
    • Social Media
    • Media Kit
    • Contact Us
Powered by GitBook
On this page

Was this helpful?

  1. For users
  2. Whitepaper
  3. POADAO v1
  4. Decentralized apps (DApps)

Proof of Bank Account DApp

PreviousProof of Physical Address (PoPA) DAppNextProof of Social Network DApp

Last updated 5 years ago

Was this helpful?

In contrast to other identity DApps, PoBA is (from the contract's point of view) a one-step verification process.

DApp client and server are integrated with bank accounting API service (plaid.com).

Client side uses the service's widget (Plaid Link) to authenticate the user, and as a result of successful authentication, access_token is returned from Plaid to the client. User then fills out a form with his/her bank account number and submits it to the server alongside Plaid's access token.

Server consists of a web app and a parity node connected to the blockchain. The node is run under the ethereum account that was used to deploy the PoP contract (contract's owner). This account needs to be unlocked.

Server validates and normalizes the user's account number by removing trailing spaces. Then the server fetches the bank account numbers from Plaid using access_token. It checks that the account number submitted by the user is present in the list returned by Plaid.

Server then combines user's eth address + bank's name + account number into a single string and hashes it with SHA-3 function. The hash is then signed with owner's private key (this is why owner account needs to be unlocked).

Signature, normalized account number, and bank name are returned to the client. User then signs the transaction in MetaMask and invokes the contract's method.

Contract checks that the account number for this bank for this eth address doesn't already exist. If it does, the contract rejects the transaction. Otherwise, it combines parameters in the same order as the server did and computes sha3 hash of them. Then it uses the built-in ecrecover function to validate that the signature belongs to the owner. If it doesn't, the contract rejects the transaction, otherwise, it saves the information to the blockchain.

Possible cheating

  1. user can generate his/her own confirmation code, compute all hashes, and submit it to the contract, and then confirm it This can't be done because the user doesn't know the owner's private key and hence can't compute a valid signature.

  2. user can use someone else's access_token returned by Plaid and thus verify the account he/she has no real access to This is equivalent to either hacking someone else's computer or the account's owner deliberately providing the user with his/her access_token. Since all communications with Plaid are via HTTPS protocol, there is no way for the user to intercept access_token sent to someone else.

Click on image to enlarge