📐Architecture
PLAUSIBLE Protocol
W3C Compliant DIDs, Verifiable Credentials and OpenBadges powered by Algorand Blockchain
This documentation is subject to update for newer updates please refer to Plausible FAQ
Plausible is W3C Compliant DIDs, Verifiable Credentials, OpenBadges, and smart utility NFTs protocol built on Algorand.
Plausible links
top↑
Plausible concept:
top↑
GoPlausible dApp is consisted of a frontend calling an Algorand ASC system in which ASCs use each other via inner transactions and C2C calls.
Plausible protocol fully complies to ARC3 and ARC4 standards on Algorand as well as ARC13 and ARC113 proposed and heavily used internally by GoPlausible.
Plausible technical design:
top↑
Plausible features :
Geo constraint option (Geofencing using connecting ISP country and allow and ban lists ).
Authorization Signature constraint option (Author must sign the release before Plausible issuance for claimed claimers).
Shared Secret constraint option (Claimer must scan a QRCode during calling the Plausible Item ASC with it in order to claim successfully).
Dynamic NFTs per Plausible item (Plausible is 100% token-less and NFTs are generated and owned by Plausible item contract and that belongs to Plausible item's author).
Plausible is consisted of a frontend and smart contracts on Algorand chain:
Frontend
Smart Contracts
Plausible frontend has 3 major functions (all in a single view for simplicity):
Wallet Session
Author UI
Claim UI
Note: Frontend will be available through both cloudflare (heavily distributed on edge) and IPFS to ensure decentralization (with transparent routing for best UX).
Author's Journey:
top↑
1- Author easily gets onboard by opting into Plausible's parent ASC.
2- Then can create a new Plausible venue.
3- Then activate the venue to let claims begin (This differs than start time option of Plausible).
Note : If SIG is not enabled for Plausible Venue, Claim approval will send Plausible NFT or TXN to Claimer's wallet but if SIG is enabled then after signing of Author, Plausible NFT or TXN will be sent automatically to Claimer's wallet, after author signs and sends a release method call transaction to release all successfully claimed Plausible Claimer.
Options available for Plausible creation:
Time (default enabled): Start time check (compared to LatestTimestamp)
Geo: Country allow and ban lists.
Signature: Author's signature is needed to make Plausible claimable for every Claimer, individually. Each and every Claimer can receive their single claimed Plausible (in NFT or TXN depending on Plausible config) only after Author's authorization via a successful method call (which obviously should happen after both venue activation and venue start time).
QRCode: Upon activation a secret key will be generated and included in a transaction as a method input parameter and this TXN is then communicated by a QRCode in venue location and Claimer scans this QRCode during physical presence and claims (other arguments will be added to this raw transaction object after scan and when claiming).
Note: QRCode feature is still under heavy re-ideation, re-design and re-everything! So please, kindly consider it WIP and FUTURE release functionality!
Claimer's Journey:
top↑
1- Claimer simply gets onboard by opting into parent ASC.
2- Then get a searchable list of Plausible venues and applys to one by opting into it.
3- Then after general venue activation (by author) and by satisfying what Plausible venue options require, claim the Plausible and get Plausible NFT if approved.
Note : If SIG is not enabled for Plausible Venue, Claim approval will send Plausible NFT to Claimer's wallet but if SIG is enabled then after signing of Author, it'l be sent automatically to Claimer's wallet.
Plausible Smart Contracts
top↑
Plausible ASC System is designed on basis of newest TEAL features came with TEAL v 8.0 on AVM8. Plausible Parent contract is created and thereafter every Plausible item is created by this parent contract based on configurations needed.
All methods expenses and fee details are in following table (those not in this table have just normal 1 MinFee):
Note: This section (Fees) is subject to further updates and changes and is work in progress!
Entities Relations:
Lifecycle:
UseCase:
Note: The NoOp calls without args will be rejected with error. This is being examined as a security practice
Plausible ASC TEAL Graph:
top↑
Plausible ASC ABI :
top↑
Note 1: Data fields are global states of Plausible parent smart contract.
Note 2: Fee collection is not included anywhere at this phase of Plausible MVP development but certainly is a priority prior to public TESTNET deployment. It happens on parent smart contract.
Note 3: Author user has all metrics in localState of Plausible Item smart contract and all Authored Plausibles (upt to 16 item) in localState of Plausible smart contract (parent)
Plausible ASC ABI Schema :
top↑
Plausible Item ASC TEAL Graph:
top↑
Plausible ASC ITEM ABI :
top↑
Note 1: Data fields are global states of Plausible item smart contract.
Plausible ASC ITEM ABI Schema :
top↑
Since Plausible is totally decentralized, trustless and permission-less: Every Plausible item author has full authority of the created PLAUS items (Plausible-DAO is coming with dao, voting and governance features in near future, after startup formation. Preferably I will use integration to an already working service with ABI)!
The plaus_contract.json contains the ABI Schema for parent Plausible contract and plaus_item_contract.json is the full ABI Schema of Plausible item contract which will be created via an inner transaction.
Last updated