Support  our Project on Lokdon

LokDon | Endpoint-To-Endpoint Encryption

Security Module as a Software Service ( SMAASS)

The Keyless, Distributed, Decentralized, Autonomous Security For Mobile, Cloud And Internet Of Things.

LokDon$ App (New) ยป


ZKP Triangle Flow 4

  • A must confirm the transaction in flow 3 by undergoing another ZKP. “I am A sealing that I did this transfer for you as agreed”
    This is second and the last ZKP by A.
  • Sender M3Pin is extracted from the message body decrypted and compared with the recipient M3Pin for a character length of 10 if it matches to determine a valid m3pin string if(!CipherControl.getInstance().decryptMpinFromSinglePosition(m3Pin+applicationController .getValueFromPerference(Constants.KEY_MPIN).charAt(10)) .equalsIgnoreCase(CipherControl.getInstance() .decryptTransactionSecurityPin(applicationController .getValueFromPerference(Constants.KEY_MPIN)))) { TastyToast.makeText(context,”Mpin Not Match”,TastyToast.LENGTH_SHORT,TastyToast.ERROR).show(); Return; }
  • The confirm payment API is accessed LEG B with parameters like sent amount, session message, sender phone number and receiver phone number all encrypted.
  • On success complete payment is made and all necessary debit and credit would be initiated on both accounts i.e, the sender would be debited from the LOKDON wallet with sent amount while the recipient would be credited accordingly.


There is not much to write about. It’s just that where you have matching. Should be receivers m3pin added to the message is extracted, decrypted to the next mode m2pin. This iS compared to m2pin held locally or by the server.