diff --git a/404.html b/404.html index 9f61386722c..2b488fba73d 100644 --- a/404.html +++ b/404.html @@ -4,13 +4,13 @@ Page Not Found | Web3 Foundation Grants - +
Skip to main content

Page Not Found

We could not find what you were looking for.

Please contact the owner of the site that linked you to the original URL and let them know their link is broken.

- + \ No newline at end of file diff --git a/CODE_OF_CONDUCT.html b/CODE_OF_CONDUCT.html index 07f3dfb7525..533a8a4c486 100644 --- a/CODE_OF_CONDUCT.html +++ b/CODE_OF_CONDUCT.html @@ -4,7 +4,7 @@ Contributor Covenant Code of Conduct | Web3 Foundation Grants - + @@ -59,7 +59,7 @@ enforcement ladder.

For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.

- + \ No newline at end of file diff --git a/applications.html b/applications.html index 90deb8fdb36..5058e4df367 100644 --- a/applications.html +++ b/applications.html @@ -4,13 +4,13 @@ Accepted Grant Applications | Web3 Foundation Grants - +
Skip to main content

Accepted Grant Applications

Use this page for an overview of all public grants and their status. Use the sidebar to navigate directly to a specific grant application document.

info

This page provides an overview of accepted grant applications, their progress, and a link to their GitHub repositories. In cases where the link points to an organization, you should be aware that the grant application itself is often an independent project unrelated to other work done by the teams.

Furthermore, the page lists terminations that happened due to a breach of the terms of the grants programs. Additionally, teams might have decided to stop working on the grantโ€”though not necessarily on the project itselfโ€”for various reasons, which is not reflected on this sheet.

Besides, there is a clear difference between an application being accepted and the successful delivery of the respective project, and only teams that have successfully delivered a milestone are allowed to make public announcements on the matter or to use our badge. The badge can also never be used as a general endorsement for a team. Violations to this policy can be reported here.

2023โ€‹

๐Ÿ„ Wave 20 - Q4 2023โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
Livetree Community LtdDecentralMLGitHubโ˜โ˜โ˜
LimeChainPolkadot Protocol Conformance Tests ResearchGitHubโ˜โ˜โ˜
KodaDotAssetsHub NFT indexerGitHubโ˜โ˜โ˜
Apollos CollectiveInfimumGitHubโ˜โ˜โ˜
CoinFabrikCoinFabrik On Ink Integration Tests 2GitHubโ˜โ˜โ˜
PlutonicationPlutonicationGitHubโ˜โ˜โ˜
gmajorJsonRpsee socks5 proxyGitHubโ˜โ˜โ˜
ParaSpellSpellRouterGitHubโ˜โ˜โ˜
Paraverse FoundationSignet - TalismanGitHubโ˜โ˜โ˜
Libeccio LabsTux0GitHubโ˜โ˜โ˜

๐Ÿ”

๐Ÿ„ Wave 19 - Q3 2023โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
ProtofireContract WizardGitHubโ˜โ˜โ˜
ZeroDAOMelodotGitHubโ˜โ˜’โ˜’
StarksXCM tool for NFTsGitHubโ˜โ˜โ˜
ChainSafePolkadot Snap MaintenanceGitHubโ˜โ˜โ˜
justmertDOTLY: Revolutionizing Polkadot Account StatisticsGitHubโ˜โ˜’โ˜’
Federico CicciarellaTracking ChainGitHubโ˜โ˜’โ˜
TPScoreTPScoreGitHubโ˜โ˜’โ˜’
Orochi NetworkResearch and development MPC ECDSAGitHubโ˜โ˜’โ˜’
k/factoryOn-Chain Automated Treasury ManagementGitHubโ˜โ˜โ˜
AISLAND DAOAisland DocsigGitHubโ˜โ˜’โ˜’
EigerStorage solution on PolkadotGitHubโ˜โ˜โ˜
Salaheldin SolimanSolang PlaygroundGitHubโ˜โ˜โ˜
P2P.ORGP2P data platformGitHubโ˜โ˜โ˜
CoinFabrikCoinFabrik On Ink Integration TestsGitHubโ˜โ˜’โ˜’
Stake Plus IncTreasury TrackerGitHubโ˜โ˜’โ˜’
MOBR SystemsPolkadot Analytics PlatformGitHubโ˜โ˜’โ˜
Infra3Hyperdot - Powerful data analysis and creations platformGitHubโ˜โ˜โ˜
David Semakulaink! analyzer (phase 2)GitHubโ˜โ˜’โ˜
Myriad Systems LTD.Myriad SocialGitHubโ˜โ˜โ˜
LiisaPolkadot NFT Portfolio TrackerGitHubโ˜โ˜โ˜
NeoPower DigitalRoloi - XCM Payment AutomationGitHubโ˜โ˜โ˜
EigerMoveVM Substrate Pallet, part 2GitHubโ˜โ˜โ˜
Rust Syndicate x DecentrationXCMSendGitHubโ˜โ˜’โ˜
Off Narrative LabsTuxedo Parachain SupportGitHubโ˜โ˜โ˜
PolyCrypt GmbHDistributed Cryptography for Polkadot WalletsGitHubโ˜โ˜โ˜
Open Smart ContractISO20022 PoCGitHubโ˜โ˜’โ˜’
DAOsignDAOsignGitHubโ˜โ˜โ˜
Zondax AGPoC Polkadot Conformance TestsGitHubโ˜โ˜โ˜
SO/DA zoneOcelloids XCM Transfer Monitoring ServiceGitHubโ˜โ˜โ˜
Moonsong LabsStorageHubGitHubโ˜โ˜โ˜
Jonathan BrownHybrid Explorer Phase 2GitHubโ˜โ˜’โ˜
Coong CraftsDelightfulDOTGitHubโ˜โ˜โ˜
LasticLasticGitHubโ˜โ˜โ˜

๐Ÿ”

๐Ÿ„ Wave 18 - Q2 2023โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
InterstellarInterstellar - Wallet Phase 2GitHubโ˜โ˜’โ˜’
Valletech ABDINFRAGitHubโ˜โ˜’โ˜
DAuthDAuthGitHubโ˜โ˜โ˜
Galaxy.DoGalaxy: Three-dimensional Web for Polkadot UsersGitHubโ˜โ˜’โ˜’
Web3 Labs LtdSirato (Epirus) Substrate Explorer - Phase IIIGitHubโ˜โ˜’โ˜’
Collective Intelligence LabsOmnichain InfrastructureGitHubโ˜โ˜’โ˜
TradeLinkSandoxGitHubโ˜โ˜’โ˜
Wunderbar NetworkVue.js + TypeScript Substrate Front-End TemplateGitHubโ˜โ˜โ˜
Profond.aiProfondGitHubโ˜โ˜’โ˜
727.venturesPatronGitHubโ˜โ˜’โ˜’
Supercomputing Systems AGSARP - A Static Analysis Tool for Runtime PalletsGitHubโ˜โ˜’โ˜’
Ed AndersonBlockchainiaGitHubโ˜โ˜โ˜
CoinFabrikScoutCoinFabrik: Milestone 2GitHubโ˜โ˜’โ˜’
Polytope LabsInteroperable State Machine ProtocolGitHubโ˜โ˜’โ˜’
Talentica SoftwareImplementation Benchmarking Milestone 3GitHubโ˜โ˜’โ˜’
Deep Ink Ventures GmbHStylographGitHubโ˜โ˜’โ˜’
ZeeveInk Playground IDE ImprovementsGitHubโ˜โ˜โ˜
Scio LabsXCM Domain Name ServiceGitHubโ˜โ˜’โ˜’
GloslabContracts performance measurement tool proposalGitHubโ˜โ˜’โ˜
Nikita Orlov PRFaucet chat based botGitHubโ˜โ˜’โ˜’
Societal Labs Ltd.Societal Saas PricingGitHubโ˜โ˜’โ˜’
MASTER UNION LLC.DotflowGitHubโ˜โ˜’โ˜’
Antier SolutionsRFP/securityMarketPlaceGitHubโ˜โ˜’โ˜
SO/DA zoneOcelloids Monitoring SDK grant applicationGitHubโ˜โ˜’โ˜’
Antier Solutions Pvt. Ltd.Grants webappGitHubโ˜โ˜’โ˜’
Zaniyar JahanyGrantmasterGitHubโ˜โ˜โ˜
FiDi TechFiDi DotSight: Analytics Data Platform for DotSamaGitHubโ˜โ˜’โ˜
Ideal LabsCryptexGitHubโ˜โ˜’โ˜’
XcavateReal estate centric lending and asset minting protocolGitHubโ˜โ˜’โ˜’
SyncraNo Code DAO Maker and ZK Powered Private Voting SolutionGitHubโ˜โ˜โ˜
P2P.ORGValidator Monitoring ServiceGitHubโ˜โ˜’โ˜’
Colorful NotionDeep Account Analytics in Three Tiers for the Polkadot Data AllianceGitHubโ˜โ˜โ˜
Dastanbek SamatovISO-8553 PoC implementationGitHubโ˜โ˜’โ˜
EigerSubstrate Move System Pallet, pt. 1GitHubโ˜โ˜’โ˜’
DavantiDot-ETL ProjectGitHubโ˜โ˜โ˜
ParaSpellLightSpell: XCM APIGitHubโ˜โ˜’โ˜’

๐Ÿ”

๐Ÿ„ Wave 17 - Q1 2023โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
Deep Ink Ventures GmbHGenesisDAOGitHubโ˜โ˜’โ˜’
ArtZeroArtZero & InkWhaleGitHubโ˜โ˜’โ˜’
EightFishEightFishGitHubโ˜โ˜’โ˜’
ProtofirePolkadot Contract WizardGitHubโ˜โ˜’โ˜’
Runtime VerificationKMIR: the K semantics of MIRGitHubโ˜โ˜’โ˜’
Me ProtocolMe ProtocolGitHubโ˜โ˜โ˜
Comrade CoopValidated StreamsGitHubโ˜โ˜’โ˜’
BlockcodersKuma Cross-chain WalletGitHubโ˜โ˜’โ˜’
OmniBTCPolkadot Smart ChainGitHubโ˜โ˜’โ˜’
ChainSafeMultix - a simple interface to use complex multisigsGitHubโ˜โ˜’โ˜’
Composable Finance LTDCosmWasm VMGitHubโ˜โ˜’โ˜
Asyoume incDao-entrance: online collaboration tool for web3GitHubโ˜’โ˜’โ˜
Talentica Softwareink!/pallet/solidity performance benchmarkingGitHubโ˜โ˜’โ˜’
Societal Labs Ltd.Societal - MVP - Phase 2GitHubโ˜โ˜’โ˜’
Omniverse LabsOmniverse DLTGitHubโ˜โ˜’โ˜’
MOBR SystemsKnowledge Oriented FrameworkGitHubโ˜โ˜’โ˜’
Aviraj KharePolkasearchGitHubโ˜โ˜โ˜
gmajorPHP RPC Lib Follow upGitHubโ˜โ˜’โ˜’
CoinFabrikScout - Security Analysis ToolGitHubโ˜โ˜’โ˜’
727.venturesTypechain-Polkadot Follow-up-2GitHubโ˜โ˜’โ˜’
Mark Van de Vyver PhD(Dist)Substrate Tokenomics SurveyGitHubโ˜โ˜’โ˜
ZeeveParachain deployment zoombienet testing automationGitHubโ˜โ˜’โ˜’
Polytope LabsTrie Verifier ImplementationGitHubโ˜โ˜’โ˜’
Off-Narrative LabsTuxedoGitHubโ˜โ˜’โ˜’
FuzzLandFuzzLandGitHubโ˜โ˜โ˜
FuuAnchor, On-chain Linked List pallet and Name ServiceGitHubโ˜โ˜’โ˜’
hack-inkSlothunterGitHubโ˜โ˜’โ˜’
Invers IncZkwasm Rollups TransferGitHubโ˜โ˜’โ˜
decentraDOTCyclops Validator DashboardGitHubโ˜โ˜’โ˜’
Anwesh NayakMempool Dashboard - Version 2GitHubโ˜โ˜โ˜
Tellor IncTellor Oracle ProtocolGitHubโ˜โ˜’โ˜
Jonathan BrownHybrid ExplorerGitHubโ˜โ˜’โ˜’
ParaSpellParaSpell_Follow Up 2GitHubโ˜โ˜’โ˜’
justmertPolkaFlowGitHubโ˜โ˜’โ˜’
BelSoftDiffy messengerGitHubโ˜โ˜’โ˜’
ZkverseZkverseGitHubโ˜โ˜โ˜
Taiwan Research-based Biopharmaceutical Manufacturers AssociationClaps HealthGitHubโ˜โ˜โ˜
Tolga YaycฤฑAwesome PolkaGitHubโ˜โ˜’โ˜’
gmajorXCM ToolsGitHubโ˜โ˜’โ˜’
David Semakulaink! AnalyzerGitHubโ˜โ˜’โ˜’
Bright InventionsHigh-availability validator setupGitHubโ˜โ˜’โ˜’
DIA DataBridgestate Attestation OracleGitHubโ˜โ˜’โ˜’
TogetherCrewCommunity Health CheckGitHubโ˜โ˜’โ˜
DecentrationSupersig Phase 2GitHubโ˜โ˜’โ˜’
Polkadrys LabsOpen PayrollGitHubโ˜โ˜’โ˜
IteringSolidity Verifier Implementation for Accountable Light ClientGitHubโ˜โ˜’โ˜’

๐Ÿ”

2022โ€‹

๐Ÿ„ Wave 16 - Q4 2022โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
CrossChain LabsDotPulseGitHubโ˜โ˜’โ˜’
Jett HaysDistributed Key ManagementGitHubโ˜โ˜’โ˜’
NexToken TechnologyTREX - Timed Release Encryption Xing chainsGitHubโ˜โ˜’โ˜’
BlockcodersCross-Consensus Messaging Software Development KitGitHubโ˜โ˜’โ˜’
Keystone WalletPolkadot SnapGitHubโ˜โ˜โ˜
LeetCoinLeetCoinGitHubโ˜โ˜โ˜
727.venturesSol2Ink Phase 2GitHubโ˜โ˜’โ˜’
walt.idNFT infrastructureGitHubโ˜โ˜’โ˜’
SydTekDigital Inheritance in Web3: A Case Study of Soulbound Tokens and Social Recovery PalletsGitHubโ˜โ˜’โ˜
AnagolayMulti-token community contributions for verified creatorsGitHubโ˜โ˜’โ˜’
Ink Contracts Wizard TeamInk Smart Contract WizardGitHubโ˜โ˜’โ˜’
TDSoftwareSubstrate IPFS UtilitiesGitHubโ˜โ˜’โ˜’
Ink Boxes TeamInk BoxesGitHubโ˜โ˜’โ˜’
ParaSpellParaSpell Phase 2GitHubโ˜โ˜’โ˜’
SubRelaySubRelayGitHubโ˜โ˜’โ˜’
Wow LabzDot Marketplace Phase 3GitHubโ˜โ˜’โ˜’
10Clouds Sp. z o.o.Crowdloan Front End TemplateGitHubโ˜โ˜’โ˜’
DodoRare, Inc.FateriumGitHubโ˜โ˜’โ˜’
The Bacon BeaconPallet Drand ClientGitHubโ˜โ˜’โ˜
Helikon LabsChainViz v1GitHubโ˜โ˜’โ˜
Mutai SolutionsCrowdloans-FETGitHubโ˜โ˜โ˜
k/factoryCentrifuge Go-Substrate-RPC Client V2GitHubโ˜โ˜โ˜
Colorful NotionZombienet Explorer: Multi-Chain Substrate Block ExplorerGitHubโ˜โ˜โ˜
TwinPDecentralized InvoiceGitHubโ˜โ˜’โ˜’
ZondaxHybrid node research grantGitHubโ˜โ˜’โ˜’
Bright InventionsZK-Snarks TutorialGitHubโ˜โ˜’โ˜’
Common Orbit LLCwasm-opt-for-rust maintenanceGitHubโ˜โ˜’โ˜
Salaheldin SolimanSolang developer experience improvementsGitHubโ˜โ˜’โ˜’
Optymalizacja AI Grzegorz MiebsValidator selectionGitHubโ˜โ˜’โ˜’
Applied Blockchain LtdSilent DataGitHubโ˜โ˜’โ˜’
Web3Box LabsWeb3BoxGitHubโ˜โ˜’โ˜’
LimeChainResearch feasibility of Polkadot Host in JavaGitHubโ˜โ˜’โ˜’
Blaize.techUnified deployment for the collator nodeGitHubโ˜โ˜’โ˜’
Odyssey B.V.Momentum, an open source, metaverse for digital societiesGitHubโ˜โ˜โ˜
Bela SupernovaRubeus Keeper Stage 2GitHubโ˜โ˜’โ˜’
Coong TeamCoong WalletGitHubโ˜โ˜’โ˜’
OCamlMyCamlPrivaDEX: Cross-Chain DEX Aggregator MVPGitHubโ˜โ˜’โ˜’
Aband-NetworkSubstrate Parachain PoS TemplateGitHubโ˜โ˜’โ˜’
MangoBOX labsMangoSale ProtocolGitHubโ˜โ˜’โ˜’

๐Ÿ”

๐Ÿ„ Wave 15 - Q3 2022โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
QRUCIAL OรœQRUCIAL DAOGitHubโ˜โ˜’โ˜’
Polkadot js plusPolkadot js plus / Social Recovery WalletGitHubโ˜โ˜’โ˜
LeeHex Space Social GraphGitHubโ˜โ˜’โ˜
Liberland LLCLiberland PalletsGitHubโ˜โ˜’โ˜’
Standard ProtocolSignac - a monorepo plugin for developing multiple Parity ink! smart contractsGitHubโ˜โ˜’โ˜’
B-DatagrayDatagen ProjectGitHubโ˜โ˜’โ˜
Colorful NotionPolkaholic.io's Multi-Chain Substrate Block ExplorerGitHubโ˜โ˜โ˜
Common Orbit LLCwasm-opt for RustGitHubโ˜โ˜’โ˜’
BlockcodersInk ExplorerGitHubโ˜โ˜’โ˜’
EquilibriumPolkadot Light Client in C++GitHubโ˜โ˜’โ˜’
Open rollupOpen rollup - MVP - Phase 1GitHubโ˜โ˜โ˜
VeridiseVanguardGitHubโ˜โ˜โ˜
Karolis RamanauskasGeneric Sybil-Resistant FaucetGitHubโ˜โ˜’โ˜’
LimeChainResearch feasibility for a Go RuntimeGitHubโ˜โ˜’โ˜’
Jim YamdaosGitHubโ˜โ˜’โ˜’
Green LemonGreen Lemon ProtocolGitHubโ˜โ˜’โ˜’
Stardust Labs Inc.Integrating ISO-8583GitHubโ˜โ˜’โ˜’
TwinPEscrow PalletGitHubโ˜โ˜’โ˜’
Meta Defender TeamMeta DefenderGitHubโ˜โ˜โ˜
ParaSpellParaSpellGitHubโ˜โ˜’โ˜’
Primis LabsPrimisGitHubโ˜โ˜’โ˜’
UkeUke Messaging - PoC - Phase 1GitHubโ˜’โ˜โ˜
Redstone NetworkRedstone NetworkGitHubโ˜โ˜’โ˜
JURIMETRIC TECNOLOGIA LTDAPolkadartGitHubโ˜โ˜’โ˜’
Skye KiwiChoko WalletGitHubโ˜โ˜’โ˜’
Popular CodingVenturGitHubโ˜โ˜’โ˜’
AsylumAsylum follow-up 1GitHubโ˜’โ˜’โ˜
Cyril CarlierMakiGitHubโ˜โ˜โ˜
TopMonksCalamarGitHubโ˜โ˜’โ˜
Bela SupernovaRubeus KeeperGitHubโ˜โ˜’โ˜’
Web3 Labs LtdEpirus Substrate Explorer - Phase 2GitHubโ˜โ˜’โ˜’
UkeUke Protocol PoC & App (revised)GitHubโ˜โ˜’โ˜’
727.venturesTypechain Phase 2GitHubโ˜โ˜’โ˜’
QSTNQSTNGitHubโ˜โ˜โ˜
CESS LABSubstats (The framework of lightweight block explorer)GitHubโ˜โ˜’โ˜’
PolketToEarnFunGitHubโ˜โ˜’โ˜’
ALPHA LABSBinary merkle treeGitHubโ˜โ˜’โ˜
Standard ProtocolNew Order - a full onchain orderbook dex with indexersGitHubโ˜’โ˜โ˜
hack-inkSubalfredGitHubโ˜โ˜’โ˜’

๐Ÿ”

๐Ÿ„ Wave 14 - Q2 2022โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
TDSoftwareSubIdentityGitHubโ˜โ˜’โ˜’
ChainSafe SystemsSubstrateSnap Maintenance ProposalGitHubโ˜โ˜’โ˜’
HugoByteProject Aurras - MVP - Phase 2GitHubโ˜โ˜’โ˜
Perun NetworkPerun App ChannelsGitHubโ˜โ˜’โ˜’
ChainSafe SystemsPrivacy enhancement for Polkadot-js extensionGitHubโ˜โ˜’โ˜’
BQPQuantum Lock for QBITCOINGitHubโ˜โ˜โ˜
Simply VCPANIC Monitoring and Alerting For BlockchainsGitHubโ˜โ˜’โ˜’
Artree LLCZero NetworkGitHubโ˜โ˜โ˜
sigma primeDifferential FuzzerGitHubโ˜โ˜โ˜
t3rnXBI - xcm-based high-level standard and interface (ABI) for smart contractsGitHubโ˜โ˜’โ˜’
Dante NetworkDante NetworkGitHubโ˜โ˜’โ˜’
VeridaSingle Sign-On for AppsGitHubโ˜โ˜โ˜
Kami EkbatanifardPolkadot js plus / Nomination poolsGitHubโ˜โ˜’โ˜’
Afloat IncTax Infrastructure Polkadot IntegrationGitHubโ˜โ˜’โ˜’
gmajorSCALE Codec ComparatorGitHubโ˜โ˜’โ˜’
Rusty CrewmatesSubstrate TutorialsGitHubโ˜โ˜’โ˜’
SequesterA Common-Good Carbon Sink on PolkadotGitHubโ˜โ˜’โ˜’
Keysafe NetworkA decentralized protocol for private key custody and crypto asset managementGitHubโ˜’โ˜’โ˜
Fennel LabsWhiteflag on Fennel ProtocolGitHubโ˜โ˜’โ˜’
RelationlabsRelation GraphGitHubโ˜โ˜โ˜
DecentrationSupersigGitHubโ˜โ˜’โ˜’
Web3 Labs LtdEpirus Substrate ExplorerGitHubโ˜โ˜’โ˜’
727.venturesSol2InkGitHubโ˜โ˜โ˜
727.venturesOpenBrush Phase 3GitHubโ˜โ˜’โ˜’
FSFair SquaresGitHubโ˜โ˜’โ˜’
Ideal LabsIris: Phase 2GitHubโ˜โ˜’โ˜
NeoPowerRoloi: Stream money from one wallet to anotherGitHubโ˜โ˜’โ˜’
Tribal Protocol LabsTribal Protocol Smart Contract DevelopmentGitHubโ˜โ˜’โ˜
Yahuang WuDual-Key Stealth Address ProtocolGitHubโ˜โ˜’โ˜’
UNIVERSALDOT FOUNDATIONUniversaldot.me Phase 2GitHubโ˜’โ˜โ˜
Societal Labs Ltd.Societal - MVP - Phase 1GitHubโ˜โ˜’โ˜’
Faceless ProtocolFaceless ProtocolGitHubโ˜โ˜’โ˜’
727.venturesTypechainGitHubโ˜โ˜’โ˜’
CodelightMassbit RouteGitHubโ˜โ˜’โ˜’
Hypha Hashed PartnersSocial Recovery WalletGitHubโ˜โ˜’โ˜’
MangoBOX labsMangoBOX ProtocolGitHubโ˜โ˜’โ˜’

๐Ÿ”

๐Ÿ„ Wave 13 - Q1 2022โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
ChainifyNolikGitHubโ˜โ˜’โ˜’
Pennsylvania State UniversityAvoiding Rust Deadlocks via Lifetime VisualizationGitHubโ˜โ˜’โ˜’
AnagolayProject IdiyanaleGitHubโ˜โ˜’โ˜’
Fennel LabsFennel ProtocolGitHubโ˜โ˜’โ˜’
Valletech ABPolkawatchGitHubโ˜โ˜’โ˜’
EzCodePolkadot.js NoCode PluginGitHubโ˜โ˜’โ˜’
Virto NetworkLIP payments palletGitHubโ˜โ˜’โ˜’
Kami EkbatanifardPolkadot.js Plus ExtensionGitHubโ˜โ˜’โ˜’
Dora FactoryMultisig UIGitHubโ˜โ˜’โ˜’
BlackprintIntegrating Polkadot.js with BlackprintGitHubโ˜โ˜’โ˜’
OpenSquare NetworkOpenSquare Paid QA protocolGitHubโ˜โ˜’โ˜’
@Scale TechnologiesLibra - Decentralized Payment NetworkGitHubโ˜โ˜’โ˜’
InterstellarInterstellar - Wallet Phase 1GitHubโ˜โ˜’โ˜’
PendulumSpacewalk: a Stellar bridgeGitHubโ˜โ˜’โ˜
Dmitrii KoshelevImplementation of the new hash function to BLS12 curvesGitHubโ˜โ˜’โ˜’
HamsterHamster - A decentralized computing networkGitHubโ˜โ˜’โ˜’
Papers GmbHZaturn - A Generic Attestable Oracle parachain Phase 1GitHubโ˜โ˜’โ˜’
SlonigirafSLON - a recommendation letter systemGitHubโ˜โ˜’โ˜’
HelixstreetHelixstreet ModuleGitHubโ˜’โ˜โ˜
CryptovietGafi Network - The Network of Game FinanceGitHubโ˜โ˜’โ˜’
AsylumMetaverse for next generation gamingGitHubโ˜โ˜’โ˜’
CESS LABData Store PalletGitHubโ˜โ˜’โ˜’
ChainSafeSubstrate Core PolywrapperGitHubโ˜โ˜’โ˜’
Bela SupernovaOn-chain cash exchange (OCEX)โ˜โ˜’โ˜’
Second StateWasmEdge for SubstrateGitHubโ˜โ˜’โ˜
Wow LabzDot Marketplace Phase 2GitHubโ˜โ˜’โ˜’
Stardust Labs Inc.Uncollateralized Stablecoin Research and DesignGitHubโ˜โ˜’โ˜’
Hashed SystemsNative Bitcoin Vaults (NBV)GitHubโ˜โ˜’โ˜’
SetheumSetheum HighEnd LaunchPad Crowdsales ModuleGitHubโ˜โ˜โ˜
SaaS3 LabSaaS3GitHubโ˜โ˜’โ˜’
NUTS FinanceDOT-pegged derivative built on top of the stable asset protocolGitHubโ˜’โ˜’โ˜
Strategy ObjectSubstrate Client for JavaGitHubโ˜โ˜’โ˜

๐Ÿ”

2021โ€‹

๐Ÿ„ Wave 12 - Q4 2021โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
Matthew DarnellcScaleGitHubโ˜โ˜’โ˜
Web3goWeb3goGitHubโ˜โ˜’โ˜’
Prosopo LimitedProsopo: Human Verification MarketplaceGitHubโ˜โ˜’โ˜’
LitentryPolka SignInGitHubโ˜โ˜โ˜
gmajorPHP RPC LibGitHubโ˜โ˜’โ˜’
logionLogion walletGitHubโ˜โ˜’โ˜’
727.venturesOpenBrush - Secure smart-contract development on ink! Phase 2GitHubโ˜โ˜’โ˜
Nitor InfotechPhp substrate apiGitHubโ˜โ˜’โ˜’
@agryaznovCandle Auctions on Ink!GitHubโ˜โ˜’โ˜’
Iridium IndustriesIris: Decentralized storage network for substrate-based chainsGitHubโ˜โ˜’โ˜’
DICO TeamDICO: Decentralized and governable ICO platformGitHubโ˜โ˜โ˜
DodoRare, Inc.Crossbow - Cross-Platform Rust Toolkit for GamesGitHubโ˜โ˜’โ˜’
Rainbowcity FoundationRainbowDAO Protocol ink! Phase 1GitHubโ˜โ˜’โ˜’
Web Registry DAOWika NetworkGitHubโ˜โ˜’โ˜
Helikon LabsSubVT Telegram Bot for Kusama and PolkadotGitHubโ˜โ˜’โ˜’
Elamin LTDImbue NetworkGitHubโ˜โ˜’โ˜’
Koi MetaverseBuilding the Digital Collectibles Platform for Virtual GameFi NFTsGitHubโ˜โ˜โ˜
Health HeroDecentralized Well-being Game APIGitHubโ˜โ˜โ˜
UNIVERSALDOT FOUNDATIONA freelancing decentralized applicationGitHubโ˜’โ˜’โ˜
AdMetaA privacy-preserving Ad PlatformGitHubโ˜โ˜’โ˜’
Crypto Pay Lab (CPL))Dotpay a github paid task platform using DOTGitHubโ˜โ˜’โ˜’

๐Ÿ”

๐Ÿ„ Wave 11 - Q3 2021โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
PawnNuLinkGitHubโ˜โ˜’โ˜’
Cyril CarlierPolk-Auction WebsiteGitHubโ˜โ˜’โ˜’
UddugJuniDB - Peer-to-Peer DatabasesGitHubโ˜’โ˜โ˜
Canyon LabsPermanent decentralized storage Phase 2GitHubโ˜โ˜’โ˜’
Skynet LabsPallet for Decentralized Off-Chain Storage on SkynetGitHubโ˜โ˜’โ˜’
Uniwrap/1001 GroupProject 1001GitHubโ˜โ˜โ˜
YibanChenNotes DApp & Site-PalletGitHubโ˜โ˜’โ˜
727.venturesOpenBrush - Secure smart-contract development on ink!GitHubโ˜โ˜’โ˜’
Banksy FinanceNFT Pool-Based Lending HubGitHubโ˜โ˜โ˜
SubDAO LabsPolkaSign - Web3.0 app for electronic agreementsGitHubโ˜โ˜’โ˜’
ValibrePeople Local Interactions Protocol (PLIP)GitHubโ˜โ˜โ˜
ReauditoShivarthu: A blockchain-based decentralized governance systemGitHubโ˜โ˜’โ˜
UniscanNFT ExplorerGitHubโ˜โ˜’โ˜’
LimeChainSubsembly - Support for GRANDPAGitHubโ˜โ˜’โ˜’
OpenSquareOff-chain voting platformGitHubโ˜โ˜’โ˜’
Health HeroNFT Product Analytics Suiteโ˜โ˜โ˜
TesseractMobile dApps/Wallet ConnectionGitHubโ˜โ˜’โ˜’
Wow LabzDot MarketplaceGitHubโ˜โ˜’โ˜’
Perun NetworkPerun Channels - Integration with go-perunGitHubโ˜โ˜’โ˜’
InvArchitectsInvArch - IP Infrastructure for SubstrateGitHubโ˜โ˜’โ˜’
SubGame NetworkA decentralized game platform Phase 2GitHubโ˜โ˜’โ˜’
CESS LABCumulus Encrypted Storage System (CESS)GitHubโ˜โ˜’โ˜’
CheersLand LabsMulti-game Platform for Polkadot & KusamaGitHubโ˜โ˜โ˜
UNI-ARTSRuby Substate ClientGitHubโ˜โ˜’โ˜
Skye KiwiSkyeKiwi ProtocolGitHubโ˜โ˜’โ˜’
EvercitySustainable Finance ProtocolGitHubโ˜โ˜’โ˜’

๐Ÿ”

๐Ÿ„ Wave 10 - Q2 2021โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
GamePowerNFT Collectibles WalletGitHubโ˜โ˜’โ˜
Subspace LabsProof-of-Capacity Consensus for SubstrateGitHubโ˜โ˜’โ˜’
ChainSafeGo implementation of CumulusGitHubโ˜โ˜โ˜
PolkadottersSubauctionGitHubโ˜โ˜’โ˜’
Phala NetworkOpen Node FrameworkGitHubโ˜โ˜โ˜
Ruby ProtocolCryptographic Infrastructure for Data MonetizationGitHubโ˜โ˜’โ˜’
Find Signal Studio PTE. LTD.YieldScan Phase 2GitHubโ˜โ˜’โ˜’
PolkaMusicOperating decentralized music businesses on blockchainGitHubโ˜โ˜’โ˜
element36FIAT on-off-rampGitHubโ˜โ˜’โ˜’
ZondaxLedger Asset AppGitHubโ˜โ˜’โ˜’
Moonbeam NetworkPallet-dPoS for Parachain StakingGitHubโ˜โ˜’โ˜’
Dora FactoryMolochDAO substrate pallets v1 and v2GitHubโ˜โ˜’โ˜’
BCANNBlockchain system for Assigned Names And NumbersGitHubโ˜โ˜โ˜
MyBank LabsPlatform Bank, Social Network Bank, MyDeX and Credit Scoring SystemGitHubโ˜โ˜โ˜
ChainBridge NetworkDoter: A browser extension wallet for PolkadotGitHubโ˜โ˜’โ˜’
SubDAO LabsSubDAO Chrome ExtensionGitHubโ˜โ˜’โ˜’
Sukhavati LabsSukhavati PoC ModuleGitHubโ˜โ˜โ˜
HypeLabs Inc.UpLink - Decentralized and infrastructure-free approach to peer-to-peer connectivityGitHubโ˜โ˜โ˜
Jackson Harris IIIStaking Rewards ViewerGitHubโ˜โ˜’โ˜’
KlevoyaWASM Smart Contract FuzzerGitHubโ˜โ˜โ˜
Perun NetworkPerun ChannelsGitHubโ˜โ˜’โ˜’
NewOmegaA blockchain game that cannot be shut down (Milestone 3 and 4)GitHubโ˜โ˜’โ˜’
Webb TechWebb Mixer ExtendedGitHubโ˜โ˜’โ˜’
AjunaUnitySDK for SubstrateGitHubโ˜โ˜’โ˜’
Canyon LabsPermanent decentralized storageGitHubโ˜โ˜’โ˜’
ZeroDAO NetworkDecentralised reputation systems and social networksGitHubโ˜โ˜’โ˜’
Stake TechnologiesZK Plonk PalletGitHubโ˜โ˜’โ˜’
CryptoLabStaking Reward CollectorGitHubโ˜โ˜’โ˜’
Yatima IncLambda-VM and programming language for SubstrateGitHubโ˜โ˜’โ˜’

๐Ÿ”

๐Ÿ„ Wave 9 - Q1 2021โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
ZenlinkCross-chain DEXGitHubโ˜โ˜โ˜
NFTT StudioNFT Store Pallet and Front EndGitHubโ˜โ˜’โ˜’
SubGame NetworkA decentralized game platformGitHubโ˜โ˜’โ˜’
ParamiBlockchain-empowered advertising allianceGitHubโ˜โ˜โ˜
Sunrise ProtocolSunrise DEXGitHubโ˜โ˜โ˜
CoboCobo Vault Phase 2GitHubโ˜โ˜’โ˜
OxyDevSubsCrypt: Managing subscriptionsGitHubโ˜โ˜’โ˜’
DNFT-TeamData framework between personal data and AI modelsGitHubโ˜โ˜โ˜
UMC LabsSecured token subscriptionGitHubโ˜โ˜โ˜
Perpetual Altruism LtdIP-Rights compliant NFT bridge protocolGitHubโ˜โ˜โ˜
CloverEasy-to-use blockchain infrastructureGitHubโ˜’โ˜’โ˜
DoraHacksQuadratic Funding PalletGitHubโ˜โ˜’โ˜’
SEORMulti-chain smart contract development platformGitHubโ˜โ˜’โ˜
PolkastarterCrowdloan UIGitHubโ˜’โ˜โ˜
Equilibrium.ioCurve AMM PalletGitHubโ˜โ˜’โ˜’
ZondaxLedger maintenance + recovery extensions + supportGitHubโ˜โ˜’โ˜’
Nuclei StudioVoting PalletsGitHubโ˜โ˜’โ˜’
RAMP DEFIPolkakeeper - A Community-Led Value Assurance ProtocolGitHubโ˜โ˜โ˜
StoneIndex project which aims to track the portfolio of multiple digital assetsGitHubโ˜โ˜’โ˜’
Reserve LabsAlgoCash - An algorithmic stablecoinGitHubโ˜โ˜’โ˜’
gmajorPHP Scale CodecGitHubโ˜โ˜’โ˜’
Trust Fractal GmbHink! Smart Contract UpgradeabilityGitHubโ˜โ˜’โ˜’
Starry NetworkSplittable NFTsGitHubโ˜โ˜’โ˜’
EquilibriumResearch Storage NetworkGitHubโ˜โ˜’โ˜’
AjunaSubstrate .NET APIGitHubโ˜โ˜’โ˜’
NewOmegaA blockchain game that cannot be shut downGitHubโ˜โ˜’โ˜’
Bright InventionsTreasury Web applicationGitHubโ˜โ˜’โ˜’
Standard protocolA collateralized algorithmic stablecoin protocol for synthetic assetsGitHubโ˜โ˜’โ˜
Skye KiwiSkyePass: A decentralized, open source password managerGitHubโ˜โ˜’โ˜
RidOne TechnologiesPolkadot UI Web + Angular IdenticonGitHubโ˜โ˜’โ˜’
ZeropoolPrivate transactions on Polkadot Phase 2GitHubโ˜โ˜’โ˜’
OAK FoundationQuadratic Funding Module and Dapp ApplicationGitHubโ˜โ˜’โ˜’
Commonwealth LabsWebb MixerGitHubโ˜โ˜’โ˜’
TEA ProjectGluon - Decentralized Hardware Crypto Wallet ServicesGitHubโ˜โ˜’โ˜
Cycan TechnologiesEverlasting Cash: A hybrid of a crypto-collateralized and an algorithmic stablecoinGitHubโ˜โ˜โ˜
Shard LabsSubstrate Identity DirectoryGitHubโ˜โ˜’โ˜
LumenaA blockchain based EV charging platformGitHubโ˜โ˜’โ˜’
DEGOTreasureland: An NFT publishing and trading platformGitHubโ˜โ˜โ˜
AIKONChainJS integrationGitHubโ˜โ˜โ˜
Nathan SchwermannPolkaJ Android SupportGitHubโ˜โ˜’โ˜
Acalaxtokens - XCM Implementation for Fungible AssetsGitHubโ˜โ˜’โ˜’
NUTS FinanceStable AssetGitHubโ˜โ˜’โ˜’
MVP Workshoppallet-maci (Minimal Anti Collusion Infrastructure)GitHubโ˜โ˜โ˜
X-PredictDecentralized prediction marketGitHubโ˜โ˜โ˜
ChevdorSRTOOL AppGitLabโ˜โ˜’โ˜’
Bit.CountryA decentralized world - Phase 2GitHubโ˜โ˜’โ˜’
VeraNFT Lending + ExchangeGitHubโ˜โ˜’โ˜’
Parallel FinanceDecentralized lending/borrowing and staking protocolGitHubโ˜โ˜’โ˜’

๐Ÿ”

2020โ€‹

๐Ÿ„ Wave 8 - Q4 2020โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
Sean YoungSolidity to WASM compiler Phase 2GitHubโ˜โ˜’โ˜’
Nuclei StudioGovernance OSGitHubโ˜โ˜’โ˜’
NBLTrustDart SCALE CodecGitHubโ˜โ˜’โ˜’
Nsure.NetworkOpen Insurance Platform for Open FinanceGitHubโ˜โ˜’โ˜
Kylin NetworkCross-chain Platform for the Data EconomyGitHubโ˜โ˜’โ˜’
Bit.CountryA decentralized worldGitHubโ˜โ˜’โ˜’
MIDL.devPolkashots.io: Snapshot website for Polkadot and KusamaGitHubโ˜โ˜’โ˜’
Ares ProtocolDecentralized Oracle ProtocolGitHubโ˜โ˜’โ˜’
SaitoPolkadot Gaming Protocol and LibraryGitHubโ˜โ˜’โ˜
LimeChainSubsembly: Framework for building AssemblyScript RuntimesGitHubโ˜โ˜’โ˜
WificoinPESA: On-ramp/off-ramp to crypto/local currencies for Polkadotโ˜โ˜โ˜
WalletConnectOpen protocol for connecting Wallets to DappsGitHubโ˜โ˜’โ˜
Citadel.oneNon-custodial Proof-of-Stake platformโ˜โ˜’โ˜’
Geometry LabsLoad Balanced Endpoints Phase 2GitHubโ˜โ˜’โ˜’
MAP labsMap Bridge: Connect Polkadot and other PoW chainsGitHubโ˜’โ˜โ˜
RareLinkDynamic non-fungible token (NFT) ProtocolGitHubโ˜โ˜โ˜
Cere NetworkTurnkey Private Blockchain NetworkGitHubโ˜โ˜’โ˜’
SubDAO LabsSubDAO is a Cross-chain Platform to link DAO and DApp on PolkadotGitHubโ˜โ˜’โ˜’
Idavoll NetworkDecentralized organization platformGitHubโ˜โ˜’โ˜’
ZenlinkDEX Ink! smart contractGitHubโ˜โ˜โ˜
SetheumSetheum Elastic Reserve ProtocolGitHubโ˜’โ˜โ˜
EverstakeDKG msig walletGitHubโ˜โ˜โ˜
CoinversationDecentralized exchange for trading synthetic assetsGitHubโ˜’โ˜โ˜
Manta NetworkA Privacy Preserving Decentralized ExchangeGitHubโ˜โ˜’โ˜
Stake TechnologiesZK Rollups PalletGitHubโ˜โ˜’โ˜
Apron NetworkDecentralized infrastructure providerGitHubโ˜โ˜’โ˜’
Pocket 4DSubstrate Dart API clientGitHubโ˜โ˜’โ˜
ListenDecentralized social network focusing on soundGitHubโ˜’โ˜โ˜
ProtofirePolkadot Mempool ExplorerGitHubโ˜โ˜’โ˜’
Fuzhou Wakanda Information TechnologyBlack Diamond WalletGitHubโ˜โ˜โ˜
KonomiPool Lending ModuleGitHubโ˜โ˜’โ˜’
AcalaBodhi:Composable & Innovative Stack for EVMGitHubโ˜โ˜’โ˜’
Pontem NetworkMove smart contract palletGitHubโ˜โ˜’โ˜’
SpiderDAOHardware-based DAO governanceGitHubโ˜โ˜โ˜
onfinalitySubquery: Open-source tool to process and query dataGitHubโ˜โ˜’โ˜’
FOS Foundation LTDPacific store: OpenSea.js on polkadotGitHubโ˜โ˜’โ˜
Polkadot Technology AllianceShadows Network: synthetic assetsGitHubโ˜’โ˜’โ˜
BLDG BLOXESG (Environmental, Social, and Corporate Governance) ratings dashboardGitHubโ˜โ˜โ˜
DEIPWORLDIP Management/Governance ModuleGitHubโ˜โ˜’โ˜
Deeper.NetworkMicropayments palletGitHubโ˜โ˜’โ˜’
EvanescoPrivate network protocolGitHubโ˜โ˜’โ˜’
HugoByteProject Aurras: Event ManagerGitHubโ˜โ˜’โ˜’
Bounce ProtocolDecentralized Auction ProtocolGitHubโ˜โ˜โ˜

๐Ÿ”

๐Ÿ„ Wave 7 - Q3 2020โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
HalvaA toolchain for improving the experience of developing Decentralized Applications based on SubstrateGitHubโ˜โ˜’โ˜’
SubscanSubstrate explorerGitHubโ˜โ˜’โ˜’
t3rnA protocol for blockchain interoperabilityGitHubโ˜โ˜’โ˜’
Stake TechnologiesHardware ECDSA for Polkadot JSGitHubโ˜โ˜’โ˜’
ProtofireFailover mechanism for validators upgradeGitHubโ˜โ˜’โ˜
DappForceSubSocial Chapter 2GitHubโ˜โ˜’โ˜’
OpenSquare NetworkA blockchain based crowdsourcing and reputation platformGitHubโ˜โ˜’โ˜’
CardinalsThreshold BLS Randomness Beacon for SubstrateGitLabโ˜โ˜’โ˜’
KILTPolimec: A Fundraising Mechanism for Projects within the Polkadot EcosystemGitHubโ˜โ˜โ˜
Simply VCP.A.N.I.C. Phase 2GitHubโ˜โ˜โ˜
InterlayTrustless BTC-Polkadot BridgeGitLabโ˜โ˜’โ˜
DodoRareCrossbow: Mobile Game Framework for SubstrateGitHubโ˜โ˜’โ˜’
HalvaHalva: Bootstrapping and ScaffoldingGitHubโ˜โ˜’โ˜’
Sunshine SystemsSunshine KeybaseGitHubโ˜โ˜’โ˜’
SubscanMulti-signature Management ToolGitHubโ˜โ˜’โ˜’
EvercitySmart Sustainable Bond Protocol (SSB-P)GitHubโ˜โ˜’โ˜’
PermiurlyPolkassemblyGitHubโ˜โ˜’โ˜’
ZeropoolPrivate transactions on PolkadotGitHubโ˜โ˜’โ˜
PolkadexA decentralized, peer-peer, cryptocurrency exchange for DeFi ecosystem in SubstrateGitHubโ˜’โ˜’โ˜
FractappMessenger with crypto walletGitHubโ˜โ˜’โ˜’
Equilibrium.ioAll-in-one Interoperable DeFi hub.GitHubโ˜โ˜’โ˜’
Glacier Blockchain TechnologyStarks NetworkGitHubโ˜โ˜’โ˜’
SubDEXA decentralized cross-chain exchange based on AMMGitHubโ˜โ˜’โ˜’
ZenlinkA cross-chain DEX networkGitHubโ˜โ˜’โ˜’
SubscriptSubstrate smart contract api and sdk in AssemblyScriptGitHubโ˜โ˜’โ˜’
TesseractSwift APIGitHubโ˜โ˜’โ˜’
CoboCobo VaultGitHubโ˜โ˜’โ˜’
NodeFactoryVedar: Auto-funded public P2P infrastructure (APPI)GitHubโ˜โ˜’โ˜’
AdoriasoftCosmos-SDK Parachain Development Kit Phase 2GitHubโ˜โ˜’โ˜’
supCommand line tool for generating or upgrading a Substrate nodeGitHubโ˜โ˜’โ˜’
Shard LabsTip or Donate KSM Embeddable ButtonGitHubโ˜โ˜’โ˜’

๐Ÿ”

๐Ÿ„ Wave 6 - Q2 2020โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
ProtofireFailover mechanism for validatorsGitHubโ˜โ˜’โ˜’
HashQuarkValidator Dashboard Phase 2GitHubโ˜โ˜’โ˜’
BUIDL LabsYieldScan Staking DashboardGitHubโ˜โ˜’โ˜’
BoBao TechnologiesPolkaKey an electron app to generate Polkadot addresses + tutorialsGitHubโ˜โ˜’โ˜
Webassembly SecurityImproving security and resilience of WebAssembly runtimesGitHubโ˜โ˜’โ˜’
FinoaC library for SubstrateGitHubโ˜โ˜’โ˜’
Crust NetworkIncentive layer protocol for decentralized storageGitHubโ˜โ˜’โ˜’
ETCDEVPolkadot Java ClientGitHubโ˜โ˜’โ˜’
ZondaxLedger app for Polkadot/Kusama Phase 2GitHubโ˜โ˜’โ˜’
SoramitsuHyperledger Iroha BridgeGitHubโ˜โ˜’โ˜’
LimeChainAssemblyScript SCALE CodecGitHubโ˜โ˜’โ˜’
InsightLoad Balanced EndpointsGitHubโ˜โ˜’โ˜’
EthworksPolkadot.{js} Desktop ApplicationGitHubโ˜โ˜’โ˜’
UsetechNFT Tracking ModuleGitHubโ˜โ˜’โ˜’
ChevdorPolkabotGitHubโ˜โ˜’โ˜’
Aleksandr KrupenkinHaskell Web3 libraryGitHubโ˜โ˜’โ˜’
WEB3SCANPolkascan Signer InterfacesGitHubโ˜โ˜’โ˜’
FortmaticSDK + Burner Wallet to implement Web 2.0 login for dappsGitHubโ˜โ˜โ˜
PureStakeWeb3 Compatible APIGitHubโ˜โ˜’โ˜’
Phala.NetworkWeb3 AnalyticsGitHubโ˜โ˜โ˜
TerenceGeC implementation of SchnorrkelGitHubโ˜โ˜’โ˜’
AdoriasoftCosmos-SDK Parachain Development KitGitHubโ˜โ˜’โ˜’
Laminar OneReusable Libraries: Runtime Modules + Monitoring FrameworkGitHubโ˜โ˜’โ˜’
FaberSubwallet: CLI wallet for Polkadot/SubstrateGitHubโ˜โ˜’โ˜’
Equilibrium.cooffchain::ipfsGitHubโ˜โ˜’โ˜’
SnowforkEthereum BridgeGitHubโ˜โ˜’โ˜’
LunieLunie Governance integrationGitHubโ˜โ˜’โ˜’
LimeChainAssemblyScript RuntimeGitHubโ˜โ˜’โ˜’
MVP WorkshopSubstrate startkit GUI (marketplace for substrate pallets)GitHubโ˜โ˜’โ˜’
P2PMultiblockchain ETLGitHubโ˜โ˜’โ˜’
FlexDappsGantree Phase 4GitHubโ˜โ˜โ˜
ZondaxLedgeracio: A command-line tool and Ledger app designed for staking operationsGitHubโ˜โ˜’โ˜’
Dipole TechDipole Oracle: Distributed energy resource managementGitHubโ˜โ˜’โ˜’

๐Ÿ”

๐Ÿ„ Wave 5 - Q1 2020โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
BifrostEOS interoperable bridgeGitHubโ˜โ˜’โ˜’
Entropy LabsA toolkit for building and deploying applications with substrateโ˜โ˜’โ˜
Papers GmbHAirGap - Desktop (+mobile) wallet for PolkadotGitHubโ˜โ˜’โ˜’
Stake TechnologiesPlasm Chain + OVM ImplementationGitHubโ˜โ˜’โ˜
UsetechPostgreSQL Indexer and Consensus InsurerGitHubโ˜โ˜’โ˜’
AcalaA decentralized stablecoin platformGitHubโ˜โ˜’โ˜’
ETCDEVPolkadot Network CrawlerGitHubโ˜โ˜’โ˜’
XayaDecentralised Complex GamingGitHubโ˜โ˜’โ˜’
CelerLayer 2 Scaling InfrastructureGitHubโ˜โ˜’โ˜
Cryptoeconomics LabSubstrate adapter of Plasma child chainGitHubโ˜โ˜โ˜
Centrifuge / ChainSafeSubstrate / Ethereum BridgeGitHub 1, Github 2โ˜โ˜’โ˜’
AdvancaPrivacy-preserving general-purpose compute/storage layerGitHubโ˜โ˜’โ˜’
NodleSecurely identify, certify and verify IoT devicesGitHubโ˜โ˜’โ˜’
FigmentDotHub: Information Hub for validators and delegatorsGitHubโ˜โ˜’โ˜’
LunieWeb and mobile walletGitHubโ˜โ˜’โ˜’
Web3 GardensRuntime modules and UI for creating stable, well-governed communities on SubstrateGitHubโ˜โ˜’โ˜
IteringRuby Substrate APIGitHubโ˜โ˜’โ˜’
WEB3SCANIdentity Pallet for PolkascanGitHubโ˜โ˜’โ˜’
Swisscom Blockchain AGKubernetes Operator for Sentry nodes or Validators deploymentGitHubโ˜โ˜’โ˜’
PolkastatsPolkadot/Kusama network statisticsGitHubโ˜โ˜’โ˜’
Supercomputing SystemsSubstraTEE extension packGitHubโ˜โ˜’โ˜’
EncointerAn Ecological, Egalitarian and Private Cryptocurrency and Self-Sovereign Identity SystemGitHubโ˜โ˜’โ˜’
FlexDappsGantree is a full-service node infrastructure toolkit for Substrate-based blockchainsGitHubโ˜โ˜’โ˜’
Matter LabsZinc/RedShift ZK programming frameworkGitHubโ˜โ˜โ˜
Second StateBridging Ethereum Tools and Smart Contracts into Substrate EcosystemGitHubโ˜โ˜’โ˜’
Sensio.GroupSubstrate modules + UI that focus on photo copyright and privacyGitLabโ˜โ˜’โ˜
KILTSubstrate Anonymous CredentialsGitHubโ˜โ˜’โ˜’
Node FactoryMetamask plugin for PolkadotGitHubโ˜โ˜’โ˜’
InterlayPolkadot/BTC bridge specification (RFP)GitLabโ˜โ˜’โ˜’
Stake TechnologiesECDSA for Polkadot JSGitHubโ˜โ˜’โ˜’
Obsidian LabsSubstrate IDEGitHubโ˜โ˜’โ˜’
DefinexA financial market protocolGitHubโ˜โ˜’โ˜’
Attic LabMultisignature Wallet Standardization/PSPGitHubโ˜โ˜’โ˜’
ImTokenMulti-chain non-custodial mobile and hardware wallet for iOS & AndroidGitHubโ˜โ˜’โ˜’
SelfKeySelfKey DIDs & Claims as Ink! Smart ContractsGitHubโ˜โ˜โ˜
LykenRust trait system revampGitHubโ˜โ˜’โ˜
Chorus OneGrandpa light client in TendermintGitHubโ˜โ˜’โ˜’

๐Ÿ”

2019โ€‹

๐Ÿ„ Wave 4 - Q4 2019โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
Genesis LabValidator TrackerGitHubโ˜โ˜’โ˜’
UsetechSubstrate API in .NETGitHubโ˜โ˜’โ˜’
BlockX LabsEnzyme Browser extension walletGitHubโ˜โ˜’โ˜’
WEB3SCANPython API clientGitHubโ˜โ˜’โ˜’
Galactic CouncilPolkalert: Validator MonitoringGitHubโ˜โ˜’โ˜’
BandotStablecoinGitHubโ˜’โ˜’โ˜
Laminar OneLaminarChain: High performance Flow Protocols powering synthetic asset and margin tradingGitHubโ˜โ˜’โ˜’
Stake TechnologiesInk! PlaygroundGitHubโ˜โ˜’โ˜’
B-HarvestNode Monitoring ToolGitHubโ˜โ˜’โ˜
Simply VCP.A.N.I.C. Validator alerting solutionGitHubโ˜โ˜’โ˜’
EthworksPolkadot{.js} extension improvementsGitHubโ˜โ˜’โ˜’
Lyken Software SolutionsInvestigation of runtime compilationGitHubโ˜โ˜’โ˜’
Blockchain ITInk! Remix PluginGitHubโ˜โ˜’โ˜’
KadenaPact feasibility studyGitHubโ˜โ˜โ˜
STAFI ProtocolStafi is a protocol to provide liquidity for staking assetsGitHubโ˜โ˜’โ˜’
Vision BakerDatDot โ€” Dat protocol for PolkadotGitHubโ˜โ˜’โ˜
Speckle OSIntegrating additional features into Speckle OSGitHubโ˜โ˜โ˜
ArchipelSolution to resolve high availability problem of Validator nodes in PoSGitHubโ˜โ˜’โ˜’
ZondaxFlexible TrustZone-based HSM stackGitHubโ˜โ˜’โ˜’
UsetechSR25519 library in pure C and C#GitHubโ˜โ˜’โ˜’
AkropolisPolkaHub โ€” Heroku-like infrastructure for node deploymentGitHubโ˜โ˜’โ˜’
PixuraSubstrate API client in HaskellGitHubโ˜โ˜โ˜
HashQuarkValidator DashboardGitHubโ˜โ˜’โ˜’
StackticalPerformance Management Runtime ModulesGitHubโ˜โ˜’โ˜
Sean YoungSolidity to WASM compilerGitHubโ˜โ˜’โ˜’
Chain SecurityTool for validating correctness of Polkadot runtimesGitHubโ˜โ˜’โ˜’

๐Ÿ”

๐Ÿ„ Wave 3 - Q3 2019โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
Supercomputing systemsSubstrate Rust API clientGitHubโ˜โ˜’โ˜’
NGRAVESubstrate Hardware Wallet Integrationโ˜โ˜’โ˜
Caelum LabsDecentralised identity modulesโ˜โ˜’โ˜
Runtime VerificationBuild executable K specifications of the SRMLGitHubโ˜โ˜’โ˜’
Attic LabVS Code and Atom pluginsGitHubโ˜โ˜’โ˜’
DockVerifiable Claimsโ˜โ˜’โ˜
BlockdaemonPolkadot Package ManagerGitHubโ˜โ˜’โ˜’
ZondaxLedger app for PolkadotGitHubโ˜โ˜’โ˜’
GeefuVue JS components for Polkadot JS appsGitHubโ˜โ˜’โ˜’
CentrifugeSubstrate Go API clientGitHubโ˜โ˜’โ˜’
LitentryIdentity modules and corresponding UIsGitHubโ˜โ˜’โ˜’
DappForceSubSocial - Substrate module and web UI for decentralized communitiesGitHubโ˜โ˜’โ˜’
Phala.NetworkpLibra, Privacy Bridge between Polkadot and Libra chainGitHubโ˜โ˜’โ˜
WivSupply chain modules and front-end UIGitHubโ˜’โ˜โ˜

๐Ÿ”

๐Ÿ„ Wave 2 - Q2 2019โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
Cap9A low-level security protocol and framework for smart contractsGitHubโ˜โ˜’โ˜’
Substrate Java APIJava version of our JS APIGitHubโ˜โ˜’โ˜’
StarlogA metadata chain for IPFSGitHubโ˜โ˜’โ˜
MixBytesBenchmarking tool for Substrate and PolkadotGitHubโ˜โ˜’โ˜’
GunclearPrivate secure data storage solution using Plasma Cash in SubstrateGitHubโ˜’โ˜’โ˜
ZeroChainZero knowledge transactions in SubstrateGitHubโ˜โ˜’โ˜’
RobonomicsSubstrate modules for controlling robotsGitHubโ˜โ˜’โ˜
AvadoPolkadot node deployment with consumer hardwareGitHubโ˜โ˜’โ˜’
Stake TechnologiesPlasma modules for SubstrateGitHubโ˜โ˜’โ˜’
HOPRSubstrate integration with this P2P messaging protocolGitHubโ˜โ˜’โ˜’
Mailchaina Multi-Blockchain Messaging ApplicationGitHubโ˜โ˜’โ˜’
UsetechPolkadot C++ APIGitHubโ˜โ˜’โ˜’

๐Ÿ”

๐Ÿ„ Wave 1 - Q1 2019โ€‹

TeamProjectLinkTerminatedFirst DeliveryCompleted
ChainSafePolkadot Runtime Environment in Go (via an RFP)GitHubโ˜โ˜’โ˜’
SoramitsuPolkadot Runtime Environment in C++ (via an RFP)GitHubโ˜โ˜’โ˜’
WEB3SCANPolkascan: Open Source Block ExplorerGitHubโ˜โ˜’โ˜’
PolkawalletMobile WalletGitHubโ˜โ˜’โ˜
ValidatorsOpen Source Scalable ClusterGitHubโ˜โ˜’โ˜’
BlockX LabsEnzyme Browser extension walletGitHubโ˜โ˜’โ˜’
Speckle OSBrowser extension walletGitHubโ˜โ˜’โ˜’
Noise ExplorerRust code generator for formally verified (Noise/ cryptographic) handshakesSource Codeโ˜โ˜’โ˜’
ProtosOpen Source Node ExplorerGitHubโ˜’โ˜’โ˜
Supercomputing SystemsSubstrate Transaction Privacy using Intel SGXGitHubโ˜โ˜’โ˜’

๐Ÿ”

- + \ No newline at end of file diff --git a/applications/AdMeta.html b/applications/AdMeta.html index 57a6380656d..e60f60d6e3e 100644 --- a/applications/AdMeta.html +++ b/applications/AdMeta.html @@ -4,13 +4,13 @@ AdMeta | Web3 Foundation Grants - +
Skip to main content

AdMeta

  • Team Name: AdMeta
  • Payment Address: 0x1D346c4F0732674a1fc69b4bAFBa854F53353C35 (ERC20 USDT)
  • Level: 2

Project Overview ๐Ÿ“„โ€‹

Overviewโ€‹

Advertising in Metaverse

AdMeta is a Metaverse advertisement platform that focuses on privacy-preserving. AdMeta uses a TEE-based DID service to identify target groups for advertisers, and with the usage of TEE, AdMeta guarantees not to collect any user data. AdMeta builds multiple forms of ad assets (e.g. billboards, wall paintings) in Metaverse platforms like Decentraland, Bit.Country, to allow land holders to integrate our products easily. Qualified conversions let both users and publishers get rewards from advertisers.

In Polkadot and Kusama ecosystem, DID projects like Litentry are growing fast along with its related products. We have already discussed and agreed on our initial cooperation with Litentry. Also, we have contacted with Metaverse projects like Bit.Country, who shows great interests in cooperation as well.

Unlike traditional ad platforms, who collect users sensitive data(e.g. location, browsing history) for advertising, AdMeta does not collect or store any user data per se. Instead, users voluntarily decide and control what data can be stored in TEE, and the stored data in TEE cannot be accessed by anyone except users themselves.

Project Detailsโ€‹

AdMeta Demo - the floating billboard

In the above image, the floating billboard is our prototype ad component built with decentraland SDK. Users who registered on our blockchain, and switched "Ad Display" option on (by default it's off) are able to see a customized ad content on this billboard while gaming in decentraland.

The content of this ad component is selected according to user's personal data and preference. Unlike centralized ad platforms, we don't store user's data on or database. Instead, it's stored on the TEE layer of blockchain, and the target group matching and selecting happen also in the TEE layer, which ensures that no private data are exposed during the whole process. Eventually, both user and publisher receive some amount of token as rewards from advertiser.

Our blockchain is built with Substrate, and the pallet-ad provides the functionality of advertisement proposal, storage and governance. The user pallet will connect to TEE-based external identity aggregation and DID service provided by Litentry (we have already the initial cooperation plan) to match ads with users data and preference.

Architectureโ€‹

AdMeta Architecture

Advertisers can propose an ad with certain acceptance rule, e.g. link clicking, and also advertiser provides how many times the ads are displayed and converted, and how much they pay for each conversion. They need to pay the total price (the number of conversions * price per conversion) while proposing the ad. Each ad display has a unique ID, which is generated while creating the proposal. A Merkle tree are built with all these unique IDs, and the root of Merkle tree will be stored in on-chain storage. A qualified conversion gives the participated user this UID, with which the user can claim for rewards.

Councils shall approve or reject ad proposals according to the content of ads. Also, advertisers are evaluated on their behavior democratically.

Users can switch on the "Ad Display" option on AdMeta, so that users can get rewards by viewing and interacting with ads. By default, this option is off, which means users who haven't set up their AdMeta won't see any ads. Users can also provide their data for a better ad matching, by means of this they will get more rewards.

Publishers can simply utilize our Ad Assets on any Metaverse platform and place it on their lands. Users also get rewards by a qualified display conversion.

Technology Stackโ€‹

  • Substrate
  • Node.js
  • 3D Model Design

Ecosystem Fitโ€‹

There are an increasing number of Metaverse related projects in Polkadot/Kusama ecosystem, however, the current Metaverse platforms still lack of infrastructures and applications, comparing to our current real life. We therefore build this for various Metaverse platforms.

Our target audiences can be Web3 projects, who are potential advertisers, Metaverse land holders, who are potential publishers, and Metaverse players, who are potential users.

Advertising is our natural needs in almost all social scenarios, and we meet this needs in Metaverse.

Parami builds Web3 ad platforms as well, and their scope is to build the DID and privacy layer by themselves. While we are focusing on the advertising functionality, and the DID service will be provided by Litentry, who is more professional on this field and has already their products. Also, our ad platform is targeting on Metaverse, not Web3.

Team ๐Ÿ‘ฅโ€‹

Team members (In order of joining time)โ€‹

Han Zhao - Core Dev and PM of Litentry Parachain Team. University of Stuttgart

Yvonne Xie - Digital Marketing Lead. King's College London

Shihao Zhao - Full Stack Dev of Litentry. University of Toronto

Hao Ding - VP of Litentry, Founder of Web3Go. University of Stuttgart

Dr. John Wu - Core Dev of Litentry Parachain Team. The University of Tokyo

Contactโ€‹

  • Registered Address: No legal structure yet.
  • Registered Legal Entity: No legal structure yet.

Team's experienceโ€‹

Han and John are core developers as well as project managers at Litentry, and both of them are main developers who implemented the Litentry parachain from scratch. Litentry is an identity aggregation focused company in Polkadot ecosystem, and has got the Web3 Foundation grant since 2019.

Yvonne has more than 8 years experience of digital marketing, and she has a deep understanding and practice of various online marketing and advertising methods. She also initialized this idea of combining advertisement and privacy preserving, to archive the goal of data protection.

Shihao is a full stack developer at Litentry, who contributes a lot in Litentry and Web3Go web apps and backend apps.

Hao is the founder of Web3Go, VP of Litentry, who has a very solid practical experience on both blockchain and data science.

Note: Both Litentry and Web3Go are Web3 granted projects.

Team Code Reposโ€‹

Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

Team LinkedIn Profiles (if available)โ€‹

Development Status ๐Ÿ“–โ€‹

Development Roadmap ๐Ÿ”ฉโ€‹

Overviewโ€‹

  • Total Estimated Duration: 1 months
  • Full-Time Equivalent (FTE): 2 FTE
  • Total Costs: 12,000 USD

Milestone 1 โ€” Substrate Chain with Impression Ad, Web Appโ€‹

  • Estimated duration: 6 month
  • FTE: 2
  • Costs: 12,000 USD
NumberDeliverableSpecification
0a.LicenseGPLv3
0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
0e.ArticleWe will publish an article/workshop that explains our advertising workflow as well as technical details.
1.Substrate module: adWe will create a Substrate module that will allow advertiser to create impression ads, and with council's approval, this ad will be ready to be displayed. If ads are rejected by the council(e.g. illegal or pornographic content), the advertiser's proposal bond will be slashed and collected in treasury.
2.Substrate module: user mockWe will create a Substrate module that will first store users data on chain, to test and verify our logic. Also, user can update their data, control what data should be used, and these data are used to find the best matching ad for user.
3.Substrate chainModule ad and user can be integrated into a substrate node, to enable users access of all approved ads, receive rewards, etc. This chain will integrate treasury, council, democracy and also other essential pallets, to build a full-featured blockchain.
4.Web AppWe will create a web app, to let users easily interact with our substrate node. Users can claim rewards from viewing and clicking ads, and they can also configure their ad preferences and decide if they are willing to view ads or not.

Future Plansโ€‹

The next step is to have sensitive data stored in TEE. Also, we will build more ad types, like click ads and acquisition/action ads. Meanwhile, we will implement a Chrome extension to simplify the claim process, and an Ad asset on Decentraland(or other Metaverse platform) to enable land holders to use our ad assets conveniently.

In a long run, we will cooperate and adapt our products with more Metaverse platforms, and also we will develop more creative and interactive ad types.

Additional Information โž•โ€‹

How did you hear about the Grants Program? Personal recommendation

- + \ No newline at end of file diff --git a/applications/Afloat.html b/applications/Afloat.html index a6377172dd4..25f69d1daaa 100644 --- a/applications/Afloat.html +++ b/applications/Afloat.html @@ -4,7 +4,7 @@ Afloat Tax Infrastructure Polkadot Integration | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ (5 contributors)
NumberDeliverableSpecification
0a.LicenseMIT
0b.DocumentationWe will provide inline documentation of the code and a basic tutorial of the modules delivered in this Milestone.
0c.TestingUnit testing will be applied to ensure reliability. Documentation of tests and results will be provided
0d.VideoWe will provide a video demonstration that will illustrate all of the functionality delivered with this milestone.
0e.ArticleWe will publish an article in English and Spanish that explains what was built and how it can benefit other projects
1.Order Part of an NFTWeb client and pallet support for fractionalizing a Tax Credit NFT. Users may specify the % and/or direct amount for the order. Rust and Angular/Vuejs
2.Complete/Confirm OrderSell the entire or a fraction of the tax credit to interested buyers using fruniques pallets. Rust and Angular/Vuejs
3.Order SettlementEnsure the marketplace correctly calculates appropriate commissions and fees. Calculations will be in Rust, displayed in application using Angular/Vuejs

Milestone 4 โ€” Redeem the tax credit and confirm redemption and freeze/burn asset on-chainโ€‹

NumberDeliverableSpecification
0a.LicenseMIT
0b.DocumentationWe will provide inline documentation of the code and a basic tutorial of the modules delivered in this Milestone.
0c.TestingUnit testing will be applied to ensure reliability. Documentation of tests and results will be provided
0d.VideoWe will provide a video demonstration that will illustrate all of the functionality delivered with this milestone.
0e.ArticleWe will publish an article in English and Spanish that explains what was built and how it can benefit other projects
1.Approve Redemption SpecialistsPallet and web client for onboarding and approving/enrolling Tax Credit Redemption Specialists. These are experts that know how to perform appropriate steps to migrate a tax credit IRL. Approval will be handled by marketplace administrator initially, by the community eventually.
2.Request RedemptionPallet and web function/form for requesting redemption, optionally from a specific Redemption Specialist or system will choose.
3.View materials and RedeemPallet support and web client for Redemption Specialist to review the encrypted tax credit materials and confirm that off-chain IRL redemption has been completed. Redemption completion will be approved by owner and Redemption specialist.
4.Asset ManagerOnce part or all of a tax credit NFT is redeemed, the Tax Credit Asset Manager(s) will be able to lock, freeze, and/or burn the NFT.
5.Launch MaterialsLaunch materials, videos and speaking arrangements for Louise are already in queue.

Future Plansโ€‹

Immediate Useโ€‹

All Afloat users will be migrated to the substrate application and benefit from the identity and security enhancements. Afloat will gain access to the full substrate ecosystem and vice versa.

Next Phasesโ€‹

This proposal covers Afloat migration of the current functionality. Below are future phases that expand it:

Phase 2โ€‹

User scenarios:

Web client for:

Phase 3โ€‹

User scenarios:

Phase 4โ€‹

Additional Information โž•โ€‹

How did you hear about the Grants Program? Raul Romanutti recommended the program on a call with Louise Reed, Max Gravitt and Augusto Lara on March 21st, 2022.

Additional Contextโ€‹

State Tax Credit Breakdownโ€‹

Currently, forty-one states offer tax credits designed to incentivize economically and socially desirable behavior, like historic structure rehabilitation, land preservation and film production.

Image

Thirty-four of those states allow the producers of these credits to be incentivized even if they do not have enough state income to fully utilize the credits and/or need the cash flow to further expand the incentivized behavior.

Image

Blockchain Friendly State Breakdown

Image

https://www.investopedia.com/news/majority-us-states-are-still-acknowledge-cryptocurrencies/

- + \ No newline at end of file diff --git a/applications/Aisland-DocSig.html b/applications/Aisland-DocSig.html index aa547a7cfbe..08904876541 100644 --- a/applications/Aisland-DocSig.html +++ b/applications/Aisland-DocSig.html @@ -4,7 +4,7 @@ Aisland Docsig | Web3 Foundation Grants - + @@ -52,7 +52,7 @@ https://github.com/aisland-dao/docsig

An live demo is available at:
https://docsig.aisland.io

Development Roadmap ๐Ÿ”ฉโ€‹

Overviewโ€‹

Milestone 1 Example โ€” Basic functionalityโ€‹

NumberDeliverableSpecification
0a.LicenseApache 2.0
0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to start the node and run the Dapp
0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
0e.ArticleWe will publish an article/workshop that explains what was done/achieved as part of the grant. The language will be English and it will be published also in our media channels
1.Substrate module: pallet-docsigWe will implement the current pallet-docsig to allow the storage on chain of the documents within certain size limits
2.Dapp Feature: Standard Signature ImageWe will add the new feature to manage the standard signatures as described at the point 1 of "Details of the Proposal"
3.Dapp Feature: Signature MarkerWe will create a plugin for editor.js to allow the placing of the signature marker as described at the point 2 of "Details of the Proposal"
4.Dapp Feature: EncryptionWe will implement the encryption as described at the point 3 of "Details of the Proposal"

Milestone 2 - Additional Featuresโ€‹

NumberDeliverableSpecification
0a.LicenseApache 2.0
0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to start the node and run the Dapp
0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
0e.ArticleWe will publish an article/workshop that explains what was done/achieved as part of the grant. The language will be English and it will be published also in our media channels
1.Dapp Feature: Pdf OutputWe will add the new feature to generate a pdf output as described at the point 5 of "Details of the Proposal"
2.Dapp Feature: Link SharingWe will add a function to share the link for signature as described at the point 6 of "Details of the Proposal"
3.Dapp Feature: Multiple Counter PartiesWe will reafactor the Dapp to allow the signature from different parties as described at the point 7 of "Details of the Proposal"
4.Dapp Feature: Enhanced TemplatesWe will add the feature to create/manage private templates into the Dapp as described at the point 8 of "Details of the Proposal"

Future Plansโ€‹

Referral Program (optional) ๐Ÿ’ฐโ€‹

Not applicable

Additional Information โž•โ€‹

How did you hear about the Grants Program? Web3 Foundation Website

- + \ No newline at end of file diff --git a/applications/AlgoCash.html b/applications/AlgoCash.html index 92b94c7245f..1ba033e49a7 100644 --- a/applications/AlgoCash.html +++ b/applications/AlgoCash.html @@ -4,13 +4,13 @@ AlgoCash | Web3 Foundation Grants - +
Skip to main content

AlgoCash

This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

  • Team Name: Reserve Labs
  • Payment Address: DAI Address: 0x3f91475fbd0c3d9c676d39af071691c1cf635f0b

Project Overviewโ€‹

Overviewโ€‹

The price volatility of cryptocurrencies is a major blocker for mass adoption. Their rapid change in fiat-denominated value causes payment values to vary even during settlement times, being highly inconvenient to merchants that handle them.

Stablecoins are cryptocurrencies with an exchange rate peg with existing fiat currencies or a fiat-related index, thereby drastically increasing their usefulness as a payment medium.

Although there exists a wide variety of stablecoin mechanisms, some are with censorship risks or some are still suffered from price volatility.

Algo Cash specifically uses an algorithmic approach to manage the supply of tokens according to a predetermined logic. The algorithm is in charge of balancing stablecoin supply to fluctuating demand, ensuring that the token price remains relatively stable.

Integrationโ€‹

Algo Cash is implemented as a smart contract which can be deployed into ink! pallet of a parachain.

For trading and liquidity purpose, Algo Cash could be integrated with such protocols in Polkadot as Konomi and Zenlink.

Project Detailsโ€‹

Tokensโ€‹

ALC - Algo Cashโ€‹

Algo Cash tokens are designed to be used as a medium of exchange. The built-in stability mechanism expands and contracts their supply, maintaining their peg to the aUSD token.

ALB - Algo Bondsโ€‹

Algo Bonds are minted and redeemed to incentivize changes in the Algo Cash supply. Bonds are always on sale to Algo Cash holders, although purchases are expected to be made at a price below 1 Algo Cash. At any given time, holders are able to exchange their bonds to Algo Cash tokens in the Algo Cash Treasury. Upon redemption, they are able to convert 1 Algo Bond to 1 Algo Cash, earning them a premium on their previous bond purchases.

Bonds do not have expiration dates. All holders are able to convert their bonds to Algo Cash tokens, as long as the Treasury has a positive ALC balance.

ALS - Algo Sharesโ€‹

Algo Shares loosely represent the value of the Algo Cash network. Increased demand for Algo Cash results in new Algo Cash tokens to be minted and distributed to Algo Share holders, provided that the Treasury is sufficiently full.

Holders of Algo Share tokens can claim a pro-rata share of Algo Cash tokens accumulated to the Boardroom contract.

Poolsโ€‹

Treasuryโ€‹

The Algo Cash Treasury exists to enable bond-to-cash redemptions. Bonds redeemed via the Treasury automatically returns the user an equal number of Algo Cash, provided that: 1) the oracle price of Algo Cash is above 1 aUSD, and 2) the Treasury contract has a positive balance of Algo Cash.

Disallowing redemptions when the Algo Cash price is below 1 aUSD prevents bond holders from prematurely cutting their losses and creating unnecessary downward pressure on the price of ALC.

Boardroomโ€‹

The Boardroom allows Algo Share holders to claim excess Algo Cash minted by the protocol. Holders of Algo Shares can stake their Shares to the Boardroom contract, which by doing so, they can claim a pro-rata share of Algo Cash tokens assigned to the Boardroom.

Stabilization Mechanismโ€‹

The Algo Cash protocol is designed to guarantee Algo Cash tokens to be exchanged at a value of a single US dollar, with the stabilizer (in-protocol stability mechanism) in charge of matching the supply of Algo Cash to their demand.

Every 24 hours, the time-weighted average of the ALC-aUSD exchange rate is read from the DEX Aggregator in Polkaot, which is then fed into the Algo Cash protocol to be referenced by its stability mechanism.

The stabilization mechanism is triggered whenever the price of Algo Cash is observed to be above / below (1+ฮต) aUSD, where ฮต is a parameter that defines the range of price stability for the ALC token. In inilization, ฮต is set to be 0.05.

Contractionary Policyโ€‹

At any point in time, Algo Bonds can be bought from the protocol in exchange for Algo Cash. Purchase of Bonds are performed at an algorithmically set price. With a Algo Cash oracle price of P aUSD, bonds are sold off at a price of P ALC (effective price being P^2 aUSD), promising bond holders a premium when redeemed. Purchased bonds can be converted to Algo Cash, insofar as the preconditions are met and the Treasury is not empty.

Expansionary Policyโ€‹

If the price of Algo Cash is observed to be higher than (1+ฮต) aUSDT, the system mints totalSupply *(oraclePrice-1) number of new Algo Cash tokens. The issued Algo Cash is either deposited to the Treasury or the Boardroom, depending on the Algo Cash balance of the Treasury.

If the Treasury has a balance above 1,000 Algo Cash, then it is logical to assume that either all bonds have been already redeemed, or no bond holder is currently willing to perform a redemption.Either way, this signals that the demand for bond redemption do not exist at this time, and thus the freshly minted Algo Cash is given to the Boardroom contract.

However, if the Treasury has a balance of below 1,000 Algo Cash, then it is assumed that there will be additional demand for bond-to-cash redemption. Therefore, the issued Algo Cash is routed to the Treasury so that Bond holders can exercise redemptions.

Token Distributionโ€‹

Initial distribution of Algo Cash are done to those that deposit aUSD to the distribution contract. A total of 100,000 Algo Cash tokens are distributed to depositors, with 10,000 Cash tokens distributed per day. The amount of stablecoin deposits are limited to 20,000 tokens per account.

Afterwards, a total of 1,500,000 Algo Shares are on crowd sale and the initial token price would be 40 aUSD. The crowd sale will last for 15 days. Afterwards, ALS will be listed on the DEXs with the same price as in the crowd sale, all funds raised in the crowd sale will be distributed to the DEX as buy orders and all Share tokens left will be distributed as sell orders.

Further distribution of Algo Shares are given to liquidity providers (e.g. ALS-DOT pair, ALS-aUSD pair, etc.) or ecosystem contributors. A total of 500,000 Algo Shares are distributed over a period of 1 year, and an equal amount of tokens are distributed per day.

Advantages

  1. Funds in the crowd sale will not be abused, but used to establish the liquidity market.

  2. Regardless of the funds raised, sufficient selling liquidity can be provided to facilitate large amounts of funds to enter the market.

  3. Compared to joint curve issuance: a fair start, avoiding scientists from rushing

  4. Compared to AMM 2 pool mining: inflation tokens are not required to pay liquidity rents, and tokens are distributed to investors instead of those who "dig, sell and withdraw".

  5. Compared to auctions: Crowd sale is compatible with auction functions, but it is not just a simple fundraising. After the crowd sale is over, a market with abundant liquidity will be established immediately. Even having not raise enough funds, a market with sufficient selling liquidity can still be established, which AMM cannot do.

Contractโ€‹

cash - Minting and burning of the cash token

Mints amount cash to the recipient account.

Burns amount cash from the account.

bond - Minting and burning of the bond token

Mints amount bond to the recipient account.

Burns amount bond from the account.

share - Minting and burning of the share token

Mints amount share to the recipient account.

Burns amount share from the account.

Treasure - Bond purchase and redemptions

Returns the oracle price of Algo Cash denominated in aUST.

Mints amount Algo Bonds, in exchange for same amount Algo Cash burnt.

Mints amount Algo Cash, in exchange for amount Algo Bonds burnt.

If the oracle price of Algo Cash is above (1+ฮต) aUST, mints ((ALC Oracle Price) - 1) cashSupply* number of Algo Cash to either the Boardroom contract or the Treasury contract.If the Treasury's balance is below 1,000 ALC, the allocation is given to the Treasury, else give it to the Boardroom.

Boardroom - Handling claims from the share

Stakes amount Algo Shares to Boardroom sends all prior accrued dividends to account.

Withdraws amount Algo Shares and all accrued dividends to account.

Returns the amount of all dividends accrued by account.

Claims all accrued dividends to account.

When new cash is assigned to the Boardroom contract. Records the current block timestamp, the amount of new cash, and the current amount of total Shares staked.

oracle - Retrieving the exchange rate between Algo Cash and aUST

If 24 hours has passed since update() was last successfully executed, updates the time-weighted average price of Algo Cash.

Returns the amount of output tokens given in exchange for input number of token tokens ((Price of token token denominated in output tokens) * input).

Ecosystem Fitโ€‹

Acala, aUSD is generated in a collateral way.

Basis Cash (on Ethereum), shares are initialized by 'AMM + 2nd pool' which would cause dramatic infaltion, forcing Yeild Farmers to sell their assets to the second market.

Teamโ€‹

Team membersโ€‹

  • Nick Hsu, Blockchain Expert and Team Leader
  • Gang Chan, Full Stack Developer
  • Gieno Miao, Crypto Expert and Blockchain Architect

Contactโ€‹

No legal Entity

Team's experienceโ€‹

Nick has 16 years of software development experience and 5 years working in Blochain area as developer and product owner.

Gang is now working as a freelancer. He is a full stack developer proficient in C++, Rust, React and Solidity. He has 3 years software development experience and 2 years smart contract development experience.

Team Code Reposโ€‹

Team LinkedIn Profilesโ€‹

no

Development Roadmapโ€‹

Overviewโ€‹

  • Total Estimated Duration: 6 weeks
  • Full-time equivalent (FTE): 1.5
  • Total Costs: 5,000 DAI

Milestone 1 Example โ€” Implement Substrate Modulesโ€‹

  • Estimated Duration: 7 weeks
  • FTE: 2
  • Costs: 5,000 DAI
NumberDeliverableSpecification
0LicenseApache 2.0 / MIT / Unlicense
1DocumentationSpecification of the background, components and working mechanism
2Smart ContractAlgoCash smart contract repo. The smart contract can be deployed to any substrate chain with ink! pallet.
3TestsUnit Test and also we will test it on Canvas
4DockerA docker image with a Substrate chain for PoC

Future Plansโ€‹

Shares token design for governance.

We will build a DEX with PMM (Proactive Market Maker) algorithm.

Community Engagementโ€‹

We will reach DEX and Lending protocol communities to enlarge Algo Cash adoption.

- + \ No newline at end of file diff --git a/applications/Anchor.html b/applications/Anchor.html index d32dda5c1d0..74bd4622271 100644 --- a/applications/Anchor.html +++ b/applications/Anchor.html @@ -4,7 +4,7 @@ Anchor, On-chain Linked List pallet and Name Service | Web3 Foundation Grants - + @@ -22,7 +22,7 @@ It is not very stable to access Github here, so the left codes are on my private git server.

  • The whole EasyPolka framework works properly, but still so many details to fix and neccesary function to add.

    • Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website.

    - + \ No newline at end of file diff --git a/applications/Apron_Network.html b/applications/Apron_Network.html index 2a6bfe402a9..23d77d2af7f 100644 --- a/applications/Apron_Network.html +++ b/applications/Apron_Network.html @@ -4,13 +4,13 @@ Apron Network | Web3 Foundation Grants - +
    Skip to main content

    Apron Network

    • Team Name: Apron Labs
    • Payment Address: 15tV6rQSwNgWQ1Z5pim2yJmELLvWNm5D4V

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Introductionโ€‹

    The Apron Network's vision is to be the entry point of the Web3 World in the future. The goal of the Apron Network is to create the decentralized infrastructure for all the developers who want to build applications on top of the blockchain, the service providers who are running nodes for blockchain, and the users who are using applications based on blockchain.

    The blockchain infrastructure services are provided by seldom centralized service providers. Those service providers are commercial companies and earn profit by providing these services. In general speaking, there is no problem with such a business model that commercial companies provide infrastructure services and get paid by developers or users in the past ages. But NOT NOW. The main feature of blockchain is decentralization, while all the blockchain infrastructure services are built and maintained by commercial companies, and those systems are centralized, which is against the decentralization of blockchain. There is a potential issue of such a business model that the service providers can steal the blockchain from the community by manipulating the API accesses through their infrastructure services. Once the service providers manipulate the API accesses, there is no real blockchain anymore.

    Maybe you are still thinking that it sounds terrible but no one can prove it. Let's see the recent accident of infura.io. Almost all of the blockchain applications mainly rely on the API services from infura.io, but none of the builders of blockchain applications can imagine what will happen if infura.io manipulates the API services. Hopefully, infura.io worth our trust according to past services, and there is no manipulation found yet.

    On Nov. 11th, 2020, the API services from infura.io are down, and the idea of Apron Network comes out.

    The Apron Network is built by the Apron Labs powered by Substrate. It provides a Cross-chain Decentralized Infrastructure Services Network that will be used by blockchain node runners, DApp developers, the public chain community, and DApp users. Every DApp developer can discover the proper service provider for a specific blockchain through the decentralized infrastructure market on the Apron Network. The Apron Network can be run as a parachain of Polkadot.

    With the Apron Network, the DApp developers can find their API endpoint, node runners can provide infrastructure services to get profit and all the infrastructure services will be decentralized on the two-layers infrastructure service network. The Apron Network will guaranty there is no infura.io accident anymore!

    Integrationโ€‹

    The Apron Network can be run as a parachain on Polkadot, or an independent chain. The Apron Network contains Apron Node and Apron Market. The Apron Node is built with Substrate 2.0 Framework, and the OCW (Off-chain worker) will be included for API manage records. Apron Market consists of Apron Market Contracts and Apron Market Front End. The contracts will be implemented with Ink!, and the front-end will be built with polkadot.js.

    Team Interestโ€‹

    Most of the team members are DApp developers who suffer from the lacking of Ethereum API Endpoint and tightly rely on infura.io since we are not able to set up our full node due to funds. As we have known, most of the DApp developers have the same embarrassing situation as us. After shocked by the accident of infura.io, we are willing to build a decentralized infrastructure service network, and we name it the Apron Network.

    With Substrate 2.0 Framework, we are able to build a customized blockchain network easily, and we have the ability to integrate an API Gateway to manage blockchain API services in Apron Node. With the Apron Network, the blockchain node runners can provide Infrastructure service easily and get profit through this decentralized infrastructure services network.

    Project Detailsโ€‹

    Architectureโ€‹

    The Apron Network consists of Apron Node, Arpon Market Contracts, Decentralized API Market, and the Apron SDK.

    img

    • The Apron Node is the customized chain node for the Apron network built with Substrate 2.0. Besides blockchain-related features, it contains the full features of an API Gateway in the early versions. In future versions, more infrastructure features will be added. It should be run together with the blockchain node and operate by blockchain node runners. For example, the owner of the Ethereum Full node can set up an Apron Node to interact with his Ethereum Full node through RPC, then the DApp developer can retrieve the information of his Apron Node from the Apron Network, and call the API like calling an API with infura.io.
    • The Apron Market Contracts manage the API services information, the registration of API services, the registration of API users, and the billing of API usage. All the API information is stored in these contracts. The billing feature is implemented, the API users have to pay $ANT to use these APIs and the API owners will get paid by $ANT. Everything is done through smart contracts. $ANT is the native token in Apron Network.
    • Decentralized API Market lists all the API services registered and available for developers from the data in smart contracts. DApp developers search the API services according to their needs and choose the one with the proper price.
    • The Apron SDK makes the use of Apron Network easier. DApp developers can integrate this SDK in their app to dynamic switch blockchain entry-point according to their needs.

    Substrate / Polkadot Integrationโ€‹

    The Apron Network can be run as a para-chain of Polkadot, and also can be run as an independent chain apart from Polkadot.

    The whole network is built on top of the Substate 2.0 Framework, and OCW (off-chain worker) is used to report API usage statistics on which the billing relies.

    All the contracts will be implemented with Ink!, and the front-end of Decentralized API Market will be on top of polkadot.js.

    Scenariosโ€‹

    • Node Runners

    img

    The above figure shows the role of each component act from the view of the blockchain node owner. To simply the scenario, we take an example. The para-chain node is running at the beginning, the Apron Node shown above is set up by the owner by staking some $ANT, and the Apron Node is accessible on the internet. The owner can configure Apron Node with the RPC entry point of the para-chain node, API access frequency, API access fee, and other limitations. After everything is configured, the Apron Node will be able to call the RPC interface of para-chain, and DApps will call the API through the Apron Node. The Apron Node calculates the API usage statistics of each caller, then stores this data through OCW (off-chain worker) on the chain for further billing.

    • DApp Developers

    img

    For DApp developers, there are two components that will be used. One is the Decentralized API Market, the other one is the Apron SDK. Firstly, DApp developers search the API services in the API service repositories ( which is part of the Decentralized API Market) on the webpage. After finding the proper API service, the DApp developer will generate an API access key with the help of Apron Market Contracts. Finally, the DApp developer develops the DApp with the API access key to use the related API services. Of course, the DApp developer should pay the fee of using the API services according to the fee addressed by the API service provider.

    Interface Specificationโ€‹

    The function provided by the pallet to report API usage statistics data is reportAPIUsage.

    1. reportAPIUsage

    - desc: Report the API usage statistics from API Gateway data.
    - params: API Key
    - return: the calls number

    Ecosystem Fitโ€‹

    Infura.io is the typical infrastructure services provider that is totally centralized.

    The Apron Network provides exactly the same API services as infura.io but in a decentralized way, thanks to Substrate 2.0 Framework which let us only focused on the logic on top of blockchain rather than re-develop a new blockchain. In the future, the Apron Network will provide a decentralized infrastructure services network.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Toney - CTO/Project Lead
    • Junjun - Full-stack Developer

    Contactโ€‹

    No Legal Entity

    Team's experienceโ€‹

    Toney

    • Over 13 years of experiences in Software Development
    • Software Engineer in MS
    • Mobile Game Developer
    • Blockchain Game Developer
    • The Chief Tech Officier of the team which wins TRON Accelerator 2018 Game Rewards

    Junjun

    • Over 15 years of experiences in Software Development
    • Former Senior Software Engineer in Lucent
    • DApp Developer
    • Full-stack Developer

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-time equivalent (FTE): 4
    • Total Costs: 0.73 BTC

    Milestone 1 Example โ€” Implement Substrate Modulesโ€‹

    • Estimated Duration: 3 months
    • Full-time Equivalent (FTE): 4
    • Costs: 0.73 BTC

    In the first milestone, the features for the PoC will be implemented and tested by limited users.

    The following components will be included:

    • Apron Node
    • Apron Market Contracts
    • Decentralized API Market / Front End
    • Apron SDK
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationThe documentation will be provided to show the whole achitecture of the Apron Network.
    0c.Testing GuideThe testing guide will be provided to test each component.
    1.Apron Node RepoWe will create a customized chain node with Substrate 2.0 Framework, it will contains the OCW module to report API usage statistics on-chain.
    2.Apron Market Contracts RepoThe contracts will be implemented with Ink!, and it will handle all the API services related functions such as 1) Staking tokens to register API service for node runner, 2) Register and unregister API service for node runner, 3) Define the price of API service for node runner, 4) Apply API service access key for node runner and DApp developers, 5) Billing System of the API usage for node runner and DApp developers, 6)Interface to integrate with a DAO to solve dispute between node runner and DApp developer
    3.Decentralized API Market / Front End RepoIt's a webpage working with Arpon Network, it's implemented based on polkadot.js as planned.
    4.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain
    5.TutorialWe will write an tutorial about how to use Apron Network.
    6.ArticleWe will write an article published on media channels.
    7.DAOA Apron DAO will be created to handle the governance of the Decentralized API Market.

    Future Plansโ€‹

    Community Plan

    • Hire 3 more developers.
    • Hire 1 marketing adviser.
    • Recruit more contributors involved in our project.
    • Join Polkadot related events.
    • Bounty Program.
    • Publish articles on media channels to expose the Apron Network.

    Development Plan

    • The Apron Network will run as a parachain of the Kusama.
    • Support Kusama Node.
    • In phase 1, our goal is to achieve all the designed functions.
    • In phase 2, improve the stability of the Apron Network.
    • In phase 3, provide decentralized quick node services.
    • Finally, our goal is to provide the infrastructure services network.

    Additional Information โž•โ€‹

    Currently we just start the first design of the Apron Network.

    The project repo: https://github.com/apron-network

    - + \ No newline at end of file diff --git a/applications/ArtZero_InkWhale.html b/applications/ArtZero_InkWhale.html index c949fc1c593..f13815de7ad 100644 --- a/applications/ArtZero_InkWhale.html +++ b/applications/ArtZero_InkWhale.html @@ -4,7 +4,7 @@ ArtZero & InkWhale | Web3 Foundation Grants - + @@ -21,7 +21,7 @@ Mr. Tung Nguyen - Back-end and Blockchain Developer

    Other part-time testers and designers.

    Contactโ€‹

    Team's experienceโ€‹

    Brian Nguyen graduated from University of Nottingham with a 1st class degree in Computer and Electronics Engineering. Over the last 15 years, He has developed many data-driven applications. He also has deep interest in blockchain technology and development of decentralized apps on Ethereum, Binance Smart Chain, Tron, Solana network. He is the founder of ArtZero - the first NFT Marketplace & also 1st dApp on Aleph Zero network.

    Frankie Kao owns a design company and have been working in many projects on web design, graphic designs etc. He dedicated his resources to work with ArtZero.

    Phuong Hoang has been in sale and marketing industry for over a decade. She has been Sale and Marketing Manager/Director for many companies including: Honda Vietnam, Plex Cinama, Saga Media etc.

    All of our developers have at least 5-10 years experience in software development.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We have completed the Testnet demo version of the ArtZero NFT Marketplace. The first version of the contracts are waiting to be audited then our platform will be ready to be launch on Aleph Zero Mainnet.

    https://artzero.io https://docs.artzero.io/

    Ink Whale is still in development and the MVP is completed for public test at https://inkwhale.net

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” NFT Marketplace on Polkadot Parachainsโ€‹

    In this milestone, We will create Smart contracts to be compatible with Ink!4.0 Polkadot Parachains with full working NFT Marketplace UI/UX and backend.

    NumberDeliverableSpecification
    0a.LicenseApache License 2.0
    0b.DocumentationWe will provide technical documents and user guides
    0c.Testing GuideWe will provide Test Plan and Test Results for operating and using the NFT Marketplace
    0d.Article/TutorialWe will write an article or tutorial that explains the NFT Marketplace
    1.Smart contract DevelopmentWe use ink! to develop the contracts and the functions that contracts support are: list, unlist NFT, buy NFT at fixed price, bid for an NFT, accept an NFT bid, add NFT Collection, add a launchpad project. We need to develop the contracts using project structure as defined in https://github.com/Supercolony-net/openbrush-contracts/tree/main/example_project_structure to meet higher code standard for better code management. The functions are partly built with psp34 support and still need more work to be compatible with psp37 (erc1155) standard.
    2.BackendBuild infrastructure to serve the need of NFT Marketplaces. We use nodejs and mongodb on AWS Services. The backend will have an api service that serves the front end and cron jobs to fetch data from blockchains to save into the local database. The API definition can be found at https://docs.google.com/document/d/1bPq9aFMaaVgKgsYWG3K4APubRK33OloY4_gHM3c8wo0/edit and it needs development to work on all Polkadot's parachains. The backend will have to handle the following tasks: Monitor NFT bids in the queue and update Bid table in the database; Cache Images from IPFS to CloudFlare Image; Cache NFT Metadata to local database; Monitor NFT Collection changes and update the database; Monitor NFT Information and update the database; Telegram bot to alert system operators: queue length and access attempt and work load.
    3.FrontendCreate new front-end for the NFT Marketplace, we have 2 mockups at https://www.figma.com/file/76ER4HZUR1KMDaxctx5BS6/DragonSUI?node-id=146%3A68 and https://www.figma.com/file/xsVkm8VOdTqyPWPgTrbQpl/ArtZero?node-id=275%3A12 these are under converting from Figma to ReactJS code.
    4.TestingWe will provide unit test for smart contracts. For Frontend and Backend testing we will provide Test Document with Plan and Test Cases for operating and using the NFT Marketplace

    Milestone 2 โ€” Ink Whale Staking and Yield Farming Platform Developmentโ€‹

    In this milestone, We will continue to improve the current development of Ink Whale Platform to completion.

    NumberDeliverableSpecification
    0a.LicenseApache License 2.0
    0b.DocumentationWe will provide technical documents and user guides
    0c.Testing GuideWe will provide Test Plan and Test Results for operating and using the staking and yield farming platform.
    0d.Article/TutorialWe will write an article or tutorial that explains the work principle as part of the grant.
    1.Smart Contract DevelopmentEnhance the current smart contracts in MVP. The contracts will be compatible with Ink!4.0 and have following functions: create PSP22 token, create a staking pool, create NFT yield farm, create token yield farm, add rewards to pool, remove rewards from pool, claim reward from pool. We have to create 9 different contracts; WAL token contract that allows public minting and fixed total supply; General psp22 token contract and psp22 token generator contract; Pool Contract and Pool Generator Contract; NFT Farming Contract and NFT Farming Generator Contract; LP Farming Contract and LP Farming Generator Contract.
    2.BackendBuild infrastructure to serve the need of Ink Whale. We use nodejs and mongodb on AWS Services. The cronjob monitor update queue to make sure data in the database match with data on-chain; The API serves the frontend with following functions: getTokens, getPools, getLPPools, getNFTPools, getPoolsbyOwner and getPoolsbyAddress. update API also required to add update request to the database queue and serves the cronjobs.
    3.FrontendRevamp the front-end for final version, better UI/UX. The new design is currently in progress and can be found at https://www.figma.com/file/63xCCH71Oa8AfJpkK1wCO3/Ink-Whale?node-id=88%3A234. The current demo can be seen at https://testnet.inkwhale.net
    4.TestingWe will provide unit test for smart contracts. For Frontend and Backend testing we will provide Test Document with Plan and Test Cases for operating and using Ink Whale platform

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? from Founder of SubWallet

    - + \ No newline at end of file diff --git a/applications/Awesome-Polka.html b/applications/Awesome-Polka.html index dc65c6c5901..485f21d6ce1 100644 --- a/applications/Awesome-Polka.html +++ b/applications/Awesome-Polka.html @@ -4,13 +4,13 @@ Awesome Polka | Web3 Foundation Grants - +
    Skip to main content

    Awesome Polka

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Awesome Polka - the ultimate social platform for discovering and exploring the most exciting projects in the Polkadot ecosystem! Whether you're a developer, investor, or simply a curious enthusiast, Awesome Polka provides a one-stop-shop for accessing comprehensive and detailed applications about the projects. With this cutting-edge platform, you can discover the latest updates and developments, connect with project owners, and stay up-to-date with the most innovative projects in the Polkadot community.

    Project Detailsโ€‹

    Project showcase platforms face several challenges that hinder their effectiveness in promoting and highlighting various projects. The most significant challenges include sustainability and limited ecosystem partner (admins - authorized ones like someone from a DAO) authorities on the platform. These challenges significantly affect user experience and discourage project owners and ecosystem partners from utilizing the platforms fully. To address these issues, there is a need to develop innovative and user-centric strategies that enhance the functionality and sustainability of showcase platforms.

    General overview of Awesome Polka:

    Awesome_Polka_Mindmap

    Problemsโ€‹

    Let's take a closer look at some of the issues of project showcase platforms that I have encountered:

    Sustainability: The long-term sustainability of a platform depends on its ability to consistently deliver value to its users. Manual updates to listed projects through forms and limited content control can result in outdated or inaccurate information, reducing user trust and engagement.

    UI & UX: The user experience (UX) of a website or platform can significantly impact user engagement and satisfaction. Poorly designed UIs, slow loading times, confusing navigation, and other factors can all contribute to a low UX, hence reducing user engagement.

    Poor Search Algorithms: A platform showcasing tens of projects will require an effective search algorithm to help users easily find the specific project they are looking for. Weak search algorithms can result in irrelevant search results, leading to frustration and decreased user engagement.

    Static Project Pages: A project page should provide detailed information about the project, such as its objectives, methodology, team members, progress, and impact. A page that only includes a brief description can leave users with unanswered questions and reduce their interest in the project.

    Educational Materials & Articles: For users interested in a particular project, educational materials and related articles can provide valuable context and additional information. Making these resources easy to find and linking them directly to the relevant project pages can enhance user engagement and interest.

    Ecosystem Partner Rights: Partnerships with DAOs or other ecosystem partners can bring significant benefits to a platform, such as increased visibility, funding, and community support. However, without proper rights and access, these partners may not be able to fully leverage their resources and expertise to help the platform grow and succeed.

    Solutionsโ€‹

    Awesome Polka is a social platform that aims to benefit the broader Polkadot developer ecosystem in several ways. Firstly, as Polkadot is one of the fastest-growing protocols, having a platform like Awesome Polka that aggregates all the projects in the ecosystem can help to further increase its size and diversity.

    Additionally, Awesome Polka provides a fluent user experience that enables more people to stay informed about what's happening on Polkadot. By making it easy to access detailed information about projects and events, Awesome Polka helps to promote collaboration and engagement among developers and enthusiasts alike.

    Finally, the platform will be continually supported through Twitter sharing and events, ensuring that it remains a vibrant hub of activity within the Polkadot ecosystem.

    Awesome Polka provides solutions to the problems mentioned in the previous statements in the following ways:

    Solution to Sustainability

    Awesome Polka has 2 personas for managing the platform: Project owners that want to publish their project on Awesome Polka, and ecosystem partners that is authorized ones like someone from a DAO, or from Polkadot team.

    Project owners can send a request to publish their project. After review and approval, they will receive login information to publish and edit their project's page via their web3 wallets on a special dashboard. This enables project pages to be updated by project owners all the time and have unique dynamic pages.

    On the other side, ecosystem partners can have admin access to Awesome Polka. They can approve or reject projects and request to remove any harmful content with an explanation. This allows ecosystem partners to help manage Awesome Polka and ensure that all projects are aligned with sustainability goals.

    In summary, Awesome Polka provides a platform where project owners and ecosystem partners can work together to create long-term sustainable platform. By empowering project owners to create and manage their own projects and providing ecosystem partners with the tools to manage and monitor the platform, Awesome Polka helps to create a sustainable future for all.

    Improvement on UI & UX

    Awesome Polka has a simple and effective user interface that makes it easy to navigate the website and find the information you are looking for. With just a few clicks, users can access general information and project details on the platform. The user interface has been designed to be fresh and cross-platform compatible, which ensures a seamless and enjoyable user experience regardless of the device or browser used.

    The platform is continually undergoing UI developments to enhance the user experience further. At the final stage of development, the user interface will be fully responsible and optimized for all screen sizes, ensuring that users have a consistent and enjoyable experience across all devices. Overall, Awesome Polka prioritizes usability and user experience to create a platform that is both informative and easy to use.

    Home PageProjects PageArticles Page
    Awesome Polka Home PageAwesome Polka Projects PageAwesome Polka Articles Page

    Solution to Poor Search Algorithms

    Awesome Polka has a powerful search infrastructure that uses Algolia to deliver detailed and lightning-fast search results.

    On Awesome Polka, category list exist to organize projects in detail. Ecosystem partners can add categories to this category list according to ecosystem needs, while project owners can select their category and subcategory while adding their project to the platform. Awesome Polka automatically integrates new categories into relevant pages to increase search efficiency.

    Moreover, Awesome Polka's search infrastructure uses a detailed searching matrix. Unlike most showcase platforms that only use titles to search for anything, Awesome Polka's range of parameters is much wider, ranging from titles to project descriptions. This ensures that users can find what they are looking for more easily and with greater precision.

    In summary, Awesome Polka's search infrastructure is designed to provide a seamless and efficient user experience. Additionally, ecosystem partners work to ensure that the platform's categories are up-to-date and relevant to the needs of the community, further enhancing the search experience.

    Search ElementSearch Focused

    Solution on Static Project Pages

    On Awesome Polka, project owners can manage their project pages, which include several modules such as:

    • Project Description
    • Token Stats
    • GitHub Stats
    • Team Info
    • Latest Articles
    • Frequently Asked Questions
    • Job Postings

    The number of these modules will be increased and further developed.

    Project owners can update their project page using these modules. In the future, additional modules can be added based on the needs of the ecosystem.

    In summary, project pages on Awesome Polka are highly customizable, allowing project owners to showcase their projects using a variety of modules. By providing these modules, Awesome Polka enables project owners to provide up-to-date information about their projects and engage with the ecosystem more effectively.

    Improvement on Educational Materials & Articles

    Awesome Polka offers a platform for project owners to publish educational materials and articles to inform and engage with the ecosystem. With the built-in editor, project owners can create compelling content that keeps their audience up-to-date on the latest developments in their projects. By providing these tools, Awesome Polka helps to create a more informed and engaged community.

    Improvement on Ecosystem Partner Rights

    Ecosystem partners play a crucial role in ensuring the sustainability of the Awesome Polka platform. By giving them admin rights, they can help manage the platform and ensure that it meets the needs of the community. The committee responsible for this role will be selected based on their ability to review and manage projects effectively.

    Technology Stackโ€‹

    • AWS App Sync (GraphQL)
    • AWS Amplify
    • Next.js
    • Additional Tools & Frameworks
      • Redux
      • Tailwind CSS
      • Magic (Web3 Auth & Wallet)
      • Algolia (Search Infrastructure)

    Documentationโ€‹

    Once all project milestones have been accomplished, we will create and publish comprehensive technical documentation that provides all the necessary information for end users to fully understand the system and its capabilities.

    PoC/MVP or other relevant prior work or research on the topicโ€‹

    Awesome Polka MVP Link: https://dev.awesomepolka.org

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem?

      Polkadot's User Interface section is the ideal place to start for the Awesome Polka project, offering the best opportunity for success.

    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

      Awesome Polka targets a diverse range of audiences, including individuals who are interested in learning about Polkadot projects and their latest updates. This includes investors, enthusiasts, and other stakeholders who want to stay up-to-date with the developments in the Polkadot ecosystem.

      In addition to individuals, Awesome Polka also targets both early-stage and live projects on the Polkadot ecosystem. By providing a comprehensive platform that supports projects of all sizes, Awesome Polka aims to support the growth and development of the entire Polkadot ecosystem.

      Furthermore, Awesome Polka also targets ecosystem partners such as DAOs who can help to make the platform more sustainable and aligned with their vision. By engaging with the community and involving ecosystem partners in the management of the platform, Awesome Polka aims to create a more collaborative and impactful platform that benefits everyone involved in the Polkadot ecosystem.

    • What need(s) does your project meet?

      Awesome Polka meets the needs I mentioned in the solution section above, but if I have to write it as a summary, it covers the following:

      • Sustainable project management: The project ensures sustainable project management by providing a comprehensive and structured approach to project management. This approach includes planning, execution, monitoring, and control of project activities, which helps to achieve project goals while minimizing risks and resource wastage.

      • Strong SEO optimization: The project meets the need for strong SEO optimization by implementing best practices for on-page and off-page SEO. This includes optimizing content for keywords, ensuring site speed and mobile responsiveness, and building high-quality backlinks to improve search engine rankings and visibility.

      • Fresh and easy-to-use UI: The project meets the need for a fresh and easy-to-use UI by providing a user-friendly interface that is intuitive and easy to navigate. This helps to enhance the user experience and encourages users to engage with the project more frequently.

      • Efficient and lightning-fast search infrastructure: The project meets the need for efficient and lightning-fast search infrastructure by implementing a robust search system that enables users to find the information they need quickly and easily. This ensures that users can access the project's content and resources without delays, which improves overall usability and satisfaction.

      • Detailed project modules: The project meets the need for detailed project modules by providing comprehensive information on various project aspects such as token stats, GitHub activity, job postings, and so on. This helps users to stay informed about project updates and developments, which enhances transparency and trust in the project.

    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

      • If so, how is your project different?
        • Yes, I found a similar project called Polka Project, there may be other projects, but let me tell you about the differentiating aspects of Awesome Polka.
          • Detailed filtering and search options for easier and efficient project discovery
          • Ability for projects to use modules for article sharing and job postings and so on
          • Display of GitHub repository information and statistics
          • Display of token information, including market capitalization, total volume, and price
          • A learning section with resources for the Polkadot ecosystem
          • Sharing of project team information.
          • Dashboard for Projects Owners and Admins to manage platform sustainable.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Tolga Yaycฤฑ

    Contactโ€‹

    • Registered Address: -
    • Registered Legal Entity: -

    Team's experienceโ€‹

    As a full-stack developer with 2 years of experience, I have honed my skills in software development, with a focus on dApp development in the past year. I have a deep interest in the Web3 and NFT space and have put my skills to the test by creating a number of relevant applications. In addition to my experience, I have developed detailed React and Next.js projects, further enhancing my ability to build robust and scalable web applications.

    In addition to my technical skills, I have also been actively involved in the wider tech community. I have served as a Chainlink Community Advocate, Aave Turkey Community Manager, and Founding Chair of Gazi University ACM Student Chapter. My previous role as a Microsoft Learn Student Ambassador has also given me the opportunity to share my knowledge and experience with others. I have set of experiences and skills and particularly in the areas of full stack software development and community management.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    The user interface and search infrastructure of this project are largely complete and ready for discovery. To get a glimpse of the minimum viable product (MVP), you can either take a look at the repository or visit the website.

    Development Roadmap ๐Ÿ”ฉโ€‹

    This project is planned as 1 milestone, it will be completed in one months.

    • Total Estimated Duration: ~1 month
    • Full-Time Equivalent (FTE): 1
    • Total Costs: 10,000 USD

    Milestone 1โ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseUnlicense
    0b.DocumentationI will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleI will publish an article/workshop that explains what was done/achieved as part of the grant.
    1.UI & UX DevelopmentHome Page: Visually appealing and user-friendly homepage which includes latest articles, popular categories and many more
    Projects Page: Showcase page with detailed filtering and search infrastructure
    Project Detail Page: Project details page to display detailed information about project with several modules like explained in the solution
    Articles Page: Articles page to showcase informative articles related to the subject
    Article Detail Page: Detail page for individual articles to display their full content
    Ranking Page: Ranking page based on votes and token stats which is supported by CoinGecko api to showcase popular projects and articles
    Learn Page: Useful resources to learn about polkadot ecosystem </br/> UX Improvements & Testing: I will work to improve the user experience by ensuring that the user interface is fully compatible with mobile and tablet devices.
    2.Project Owner DashboardAs part of this milestone, I will be implementing both the frontend and backend components of the Project Owner Dashboard. This involves designing and developing the user interface (UI) for the dashboard, as well as building the necessary backend infrastructure to support its functionality. To ensure the quality of my work, I will conduct thorough testing to ensure that the dashboard is user-friendly and performs as expected. My ultimate goal is to provide project owners with a seamless and efficient experience when updating their pages and publishing articles on our platform.

    Future Plansโ€‹

    I will manage the @awesomepolka Twitter account and keep the followers of the Awesome Polka community updated on the latest projects added to the platform. Additionally, I will create monthly threads to share developments with the community.

    Besides, to ensure the best possible user experience, I will actively monitor the Awesome Polka platform for any bugs or technical issues that may arise. I am committed to maintaining the platform's quality, and any problems that are identified will be addressed promptly.

    I will conduct ongoing maintenance and support for a year to ensure the smooth functioning of the platform. If users encounter any issues while using Awesome Polka, they can report them by creating a GitHub issue or by filling out a form that is available on the website.

    My goal is to provide a reliable and user-friendly platform for the web3 community, and I am dedicated to addressing any issues that arise in a timely and efficient manner.

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    • Referrer: -
    • Payment Address: -

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/BCANN.html b/applications/BCANN.html index 5a2181576c9..cff632d4470 100644 --- a/applications/BCANN.html +++ b/applications/BCANN.html @@ -4,7 +4,7 @@ BCANN ( The blockchain system for Assigned Names And Numbers ) | Web3 Foundation Grants - + @@ -35,7 +35,7 @@ c. Unit testing and test documentation

    Milestone 2: Example of name services dappโ€‹

    mock-ups for milestone 2

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide documentation on how to get a name/subname, and how to use your name/subname for crypto address resolve
    0c.Testing GuideWe will provide users with a test name services, and users can get a 30-day test period for a name/subname
    1.ns dappWe will implement a dapp to get/manage/transfer your name/subname.

    We will implement a dapp at this milestone. The deliverable part includes: a. Dapp for getting/managing/transferring your name/subname b. Dapp for getting/managing/transferring your name/subname for test purpose (free name/subname)

    Future Plansโ€‹

    1. We will create a mail system for name/subname which offers common mail service with crypto currency sending service
    2. We will create a BCANN parachain for each parachain as the superset of the registry data, it can provide developers with one-stop domain name registry and resolve services
    - + \ No newline at end of file diff --git a/applications/Banksy_Finance.html b/applications/Banksy_Finance.html index 030e36c5056..5665589b87d 100644 --- a/applications/Banksy_Finance.html +++ b/applications/Banksy_Finance.html @@ -4,13 +4,13 @@ Banksy Finance | Web3 Foundation Grants - +
    Skip to main content

    Banksy Finance

    • Proposer: Clink Li

    • Payment Address: 0x111767Cb725C92f06031570Cf2dfb694EbD25bf6

    • Status: Terminated

    Project Description ๐Ÿ“„โ€‹

    The lack of options for loans collateralized by NFTs is the consequence of the larger challenge of NFT liquidity and defining the NFT assetsโ€™ price. The same problem fungible (ERC-20) tokens faced before AMMs (automated market makers) were introduced. Once it is solved and an efficient price discovery mechanism is created, NFTs backed loans will experience a boom.

    In the overall market, loans can release asset values and provide the NFT with much-needed liquidity.

    The existing NFT lending platforms in the market, including NFTfi, UpShot One, NFT20, and other projects, all adopt the P2P lending model. The disadvantages are that there is no NFT price evaluation mechanism, and it is difficult for debtors and creditors to find the exact matching businesses. In addition, NFT liquidity is extremely limited. So, the lenders have to bear a lot of risks in P2P lending.

    Overviewโ€‹

    Banksy Finance is a decentralized AI-driven NFT Pool-based lending hub, dedicated to addressing the issues of the NFT market, providing a complete solution for NFT mortgage lending that is different from the P2P lending model. It supports mortgage NFT for loans directly on the platform, without requiring both lenders and borrowers to an agreement. It is the first NFT pool-based lending platform in the market.

    • NAK Protocol

      Banksy Finance first integrated AI technology in the NFT market and provided a reliable NFT pool-based lending solution to address the issues for the market.

      Banksy has developed a set of AI-driven NFT AI KIT, which is an NFT market-based artificial intelligence algorithms toolset, referred to as the NAK protocol. The NAK protocol includes the following features:

      1. Base Analysis: It will timely collect and analyse the data from different Chains, including NFT creator information, attributes, historical transactions, media coverage, community status, popularity, and other information for evaluation of NFT value trend and NFT public opinion trend.

      2. Originality Check: Banksy would extract all NFT characteristics to compose corresponding feature vectors, calculate NFT feature Hash value by the encryption algorithm, and carry out Originality Check for all created NFT.

      3. AI-Assisted NFT Creation: Banksy uses an AI algorithm of image style migration to generate NFT of specified style and content to help artists create better and faster.

      4. AI Oracle For NFT: Banksy integrates the data Analysis results of Base Analysis, uses a machine-learning algorithm to calculate the NFT price in real-time, and feeds the price to oracle.

    • NFT lending pool

      Based on the NAK protocol, Banksy built the NFT pool-based lending platform to provide effective funds security for lenders and meet the needs of NFT holders and lenders.

      Lenders: Users are welcome to deposit their funds (like ETH, USDT) in the Lending Pool for earning interest. The funds will exchange for c-tokens and mortgages for a loan of other mainstream tokens. They will also get the rewards of Banksy native tokens KSY.

      Borrowers: Users can mortgage NFTs in the mortgage contract and get a reference price through AI Oracle. Exchange for corresponding c-tokens to mortgage and take a loan from Lending Pool. It helps to get flexible cash flow for borrowers

      Liquidator: When the Health Factor was closed to 1 that means the collateral value is not properly covered by the value of the loan, the liquidation risk NFTs will be list out for all users. Users can pre-pay as liquidators and get the NFTs when the Health Factor falls below 1 to initiate liquidation. They will receive the KSY tokens as incentives.

    Project Detailsโ€‹

    • NFT Pool-based mortgage lending

    arch

    To ensure the healthy and sustainable NFT mortgage lending business development on the platform, Banksy has designed the following mechanisms:

    1. Whitelist

      By community voting, the pool-based lending business will support series of NFT works, such as the CryptoKitties series and the Bored Ape Yacht series. Introduce high-quality NFT works to eliminate worthless NFT works, thereby ensuring the quality of the NFT works in the platform and ensuring the security of the funds.

    2. Mortgage Rate

      By NAK protocol, the mortgage rate intelligently changes according to the multi-dimensional comprehensive evaluation and analysis of lending, loan demand, and NFT valuation of the whole platform to maintain a reasonable and healthy boundary.

    3. Lending Rate

      The lending rate will intelligently change according to the borrowing demand, capital stock, interest rate fluctuation, and so on to ensure the liquidity and safety of the funds through the NAK protocol.

    4. Liquidation mechanism

      NAK protocol will real-timely monitor and analysis the comprehensive data of collateral NFT to make value anticipation. When the NFT price fluctuates to affect the safety of lending money, the NAK protocol will notify the system to trigger the liquidation mechanism. All users of the Banksy platform will have the right to participate in the liquidation for a lower price and benefit from the liquidation. Meanwhile, we will also reward users for participating in the liquidation.

    5. Safety fund pool

      We set up a Safety Funds Pool where users can stake KSY and KSY/ETH trading pairs in the pool for revenues and rewards from the platform. In case of capital loss, the safety funds pool will use up to 30% of the assets locked to cover the deficit. It will ensure the funds when the shortfall event occurs.

    6. Platform revenue sharing

      Since the users are taking certain risks for staking their funds, Banksy will give incentives and platform revenue to stakes.

    • AI Oracle

      Oracle algorithm

      The open and transparency of NFT transaction data in the chains allow access to historical transactions, NFT attribute information, NFT creator information, and NFT popularity information (including Twitter attention, major media NFT attention). It will facilitate a comprehensive analysis of NFT value and trend forecast.

      Banksy will aggregate all the transaction data, take the transaction price and experts estimate as to the machine learning labels of sample data, and take all the relevant data of NFT as sample attribute data for the model training through machine learning algorithms. It will set out a reasonable model of machine learning.

      The real-time attribute data of NFT is used as the model input to predict the NFT price with the machine learning model. It finally multiples with a valuation coefficient to serve as the real-time reference price, as shown in the figure below:

    ml

    โ€‹ Decentralized deployment

    AI Oracle uses a decentralized oracle deployment, as shown in the following picture. The machine learning model calculates at AI Node, with data input provided by the Data sources node. Not the only one predictor node O is in the network, but n different predictor nodes (O1, O2,......, On). Each predictor Oi has its data sources that may not overlap. Oi takes and aggregates the data from the data sources and sends its own aggregated data Ai to request Req. BANKSY-SC will calculate A-Agg (A1, A2,...... using the number of Agg letters an) and return result A to USER-SC.

    oracle

    Banksy-Oracle workflow

    1. User-SC initiates on-chain requests.
    2. Banksy-SC records events for Oracle.
    3. Banksy-AI-Node receives the event log and performs the task, request data from external API.
    4. Banksy-AI-Node processes the returned data and returns the processing result.
    5. Banksy-AI-Node core software sends data back to Banksy-SC.
    6. Banksy-SC aggregates the data into a single data and returns it to User-SC.

    Ecosystem Fitโ€‹

    The NFT trading platforms launched in the Polkadot ecosystem include NFTmart, Starry Network, DNFT, and Vera Defi. Only DNFT and Vera are involved in NFT lending, and they are all P2P models with many limitations.

    Banksy breaks through the P2P lending and supports users to directly mortgage NFTs in the platform pool, where Oracle conducts valuation and risk assessment and has a safety funds pool to guarantee their funds. The platform also supports users to liquidate their collateral that exceeds the threshold of the health factor. The entire solution balances the risks and benefits of the NFT mortgage pool and the safety funds pool to ensure the safety of funds.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Team members have rich development experience, including algorithm, front-end development, back-end development, Smart contract development, etc. We have participated in the development of Defi projects. The team has in-depth research and accumulation of blockchain technology.

    Team Code Reposโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-time equivalent (FTE): 6
    • Total Costs: DAI 8500

    Milestone 1 -- Implementation of NFT pool-based lendingโ€‹

    • Estimated Duration: 2 month
    • FTE: 6
    • Costs: DAI 8500
    NumberDeliverableSpecification
    0a.LicenseApache License 2.0
    0b.DocumentationDocument includes the business and technical framework of NFT pool-based Mortgage Lending, as well as tutorials for Dapp users, including video tutorials. We will also provide NFT mortgage lending protocol and code calling instructions, and provide NFT pool-based mortgage lending infrastructure for other applications in the ecosystem.
    0c.Testing GuideWe will provide Banksy with a complete test suite and guide. The code will cover the unit tests of the main functions of NFT mortgage lending to ensure the robustness of business functions.
    0d.Article/TutorialWe will write an article or tutorial that explains the work principle as part of the grant.
    1a.Node RepoComplete the deploment of the basic public chain.
    2a.Pallet_lendingWe will complete the development of the NFT pool-based lending protocol and business, and run it on the test chain.
    2b.Pallet_safetypoolWe will complete the design and development of the pallet_safetypool model, including auction module, backstop module and ecosystem reserve.
    2c.Pallet_mortgageWe will complete the design and development of Pallet_mortgage, including the real-time output module of NFT valuation and mortgage rate, the NFT mortgage contract module, and the user's cToken calculation module.
    2d.Pallet_liquidationWe will complete the design and development of the Pallet_liquidation mechanism to support users to liquidate and benefit from NFTs with financial risks, including the NFT liquidation list module, liquidation protocol module, liquidation reward and penalty module.
    2e.Pallet_daoWe will complete the design and development of the Pallet_dao mechanism, including whitelist voting for the NFT series, banksy development voting, and dividend module.
    3.UI/DesginDesign UI based on the pahse mockup.
    4.User InterfaceBuild the UI on top of the smart contract functionalities and base on the design.
    5.DockerWell will provide a dockerfile to demonstrate the full functionality of the application.

    Future Plansโ€‹

    • We will keep enriching the types of NFT collateral and further enhance the liquidity of NFT.
    • We will keep adjusting the model for AI training in Oracle to make it more objective and timelier to present the price of NFT.
    • We will continue to develop and optimize the NAK protocol, and open the NAK protocol to the entire industry at the right time. As part of the NFT market infrastructure, the NAK protocol will help the NFT market develop healthier and faster.

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/CESS.html b/applications/CESS.html index f48cbe694f7..88f32699a56 100644 --- a/applications/CESS.html +++ b/applications/CESS.html @@ -4,7 +4,7 @@ Cumulus Encrypted Storage System (CESS) | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Cumulus Encrypted Storage System (CESS)

    • Team Name: CESS LAB
    • Payment Address: 0x378D889a6e66996C9Eda86D20D7E6adE666ce167(USDT)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    • Tag line: An infrastructure for a blockchain-based decentralized cloud data network.
    • Brief description: Cumulus Encrypted Storage System (CESS) is dedicated to develop a new global decentralized cloud data storage platform โ€“ a blockchain-based network infrastructure that is transparent, efficient, and equal opportunity to all members of the global community. CESS encourages excess or under-utilized resources as nodes to join CESSโ€™s unrestricted expandable network via the token economy incentive method. Each node joins the CESS peer-to-peer network by contributing data storage resources, computational resources, or network bandwidth. Built on our state-of-the-art virtualization and cloud computing technologies, CESS organizes and manages the participating resources providing clients with secure, high performance, and boundless cloud data storage services. Furthermore, the CESS protocol enables interconnection of network nodes, to build a large decentralized cloud storage system that supports up to 100PB storage scale to meet the demand of enterprise level data storage. CESS will adopt a phased approach to implement the above goals.
    • Indication 1: With the goal of entering Polkadot ecosystem, CESS will build a blockchain system based on Substrate directly, and plans to develop custom pallets on FRAME. In the future, CESS will consider integrating to Polkadot in the form of Parachain to create a new decentralized cloud storage ecosystem, establish a large-scale distributed storage network.
    • Indication 2: With rapid advances of new computing technologies such as big data and machine learning, the value of humanityโ€™s digital assets, the so-called โ€œDigital Goldโ€, are being discovered. Explosively growing amount of data in cyberspace calls for new technologies of secure data storage and efficient data sharing. The challenges are to achieve secure storage, efficient sharing, and trading with data ownerโ€™s rights protection, but current solutions are complex and worrisome. Distributed storage networks can better drive the arrival of Web3.0 and are one of the underlying technical infrastructure of Web3.0.

    Project Detailsโ€‹

    We expect the teams to already have a solid idea about your project's expected final state. Therefore, we ask the teams to submit (where relevant):

    Mockups/designs of any UI components

    • Global nodes: Display the global map and the number of global nodes of distributed storage network, and mark the location distribution of nodes according to coordinates; Display node list.

    Image

    • My cloud disk: Personal storage space to view the files uploaded to the storage network; The list can be sorted by upload time, file name, file type and file size; Supports file download, share, property setting, deletion and other operations. Image

    • File upload: Select the files to be stored and set the relevant storage parameters.

    Image

    • Search for file: Search the whole network through keywords, and download the search results. Image

    Documentation of core components, protocols, architecture, etc. to be deployed

    • CESS is a high-speed, secure, scalable and decentralized cloud storage system. It can handle tens of thousands of transactions per second through parallel technology. Through Data slicing technology, it can achieve the secure storage of massive data, and it has the functions of Data confirmation and Data rights protection, which provides powerful data service ability. It provides DAPP with unlimited scalable storage capacity and perfect Data rights protection capability.

    • Data storage workflow: When a client requests to store a data file, the CESS platform pre-processes the data file to obtain and store its meta-data and data fingerprints. The pre-process software also performs data file replication and fault tolerant erasure coding. The meta-data includes info of data owner, data keywords, and etc. The data fingerprints are for subsequent data rights confirmation.

    • CESS client-platform interactions: A typical CESS data client and platform interaction flow is as follows: first, a data storage client interrogates CESS chain to get current storage price. The client then places an order for his/her data file via extrinsics on blockchain. Once the payment is made and order is approved, the client then uploads the data file using API provided by CESS platform. The data file is not directly uploaded to storage nodes, instead it is uploaded to a CESS storage scheduling node. The scheduling nodes are the ones with secure hardware environment (Trusted Execution Environment or TEE) and the data file will be pre-processed, encrypted, and sharded. Finally, the scheduling node distributes data segments to storage nodes to store. CESS storage miners do not make deal directly with clients, and they get rewarded from CESS system by providing storage space. Minersโ€™ storage resources are uniformly managed by CESS system, which fairly distributes data files. Miners have the responsibility to maintain the integrity of clientsโ€™ data. Any malicious behavior will be punished (CESS token deduction).
    • Overall system architecture: CESS adopts a layered and loosely coupled system architecture, which is divided into blockchain service layer, distributed storage resource layer, distributed content delivery layer and application layer.
    • CESS MDRC mechanism workflow: CESS have designed a unique Multi-format Data Rights Confirmation Mechanism (MDRC), which extracts data fingerprint from each data file to generate data certificate ID. By comparing similarities between data fingerprints, the system identifies data lineages of data files, and may take appropriate actions to prevent possible violations, and to provide strong evidences for ownersโ€™ data rights protection.

    Ecosystem Fitโ€‹

    CESS is a distributed cloud data network with user friendly ledgers, novel consensus mechanism, multiple data authenticity proof schemes, and reliable network infrastructure. CESS offers data storage service with the advantages of low cost, privacy protection, security and robustness. With the implementation of CESS data confirmation and proxy re-encryption technology, CESS provides Web3.0 clients and DAPPs with trustworthy, secure and reliable data rights protection.

    Compared to the similar projects in the Polkadot ecosystem including Ocean, DataHighway and Bluzelle, CESS storage service features:

    • Encrypted data storage
    • Multiple copies (3 copies by default, more upon request)
    • Sharded and distributed on multiple nodes
    • Highly scalable storage space
    • Transactions secured by CESS blockchain
    • Data rights protection for data owners
    • Competitive cost

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Joseph Li
    • Jinghong Zeng

    Contactโ€‹

    • Registered Address: 22 St Leonard's Ave, Lostock, Bolton BL6 4JE, England
    • Registered Legal Entity: Paul David Humphreys

    Team's experienceโ€‹

    • Team CESS

    CESS technical team members have an affluent understanding of technology and have been involved in internationally renowned cloud storage companies as essential technical development members.

    The background of our team members includes but not limited to cloud computing and storage, involved in cloud related PaaS and SaaS products research and development; unique insights into the network development, cryptography algorithm implementation, and performance optimization; comprehensive knowledge of public chain and played a major role in the development of public chain focusing on the delivery of commercial applications.

    For the past two years, CESS core team members have been developing and building a stable decentralized cloud storage service atop the distributed resources to surmount the security risks presented in the current centralized storage platform. The members are working in the UK, China, and India locations with the commitment creating a decentralized cloud storage data network for commercial use.

    • Joseph Li

    Joseph Li brings to our operations 24 years of experiences as a Principal Network Engineer managing and supporting large-scale networks on a global scale. Amongst Josephโ€™s numerous achievements was the IP infrastructure conversion for a network of over 900 nodes and his major accomplishments within the field of VPN.

    • Jinghong Zeng

    Jinghong Zeng served more than 20 years with a global telecommunications cooperation as a Senior System Architect and Software Engineer, she has proven skills in data warehousing, data processing within distributed systems and a solid understanding of Blockchain.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4 months
    • Full-Time Equivalent (FTE): 2
    • Total Costs: 8,000 USD

    Milestone 1: Implement Substrate Modulesโ€‹

    • Estimated Duration: 2 months
    • FTE: 2
    • Costs: 4,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can running substrate to support storage service.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.Article/TutorialWe will publish an article and a tutorial that explains the work done as part of the grant.
    1a.Substrate module: Files BankWe will create a Substrate module that will generate file's tag information based on the user's subscription.
    1b.Substrate module: Files MapWe will create a Substrate module that will allow users to query file storage path.
    1c.Substrate module: Storage MinerWe will create a Substrate module that will process and upload user data, and support Integrity verification.
    2.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain.

    Milestone 2: Implement Storage Miningโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 2,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how proof of storage service works.
    0c.Testing GuideThe code will have unit-test coverage (min. 80%) to ensure functionality and robustness. In the guide we will describe how to run these tests.
    0d.Article/TutorialWe will publish an article and a tutorial that explains the work done as part of the grant.
    1a.Stacked DRG LibraryWe will create a library for proving and verifying transactions, compatible with the substrate pallet.
    1b.zk-SNARK proofsWe will implement the algorithm to process the proof results from stacked DRG library.
    2.Substrate module: Segment BookDevelop pallet implement function of storage mining.
    3.Miner ClientInteractive with pallet for storage mining to implement mining supporting services.

    Milestone 3: Implement and Integrate CESS Applicationsโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 2,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide an application manual and a basic tutorial that introduces the functions of clients.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness.
    0d.Article/TutorialWe will publish an article and a tutorial that explains the work done as part of the grant.
    1.Cryptographic modulesWe will implement the cryptographic modules including inner product functional encryption and the associated zero-knowledge proof for storage proof.
    2.UI ModulesWe will design a user-friendly UI that supports both PC and mobile.
    3.File processingWe provide abundant file operation services, including file upload, download, share, delete, etc.
    4.BenchmarkPerform unit tests on the individual algorithms to ensure system safety.
    5.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain.

    Future Plansโ€‹

    We will continue to improve the substrate-based CESS blockchain and provide reusable modules for the substrate FRAME. The next phase of our project is to implement CESS protocol for decentralized cloud on-chain data sharing platform.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We have heard from Parity Asia.

    What work has been done already? We have already implemented a design prototype and pilot test system.

    Have you ever applied for other grants? We have not applied for any other grants so far.

    - + \ No newline at end of file diff --git a/applications/CILA-omnichain-infrastructure.html b/applications/CILA-omnichain-infrastructure.html index f5ea80cd070..85c0bec0ba3 100644 --- a/applications/CILA-omnichain-infrastructure.html +++ b/applications/CILA-omnichain-infrastructure.html @@ -4,14 +4,14 @@ CILA - Omnichain Infrastructure | Web3 Foundation Grants - +
    Skip to main content

    CILA - Omnichain Infrastructure

    • Team Name: Collective Intelligence Labs
    • Payment Address: bc1qff0kjc6pyjkneyt3pctm5nahjpd9f774avz55x (BTC)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    The goal of this project is to implement an omnichain smart contract infrastructure support for Substrate framework. ๐ŸŒ๐Ÿค– This will include the implementation of CQRS + Event Sourcing execution environment plus an example smart-contract. The implementation will be done using WASM and/or native Rust Substrate implementation as a pallet. The implementation will include implementing Protobuf support on-chain, serialization/deserialization, aggregated repository, event store, command/operations dispatcher, and events emitter. ๐Ÿ› ๏ธ๐Ÿ‘จโ€๐Ÿ’ป

    Introductionโ€‹

    This project aims to add an omnichain smart contract infrastructure support for Substrate framework by implementing a CQRS + Event Sourcing execution environment. CQRS (Command Query Responsibility Segregation) is a design pattern that separates the command and query responsibilities of an application. Event Sourcing is a design pattern that represents the state of an application as a series of events that are stored in an event store. ๐Ÿงฌ๐Ÿ’ป

    Implementationโ€‹

    The implementation of the omnichain smart contract infrastructure will be done using WASM and/or native Rust Substrate implementation as a pallet. The implementation will include the following components:

    Protobuf support on-chainโ€‹

    Protobuf is a language-agnostic binary serialization format that allows developers to define structured data schemas. The implementation will include support for Protobuf on-chain, which will enable developers to define smart contract interfaces using Protobuf. ๐Ÿค–๐Ÿ’พ

    Aggregate Repositoryโ€‹

    Aggregate Repository is a data storage module that manages the state and storage of aggregate objects. It provides methods for creating, reading, updating, and deleting aggregates. ๐Ÿ“ˆ๐Ÿ“Š

    Event Storeโ€‹

    An event store is a database that stores events in the order they occurred. The implementation will include an event store, which will store all the events generated by the smart contract. ๐Ÿ—‚๏ธ๐Ÿ“‘

    Command/operations Dispatcherโ€‹

    A command/operations dispatcher is a component that receives commands/operations and dispatches them to the appropriate handler. The implementation will include a command/operations dispatcher, which will enable developers to define command/operation handlers for the smart contract. ๐Ÿšš๐Ÿ‘จโ€โœˆ๏ธ

    Events Emitterโ€‹

    An events emitter is a component that emits events. The implementation will include an events emitter, which will enable developers to define event handlers for the smart contract. ๐Ÿ“ฃ๐Ÿ”Š

    Conclusionโ€‹

    The completion of this project will provide a powerful infrastructure for developers to build customized omnichain smart contracts on the Substrate framework. ๐Ÿ’ช๐Ÿ‘จโ€๐Ÿ’ผ

    architecture

    ๐Ÿš€ Technology Stackโ€‹

    Programming Language - Rust ๐Ÿฆ€

    Blockchain Framework - Substrate โ›“๏ธ

    Virtual Machine - WebAssembly (WASM) ๐Ÿ•ธ๏ธ

    Serialization - Protocol Buffers (protobuf) ๐Ÿ“œ: a language-agnostic data serialization format that allows for efficient and interoperable communication between different services and systems.

    Design Patterns:

    • Event Sourcing ๐Ÿ“: a pattern that captures all changes to an application state as a sequence of events, which can be used to reconstruct the state at any point in time.
    • Command Query Responsibility Segregation (CQRS) ๐Ÿงฌ: a pattern that separates the read and write concerns of an application, using separate models and interfaces for each.
    • Saga pattern ๐ŸŒŸ: a pattern for coordinating distributed transactions across multiple services, ensuring consistency and reliability.
    • Domain-Driven Design (DDD) ๐Ÿฐ: a design approach that emphasizes the importance of the domain model in shaping the architecture of a software system.

    Database - MongoDB ๐Ÿ—„๏ธ: a NoSQL document database that provides scalability, flexibility, and high availability.

    Testing Framework - Rust Testing ๐Ÿงช: Rust has an inbuilt testing framework that enables testing of units of code in isolation.

    CI/CD - GitHub Actions ๐Ÿš€: a continuous integration and continuous deployment service that can automate the build and deployment processes.

    Containerization - Docker ๐Ÿณ: a tool that allows for the creation, deployment, and running of applications in containers, providing a consistent runtime environment across different platforms.

    Documentation for Core Copmpontents

    Dispatcher

    The Dispatcher is a component of the omnichain smart contract infrastructure that receives commands/operations and dispatches them to the appropriate handler. The Dispatcher class enables developers to define command/operation handlers for the smart contract.

    Usageโ€‹

    The Dispatcher can be used in the implementation of the CQRS + Event Sourcing execution environment for Substrate framework. It receives commands/operations from external sources, such as a client or a node, and routes them to the appropriate command/operation handler.

    To use the Dispatcher, developers first define a set of command/operation handlers for the smart contract. These handlers can be implemented as methods in a Rust struct. The Dispatcher class then instantiates this struct and routes commands/operations to the appropriate method based on the type of command/operation.

    Benefitsโ€‹

    The Dispatcher provides a simple and flexible way to handle commands/operations in the smart contract. By defining a set of command/operation handlers, developers can easily add new functionality to the smart contract without having to modify the Dispatcher class itself.

    In addition, the Dispatcher enables developers to implement complex business logic in the smart contract by routing commands/operations to the appropriate handler. This allows for a more modular and maintainable codebase.

    Conclusionโ€‹

    The Dispatcher is a crucial component of the omnichain smart contract infrastructure. By enabling developers to define command/operation handlers for the smart contract, it provides a simple and flexible way to handle commands/operations. Its usage in the implementation of the CQRS + Event Sourcing execution environment for Substrate framework enables developers to implement complex business logic in a modular and maintainable codebase.

    EventStore

    Descriptionโ€‹

    The EventStore is a database that stores events in the order they occurred. It is a crucial component of the omnichain smart contract infrastructure support for Substrate framework. The EventStore class enables the storage of all events generated by the smart contract, allowing for a complete historical record of all transactions and changes to the smart contract's state.

    Implementationโ€‹

    The EventStore is implemented using an internal Substrate database. The EventStore stores events in the form of serialized binary data plus metadata, which can be easily deserialized for querying and analysis.

    Featuresโ€‹

    The EventStore includes the following features:

    • Event storage: The EventStore stores all events generated by the smart contract in the order they occurred, allowing for a complete historical record of all transactions and changes to the smart contract's state.

    • Querying: The EventStore allows for easy querying of events using various criteria, such as time range, event type, or specific parameters.

    • Deserialization: The EventStore can easily deserialize stored binary data for querying and analysis.

    • Scalability: The EventStore can handle large volumes of events and is designed for scalability.

    Benefitsโ€‹

    The EventStore provides several benefits to developers building smart contracts on the Substrate framework, including:

    • Transparency: The EventStore provides a complete historical record of all transactions and changes to the smart contract's state, ensuring transparency and accountability.

    • Auditability: The EventStore allows for easy querying and analysis of events, enabling developers to audit the smart contract's behavior and ensure compliance with regulations and business rules.

    • Flexibility: The EventStore can handle a wide range of event types and is designed for scalability, providing flexibility for developers building smart contracts on the Substrate framework.

    Conclusionโ€‹

    The EventStore is a crucial component of the omnichain smart contract infrastructure support for Substrate framework. It provides event storage, querying, deserialization, and scalability features, enabling developers to build transparent, auditable, and flexible smart contracts on the Substrate framework. The completion of this project will provide a powerful infrastructure for developers to build customized smart contracts on the Substrate framework, with the EventStore serving as a key component of this infrastructure.

    Snapshot Store

    Overviewโ€‹

    The Snapshot Store is a component of the omnichain smart contract infrastructure that provides a way to store and retrieve snapshots of the smart contract state. A snapshot is a read-only view of the smart contract state at a particular point in time. Snapshots are useful for optimizing the performance of the smart contract by reducing the amount of data that needs to be read from the event store.

    Implementationโ€‹

    The implementation of the Snapshot Store includes the following components:

    • Snapshot Store: The Snapshot Store is the primary component. It provides an interface for storing and retrieving snapshots of the smart contract state.
    • Snapshot Index: The Snapshot Index is a data structure that is used to index snapshots by their version. It allows for efficient retrieval of the latest snapshot.
    • Snapshot Writer: The Snapshot Writer is a component that is used to write snapshots to the Snapshot Store. It receives the current state of the smart contract and writes it to the Snapshot Store as a snapshot.
    • Snapshot Reader: The Snapshot Reader is a component that is used to read snapshots from the Snapshot Store. It receives a snapshot version and returns a read-only view of the smart contract state at that version.

    Conclusionโ€‹

    The Snapshot Store provides a way to store and retrieve snapshots of the smart contract state, which can be used to optimize the performance of the smart contract. The implementation includes the Snapshot Store, Snapshot Index, Snapshot Writer, and Snapshot Reader components. The completion of this component will provide a pefrormance optmization for omnichain smart contracts on the Substrate framework.

    Aggregate

    The Aggregate is a core component of the CQRS + Event Sourcing design pattern. It represents the current state of an entity and is responsible for handling commands and producing events.

    Descriptionโ€‹

    An Aggregate is a stateful object that represents a single entity in the system. It maintains its state by applying events to its internal state. A new state can be generated by applying new events to the existing state.

    In the context of the Substrate framework, an Aggregate is implemented as a Rust struct that contains its internal state and a set of methods to apply events and handle commands.

    Implementationโ€‹

    The Aggregate is implemented using the following components:

    Internal stateโ€‹

    The internal state of an Aggregate is represented as a Rust struct. The struct contains all the data necessary to represent the current state of the entity.

    Command handlingโ€‹

    The Aggregate contains a set of methods to handle commands. These methods accept a command object as input and return a set of events that represent the result of executing the command.

    Event sourcingโ€‹

    The Aggregate implements event sourcing by maintaining a list of events that have been applied to the internal state. When a new command is received, the Aggregate applies the appropriate events to generate a new state.

    Snapshottingโ€‹

    The Aggregate implements snapshotting by periodically storing a snapshot of its internal state. When an Aggregate is retrieved from its event stream, it can be initialized with the latest snapshot and then apply only the events that occurred after the snapshot.

    Conclusionโ€‹

    The Aggregate is a core component of the CQRS + Event Sourcing design pattern. It represents the current state of an entity and is responsible for handling commands and producing events. The implementation of the Aggregate in the Substrate framework provides a powerful mechanism for building complex and scalable smart contracts.

    AggregateState

    The AggregateState represents the state of an aggregate object in the event sourcing pattern. It is responsible for maintaining the current state of the aggregate object by processing the events that have occurred in the past.

    Propertiesโ€‹

    • id: The unique identifier of the aggregate object.
    • version: The version of the aggregate object.
    • events: The list of events that have occurred in the past.

    Methodsโ€‹

    • apply_event(event): Applies the given event to the current state of the aggregate object. This method updates the state of the aggregate object based on the event that occurred.
    • get_version(): Returns the version of the aggregate object.
    • get_events(): Returns the list of events that have occurred in the past.

    Usageโ€‹

    To use the AggregateState , you must first create an instance of it and initialize it with the current state of the aggregate object. You can then apply events to the aggregate object by calling the apply_event() method.

    Diagrammโ€‹

    Architecture Overview Diagram Diagramm

    Flow Diagramm

    Diagramm

    Command Processing Flow Diagramm

     +------------+       +------------+       +-----------------+       +-------------------+       +------------+
     | Application|       |   Router   |       | Execution Chain |       |  Event Relay Node |       | Aggregation|
     +------------+       +------------+       +-----------------+       +-------------------+       +------------+
            |                    |                    |                            |                               |
            |   Command Request  |                    |                            |                               |
            |------------------>|                    |                            |                               |
            |                    |                    |                            |                               |
            |   Command Handler  |                    |                            |                               |
            |------------------>|                    |                            |                               |
            |                    |   Command Request   |                            |                               |
            |                    |------------------->|                            |                               |
            |                    |                    |  Execute Command (CQRS)    |                               |
            |                    |                    |--------------------------->|                               |
            |                    |                    |                            |     Store Event (ES)         |
            |                    |                    |                            |----------------------------->|
            |                    |                    |                            |                               |
            |                    |                    |                            |   Broadcast Event to        |
            |                    |                    |                            |     Other Chains            |
            |                    |                    |                            |--------------------------->|
            |                    |                    |                            |                               |
            |                    |                    |                            |  Transmit Event to          |
            |                    |                    |                            |     Aggregation Cluster     |
            |                    |                    |                            |----------------------------->|
            |                    |                    |                            |                               |
            |                    |                    |                            |   Process Events and        |
            |                    |                    |                            |     Produce Aggregated Data |
            |                    |                    |                            |<-----------------------------|
            |                    |                    |                            |                               |
            |                    |                    |                            |     Return Aggregated Data  |
            |                    |                    |                            |<-----------------------------|
            |                    |                    |                            |                               |

    API Documentation

    Domainโ€‹

    Aggregateโ€‹

    AggregateStateโ€‹

    Methodsโ€‹
    • new() -> Self: Creates a new instance of AggregateState.
    • apply_events(&mut self, events: Vec<DomainEvent>) -> Result<(), String>: Applies a list of domain events to the aggregate state.
    • clear(&mut self): Clears the state of the aggregate.

    DomainEventโ€‹

    Methodsโ€‹
    • new(evnt_type: DomainEventType, evnt_payload: Vec<u8>) -> Self: Creates a new instance of DomainEvent.
    • serialize(&self) -> Result<Vec<u8>, String>: Serializes the domain event to a byte array.

    DomainEventTypeโ€‹

    Variantsโ€‹
    • NFT_MINTED
    • NFT_TRANSFERED

    Entitiesโ€‹

    NFTโ€‹

    Fieldsโ€‹
    • hash: [u8; 32]: The unique hash of the NFT.
    • owner: Address: The address of the owner of the NFT.
    Methodsโ€‹
    • new(hash: [u8; 32], owner: Address) -> Self: Creates a new instance of NFT.
    • get_hash(&self) -> [u8; 32]: Returns the hash of the NFT.
    • get_owner(&self) -> Address: Returns the owner of the NFT.
    • transfer(&mut self, new_owner: Address): Transfers the ownership of the NFT to a new owner.

    Applicationโ€‹

    Commandโ€‹

    Commandโ€‹

    Fieldsโ€‹
    • cmd_type: CommandType
    • cmd_payload: Vec<u8>
    Methodsโ€‹
    • new(cmd_type: CommandType, cmd_payload: Vec<u8>) -> Self: Creates a new instance of Command.
    • serialize(&self) -> Result<Vec<u8>, String>: Serializes the command to a byte array.

    CommandTypeโ€‹

    Variantsโ€‹
    • MINT_NFT
    • TRANSFER_NFT

    Serviceโ€‹

    CommandDispatcherโ€‹

    Methodsโ€‹
    • dispatch(command: Command) -> Result<(), String>: Dispatches a command to the appropriate handler.

    NFTServiceโ€‹

    Fieldsโ€‹
    • state: NFTsState
    • event_store: Box<dyn EventStore>
    • dispatcher: Box<dyn CommandDispatcher>
    Methodsโ€‹
    • new(state: NFTsState, event_store: Box<dyn EventStore>, dispatcher: Box<dyn CommandDispatcher>) -> Self: Creates a new instance of NFTService.
    • handle_command(&mut self, command: Command) -> Result<(), String>: Handles a command by dispatching it to the appropriate handler.
    • get_nft_owner(&self, hash: [u8; 32]) -> Option<Address>: Returns the owner of an NFT with the given hash.

    Eventโ€‹

    DomainEventTypeโ€‹

    Variantsโ€‹
    • NFT_MINTED
    • NFT_TRANSFERED

    DomainEventโ€‹

    Fieldsโ€‹
    • evnt_type: DomainEventType
    • evnt_payload: Vec<u8>
    Methodsโ€‹
    • new(evnt_type: DomainEventType, evnt_payload: Vec<u8>) -> Self: Creates a new instance of DomainEvent.
    • serialize(&self) -> Result<Vec<u8>, String>: Serializes the domain event to a byte array.

    Storeโ€‹

    AggregateRepositoryโ€‹

    Fieldsโ€‹
    • event_store: Box<dyn EventStore>
    Methodsโ€‹
    • new(event_store: Box<dyn EventStore>) -> Self: Creates a new instance of `AggregateRepository

    ๐ŸŒŸ Ecosystem Fit: ๐ŸŒŸ

    ๐Ÿ”น Project's Fit: CILA will provide an infrastructure for building efficient omnichain smart contracts that can be integrated into the Polkadot ecosystem, offering a unique solution in the Substrate/Polkadot/Kusama landscape.

    ๐Ÿ”น Target Audience: Developers interested in building omnichain smart contracts on Substrate, Polkadot, and Kusama, particularly those looking to develop cross-chain applications and interact with multiple blockchain networks.

    ๐Ÿ”น Project's Purpose: The infrastructure will enable developers to build more efficient and scalable omnichain smart contracts, making it easier to create cross-chain applications that interact with multiple blockchain networks. This will help solve the problem of siloed blockchains and allow developers to take advantage of the benefits of multiple chains.

    ๐Ÿ”น Similar Projects: We are not aware of any other projects similar to OmniChain in the Substrate/Polkadot/Kusama ecosystem, offering a unique solution for building omnichain smart contracts.

    Team ๐Ÿฆพโ€‹

    Team membersโ€‹

    • ๐Ÿ‘จโ€๐Ÿ’ป Alex Shkor - Architect, Developer, Team Lead
    • ๐Ÿ‘จโ€๐Ÿ’ป Alexey Kulik - Architect, Developer
    • ๐Ÿ‘ฉโ€๐Ÿ’ผ Julia Shinkevich - Project Manager
    • ๐Ÿง‘โ€๐Ÿ’ผ Max Slyzkoukh - Product Manager
    • ๐Ÿ‘จโ€๐Ÿ”ง Yahor Tsaryk - Engineer

    Contactโ€‹

    • Registered Address: 16192 Coastal Highway, Lewes, DE 19958, United States.
    • Registered Legal Entity: Collective Intelligence Labs Inc.

    Team's experienceโ€‹

    Our team's extensive experience in blockchain development and past successful projects make us well-suited for this project. We have developed several blockchain-based platforms, including DeSci, which offers a decentralized scientific communication infrastructure, and IPledger, which registers intellectual property assets on the blockchain. We have also built a Proof of Share protocol for verification on a chain that specific files have been shared between parties, an on-chain grants distribution platform, a decentralized technology transfer platform, F-NFT and Event Proxy for Substrate, and other projects.

    Our team members have also contributed to open-source blockchain projects, demonstrating our commitment to the development of the blockchain ecosystem as a whole.

    Our Team Lead is distributed systems architect and has over 14 years of experience in this field, with one of our team members being the inventor of omnichain smart-contracts protocol, which is an important aspect of this project. Our Software Engineer has over 10 years of experience in distributed systems engineering and was the ex-CTO at DEIP and the creator of the Economy Protocol. Our Tech Lead has experience in distributed system and blockchain R&D and was the ex-Head of R&D at Paralect, while also having experience as an ex-CPO at DEIP. Our Head of Marketing has 9 years of experience in PR and communications, having worked with micromobility and web3 startups. Our Product Manager expert in digital transformation has 6 years of experience in the procurement of 50+ leading private and state Ukrainian enterprises.

    As a team, we have previously applied for a grant from the web3 foundation grants program for our DEIP project (DEIPWORLC Inc. legal entity). However, due to the constantly evolving market landscape and changing needs of the industry, we decided to pivot multiple times, and therefore did not deliver original proposal fully (only about 50% of it - onchain part). During the process we realized that on-chain IP management would not be possible without other infrastructure part. Therefore we decided to completely stop previous project, change our focus and start working on a diferent solution, the core solution that will make possible to implement DEIP and other our projects that rely on omni-chain infrastructure and onchain IP management - omni-chain infrastructure

    We believe that being transparent about our previous application and pivot is important. We want to assure the committee that we are committed to delivering the proposed solution for our current application, and that we are passionate about creating value in the blockchain ecosystem.

    We are confident that our team's expertise and experience in developing distributed systems and infrastructure will enable us to successfully execute our proposed CILA omnichain infrastructure project. We believe that this infrastructure is crucial for the growth and adoption of blockchain technology, and we are excited about the opportunity to contribute to this space.

    Team Code Reposโ€‹

    Team GitHub Profilesโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    CILA omnichain infrastructure for Substrate is currently in the research and planning phase. We have conducted extensive research on the existing smart contract infrastructure and identified the need for an omnichain smart contract solution. Our team has also analyzed the capabilities of the Substrate/Polkadot/Kusama ecosystem and determined that it is the ideal platform for building this solution.

    We have created a detailed project plan that outlines the development roadmap and milestones. This plan includes research and development of the necessary components.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 30,000 USD

    Milestone 1 โ€” Design and Implementationโ€‹

    • Estimated duration: 1 month
    • FTE: 2
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will ensure comprehensive documentation of the code by providing both inline comments and a step-by-step tutorial. This tutorial will guide the user through spinning up a Substrate-based execution environment for the CILA Omnichain Infrastructure and testing omnichain transactions, showcasing the new functionality.
    0c.Testing and Testing GuideWe will conduct comprehensive unit testing on the core functionalities including Aggregate, Event Store, Aggregate Repository, Snapshot Store, and Dispatcher, to ensure optimum functionality and robustness. The testing guide will contain instructions on how to execute these tests.
    0d.DockerWe will deliver Dockerfiles for testing all the functionality included in this milestone.
    1.Substrate module: AggregateThe Aggregate pallet provides the base functionality for implementing the Command Query Responsibility Segregation (CQRS) pattern on a Substrate-based blockchain. It defines the Aggregate trait, which is used to define the state and behavior of an Aggregate.
    2.Substrate module: AggregateStateThe AggregateState pallet provides a default implementation of the AggregateState trait, which stores the current state of an Aggregate in the blockchain's storage. This pallet is responsible for managing the state of an Aggregate and updating it based on incoming commands.
    3.Substrate module: AggregateRepositoryThe AggregateRepository pallet provides an implementation of the AggregateRepository trait, which is responsible for retrieving and storing Aggregates in the blockchain's storage. It allows developers to easily store and retrieve Aggregates from the blockchain's storage.
    4.Substrate module: CommandDispatcherThe CommandDispatcher pallet provides a way to dispatch incoming commands to the appropriate Aggregates based on their type. It uses a HashMap to store the mapping between command types and the Aggregates that handle them.
    5.Substrate module: EventStoreThe EventStore pallet provides a way to store and retrieve events that have been emitted by Aggregates. It allows developers to easily retrieve the events emitted by a specific Aggregate and replay them to reconstruct the current state of the Aggregate.
    6.Substrate module: EventsEmitterThe EventsEmitter pallet provides a way for Aggregates to emit events. It defines a trait that Aggregates can implement to specify the types of events they emit, and provides a way to subscribe to events emitted by specific Aggregates.

    Milestone 2 โ€” Testing and Documentationโ€‹

    • Estimated duration: 1 month
    • FTE: 2
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will ensure comprehensive documentation of the code by providing both inline comments and a step-by-step tutorial. This tutorial will guide the user through spinning up a Substrate-based execution environment for the CILA Omnichain Infrastructure and testing omnichain transactions, showcasing the new functionality. Special attention will be given to documenting the setup and testing of multiple Substrate chains running simultaneously, to test the synchronization of the state smart contract between them.
    0c.Testing and Testing GuideWe will conduct comprehensive unit testing on the core functionalities including Aggregate, Event Store, Aggregate Repository, Snapshot Store, and Dispatcher, to ensure optimum functionality and robustness. In particular, we will place emphasis on testing the infrastructure running with multiple chains to ensure that the synchronization mechanism is functioning as intended. The testing guide will contain instructions on how to execute these tests.
    0d.DockerWe will deliver Dockerfiles for testing all the functionality included in this milestone, including orchestration with multiple chains. For orchestration purposes we might use Kubernates.
    0e.ArticleWe will publish a technical article that details the implementation of the Command-Query Responsibility Segregation (CQRS) and Event Sourcing architecture on the Substrate framework. The article will provide an in-depth explanation of the design choices made and the challenges faced during the implementation. It will also include a detailed walkthrough of the codebase, highlighting key areas of interest and how they fit into the overall architecture. The article will be written in a technical language that targets developers with experience in blockchain and distributed systems.
    1.Substrate chainSet up and run multiple Substrate chains simultaneously to test the synchronization of a state smart contract between them. This will involve deploying the omnichain smart contract infrastructure to each chain and executing transactions on each chain to ensure that the contract state is properly synchronized between them. Additionally, various network conditions such as network latency and node failures will be simulated to test the robustness and reliability of the synchronization mechanism. The results of these tests will be recorded and analyzed to identify any potential issues and ensure that the synchronization mechanism is functioning as intended.
    2.Automated TestsWe will create and publish automated tests for critical infrastructure parts of Substrate-based CQRS + Event Sourcing execution enviroment. The aim of this test will be to test two cases - non conflicting execution (changes coming to one chain and transmitted to the other one), and conflicting transactions when the same aggregate is updated with two conflicing state changes that simuntaniusly come to different chans.

    Milestone 3 โ€” Example Smart Contracts and Enhancementsโ€‹

    • Estimated duration: 1 month
    • FTE: 2
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationProvide inline documentation of the NFTAggregate pallet and NFTAggregateState pallet code, as well as a basic tutorial that explains how a user can set up a Substrate node and send test transactions to test the NFT functionalities provided by these modules. Additionally, comprehensive unit tests will be developed and documented to ensure the functionality and robustness of the NFTAggregate pallet and NFTAggregateState pallet. A testing guide will also be provided, describing how to run the tests.
    0c.Testing and Testing GuideFor this milestone, we will develop comprehensive unit tests to cover the core functions of the NFTAggregate module and the NFTAggregateState pallet. These tests will be designed to ensure the functionality and robustness of the code. The unit tests will be included in the code repository and will cover a range of scenarios to ensure that the code is thoroughly tested. For example, we will test the minting, burning, and transferring of NFTs, as well as error handling and edge cases. In the testing guide, we will provide detailed instructions on how to run these tests, including any required dependencies and setup steps. We will also include information on how to interpret the test results and what to do in the case of failures or errors..
    0d.DockerIn order to facilitate testing and deployment of the NFTAggregate pallet and NFTAggregateState pallet, we will provide Dockerfiles that can be used to easily set up and configure a development environment. These Dockerfiles will include all the necessary dependencies and configuration to run the Substrate-based blockchain with the new functionalities.
    1.Substrate module: NFTAggregateThe NFTAggregate pallet provides a way to implement Non-Fungible Tokens (NFTs) on a Substrate-based blockchain. It defines a trait that NFT Aggregates can implement to specify the behavior of NFTs, including minting, burning, and transferring.
    2.Substrate module: NFTAggregateStateThe NFTAggregateState pallet provides a default implementation of the state of an NFT Aggregate, which stores the current state of NFTs in the blockchain's storage. This pallet is responsible for managing the state of NFTs and updating it based on incoming commands.
    3.Report: Substrate Ecosystem NFT standardsTo choose the most optimal standard for omnichain implementation we will conduct research and assess all the available NFT standards against two major criteria: popularity and technical quality. Popularity will be measured by the number of stars on the GitHub repository and how many projects are actually using it (usage assesment will be done on a best effort basis), and the technical quality will be assessed by analyzing if a specific standard satisfies SOLID design principles.

    Future Plansโ€‹

    In the short term, we plan to continue to develop and enhance our project to ensure its success and sustainability. This will include ongoing testing, bug fixes, and implementing additional features and improvements as needed. We will actively promote our project through various channels, including social media, blog posts, and community events.

    After the completion of the proposed infrastructure, we intend to continue its development by incorporating support for multiple blockchains and introducing more advanced functionalities, such as dynamic rebalancing for aggregates. Additionally, we plan to establish partnerships with leading players in the Substrate/Polkadot/Kusama ecosystem and to integrate our omnichain infrastructure with existing projects, such as DeFi and NFT marketplaces, to further increase adoption. Finally, we will provide comprehensive documentation and support to ensure that our infrastructure is accessible and user-friendly for developers and users alike.

    In the long term, we envision our project becoming a leading platform for event-centric CQRS + Event Sourcing execution environments and omnichain smart contracts on the Substrate blockchain. We plan to expand our team and further invest in research and development to stay ahead of the curve and meet the needs of the rapidly evolving blockchain industry. We will continue to engage with the community and seek feedback to ensure that our project remains relevant and valuable to users. Our ultimate goal is to create a platform that is widely adopted and helps to drive the mainstream adoption of blockchain technology.

    Additional Information โž•โ€‹

    mission

    How did you hear about the Grants Program? personal recommendation

    - + \ No newline at end of file diff --git a/applications/Calamar.html b/applications/Calamar.html index 6546ce6347f..218e26492f4 100644 --- a/applications/Calamar.html +++ b/applications/Calamar.html @@ -4,7 +4,7 @@ Calamar | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ https://calamar.app \ and we manage the code here: https://github.com/topmonks/calamar

    Based on the positive feedback we would like to push the project further and bring more valuable features for the users, closely cooperating with the Subsquid team and gathering an ongoing feedback from the users.

    While developing Calamar, we focus on UI and UX friendliness so that users enjoy dotsama chains exploring, as well as relevance of displayed data.

    Project Detailsโ€‹

    Calamar explorer will allow users to search and display various items and statistics.

    The plan is to have at least these features implemented:

    Homepageโ€‹

    Homepage with google-like search box and with links to chain dashboards.

    Home page

    Search where you don't have to know which chain the searched item belongs to. You just put the hash into the search box and the explorer will take care of the determining on which chain it is. This is going to be an addition to the ability to restrict search to a specific chain.

    Block detailโ€‹

    Display block's data and its extrinsics, transfers, calls and events.

    Extrinsic detailโ€‹

    Display extrinsic's data, its calls and events.

    Call detailโ€‹

    Display call's data, and its events.

    Event detailโ€‹

    Display event's data

    Search extrinsics and events by nameโ€‹

    Display a list of matching extrinsics and events by name.

    Account detailโ€‹

    As we are gathering feedback, one of the most important features for the users seems to be the account overview where users can find information about their balances and transactions across all chains.

    Account page

    Chain dashboardsโ€‹

    Each chain will have own dashboard with statistics and listing of latest blocks, latest transfers, top holders, etc. It makes the explorer more useful even for users who are not searching for specific items.

    Statistics page

    Metadata explorerโ€‹

    The runtime metadata of each chain are still evolving and changing but it is not so easy to display them in a structured and human-readable way. There is e.g. a tool https://wiki.polkadot.network/docs/metadata which displays them but only latest version and supports only a few networks. The metadata explorer we are going to implement will support all the networks and also historical versions of the runtime spec.

    Metadata explorer

    Item metadataโ€‹

    The metadata information will be deeply integrated into whole Calamar so we can display it in the detail pages of the items. E.g. in extrinsic's detail page we will show info for the call name, error, parameters and link to the metadata explorer for more info.

    Extrinsic metadata

    Search input autocomplete for call and event namesโ€‹

    Thanks to the metadata we can also autocomplete and suggest the call and event names when typing into the search input.

    Technology stackโ€‹

    Typescript, React, GraphQL

    Ecosystem Fitโ€‹

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    All of our team members developed the first version of Calamar explorer.

    Antonina Nesmelova is young and enthusiastic web-developer with 3,5 years experience with web applications development, including a year and a half of experience in the world of crypto: development of dApps and smart contracts.

    Richard Jedliฤka has several years of expertise in web applications full-stack development.

    Radek Jakl invented the design for Calamar. He has many years of experience in graphics and UI/UX design.

    Jan Lopusek co-founded the startup studio for TopMonks software house. He is experienced project manager and business developer

    Team Code Reposโ€‹

    Project referencesโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Current version of Calamar is running on https://calamar.app

    It is mostly a result of our participation in hackaton as an implementation of the bounty declared by Subsquid team. See Additional Information.

    For now, it allows users to:

    While it may seem to be already working explorer it has only basic features and lacks many of the important or useful ones. See Milestone 1 for details.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Core functionalityโ€‹

    Even though we have the already working application, there are still many things missing. Some of them prevent the users from using Calamar fully as the main explorer. We need to first assure the correct core functionality, display all the meaningful data which are retrievable without further complex processing, improve design and UX and integrate more into the Polkadot ecosystem.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation of the code where necessary, technical description of how to run the own instance of Calamar and tutorials how to use the application from the user perspective.
    0c.Testing GuideWe will provide end-to-end tests covering UI functionality.
    0d.DockerWe will provide a Dockerfile(s) for testing and running own Calamar instance.
    0e.ArticleWe will publish an article that explains what was done as part of the grant.
    1.Fix usage blockersFix things which block the app's real usage
    • search results are not shareable due to missing info about the chain in the URL
    • extrinsic's args are missing
    2.Add related items listingsAdd missing related items listing to detail pages
    • block's extrinsics, call and events
    • extrinsic's calls
    3.Add call detail pageSee Call detail.
    4.Add event detail pageSee Event detail.
    5.ResponsivenessImprove overall responsiveness for mobile devices especially of item tables and extrinsics/event args.
    6.Extrinsics/event args displaying improvementsAdd args display options: raw/json, human readable. Find a better way to show nested properties' data types.
    7.Items countCurrent implementation doens't show the total number of searched items. We would like to retrieve the items count and display it properly.
    8.Extrinsic/event case-insensitive search by nameAdd ability to search extrinsics and events by their name case-insensitive.
    9.Account address parsing in events argsDetect account address in event args and link it to the account detail (chain detected automatically).
    10.Website polishingAdd useful information to the website (footer with team logos, contact information, terms, etc.).
    11.Polkadot.js integrationCreate a PR to integrate links to the Calamar Explorer into Polkadot.js app.

    Milestone 2 - Account detail & Chain dashboardsโ€‹

    In this milestone we are going to improve account detail page and replace latest extrinsics page with proper dashboard page for each chain.

    Subsquid (data provider) might not support each feature for all chains at the time of the implementation, so the features will be implemented universally to support each chain whenever the data are provided in the future.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation of the code where necessary and user documentation for new features.
    0c.Testing GuideWe will provide end-to-end tests covering UI functionality.
    0d.DockerN/A - will be provided by the first milestone.
    0e.ArticleWe will publish an article that explains what was done as part of the grant
    1.Account / Balance overviewOverview of owned assets accross all listed chains with chain specific addresses, including dollar values
    2.Account / Balance chartsChart visualization of balance by assets and by type (reserved, tranferable, ...), including dollar values
    3.Account / Transfers listAdd account's transfers list table
    4.Account / Calls listAdd account's calls list table
    5.Account / Identity infoAdd account's identity information if set (name, twitter, ...)
    6.Chain dashboard / StatsShow chain's stats (blocks count, signed extrinsics count, total issuence, transfers count, holders count, total issuence, staked value, inflation rate, validators count) including USD values
    7.Chain dashboard / Asset value chartChart visualization of asset value by type (staked, circulating, other)
    8.Chain dashboard / Latest blocksAdd latest blocks list table
    9.Chain dashboard / Latest transfersAdd latest transfers list table
    10.Chain dashboard / Top holdersAdd top holders list table

    Milestone 3 - Universal search & Metadata explorerโ€‹

    In this milestone we are going to implement universal search and one of the most requested features: cross-chain transfers detection.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation of the code where necessary and tutorials on how to use new features.
    0c.Testing GuideWe will provide end-to-end tests covering UI functionality.
    0d.DockerN/A - will be provided by the first milestone.
    0e.ArticleWe will publish an article that explains what was done as part of the grant
    1.Universal searchSearch items through all the chains without the knowledge where it belongs. See Universal search.
    2.Metadata explorerUI interface for exploring metadata retrieved from network's latest and historical versions of runtime spec. See Metadata explorer.
    3.Show related runtime metadata in items' detailShow related metadata information directly in detail pages of individual items and interlink to metadata explorer. See Item metadata.
    4.Search input autocompleteAutocomplete extrinsic and event name in the search input. See Search input autocomplete for call and event names.

    Future Plansโ€‹

    There is a huge potential for future improvements which the Polkadot's community can benefit from.

    We would like to definitely display information about XCM transfers and teleports.

    As developers of most parachains implement their own custom modules/pallets it opens the opportunity to cooperate and customize Calamar explorer with UI/UX components and logic tailored to their needs.

    It relates to various XCM transactions which makes it even more complex and the more types will our explorer support the more it makes the users' lives easier.

    Another requests which came to us are:

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Personal recommendation

    - + \ No newline at end of file diff --git a/applications/Cere_Turnkey_Private_Blockchain_Network.html b/applications/Cere_Turnkey_Private_Blockchain_Network.html index b8a4a732333..e1d479c3ea2 100644 --- a/applications/Cere_Turnkey_Private_Blockchain_Network.html +++ b/applications/Cere_Turnkey_Private_Blockchain_Network.html @@ -4,13 +4,13 @@ Turn-key Private Standalone Blockchain Network | Web3 Foundation Grants - +
    Skip to main content

    Turn-key Private Standalone Blockchain Network

    • Proposer: Cere-Network
    • Payment Address: 1BbyAGddobdPgNo9c63xsRnwK5hen8pV7F

    Project Description ๐Ÿ“„โ€‹

    Cere Network is providing a turn-key Private/Permissioned/Standalone blockchain network which can be readily integrated by any enterprise. Since itโ€™s built with Substrate, this network can be integrated into any Polkadot/Substrate based Layer 1 network to serve as a secondary chain.

    This turn-key network intends to abstract the implementation complexity for businesses, as well as providing a ready-made package to optimize for a higher level of security, privacy, and performance, and to serve as a template or base-implementation of a highly customizable and performant enterprise specific blockchain network.

    Furthermore, any network built from or derived from this project will also be able to use derivative assets to represent real-world value transfers on-chain (e.g. micropayments, discount vouchers, loyalty points, etc), as well as being able to programatically issue these assets between user and application wallets.

    Below we have the overview of all the key features that this project will support:

    • A set of turn-key substrate based packaging and tools that simplifies the customization, configuration, testing, and deployment of such a blockchain network.
    • Pre-built solutions to create/assign/transfer derivative assets in business to consumer use cases.
    • Pre-configured and optimized for feeless transactions and performance.
    • Creation of custom derivative assets and automate the transfer to/from user wallets to app wallets by any/app brand.
    • Optimization of batch user onboarding and transaction processing for higher throughput situations needed for consumer apps/sites.

    Repository Hierarchy:โ€‹

    โ”œโ”€โ”€ Private Standalone Network (PSN) Node [link](https://github.com/Cerebellum-Network/private-standalone-network-node)
    โ”‚   โ”œโ”€โ”€ ./node ["PSN Node"]
    โ”‚   โ”œโ”€โ”€ ./scripts [Packaging & Deployment Scripts]
    โ”‚   โ”œโ”€โ”€ ./pallets [PSN Pallets]
    โ”‚   โ”‚       โ””โ”€โ”€ ./pallets/cere-ddc [Transfer Data Pallet (future)]
    โ”‚   โ”‚               โ””โ”€โ”€ Cere DDC service connector
    โ”‚   โ””โ”€โ”€ ./runtime [PSN Runtime Module]
    โ”‚           โ””โ”€โ”€ Included custom Cere DDC Pallet
    โ”‚
    โ””โ”€โ”€ Cere Enterprise Smart Contracts [link](https://github.com/Cerebellum-Network/cere-enterprise-smart-contracts)
        โ””โ”€โ”€ ./cere01 [Enterprise Derivative Assets]
             โ””โ”€โ”€ ./cere01/specification [CERE01 Standard definition]
             โ””โ”€โ”€ ./cere01/lib.rs [Implementation, Tests]

    There will be three primary directories in this repository:

    Node: A blockchain node is an application that allows users to participate in a blockchain network. Substrate-based blockchain nodes expose a number of capabilities like, Networking, Consensus, RPC Server.

    Runtime: The terms "runtime" and "state transition function" are analogous - they refer to the core logic of the blockchain that is responsible for validating blocks and executing the state changes they define. The Substrate project in this repository uses the FRAME framework to construct a blockchain runtime. FRAME allows runtime developers to declare domain-specific logic in modules called "pallets".

    Pallets: The runtime in this project is constructed using many FRAME pallets that ship with the core Substrate repository and a template pallet that is defined in the pallets directory. A FRAME pallet consists of a number of blockchain primitives namely, Storage, Dispatchables, Events, Errors and Trait.

    Team ๐Ÿ‘ฅโ€‹

    • Team Members: Evgeny Svirsky, Shivam C, Huy Thanh N
    • Team Website: https://cere.network/#/team
    • Code Repos: https://github.com/Cerebellum-Network/private-standalone-network-node.git
    • Website: http://cere.network/
    • Legal Structure: Delaware C Corp
    • Team's Experience:
      Evgeny has been one of the core developers on Cere team, where heโ€™s been instrumental in developing our blockchain network, tooling, and integrating with real-world applications.
      Shivam started programming at the age of 13, with roots in all-round programming. One of the first employees at Asiaโ€™s top cryptocurrency exchange, winner of multiple global hackathons and an early Blockchain adopter, believer and developer.
      Thanh has years of experience working with various blockchain projects ranging from Solidity smart contracts to enterprise integrations with Hyperledger and other networks.

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 9 weeks
    • Total Costs: 1.8 BTC

    Milestone 1โ€‹

    • Estimated Duration: 5 weeks
    • Costs: 0.8 BTC
    • Main Goal: Basic functionality: Private node, Smart Contract implementation and setup guide.
    NumberDeliverableSpecification
    1.Documentation and basic testsWe will provide README files inside repositories with instructions of how to build, deploy and test.
    2.Ink! based Smart Contract StandardWe are introducing a new smart contract standard which allows assets adaptable for real businesses to be programmatically created, managed, owned, transferred, and traded. It provides a template for establishing a foundation to capture common enterprise utility, and can be easily extended.. This standard is purposefully being built on top of Parityโ€™s ink! Smart contract framework.
    2a.Enterprise Derivative AssetsDerivative Asset support for the enterprise needs, with attributes such as expiration, limit on transfers, longitudinal unlocking, redemptions, etc
    2b.Manual Direct Wallet TransferSupport for most Substrate/Polkadot based wallet applications. Smart Contract transfer function allows for the directly wallet-signed transfer of assets from one application/user address to the other.
    2c.Programmatic Asset TransferSmart Contract transfer function allows for the programmatic/automated transfer of tokens from one application/user via smart contract to the other.
    2d.Asset RestrictionsSupport for the locking of assets by time or by issuer permission, support for expirations and potentially invalidations.
    3.Smart Contract TestsThe Smart Contract implementation will include unit tests, we will be using the off-chain test environment that ink! provides.

    Milestone 2โ€‹

    • Estimated Duration: 4 weeks
    • Costs: 1 BTC
    NumberDeliverableSpecification
    1.Supporting Fee AbastractionThis is an important feature to allow enterprises to conduct value transfers between app/user accounts without worrying about fees. This was moved from milestone 1 to milestone 2 to allow more testing with a couple of different approaches.
    2.Deployment packagingAt minimum the docker container or even the entire script that packages the container with the latest code from Substrate will also run on CI to test the deliverables of the milestone.
    3.TestingRepositories including the deployment and test sections for instructions and scripts to help contributors to package, deploy, run, test.
    4.(optional) Batch processingAllowing an app to optimize for creating asset transfers or data events to a batch of users at once, this would be a very nice to have from our practical experience.
    5.TutorialCere will provide written documentation as well as a video tutorial on how to integrate and use Cereโ€™s turnkey private blockchain networks for applications to showcase the ease of use.
    6.ArticleThe main topic/theme: โ€œ...Cere Network is providing a turn-key permissioned standalone blockchain network which can be readily integrated by any enterprise. Since itโ€™s built with Substrate, this network can be potentially integrated into any Polkadot/Substrate based Layer 1 network to serve as a secondary chain. Furthermore, any network built from or derived from this project will also be able to use derivative assets to represent real-world value transfers on-chain (e.g. micropayments, discount vouchers, loyalty points, etc), as well as being able to programatically issue these assets between user and application wallets...

    Community engagementโ€‹

    We will be producing a series of articles/tutorials and publish them on Medium and our community channels to highlight each milestone. More on our marketing strategy:

    Marketing strategy

    Additional Information โž•โ€‹

    Any additional information that you think is relevant to this application that hasn't already been included.

    Possible additional information to include:

    • What work has been done so far?
      • Many of the components in this project have already been created, yet they are not optimized or packaged in a way that can be readily used by anyone in the Polkadot/Substrate community.
    • Are there any teams who have already contributed (financially) to the project?
      • Yes, The Cerebellum Network team has been well-funded and supported by some of the top blockchain innovation institutions and investors.
    • Have you applied for other grants so far?
      • No.
    - + \ No newline at end of file diff --git a/applications/Claps.html b/applications/Claps.html index 3551b86580c..8c53830a41f 100644 --- a/applications/Claps.html +++ b/applications/Claps.html @@ -4,7 +4,7 @@ Claps Health | Web3 Foundation Grants - + @@ -30,7 +30,7 @@ Consent Tracking

    By implementing consent tracking smart contracts, organizations can demonstrate that they are following privacy regulations and that patients have control over their health data.

    Right to be forgottenโ€‹

    Claps Health does not store personal data on the blockchain and there is only random ID and hash code on chain. Individuals have more control over their data and can request deletion of the corresponding data in the database. Ensure that all personal data is securely deleted and no residual information remains that could be used to re-identify individuals.

    However, it is important to note that HIPAA/GDPR compliance involves a comprehensive set of rules and regulations for protecting health information. This proposal does not cover all of the guidelines such as physical access, governance of organizations..etc.

    Future Plansโ€‹

    Health Educationsโ€‹

    We are planning to expand Claps Health by developing a health education publishing service. This service will be available on our web backend and mobile app, and will allow healthcare providers to create and share educational content with their patients. By providing easy access to reliable health information, we hope to empower patients to take control of their health and wellbeing.

    Omni-Channel and Health data analyticsโ€‹

    We recognize that healthcare providers need a way to analyze large datasets to identify patterns in health behaviors and improve patient outcomes. To meet this need, we are planning to develop an omni-channel health data analytics service on our web backend. Based on patient Informed Consent Management

    Open AI Integrationโ€‹

    We are planning to integrate Open AI into Claps health mobile app in a second phase, after testing the market and gathering feedback. This approach allows us to minimize development costs and time in the first phase, while also gathering feedback and making sure that the features that we implement in the second phase are the most useful and needed.

    Expand Substrateโ€‹

    We are planning to build an omnichannel platform for pharmaceutical companies and healthcare related based on Polkadot Substrate for expanding the ecosystem, providing a more secure and private way of data management, better interoperability, automation and improved healthcare education communication.

    Additional Informationโ€‹

    Reference: https://www.ledgerinsights.com/blockchain-health-records-taiwan/ https://medium.com/dtco/blockchain-enabled-personal-health-record-os-challenges-opportunities-in-health-care-55161e3a5a32

    - + \ No newline at end of file diff --git a/applications/CoinFabrik_On_Ink_Integration_Tests.html b/applications/CoinFabrik_On_Ink_Integration_Tests.html index e371baa9a32..525ba173b09 100644 --- a/applications/CoinFabrik_On_Ink_Integration_Tests.html +++ b/applications/CoinFabrik_On_Ink_Integration_Tests.html @@ -4,7 +4,7 @@ CoinFabrik On Ink Integration Tests | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ 0.25 Tech Lead, 1 Full time Sr. Rust Developer, 1 Full Time SemiSr. Rust Developer)
  • Total Costs: 13,500 USD

    • Milestone 1: Analysisโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationCreate a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. The report's focus is to identify what can be accomplished in E2E tests but not currently in integration tests, as well as any inconsistencies. If applicable, we will provide suggestions that are not covered by either test type.
    0c.Testing and Testing GuideNo tests will be produced at this stage.
    0d.DockerDoes not apply at this stage.
    0e.ArticleWe will prepare a summary report and publish it on our blog https://blog.coinfabrik.com/
    1AnalyzeStudy and compare Integration and E2E (End-to-End) tests in ink!.
    2EvaluateAssign a complexity level to each finding based on the difficulty of implementing the missing or enhanced functionality.
    3EstimateIndicate an order of priority under which the missing functionalities shall be developed during the next milestone, where the functionalities are effectively implemented for integration tests.

    Future Plansโ€‹

    After finishing Milestone 1: Analysis, and having a good understanding of which missing functionalities in the integration testing environment can be developed, as well as an estimation of the effort required to develop them, we will submit a new grant proposal for a second milestone. The intention of this second milestone is to effectively implement these missing features. We detail in the table bellow its deliverables; its estimated duration is to be defined upon the delivery of the initial Analysis milestone.

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will update our previous report. This includes the current status of identified use cases.
    0c.Testing and Testing GuideWe will develop the missing functionalities identified, and submit a pull request to the corresponding repository. The newly developed functionalities will be documented and a testing guide will be included.
    0d.DockerDoes not apply at this stage.
    0e.ArticleWe will publish an updated report in our blog at https://blog.coinfabrik.com/.
    1DevelopBuild the necessary improvements and missing tests for the identified use cases outlined in the first milestone.
    2Analyze and EstimateIf applicable, suggest additional tests for this or next milestones.

    Moving forward, we have two projects in mind:

    1. Research and develop an advanced testing automation solution for ink! smart contracts.
    2. Improve our open source bug-detection tool Scout

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Richard Casey from Parity brought this program to our attention, and we have already successfully delivered two applications as a result.

    During our inquiries for this application, we briefly consulted Sam Ruberti from the ink! Team and David Hawig from the Web3 Foundation. Their encouragement motivated us to proceed with this presentation.

    - + \ No newline at end of file diff --git a/applications/CoinFabrik_On_Ink_Integration_Tests_2.html b/applications/CoinFabrik_On_Ink_Integration_Tests_2.html index d35fa2c4802..a2f1ff8549a 100644 --- a/applications/CoinFabrik_On_Ink_Integration_Tests_2.html +++ b/applications/CoinFabrik_On_Ink_Integration_Tests_2.html @@ -4,7 +4,7 @@ CoinFabrik On Ink Integration Tests 2 | Web3 Foundation Grants - + @@ -41,7 +41,7 @@ 1 Full time Sr Rust Developer, 1 Full Time SemiSr Rust Developer, 1 Full Time QA Specialist)
  • Total Costs: 30,000 USD

    • Milestone 1: Execution and Further Analysisโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on the functions to be implemented/corrected in this milestone, corresponding to issues 1-default_accounts(), 2-set_contract_storage() and 7-instantiate_contract().

    Documentation and test cases will be provided for the 13 functions with remaining analysis. If implementation differences are found in these functions, an estimate for their correction and an implementation idea will also be provided in our report.

    If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the env_access.rs file, but that could be related to integration or e2e testing.
    0c.Testing and Testing GuideThe newly developed functionalities will be documented and tested following existing contribution guidelines. A testing guide will be included.
    0d.DockerDoes not apply at this stage.
    0e.ArticleWe will publish an updated report summary in our blog at https://blog.coinfabrik.com/.
    1DevelopWe will develop the missing functionalities or correct implementation differences for functions 1-default_accounts(), 2-set_contract_storage() and 7-instantiate_contract(). All these implementations or modifications will be pushed into the ink! project repository following existing contribution guidelines.

    If applicable, we will develop additional tests or make ad hoc improvements to the ink codebase necessary for the completion of this milestone. Particularly for functions declared outside the env_access.rs file that might be related to integration or end-to-end testing.
    2Review and EstimateWe will review the remaining 13 unanalysed functions, which are implemented both for integration and e2e tests. For these functions we will provide documentation, a test case and an implementation estimation if applicable. These correspond to functions issue numbers 12 through 24.
    3Quality AssuranceWe will adhere to existing contribution guidelines and add necessary tests to integrate the new implemented or corrected functions to the ink! project repository.

    Future Plansโ€‹

    After finishing the Milestone 1: Execution and Further Analysis, we will submit a new grant proposal to continue with the implementation of the remaining functions. We will include specific references to developments associated with the estimations resulting from the further analysis of functions issue numbers 12 through 24.

    Next Milestone: Executionโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on the the functions to be implemented in this milestone, corresponding to issues 3-invoke_contract_delegate(), 4-invoke_contract(), 6-set_code_hash(), 8-caller_is_origin(), 9-code_hash(), 10-own_code_hash().

    Our report will also document the implementation of any missing functionalities, or correct implementation differences, for the 13 functions with issues 12 through 24. For this group, we will document any additional work that was required in order to ensure consistency between integration and e2e tests.

    If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the env_access.rs file, but that could be related to integration or e2e testing.
    0c.Testing and Testing GuideThe newly developed functionalities will be documented and tested following existing contribution guidelines. A testing guide will be included.
    0d.DockerDoes not apply at this stage.
    0e.ArticleWe will publish an updated report summary in our blog at https://blog.coinfabrik.com/.
    1DevelopmentWe will implement the missing functionalities or resolve implementation differences for function issues 3-invoke_contract_delegate(), 4-invoke_contract(), 6-set_code_hash(), 8-caller_is_origin(), 9-code_hash(), 10-own_code_hash().

    We will implement any missing functionalities, or correct implementation differences, for the 13 functions with issues 12 through 24. For this group, we will document any additional work required in order to ensure consistency between integration and e2e tests.

    All these implementations or modifications will be pushed into the ink! project repository following existing contribution guidelines.

    If applicable, we will develop additional tests or make ad hoc improvements to the ink codebase necessary for the completion of this milestone. Particularly for functions declared outside the env_access.rs file that might be related to integration or end-to-end testing.
    2Quality AssuranceWe will adhere to existing contribution guidelines and add necessary tests to integrate the new implemented or corrected functions to the ink! project repository.

    Moving forward, we have two projects in mind:

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Richard Casey from Parity brought this program to our attention, and we have already successfully delivered two applications as a result.

    During our inquiries for this application, we briefly consulted Sam Ruberti from the ink! Team and David Hawig from the Web3 Foundation. Their encouragement motivated us to proceed with this presentation.

    - + \ No newline at end of file diff --git a/applications/Coinversation.html b/applications/Coinversation.html index c99c8fccd57..0b89f4f9ad0 100644 --- a/applications/Coinversation.html +++ b/applications/Coinversation.html @@ -4,13 +4,13 @@ Coinversation Protocol | Web3 Foundation Grants - +
    Skip to main content

    Coinversation Protocol

    Project Overview ๐Ÿ“„โ€‹

    Coinversation Protocol is an open financial platform integrating stablecoin, synthetic asset issuance, collateral lending, decentralized contract exchange and Polkadot bridge. Coinversation Stablecoin is a very important part of it. Coinversation is committed to making breakthrough contributions to the stablecoin and DeFi in the Polkadot ecosystem.

    Overviewโ€‹

    The stablecoin created by Coinversation Protocol is decentralized, multi-asset collateralized, supports cross-chain, and supports real-world asset access through Polkadot bridge. The biggest difference between it and the past decentralized stablecoins is that there are no stability fees or interest, but stablecoins are issued in a synthetic asset collateral pool. Therefore, the cost that users pay to generate Coinversation Stablecoin (cUSD) through collateral is determined by the relative change of all synthetic assets in the entire system, rather than artificial regulations in previous decentralized stablecoins (e.g. Dai). This cost is more market-oriented, and at the same time it is equivalent to the inflation rate of stablecoin to world assets. In general, the stable currency cUSD and the synthetic asset issuance and contract exchanges in the Coinversation Protocol constitute a complete Defi system in the Polkadot ecosystem. In addition, we can access alliance chains such as AntChain and HyperChain through Coinversation's own bridge to realize access to various real-world assets. This will not only enrich the collateral for this project, but also enrich the range of assets in the entire Polkadot ecosystem through cross-chain.

    Project Detailsโ€‹

    The main functional modules of the entire system include: Polkadot bridge, forging synthetic assets(MintC), DEX, collateral pools, fee pools, oracles, and liquidity mining.

    Coinversation architecture diagram

    Polkadot Bridgeโ€‹

    This bridge connect several alliance chains, such as AntChian and HyperChain, into Coinversation Protocol and Polkadot ecosystem. So assets on those chains can be used as collateral to issue stablecoin and synthetic assets. Meanwhile, Coinversation Stablecoin can also provide liquidity for those assets through cUSD lending.

    Forging Synthetic Assets(MintC)โ€‹

    The synthetic assets issued by the entire system are all produced by users staking certain collateral. The initial collateral includes CTO and DOT, and the collateralization ratio is 800% and 500% respectively. In the future, the collateral and collateralization ratio can be adjusted through community governance. When users stake collaterals and forge synthetic assets, corresponding debts are generated. When the user wants to unlock the collateral, he must repay the debt, that is, destroy the previously generated synthetic assets.

    cUSDโ€‹

    At present, it is stipulated that the assets synthesized by direct staking of collateral are the stablecoin cUSD. That is, after users stake the CTO or DOT, the directly generated synthetic asset is cUSD, while other synthetic assets need to be converted by the user through contract trading in DEX. The price of cUSD is always defined as $1 throughout the system. All cUSD generated by all users is the total liability of the entire system, priced in cUSD.

    Through contract trading, cUSD can be converted into any synthetic assets supported by the system, such as cBTC, cETH, and even cAAPL, cXAU linked to traditional assets such as stocks and gold, and supports long or short. The types of synthetic assets can be added by community governance. It should be noted that if the user simply holds cUSD after minting, it is equivalent to automatically shorting all other assets in the system.

    DEXโ€‹

    It is an exchange that provides conversion of different synthetic assets and contract trading. Due to the design characteristics of CP, this DEX does not require a counterparty, and there is no issue of transaction depth.

    Collateral Poolโ€‹

    The collateral pool is the sum of synthetic assets generated by all users, and is priced in cUSD. According to the amounts of synthetic assets generated by each user, the debt pool also records the proportion of each user's debt. Whenever a new synthetic asset is generated, the debt ratio of the system must be recalculated.

    Fee Poolโ€‹

    Users trading or converting synthetic assets on the DEX will incur transaction fees. The fee ratio is tentatively set at 0.3%, and these fees all enter the fee pool. The fee is collected in cUSD, and all the fees are distributed to users in proportion to the debt. The system stipulates that only users whose collateral is the CTO can receive rewards, as an incentive for CTO holders. Because the CTO price fluctuates, it is stipulated that only users who meet the collateralization ratio are eligible to receive rewards.

    Oracleโ€‹

    Since the price of contract trading needs to be read from outside sources, the oracle is a very critical part of this project. In the initial stage, the system will use the centralized oracles provided by the project team, and in the future, it will introduce more secure decentralized oracles.

    Liquidity Miningโ€‹

    Liquidity mining is the module of issuing CTO tokens. Users can lock CTO or DOT here to get the rewards of CTO. The proportion of rewards obtained by CTO and DOT is different. It also stipulates that users who lock their tokens for liquidity mining must also put a corresponding proportion of CTO or DOT in the collateral pool to mint synthetic assets, to provide more liquidity for the entire system.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Qiuye, team leader, PhD in Economics, major in Macroeconomics including currency, finance and exchange rates. Mainly focuses on cryptocurrency and is committed to exploring the fundamental changes that cryptocurrency brings to traditional economic theories.

    Team Websiteโ€‹

    • Crypto Geeks Capital Ltd.
    • No.977 Wenyi West Road, Yongfu Community, Wuchang Street, Yuhang District, Hangzhou City, China

    Team's experienceโ€‹

    Founded by a US PhD team, the core members are from first-tier technology companies such as Alibaba, ANT Group, Google. More than 70% of the team members have a Master degree or a PhD degree, and many of them have more than ten years of development experience and are early developers of Ethereum.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 6 months
    • Full-time equivalent (FTE): 3
    • Total Costs: 0.6 BTC

    Milestone 1 โ€” the minting center for minting and destroying cUSDโ€‹

    • Estimated Duration: 3 months
    • FTE: 3
    • Costs: 0.3 BTC
    NumberDeliverableSpecification
    1.oracleComplete the oracle function by an off-chain worker.
    2.forging centerRealize the functions of staking DOT and CTO by ink! Smart Contract, forging synthetic assets, including cUSD, cBTC, cETH, cAAPL, cXAU, etc.
    3.TestingThe code will have proper unit-test coverage to ensure functionality and robustness.
    4.TutorialThe tutorial will not only indicate that how to use set up and deploy it into the ink! module, and also introduce special user cases and potential extensibility.

    Milestone 2 โ€” a decentralized exchange for trading synthetic assetsโ€‹

    • Estimated Duration: 3 months
    • FTE: 3
    • Costs: 0.3 BTC
    NumberDeliverableSpecification
    1.collateral poolRealize the collateral pool function by ink! Smart Contract: When a user newly generates or destroys cUSD, the debt ratio is re-determined, and the user's profit is calculated based on the change in asset prices.
    2.fee poolRealize the function of fee pool by ink! Smart Contract: transaction fees are included in the fee pool to complete the benefit distribution of CTO users. Allow users to view the debt ratio, total system debt, balance of personal synthetic assets, rewards income, etc.
    3.decentralized contract exchangeRealize the trading function on the Web end, allowing users to freely trade various synthetic assets. It is convenient for users to stake CTO or DOT to mint cUSD and destroy cUSD.
    4.TestingThe code will have proper unit-test coverage to ensure functionality and robustness.
    5.TutorialThe tutorial will not only indicate that how to use set up and deploy it into the ink! module, and also introduce special user cases and potential extensibility.

    Future Plansโ€‹

    There is still a lot of space for growth in the future, including:

    At present, the type of synthetic assets of the project is determined by the project team or community governance. In the future, it is planned to upgrade so that different investors can independently sign any type of contract on this system.

    At present, the stablecoin cUSD or other synthetic assets produced by the project are limited to the system. When there are standardized tokens similar to Ethereum ERC-20 on the Polkadot in the future, all synthetic assets of this project can be circulated outside the system in the form of standardized tokens, and even enter other exchanges. Among them, cUSD can become an important stable currency in the Polkadot ecology.

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/Contract_wizard.html b/applications/Contract_wizard.html index c920fe8bd54..87e1323b9e3 100644 --- a/applications/Contract_wizard.html +++ b/applications/Contract_wizard.html @@ -4,7 +4,7 @@ Polkadot Contract Wizard | Web3 Foundation Grants - + @@ -54,7 +54,7 @@ As we continue to develop our platform, we understand the importance of building a community around it. We believe that by creating a community of users, we can facilitate the sharing of knowledge, contracts, and different approaches to problem-solving. Through our platform, users will have the ability to share their experiences, ask questions, and engage with others within the community. This will create an environment that fosters innovation and encourages collaboration, leading to the development of new and exciting ideas. Our hope is that our platform will serve as a hub for all things smart contract-related, where users can come together to learn, grow, and innovate.

    Custom contracts

    Social Interaction

    Additional Information โž•โ€‹

    โ€‹ How did you hear about the Grants Program?

    Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/CosmWasmVM-CoreProduct.html b/applications/CosmWasmVM-CoreProduct.html index 9da323c3a4e..3a466d7d76e 100644 --- a/applications/CosmWasmVM-CoreProduct.html +++ b/applications/CosmWasmVM-CoreProduct.html @@ -4,7 +4,7 @@ CosmWasm VM - Core product | Web3 Foundation Grants - + @@ -39,7 +39,7 @@ We utilized the Wasmd reference material to rewrite the Go portions of CosmWasm in Rust for implementation on our parachains.

    high_level_overview

    Ecosystem Fitโ€‹

    CosmWasm would be able to facilitate the orchestration of cross-chain smart contracts between different parachains.

    Our target audience consists of parachain builders, and dApps in the Dotsama ecosystem that want to leverage a WASM based smart contracting framework. We hope this VM enables and incentivizes developers to build in the Polkadot ecosystem as CosmWasm has been adopted by a large developer community.

    We are the only team in the Substrate/Polkadot/Kusama ecosystem implementing CosmWasm for Substrate.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Team Code Reposโ€‹

    GitHub accounts of all team members:

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    https://medium.com/supercolony/a-look-into-virtual-machines-and-smart-contract-runtimes-313cd7d494e3

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Pallet CosmWasm VMโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3 / MIT /
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can test and execute transactions using cosmwasm vm pallet.
    0c.Testing GuideCore functions will be fully covered by integration tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test the pallet functionality.
    1a.DevelopmentWe will deliver the core pallet for the CosmWasm VM
    1b.DevelopmentThis milestone includes the pallet supporting the following features: XCM integration, native asset support, allow calling extrinsics, verification through Fuzzing & Kani and Benchmarking.
    1c.TestingA local network setup running a substrate chain with the pallet and a contract showing the functionality described in the milestones, so that it can be inspected and called through Polkadotjs.org.

    Milestone 2 โ€” PolkadotJS Integrationโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3 / MIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how contracts interact with PolkadotJS.
    0c.Testing GuideCore functions will be fully covered by integration tests to ensure functionality and robustness.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone
    0e.ArticleWe intend to publish an article which outlines what was achieved as part of the grant, how it benefits the Substrate ecosystem and how other parachains can utilize the pallet.
    1.DevelopmentThis milestone would include PolkadotJS support querying contractsโ€™ state and interacting with CosmWam contracts

    Future Plansโ€‹

    Composable is continuing to contribute upstream, further pushing the boundaries of cryptographic research and opening up endless possibilities for the Dotama ecosystem as we work in line with our cross-chain/cross-layer interoperability goals.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Web3 Foundation Medium and Twitter

    - + \ No newline at end of file diff --git a/applications/Crowdloans-FET.html b/applications/Crowdloans-FET.html index cbe7ffe9c5f..bcb489434f1 100644 --- a/applications/Crowdloans-FET.html +++ b/applications/Crowdloans-FET.html @@ -4,13 +4,13 @@ The CrowdloanFET Project | Web3 Foundation Grants - +
    Skip to main content

    The CrowdloanFET Project

    • Team Name: Mutai Solutions
    • Payment Address: 0xE27F2E8321Fb4c32525a4ED86d2902dbA63491E4 Ethereum (USDT)
    • Level: 1
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    This application is response to the Crowdloan Front End Template RFP

    The CrowdloanFET project is a free and opensource white-label solution for Polkadot projects to showcase the Crowdloan to prospective and current project supporters and community members.

    Built using Nextjs, Tailwind and Polkadotjs, projects can easily configure/modify and deploy a frontend for their crowdloan campaign, either on their own infrastructure that supports node or on affordable/free platforms like Vercel.

    The template will come with an unopinionated style and will provide the appropriate information architecture for different projects to add on top of and apply their own brand assets.

    Project Detailsโ€‹

    Technology stack overview:โ€‹

    • Framework: Next.js, built using Typescript
    • Styling and branding config: Tailwind
    • Wallet/on-chain data & network interactions: Polkadotjs

    Configuration:โ€‹

    To make the template generic & simple to configure, we shall use 3 main points of modifation:

    • Markdown Files - To populate the project copy thorough various sections of the template
    • .ENV configuration file - To configure various settings that may be required for querying data on-chain and various other uses around the template. A few config variables to include would be: PARA_ID, HOMEPAGE_LINK, DISCORD_INVITE_LINK, TWITTER_ACCOUNT_USERNAME, BLOG_LINK, etc
    • Tailwind.config.js - To configure key branding aspects. e.g Colours, Font, etc

    These as well as further configuration steps shall be outlined the accompanying documentation and tutorial article.

    Mockups:โ€‹

    Project Overview/Description Sectionโ€‹

    Wireframe

    image.png

    Example Mockup

    image.png

    Crowdloan details & timeline Sectionโ€‹

    Wireframe

    image.png

    Example Mockup

    image.png

    Crowdloan Rewards Section:โ€‹

    Wireframe

    image.png

    Example Mockup

    image.png

    Crowdloan Contributions Section:โ€‹

    Wireframe

    image.png

    Example Mockup

    image.png

    Competing crowdloans Section:โ€‹

    Example Mockup

    image.png

    FAQ Section:โ€‹

    Example Mockup

    image.png

    Ecosystem Fitโ€‹

    As outlined above in the Project Overview, this project is targeted toward project maintainers and their respective communities/contributors that are undertaking a crowdloan campaign. This ideally would help with eliviating some of the workload on the project maintainers while also providing conclusive visibility of a crowdloan to the wider Polkadot ecosystem at large and an easy approach to contributing to it.

    Similar implementations/projects:

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Bryan Mutai : Full-Stack developer and web designer

    Contactโ€‹

    • Registered Address: 90 JGO, James Gichuru Road, Lavington, Nairobi, Kenya - P.O.Box 1669-00100 Nairobi GPO
    • Registered Legal Entity: Mutai Solutions

    Team's experienceโ€‹

    I studied software engineering at the University of Glasgow, I currently have 5 years experience in web design & development and have been working as a freelance web developer, working in various programming languages (Typescript/Python) and in various frameworks and libraries (React/Angularjs/Django). Over the past 2 years I have also been contributing towards various blockchain related opensource projects. Recently in particular:

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1 Month
    • Full-Time Equivalent (FTE): 1
    • Total Costs: 5,600 USD

    Milestone 1โ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: 5,600 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can deploy an instance of the template for their project
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains the core functionality of the template and intended use as well as a step by step tutorial targeted towards developers on how to configure, modify & deploy the template on a popular hosting platform like Vercel
    1.Template User interface implementationI will design and implement the template UI using Tailwind in the Nextjs framework. The user interface will include: Project information, rewards schema, current contributions, time left in the crowdloan and information on the contribtions made after the crowdloan ends as shown simulated in the mockups above
    2.Contribution form & interactionA simple interface for users to contribute directly through the deployed template through the entire cycle contribution, handling both a finalised contribution as well as any encountered errors
    3.Example User interfaceUsing the output from 1 & 2 I will create a sample crowdloan deployment that would be the result of implementing the Front End template following the steps outlined in the output from 0d.

    Future Plansโ€‹

    • Core maintainance of project, such as critical bugs and security updates
    • Implementing/merging community suggestions/Pull Requests on features that could help improve the experience of both deploying and using the template.
    • Collecting feedback from projects that consider/use this template.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/DAOsign.html b/applications/DAOsign.html index 6748732a88d..5c58be5463e 100644 --- a/applications/DAOsign.html +++ b/applications/DAOsign.html @@ -4,7 +4,7 @@ DAOsign | Web3 Foundation Grants - + @@ -34,7 +34,7 @@ Experience with enterprises and startup companies, scaling teams, and building blockchain products. Previous blockchain projects include:

    Misha Kushka: Tech Lead and Blockchain Developer Background: 6+ years of professional experience as a developer, 4+ years of professional experience in the Blockchain field, 4+ years experience as a lead

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We are currently working on a tech demo (kind of a pre-beta version) and non-blockchain version of DAOsign is available here: https://testnet.daosign.org

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 - Smart Contract Developmentโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use DAOsign Smart Contract developed in ink! for proof verification.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains what was done as part of the grant. And we will publish a series of articles that explains how DAOsign works from a high-level perspective. The content of the articles will be consistent with the functions at this stage.
    1.Smart ContractsDAOsign Smart Contract repo that includes following components: Agreement Contract, EIP712/EIP2771 standard implementation on Ink!. These smart contracts can be deployed to any substrate chain with contracts-pallet.

    Milestone 2 - DAOsign Application integrationโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness.
    0d.DockerDockerfile(s) provided in Milestone 1 will be used to test all the functionality delivered with this milestone.
    1.DAOsign Ink! JS SDKWe will publish a npm/yarn package with the logic how to interact with Smart Contract from JS
    2.DAOsign Application IntegrationIntegrate DAOsign application using SDK. DAOsign application (which is not part of this grant) will be open sourced as well. DAOsign is written using ReactJS on frontend and Typescript on backend

    Milestone 3 - Relayer Developmentโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can run Relayer and broadcast transactions
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Gas RelayerOff-chain component for relaying transactions. Will be developed on Typescript/NodeJS using polkadot.js library

    Future Plansโ€‹

    After the ink! version of the DAOsign protocol stack is fully tested, we would like to implement a pallet version for Polkadot ecosystems. Anyone who is integrating it can communicate with other ecosystems conveniently.

    Add support for multi-chain proof verification using XCM and IBC protocols.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    By recommendation of Richard Casey from Parity.

    - + \ No newline at end of file diff --git a/applications/DIA_Bridge_Attestation_Oracle.html b/applications/DIA_Bridge_Attestation_Oracle.html index 1796110e5c7..0e6520a389d 100644 --- a/applications/DIA_Bridge_Attestation_Oracle.html +++ b/applications/DIA_Bridge_Attestation_Oracle.html @@ -4,14 +4,14 @@ Bridges Attestation Oracle | Web3 Foundation Grants - +
    Skip to main content

    Bridges Attestation Oracle

    • Team Name: DIA Data
    • Payment Address: 0xC13233bd20a7FcB1d7c2394AdE4857b778382264 Ethereum. Preferred currency - USDC (0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48).
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Decentralized, on-chain bridge attestation oracle for Polkadot using off-chain workers

    Over the last few years, bridges have been the target of a number of high profile hacks. According to the rekt.news 'hack leaderboard', 4 of the top 5 hacks in terms of USD value lost were attacks on bridges (total $2.2 billion lost amongst these 4 hacks). Despite many efforts to develop more robust and secure bridge architectures, there is no industry-wide tooling available for protocols to bolster their security in case a bridge is hacked. This is why we aim to to develop a decentralised, real-time bridge status update oracle that will help protocols in the Polkadot ecosystem protect their operations and customer funds.

    Bridge Attestaion Oracle Solution Overview

    Our approach is to introduce on-chain verification of bridge balances on the Polkadot network using off-chain workers. The main idea behind this is that all dapps operating on Polkadot parachains will be able to integrate this security module, enabling them to trigger automated precautionary notifications and actions in case bridge balances unexpectedly drop. We achieve this by tracking bridges' locked asset vs issued assets across multiple chains. This allows us to calculate a collateral ratio, which protocols can use to define and trigger safety procedures in their code when the specified conditions are met.

    The DIA team has already gained experience with collateral ratios, while creating fair value price feeds for Liquid Staked Tokens in the Polkadot ecosystem and beyond (more info here). The bridge attestation oracle would be specifically designed for use in the Polkadot ecosystem. Being a crosschain oracle by nature, we perceive a significant benefit in the proposed solution, because using the collateral ratio in the determination of asset prices that use bridges to bring liquidity to multiple blockchains enables the calculation of fair value prices.

    Project Detailsโ€‹

    Architecture overviewโ€‹

    The proposed project consists of a few core components that are to be developed.

    First, an overview regarding the data structures needed to represent bridge states:

    Asset:
        Address  string
        Chain    string
        Decimals uint
        Symbol   string
        Name     string
        
    BridgeSet:
        LockedAssets  []Asset
        MintedAsset   Asset
        LockedAmounts []uint
        MintedAmount  uint

    Bridge:
        Sets []BridgeSet

    Note that BridgeSet is directional, so a bridge can hold a set twice in both directions if needed. By that, we can track minted and locked pairs in an omnidirectional way. Also note, that a BridgeSet mints one token but can access several locked assets on different source chains.

    With these in mind, the following components are proposed:

    1. An off-chain worker which reads bridge states: This component is used as an adapter between bridge states and the target parachain. It is used to read the amounts of locked assets from specified addresses (the bridge reserve addresses).
    2. A token identification system which identifies matching tokens across multiple chains (i.e. both sides of each bridged asset). Identification requires that for an asset at least the chain and the address are defined.

    An example flow on the token identification within the proposed system could look like this:

    1. Read bridge-locked tokens on multiple source blockchains with RPC calls.
    2. Compute total amount of locked tokens by adding the values from the previous calls.
    3. Determine the amount of issued tokens on the target network.
    4. Perform calculation MintedAmount - Sum([]LockedAmounts).
    5. Output values of number of issued tokens, number of locked tokens and collateral ratio values.

    All components will be available open-source to enable access to any dapp/protocol that intends to integrate this or further develop the components. Also, a standard format (similar to the defined data structures above) will be developed to facilitate integrations of future bridges.

    Technology stackโ€‹

    • Pallet & off-chain workers will be the main enabler of the entire solution, reflecting Polkadot's native feature of off-chain workers integrated with pallets.
      • Rust programming language will be used to develop the pallet and the off-chain worker.
    • RPCs will be the main gateway for querying data from different chains. As RPCs represent single points of failure, they will be implemented using the following logic:
      • Only publicly available RPCs will be used to circumvent private key management hurdles for publicly accessible solutions. If technically possible, we would enable the pallet integrator to choose their own private RPCs, if they prefer this.
      • We will set-up a back-up system of at least 2 additional public RPCs in case one RPCs fails.
      • We will set-up backstops for generating collateral value in case at least one of the RPCs fail.

    Hosting and infrastructure will be organized as follows:

    The main repository will be available on Github. Pre-built instances of our container images will live in Docker Hub for everyone to download. We seek to implement a CI/CD system that automatically builds and publishes latest changes so that anyone can use the latest version with ease and integrate fetching the latest version in their automation flow as well. Due to the decentralized nature of the proposed architecture, only the token identification data needs to be hosted centrally. For that, we will either extend existing community directories or build our own, with hosting the resulting identification files on github as well.

    We will also host documentation on how to use and participate in the system.

    MVPโ€‹

    Our MVP will consist of four main parts:

    1. The pallet providing collateral value that can be integrated by parachains
    2. The documentation of integration
    3. Integration of 2 bridges
    4. Guidelines on integrating new bridges

    Expectationsโ€‹

    Team DIA will:

    • Create the framework and open-source the library of this integration.
    • Integrate 2 bridges for initial use. Further integrations will be open for submissions from contributors.

    We will not:

    • Cover a security audit as a part of MVP design.

    Ecosystem Fit (Requirements)โ€‹

    Overviewโ€‹

    The Polkadot ecosystem is a natural fit for this solution for several reasons:

    • Polkadot is a network of numerous parachains which utilize XCM for trustless and secure communication without relying on bridges. However, to achieve the vision of interoperability with external chains, bridge monitoring and attestation are necessary to establish trust and ensure the integrity of the transactions between the networks.
    • The entire architecture of the product is tailored specifically to the Polkadot ecosystem due to it's unique ability of executing computational programs via off-chain workers.
    • The tool adds significant value for a variety of Polkadot ecosystem actors - parachains, dapps, bridges, oracles and others.
    • The tool aims to serve as a public good on Polkadot, therefore will benefit anyone that integrates it.

    Target audienceโ€‹

    We have identified our target audience as follows:

    • Parachains are the target facilitator that will enable the adoption, but they also stand to benefit from integration themselves as the tool enables them to track bridges' security on a chain level.
    • DeFi dapp developers (e.g., lending protocols) are the main beneficiaries. We expect to see most adoption from them, as they are the arbiters that enable bridged assets to be traded/staked or used however else and thus are most directly exposing their users' assets to these risks.
    • Bridges can integrate the security module to create their own security processes. They will strongly benefit from having an independent third party tracker next to their own internal ones.
    • Oracles will be able to use the collateral ratio for interchain asset pricing. In theory, native asset trading statistics can be bridged to synthetic asset in order to decrease manipulation risk.
    • As the module will be fully open source, any other Polkadot ecosystem developer/team can integrate it for their use cases.

    Meeting the needsโ€‹

    Bridge hacks are rare but painful because of the potentially high amount of funds that are constantly at risk / an attractive target for malicious actors. Therefore, the bridge attestation oracle will provide a live auditing tool for any actor in the Polkadot ecosystem that wants to make their operation more secure.

    In discussions with various ecosystem actors, the idea and architecture of the solution were presented with the goal of validating the problem and the potential solution. We received supportive feedback from all interviewees, and therefore decided to pursue the inititive further.

    To verify the relevance of the idea we conducted interviews with several ecosystem participants, including

    • Acala
    • Astar
    • AstridDAO
    • Interlay
    • Pendulum
    • StellaSwap

    Similar projectsโ€‹

    We were not able to identify any similar solution present in the market. Similar approaches can be attributed to:

    1. Proof of Reserves oracles - developed by several oracle providers, these oracles track the amount of tokens in reserves and provide this information publicly.
    2. Cross-chain messaging protocols - these have architectural similarity in that one could transmit bridge balances as a message, however there are several limitations to this approach:
    • They would act as a 2nd layer bridge (bridge for bridge balances) and are also prone to manipulation.
    • Gas fees would have to be paid on the origin chain, which causes potentially volatile costs required to run such operation, putting them at risk.
    1. Real time alert providers for smart contract activities. Tools such as Forta allow to set-up monitoring and notifications for pre-determined smart contract activities. However, they do not offer a direct solution for bridge balance monitoring, which we aim to deliver.

    As our proposed solution is different in nature, we do not perceive any of the existing approaches as real alternatives. Additionally, all of these solutions are commercially driven, while the bridge attestation oracle will serve as a public good.

    Risksโ€‹

    • RPC manipulation risk - the solution will use RPC services to retrieve data from blockchains. Therefore, if someone manages to manipulate RPC data, the final value could be exploited. A potential mitigation could be to introduce connections to multiple RPCs simultaneously to reach a consensus.
    • Contract migration risk - from time to time protocols may need to migrate or upgrade contracts. This could produce incosistent values. To avoid this, direct communication channels with bridges can be set up and tracked to flag any changes on the smart contract level. This could be complemented with community based forum where contributors could also flag these migrations manually.
    • Off-chain worker operational risk - the solution is developed on the assumption that off-chain workers can be trusted and will be maintained within the Polkadot ecosystem. However, upgrades, malfunctions or the unlikely event of discontinuation of off-chain workers poses a risk to the solution. In this case, migration to another off-chain computation platform could be a mitigation (e.g. Phala or Integritee).

    Team ๐Ÿ‘ฅโ€‹

    Teamโ€‹

    • Samuel Brack // Cofounder and CTO at DIA // Github // LinkedIn
    • Philipp Pade // Lead Integrations Developer at DIA // Github // LinkedIn
    • Nitin Gurbani // Senior Developer at DIA // Github // LinkedIn
    • Zygis Marazas // Product Lead at DIA // LinkedIn
    • Paul Claudius // Cofounder and Business Development Lead at DIA // LinkedIn
    • Dillon Hanson // Business Development Manager at DIA // LinkedIn

    Contactโ€‹

    • _Registered Address: Baarerstrasse 10, 6300 Zug, Switzerland.
    • _Registered Legal Entity: DIA e.V.

    Team's experienceโ€‹

    Experience which will help to succesfully develop this project is listed below:

    Development of a pallet for oraclesโ€‹

    Team DIA has extensive experience in developing a pallet for Polkadot using off-chain workers. The pallet was developed to serve the purpose of accessing oracles natively by parachains. The documentation of the solution can be found here.

    Scraping Multichain bridgeโ€‹

    Team DIA already did experiments with automatic bridged assets identification, therefore we already developed a Multichain bridge scraper which maps out assets accross a variety of chains.

    Development of collateral based values for nASTR, iBTC, stDOT, stETH, rETH, vKSM, kBTCโ€‹

    We recently launched xLSD - a product that tracks collateral values for liquid staked tokens

    Established partnerships in oracle fields with Polkadot ecosystem parachainsโ€‹

    We are already present in the Polkadot ecosystem and have developed oracles for a range of parachains and dapps, and integrated natively with a range of DEXs including:

    • Moonbeam & Moonriver
      • Midas Capital
      • Mixbytes
      • Orbiter One
      • Raze Network
    • Astar
      • Starlay
      • SIO2 Finance
      • Algem
      • AstridDAO
      • Orcus Finance
      • Starfish Finance
      • Rikkei Finance
      • Arka Finance
      • Standard Protocol
    • Pendulum
    • Interlay
    • Bifrost

    DEX integrations:

    • Beamswap (Moonbeam)
    • Stellaswap (Moonbeam)
    • Arthswap (Astar)
    • Huckleberry (Moonriver)
    • Solarbeam (Moonriver)

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 1.5 FTE
    • Total Costs: 26,000 USD

    Milestone 1 - Core functionalityโ€‹

    • Estimated duration: 1.5 months
    • FTE: 1.5
    • Costs: 18,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can intgrate the collateral value into their code, which will display the functionality.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that introduces to the solution with all the guidelines included.
    1.Attestation oracle core: Off-chain workerWe will create an Off-chain worker as stated in the architecture overview section.
    2.Attestation oracle core: PalletThe entire solution will be made available as Pallet (described in architecture section).
    3.Attestation oracle core: RPCsWe will set-up connections to RPCs of other chains with fallback functionality (at least 2 RPCs per chain).
    4.Attestation oracle core: Collateral ratio calculationThe logic for calculating collateral ratio will be developed within the off-chain worker.

    Milestone 2 โ€” Bridge integrationsโ€‹

    • Estimated Duration: 1.5 months
    • FTE: 1
    • Costs: 8,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can integrate bridges collateralization value, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Bridge Integration: MultichainWe will develop a module as part of the proposed solution that retrieves collateral information for assets bridged by the Multichain bridge contracts.
    2.Bridge Integration: InterlayWe will develop a module as part of the proposed solution that retrieves collateral information for assets bridged by the Interlay bridge contracts.

    Future Plansโ€‹

    We see a lot of potential for the future of the solution, these include:

    • Develop attestation for multichain Liquid Staked Tokens (e.g. aUSD).
    • Spin-off as independent solution (not a pallet).
    • Develop monitoring dashboards for researchers.
    • Create built-in notifications services.
    • Expand into any smart contract metrics tracking that allows users to define their own logic.
    • Introduce community driven governance for any changes and future directions of the solution.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? - personal recommendation

    - + \ No newline at end of file diff --git a/applications/DICO.html b/applications/DICO.html index 3f8086d4327..e8e33ddfe20 100644 --- a/applications/DICO.html +++ b/applications/DICO.html @@ -4,13 +4,13 @@ DICO | Web3 Foundation Grants - +
    Skip to main content

    DICO

    • Team Name: DICO Team
    • Payment Address: 0x0211ae8881a3a0a41150627da07c900b78144a84(USDT)
    • Status: Terminated

    Project Overviewโ€‹

    The DICO is to create a decentralized and governable ICO platform for the Polkadot/Kusama ecology. Our platform will allow entrepreneurs to quickly find investors. In a word: Be a platform to link ideas and capital.

    Overviewโ€‹

    Our platform offers a few key features:

    • KYC: Includes identity authentication service(IAS), KYC users, and supervisor. responsible for providing users with a decentralized KYC certification service.
    • ICO: Apply for ICO and council review for the project party.
    • DAO: Integrate governance with the ICO module to provide governance logic for the opening and closing of the ICO of the project.
    • Swap: Provide an exchange agreement for tokens and an interest-generating method for collateralized tokens into the liquidity pool for disposable tokens
    • Oracle: Provide an oracle for the platform.

    Our project use substrate framework and is built on top of Polkadot/Kusama ecosystem:

    • KYC,ICO,DAO and Swap modules are built on substrate runtime. they complete the basic user interaction logic.
    • Oracle enabled off-chain worker to query the current price feed of the platform or other tokens.

    Project Detailsโ€‹

    Mockups and UI componentsโ€‹

    ICOโ€‹

    KYCโ€‹

    DAOโ€‹

    Swapโ€‹

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem?

    We are aiming to offer the first decentralized KYC/ICO in the Polkadot/Kusama ecosystem.

    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

    To start with, our target audience are the DICO/DOT/KSM/other tokens holders who are looking to participate in ICO project. and the team funded through ICO.at this stage, we will provide a KYC area for legal regional ICO. next๏ผŒ we provide derivatives related to ICO. Such as providing token exchange and staking protocol. at this stage, allow any token holders to participate in their promising projects. in addition,We will go to support or self-improve all the required ecology, such as social. finally, we provide stable project maintenance and update functions that keep pace with the times, and serve the entire ecological stability.

    • What need(s) does your project meet?

    Be a platform to link ideas and capital.

    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

      • If so, how is your project different? coinlist๏ผŒA token financing platform, all the mainstream virtual currencies above can be traded and financed. It provides token financing, but does not provide the funds needed by early creator and the control of the entire project cycle.

      • If not, are there similar projects in related ecosystems? We have not yet found a project that will be focusing ICO and derivatives.

    Teamโ€‹

    Team membersโ€‹

    • Name of team leader: gogomath

    • Names of team members:Daniel, gogomath,Dunham,cf,tokggo,cj1afs,meliart

    Contactโ€‹

    (we are in the process of registering the legal entity)

    • Registered Address: N/A
    • Registered Legal Entity: N/A

    Team's experienceโ€‹

    Daniel: Daniel is currently a venture investor at WEB3 Venture Capital. Daniel previously is a solidity/EOS engineer.

    gogomath: gogomath is the CTO of the team and has 10 years of software development experience. The fields involved are big data, machine learning, SAAS, devops. And familiar with eth/near/polkadot in the field of digital encryption development.

    cf: cf is a full stack engineer with five years of development experience. and familiar with Go/Rust/Java/Python/Javascript/Typescript

    tokggo: tokggo is the test/devops engineer of the team, he is very good at writing various documents.and has 6 years of development experience.

    cj1afs: A graduate student in financial mathematics, a new friend in the field of blockchain, will participate in the development of various pallets.

    meliart: Back-end development engineer with 3 years of experience, familiar with Go/Rust/Node/Typescript.

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    interface iterations and resource: https://github.com/DICO-TEAM/resources

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1 months
    • Full-Time Equivalent (FTE): 6 FTE
    • Total Costs: 10k USD

    Milestone 1 โ€” Implement KYC, ICO, DAO Modulesโ€‹

    • Estimated duration: 1 month
    • FTE: 6
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0LicenseApache 2.0
    1.aSubstrate module: KYC palletKYC pallet Includes identity authentication service(IAS), KYC users, and swordholder. responsible for providing users with a decentralized KYC certification service.and provide area authentication of the account.Detailed explanation is described here
    1.bSubstrate module: ICO palletApply for ICO and council review for the project party. Detailed explanation is described here
    1.cSubstrate module: DAO palletIntegrate governance with the ICO module to provide governance logic for the opening and closing of the ICO of the project. Detailed explanation is described here
    2.a.Integration with front-end(dapp)integrate our existing front end to the finalized module.
    2.bTutorialWe will create an screenshot tutorial and a demo video that will explain how users can start using the platform for KYC and ICO.
    3.Testing Guide/DocumentationCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests and add inline documentation of the code.
    4.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    5.Docker-composeWe will provide a docker-compse.yml that can be used to test parachain version node delivered with this milestone.in this version, users will be invited to this testnet
    6.Lending module(research oriented)Innovation combining ICO and borrowing/lending. In our 2.0 version, we hope to introduce an innovation combining lending and ICO. The goal is to make ICO more diversified through borrowing/lending. Through the logic of borrowing/lending, and participation in ICO, the participants will be more diverse. At the same time, in the 2.0 testnet, we will let users participate in this pallet. According to the test results, publish a blog to show the test results.
    - + \ No newline at end of file diff --git a/applications/DINFRA.html b/applications/DINFRA.html index 23604f0614d..92039c7240d 100644 --- a/applications/DINFRA.html +++ b/applications/DINFRA.html @@ -4,13 +4,13 @@ DINFRA | Web3 Foundation Grants - +
    Skip to main content

    DINFRA

    • Team Name: Valletech AB
    • Payment Address: FIAT
    • Level: 3

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    DINFRA, decentralized infrastructure, is substrate orchestrated infrastructure, a decentralized alternative to public clouds.

    Substrate allows us to create a specialized blockchain, which we see as the perfect blending between Custom Functionality, Decentralized Governance and Value/State tracking.

    Modern data-center technology is now software defined, API driven and hyper-convergent with capability to virtualize Compute, Storage and Networking. Specialized network equipment is being replaced by virtualized services. There is also great availability of Open Source technologies covering all aspects of the modern data center.

    DINFRA aims to create a Substrate blockchain to orchestrate hyperconvergence infrastructure in a democratic, decentralized, open/neutral and non technically opinionated way.

    Realizing DINFRA vision requires a viable strategy. This project represents the first phase of a three phase strategy in which an Open Source Minimum Viable Product is delivered for the purpose of developing, testing, generating awareness and gaining community support.

    After delivering Polkawatch, our analytic engine to measure decentralization of the substrate validation process, DINFRA is the natural next step for us to take in the Substrate Ecosystem. We have a track record contributing to Cloud automation stacks, we created Privazio for small organizations to be able to fully automate their infrastructure and have used it to deliver Polkawatch for Polkadot and Kusama. We would like to start contributing to effective substrate infrastructure decentralization next.

    For a complete presentation of DINFRA vision and strategy see this Video Presentation.

    Project Detailsโ€‹

    Design Constraints

    We gave been part of the Dotsama community and that has allowed us to gain a better understanding of how it operates. Consequently, some key decisions have been taken that impact our choices of design and architecture:

    • DINFRA must be open and non technically opinionated. Infrastructure providers must be able to offer their solutions via DINFRA without being forced into specific technologies or opinionated solutions. Furthermore, they should be able to offer their current infrastructure via DINFRA provided they have industry standard automation capabilities, which typically they do, with minimal effort.
    • DINFRA must be decentralized and democratic adopting and following the practices that we see on Kusama and Polkadot for governance.
    • DINFRA must focus on the needs of our ecosystem first.

    We consider these points a prerequisite for community acceptance and adoption.

    Design Interfaces and Data Modeling

    DINFRA main responsibility will be to mediate between consumers and providers awarding "deployment descriptors" to "infrastructure providers" by means of consensus, collect balances accordingly, etc.

    From the previous constraints we deduce that we need lose typing of deployments descriptors, and DINFRA being able to distribute descriptors as opaque entities which don't need to be fully understood.

    Infrastructure Providers should be able to self register on DINFRA with information about which types of descriptors they can serve, even register new types of Deployment Descriptors for their flavored solutions if they happen to have some differential in-house capability.

    Deployment Descriptors will be able to represent things as diverse as a Helm Chart, Docker Compose, Cloud-Init user data, Subquery Project descriptor or IPFS cluster member profile. As long as each Provider registers their deployment capabilities properly, DINFRA must be able to route deployment requests to them.

    Deployment descriptors will be specified in JSON with its type defined as a JSON Schema. This provides loose typing and flexibility to accommodate any deployment descriptor possible, besides the fact that JSON/YAML is a widely used already by most infrastructure platforms and solutions.

    Note that Deployment descriptors won't be stored on chain but preimaged and backed on IPFS, as they are required during deployment. Secrets, whenever possible should be deduced from on-chain data preferably in the form of public keys.

    High Level Architecture

    DINFRA Architectural stack resembles pretty much a substrate stack under an infrastructure automation stack, like this:

    DinfraHLArch

    We make the active choice of not connecting infrastructure platform / automation stack directly to the blockchain, for example via its Offchain Worker Interface, but we introduce an intermediate component called "Chain Reactor."

    The Chain Reactor is responsible for orchestrating infrastructure according to decisions taken on chain. The most prominent actions would be to deploy infrastructure as a descriptor is awarded or tear down infrastructure as a deployment reaches its termination.

    In order to fulfill the constraints above, Chain Reactors must be easy to implement using any infrastructure automation stack on any suitable language, and it must be simple to do so. Whether Python/Ansible, Java/Cloustack, Go/Terraform, Go/Helm, Python/Juju, etc. Chain Reactors must rely on programming language-agnostic API specifications/tooling such as OpenAPI/swagger for generating stubs in any language that can be used as base for implementation.

    Technology Stack Used

    In line with the strategy decided above, this project will focus on a minimal viable product while honoring the constraints and architecture above.

    The components generated must also serve as "Reference Implementation" to community members willing to generate similar implementations for other infrastructure platforms or solutions.

    The Stack for the current MVP will be made of:

    • Apache CloudStack: As Infrastructure Platform
    • Ansible / Python: As tooling for implementing a Chain Reactor.
    • Substrate: For DINFRA Parachain
    • Gitlab CD/CI: For Reference Implementation of Automated Testing and CI/CD.
    • Docker Compose: For rapid development setup.
    • Gitlab CD/CI: for End to end Itegration testing, to avoid regression when new Apache CloudStack versions are released.

    Scope

    Lots of the features that we pitch in our DINFRA video presentation are left out of the scope of this phase. DINFRA opens a lot of exciting possibilities but it is important to remain in focus and deliver a MVP useful for development and bringing community awareness now.

    What DINFRA is not

    DINFRA is not an Infrastructure Provider for the Dotsama ecosystem, but rather a parachain designed to arrange deployments between infrastructure consumers an infrastructure providers in a decentralized way.

    DINFRA may provide concrete infrastructure automation modules, but they will be open-source and infrastructure providers will be able to use them, modify them or utilize as reference implementation for their own.

    DINFRA is not meant to deliver a company or venture but rather a decentralized community that follows Polkadot's governance model and serve our ecosystem first.

    DINFRA will not become a way to just "open" infrastructure to the whole world. Blockchain features may be used for consumers to pick specific providers, providers to accept specific consumers even for consumers to manage their own infrastructure in a private way. Completely public infrastructure remains a valid use case but would benefit from on-chain features such as reputation, arbitrage, deposits, offenses, etc for it to be practically viable.

    Ecosystem Fitโ€‹

    As we can see with Polkawatch, our infrastucture plays an important role in the level of effective decentralization of Substrate Validation process.

    Our treasuries invest significant funds on infrastructure, for which our ecosystem counts with fantastic providers. However, it is becoming clear that our ecosystem needs strategic actions at infrastructure level. Some projects have already been started by our treasuries, a good example being the Infrastructure Builders Program.

    DINFRA intents to provide an strategic approach to managing our ecosystem infrastructure using our biggest asset: Substrate itself.

    On the other hand our ecosystem is investing significant effort on Decentralized Finance. A successful DINFRA parachain, used to arrange delivery of our own infrastructure, would channel significant resources becoming effectively a Web3 commodity: a currency that everybody in our community needs and uses, backed by real, tangible, infrastructure services. This would provide health to our DEFI community as DEFI is often criticized for baking tokens with tokens non of which are backed by "real" assets. Commodities play an important role in traditional economies and the same could apply to our ecosystem.

    The target audience of DINFRA is therefore our Governance bodies, infrastructure providers, infrastructure consumers (Parachains, DAPPs, etc), and on the other hand substrate, UI and infrastructure engineers willing to contribute.

    Regarding similar projects, on top of strategic programs launched by our treasuries there is also ThreeFold. An impressive decentralized infrastructure venture which utilities substrate technology while not being formally part of our ecosystem. We had the pleasure to meet their friendly team during the last Sub0 conference in Portugal and their experience was instrumental in realizing that DINFRA is far from a technological-only challenge and needed key design constraints for it to be acceptable to our ecosystem: inclusive to current infrastructure providers, non technically opinionated, community governed, strategically designed to serve our community first, etc.

    At a different level DINFRA is an attempt to orchestrate a set of independent providers that will appear to the consumer as a single entity. Effectively DINFRA could become a decentralized alternative to Public Clouds in the long term. Lessons learned from DINFRA could apply to other industries too. Any industry with an existing level of automation and many independent players could be orchestrated similarly

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Rafael del Valle Lรณpez
    • Renรฉ Moser

    Contactโ€‹

    • Registered Address: Blรฅmesv. 26, 186-47 Vallentuna, Sweden
    • Registered Legal Entity: Valletech AB, Org. Num: 5590673694

    Team's experienceโ€‹

    Rafael lives with his family in Sweden and has over 20 years experience creating Software Product, Services and Ventures. In the last years has started to contribute to Open Source projects in the Infrastructure field. A significant contribution to Open Nebula was the Python Bindings, now part of the official distribution. More recently the Privaz.io project was created with the goal to facilitate the adoption of Private Clouds by small projects. Privazio is currently in use to deploy Polkawatch, a Web3 Foundation project currently in production and backed both by Polkadot and Kusama treasuries.

    Renรฉ Moser lives with his family in Switzerland and have been a software and systems engineer for over 20 years. Renรฉ is co-author of O'Reilly's "Ansible: Up & Running" and longtime open source software developer and author of many Ansible Cloud Provider Automation integrations, such as Vultr, CloudStack, Exoscale, cloudscale.ch, Hetzner and became member of the Ansible Core Contributors Team. Furthermore, Renรฉ is Apache Foundation CloudStack Project Management Committee member since 2015 and founded my own company moser-systems.com with focus on "Cloud Automation, Scaling and Integration." currently delivering its flagship project ngine.io, a platform for cloud-agnostic services including autoscaling which has been released as open source software "scalr".

    Renรฉ and Rafael met during an open source collaboration to deliver new Apache CloudStack automation features.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    The project has not started formal implementation yet. However we have performed a viability check of required deliverables.

    Most infrastructure deliverables belong to our domain of expertise per contributions made in the past to other open source projects, therefore is easy for us to ensure its viability. Intermediate interfaces don't have technical risk, they have important technical requirements when considering our project constraints but they are straight forward to deliver.

    Substrate deliverables are newer to us and imply a learning curve, however the amazing resources put together by the community at substrate.io: the tutorials, test frameworks, etc have allowed us to verify their viability.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3.5 months
    • Full-Time Equivalent (FTE): 1
    • Total Costs: 47.000 USD

    Milestone 1 โ€” Infrastructure Provider SDKโ€‹

    • Estimated duration: 1.5 month
    • FTE: 1
    • Costs: 20.000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can test functionality, implement a Chain Reactor, etc.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Chain Reactor APIWe will create the API for Chain Reactors using API technologies (OpenAPI or similar) that facilitate language-agnostic implementations.
    2.Chain Reactor RIWe will implement a Chain Reactor Reference Implementation based on Apache CloudStack that can run against the Apache CloudStack Simulator to facilitate further development. The RI will be written in Python as programming language and Ansible as automation stack
    3.Chain Reactor RI Test SuiteWe will release a comprehensive set of Chain Reactor RI Unit tests that should serve as guideline for TDD of other implementations, implmented with Python.
    4.CD/CI Chain Reactor RIGitlab Pipelines will be created for Chain Reactor Reference Implementation that must serve as guideline to other implementations
    5.SSH Key DerivationA viability study and implementation of converter of Substrate Account Keys into SSH Keys based on ed25519. Implemented with NodeJS
    6.Substrate Deployment DescriptorsDocumented Examples of Deployment Descriptors for the Chain Reactor RI will be provided that would spawn Substrate Nodes under DINFRA.

    Milestone 2 โ€” Substrate Parachainโ€‹

    • Estimated duration: 2 month
    • FTE: 1
    • Costs: 27,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can run, test and contribute to the DINFRA parachain.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.DINFRA Provider PalletIt will allow for Accounts to register as providers, Providers to declare supported Deployment types and avilable capacity. Will Assign Deployments to Providers by simple means such as Round Robin, Random or Capacity Based. Implemented with Substrate/Rust.
    2.DINFRA Subscription PalletIt will represent a simple Subscription to pay for a deployment. Cost will be fixed per block. Deployments will be teared down when allocated Balance is consumed. Consumers will be able to cancel Subscriptions and any time, tearing down the deployment. Implemented with Substrate/Rust.
    3.Chain Reactor InterfaceA Substrate Interface will be created with Providers Chain Reactors so that Deployment Contracts can be Deployed and Teared Down. The interface will be based on standard Substrate interfaces OCW, RPC and/or sidecar service / REST

    Future Plansโ€‹

    We intend to continue to our second phase in the plan as described in our video presentation. We will use the deliverables from this release to:

    • Setup a DINFRA Test Network
    • Generate awareness in our community
    • Allow the community to test the system
    • Pitch and demo: Treasuries, Infrastructure Providers, Developers
    • Seek launching DINFRA with specific Dotsama use cases.
    - + \ No newline at end of file diff --git a/applications/DKSAP.html b/applications/DKSAP.html index 8616e96697c..2ad7f882fbc 100644 --- a/applications/DKSAP.html +++ b/applications/DKSAP.html @@ -4,7 +4,7 @@ DKSAP | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ Blockchain-Based Internet of Things Systems

  • PDKSAP : Perfected Double-Key Stealth Address Protocol without Temporary Key Leakage in Blockchain

  • EDKSAP : Efficient Double-Key Stealth Address Protocol in Blockchain

    • Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement Substrate Modules & DKSAPโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.(Node.js)SDK: Client ToolDevelopment and testing of the basic abilities of the client tool, including computing a shared secret by ECDH, computing encrypted public key of the receiver, computing ephemeral private key(adding points in elliptic curve cryptography), and pushing transactions to relayer through HTTPS.
    2.(ink!)Smart contracts: Anonymous NFTDevelopment and testing of the core functions of the Anonymous NFT smart contract, including minting new NFT, transferring NFT, and burning NFT. In particular, it is important to note that the address of the owner stored in the contract is encrypted by the scan public key of receiver. At the same time, when users need to perform Mint or Transfer operations, smart contract need to verify the signature of the private key corresponding to this address on-chain.
    3.HTTPS Service: Node.js RelayerBuild an early-stage HTTPS service relayer including accepts requests from users and pushes transaction to NFT smart contract.

    Future Plansโ€‹

    - + \ No newline at end of file diff --git a/applications/DNFT.html b/applications/DNFT.html index fc9f97640cb..660922f732e 100644 --- a/applications/DNFT.html +++ b/applications/DNFT.html @@ -4,7 +4,7 @@ DNFT Protocol | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ 2.Pallet_tax, we will set a customized tax-set stanard towards different NFT colletcions, rather than a simple All-The-Same solution. 3.Pallet_swap, we will add auction, dex, rather than a simple transfer. 4.Pallet_dao, we will add a governance mechanism to lanch proposals.

    - + \ No newline at end of file diff --git a/applications/Dante_Network.html b/applications/Dante_Network.html index 5f9cb3b713c..4cfcd267354 100644 --- a/applications/Dante_Network.html +++ b/applications/Dante_Network.html @@ -4,7 +4,7 @@ Dante Network | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ SINGAPORE (199588)
  • Registered Legal Entity: KVANACE TECHNOLOGY FOUNDATION LTD.

    • Team's experienceโ€‹

    Our technical team consists of several experienced full-stack engineers and scientists. Each member has many years of technical experience. Our members have a lot of experience in the web3 world. They are deep participants in several technical communities, hackathon winners, and node service providers for Polkadot/Kusama, EOS, and PlatON.

    Team Code Reposโ€‹

    Team members' repos:โ€‹

    Development Status ๐Ÿ“–โ€‹

    Demo Vedioโ€‹

    The principle of Dante protocol stack can be seen below: https://www.youtube.com/watch?v=CYXx4O8Xgcs

    Demoโ€‹

    Everyone can try a simple demo at Demo

    Tasting SDKโ€‹

    Weโ€™ve published a tasting version of the dev SDK for multi-chain DApp developers at: tasting SDK

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Service expression layer, message verification & router credibility evaluation algorithms, basic off-chain routers, basic SDKโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use the the SDK of Dante smart contract developed in ink! to build their own Omnichain DApps. At this stage, the tutorial will cover how to make message communications and contract invocations between Polkadotโ€™s smart contract parachains and other chains(like Ethereum).
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains what was done as part of the grant. And we will publish a series of articles that explains how Dante Protocol Stack works from a high-level perspective. The content of the articles will be consistent with the functions at this stage.
    1.(ink!)smart contracts: Service expression layerDevelopment and testing of Service expression layer on some of Polkadotโ€™s smart contract parachains (Astar/Edgeware); Demos for communication and interoperation between one of Polkadotโ€™s smart contract platforms and Ethereum, Near, Avalanche.
    2.(ink!)smart contracts: message verification algorithmDevelopment and testing of verification algorithms of the consensus verification layer on some of Polkadotโ€™s smart contract parachains (Astar/Edgeware) and other chains including Ethereum, Near, Avalanche, Flow, PlatON. Verification contracts deployed on testnet. Demos for information verification.
    3.(ink!)smart contracts: router credibility evaluation algorithmDevelopment and testing of the credibility evaluation algorithms of the consensus verification layer; Selection of growth function and decrease function suitable for smart contract on-chain is the key point; Router behavior evaluation contracts deployed on testnet; Demos for router evaluation according to their behaviors.
    4.off-chain routers: general message sharingDevelopment and testing of the basic abilities of the off-chain router, including general message encoding and decoding, message delivery between multi-chains; Demos for some of Polkadot's smart-contracts parachain, along with Ethereum, Near, PlatON, etc.
    5.(Rust)SDK: general message sharingBuild an early-stage SDK including a general message sending and receiving interface. Adapted to some of Polkadot's smart-contracts parachain, along with Ethereum, Near, PlatON, etc.

    Milestone 2 โ€” parallel router scheduling algorithms, SQoS, off-chain routers, SDK, testnetโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use the the SDK of Dante smart contract developed in ink! to build their own Omnichain DApps. At this stage, the tutorial will cover how to use SQoS to balance security and scalability when making multi-chain operations.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains what was done as part of the grant. And we will publish a series of articles that explains how Dante Protocol Stack works from a high-level perspective. The content of the articles will be consistent with the functions at this stage.
    1.(ink!)smart contracts: parallel router scheduling algorithmDevelopment and testing of parallel router scheduling algorithms of the consensus verification layer; Suitable randomness is the key point; Scheduling contracts deployed on testnet. Demos for router scheduling, a router with high credibility will have a higher probability to be chosen.
    2.(ink!)smart contracts: SQoSDevelopment, and testing of the SQoS (Security Quality of Service) mechanisms including hidden & reveal, challenge confirm, error rollback, verification threshold, authority context, etc. Multi-chain message contracts deployed on testnet. Demos for showing each of the SQoS items.
    3.off-chain routers: SQoSSQoS abilities related to off-chain routers, including hidden & reveal, challenge confirm, error rollback, verification threshold, authority context, etc. Adapted to some of smart contract parachain in Polkadot, along with Ethereum, Near, PlatON, etc.
    4.(Rust)SDK: contracts invocation; SQoSInterface of contracts invocation between multi-chains and setting of SQoS; Adapted to some of smart contract parachain in Polkadot, along with Ethereum, Near, PlatON, etc.
    5.testnetThe testing for the basic abilities of the whole protocol stack. Demos for the whole abilities. Launch the testnet of Dante Network.

    Future Plansโ€‹

    After the ink! version of the Dante protocol stack is fully tested, we would like to implement a pallet version for Polkadot ecosystems. Anyone who is integrating it can communicate with other ecosystems conveniently.

    Our next step is to work with many application-based projects to iterate our SDK for developers based on their needs, making web3's multi-chain interaction easier.

    At the same time, we will continue to improve and update our protocol stack as we use it. We will invite more project parties, developers, and end-users to participate and give their valuable suggestions.

    Security is the most important point in this field, so it will be fully tested on the testnet. And there will also be some targeted hackathon events related to security.

    Dante Network will be a long-term project because our final goal is to provide a simple, easy-to-use, secure infrastructure. At that time, the interactions between most of the chains in web3 will be as convenient as the interactions with terminal devices in web2 through the internet.

    Additional Information โž•โ€‹

    We highly endorse the philosophy of Web3 Foundation. We think the web3 world is expected to be an โ€œinternetโ€ of multi-chains, each of which can provide its own special features and every participant can share it worldwide. So there should be a kind of infrastructure that can provide consistent and convenient multi-chain interoperability for DApps in Web3 so that they can focus on their application business. At that time, DApps can serve the whole web3 market instead of staying in some certain ecosystem.

    In our idea, we think different chains are like realms in mythology. There are barriers for users to having universal transportation to travel around the different realms. And there is Bifrost to open a teleport between realms, but it is neither cheap nor easy. So inspired by this, we want to grow a โ€œWorld Treeโ€ that supports open and collaborative ecosystems in web3.

    It can take roots in the computing resources and storage infrastructures in web3 and web2 to provide orderly resource scheduling. And it can grow by offering non-differentiated data collaboration services for DApps in web3 and providing valid resources. This is why we have the Dante Network.

    - + \ No newline at end of file diff --git a/applications/Datagen_Project.html b/applications/Datagen_Project.html index e943c2d0cb6..1dc56f3ba1b 100644 --- a/applications/Datagen_Project.html +++ b/applications/Datagen_Project.html @@ -4,7 +4,7 @@ Datagen Project | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ If, instead, for at least 2 validators (between B, C and D) hash Z โ‰  hash Y, validator A is presumed a liar. Since to be a validator A needed both to provide GPU and/or CPU processing capacity and to buy and stake DataGen native tokens, is easy to impose an economical cost for the cheating validator A by making it loose staked coins as a consequence of its wrong computation. In this regard the Parachain acts as an authority for the random processes of the FB.

    We prefer the use of a Parachain, instead of two FB or a HB of our own FB, because of the improved resiliency that the Polkadot ecosystem can provide.

    We must underline that, even if the goal of this very complex design is to keep even the hardware layer as decentralized as possible (compared to a PoS network, where there is strong economic incentive for a validator to host the computing capacity on the top of centralized server farm like AWS) we canโ€™t prevent the validators hosted on centralized providers to participate to the network.

    The trade-off for such a result would so impede efficiency and low latency that, instead of trying to attain it (for some ideological reason of decentralization per self) we think we should try keeping the hardware layer of the network decentralized enough. We think that this can be attained as a collateral result of the above explained ECHO procedure (whose primary goal is to increase the overall efficiency and decrease the overall latency time of the network, by pairing users and validators on the basis of response time).

    This collateral positive externality happens since validators that are faster to respond to specific clusters of users are rewarded by the process with the right to provide the cloud computing power requested by those clusters, with meaningful consequences for the geographical distribution of the validators themselves: in some geographical contexts (US coasts or Western Europe), where the internet connection is fast and big server farms are close-by, this will keep the economic incentive for validators to be hosted in centralized server farms; on the opposite, in other contexts (like some parts of South-East Asia, Sub-Saharan Africa and LATAM), where broadband connection is slow or inexistent and server farms far away, there will be a strong economic incentive to set up independent hardware facilities to validate the activity of local or regional areas.

    Those independent validators, while not optimally located to compete with AWS-hosted validators for users in the โ€œnorth of the worldโ€, can also become validators of last resort in the case in which the centralized server farms are not providing service anymore (it can be due to technical outage or political pressure for censorship or other factors). As said, the goal is not to expel AWS-hosted validators from the Datagen network, but to keep it decentralized enough while being at the same time low latency and computationally efficient.

    The only computational activity that is happening off-chain is (following the example above) the act of validator A processing the raw data X and giving it to the user A, but: to receive the reward in #DG, validator A needs also to send the hashed data to both the other validators of the FB lighter chain and to the Parachain, since failing to do so will mean no reward because validator A would be processing off-chain data which wouldn't be recorded in the blockchain. Raw data is also sent independently from the user A to the Parachain and the correct pairing between hashing and raw data is always verified in-chain.

    Ideally, we would like to explore some technic to keep light the blockchains long-term to keep it clean of old unnecessary raw data and just having hashes long term (thatโ€™s why we like so much Polkadotโ€™s feature that allows blockchains to evolve without forking).

    So Datagen is NOT:

    Ecosystem Fitโ€‹

    The Datagen project fits into Polkadot ecosystem by expanding its use cases to the segment of decentralized cloud computing, whose importance can never be underlined enough for the healthiness of the broader Web3 and blockchain industries. Since the Datagen infrastructure is targeting mostly Web3 application providers as main customers to provide cloud computing to, this can loop in a positive feedback of new projects entering in the Polkadot ecosystem and as well as a very valuable use for a Polkadotโ€™s / Kusamaโ€™s parachain.

    In the Polkadot / Kusama ecosystem the most similar project is the Phala Network (https://www.phala.network/en/). Even if Phala Networkโ€™s goal is similar to the one of Datagen (decentralized cloud computing), the technical approach is radically different, since Phala is pursuing off-chain computation secured by a secure smart-contract platform.

    Both solutions are technically viable, but we feel that (without the presumption of being too knowledgeable about someoneโ€™s else target market or to give suggestions to someone else) Phala can be more appealing for legacy industries that want to interface blockchain (and Web3) to innovate existing business model (for example we think that Phala could be very compelling for health-tech applications that want to validate sensitive clinical data with a secure, encrypted network) while (from the feedbacks that we receive) we feel that in-chain computation would be more compelling for Web3 native applications, since in-chain computation is perceived as more decentralized and more secure (not necessarily rightly) by the semi-technical management that often decides what provider is more suitable.

    For the above explained reasons, we see Phala more like a complementary project than like an outright competitor (even if, of course, some marginal market overlapping could appear in some specific areas), since off-chain and in-chain computation, even if equally decentralized, can draw user-base from different contexts.

    In other ecosystems we can see different competitors, each one with a very different both technical and go to market approach (explaining them one to one will be too long to explain in this grant application), both off-chain and in-chain.

    Off-chain SONM (independent copy-cat of the Ethereum blockchain), Aleph.im (Solana, cross-chain compatible). And (more or less) in-chain: Akash (Solana Nodes + Cosmos), Golem (Ethereum), Cudos (L1, independent, cross-chain compatible), StackOS (Binance Polygon, Avalanche) and others.

    The existence of many competitors (each different from the other) in many different stacks is for us a confirmation that we are working on something that matters and we think that for the Polkadot ecosystem is important to harbor different cloud computing projects, with different (in some points complementary and in other alternative) approaches, both to help boosting the wider Web3 environment to shift away from centralized Web2 providers like AWS, Google Cloud, Azure, IBM, Alibaba and to acquire and retain valuable projects while competing with other major stacks, because cloud computing matters a lot in the web economy and in the web physical infrastructure and for a top stack like Polkadot / Kusama should matter where cloud computing, as a strategic asset, is happening.

    In particular is possible to observe that the Solana ecosystem is backing both one in-chain (Akash) and one off-chain (Aleph.im) decentralized cloud computing project, clearly in light of the different markets than in-chain and off-chain decentralized cloud computing can tap. In this way Solana ecosystem is positioning itself with a strong head-start to win the race for decentralized cloud computing.

    Teamโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Both founders (Angela & Luca) have a legal background. They entered in the blockchain space in 2019 (shifting carrier) because they both strongly believe in the transformative power that the blockchain revolution can have on society.

    After โ‰ˆ1 year of self-taught study of the blockchain technology and market, they incorporated B-Datagray in late 2020. At the beginning it was a very lonely but enriching journey, since they had 0 previous connection in the industry, 0 track record and 0 capital. Angela and Luca started being full-time on the project in January 2021.

    In Spring 2021 they started building the technical team (at the beginning all part time, due to the lack of capital) and not without encountering not particularly honest devs, while that made things more difficult short-term, long-term it allowed the funders to become more skilled in managing a team. Our currently beautiful team started to come togheter after summer 2021.

    In that period, we also entered in the XEurope Accelerator. Ren (with 7 years of coding experience and 5 of Solidity coding) was the first to become mostly full-time, in October 2021, before we were able to pay him a salary.

    In November B-Datagray received the first VC investment and to date we have 2 VC and 2 angel investments. We have developed all the tokenomic smart contracts, including a community governance smart contract to help smoothing the transition from the BSC to our Native + Polkadot blockchain and all of them have been audited by Certik. B-Datagray has also been recently finalist at the MIT Bitcoin Pitch Competition 2022.

    We know that we still have much to grow and to learn, but all the journey until here and now taught to B-Datagrayโ€™s founder a great deal about bootstrapping and managing a company and about doing much with very little.

    The ability and willingness to learn and grow and change and to work hard and to believe, even in the most difficult moment, and to find the resources, in the inner-self and in the other people, even when is seemingly and rationally impossible, in our opinion is more important than any learned skill for team and project leaders, since is an attitude that you have inside you and that you express in every aspect of your personal and professional life and that will be determinant to solve any of the multiple problems that will inevitably and unexpectedly occur during the projectโ€™s lifetime.

    All our devs (and our designers) are professionals and also very committed to learning and improving constantly their skills.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Statusโ€‹

    What we have already developed (using Solidity) is all the tokenomic smart contracts regulating our DataGen token (#DG), including one to smooth the transition from the BSC network to the Polkadot / Native Datagen Infrastructure, with a rigorously decentralized community voting procedure (https://github.com/Datagen-Project/DataGen-Smart-Contracts/blob/main/contracts/MiningReservation.sol).

    In total our team has already developed around โ‰ˆ2K lines of code of smart contracts just for the Datagen project, excluding of course the default configurations (like lock.json , etcโ€ฆ), we are speaking of functional code. In addition to that, we have in private repo the functional code for the website and the sale interface.

    Regarding anyone in the Web3 foundation (and/or Parity Technologies) that we spoke with about our intended development with substrate we had: some technical email and email exchange with Gavin Wood, casual technical conversation with Richard Casey in a Dublin blockchain event, some calls (including technical explanations) with Rohan Joseph and Surag Sheth. One technical call with Justin Frevert. A long technical chat in person with Dan Shields at the MIT Bitcoin Expo 2022. A call with Santiago Balaguer.

    Development Roadmapโ€‹

    We will implement only a PoC with this grant.

    The goal is to achive a fully functional mechanism for the random selection of the nodes in the fast blockchian and smooth communication between the two blockchains.

    Overviewโ€‹

    Milestone 1 โ€” Implement the randomized substrate pallet pallet_random_node_selector and pallet_check_node_computational_workโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and an API specifications
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article on Medium that explains how we are going to develop the pallet.
    1.Substrate palletWe will create a pallet_random_node_selector that implement the randomized selection of the nodes for the fast blockchain using the Substrate Randomness trait. This pallet run on the Heavy Blockchain.
    1a.Functions
    • reliable_node update the list of the reliable nodes on the Heavy Blockchain.
    • random_checker_node_selector select 3 reliable random nodes in the fast blockchain to check the computational work.
    • random_node_to_check select a single random node to be check by the 3 checker nodes.
    2.Substrate palletWe will create a pallet_computational_work that runs computational work on the fast nodes and pair them with their works.
    2a.Functions
    • math_work_testing this function will provide math problems to solve by Fast Blockahin nodes, just for testing.
    • hash_work function will hash the raw math problem and the elaborated result from the node and pair, comunicate to the Heavy Blockchain.
    3.Substrate palletWe will crate a pallet_check_node_computational_work that manage the control process on the Fast Blockchain.
    3a.Functions
    • check_computational_work take info from the Heavy Blockchain (from the pallet_random_node_selector) and check the computational work of the target node. At this moment the nodes will make a simple math calculations just to check the mechanism.
    • check_result elaborate the result of the check process. If checked node has the same result of the majority of the checker nodes nothing happen. If the majority of the nodes have a different result from checked node this one will lose all his staked tokens (at this moment we only simulate the token lost) and checked node will be excluded from the Fast Blockchain.
    • reliable_node update the list of the reliable nodes on the Fast Blockchain.

    Milestone 2 โ€” Connecting the two blockchainsโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and and an documentation of the infrastructure
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article on Medium that explains how we are going to develop this step.
    1.RPC Method (Random Selector)We will create a custom RPC method to get the result of the random selection of the nodes to the Fast Blockchain. We will implement comunication to get:
    • Random node id to check and raw math problem (From HB to FB)
    • 3 Random node id for the checkers and raw math problem (From HB to FB)
    2.RPC Method (Blockchain status)We will implement a set of RPC methods to check the status of the two blockchains.
    • Mapping of all nodes an their status (reliable or not reliable) sync from Heavy Blockchain.
    • Computetional works done and to be done by FB (total and mapping for every fast node)
    3.Setup the two blockchainsWe will setup the two blockchains to deep test the communications and pallet_random_node_selector, pallet_check_node_computational_work and pallet_computational_work.

    Milestone 3 โ€” Web Dappโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and and an documentation of the infrastructure
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article on Medium that explains how we are going to develop this step.
    1.Web DappWe will create a web dapp to verify the functionality of the infrastructure, the GUI will display interactions between the two blockchains.
    1a.Dapp Mock-upDownload the mock-up of the dapp at this link.
    1b.Home pagehome page
    1. Filter to switch between the two blockcahins for searching purpose
    2. Searching field (could search for blocks or nodes by typing id)
    3. The id of the last node checked with check_computational_work pallet
    4. The total number of nodes checked with check_computational_work pallet
    5. Total checks with check_computational_work
    6. Avarage number of checks on a single fast node with check_computational_work pallet
    7. Id of a fast blockchain node
    8. Number of checks on a node with check_computational_work pallet
    9. The fast nodes that verify the computational work with check_computational_work pallet
    10. Check result from check_computational_work pallet
    11. Total blocks finalized by the blockcahin
    12. Total nodes of the blockchain
    13. Block height
    14. Block age
    15. Validator id of the block
    1c.Fast Blockchain - Block PageFB Block
    1. Blockchain identifier
    2. Block identifier (height)
    3. Block height, arrows change the block by 1 (left -1, right +1)
    4. The age of the block and its creation time
    5. Validator identifier, optionally a name and time required to validate the block
    6. Total number of fast nodes at this block height
    7. Number of nodes checked with check_computational_work pallet in this block
    1d.Heavy Blockchain - Block PageHB Block For functionalities see 1c. list.
    1e.Fast Blockchain - Node PageFB Node
    1. Node identifier
    2. Node identifier arrows change the node by 1 (left -1, right +1)
    3. Blockchain identifier
    4. Last time node checked with check_computational_work pallet.
    5. Total number of checks with check_computational_work pallet on this node
    6. How many pass results on this block
    1f.Heavy Blockchain - Node PageHB Node For functionalities see 1e. list.

    Future Plansโ€‹

    - + \ No newline at end of file diff --git a/applications/DeepAccountAnalytics-PolkadotDataAlliance.html b/applications/DeepAccountAnalytics-PolkadotDataAlliance.html index 7fe74c16b9c..67c5cd00216 100644 --- a/applications/DeepAccountAnalytics-PolkadotDataAlliance.html +++ b/applications/DeepAccountAnalytics-PolkadotDataAlliance.html @@ -4,7 +4,7 @@ Web3 Foundation Deep Account Analytics in Three Tiers for the Polkadot Data Alliance | Web3 Foundation Grants - + @@ -45,7 +45,7 @@ but we hope our value and commitment to sharing and collaboration is recognized by the community so we can be productive high impact contributors.

    - + \ No newline at end of file diff --git a/applications/Diffy_chat.html b/applications/Diffy_chat.html index 95cf1fa5558..c3aef3a0656 100644 --- a/applications/Diffy_chat.html +++ b/applications/Diffy_chat.html @@ -4,7 +4,7 @@ Diffy messenger | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Diffy messenger

    • Team Name: BelSoft
    • Payment Address: Polkadot (Statemint): 14nQH1ZTDkRxLWdCWbSZjRGrBJpXgj4m2RRZDtQZExPP73K (USDT)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    This application complies with a potentially interesting project โ€œPrivate instant messenger that uses on-chain identityโ€ mentioned in Open Source Polkadot Stack page in the โ€œSocial Networkingโ€ section.

    Project Overview ๐Ÿ“„โ€‹

    A lot of sensitive data is meant to be transferred between parties in a secure way, but most of the centralized messengers and mail agents, even secured ones, have a common point of vulnerability - a centralized database/backend that stores all the data and manages connections. Meanwhile, some entities or even industries as a whole have demand for secured private channels for exchanging messages, e.g. medical institutions, that exchange sensitive data with patients or with other market players.

    The aim of this project is to develop a secured decentralized messenger that doesnโ€™t store data on a centralized backend and uses personal Polkadot wallet credentials for chatting initiation and messaging.

    Project Detailsโ€‹

    P2p channels between users will be set using WebRTC. We will develop a Substrate pallet for exchanging SDP offers. For address discovery of NAT users we will use any public STUN server. All messages between users will be encrypted with userโ€™s public keys, so only receiving user could decrypt his messages using his private key of his Polkadot wallet. Also, the pallet will include a โ€œcontactsโ€ feature: a user will be able to tie names to wallet addresses and organize his contacts in a common way.

    image

    Ecosystem Fitโ€‹

    The Diffy chat dapp is very in demand in areas where it is crucial to protect personal and other critical data from unauthorized access during interaction or communication between counterparties. The target audience is very wide: from medical institutions providing telemedicine services to remote financial services and corporate channels for transmitting sensitive information between remote divisions.

    In the Open Source Polkadot Stack we see the Uke Protocol Pallet project, that provides functionality to perform basic messaging and identity assignment to users on a given Substrate chain. Unlike Uke Protocol, Diffy chat dapp wonโ€™t use a blockchain for sending and storing entire messages as in case of mass use this feature will dramatically clog the blockchain with unnecessary information like "hello" messages. Our dapp will use a blockchain just for authorization purposes, p2p connection initiation and for personal encryption keys. History backup feature can be available on later stages of the project by storing files locally or in IPFS with putting just a hash sum in a blockchain.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Max Remov, managing partner at BelSoft Dev d.o.o
    • Alexey Vexin, CEO at BelSoft Dev d.o.o
    • Dmitrii Shevchenko, CTO at BelSoft Dev d.o.o
    • Nikita Orlov, Teamlead at BelSoft Dev d.o.o
    • Alexander Plekhanov, Middle full stack developer at BelSoft Dev d.o.o
    • Valeriy Tetevin, Senior full stack developer at BelSoft Dev d.o.o

    Contactโ€‹

    • Registered Address: Kneza Mihaila 33, sprat 2 , Stari Grad , 11000 Beograd , Srbija
    • Registered Legal Entity: Belsoft Dev DOO Beograd

    Team's experienceโ€‹

    Max Remov is a business and personality transformation expert, executive and visionary, innovation instigator across telecom, retail, chemistry, pharma. Participates in several crypto initiatives.

    Alexey Vexin is product owner and project manager with 10+ years of experience in managing complicated telecoms and IT projects in Telco, Utilities and Governmental sectors with deep focus on business process management. Led dozens of federal scaled projects for IT systems implementation and industry scaled technology development, standardization and implementation.

    Dmitrii Shevchenko is a TechLead engineer with 10+ years of experience in developing and integrating IT, networking, security and blockchain solutions. Involved in implementation of highly reliable industrial solutions and development of FinTech and DeFi applications.

    Nikita Orlov, ETH Waterloo 2019 hackathon prize-winner, is a TechLead engineer with over 8 years of experience in development and integration of fault-tolerant high-loaded SaaS IT solutions including relevant experience in blockchain solutions.

    Alexander Plekhanov is a full stack software developer with over 5 years of experience including blockchain-based projects, enterprise solutions for fintech, call-centers, government services. Recent time mostly focused on smart-contracts development.

    Valeriy Tetevin is a programming engineer with over 8 years of experience in cloud-native applications. He also has strong knowledge of microservices architecture and back-end development for high-loaded applications.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    We plan to execute 3 deliverables in two milestones:

    • a Substrate pallet for chat initiation;
    • a DOTRTC library for p2p transport implementation with test html pages for message passing;
    • a web-messenger dapp MVP with polkadot wallets authorisation.

    The project will be supported by a team of 2 developers, 1 UI/UX designer, 1 DevOps engineer and 1 QA.

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 3,5 FTE
    • Total Costs: 30,000 USDT

    Milestone 1 โ€” Design and development of a pallet and a DOTRTC libraryโ€‹

    • Estimated duration: 1,5 months
    • FTE: 2
    • Costs: 16,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how the developed features work.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure new functionality and robustness. In the guide, we will describe how to run these tests.
    1.Diffy chat palletWe will develop a pallet (using Rust) which will include event handling to send and approve WebRTC offers for chat initiation.
    2.DOTRTC libraryWe will develop a DOTRTC library (with JS) for p2p transport implementation using a parachain with Diffy chat pallet. This library will include an API for organizing p2p communication, methods for splitting packets into chunks (and reassemble on the receiverโ€™s end). For secure messaging between two participants a e2e encryption using the rs25519 algorithm will be implemented in the DOTRTC library (a sender will encrypt outgoing messages with recipientโ€™s public key so only the recipient could decrypt them with his private key).
    3.HTML test pageWe will deliver an HTML test page for DOTRTC library testing (setting a p2p channel between 2 users using the DOTRTC library).

    Milestone 2 โ€” A web messenger MVP developmentโ€‹

    • Estimated duration: 1,5 months
    • FTE: 1,5
    • Costs: 14,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how the new dapp works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains what was achieved, how to use the new Dapp and what benefits what are the benefits of using the system
    1.Contacts list featureWe will develop a contact list feature allowing users to tie real names to contactโ€™s wallet addresses and store them encrypted in a blockchain. Encryption and decryption will be carried out on the frontend.
    2.Web messenger dapp MVPA web messenger dapp (written on JS) with authorization via Polkadot.js keys, p2p messaging using developed DOTRTC library and contacts list: a user will be able to start a conversation with someone on his contacts list. A web dapp MVP mockup is shouwn below and the basic user logic is as follows. To establish a chat User A sends a short 1st message to User B (limited to 50 symbols as it is written into the blockchain). This message is sent with the connection request. When User B is on-line he receives this message with connection request and accepts it: automatically for users on his contact list and manually for requests from unknown users (connection request can be declined as well).

    Diffy_chat mockup

    Future Plansโ€‹

    In the next stages of the project we plan to implement new fundamental features like:

    • offline messaging;
    • group chats (p2mp);
    • sending/receiving files;
    • chats backup feature.

    These should be developed under later stages of the project.

    - + \ No newline at end of file diff --git a/applications/DipoleOracle.html b/applications/DipoleOracle.html index 51bb2f07b24..9cbb819bbb3 100644 --- a/applications/DipoleOracle.html +++ b/applications/DipoleOracle.html @@ -4,13 +4,13 @@ Dipole Oracle | Web3 Foundation Grants - +
    Skip to main content

    Dipole Oracle

    • Proposer: KK

    • Payment Address:

      โ€‹ BTC: 12q2NigsthG7YdxUBRbAaZPTHYj1xuEjCx

    Project Description ๐Ÿ“„โ€‹

    Dipole is an award-winning clean-tech company that brings blockchain technology into distributed energy resource management. Our aim is to provide service for the massive and fragmented distributed energy assets that will emerge in the near future, as well as facilitate the decarbonization of the energy system.

    Our EMS platform allows secure and reliable energy trading, where users can access a customized energy management module and trace their energy consumption in real-time.

    Working alongside the UN Environment Programme (UNEP), Dipole Tech already has been implementing regional energy allocation projects in communities in Manila and Bangkok, providing decentralized tools that allow customers to monitor, manage, and buy electricity in local markets.

    Dipole Oracle

    Due to large amount of onchain-offchain data interaction involved in the distributed energy scenario, together with its fragmented nature, there caused massive data interoperability in the reality. However Dipole is developing an independent Substrate-based blockchain on the Polkadot network (DipoleOracle), which records all stages of the energy industry and inter-operators with other systems.

    DipoleOracle connects Dipole chain and offline electrical hardware, ensure the safety and accuracy of offline power usage and transaction data, make them applicable for blockchain use. Which can enrich the ecosystem of Substrate and Polkadot, and bring the revolution of clean energy ecology in whole society.

    DipoleOracle includes four key components: Operator, GoodsOracle, PayOracle and Collector. The whole system provides the feeding and collecting of energy generation/consumption and transaction data.

    • Operator

    In the energy industry, electrical hardwares are extremely miscellaneous. The Operator module defines several common used electrical hardwares like electricity meter and charging point. The Operator module allows each registered electrical hardware to upload data online.

    • GoodsOracle

    In the energy industry, collecting real-time data from hardware such as electricity meter and charging piles has always been a technical challenge. DipoleGoodsOracle can be applicable to various electricity meters and protocols, which achieve a solid progress in this area.

    • PayOracle

    In the energy industry, periodical power transaction cause high needs of splitting bills for participants, third-party payments or stablecoins. PayOracle is able to complete all steps automatically. In area which don't have completed payment system like South Asia and Africa, PayOracle can enormously reduce the cost of payment.

    • Collector

    In the energy industry, collecting energy generation/consumption and transaction data costs a lot of manpower and material resources. With the Collector module, users can easily get data they really need, which can help them customize their business scenarios.

    Advantage

    • a customized oracle module can be applied to different kinds of variables data procession, such as electricity meter and charging point.

    • with the Operator module, any registered IoT device can easily upload data. Users can customized their set up like authorized uploading devices, filter malicious ones, and even build a scoring system.

    • with the Collector module, users can customize advanced calculating model such as dynamic data processing, incremental and filter statistics.

    Team ๐Ÿ‘ฅโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 4 weeks
    • Full-time equivalent (FTE): 1.25
    • Total Costs: 1 BTC

    Milestoneโ€‹

    • Estimated Duration: 4 weeks
    • FTE: 1.25
    • Costs: 1 BTC
    NumberDeliverableSpecification
    1.DipoleOracleIncluding GoodsOracle and PayOracle processing; Feature complete for traits, pallets and utilities;complete benchmarking, weight annotation, test coverage and code linting
    2.Backend ClientBackend client example in the programming language nodejs, which shows how to use DipoleOracle
    3.DocumentationDocumentation, examples and tutorials will be provided for using DipoleOracle

    DipoleOracle Features

    • traits
      • OperatorManager
      • GoodsDataProvider
      • PayDataProvider
      • CollectorManager
    • pallets
      • collector
      • goods-oracle
      • operator
      • pay-oracle
      • support

    Additional Information โž•โ€‹

    • We're currently implementing a Substrate-based chain, which provides blockchain services for clean energy ecosystem, including energy-based oracle, energy traceability, distributed energy trading, energy-based NFT, etc. DipoleOracle is a very important part of the ecosystem.
    • This project was born out of genuine needs from clean energy evolution based on blockchain. Our intention is to develop a clean energy ecosystem and accelerate the growth of Substrate and Polkadot community.
    • Currently it's all coming out of Dipole's own development cost
    • We were rewarded 2020 Asia Pacific Low Carbon Lifestyle Challenge Prize issued by the United Nations Environment Programme (UNEP)

    About Dipoleโ€‹

    Dipole Tech is a Distributed Energy Resource aggregator, providing services for the massive amount of distributed energy assets that will emerge in the future and facilitating the decarbonization of the energy system. Dipole Tech develops an independent Substrate-based blockchain which records all stages within the industry and enables interoperability from DER assets. Learn more by visiting the Dipole Tech website or following them on Twitter.

    - + \ No newline at end of file diff --git a/applications/DistributedKeyManagement.html b/applications/DistributedKeyManagement.html index a28ecc80fa3..a7606ba5cb9 100644 --- a/applications/DistributedKeyManagement.html +++ b/applications/DistributedKeyManagement.html @@ -4,7 +4,7 @@ Distributed Key Management | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ Advisor: Nicolas Christin

    Contactโ€‹

    Individual / Sole Proprietor

    Team's experienceโ€‹

    Jett Hays is the President of the Carnegie Mellon blockchain club where he helps members build and understand the decentralized future. Previous projects have included a open source key management package[https://github.com/KryptikApp/kryptik-seedloop] and a multichain web wallet. Both projects have received support from Carnegie Mellon and multiple blockchain foundations.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    The idea of a distributed key manager came to me during a class at Carnegie Mellon on shamir secret sharing. After coming up with a rough interface, I applied for a small undergraduate research grant from CMU, with Professor Nicolas Christin agreeing to be my advisor. This research led me to create the open source Kryptik wallet, whcih I have been working on for the past year. A short demo of the wallet can be found via this link. This wallet uses a simple version of the distributed key management system I described above.

    As part of this project, I also released a seedloop manager as an open source NPM package, which can be found here. This package allows developers to easily generate wallets and sign transactions across multiple blockchains.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 - Research Paperโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide regular blog updates that document our discoveries on decentralized key management as we develop the paper.
    0c.Testing and Testing GuideSince this milestone is focused on creating and publishing a research paper, there is no need for a testing guide.
    0d.DockerThis milestone does not involve explicit software, so no dockerfiles are needed for testing.
    0e.ArticleWe will publish an article that summarizes the key findings of our distributed key management research for developers (who may not be interested in the nitty gritty technical details or security models).
    1.Formal InvestigationThe research period will be spent investigating the following questions about the kryptik key management system. What is the threat model? How can keys be synced across devices? How can the system include more than two shareholders? What is the ideal number of shareholders? Is there any application to social recovery? By the end of this period, I will have organized a sequence of proofs and thoughts that can be shaped into a paper. Each question and associated discovery will be documented via regular blog posts.
    2.Research PaperThis paper will include an in depth analysis of the research questions discussed above. Professor Nicolas Cristin of Carnegie Mellon will help advise the paperโ€“ he served as an advisor for my initial research grant from CMU. The paper will be released as an open source document on Github. We expect this open source key management knowledge to provide a strong foundation for future Polkadot/Kusama/Substrate wallet designers.

    Milestone 2 โ€” Reference Implementationโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide extensive inline documentation that describes the purpose of functions and parameters. This will help create a 'trail of knowledge' that developers can follow through the key management system.
    0c.Testing and Testing GuideWe will include a step by step guide that shows the distributed key management system works as intended. Unit tests will be included for critical functions like share generation/ recombination. Unit tests will be executed using vitest.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that provides a step by step explanation of the distributed key management system and how each function is implemented in code. This will be published as a blog post.
    1.Vault ModuleThe vault module will provide a standard interface for storing a BIP 39 seed and multiple blockchain accounts on the client.
    2.Encryption ModuleThe encryption module will allow seed vaults to be locked/unlocked via a user provided password. The module will also use a randomly generated encryption key to create ciphertext for the BIP39 seedphrase when persisting vault storage on the client.
    3.Share ModuleThe share module will generate shamir shares for a given piece of data (in this case the encryption secret). This module will also allow shares to be recombined (according to the k of n secret sharing scheme) to reconstruct the original piece of data.
    4.Sync ModuleThis module will allow seed vaults to be synced across devices.
    5.Web DeploymentAnd finally, we will wrap these modules in a nice UI and deploy the interface to a website (likely using NextJs + Vercel). This website will allow developers to create a vault, sync their devices, and sign sample transactions. This will be accomplished via open source React components that developers can reuse in their own application. The deployed app will have Polkadot/Kusama/Substrate specific examples (address generation, signatures, etc) that will benefit future developers.

    Future Plansโ€‹

    After the grant is completed, I will continue improving the open source Kryptik wallet, which builds upon the distributed key management system described above. Work on the wallet interfaceโ€“ which has been sponsored by other grantsโ€“ will necessarily include revisiting the key management system and making improvements (such as adding the ability to sync key shares between devices). Beyond that, the research and published paper are a timeless body of knowledge that will continually benefit production implementations and new research on key management.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? I first heard about the grants program at EthDenver 2022. I then learned more about the program via the Web3 Foundation Website.

    The NEAR foundation awarded a $45,000 grant to develop the Kryptik wallet interface. This work wrapped the key management system with software that supports multi chain swaps, collectibles, payments, etc. I also received $20,000 from the Solana Foundation to provide open source documentation and Solana specific examples. Both of these grants are directed towards the Kryptik wallet interface, not the key management system which was devised separately.

    Finally, I received $500 from Carnegie Mellon to build the key manager and host the wallet interface.

    **How does this project benefit the Polkadot/Kusama/Substrate ecosystem? Asymmetric key management is an open issue that affects every blockchain ecosystem. An improved key management system will help improve wallet design which, in turn, will help improve the user experience of the Polkadot/Kusama/Substrate ecosystem. The research proposed above will provide foundational knowledge and software that can be integrated into existing Polkadot related wallets and in emerging wallets that have yet to be designed. In summary, successful execution of the grant will result in a simple and more secure way to interact with the Polkadot/Kusama/Substrate ecosystem. This will benefit users, who will have an improved wallet experience, and developers who can build upon a novel approach to key management.

    - + \ No newline at end of file diff --git a/applications/DotPay.html b/applications/DotPay.html index 6411f344fe6..06a2db6d591 100644 --- a/applications/DotPay.html +++ b/applications/DotPay.html @@ -4,7 +4,7 @@ DOT PAY | Web3 Foundation Grants - + @@ -27,7 +27,7 @@ The following is a brief description of what the repository contains: Including GitHub webhook server๏ผŒit can listen to GitHub events, handle some specific instructions in the issue, and extend the instruction processor.

    Future Plansโ€‹

    FAQโ€‹

    Why not use Paypal?

    Paypal has obvious borders for global developer collaboration, and it is not convenient to use.

    In fact, we did similar attempts at the earliest and found that many countries do not use Paypal at all.

    And we hope that open source paid collaboration More decentralized rather than relying on a certain company.

    - + \ No newline at end of file diff --git a/applications/DotPulse.html b/applications/DotPulse.html index ce4e7e538e8..e9528b445f6 100644 --- a/applications/DotPulse.html +++ b/applications/DotPulse.html @@ -4,14 +4,14 @@ DotPulse | Web3 Foundation Grants - +
    Skip to main content

    DotPulse

    • Team Name: CrossChain Labs
    • Payment Address: 0xC289B81a8e5f8F8d691b4Cf1DBc16A7107B630e3 (USDC)
    • Level: 3

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Polkadot has increasingly grown the open source developer ecosystem. But there is currently no way to get an activity overview and easily track the development among different Polkadot organisations on Github, understand what is their status, track the contributions made by developers and get an idea on how the repositories evolve. Is really hard to understand how the Polkadot ecosystem is progressing since the data is scattered all over GitHub, with contributors, commits, issues, repositories and PRs data.

    The solution that CrossChain Labs presents is going to address the problems described above and will offer clarity on the open source Polkadotโ€™s developer ecosystem. This will be done by scraping the data related to Polkadotโ€™s organisations on GitHub and exposing it in a nicely designed dashboard that allows tracking the number of commits, repositories, contributors, PRs, the top contributors of the month, the evolution of commits and active contributors for each month over the last year and monitoring the recent commits that are being done in the various Polkadot organisations.

    Project Detailsโ€‹

    Deliverables:

    • GitHub Scraper that will collect all the required data from GitHub
    • DotPulse APIs that will serve to get the data from the scraper and interact with the DotPulse dashboard
    • DotPulse Dashboard that will include:
      • the statistics top section with the overall number of commits, repositories, contributors and PRs
      • contributors of the month
      • commits graph with info regarding the last 12 months
      • issues graph that shows the number of open and closed issues together with their total
      • graph of active contributors for each month over the last year
      • the recent commits section that shows the activity of the ecosystem over the last 30 days, with clickable links to open a commit, its repository or the developer's profile on GitHub

    Dashboard Overview

    DotPulse

    Ecosystem Fitโ€‹

    The DotPulse project will enable all the interested parties to track the development among different Polkadot organisations on Github, to follow the number of commits, repositories, contributors, PRs, the top contributors of the month, the evolution of commits and active contributors for each month over the last year and monitor the recent commits that are being done in the various Polkadot organisations.

    There are many benefits of getting the DotPulse project up and running:

    • it offers a clear overview on the open source development that is being done across the various Polkadot organizations, by having all the required data aggregated in one place
    • acknowledges the contributors of the month
    • displays the active contributors for each month over the last year
    • shows the evolution of the number of commits made on GitHub by developers throughout the entire Polkadot ecosystem
    • outlines the recent commits

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Andreea - Team Leader
    • Cristina - Full Stack Developer (JavaScript, React)
    • Catalin - Full Stack Developer (JavaScript, React)
    • Florin - UI/UX Designer (Sketch, Figma)

    Contactโ€‹

    • Registered Address: Oaspetilor Boulevard, 15, Bucharest, Romania, #013865
    • Registered Legal Entity: CrossChain Labs SRL

    Team's experienceโ€‹

    Weโ€™re CrossChain Labs, a team of of designer and software developersย with hands-on experience on blockchain technology and development of decentralised applications, with previous experience as ConsenSys employees. Some of the latest dev-grants were for projects from Filecoin (https://filmarket.io/) and NEAR protocol (NEAR registrar, Audit Registry, near.link, Developer Dashboard) with tech stack: IPFS, Arweave, rust, react, go and javascript. We're creative, experienced, responsible, organised and do our best to make high quality work and bring ideas to life.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Since Polkadot has increasingly grown the open source developer ecosystem, there is a need to get an activity overview and easily track the development among different Polkadot organisations on Github, understand what is their status, track the contributions made by developers and get an idea on how the repositories evolve. Is really hard to understand how the Polkadot ecosystem is progressing since the data is scattered all over GitHub, with contributors, commits, issues, repositories and PRs data.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 8 weeks
    • Full-Time Equivalent (FTE): 3 FTE, 1 PTE
    • Total Costs: 42,000 USD

    Milestone 1โ€‹

    • Estimated duration: 4 weeks
    • FTE: 3.5
    • Costs: 20,500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT
    0b.DocumentationWe will provide both documentation of the code and a basic video tutorial that explains how a user can easily use DotPulse app
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.Implement Github scraper functionalityPeriodically update the list of repositories that are being part of the Polkadot organizations on GitHub
    2.Implement Github scraper functionalityCalculate the total number of commits, repositories, contributors and PRs from the entire Polkadot ecosystem
    3.Implement Github scraper functionalityGet the contributors of the month based on the number of commits
    4.Implement Github scraper functionalityCalculate the total number of commits across all the repositories for each month over the last year
    5.Implement Github scraper functionalityCollect the total number of issues that are being opened or closed at the moment
    6.Implement Github scraper functionalityCalculate the number of active contributors for each month over the last year
    7.Implement Github scraper functionalityCollect the list of recent commits across all the Polkadot's Github repositories from the last 30 days
    8.Finalize the UXWith all its design elements
    9.Implement the DotPulse APIs required by frontendStatistics API that returns the overall number of commits, repositories, contributors, PRs
    10.Implement the DotPulse APIs required by frontendContributors API that returns the list of contributors of the month based on the number of commits over the last month
    11.Implement the DotPulse APIs required by frontendIssues APIs that return the total number of issues, the number of closed and open issues
    12.Implement the DotPulse APIs required by frontendCommits API that returns the total number of commits per month

    Milestone 2โ€‹

    • Estimated duration: 4 weeks
    • FTE: 3.5
    • Costs: 21,500 USD,
    • NOTE: The M2 calculation includes the cloud infrastructure cost estimated at $1,000
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT
    0b.DocumentationWe will provide both documentation of the code and a basic video tutorial that explains how a user can easily use DotPulse app
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains what was achieved as part of the grant and how users can benefit the most from DotPulse functionalities.
    1.Implement the DotPulse APIs required by frontendActive contributors API that returns the number of active developers for each month over the last year
    2.Implement the DotPulse APIs required by frontendRecent commits API that returns the list of recent commits across all Polkadot repositories over the last 30 days
    3.Build the DotPulse dashboardDisplay the statistics top section with the overall number of commits, repositories, contributors and PRs
    4.Build the DotPulse dashboardShow the contributors of the month
    5.Build the DotPulse dashboardCommits graph with info regarding the last 12 months
    6.Build the DotPulse dashboardIssues graph that shows the number of open and closed issues together with their total
    7.Build the DotPulse dashboardActive contributors graph
    8.Build the DotPulse dashboardThe recent commits section that shows the activity of the ecosystem over the last 30 days, with clickable links to open a commit, its repository or the developer's profile on GitHub
    9.Prepare the final adjustmentsCreate the production infrastructure on Google Cloud
    10.Prepare the final adjustmentsDeploy dotpulse.io webapp
    11.Prepare the final adjustmentsRun the final tests
    12.Prepare the final adjustmentsPublic release

    Future Plansโ€‹

    To drive adoption of the DotPulse platform, CrossChain Labs will:

    • create a YouTube video tutorial showcasing the DotPulse functionalities and usage
    • distribute it via Polkadot Discord channels
    • add Google Analytics to track users engagement in order to adapt and improve accordingly

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website / Friends & Colleagues

    - + \ No newline at end of file diff --git a/applications/Doter.html b/applications/Doter.html index d6520be36b3..a3860f0280f 100644 --- a/applications/Doter.html +++ b/applications/Doter.html @@ -4,7 +4,7 @@ Doter (A browser extension wallet for Polkadot) | Web3 Foundation Grants - + @@ -23,7 +23,7 @@ He joined Pinduoduo Inc.๏ผˆlisted on NASDAQ๏ผ‰in 2018 and became a full-time front-end development engineer. Responsible for the maintenance of the website promotion page, maintenance and development of the weChat applet architecture Project deployment and launch, development of productivity tools. He has three years of development experience, is familiar with project deployment and front-end technology stack, and is keen on Polkadot ecological technology trends.

    Personal Code Repos๏ผšhttps://github.com/dianluyuanli-wp

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Guan Yu๏ผšhttps://www.linkedin.com/in/yu-guan-482624155/
    Gao Jianli๏ผšhttps://www.linkedin.com/in/jianli-gao-6785a1140/

    Development Roadmapโ€‹

    In particular, we have completed the basic module of the Doter wallet, and the extension program has been put on the Google extension market. You can already install and use Doter.

    The following is a list of functions that have been implemented

    Overviewโ€‹

    Milestoneโ€‹

    M1: Injection and signatureโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DescriptionWe will implement wallet injection and transaction signature on Polkadot, and optimize the UI experience of existing funcctions.
    0c.Delivery timeMid May
    0d.How to verifyIt is expected that in Mid May, you can install the latest version of Doter in the Google Extended Market and verify the functional modules promised in the milestone. In addition, you can also verify through integration tests, We will provide yarn commond for anyone who want to run the unit test scripts and check the results.
    1.Core component Wallet injection on Polkadot
     Transaction signature on Polkadot
    * Optimize account creation, transfer, account management and other functions to improve user experience

    M2: Support kusama networkโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DescriptionWe will support all functional modules that have been implemented on Polkadot.
    0c.Delivery timeMid June
    0d.How to verifyIt is expected that in mid June, you can install the latest version of Doter in the Google Extended Market and verify the functional modules promised in the milestone. In addition, you can also verify through integration tests, We will provide yarn commond for anyone who want to run the unit test scripts and check the results.
    1.Core component Create and import wallets on Kusama
     Transfer and receive on Kusama
    Backup wallet on Kusama
     Query transaction records on Kusama
    Referendum on the chain on Kusama
     Switch multiple wallets on Kusama
    Manage address book on Kusama
     Switch language on Kusama
    * wallet injection and signature on Kusama

    Community engagementโ€‹

    This is a tutorial posted on medium๏ผšhttps://chainbridgenetwork.medium.com/polkadots-browser-extension-wallet-doter-ac8cd91a5bf3

    Future Plansโ€‹

    Doterโ€™s development team is ChainBridgeNetworkTeam. As the name suggests, our long-term vision is to be a bridge between different blockchains. We will use trust-free cross-chain asset custody and on-chain mapping to enable digital assets on different chains to be interoperable.

    Doter is our first product. We believe that with the launch of the parachain, Doter will act as an important interaction bridge in the Polkadot ecosystem. After completing the development of 2 milestones, we will design Doter version 2.0. In version 2.0, users can easily manage private digital assets without memorizing mnemonic words. This will be achieved through an innovative technology. We believe in version 2.0 Doter will greatly reduce the threshold for users to use wallets, making Doter a real bridge between Polkadot and ordinary users.

    Additional Informationโ€‹

    ChainBridgeNetworkTeam has just been established for two months, but we have completed the basic module of Doter, and have designed the other two milestones. In the next two months, we will deliver all pre-designed functional modules.

    So far, we have developed at our own expense, but in order to have sufficient funds to support the realization of our long-term vision, we will try to obtain the support of investment institutions.

    - + \ No newline at end of file diff --git a/applications/Dotflow.html b/applications/Dotflow.html index ac0630847fc..57323e4e424 100644 --- a/applications/Dotflow.html +++ b/applications/Dotflow.html @@ -4,7 +4,7 @@ Dotflow | Web3 Foundation Grants - + @@ -16,7 +16,7 @@ Of course, the user won't need to do this task manually, the UI will make this task very simple. The following section will show how this will work from the user's perspective.

    In case we update some of our addresses but we want to restrict access to the users that previously were granted access to that address there will be an option to regenerate the cipher. This way everyone that had access to the old address won't have access to the new one.

    UI Designโ€‹

    The UI will consist of three main parts:

    My Identity pageโ€‹

    1-1-dashboard-2.png

    The user will be able to create his own identity and provide the addresses he owns on to his identity.

    Add Address

    In case some of the addresses the user owns change over time he will be able to edit them. Also, we can select the option to regenerate the cipher so that people that had access to the old address won't be able to access the new one.

    1-1-create-identity-4.png

    When sharing their identity users will also be able to select which addresses will be available for the person they are sending their identity to. The user will have to copy his identityNo but also the identityKey which specifies which addresses are accessible for the user that receives this key.

    1-1-create-identity-2.png

    Transfer pageโ€‹

    2-1-transfer-1.png

    Ther user will be able to transfer tokens to an identity by specifying the origin chain, destionation chain, and the receiver's identityNo.

    Address Book pageโ€‹

    Address book page

    The user will be able to add identities to his own address book. The identities will be added by providing the identityNo and some nickname for the identity. Also by clicking on the transfer icon on one of the identities the user will be redirected to the transfer page where the identityNo will be automatically filled out.

    3-1-Address-book-3.png

    When adding an Identity to an address book the user will also be required to provide the Identity Key which will be used for decrypting the identity's addresses when sending tokens.

    Ecosystem Fitโ€‹

    This project fits perfectly with the Polkadot ecosystem because it has everything we need to make it work. Polkadot is a multi-chain network, so a lot of users have different addresses on different chains for the same reasons we mentioned earlier. That's why the problems we talked about are important in this ecosystem.

    XCM is going to be a core component of our project since it'll help us transfer tokens between the parachains and the relay chain.

    Target Audienceโ€‹

    Our target audience is people who deal with sending assets frequently over the Polkadot network.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Sergej Sakacโ€‹

    Oliver Limโ€‹

    Team Code Reposโ€‹

    We will be working on two separate repos, one for the UI and the other for the ink! contracts.

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 Example โ€” Basic functionalityโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationInk! contracts and the UI code will be well documented and open for everybody to take a look. The UI will be simple and intuitive to use.
    0c.Testing and Testing GuideThe Identity ink! contract will be well tested with unit and integration tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milesone.
    1.Identity ContractWe will write the code for the Identity contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Identity contract will provide a range of functions, including creating an identity, adding addresses that are mapped to specific blockchains, and updating these addresses as needed. The contract will automatically generate a unique identifier, referred to as identityNo, for each identity. To ensure maximum security, we will allow the identity creator to specify the accounts that are authorized to modify the identity's addresses. This will enable the creator to retain control of the identity even if they lose access to the account used to create it.
    2.My Identity pageThe My Identity page will be developed using React.js, providing users with a user-friendly interface to interact with the Identity contract. This will include the ability to create a new identity, add or remove addresses associated with an identity, and access and copy the unique identityNo to share with others. This UI will also generate the Identity Key for the user's identity and will update it every time he adds a new blockchain address. This Identity Key will be accessible for the identity creator when sharing his identity. The interface will be based on the mock design presented in the UI design section.

    Milestone 2 Example โ€” Additional featuresโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationThe contract and the website code will be well documented and open for everybody to check. The UI will have a simple UI that will be intuitive to use.
    0c.Testing and Testing GuideThe Address Book ink! contract will be well tested with unit and integration tests. The functionality for generating XCM messages will very well tested to make sure the tokens are always transfered to the proper destination.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milesone.
    0e.ArticleWe will publish a Medium article that explains the details of our project.
    1.Address BookWe will develop the code for the Address Book contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Address Book will enable users to create an address book and populate it with the identities they interact with most frequently. The identities will be added via their identityNo since our main goal is abstracting away addresses from the users. When adding an identity to an address book the Identity Key will also be needed. The address book will be stored on chain but the IdentityKey will be stored in local storage. The application will expect the user to provide the IdentityKey when using the app from a different device for the first time.
    2.Routing functionality.The code responsible for routing tokens to the correct destination will be incorporated into the frontend code written in TypeScript. This code will incorporate the necessary logic for constructing XCM messages to route tokens to the appropriate address. In cases where the destination chain is the same as the origin, a simple transaction will be executed. Because of possible race conditions where the identity owner is trying to update an address on a parachain while another user is trying to send funds to that identity on that parachain we introduce additional checks on the frontend. Before sending a transaction that will transfer the funds, the frontend will check whether there are any pending transactions happening that would change the address on the chain the user is transferring funds to. In case there is a pending transaction the user will get a warning and will be advised to wait for a moment and try sending the transaction again.
    3.Address Book pageWe will write the code for the Address Book UI using React.js. The UI will be based on the provided mock design that we displayed above in the UI design section. The UI will make it possible for users to create an address book and add identities to it.
    4.Transfer pageWe will create a user interface using React.js that will enable users to send tokens to a designated IdentityId. This UI will abstract away the complexity of addresses and leverage the Routing functionality described in this table(Section 2) to handle token routing. The UI design will be based on the mock design presented in the UI design section for optimal user experience.

    Future Plansโ€‹

    Our future plan is to expand our core functionality and add more features so that the tokens can be routed based on some different criteria. Some example of these ideas are:

    An exciting feature we would like to build in the future is enable token transfers between blockchains that are not part of the Polkadot network(e.g. Polkadot<->Ethereum).

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? GitHub

    - + \ No newline at end of file diff --git a/applications/Eiger_Storage_on_Polkadot_1.html b/applications/Eiger_Storage_on_Polkadot_1.html index 471c148a46a..b976f08e7b6 100644 --- a/applications/Eiger_Storage_on_Polkadot_1.html +++ b/applications/Eiger_Storage_on_Polkadot_1.html @@ -4,13 +4,13 @@ Proposal: Storage solution on Polkadot | Web3 Foundation Grants - +
    Skip to main content

    Proposal: Storage solution on Polkadot

    • Team Name: Eiger
    • Payment Address: Fiat 14.04.2023, 16:50 UTC+3
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    The main goal is to implement and maintain a Filecoin-like system parachain that uses DOT as the native token and is easily usable for all kinds of parachain projects in the ecosystem via XCM.

    Project Detailsโ€‹

    To accomplish this we are submitting this initial proposal to update our previous research and test how XCM could be used to allow the ecosystem to use this storage network.

    We are interested to build this because:

    • Native storage in Polkadot payable in DOT is not currently available
    • We have done the research 2 years ago.
    • After talking to community members in Decoded 2023 we noticed there is demand for this kind of functionality.

    We will not be using Trusted Execution Environments or Enclaves in this solution.

    Ecosystem Fitโ€‹

    Currently a storage solution native to Polkadot is missing, by building a system parachain anyone in the ecosystem will be able to access storage thru XCM, pay in native DOT and build more complex applications withour relying on other networks.

    Team ๐Ÿ‘ฅโ€‹

    Eiger - We help leading technology companies to scale and develop their core technologies to gain an edge by providing expert teams in the most critical areas of modern web3 development.

    Eiger is part of the Equilibrium group which includes engineers from our sister company Equilibrium Labs.

    Team membersโ€‹

    • Tomek Piotrowski (Github, Linkedin) Software Engineer at Eiger, specializing in Rust-based applications. With a strong background in software development, he has spent recent years focusing on the Rust programming language. At Eiger, Tomasz actively contributes to the advancement of Rust-based blockchains and their ecosystems.
    • Mark Henderson (GitHub, Twitter) is the VP of Engineering at Equilibrium. He has led the team starting with the original Rust IPFS implementation in late 2019, through engagements with many of the largest names in Web3, and is part of the team that did the original research 2 years ago. Core contributor to OrbitDB, Rust IPFS, and Ziggurat.
    • Piotr Olszewski (Github, LinkedIn) & Karlo Mardesic (Github, LinkedIn) - currently working on MoveVM pallet, they will contribute with their Polkadot and Substrate knowledge and join the next stage of this project, implementation.

    Contactโ€‹

    • Registered Address: Linnankatu 3 A 24, 20100 Turku, Finland
    • Registered Legal Entity: Eiger Oy

    Team's experienceโ€‹

    Our clients include: Starknet, Aleo, Forte, Zcash, Fireblocks, Ripple, Algorand, Solana, Flow, Elusiv, Celestia, Stellar and more.

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    The goal of this proposal is to update the work we have done in the past to account for what has changed in the past 2 years in the Polkadot ecosystem and the advancements made in storage solutions like Filecoin.

    In addition to this research and updating the code, we will also test how XCM could be used by anyone in the ecosystem to interact with this storage.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Update research, update code and test XCMโ€‹

    • Total Estimated Duration: 1 month
    • Full-Time Equivalent (FTE): 1.5
    • Total Costs: 30,000 USD

    Two engineers will work together and in parallel to deliver these 3 subcomponents:

    1. Update the research done previously to reflect latest tech changes in Polkadot and Substrate. We want to figure out what it would take to implement a whole storage solution as a parachain without depending on 3rd part chains and evaluate what components need to be written from scratch and what can be reused.
    2. Update the code delivered in CGS or start fresh, whichever makes most sense. The scope of this is to deliver scafolding/template repository with boilerplace and dummy funcitonality. On top of this we can then test the milesone #3 below.
    3. Research and test how XCM can be used. Using the scafolding code from #2 we can test how XCM can be used to access the storage from a different parachain.
    NumberDeliverableSpecification
    0a.Copyright and LicensesApache 2.0 and MIT
    0b.Documentation/TutorialWe will provide both inline documentation of the POC code and a basic tutorial that explains how a user can run the same test.
    0c.MethodologyDetailed explanation of how the results were achieved and how to reproduce/verify the results.
    0d.InfrastructureWe will provide the list of all requirements that can be used to verify the code deliverable with this milestone. This is related to deliverable 0b. Documentation and 0g. Docker
    0e.ArticleContent: Updated research doc detailing our findings, how the tech has changed and how the solution will look like.
    0f.Testing and Testing GuideWe will deliver code that tests how XCM might be used to access this storage parachains.
    0g.DockerWhere relevant. we will provide a Dockerfile(s) that can be used to run and test the MVP and the XCM test.
    1.Updated CGS codeWe will deliver a repositiory with the update MVP code

    Future Plansโ€‹

    This initial grant will produce a game plan on how exactly this storage network will work. Using this knowledge we will submit another future proposal to build this solution. Once this storage solution has been built, it will be voted on by a governance vote. If successful then this system parachain will be available to be used by anyone in the ecosystem and payable in native DOT.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We are working on MoveVM pallet grant which asnwers the original RFP from the foundation so we were familiar with the ecosystem.

    - + \ No newline at end of file diff --git a/applications/EverlastingCash.html b/applications/EverlastingCash.html index 92fecd77186..dd57c35e375 100644 --- a/applications/EverlastingCash.html +++ b/applications/EverlastingCash.html @@ -4,7 +4,7 @@ Everlasting Cash | Web3 Foundation Grants - + @@ -35,7 +35,7 @@ Everlasting Cash will exist as an independent asset in the Polkadot ecosystem, and will also power the Cycan decentralized autonomous trust (DAT) on the path to revolutionize trust in the financial market.

    Additional Information โž•โ€‹

    ย No

    ย No

    ย To the best of our knowledge, there is no project about anti-inflation stablecoin that is similar to our project. Please let us know if there are any.

    - + \ No newline at end of file diff --git a/applications/FIAT-on-off-ramp.html b/applications/FIAT-on-off-ramp.html index 4a2be8359da..da0e2eab264 100644 --- a/applications/FIAT-on-off-ramp.html +++ b/applications/FIAT-on-off-ramp.html @@ -4,7 +4,7 @@ FIAT on-off-ramp | Web3 Foundation Grants - + @@ -25,7 +25,7 @@ this information is not there or an error case, we fall back to a default. Important is, that the balance of the bank account and the stable-coins stay the same. A default can be to wire-transfer funds back to the originator or to mint the stable-coins to a predefined address. 

    +-------------+          +-------------------+              +-------------------+                         +---------------+           +---------------+         
    | BankAccount |          | OpenBankingClient |              | EventProcessing   |                         | FiatChain     |           | TargetAccount |         
    +-------------+          +-------------------+              +-------------------+                         +---------------+           +---------------+     
           |                           |                                  |                                           |                           |                         
           |                           |                                  |                                           |                           |          
           |                           |                                  |                                           |                           |
           |                           |                                  |                                           |                           |                         
           |                           |           Check new Transactions |                                           |                           |                         
           |                           |<---------------------------------|                                           |                           |                         
           |                           |                                  |                                           |                           |                         
           |           daily statement |                                  |                                           |                           |                        
           |<--------------------------|                                  |                                           |                           |                         
           |                           |                                  |                                           |                           |                         
           |                           |                                  | found new incoming Payment:+100 โ‚ฌ         |                           |                         
           |                           |                                  |----------------------------------         |                           |                        
           |                           |                                  |                                 |         |                           |                         
           |                           |                                  |<---------------------------------         |                           |                         
           |                           |                                  |                                           |                           |                         
           |                           |                                  | mint 100 to TargetAddress                 |                           |                         
           |                           |                                  |------------------------------------------>|                           |                         
           |                           |                                  |                                           |                           |                         
           |                           |                                  |                                           | assign 100 tokens         |                         
           |                           |                                  |                                           |-------------------------->|                         
           |                           |                                  |                                           |                           |                         
           |                           |                                  |                                           |                           |        
           |                           |                                  |                                           |                           |
           |                           |                                  |                                           |                           |
    - + \ No newline at end of file diff --git a/applications/Faucet.html b/applications/Faucet.html index 3a86fff92da..cb929428e8c 100644 --- a/applications/Faucet.html +++ b/applications/Faucet.html @@ -4,13 +4,13 @@ Generic sybil-resistant faucet | Web3 Foundation Grants - +
    Skip to main content

    Generic sybil-resistant faucet

    • Team Name: MB Karolio reikalai
    • Payment Address: 0xc3e6eFA4D0847203dD4E19B7D114516Eb45840EC (DAI)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Sybil-resistant faucet is a generic browser-based faucet solution that can be used on any existing parachain (substrate-based chain, either pallets or ink! smart contracts).

    Project Detailsโ€‹

    Mockupโ€‹

    mockup

    Technology stackโ€‹

    • Next.js
    • TypeScript
    • Tailwind
    • Redis
    • @polkadot{.js}

    Architectureโ€‹

    architecture

    Configurationโ€‹

    To make the faucet generic, it will store its configuration settings in .env file which will include the following settings:

    • DRIP_CAP - how many tokens to send per drip
    • DRIP_DELAY - how often user's can request to drip tokens (in ms)
    • REDIS_ENDPOINT - Redis instance endpoint
    • RPC_ENDPOINT - Substrate node endpoint
    • PORT - Substrate node port
    • FAUCET_ACCOUNT_MNEMONIC - mnemonic of faucet's wallet
    • NEXTAUTH_ENDPOINT - authentication endpoint
    • NEXTAUTH_JWT_SECRET - used to encrypt JWT tokens
    • TWITTER_CLIENT_ID - Twitter client ID
    • TWITTER_CLIENT_SECRET - Twitter client secret
    • GITHUB_CLIENT_ID - GitHub client ID
    • GITHUB_CLIENT_SECRET - GitHub client secret

    Ecosystem Fitโ€‹

    Many dApps are facing an issue where itโ€™s difficult to onboard new users. Thus, the goal is to simplify the process by making it easier for parachain and dApp developers to spin up their own faucets, and give users free tokens without people exploiting the system. In order to make the system sybil-resistant, centralised solutions like Twitter or GitHub login will be integrated, that will uniquely identify users, and enable dripping tokens to the account only once per given time period.

    Some similar projects include:

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Karolis Ramanauskas: full-stack developer & product designer

    Contactโ€‹

    • Registered Address: Liepลณ g. 83, Klaipฤ—da 92195
    • Registered Legal Entity: MB Karolio reikalai

    Team's experienceโ€‹

    Karolis is product-minded software engineer who enjoys the challenge of creating pleasant, easy-to-use user experiences. He has worked on large-scale projects for his employers, as well as side-projects of his own. Some of the most notable experiences include building observability tools used by thousands of engineers at Uber that alert and help resolve new incidents, and enable to build more reliable services. He has also worked on a design system for Volvo Cars, and then became responsible for building tools to replace existing translation processes at the company to make them more effective.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1 month
    • Full-Time Equivalent (FTE): 1 FTE
    • Total Costs: 4,000 USD

    Milestone 1 โ€” Implement the Faucetโ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: 4,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationI will provide both inline documentation of the code and a tutorial that explains how a developer can spin up his/her own faucet.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.ArticleI will publish an article that explains how the faucet works, why it was created, and how it can be used by developers.
    1.User InterfaceI will create faucet UI with Tailwind. It will include address form, login buttons, as well as error and success states.
    2.AuthenticationI will create a module for 0Auth user authentication that will uniquely identify users and make faucet sybil-resistant.
    3.User statusI will create a module for checking whether user is eligible to receive free tokens.
    4.Faucet dripI wil create a module that will send user free tokens if eligible.

    Future Plansโ€‹

    • Keep adding additional 0Auth options or other features if needed.
    • Keep maintaining the project in case of potential issues.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Developer DAO

    - + \ No newline at end of file diff --git a/applications/Fennel_Protocol.html b/applications/Fennel_Protocol.html index f5821acef81..016d7347056 100644 --- a/applications/Fennel_Protocol.html +++ b/applications/Fennel_Protocol.html @@ -4,7 +4,7 @@ Fennel Protocol | Web3 Foundation Grants - + @@ -34,7 +34,7 @@ We heard about the Grants Program from the Web 3 Foundation Website, as well as personal recommendations from Polkadot community members.

    Thus far, we've ported our Theriak repository to the most recent version of Substrate as of writing of this application. Financial contribution has not yet begun for the Fennel Protocol project. We've also begun writing function and trait stubs to ensure that thorough documentation can be generated.

    - + \ No newline at end of file diff --git a/applications/FuzzLand.html b/applications/FuzzLand.html index 9009b5c8dd1..2b65f95e99b 100644 --- a/applications/FuzzLand.html +++ b/applications/FuzzLand.html @@ -4,7 +4,7 @@ FuzzLand | Web3 Foundation Grants - + @@ -13,7 +13,7 @@

    Screen 2: Onboarding - Select Bounty

    Screen 3: Auditing Report

    Ecosystem Fitโ€‹

    Our platform can serve the project owners who have auditing requests for their projects, regardless of Web2 or Web3: as long as they can be compiled into LLVM (e.g., any Ink, Solidity, Rust, C++, etc. programs). The auditing reports and how they correlate with the on-chain statistics can also be reviewed by anyone: not just the project owner, but also the project users. Project owners can gain more trust by sharing the auditing reports backed with consensus with their users.

    Downstream DeFis, including insurance, using the auditing intermediate information and results can be deployed to our chain. As we enable the contracts pallet in our chain, the DeFis can be developed in the form of Ink smart contracts. XCM also makes it possible to pipeline the auditing results to other chains.

    Other projects can reuse the components of FuzzLand platforms. For example, the optimistic rollups pallet can be used by Layer 2 solutions. Collaborative manual auditing projects can also use the audit pallet or our chain by replacing the rollups pallet with consensus pallets.

    Decentralized Security Marketplace is a related RFP. QRUCIAL DAO is a related project in Substrate ecosystem. QRUCIAL DAO and FuzzLand both reach consensus about the auditing result. The fundamental differences are:

    Code4rena, Immunefi, Secure3, Sherlock, etc. are similar projects in other ecosystems, but they all rely on human auditors.

    Team ๐Ÿ‘ฅโ€‹

    Team members (In order of joining time)โ€‹

    Jeff Liu (PM & Marketing)

    Chaofan Shou (Core Dev) - https://scf.so/

    Shangying Tan (Core Dev) - https://shangyit.me/

    Ben Fong (Core Dev + QA)

    Yiqi Hu (Core Dev)

    Contactโ€‹

    Team's experienceโ€‹

    Chaofan is a PhD student at UC Berkeley working on program analysis and distributed system. He has multiple research papers about fuzz testing in top conferences (e.g., CorbFuzz, Rare Path Fuzzer). He has also participated in auditing and found numerous critical vulnerabilities in well-known software and Web3 protocols. He will work on the technical portion of the project, including implementing the aforementioned Substrate pallets and the offchain oracle.

    Shangyin is a PhD student at UC Berkeley working on formal methods and fuzzing. He has previously worked at Microsoft and contributed to well-known symbolic / concolic execution tools (e.g., sai). He will be developing the algorithm for partition plan synthesis and interactive verifiers in optimistic rollups.

    Yiqi Hu graduated with a master's degree from Carnegie Mellon University. She has a strong background in program analysis and will be working on implementing the fuzz testing algorithm.

    Ben graduated from SJSU and has a strong background in full-stack development and automated QA. He will be in charge of Web App development and CI/CD pipeline.

    Jeff is the founding engineer and PM at VMware Cloud Infra org and has founded multiple startups that have been acquired by companies like Alibaba. He has co-invested in well-known Web3 companies like Deeper Network, Holokit, etc. He will be overseeing the development process.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Offchain Oracleโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of a validator or a auditor node.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains the technical details. We will also publish research papers about our algorithms and implementations.
    1.Auditor Nodes Oracle LibraryWe will implement our DPA algorithm for LLVM targets in the form of a Rust library and fine tune it for ink! contracts and Substrate pallets.
    2.Validator Nodes Oracle LibraryWe will implement the partition plan synthesis algorithm and offchain testcase validation tool in the form of a Rust library.
    3.VerifierWe will develop the verifier for testcase validation and partition plan validation in the form of a Rust library that can be compiled to WASM. We will benchmark this library to ensure that the complexity of result verification is significantly lower than that of offchain oracles generating results.
    4.Integration TestingWe will demonstrate that at least 3 auditor nodes oracle can efficiently collaborate to conduct program analysis for a ink! contract. We will also demonstrate that verifiers can be resistent to gaming by running a cluster of 2 honest validator nodes oracle and 1 malicious node.

    Milestone 2 โ€” Substrate Chainโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains the technical details and how to initiate an audit request. We will also publish research papers based on effectiveness of our solution and metrics collected from operating our platform.
    1.Substrate module: optimistic_rollupsWe will create a pallet that implements the optimistic rollups algorithm and a Rust SDK can that can interact with the pallet. We will also integrate the verifier developed in last milestone into this pallet.
    2.Substrate module: auditWe will create a pallet for onboarding auditing requests, storing testcases, and distributing rewards. The pallet can also generate auditing reports in txt format automatically.
    3.Substrate chainModule optimistic_rollups and auditing will be integrated into a Substrate node, to enable auditor nodes to submit intermediate auditing results and information. This chain will integrate contracts, treasury, council, democracy and also other essential pallets, to build a full-featured blockchain.
    4.Offchain oracle clientsAuditor and validator nodes clients will be built by integrating the libraries built in the last milestone. The two clients will be able to interact with the chain so that the full auditing workflow shown in the Project Details can be accomplished.
    4.Web AppWe will create a web app, to let users easily interact with our substrate node. Users can create auditing requests, visualize intermediate auditing information, and view final auditing report.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Personal recommendation

    - + \ No newline at end of file diff --git a/applications/Gafi.html b/applications/Gafi.html index 520cdcca6f5..68df99dd3ac 100644 --- a/applications/Gafi.html +++ b/applications/Gafi.html @@ -4,7 +4,7 @@ Gafi Network - The Network of Game Finance | Web3 Foundation Grants - + @@ -20,7 +20,7 @@ Jackson Mike Stefan

    Development Status ๐Ÿ“–โ€‹

    Gafi Node Repos: https://github.com/grindytech/gafi

    Heroes & Empires 2021 Roundup

    Whitepaper: Coming soon

    Development Roadmap ๐Ÿ”ฉโ€‹

    Gafi Network Development Roadmap session 2

    Overviewโ€‹

    Milestone 1 โ€” The Heroes & Empiresโ€‹

    At this milestone, we build modules for Player, Empires. The requirements will fall into acceptance criteria:

    NumberDeliverableSpecification
    0a.Apache 2.0
    0b.Whitepaper
    0c.DocumentationWe will comment on code, publish documents as text articles and videos to show users how Empire Pool works, how to create a player account, how to join and leave the pool
    0d.Testing GuideEvery internal and external function must have the comment followed by a unittest, and the community will be rewarded for finding bugs
    0e.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0f.ArticleThis will merge with Documentation, mostly on SubSocial, Medium, and Twitter)
    1.Substrate module: pallet_playermodule to store player information like (name, id, friends, tokens)
    2.Substrate module: pallet_option_poolProvide service options for users to join the Empire
    3.Substrate module: pallet_staking_poolProvide staking option for users to join the Empire
    4.Substrate module: proof-mappingmapping accountid with h160
    5.Weights/Benchmarkingimplement benchmarking for pallets to determine appropriate weights

    Milestone 2 โ€” Sponsored-Pool + Gafi-TX + Pallet-Cacheโ€‹

    In this milestone, the requirements will fall into acceptance criteria:

    NumberDeliverableSpecification
    0a.Apache 2.0
    0b.DocumentationModule documentation and Wiki(optional)
    0c.Testing GuideDispatable functions and public functions must have the comment followed by a unittest
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.Articlewiki.gafi.network and Medium
    1.Substrate module: pallet sponsored_poolhttps://wiki.gafi.network/learn/sponsored-pool
    2.Substrate module: pallet gafi-txhttps://wiki.gafi.network/learn/gafi-tx
    3.Substrate module: pallet-cachestore runtime data temporarily
    4.Weights/Benchmarkingimplement benchmarking for pallets to determine appropriate weights
    5.DemoDemo new features in milestone 2 with guide article

    Milestone 3 โ€” DAO + Game-Creator + Gafi Testnetโ€‹

    In this milestone, the requirements will fall into acceptance criteria:

    NumberDeliverableSpecification
    0a.Apache 2.0
    0b.DocumentationModule documentation and Wiki(optional)
    0c.Testing GuideDispatable functions and public functions must have the comment followed by a unittest
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.Articlewiki.gafi.network and Medium
    1.Substrate module: pallet game-creatorhttps://wiki.gafi.network/learn/game-creator
    2.Weights/Benchmarkingimplement benchmarking for pallets to determine appropriate weights
    3.DemoDemo new features in milestone 3 with guide article

    Future Plansโ€‹

    Fortunately, we will integrate Heroes & Empires into Gafi Network first, allowing us to devote all of our resources (20 team members including marketing, QA, and QC) to expanding, using, and testing Gafi Network.

    We will work with several top NFT Game projects and teams in Vietnam such as Axie Infinity, Imba Game, and StarPunk to deploy on Gafi Network.

    - + \ No newline at end of file diff --git a/applications/GenesisDAO.html b/applications/GenesisDAO.html index bbd4fa15f0a..f0ad99fbddd 100644 --- a/applications/GenesisDAO.html +++ b/applications/GenesisDAO.html @@ -4,7 +4,7 @@ GenesisDAO | Web3 Foundation Grants - + @@ -41,7 +41,7 @@ ecosystem will drive adoption to the network.

    Teamโ€‹

    Contactโ€‹

    Development Roadmapโ€‹

    Overviewโ€‹

    Milestone 1 Substrate Node, Dao Core, Frontend Setup and Product Initiationโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. We will add a functional test suite that covers the user flows and a manual test guide.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Parachain SetupWe will provide a docker-compose setup to spin up the entire system easily in a local environment
    2.Substrate module: pallet_dao_coreWe will create the dao core module that allows creating a dao, issue a token (intially based on pallet_assets) and manage metadata and the dao lifecycle.
    3.Frontend InfrastructureWe will setup and host a react/typescript/next.js application that will serve as dApp for our GensisDAO.
    4.Design and Product FlowWe will create UI/UX flows and designs for the dao creation process.

    Milestone 2 Proposal module, Asset fine tuning, No-Code DAO creation and proposal UX flowโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. We will add a functional test suite that covers the user flows and a manual test guide.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Substrate module: pallet_dao_assetWe will fork the pallet_asset and customize it for DAO optimization needs, most prominently with checkpoint functionality.
    2.Substrate module: pallet_dao_voteWe will create a voting module to manage the lifecycle of a proposal
    3.Frontend ImplementationWe will implement the frontend and UX flows developed in the previous milestone product section and have a no-code DAO creation experience
    4.Design and Product FlowWe will create UI/UX flows and designs for the dao proposal process.

    Milestone 3 Proposal module, Asset fine tuning, No-Code DAO creation and proposal UX flowโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. We will add a functional test suite that covers the user flows and a manual test guide.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article introducing GensisDAO, it's core concepts and vision to the public
    1.Substrate module: pallet_dao_voteWe will create a voting module to manage the lifecycle of a proposal
    2.Frontend ImplementationWe will implement the frontend and UX flows developed for the proposal and have a voting process directly on GenesisDAO (usable without xcm) and a no-code proposal integration.
    3.Product TouchesWe will create a full product experience around the dApp with landing pages, FAQ, and explainers.

    Future Plansโ€‹

    After finishing this grant, GensisDAO will be able to manage DAOs and proposal processes within it's own substrate based blockchain.

    The next two important steps will be

    Simoultanously, we will start building initial ink! infrastructure. Since we are heavily committed to shiny and elegant UX and UI, we want to heavily invest into user research and rapid feedback cycles to incorporate the needs of the community directly after the PoC that is build within this grant is live.

    The important outline for this project is to become a common good parachain, that acts as an infrastructure service for the ecosystem. Therefore extendable integrations with other important chains in the polkadot realm as well as attracting dao-specific protocols to extend the base chain functionality is part of the near term roadmap as well.

    - + \ No newline at end of file diff --git a/applications/Gluon_decentralized_hardware_crypto_wallet_services.html b/applications/Gluon_decentralized_hardware_crypto_wallet_services.html index f5883db2271..2f703c3fa3b 100644 --- a/applications/Gluon_decentralized_hardware_crypto_wallet_services.html +++ b/applications/Gluon_decentralized_hardware_crypto_wallet_services.html @@ -4,7 +4,7 @@ Gluon - Decentralized Hardware Crypto Wallet Services | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ To assist you in defining it, we created a document with examples for some grant categories here.
  • Please include the total amount of funding requested per milestone.
  • Please note that we require documentation (e.g. tutorials, API specifications, architecture details) in each milestone. This ensures that the code can be widely used by the community.
  • Please provide a test suite, comprising unit and integration tests, along with a guide on how to run these.
  • Please commit to providing a dockerfiles for the delivery of your project.
  • Please indicate the milestone duration, as well as a number of Full-Time Employees working on each milestone, and include the number of days along with their cost per day.
  • Deliverables 0a-0d are mandatory and should not be removed, unless you explicitly specify a reason within the PR's Additional Notes section (e.g. Milestone X is research-oriented and as such there is no code to test)

    • Overviewโ€‹

    Milestone 1 Example โ€” Web app and mobile app pairingโ€‹

    NumberDeliverableSpecification
    0Gluon Website and Web Portal FrameworkThe gluonwallet.com website; homepage, documents, and web app menu structure
    1Milestone1 feature list and test instructionfeatures: Users can create Gluon accounts and pair the Gluon mobile App with the web portal.
    2Test docker-composeTesters can run TEA simulator to run locally to test completed features
    3Source code on GitHubAnyone can download, build, and run local testing environments
    Task IDModule nameDescription
    0.1Add faucet pageusers can add free test tokens to accounts to start testing
    1.1User portal web pageSearch user public profiles by users' Polkadot address. All information is open public from the blockchain. Users can see pairing mobile app id. This is the feature in milestone 1
    1.2Pairing web UIThis is the web UI to start mobile app pairing
    2.0Mobile app frameworkGluon mobile app framework. We will add features one by one
    2.1Pairing mobile UI, scan QR code to startAfter the mobile app is installed, scan web pairing page to start pairing
    2.2Mobile user profile pageAfter pairing, show user profile. This is the same as the WebUI user profile content
    3.0Gluon substrate pellet: Pairing/Unpairing APIAdd mobile app pub id to existing Gluon account. Pair the mobile to this user
    3.1Gluon substrate pellet: Search APISearch user public information

    Milestone 2 - Phone upgrading and social recoveryโ€‹

    NumberDeliverableSpecification
    0Testable featuresUser upgrade new phone and transfer P1 from old phone to new phone. Use social recovery to keep assets and transfer to a new account in case of lost web and mobile app
    1Update test instructionupdate with new features
    2Source code
    3Video tutorialFull User's manual
    Task IDModule nameDescription
    1.0layer1Add social recovery API
    2.0Web PortalCreate social recovery page
    3.0Mobile appSocial recovery if initiated from phone
    3.1Mobile appScan QR code to confirm friends recovery request
    4.1Layer1Suspend old account activity during the recovering process
    4.2Gluon TeaLeafGenerate a new account to accept assets
    5.0Layer1Verify all social recovery confirmation, transfer assets to new account

    Milestone 3 - Generate DOT asset on test netโ€‹

    NumberDeliverableSpecification
    0Testable featuresUser can generate DOT addresses
    1Update test instructionupdate with new features
    2Source code
    Task IDModule nameDescription
    1.0Add a "generate DOT asset" page on web UIuser can trigger create new DOT address. Input (k,n) and other parameters
    1.1List user assets on web UIWhen successfully generated DOT address, it will show on web UI
    2.0Add a "generate DOT asset" page on mobile appusers scan the QR code on web UI. Review all tx parameters. Fingerprint unlock to commit tx to layer-1 blockchain
    2.1List user assets on mobile appWhen successfully generated DOT address, it will show mobile app
    2.2Mobile appGenerate P1
    3.0Substrate pellet: Create "generate DOT asset" taskLayer 1 verify user auth, create a task in the blockchain so that layer-2 can handle
    4.0Gluon wasm module (TeaLeaf)Select delegator and executor
    4.1Gluon TeaLeafExecutor aggregates public key from initial pinners
    4.2Gluon TeaLeafDelegator verify and response to Layer 1
    4.3Gluon TeaLeafSuspend old P2 P3 when a social recovery task in progress
    5.0Layer1Create Schnorr multisig test chain
    5.1Layer1Update user assets

    Milestone 4 - Sign DOT transaction on testnetโ€‹

    NumberDeliverableSpecification
    0Testable featuresUser send DOT transfer transaction. Gluon sign the transaction and send it to test chain
    1Update test instructionupdate with new features
    2Source code
    Task IDModule nameDescription
    1.0Gluon TeaLeafDOT SPV light node in layer2 to communicate with DOT chain
    2.0Web PortalCreate DOT transaction page
    3.0Mobile appScan, verify DOT transaction, and send to layer 1
    3.1Mobile appPartial Sign tx using P1. Send the P1 signature to DOT light node
    4.0Gluon TeaLeafExecutor find pinners and organize them to multisign tx individually
    4.1Gluon TeaLeafExecutor verify and aggregates signatures. Send the P2 signatures to test net
    5.0Layer 1Settle payment distribution

    Milestone 5 - Migrate to real hardware and test on Polkadotโ€‹

    NumberDeliverableSpecification
    0Testable featuresAll logic runs on Polkadot mainnet
    1Update test instructionupdate with new features
    2Source code
    Task IDModule nameDescription
    1.0All modulesMigrate to AWS Nitro enclave and Integration test
    2.0Web PortalUser's manual, instruction
    3.0DocumentsIntegration API for 3rd party

    Future Plansโ€‹

    Gluon will be a full-featured demo application for the TEA project once it is ready. So far, there are a few limitations that we are working on.

    Most items in this to-do list are part of the TEA Project plan. When TEA is ready, most of the features will be available too.

    Additional Information โž•โ€‹

    We started the TEA project in 2019. It has been under the radar until recently when it was released to the public. We believe the TEA project could grow large and become the backend service platform for a new type of dApps. These dApps can go beyond the limit of traditional blockchain technologies. Gluon is just one of the many possible demo apps. Once our honor gets granted, we will start looking for investors and hire a CEO and more developers to join us. We hope to maintain a long term and close relationship with the Polkadot community.

    - + \ No newline at end of file diff --git a/applications/Grant_management_webapp.html b/applications/Grant_management_webapp.html index 30e09d2015c..7a77a6645db 100644 --- a/applications/Grant_management_webapp.html +++ b/applications/Grant_management_webapp.html @@ -4,14 +4,14 @@ Grant Management Webapp | Web3 Foundation Grants - +
    Skip to main content

    Grant Management Webapp

    • Team Name: Antier Solutions Pvt. Ltd.
    • Payment Address: Fiat
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    This application is in response to the open RFP: https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/grant_management_webapp.md

    Overviewโ€‹

    The Grant Management Web Application is a comprehensive software solution designed to streamline and enhance the process of managing grants. It aims to provide w3f and other grant-making institutions with a centralized platform to efficiently handle grant applications, evaluation, tracking, reporting, and overall administration. By reducing the number of clicks, the web application will enable better navigation of data, better UI, greater ease and effectiveness in the grant management process.

    Project Detailsโ€‹

    Key Features:โ€‹

    • Organised relevant data.
    • Github API integration to carry out relevant actions.

    Technical Architecture

    Grant Management Webapp(draft 2)-Technical Architecture (1)

    • Mockups/designs of any UI components

    Core Components:โ€‹

    Front-End:โ€‹

    1. UI:

    • Project Dashboard: image_2023_05_25T13_03_13_705Z

    • Project Details: image_2023_05_25T13_03_13_706Z

    • Team Dashbard: image_2023_05_25T13_03_13_710Z

    • Team Details (applications): image_2023_05_25T13_03_13_710Z

    • Team Details (projects): image_2023_05_25T13_03_13_709Z

    • Application Dashboard: image_2023_05_25T13_03_13_703Z (1)

    The discussions, commit, and file changes pages will be designed same as they are shown on a PR in github. Approvals, reviews and rejections will be handeled in the discussions tab

    • Application Details: image_2023_05_25T13_03_13_703Z (2)

    • Delivery Dashboard: image_2023_05_25T13_03_13_704Z (2)

    • Delivery Details: image_2023_05_25T13_03_13_704Z (1)

    1. Back-End API Integrations

    Back-End:โ€‹

    1. Front-End API Integrations
    2. Github API Integrations
    3. Database API Integration
    4. Cron Job
    5. Data Extractor - Service that extracts data from the MD files for storage
    6. Web Hook Handler - Service that will listen to events and then handle the respective functionality

    Databaseโ€‹

    Grant Management Webapp(draft 2)-DB final draft (1)

    Things not included in the project:โ€‹

    There is no wallet support/oracle for treasury pallet in this application but these can be integrated upon further discussion.

    Technology Stackโ€‹

    • Front-end: HTML5, CSS3, JavaScript (React)
    • Back-end: Node.js (Express.js)
    • Database: MongoDB
    • Authentication and Authorization: Github (github apps)
    • Cloud Hosting: Github Marketplace

    Ecosystem Fitโ€‹

    The W3F grants program is growing by the day. It is quite a hassle for the grants committee to browse the Grant Program Repositories. This application aims to achieve two things: 1. Consolidate releveant information from the Grant Program Repos; 2. Provide Github Actions functionality to deal with the process of the Grant Program within the app itself.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Kulwinder Singh (Backend)
    • Shaivik Semwal (Frontend)
    • Aanchal Kathuria (Tester)

    Contactโ€‹

    • Registered Address: E-221, Phase 8B, Industrial Area, Sector 74, Sahibzada Ajit Singh Nagar, Punjab 160059
    • Registered Legal Entity: Antier Solutions Pvt. Ltd.

    Team's experienceโ€‹

    • Antier is a thought-to-finish partner for customers in their blockchain journey. We advise and consult our clients on blockchain technologies and tailor solutions utilising our powerful blockchain ecosystem. We help customers experiment and deploy proof-of-concepts on blockchain technologies and incrementally expand to scale to production releases. Our thought leaders regularly educate customers, partners, CXOs on the power of blockchain for today and tomorrow.
    • Workdone by Antier in Substrate ecosystem
    1. Antier worked on the validator and nominator apps for substrate based blockchains to offer a unique and better user experience .
    2. We have also worked on creating an optimised and homogenised design focused on improving the navigation, information architecture, user flow tasks, content design and graphic elements for a seamless and easy browsing experience.
    3. We have customised the default reward mechanism in the staking pallet of the substrate chain by integrating the sustainability and reliability score(which is calculated by ESG scores and Uptime of the validators repectively) of the validators in the current reward system.
    4. We were able to run EVM and WASM machines natively in the substrate chain so that the chain will be able to support both EVM(Metamask, Remix, Web3.js, etc) and WASM(WebAssembly target, INK framework, etc) tooling.
    5. We were able to replicate the whole polkadot ecosystem(Relay chain, Parachains, XCM), Where parachains are use case specific chains and communicate through XCM protocol with each other.

    • Our team has been proactively participating in the Substrate Stack exchange and we ask/answer question related to ink!, Substrate, parachain. We rank in the top 6% people in the Substrate Stack Exchange.

    • Profiles of our team:

    1. https://substrate.stackexchange.com/users/2372/arunjot-singh
    2. https://substrate.stackexchange.com/users/2281/amit-kumar-yadav
    3. https://substrate.stackexchange.com/users/354/shubham-gupta

    • Our organisation is the technical partner for 5ire chain: https://5ire.org/

    • Our team has worked on multiple IDE which include an EVM compatible IDE for solidity, IDE for WASM contracts for ink! based smart contracts. The EVM IDE is live and the link is : https://ide.5ire.network/

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    A minimal POC has been made wherein the basic github actions were successfully tested. Things tested in POC:

    1. Created issue in a repo
    2. Fetch list of issues in a repo.
    3. how to use responses.
    4. Get PR list to a repo
    5. Get PR by number
    6. Merge a PR
    7. Get comments on a PR
    8. Update a comment on PR
    9. Add comment on PR

    Github provides REST API for a lot of github actions. The link to the API docs is here

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 8 weeks
    • Full-Time Equivalent (FTE): 3 FTE
    • Total Costs: 10,000 USD

    Milestone 1 โ€” Teams and Projectsโ€‹

    • Estimated duration: 8 weeks
    • FTE: 3
    • Costs: 10000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can browse through the application and perform github actions
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.FrontendWe will provide dashboard and details pages for Projects and Teams with all details
    2.BackendDatabase integrations and data extractor will be implemented. i.e data from the md files on github will be processed and saved to the database using API
    3.BackendGithub API integrations and web hooks will be implemented so that our application can listen to events and make necessary changes in the db
    4.Data BaseDB schema implementation

    Future Plansโ€‹

    We plan to deliver the following after receiving the Grants Committee's approval :

    Oracle for treasury pallet integration is being researched meanwhile and also looking for decentrallised alternative for github. Upon further discussions with the grants committee we shall go ahead with this

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Grants Portal

    - + \ No newline at end of file diff --git a/applications/GreenLemon.html b/applications/GreenLemon.html index 5045bbe891b..7979d97d124 100644 --- a/applications/GreenLemon.html +++ b/applications/GreenLemon.html @@ -4,13 +4,13 @@ Green Lemon | Web3 Foundation Grants - +
    Skip to main content

    Green Lemon

    • Team Name: Green Lemon
    • Payment Address: 0xf4f463B9A0ADa68536423121e7Bf9E559ce54fAf(Ethereum ERC20 USDT)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Proposal: Dual-Key Stealth Address Protocol

    Milestone Delivery: Dual-Key Stealth Address Protocol

    Overviewโ€‹

    Many of todayโ€™s blockchains, including Bitcoin and Ethereum, are open and public ledgers in the sense that there are no restrictions on participation and all transaction details are visible on the blockchain. In a public ledger, the transaction entities are only identified by their blockchain addresses, which are derived from the corresponding public keys. Public ledgers are generally considered to be โ€œpseudo-anonymousโ€, which means that an address is linked to one person, but that person is unknown to the public. However, by analyzing the transaction graph and combining it with other information, it is possible to reveal the true real-world identity behind a blockchain address, as shown by recent research.

    The Green Lemon protocol is an anonymous NFT solution for the Polkadot ecosystem based on zero-knowledge proof and dual-key stealth address protocol: users deposit DOT to an anonymous NFT contract and then anonymously send mint, transfer, and other ERC721 functions to that contract via relayer.

    Project Detailsโ€‹

    The protocol implements the function of initiating anonymous transactions through zero-knowledge proofs and the function of hiding NFT owners through DKSAP.

    Currently, a large number of anonymous transaction projects use zero-knowledge proofs, such as Monero and ZCash based on the UXTO model, and Zether and Tornado based on the account model.

    Zether comes to our attention with its unique implementation, which uses the ฮฃ-Bullets protocol, does not require the generation of public parameters for the initiation ceremony, and uses the Elgamal encryption algorithm for homomorphic encryption and decryption of account balance, which are excellent features. But the Gas for anonymous transfers involving 64 accounts verified amounted to 36,152,558 on Ethereum virtual machine.

    Meanwhile, Tornado, based on zk-SNARK, performed well in terms of Gas, with a Gas consumption of 1,088,354 for deposits and 301,233 for withdrawals. After comparison, we decided to develop a zero-knowledge proof module based on zk-SNARK.

    DKSAP is a new privacy transaction protocol invented by rynomster/sdcoin in 2014. Since its announcement, it has landed in numerous blockchain projects (Monero, Samourai Wallet, TokenPay, etc.). It is characterized by the fact that the account needs to generate two sets of public and private key pairs, "scan key pair", and "spend key pair", the recipient of each transaction is encrypted and cannot be associated with a particular blockchain account.

    The protocol contains the following functions:

    • Deposit: The user generates a random note and deposits a coin to the NFT anonymous contract, so that can pay the relayer fees for anonymous transactions.

    • Withdrawal: The user will get back the DOT previously deposited, and nullifier the corresponding note.

    • Registration: The user registers the Scan public key and Spend public key to the NFT contract, and if the relayer sends the transaction to the chain, the user needs to pay the fee for the relayer.

    • Mint: The user generates the encrypted public key address ePub1(encrypted pub key) based on his scan pub and anonymously mint NFT through the relayer, the owner of this NFT is ePub1, and the user needs to pay the gas fee to the relayer.

    • Transfer: The user generates the encrypted public key address ePub2 based on the scan pub of the recipient and uses the private key signature corresponding to ePub1 to anonymously transfer the NFT, and the owner of the NFT is ePub2, and the user needs to pay a fee to the relayer.

    • Burn: The user pays the fee to relayer to burn NFT.

    • Other functions supported by ERC721, including Approval, ApprovalForAll, clear_approval, and set_approval_for_all.

    Ecosystem Fitโ€‹

    NFT sales reached $17.7 billion in 2021, up from $82.5 million in 2020 โ€” a jump of more than 200 times. Total NFT profits when reselling or buying also skyrocketed from $12 million in 2020 to $5.4 billion in 2021.

    Sotheby's - a renowned auction house with a history of nearly 300 years - generated $7.3 billion in sales in 2021, of which 10% was in private transactions.

    This gives us confidence that anonymous trading, the act of buying and selling without revealing the identity of the trader, is just as strongly demanded in the NFT ecosystem.

    As the first anonymous NFT application of web3 Ecology, we believe Green Lemon will have a positive impact on Polkadot. Users of NFT who value their privacy greatly will find it attractive.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Yahuang Wu

    • Github address
    • Educated in Xiamen University, MEM
    • 7 years of internet R&D experience, participated in the development of several apps with millions of Daily Active Users (Qunar, Snowball, Meiyou)
    • Head of the technical team of EOS genesis block producer
    • Author of 40 EOS technical articles list of technical articles
    • Selected into the EOS Open Source Community Acknowledgments List list of selected lists
    • EOS Hongkong Hackathon tech mentor
    • Contributed code to several repositories in the 2020 GitHub Archive Program
    • 10 blockchain technology patents Patent List

    Rick

    • Educated in Xiamen University, Computer Science & MBA
    • Head of the technical team of Meiyou APP (one of the most famous female health APP in Aisa)
    • Head of the technical team of EOS wallet (one of the most famous EOS wallets in Asia)

    Contactโ€‹

    • Registered Address:
    • Registered Legal Entity:

    Team's experienceโ€‹

    We have 10 years of experience in Internet research and development, focusing on the blockchain industry since 2018. We are deep participants in several technical communities, hackathon winners, and node service providers for EOS and PlatON.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Development Status ๐Ÿ“–โ€‹

    Milestone Delivery: Dual-Key Stealth Address Protocol

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 12 weeks
    • Full-Time Equivalent (FTE): 2
    • Total Costs: 30,000 USD

    Milestone 1 โ€” Implement anonymous NFT based on ERC721โ€‹

    • Estimated duration: 3 weeks
    • FTE: 2
    • Costs: 8,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish article & demo video that explains How is anonymous NFT contract hidden owner works based on dual-key stealth address protocol.
    1.(ink!)Smart contracts: Anonymous NFTMilestone Delivery: Dual-Key Stealth Address Protocol only implements mint, transfer, and burn. Based on the current version, we will continue to develop other ERC721 protocol methods and related test cases, such as approve, approve_for, get_approved, base_uri, and token_uri. Additionally, we need to add an extra param into the message before hashing, which is the token nonce. Account nonce is unfit due to each token owner being a unique and one-time encrypted address. When an NFT is operated once, its corresponding token nonce is automatically added by 1. We think that token nonce can prevent replay attacks for signatures already sent to the blockchain.

    Milestone 2 โ€” Implement anonymous transactionโ€‹

    • Estimated Duration: 9 weeks
    • FTE: 2
    • Costs: 22,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish article & demo video that explain How is anonymous NFT solution works based on zero-knowledge proof.
    1.(ink!)Smart contracts: Anonymous NFTDevelopment and testing of the core functions of the Anonymous NFT smart contract, including deposit/withdraw DOT from the contract, sending the transaction to the NFT contract through the relayer, and paying the transaction fee to the relayer on-chain. As mentioned above, anonymous transactions are based on zero-knowledge proof.
    2.(Node.js)Relayer serviceDevelopment and testing of the relayer service. As mentioned above, All user transactions are sent by the relayer service, and users need to transfer token to the relayer based on zero-knowledge proof.

    Future Plansโ€‹

    Please include here

    • Develop PC website and Google chrome extension wallet based on Green Lemon Protocol, lower the threshold for blockchain users
    • Add Merkle tree to store notes on-chain, so users can verify that transactions are mined by the blockchain network.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    Proposal: Dual-Key Stealth Address Protocol

    - + \ No newline at end of file diff --git a/applications/High_availability_validator_setup.html b/applications/High_availability_validator_setup.html index 7680d459442..8027e59e327 100644 --- a/applications/High_availability_validator_setup.html +++ b/applications/High_availability_validator_setup.html @@ -4,7 +4,7 @@ High-availability validator setup | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ This is a follow-up to the previous version of the grant, that was up for discussion with the Parity development team.

    Overviewโ€‹

    Currently, the recommended setup is to have one active node per validator. The main advantage of this approach is that it removes the danger of equivocation, thus preventing slashing. The key drawback is the lack of a ready backup machine to takeover the responsibility of producing blocks, voting on finality etc. in case the primary one fails.

    The drawback can be somewhat remedied by having a backup node in sync, but without access to the session keys necessary for authoring blocks. The process of replacing the keys, however, is manual. Furthermore, the session keys cannot be replaced mid-session and this introduces a time delay for when the validator is active again.

    Project Detailsโ€‹

    Rather than relying on one validator node to perform the work, what if we had multiple nodes equally capable of taking part in consensus, yet still avoiding the risk of equivocation?

    Since all our validator nodes are trusted and we don't worry about censorship resistance, we can leverage a leader-follower model to ensure high availibility. Raft is a good candidate - it offers a simple consensus mechanism, fault-tolerance and performance. It ensures only one leader is ever in charge of interacting with the network, while the followers simply receive the state updates and automatically replace the leader in case of a failure.

    Following the feedback from the Parity developers team our solution is not tightly coupled with Substrate node as it adds too much complexity in the node. It should be implemented in a way that makes this optional and loosely coupled with the node.

    Ecosystem Fitโ€‹

    The goal is to present a solution that would update the current recommended setup of one active node per validator and allow to use multiple nodes.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Bright Inventions is a team of over 70 full-time onsite developers, project managers & UX/UI designers - experts in mobile and web applications, systems integration, IOT devices and Blockchain platforms.

    We believe that building a software product is about people working together in a collective way. By offering complex support โ€“ mobile and web development as well as IT consultancy we try to eliminate roadblocks towards engaging clients as partners at every step of the process.

    We support startups, digital agencies as well as medium to big businesses. We cooperate with startups, accelerators and incubators. Whatever the client profile is, we always aim to establish a satisfying partnership for both sides. Since 2012 we have built software for more than 40 businesses worldwide.

    The team:

    Previous grants that the team members were involved in:

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    This grant proposal is a follow-up to a discussion that began in autumn 2022. Since then we managed to receive some required feedback from Parity development team and we continued to apply their suggestions in the span of these few months. It allowed us to already develop most of the original scope.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    The development of the specified goal will be broken into 3 milestones, lasting 4 weeks (M1), 3 weeks (M2) and 2 weeks (M3).

    Definition of Done for each deliverable:

    At the end of each milestone:

    Deliverables ๐Ÿ”ฉโ€‹

    Milestone 1 - Block authoring, finalization & liveness PoCโ€‹

    The goal of the first milestone will be adding a switch to the substrate codebase, which will conditionally allow block production, voting or sending I'm online message. We will achieve this by introducing a PermissionResolver trait. Only for the purpose of this milestone there are going to be two trivial implantations of this trait. First configuration will grant the validator permissions and the second one will not. At this stage we only want to verify if hardcoded conditional logic works well with the nodes with the same auth key but different configurations (permission granted/denied). For the testing purpose we will provide an additional option to the CLI, to run a validator with one of the pointed configurations.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide inline documentation.
    0c.Testing and Testing GuideWe will provide unit tests and the guidelines for running and testing it the scope.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Update substrateModify the substrate code to conditionally submit blocks/votes for finalised blocks (GRANDPA)/I'm online messages.
    2.Update substrate client - cliModify the substrate code to conditionally grant or permit permissions. There will be option to run node in permission granted or permission denied mode). It will be useful to prove that permissioning works by running two nodes with same auth keys but different modes (permission granted/denied)
    3.Integration testA dockerised setup that allows to run network in setup described above.

    Milestone 2 - External service for permission grantingโ€‹

    The second milestone introduces a microservice which will test dynamic switching of the permission granting, during the validator's work. We will be able to test permission granting triggered whenever the block is produced, the vote is made on the finalized block (GRANDPA) and a message (I'm online) is sent for communicating liveness. Only the leader validator will be granted to run those actions. At worst, the author may miss a slot.

    The service should contain only basic logic (e.g. return true for node that asked first and false for following ones).

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide inline documentation.
    0c.Testing and Testing GuideWe will provide unit tests and the guidelines for running and testing it the scope.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Basic serviceCreate a microservice that accepts connections from the node.
    2.Getting permission from microserviceSet up a custom node repository and write the PermissionResolver trait implementation for getting permission from the microservice.
    3.Allow as optionalThe choice of using an outside decision making agent for block submission should be configurable in the cli.
    4.Clean up substrate codeRemove deprecated cli options.
    5.Integration testA dockerized setup that allows to run custom node networks and a microservice in order to show that the created solution works.

    Milestone 3 - Raft based current leader selectionโ€‹

    Replace the dummy microservice as an infrastructure component with a TiKV cluster used for leader selection. Each node should try to get authorship permission based on the KV (Key-value) state. Replace the current microservice client with a TiKV client and add corresponding logic.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide inline documentation.
    0c.Testing and Testing GuideWe will provide unit tests and the guidelines for running and testing it the scope.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Run the necessary Raft servicesSet up a local dev infrastructure to run TiKV components in order to provide a distributed KV store.
    2.Integrate a Raft client into the nodeReplace the previous logic with a TiKV based one and modify configs to allow the TiKV client to connect to Placement Drivers. Placement Drivers (PD) is one of the components which stores metadata for the entire TiKV cluster. It is responsible for sending commands to the TiKV nodes. The minimum setup for PD is to manage three TiKV nodes.
    3.Integration testA dockerised setup that allows to test the Raft consensus mechanism.

    Leader selection processโ€‹

    Similar for rounds and sessions.

    - + \ No newline at end of file diff --git a/applications/Hyperdot.html b/applications/Hyperdot.html index 3bcfe0b102e..735f1d321c3 100644 --- a/applications/Hyperdot.html +++ b/applications/Hyperdot.html @@ -4,13 +4,13 @@ Hyperdot - Powerful data analysis and creation platform โ€” RFP | Web3 Foundation Grants - +
    Skip to main content

    Hyperdot - Powerful data analysis and creation platform โ€” RFP

    Project Overview ๐Ÿ“„โ€‹

    This is a response for the Analytics Website/Data Platform RFP.

    Overviewโ€‹

    Crypto data is growing rapidly, and large data companies are not consider integrating them into their systems. However, multi-chain crypto data is of significant value to users. The hyperdot is a on-chain data platform for querying, analyzing, and creations, written in Rust. It provides users with powerful capabilities for data querying, analysis, and creations.

    With hyperdot, users can easily query and analyze crypto data from Polkadot, Kusama, and other parallel chains built on the Substrate Runtime. Hyperdot separates the indexing and computation of on-chain crypto data from the off-chain data storage, analysis, and querying, addressing scalability issues present in many data analysis platforms. Hyperdot offers multiple data engines to adapt to different scenarios.

    Hyperdot provides a dashboard similar to Dune Analytics and Chainbase, offering powerful data analysis and visualization features currently. Users can create queries using different data engines and generate visual data dashboards. Importantly, Hyperdot is dedicated to building a data analysis creations community where data engineers and data scientists can create and share their work based on Hyperdot's data, fostering collaboration and knowledge exchange.

    Project Detailsโ€‹

    The System Overviewโ€‹

    The Hyperdot project consists of two main system: hyperdot-node and hyperdot-frontend-end.

    hyperdot-Node will ideally integrate the data source of substrate-etl to provide an crypto-data query api on the chain

    hyperdot-frontend-end is built using tailwind css and next.js, creating a modern web dashboard. While it works similar to Dune Analytics, it has its own unique features. Hyperdot-Frontend connects to Hyperdot-Node to provide users with user-friendly chain data analysis capabilities. Moreover, it aims to establish a data analysis community where data engineers and data scientists can create and share insights based on the data provided by Hyperdot.

    The System Architecutreโ€‹

    Hyperdot will consider the success of the existing work of the integration community, for example, on the data source, we will choose to integrate substrate-etl as the data of hyperdot-node-front engine, at the same time, in order to maintain good scalability, hyperdot-node will also retain other options.

    Hyperdot System Architecture

    The system is mainly divided into three parts

    1. substrate-etl provides the relevant data warehouse, other ecosystems allow us to customize the index, and we will integrate their data as the data source of the system on demand
    2. hyperdot-Node will integrate data from common bins provided by substrate etl and provide apis for hyperdot-front-end
    3. hyperdot-fronted-end provides a user-friendly front-end interface for data analysis, exploration, and collaborative data analysis creation. It is built using modern front-end technologies. The interaction between hyperdot-fronted-end and hyperdot primarily utilizes HTTP, while GraphQL is used for handling complex data queries. WebSockets are employed for subscription-based data updates.

    The Live Demoโ€‹

    We have deployed a small live demo that you can play directly with.

    Querying westend testnet block data

    query1

    Querying the westend block data uses the index

    query2

    Ecosystem Fitโ€‹

    hyperdot will integrate data from Polkadot, Kusama, and Substrate networks by utilizing the infrastructure of substrate, substrate-etl, and other Parity technology communities. It will support multi-chain and multi-runtime environments. hyperdot will provide a dashboard that enables users to easily query on-chain crypto data using SQL language. Additionally, it will establish a community for data querying, analysis, creation, and sharing, allowing users to exchange insights.

    hyperdot is a data querying, analysis, creation, and sharing platform targeting a wide range of users, including data analysts, data scientists, project managers, and anyone interested in analyzing on-chain crypto data using hyperdot.

    Currently, we have not found similar projects in the Substrate/Polkadot/Kusama ecosystems. Moreover, data analysis systems that support multi-chain, multi-data engine integration with good scalability are rare in other ecosystems as well. We firmly believe that hyperdot will bring significant value to the community.

    QAโ€‹

    Q: Come up with a value proposition to make it viable: "how would the project stay sustainable and capture value?" to sustain operating costs

    A:

    • Sustainability: First, technically, we have a team with a good web3 background, so we don't get stuck with technical issues. Second, we were able to reduce our storage costs by relying on other projects' data warehouses, which allowed our projects to grow healthier.

    • Capture value: We believe that the ecosystem needs a "dune for substrate, but better" project that enables more powerful analytics for all users.

    Q: Interview a few parachains/ecosystem teams & researchers on the top 3 "dashboards" or interactive data use cases they'd like to see and include how you would solve that as part of the analysis and data platform RFP.

    A: We can't give a precise answer to this question, but we did a deep dive last week into existing data analytics projects in the ecosystem and, similarly, they always present data that users expect on top3. hyperdot is a little different,

    1. hyperdot allows anyone to create analytics dashboards using data provided by the substrate-etl repository, so the top3 ranking is not actually controlled by hyperdot
    2. However, we provide a favorites ranking for each dashboard, which can accurately show which data analytics dashboards are widely used by the community based on favorites

    Teamโ€‹

    Team membersโ€‹

    • Ryan Xiao

    • Ming Dai

    • Tania

    Contactโ€‹

    • Registered Address: N/A
    • Registered Legal Entity: N/A

    Team's experienceโ€‹

    Ryan Xiao is a contributor to the Tendermint-rs and Postgres communities and. With nearly 10 years of software development experience, Ryan Xiao is an expert in Rust and C++ programming languages. He specializes in decentralized systems, large-scale distributed data systems, and cloud computing system development. Ryan Xiao has been involved in the development of the Tendermint-rs community and decentralized data systems based on Tendermint-rs and Postgres FDW. He has also contributed to multiple research-oriented databases at CMU, showcasing a deep understanding of databases. Ryan Xiao has conducted extensive research on Web3 consensus protocols and the Substrate framework, published several articles on Substrate development, and organized related presentations. He has been dedicated to helping more technologists become familiar with and understand Web3 development through Substrate.

    Ming Dai has been working in decentralized exchanges for the past few years, focusing on data security. He has a strong passion for Rust and Substrate and has conducted extensive research on Substrate pallet and runtime development, backed by rich practical experience. Ming Dai has studied the design and implementation of Dune and has implemented a data analysis system for the company based on Ethereum's chain. Additionally, Ming Dai is familiar with smart contracts, dApps, frontend design, and developm

    Tania has been involved in security audits and operational work at exchanges. She is also an excellent UI designer, dApp creator, and technical document writer. Tania has a deep love for Substrate and ink! and has been exploring the use of ink! to refactor previous smart contracts.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Development Status ๐Ÿ“–โ€‹

    In 2022, Ryan started exploring Substrate and The Graph, and at that time, he attempted to add support for Substrate data on The Graph for private chains. This effort lasted for approximately six months.

    Starting from March of this year, Ryan and Ming were inspired by Dune and Chainbase, and they thoroughly studied the architecture design and implementation of these projects. Subsequently, we discussed the feasibility of building a multi-chain, multi-runtime, multi-data engine, scalable platform for web3 data analysis, creation, and a community of web3 data enthusiasts.

    We began designing and implementing Hyperdot, with Tania providing us with a simple data playground. Currently, we have achieved an MVP (Minimum Viable Product) validation of the core components, and they are functioning well. It is estimated that it will take another three months to make them work properly. Therefore, now is the time to apply for a W3F grant and introduce the work we have done to the entire Substrate community.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 3 FTEs
    • Total Costs: 19,000 USD

    Milestone 1 โ€” Completion of all components and core functionalities of hyperdot-nodeโ€‹

    • Estimated duration: 5 weeks
    • FTE: 3
    • Costs: 9,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains [...] (what was done/achieved as part of the grant). (Content, language and medium should reflect your target audience described above.)
    1.SQL Query APIWe will use the bigquery client to integrate substrate-etl from the data sources provided by substrate-etl and creating a data query api using the bigquery client and substrate-etl, including

    1. We will integrate the table schema provided by substrate etl to create interfaces for different query capabilities we provide, such as chain information, transaction information, etc.
    2. Show the table-scheme of the associated chain
    3. Run and save sql queries
    2.Dashboard EditorThe apis needed to implement the dashboard, including
    1. Edit the visualization dashboard page by loading sql
    2. Save the dashboard you've edited
    3.DiscoveryWe will implement the apis required by the discovery feature for data analytics dashboards and data query sharing, including
    1. The dashboards list api
    2. dashboards item Detail api. Each dashboard item is clicked to show the user's previously edited dashboard
    3. queries List api
    4. queries item details api. After clicking each query item, it displays the sql data tables and other information that the user has saved and run before

    Milestone 2 โ€” Completion of all components and core functionalities of hyperdot-fronted-endโ€‹

    • Estimated duration: 7 weeks
    • FTE: 3
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains [...] (what was done/achieved as part of the grant). (Content, language and medium should reflect your target audience described above.)
    1.Page LayoutWe will provide the basic layout, which will
    1. A basic header navigation and routing
    2. Dashboard, Queries
    2.Data Creation - New Query PageWe will provide data analysis querying and creation on the Data Creation Page, and an interactive data analysis querying experience on the New Query Page:

    1. New Query Page: This page will display the supported data engines and the associated tables for each engine.
    2. Playground Editor: Users will be able to input SQL queries in an interactive manner using the Playground Editor.
    3. Dynamic Table: The results of data analysis will be presented using a dynamic table.
    4. Visual Chat: We will incorporate a visual chat feature to enhance the objectivity of the data.
    5. Save and tag created data queries: Users will have the ability to save their created data queries and add tags to them.
    3.Data Creation - New DashboardNew Dashboard allows users to create shareable dashboards that it will
    1. Create a Dashboard form
    2. Visualize the Query created by the user in the New Query Page
    4.Discovery - QueriesThe Discovery Queries section will showcase data analysis queries created by users in the community. Each creation can be clicked to access the details, where the Playground Editor will explain the SQL syntax and display relevant visualized data tables.
    5.Discovery - DashboardsThe Discovery Dashboards section will show shared visual dashboards created by users in the community. You can click on each creation to access the details, and once inside you can load a dynamic dashboard based on your query.

    Future Plansโ€‹

    After completing hyperdot and releasing the first version, we will integrate more data engines, including time series data engines (influxdb), OLAP analytics engines (Clickhouse), and distributed query engines (Spark).

    We will consider indexing more types of data, not just raw chain data, but also decoded dex and not data, as well as additional extrinsic data. Additionally, we plan to establish a mechanism where developers can propose data models they want to index through GitHub or the community. Once adopted, these data models will be incorporated into our data engines.

    We will also consider integrating ChatGPT to provide natural language querying capabilities (we are think it's something that's going to get the whole community excited about). Specifically, users will no longer need to be proficient in SQL and can run queries using natural language prompts.

    We will introduce a P2P structure for storage nodes to make them decentralized. We also plan to optimize and upgrade the UI based on user feedback, such as adding more dashboards and improving the data creation process. Additionally, we will explore integrating Grafana for better data visualization dashboards.

    Lastly, we expect to collaborate with foundations to promote our platform and showcase its value to more users. We will also engage with the community through platforms such as Twitter, YouTube, Medium, and others to introduce hyperdot.

    - + \ No newline at end of file diff --git a/applications/ISO-8583-implementation.html b/applications/ISO-8583-implementation.html index 650368611ed..fc28fca7ea3 100644 --- a/applications/ISO-8583-implementation.html +++ b/applications/ISO-8583-implementation.html @@ -4,13 +4,13 @@ ISO-8583 implementation | Web3 Foundation Grants - +
    Skip to main content

    ISO-8583 implementation

    • Team Name: Dastanbek Samatov
    • Payment Address: 0xc42D0562BB4e53f5e9D888df35e1B91eA0f19cC3 (USDC)
    • Level: 2

    This application is in response to the ISO-8583 RFP.

    Overviewโ€‹

    ISO-8583 PoC implementation for Substrate.

    In this project I aim to implement the proof of concept for the ISO-8583 standard in Substrate. The implementation will be based on the extensive research done by Adit Patel in the following repository.

    I've already worked on the similar project for EBICS standard. I can leverage the knowledge gained from that project and research done by Adit Patel to implement the ISO-8583 standard in Substrate.

    Project Detailsโ€‹

    To fully imitate the ISO-8583 standard, I have divided this PoC project into two parts: infrastracture and blockchain. Infrastracture components are responsible for imitating the flow of the ISO-8583 message from the merchant to the PCIDSS compliant gateway. Blockchain components are responsible for further processing of the ISO-8583 message and settling the transactions/messages on the Substrate chain.

    Below is the implementation plan in a deeper technical detail from Adit Patel's research:

    Implementation plan

    Infrastractureโ€‹

    For this part, the implementation will consist of the following components:

    • Merchant: A hybrid web application, i.e can be used to either make the payment directly on Substrate chain, guaranteeing instant settlement, or via debit/credit card. It will consist of a mock marketplace and main work will be done on the payment checkout window. Depending on the payment method, the application will then send the payment request to the corresponding payment processor.
    • Payment processor (Stripe, Visa, Mastercard): The payment processor will be imitated by a web server that will accept the payment request from the merchant, compose the ISO-8583 message and send it to the gateway. It will maintain the offchain ledger (database).
    • PCIDSS Compliant Gateway (Oracle Company): The gateway is the first part of the centralized oracle. It will be mocked by a message broker that will process the incoming ISO-8583 messages from the traditional network and pools them for the offchain worker to query. It is also responsible for maintaining an up-to-date record of the offchain and on-chain ledger, validating messages, keeping track of chain events and composing new messages in case there is a mismatch between the two ledgers.

    For the above componenets, there are already some open source projects that can be used. Namely:

    • ISO-8583 implementation in Javascript: I will use this library in mock web server and the merchant application. Opted for this library since it seems to be well maintained and documented (the Rust version has the last commit from 2019).
    • RabbitMQ: I will use RabbitMQ as a message broker for the gateway. It is a well known and widely used message broker. It also has a Rust client

    And for the merchant app, below are the mockups of payment checkout window:

    Card payment

    Payment on-chain

    Successfull checkout

    Blockchainโ€‹

    On the blockchain side, there were three key components that were proposed in the research:

    • A centralized oracle
    • ERC-20R smart contract
    • Substrate chain

    However, from my previous experience building the EBICS PoC and generally as a more experienced Substrate developer, I believe the first two components can be simplified to:

    • An offchain worker (OCW): It will act as a second part of the oracle, i.e it will query for the ISO-8583 messages from the gateway and will send them to the Substrate chain. The only way for the chain to receive the ISO-8583 messages will be through the OCW. This will ensure that the chain is not spammed with unnecessary messages and will also allow us to hide sensitive information like account numbers and authorization codes.
    • Pallet: pallets are more flexible and a lot easier to implement and maintain than smart contracts. It will implement the ERC-20R standard and will settle the transactions on the Substrate chain.

    Challengesโ€‹

    One of the main challenges for this project is the reversability of transactions in the ISO-8583 standard. The standard allows for the reversal of transactions in case of a dispute. This is not a problem for the traditional payment networks since they are centralized and can easily reverse the transaction. Although, ERC20-R standard has a revert function, it becomes complicated when we try to get back the funds that are already spent. I will have to do more research on this topic and will try to come up with a solution.

    Inspirationsโ€‹

    EBICS PoC implementation offers some insights and inspiration, however, the ISO-8583 standard is a lot more complex and will require a lot more robust and complex infrastructure. Similarly, on the blockchain side, the reversability of transactions will pose a great challenge. Therefore, large parts of the blockchain components will need to be rewritten from scratch or significantly refactored in best case.

    Ecosystem Fitโ€‹

    A quote from Adit Patel here:

    Supporting international standards would smooth the connection between crypto and traditional financial institutions and is a go to market strategy for several competing projects. While those efforts are focused on the newer ISO-20022, not ISO-8583, there is significant value in being the first blockchain to support traditional banking infrastructure and dislodge incumbent networks such as SWIFT or Visa/Mastercard.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Dastanbek Samatov

    Contactโ€‹

    • Registered Address: No registred entity
    • Registered Legal Entity: No registred entity

    Team's experienceโ€‹

    Dastanbek Samatov is a Software Engineer with more than 3 years of experience. For the past 2 years he has been working as a Rust/Substrate Engineer focusing on parachain development and also has been involved with several Web3 Foundation grant projects in the past (some of them as lead developer):

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    This application is in response to the ISO-8583 RFP.

    The implementation is inspired from the previous research project for this RFP.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4 months
    • Full-Time Equivalent (FTE): 1 FTE
    • Total Costs: 28,000 USD

    Milestone 1 Infrastructure Partโ€‹

    • Estimated duration: 2 month
    • FTE: 1
    • Costs: 14,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up the whole infrastructure components.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Merchant AppI will create a React application that will mock the merchant. The app will be connected to the Substrate chain with PolkadotJs and users will be able to directly pay using an on-chain extrinsic. Web app will also handle necessary balance checks by querying chain to early return invalid transactions. Users will also have an option to use their mock plastic cards.
    2.Payment ProcessorI will create a NodeJs server that will receive payment requests from merchant app, compose the ISO-8583 message and send it to the gateway. This server will also be responsible for keeping the offchain ledger, similar to how traditional networks currently operate.
    3.PCIDSS Compliant GatewayI will create a message broker service that will serve as a centralized oracle gateway. It will process and pool incoming messages from the mock payment processor. Oracle will maintain a constant connection to Substrate chain, to ensure the validity of messages in the pool before they are consumed. For example, if there is a transfer from Alice to Bob, oracle will ensure that Alice has enough funds both offchain and on-chain, tx_id of transfer is not already on-chain, etc. It will also include mechanisms to ensure the message is being consumed by genuine offchain worker and not some other malicious consumer. For this step, some basic cryptographic authentication method will be used.
    4.MakefileI will create a Makefile that will provide commands to ease testing, running and maintaining the project

    Milestone 2 Blockchain Partโ€‹

    • Estimated Duration: 2 months
    • FTE: 1
    • Costs: 14,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleI will publish an article that explains the complete lifecycle and future plans of the project
    1.Substrate ChainI will create a Substrate chain forked from substrate-node-template.
    2.Offchain WorkerI will write an offchain worker logic that queries PCIDSS compliant gateway for ISO-8583 messages, processes them and dispatches extrinsics to the chain.
    3.ERC-20R PalletI will create a pallet that implements the ERC-20R interface. It will be responsible for processing incoming message from the offchain-worker. It will perform security checks, maintain the ledger and control the issuance of the tokens.
    4.Integration testsI will add end-to-end tests with Javascript and zombienet
    5.MakefileI will create a Makefile that will provide commands to ease testing, running and maintaining the project

    Future Plansโ€‹

    In case of successful PoC, I plan to continue working on this project to address some of the pain points of the PoC:

    • Reversability: look for more decentralized ways to guarantee reversability of the transactions, maybe with somewhat similar mechanism to slashing
    • Decentralization of Oracles: look for more decentralized ways of message processing by using decentralized oracles, maybe look for the direction of zero-knowledge proofs

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    I have previously worked on several grant projects (listed above) and generally have been in Polkadot ecosystem for more than 3 years.

    - + \ No newline at end of file diff --git a/applications/ISO20022.html b/applications/ISO20022.html index a5bef1df247..15b30ca2735 100644 --- a/applications/ISO20022.html +++ b/applications/ISO20022.html @@ -4,13 +4,13 @@ ISO20022 PoC | Web3 Foundation Grants - +
    Skip to main content

    ISO20022 PoC

    • Team Name: Open Smart Contract
    • Payment Address: 3GTe5ArJLC8jesr6UFtB9kcoguQmvo8Cuo (BTC)
    • Level: 2

    Project Overviewโ€‹

    Response to RFP 20022

    Cross-border payment example as proof of concepts, leveraging the unique Off-Chain Features of Substrate that show the advantages of using ISO20022 together with Substrate.

    Overviewโ€‹

    The project is an ISO20022 based cross-border payment proof of concepts implemented with Substrate off-chain computation and indexed data storage.

    ISO (International Organization for Standardization) 20022 is becoming the de facto global data standard for payments and electronic data interchange already adopted by many countries. However the ISO20022 are all about centralized fiat based payment rails among privileged global financial institutions.

    Blockchain based decentralized payment solutions can provide efficiency, low latency and cost savings potentially benefiting billions of users worldwide. There are ledger based currency exchange and remittance network such as the real-time gross settlement system from Ripple Labs Inc. yet it is permissioned, centralized and not capable of cross chains.

    Polkadot, with its multi-chain architecture, security and cross chain interoperability, is uniquely positioned to support ISO20022 compliant global payments. This project is a Proof of Concepts to understand what it takes for Dotsama ecosystem to support a cross-border payment use case, leveraging on XCM, OCW and Substrate pallets, challenges and recommendations.

    Project Detailsโ€‹

    • Mockups/designs of any UI components

      • Use Contracts-UI (or Polkadot.js) UI interface to interact with deployed smart contracts

    • Data models / API specifications of the core functionality

      • ISO20022 XML data models that captures essential ISO20022 cross-border payment metadata
      • ISO20022 data types to XCM mappings with custom data types if gaps
      • Data securely stored off chain, indexed for queries
      • ISO20022 messaging and payment events and stats
      • Persisted off chain data storeage fo performance benchmarks, throughput, gas fees, binary size, payment latency and costs

    • An overview of the technology stack to be used

      • Substrate off chain workers to process compute intensive tasks such as ISO20022 message wrangling
      • Substrate off chain storage / indecing to persist string heavy ISO20022 messages
      • ISO20022 messages parsing / mapping / processing using OCWs
      • Substrate XCM frame pallet with transport methods for ISO20020 messaging
      • Custom OCWs to support cross-border payment use case with message, events, stats and payment flow query capabilities
      • Optional off chain connected cloud storage and HTTP requests

    • Documentation of core components, protocols, architecture, etc. to be deployed

      • Published article documenting detailed analysis of what it takes to support ISO20022 compliant cross-border payments on Dotsama blockchains
      • Custom pallet(s) implementing cross-border payment logic
      • Off chain worker logic processing compute and storage intensive payment processings
      • Mapping from cross-border ISO20022 messages to XCM and XCMP messaging
      • ISO20022 messages, payment history, events and stats, stored off chian with indexes for queries
      • Gaps identified and solution recommendations
      • Substrate based Dotsama blockchain as testnet to deploy sandbox

    • PoC/MVP or other relevant prior work or research on the topic

      • Our research shows that many challenges exist to support ISO20022 compliant cross border payment use case
        • A traditional ISO20022 cross border payment means multiple transactions in various ISO20022 message types, with multiple hops among financial entities inter-connected via custom agreements / fee structures / sfovereign regulations, with no standards
        • ISO20022 and XCM are at different granularies with a single cross-border payment mapping to a set of XCM messages with flow logic
        • ISO20022 payment transactions have different fees / charges based on many factors
        • Traditional cross-border payments on fiat rails do not have blockchain "gas fee" concept
        • Data type incompatibilities between IS20022 and XCM, such as date and time, currency, float, array, etc.
        • No out of box support of XML data processing and mapping such as XSD transformations
        • No native foreign exchange / currency conversion support
        • XCVM with instruction set for XCMP messaging is a totally different paradigm as compared to traditional message passing
        • No existing gas light solution to handle compute intensive and indexable data storage for off chain payment processing

    • What your project is not or will not provide or implement

      • This is not a complete cross border payment system given the scope of proof of concepts
      • Likely this is the first ISO20022 project on Dotsama, there could be unexpected gaps discovered
      • This project is not a full blown IS20022 implementation on Dotsama / Substrate but explore to expose gaps for future endeavors
      • This project is not about payment identity / KYC / AML solutions
      • This milestone is all about understanding what it takes to support ISO20022 compliant cross-border payments on Dotsama, not implementations which could come later with more clarity coming out of this project

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem?
      • According to the RDP: "The goal of this RFP is to find teams that implement tools that make it easy and possible for the traditional finance industry to leverage Substrate and ink! smart contracts to interact with ISO 20022 in various ways"
    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?
      • Targeting ecosystem developers to leverage on the learning and tools to further develop ISO20022 compatible dApps, to make it possible for transitional financial institutions to interoperate with Polkadot / Kusama / Substrate blockchains based payment apps.
    • What need(s) does your project meet?
      • Explore possibilities and gaps of Polkadot / Substrate support of ISO20022 standard for future improvements
    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?
      • If so, how is your project different?
      • If not, are there similar projects in related ecosystems? There are known blockchains already claim to support ISO20020 such as Ripple XRP, XLM, Algorand, etc.

    Teamโ€‹

    Team membersโ€‹

    • Name of team leader: Daniel Deng
    • Consultants with ISO20022 and cross-border domain expertise

    Contactโ€‹

    • Registered Address: No registred entity
    • Registered Legal Entity: No registred entity

    Team's experienceโ€‹

    Daniel is the Chief Product Officer at HeroDAO where he has led blockchain based smart contract products and development on Polkodot / Kusama blockchains. Previously at Meta he managed crypto (Libra / Diem) and fiat payments and web3 initiatives. Prior to that, he was Senior Director of Product Management at Visa managing Visa's global payment product portfolios and platforms.

    The project to add consultants from fintech / banks / financial institutions with relevant domain expertise in ISO20022 and cross-border payments.

    Here's a recent Medium article on ink! smart contract with Rust macros implementing dApp on Dotsama chain, with Smart Contract Deployment and Interaction Guide using Contracts-UI and Polkadot.js.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members.

    Team LinkedIn Profiles (if available)โ€‹

    Development Statusโ€‹

    Development Roadmapโ€‹

    Overviewโ€‹

    • Estimated duration: ~1-2 months
    • FTE: 1,2
    • Costs: 25K USD

    Milestone 1โ€‹

    • Estimated duration: ~1-2 months
    • FTE: 1,2
    • Costs: 25K USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDesign documents with details on what it takes for Polkadot/Substrate to support ISO20022 messages, gaps and solution recommendations
    1.Design the use caseDesign an ISO20022 cross border payment use case with persona, end-to-end flow
    2.Identify ISO20022 message types and examples for X-border paymentSpecify all ISO20022 message types with examples for cross border payment, including reference data fields
    3.Map ISO20022 - XCM messagesMap ISO20022 cross-border payment message types to a set of XCM messages with processing logic, including identifying data type incompatibilities between IS20022 and XCM, replacement data types and necessary XML transformations
    4.Map ISO20022 - XCMPMap ISO20022 cross-border payment messageing to XCMP for cross parachains transport
    5.Specify off chain data storageSpecify off chain data structure, storage and indexes for ISO20022 messages, payments, events, stats
    6.Specify off chian worker logicSpecify OCW logic for ISO20022 message processing, payment flow, error handling
    7.Specify Substrate palletsSpecify custom pallet(s) to implement X-border payments and OCW integrations
    8.Recommend blockchain gas fees handling in ISO20022 frameworkRecommend solution how to fulfill blockchain gas fees in ISO20022 framework
    8.Recommend how to implement ISO20022 cross-border charges & feesRecommend solution how to implement ISO20022 cross-border payment inter-bank / X-border payment charges and fees
    9.Specify query of ISO20022 messages and transactionsSpecify query interface to retrieve selected ISO20022 messages and transactions
    10.Publication to share with the broader community and get additional feedbackMedium article covering: 1) feasibility and comparative advantages of Substrate based ISO20022 compliant cross-border payments on Dotsama chain; 2) benefits of such a solution in contrast to traditional centralized cross-border payments; 3) recommendation of future works towards a scalable, performant and cost effective solution supporting ISO20022 on Polkadot/Kusama chains and beyond.

    Future Plansโ€‹

    • Publish learning and share with the community, similar to this Medium article and/or Contracts-UI and Polkadot.js Smart Contract Deployment and Interaction Guide
    • Long term we intend to expand this ISO20022 PoC to:
      • develop reusable tools / features to bring ISO20022 compliant payments to the Dotsama ecosystem
      • Bring Polkadot / Kusama chains up to speed with Ripple XRP / XLM / Algorand / etc. on ISO20022 support
      • Onramp transitional financial institutions worldwide to blockchain enabled cross border payments
      • Leverage Dotsama's unique off chain computing, storage and connections (cloud, HTTP) capabilities to scale web3 dApps
      • Support ISO20022 MX messages via Polkadot XCMP, and possible integration with IBC (Inter-Blockchain Communications)
      • Future milestones implementing the use case with workload estimation with insights from this initial milestone

    Referral Program (optional)โ€‹

    You can find more information about the program here.

    • Referrer: N/A
    • Payment Address: N/A

    Additional Informationโ€‹

    How did you hear about the Grants Program? Web3 Foundation Website and previous work interactions

    - + \ No newline at end of file diff --git a/applications/Idavoll Network.html b/applications/Idavoll Network.html index 087528042c5..071f466b078 100644 --- a/applications/Idavoll Network.html +++ b/applications/Idavoll Network.html @@ -4,7 +4,7 @@ Idavoll Network | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Idavoll Network

    • Proposer: jasonberger0
    • Payment Address: 1NNtuqwroKc9cMZdigpLdNLrzPKCp7zkXT

    Project Overviewโ€‹

    Overviewโ€‹

    Idavoll Network is an decentralized organization platform that provides infrastructure and services to users of the Idavoll Network and Polkadot ParaChains. Each Idavoll Network organization exists as a set of modules that define the organizationโ€™s stakeholders and their associated rights and privileges. Idavoll Network will implement idavoll court in the future, developed and maintained by Idavoll Network holders. The idavoll court can be used by organizations, to resolve subjective disputes with binary outcomes.

    Project Detailsโ€‹

    Idavoll Network is a decentralized organization network based on Substrate and run as a parachain on Polkadot. Idavoll Network has a set of pallets to achive the management of DAOs: orgnaization module, voting module, token module and finance module. By chanining these modules together, everyone can define a DAO which constrain how actions can be performed within the organization. We will give some common scenarios to explain how the idavoll pallets use predefined rules to active the standard forwarding operations.

    idv

    Common Scenariosโ€‹

    Transfer Assetsโ€‹

    • the Organization members initiate a proposal to transfer organizational assets through the Finance Module. The proposal is confirmed on the Vote Module and required to complete the voting results of the organization members within a certain period of time. The voting results are required to meet the asset transfer rules in the Finance Module. The approval votes are greater than the minimum approval votes. Only after the number and the number of negative votes are less than the limit of the maximum number of negative votes, can the proposed movement of asset transfer within the organization be realized through the Finance Module.

    Snapshot Vote Decisionsโ€‹

    • We can combine the organization module, voting module and token module to implement the decision management process. Users can create any proposal (an easy-to-understand term that the proposal must follow) and initiate the voting process. All users holding the corresponding tokens can participate in the voting. The voting ends, the Idavoll Network will count the voting results of the voters according to the snapshot of the current blockchain state. The voting results will be used as a community consensus and will be permanently stored on the blockchain.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • jasonberger0
    • Dylan
    • kericfrank

    Teamโ€™s experienceโ€‹

    • jasonberger0 Over 10 years of experiences in Development and Management,real time database products and digital currency transaction platform products expert. Currently focused on Blockchain Development and Cross-chain Technologies.
    • Dylan holds a master degree from Tsinghua University. He has more than 10 years of experience inlarge-scale computing and algorithm, with many patents such as consensus algorithm and blockchain transaction.
    • kericfrank: 8+ years development experience, proficient in public chain and cross chain development, proficient in using go and rust, p2p network expert.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4 weeks
    • Full-time equivalent (FTE): 3
    • Total Costs: 0.65 btc

    Milestone 1โ€‹

    • Estimated Duration: 4 weeks
    • FTE: 3
    • Costs: 0.65 btc

    In this milestone, We will implement Idavoll DAO proof-of-concept.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can import the protocol.
    0c.Testing GuideThis milestone will have unit-test for all modules to ensure functionality. In the guide we will describe how to run these tests.
    1.Idovall Organization moduleThis module provide methods to create a DAO with specific parameters, such as the name, the permissions and the internal addresses for your organization. And it is the entry of the other module functions.
    2.Idovall Voting moduleCreate proposal and set the voting duration, minimum approval and support percentage of your proposal. When a proposal approved, token assignment or funds transfer will execute.
    3.Idovall Token moduleImplement Token module to mint new tokens and assign them, and confer voting abilities to holders of the tokens such that one token equals one vote. Minting and assignment is trigger by Idovall Voting module .
    4.Idovall Finance moduleThis module provides tokenholders with access to the funds held by their organization. It supports deposit funds, withdraw funds and transfer funds, after the proposal approvement from Idovall Voting module . The module also shows the current balance as well as the transaction history of the organization.

    Future Plansโ€‹

    • we will provides a Dapp for everyone to interact with the Idovall network.

    • In the future, the Idavoll Network will add a court protocol to resolve subjective disputes with binary outcomes, combined with the use of IDVโ€™s infrastructure, so that the DAOs can create proposal agreements that define the subjective constraints of organizational operations, and can be used by a minority of interests Stakeholder implementation.

    - + \ No newline at end of file diff --git a/applications/Integrating-ISO8583.html b/applications/Integrating-ISO8583.html index 3ce633b398d..88936d34dff 100644 --- a/applications/Integrating-ISO8583.html +++ b/applications/Integrating-ISO8583.html @@ -4,7 +4,7 @@ Integrating ISO-8583 | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ ISO-8583 datastreams reveal far too much information to ever be publically exposed. Here neapay proposes using ISO-8583 to connect to Coinbase to purchase crypto. However you can see that once the datastream is unpacked, the user's financial details are immediately revealed. Unpacking data is a trivial process that has no security, ISO-8583 data is not encrypted. Of note is the exposed primary account number (F02_PAN: 9876 5000 0030 6082). Most people would recognize this number faster as their credit card number. While it is possible, and implemented in practice, to transfer the data securely between two, trusted centralized servers using Diffie Hellman key exchange, research is needed to construct a way to place ISO-8583 data on-chain securely, if it is even possible. There are also laws about retaining this information for a fixed period of time, for example, Minnesota, a US state mandates that this information is deleted within 48 hours of reciept which is at odds with the enduring, provable structure of a blockchain.

    Transaction Reversals Outside of simple purchases, one of the most common messages communicated over ISO-8583 are chargebacks. About 0.6% of all transactions are ultimately recalled, though it varies by industry. ISO-8583 was designed to handle this process seamlessly and has a reserved MTI code for all chargebacks and reversals (x4xx). Unfortunately, modern blockchains by design are irreversible. From the original introduction of Satoshi Nakamoto's white paper.

    While the system (traditional finance) works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services. With the possibility of reversal, the need for trust spreads.

    Supporting ISO-8583 functionality would require building a new token standard, or making changes to the operation of the blockchain to allow reversible transactions. A solution highlighted in the original bitcoin white paper is automatic escrow accounts, but research would be needed to identify the best way to implement these accounts or if there are better solutions.

    Authorizations and Privilages This leads to another major challenge. In traditional banking, the users are not equal. Certain entites such as the issuing bank or network can make decisions unilaterally without recourse. An example of this would be the aforementioned chargeback or transaction reversals which can be performed by the issuing bank or network for any reason. Blockchains operate on an equivalent peer model, and it is an open question as to how to authorize a super user and who should maintain super user priviliages over the entire network.

    For Milestone 1 we aim to deliver a robust implementation proposal with solutions to these challenges. While likely no the intent of the RFP, significant foundational reserach has to be done into the feasibility of integrating ISO-8583 with Substrate (or even blockchains in general). These challanges have significant risks and may prove unfeasible. For example, it is possible that it is ultimately too risky to store ISO-8583 data on-chain or even expose it to nodes. While we do not aim to make such determinations during Milestone 1, we will provide a detailed documentation of the major challenges, options for addressing these challenges, and the major tradeoffs. We will also try to summarize what others have done in this space.

    Ecosystem Fitโ€‹

    Supporting international standards would smooth the connection between crypto and traditional financial institutions and is a go to market strategy for several competing projects. While those efforts are focused on the newer ISO-20022, not ISO-8583, there is significant value in being the first blockchain to support traditional banking infrastructure and dislodge incumbent networks such as SWIFT or Visa/Mastercard.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Adit is a technical expert on cryptography, distributed ledgers, financial markets, and new product development. He graduated Columbia in 2011 with a BSc in Applied Physics and a minor in Econ. During his time there, he took additional coursework focused on cryptography, statistics, and fundamental computer science. After graduating, he joined Capital One and quickly rectified the failing, newly launched small business brand. These efforts made him well known as the go-to analyst for successful new product development, strategy and launch. He was tapped to design and launch financial products for Hispanic consumers and tapped again to build Capital Oneโ€™s B2B financial products. During his tenure there, Adit experienced first hand the hard learnings that lead to efficient risk mitigation in financial products and the intricacies of financial engineering. He has a decade of technical experience at the intersection of finance and technology and has built and implemented financial products including credit cards before.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Through this grant proposal, we aim to provide a well-detailed analysis and implementation plan for incorporating ISO-8583 with Substrate.

    Overviewโ€‹

    Milestone 1 โ€” ISO-8583 Implementation Plan Researchโ€‹

    NumberDeliverableSpecification
    0.RightsAll developed materials will be publicly accessible and public domain.
    1.Research GoalA well-detailed analysis and implementation plan for incorporating ISO-8583 with Substrate with solutions or options for the outstanding challenges.
    1a.Specific CoverageWe will deep dive into the outstanding challenges related to security, reversibility, and authorization. As part of this, we will cover some industry security standards such as PCIDSS compliance and it's applicability, though this is not legal advice or intended to be legal advice. For each of these three challenges we will attempt to provide either a well developed solution or options with careful detailed tradeoffs for the Web3.0 Foundation team to select from.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Previous Grantee

    - + \ No newline at end of file diff --git a/applications/Interstellar-Network.html b/applications/Interstellar-Network.html index a50efb27ccd..8c69292c373 100644 --- a/applications/Interstellar-Network.html +++ b/applications/Interstellar-Network.html @@ -4,7 +4,7 @@ Interstellar - Wallet Phase 1 | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ We achieved a production ready platform with significant performance on the logic circuit and garbled circuit production with AES-NI. The whole pipeline uses optimized memory management and avoids serialization/deserialization of the different circuit formats: HDL->non-garbled->garbled.

    1 ./circuit_display_gen_bench -nb_circuits_to_generate=5000
    2 display_size : 360,154,50,590
    3 time in s : 28.1261 s
    4 circuits_per_hour : 639975

    1844c95c-1b74-4987-8466-4ba14da41ff3 (Custom)

    5,65 ms per circuits on a Processor 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz, 2304 Mhz, 8 Core(s), 16 Logical Processor(s)

    Technology stackโ€‹

    Ecosystem Fitโ€‹

    Where and how does your project fit into the ecosystem?

    This project is the first phase of a wallet project. Although, we think that our Trusted Transaction Validation protocol could bring a novel approach to address UX/UI security issues regardless of other features of our frictionless wallet. We designed our validation transaction protocol to benefit to other wallets or Dapps. We think it could also be complementary down the road to mobile light clients like Substrate Connect (check Future Plans section).

    TTV overview overview drawio

    TTV overview overview dark drawio

    Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

    We want to target Dapp providers in the DeFi ecosystem with developer tools to integrate our solution with their Dapps. We think that our value proposition should be attractive to them. At the same time we want to target newcomers with a Robinhood wallet for Defi that includes an average dollar cost feature.

    What need(s) does your project meet?

    The need for a wallet to be simpler to set-up and use, as well as the need for higher security to address the growing malware/banking trojan threats.

    Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

    Math Wallet and Gluon are close to our solution.

    We think that we could bring a better user experience, security and performance, thanks to a highly scalable layer 2 based on SubstraTEE:

    *see: A high level attack description on solutions that use QR code for transaction confirmations Are cryptocurrency wallets more at risk than ever?

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Team deck

    We are now multiple security and fintech entrepreneurs, security researchers, patents fillers who turned open-source developers and blockchain enthusiasts.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement GCF Substrate modulesโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can create and set-up a VHDL Master File, launch Garbled Circuit generation and get the resulted garbled circuit cid on IPFS and associated GC metadata i.e to check one-time code.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains what was done/achieved as part of the grant. (Content, language and medium should reflect your target audience described above.)
    1.GCF Substrate InterfaceGCF external service interface to interact with the following Substrate modules and IPFS.
    2.Substrate module: GCF CFGWe will create a Substrate GCF configuration pallet that will store GCF encrypted configuration information on chain (including cid of master circuit file, master key and other security parameter to ensure security of circuit production.
    3.Substrate GCF CFG CLIA CLI to set-up GCF configuration pallet.
    4.Substrate module: OCW GCFWe will create an OCW pallet that will control and interact with GCF external service - Launch GC production and get resulted GC cid on IPFS.

    Milestone 2 โ€” GC Management in Substrate modules and Transaction Validation protocol use case (first part)โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can manage garbled circuit cid in pallets, with a transaction validation use case example.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains what was done/achieved as part of the grant. (Content, language and medium should reflect your target audience described above.)
    1.Substrate module OCW GCPWe will create an OCW GC provider to interact with a GC evaluator/IPFS client.
    2.Substrate module: AuthenticatorWe will create a Substrate Authenticator pallet that will implement the Transaction Validation protocol to manage GC evaluator and IPFS client.
    3.Substrate GCP CLIA CLI to request GC cid for evaluation.

    Milestone 3 โ€” Transaction Validation protocol with mobile use case (second part)โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can manage garbled circuit cid in pallets. with a transaction validation use case example with mobile GC evaluators.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains what was done/achieved as part of the grant. (Content, language and medium should reflect your target audience described above.)
    1.Mobile Client (android 1.a/iOS 1.b)We will create android and iOS mobile clients with GC evaluators and IPFS light clients to manage Transaction Confirmations.
    2.Substrate module Mobile RegistryWe will create a Substrate Mobile Registry pallet to deal with mobile clients (android/iOS) and mobile public Keys and signature verifications.
    3.Substrate module: Authenticator with mobileWe will add mobile features to Substrate Authenticator/Transaction Validation Mngt pallet.

    Milestone 4 โ€” Integration with SubstraTEE/IntegriTEEโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can manage garbled circuit cid in pallets with a transaction validation use case example in TEE environment with SubstraTEE.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains what was done/achieved as part of the grant. (Content, language and medium should reflect your target audience described above.)
    1.Substrate modules Authenticator port in TEEWe will migrate Authenticator in SubstraTEE/IntegriTEE workers.
    2.Substrate module Mobile Registry port in TEEWe will migrate a part of the Mobile Registry pallet in SubstraTEE/IntegriTEE workers.

    Milestone 5 โ€” GCF Garbling service part in TEE (amended)โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can manage GCF garbling service part in IntelSGX
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will write and share (not officially publish as we are still in stealth mode) an article that explains what was done/achieved with the grant. (Content, language and medium should reflect your target audience described above.)
    1.replacement of JustGarble (GPL) with Swanky/Fancy-Garbling (MIT)In order to use a TEE framework we need a non-GPL garbling scheme code
    2.part of GCF external service in TEEWe will migrate the circuit garbling service part in TEE/Intel SGX
    3.android client garbled circuit evaluation updatedwe will update the evaluator on android with the Fancy-Garbling scheme

    notes regarding this change:

    1: We have decided to let the creation of the Master/Configuration logical circuit part managed by ocwCircuit outside of TEE because api_circuit is not critical from a security standpoint in our use case.So, we have no reason to manage it within a TEE.

    2-3: We replaced the GPL code of JustGarble by Fancy-Garbling because we can't use GPL licence with a TEE framework. Fancy-Garbling is a classic garbling scheme using a different circuit file format and mainly design for multi-party-computation use cases. So, the change slightly impacts circuit garbling performance. As a consequence we aim at proposing a slight refactoring of the code to ensure performance optimization in a follow-up grant to achieve performance at least comparable to JustGarble. Potentially adding a permutation based garbling scheme like the one used by JustGarble if required.

    Future Plansโ€‹

    How we intend to use, enhance, promote and support your project in the short term:

    Medium-term plan

    The team's long-term plans and intentions in relation to it.

    3T Distributed HSM overview drawio

    3T DHSM overview dark drawio

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Others

    - + \ No newline at end of file diff --git a/applications/Interstellar-network2.html b/applications/Interstellar-network2.html index 286c4a5549f..3b4551019f1 100644 --- a/applications/Interstellar-network2.html +++ b/applications/Interstellar-network2.html @@ -4,7 +4,7 @@ Interstellar - Wallet Phase 2 (amended) | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ Interstellar aims to change this perception through a new approach and technology.

    We strongly believe that securely linking and registering access device security components with a blockchain-based autonomous system is an extremely powerful concept. It can provide a future-proof solution for addressing the current security, usability, and privacy issues associated with current centralized non-custodial wallet software.

    In terms of security, this approach utilizes the current and future mobile device security capabilities by implementing a secure distributed protocol. It addresses the current lack of third-party protection and management while also adding the necessary decentralized backend services to enhance security against evolving cyber threats.

    Regarding usability, this approach simplifies the user experience by adding transparent services like Instant Onboarding.

    Privacy can also be addressed using methods such as stealth addresses and other private schemes.

    Additionally, implementing this approach increases the overall system's auditability, potentially enabling the management of a guarantee fund to aid users in case of issues.

    Furthermore, this approach can enable new types of recovery schemes that would be impossible without a secure decentralized autonomous system backend.

    A highly secure and convenient wallet system is necessary to combat cyber threats and ensures larger adoption.

    Our solution transforms mobile devices into cold wallets, with private keys protected at the hardware level:

    This hardware security, combined with a Trusted Transaction Validation Protocol, offers robust protection against state-of-the-art malware, including banking Trojans, and prepares for future targeted attacks.

    Interstellar is more than a wallet, we have designed a novel secure access layer for web3 managed with a blockchain that register mobile hardware/secure elements/TEEs to protect transaction with a strong multifactor authentication (based on hardware and software computation privacy scheme i.e. garbled circuit).

    Using a blockchain for the management of multi-chain transactions offers extra security and auditability features and dramatically increase convenience for the user:

    In the medium/long term (see future plan for more details):

    This approach achieves a highly secure level for newcomers to easily onboard web3, and serves as an alternative to hardware wallets for crypto veterans.

    Our technology has the potential to disrupt the hardware wallet, smart contract wallet, and even hot wallet markets.

    Project Detailsโ€‹

    A short video on the Interstellar solution (click on the following image)

    Architecture Overviewโ€‹

    Architecture overview

    TTVP Detailedโ€‹

    TTVP Detailed

    Technology stackโ€‹

    Ecosystem Fitโ€‹

    At parisDOT.comm we had a fantastic opportunity to present our project to the leading teams in the Polkadot Parachain community. And the feedback we received was nothing short of extraordinary. Our solution, which aims to provide both hardware security and user-friendliness in a wallet solution, struck a chord with the teams.

    Their positive response is a testament to the importance of a solution that addresses this critical need in the Polkadot ecosystem and beyond. The teams were not only impressed with our solution, but they were also eager to put it to the test as soon as it becomes available.

    This is a major market fit milestone for us, and we're thrilled to have the support of such influential players in the Polkadot community. We're dedicated to delivering a solution that meets their expectations and contributes to the continued growth and success of the Polkadot ecosystem.

    We are in active conversations with some of the teams we met there, and continuously have new discussions with new teams also beyond the Polkadot ecosystem. So far, everyone is impressed and enthusiastic about the solution.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    We are now multiple security and fintech entrepreneurs, security researchers, patents fillers who turned open-source developers and blockchain enthusiasts.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” New Garbling schemeโ€‹

    NumberDeliverableSpecification
    0a.LicenseAPACHE 2
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up our stack and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.Garble Circuit pallet updateWe will rewrite the garbled circuit evaluation scheme to target at least 60 fps through parralelization, caching and likely with an efficient 1.permutation-based garbling scheme: see 4.5 optimized for performance or a 2.new garbling scheme that could potentially require lower computation cost per gate

    Milestone 2 โ€” Circuit design optimization and light security screenโ€‹

    NumberDeliverableSpecification
    0a.LicenseAPACHE 2
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up our stack and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.Display Circuit updateWe will modify the current display circuit to enable a more comfortable user experience by decreasing the cognitive load needed for the user to read the screen. - likely by adding specific sub-circuits to manage a set of probabilities of displaying segments for each frame, then fine tuned segments ON/OFF per frame to improve readbility
    2.Light security screenWe will provide a less secure but very comfortable to read secure screen version using fading with less blinking (link) - this non-screenshot proof version will be used later with our adaptive security framework

    Additional information (reason for amendment):

    As we prioritize the user experience and aim to showcase the FPS improvement and overall viusal improvement for the user compared to the previous milestone, there is no need for a Docker here. Instead, we provide an offline demo app to simplify the evaluation.

    However, if you'd like to test the full pipeline for this milestone, we can provide you with both a Docker and an online version of the app and the related demo tutorial.

    - + \ No newline at end of file diff --git a/applications/InvArch.html b/applications/InvArch.html index 3df21c4a98a..999bd632602 100644 --- a/applications/InvArch.html +++ b/applications/InvArch.html @@ -4,7 +4,7 @@ The InvArch - INV4 Frame : IP Assets, Licensings, & CLI tool for the Substate ecosystem. | Web3 Foundation Grants - + @@ -29,7 +29,7 @@ startup co-founder and developer with a history focusing on JavaScript and Rust programming. Kresna is a Polkadot ecosystem contributor who loves entrepreneurship. ๐Ÿš€

  • Mindaugas Savickas is a veteran marketing advisor and fundraising rockstar with a background providing strategic marketing solutions and scaling over 40+ product & marketing teams worldwide. He Provides a proven history of success and strategic insights as a tech marketing guru who lives & breathes outside of the box. ๐Ÿ“ˆ

    • Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement IP Pallets & Standardsโ€‹

    Goal - Develop Substrate Pallets that fully realize Git-level composability for NFTs; fully emulating file & folder functionalities.

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationDocuments containing the description of the whole architecture design for InvArch, an introduction video, and appropriate README.md files will be included.
    0c.Testing GuideThe code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.Node RepoComplete the deployment of the InvArch chain (https://github.com/InvArch/InvArch)
    2a.Pallet_ipsComplete the development of pallet_ips and realize the IP Sets standard.
    2b.Pallet_ipfComplete the development of pallet_ipf and realize the IP Token Standard.
    3.ArticleWe will write an article that explains the work done as part of the grant.

    Milestone 2 โ€” Implement DEV Pallets & Standardsโ€‹

    Goal - Develop and deliver the DEV Pallets & Standards for the InvArch Chain/InvArch Pallet Library

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationAn introduction video, and appropriate README.md files will be included.
    0c.Testing GuideThe code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1a.Pallet_iplcomplete the development of pallet_ipl and copyright & license structuring mechanism.
    1b.Pallet_iptComplete the development of pallet_ipt and realize the refungible & multi-layer governance mechanisms.
    2.INV4-Git middlewareWe will release a middleware tool for managing INV4 assets using the standard git CLI commands transparently.
    3.Article & VideoWe will write an article that explains the work done as part of the grant, as well as release a video walk through demonstrating the INV4 protocol

    Future Plansโ€‹

    1. GitArch - Decentralized, Incentivized, Open-Source On-Chain Repository Platform powered using INV4-Git.
    2. Tinkerspace - A VR Sandbox for experimenting, collaborating, & simulating development using INV4 Assets.
    3. xcINV4 Module - Upgrade the INV4 protocol with enhancements made possible due with XCA for all Parachains to enjoy.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/JsonRpsee-socks5-proxy.html b/applications/JsonRpsee-socks5-proxy.html index bfdf92905ef..6427e310fae 100644 --- a/applications/JsonRpsee-socks5-proxy.html +++ b/applications/JsonRpsee-socks5-proxy.html @@ -4,7 +4,7 @@ JsonRpsee socks5 proxy | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    JsonRpsee socks5 proxy

    • Team Name: gmajor
    • Payment Address: 0xC3094f0ddce699a1Ad9Ef2621DF68Cd297a4c44F(USDC)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    RFPs https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/jsonrpsee-proxy-support.md

    Overviewโ€‹

    This proposal is to develop a JsonRpsee socks5 middleware proxy.

    Project Detailsโ€‹

    This proposal is to develop a JsonRpsee socks5 middleware proxy.

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem?

      This project is a middleware that can be used to proxy connections using a socks5 proxy. It can be used in any application that uses jsonrpsee as a client.

    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

      jsonrpsee client developers

    • What need(s) does your project meet?

      Enhance the JsonRpsee package and add support for socks5 proxy

    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

      Nothing

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • gmajor

    Contactโ€‹

    individual

    Team's experienceโ€‹

    I have many years of PHP development experience and nearly five years of blockchain development experience, familiar with PHP, GOLANG, PYTHON, Nodejs, Rust

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    Not yet

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1 months
    • Total Costs: 9000 USDC

    Milestone 1โ€‹

    • Estimated duration: 4 week
    • FTE: 1
    • Costs: 9000 USDC
    NumberDeliverableSpecification
    0a.LicenseMIT or Apache 2.0
    0b.DocumentationSimple documentation on how to use and how to test
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.Socks5 middleware supportEnable a jsonrpsee client to proxy connections using a socks5 proxy
    2.ExampleI will now provide an example to demonstrate the usage of this socks 5 middleware.
    3.Pull requestCreate pull request merge into jsonrpsee

    Future Plansโ€‹

    If there are any problems with this feature, I will still maintain it.

    - + \ No newline at end of file diff --git a/applications/JuniDB.html b/applications/JuniDB.html index f15a498665f..3f2d3109174 100644 --- a/applications/JuniDB.html +++ b/applications/JuniDB.html @@ -4,14 +4,14 @@ JuniDB | Web3 Foundation Grants - +
    Skip to main content

    JuniDB

    • Team Name: Uddug
    • Payment Address: 0xc45eAd98E95D1962133d9c15847e2EA4E16dfD0b
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    It's a very highload action to store large amounts of data on-chain. The most-common and useful solution for decentralised apps is to use IPFS as a data storage and store on-chain only hashes. Our team inspired by the OrbitDB will focus on the scalability, decentralised, easy-learning solution for substrat developers that want to manipulate big amounts of data easily.

    Key advantagesโ€‹

    • Usability - just integrate and code
    • Security - built-in encryption
    • Scaling - ready for changes and big data

    Available storage data typesโ€‹

    • Key-value - simple key-value storage
    • Hash - hash storage like Redis hash

    Motivationโ€‹

    Working a lot with blockchain technologies, our team found that itโ€™s data-driven, and thus there are rapidly growing interests in integrating them for more secure and efficient data storage and sharing.We are convinced that blockchain technologies change the world, and have been working hard to create more transparent solutions. We designed and built core infrastructure for decentralised projects.

    We have been observing and learning Substrate technologies and find Polkadot as the best ecosystem for us to join depending on technology and strong market position. We believe that our protocol will be useful for other projects in the Polkadot ecosystem.

    Project Detailsโ€‹

    Substrate pallet provides a configurable database module allows to store and manipulate a big amount of data. Pallet works as an offchain worker and connect data between blockchain and ipfs via offchain::worker.

    Encryption moduleโ€‹

    Built-in encryption module allows to create a secure database and encrypt all data before its uploading to the database with user account keys. With enabled encryption only account users have access to the database. Data could be decrypted via Web-application after receiving. Module is based on asymmetrical cryptography and uses an account public key to encrypt data on the blockchain side and a private key to decrypt data on the client side.

    We plan to make it based on ed25519 crypto scheme and use ecies-ed2551 crate to implement encryptions on backend side.

    scheme A

    • receive data by RPC request
    • Encrypt data by account public key
    • Insert encrypted data into ipfs via offfchain::ipfs
    • Insert received ipfs hash into storage

    scheme B

    • catch request to get data by RPC request
    • get ipfs hash from storage
    • fetch encrypted data from ipfs via offchain::ipfs
    • receive encrypted data in RPC response
    • decrypt data using user account private key via app ddecryption module

    Technical stackโ€‹

    • Rust - main language

    • Substrate - blockchain framework

    • Substrate-front-end-template - web-app template

    • Offchain::ipfs - substrate-ipfs bridge

    • IPFS - data storage

    • ecies-ed25519 - encryption crate

    Public Methodsโ€‹

    • KeyValueInit(name) - initialise new keyValue database

    • KeyValueSet(key, value) - set given value in keyValue database

    • KeyValueGet(key) - get value for given key

    • KeyValueDel(key) - delete value from keyValue database

    • KeyValueAll() - fetch all values from keyValue database

    • HashInint(name) - initialise Hash database

    • HashCreate(hashName) - create new empty cash

    • HashSetField(hash, field, value) - set hash field with given value

    • HashGetField(hash, field) - get hash field

    • HashDelFied(hash, field) - delete field from hash

    • HashAll(hash) - get all hash fields

    Storageโ€‹

    • Data Map - mapping ipfs hashes and data keys
    • Key-value - database meta info

    Scheme 1. Palett structureโ€‹

    scheme C

    Data uploadingโ€‹
    • Rpc/wss request to pallet to insert data
    • Validating data based on database schema
    • Formatting data
    • Encrypted (if needed)
    • Store to ipfs via offchain::ipfs
    • Retrieving ipfs hash with data
    • Store ipfs hash into pallet storage
    Data retrievingโ€‹
    • RPC/wsss request to pallet to fetch get data
    • Validating data query
    • Get ipfs hash from storage
    • Fetch data from ipfs via offchain::ipfs
    • Return data object in response

    Scheme 2. Interaction with Substrateโ€‹

    scheme D

    Infrastructureโ€‹

    Testing substrate nodes with offchain::orbitDB pallet orchestrated by kubernetes cluster deployed on GCP.

    Ci/Cdโ€‹

    Ci/Cs organized by github actions

    Frontendโ€‹

    Simple SPA web application powered by react and polkadot.js. Using for testing purposes.

    Ecosystem Fitโ€‹

    Pallet is suitable for substrate developers and strives to become a complex solution for data storage and manipulation.

    We expect that the project will be useful for the Web3 community.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Tech lead, backend: Andrew Skurlatov

    https://www.linkedin.com/in/andrew-skurlatov/

    Head of product: Mike Manko

    https://www.linkedin.com/in/mikhail-manko-97a491a2/

    Product design: Anuar Zhumaev

    https://www.linkedin.com/in/yxorama/

    DevOps: Ivan Podcebnev

    https://www.linkedin.com/in/naykip/

    Data Science: Constantine Czerniak

    https://www.linkedin.com/in/%D1%81czerniak/

    Frontend: Nikita Velko

    https://www.linkedin.com/in/nikichv/

    Contactโ€‹

    Contact Name: Mikhail Manko

    Contact Email: ms@uddug.com

    Registered Address: PO301650, RUSSIA, UL. OVRAZHNAYA, D. 35, S. TETYAKOVKA, NOVOMOSKOVSKIJ R-N, OBL. TUL'SKAYA.

    Registered Legal Entity: PE SKURLATOV ANDREY ALEKSEEVICH

    Team's experienceโ€‹

    Core of our team is of united, like-minded professionals with solid experience. We are constantly evolving our capabilities to help software technology companies to do more with less: develop software solutions faster and ensure high quality within time constraints, with fewer resources, and lower costs. We combine proven methodologies, business domain knowledge and technology expertise of skilled software professionals to deliver highly optimized solutions and services across a wide range of industry domains.

    Team range of experience begins from developing small scaled websites up to complex blockchain architectures. Our projects are diverse, but all of them share the need to have a software solution for humans.

    Team Code Reposโ€‹

    http://github.com/andskur/

    http://github.com/uddugteam/

    Commitsโ€‹

    https://github.com/uddugteam/thc-node/commits/master

    https://thc.uddug.com/

    Development Status ๐Ÿ“–โ€‹

    We have already developed the pre-alfa pallet for Trusted Health Council (https://github.com/uddugteam/thc-node).

    Link to initial pull request (https://github.com/uddugteam/General-Grants-Program/blob/master/grants/speculative/trusted_health_consul.md).

    Link to 2nd pull request (https://github.com/uddugteam/Open-Grants-Program/blob/master/applications/ML-as-a-service.md).

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 4 months
    • Full-Time Equivalent (FTE): 2.5 FTE
    • Total Costs: 28 000 USD

    Milestone 1โ€‹

    • Estimated Duration: 1 month
    • FTE: 2.5
    • Costs: 7 000 USD
    NumberDeliverableSpecification
    0a.LicenseLicense: GNU GPL v3
    0b.DocumentationDocumentation of the code and a basic tutorial describing how the software can be used and tested.
    0c.Testing GuideComplex quality assurance for all platform features. Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains the functionality of the proposed pallet in this milestone.
    1.Substrate ML palletBasic database layout implementation with key-value data storage
    2.Web applicationInteracting with blockchain + form with fields to manipulate with data. Based on the substrate-front-end-template
    3.Docker imageWe will provide a dockerfile to demonstrate the full functionality of testing Substrate chain with integrated Database pallet.

    Milestone 2โ€‹

    • Estimated Duration: 1 month
    • FTE: 2.5
    • Costs: 7 000 USD
    NumberDeliverableSpecification
    0a.LicenseLicense: GNU GPL v3
    0b.DocumentationDocumentation of the code and a basic tutorial describing how the software can be used and tested.
    0c.Testing GuideComplex quality assurance for all platform features. Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains the functionality of the proposed pallet in this milestone.
    1.Update offchain::ipfsWe will coordinate with equilibrium.co to update offchain::ipfs to the latest Substrate version via PR to the existing repository
    2.Docker imageWe will provide a dockerfile to demonstrate the full functionality of testing Substrate chain with integrated Database pallet.

    Milestone 3โ€‹

    • Estimated Duration: 1 month
    • FTE: 2.5
    • Costs: 7 000 USD
    NumberDeliverableSpecification
    0a.LicenseLicense: GNU GPL v3
    0b.DocumentationDocumentation of the code and a basic tutorial describing how the software can be used and tested.
    0c.Testing GuideComplex quality assurance for all platform features. Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains the functionality of the proposed pallet in this milestone.
    1.Substrate palletImplement an encryption module to allow encrypt and decrypt needed data out of the box.
    2.Web applicationUpdate web application to interact with the encryption system.
    3.Docker imageWe will provide a dockerfile to demonstrate the full functionality of testing Substrate chain with integrated Database pallet.

    Milestone 4โ€‹

    • Estimated Duration: 1 month
    • FTE: 2.5
    • Costs: 7 000 USD
    NumberDeliverableSpecification
    0a.LicenseLicense: GNU GPL v3
    0b.DocumentationDocumentation of the code and a basic tutorial describing how the software can be used and tested.
    0c.Testing GuideComplex quality assurance for all platform features. Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains the functionality of the proposed pallet in this milestone.
    1.Substrate palletAdd hash data storage to the pallet. Update rpc module to interact with new data storage. Database optimizations.
    2.Web applicationUpdate web application with new data storage rpc.
    3.Docker imageWe will provide a dockerfile to demonstrate the full functionality of testing Substrate chain with integrated Database pallet.

    Future Plansโ€‹

    Further development (adding new data storages, indexing system, concurrency queries)

    Community engagement

    Also we want to realise this idea and integrate it as the core part of our project in the healthcare sphere โ€œTrusted Health Councilโ€. We have reached agreements with medical institutes in the field of further development of the project concept such as belgium "University of Antwerp" and russian "Pirogov Medical University" on the further development of the project, in particular, providing access to their databases, as well as the creation of specialized departments on the basis of institutes for the innovative development of universities, promotion, participation in healthcare exhibitions and advisors.

    Additional Information โž•โ€‹

    The development of the prototype and initial research have been started with the personal funds. We have tried for a General Grant first, and decided to start with an Open grant Program relying on recommendation. Also we have applied for the Substrate Builders Programm and have proceeded with a general interview to iterate around steps going forward. We have also opened a dialogue with Blockchers & IPFS.

    - + \ No newline at end of file diff --git a/applications/KSM-embeddable-tip-or-donate-button.html b/applications/KSM-embeddable-tip-or-donate-button.html index 296c0002764..3284eef25ab 100644 --- a/applications/KSM-embeddable-tip-or-donate-button.html +++ b/applications/KSM-embeddable-tip-or-donate-button.html @@ -4,13 +4,13 @@ Tip or Donate KSM Embeddable Button | Web3 Foundation Grants - +
    Skip to main content

    Tip or Donate KSM Embeddable Button

    Project Overviewโ€‹

    This application is in response to following RFP https://github.com/w3f/General-Grants-Program/blob/master/rfp-proposal/ksm-tipping-button.md

    Overviewโ€‹

    As proposed in the RFP we will make a standalone embedded "Tip or Donate KSM" button with customizable text by the website owner. The button's embedded code will sanitize the current URL, check if the tip for the same URL already exists and is active. If available and once clicked button will ask for permission to connect to PolkadotJS extension, offer to Propose Tip or Donate directly. If proposing a tip, it will inform the user of the funds needed to propose a tip (transaction fee and deposit), check if the user is a Council member and optionally allow him to attach a message. Only Council members are allowed to propose the amount once the tip has been created. Once the tip is proposed the button will be disabled. If donating directly it will ask for an amount and allow visitor to enter a custom note.

    Considering the request for this implementation not slowing down the websites and several performance tests from different sources exhibiting Svelte as the optimal choice performance-wise we are strongly considering using Svelte as a development framework. Before committing to that decision we will conduct the performance tests ourselves and decide if it is the optimal solution. We will be using polkadot.js API.

    Mockups:

    Connect to Polkadot

    Select a wallet

    Propose a tip/Donate

    Teamโ€‹

    Team membersโ€‹

    • Darko Maฤeลกiฤ‡
    • Ana Miliฤ‡-ล trkalj

    Team Websiteโ€‹

    SHARD LABS d.o.o., Kroz Smrdeฤac 19 Split, Croatia

    Team's experienceโ€‹

    We have experience in several private and open source projects. Most notable and relatable to the proposal:

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-time equivalent (FTE): 4 weeks
    • Total Costs: 0.75 BTC

    Milestone 1โ€‹

    • Estimated Duration: 3 weeks
    • Costs: 0.25 BTC
    NumberDeliverableSpecification
    1.Embedded codeRemoving the UTM, hashes, converting URL to bytes, checking if a tip for the same URL already exists and is active, if not the button is available.
    2.Connecting to PolkadotJS extensionIf none is present, offer to install it. If allowed, a popup asking to select an account. If denied, cancel all. Offer two options: propose a tip or donate directly (text is customizable).

    Milestone 2โ€‹

    • Estimated Duration: 1 month and 1 week
    • Costs: 0.5 BTC
    NumberDeliverableSpecification
    1.Propose tipInform user of the funds needed for tip proposal (deposit and transaction fee). If a user is a Council member ask for the amount and create a new Tip. If a user is not a Council member, create a new Tip entry without specifying the amount (only Council members are allowed to do so). Allow user to attach a message. Disable button and link to tips page in treasury after Tip is created.
    2.Donate directlyAsk the user for an amount to donate and allow him to enter a custom note.
    3.TestingWe will conduct testing of the developed functionalities on Westend testnet.
    4.Article on MediumAfter finishing with development and testing we will publish an article on Medium describing our work done for the project, and a tutorial on how to integrate it into existing websites.

    Additional Informationโ€‹

    • Are there are any teams who have already contributed (financially) to the project? No.
    • Have you applied for other grants so far? We have received funding and completed Ink! Remix plugin.
    - + \ No newline at end of file diff --git a/applications/Knowledge-Oriented-Framework.html b/applications/Knowledge-Oriented-Framework.html index e725b901d87..c3203564138 100644 --- a/applications/Knowledge-Oriented-Framework.html +++ b/applications/Knowledge-Oriented-Framework.html @@ -4,7 +4,7 @@ A Knowledge-Oriented Approach to Enhance Integration and Communicability in the Polkadot Ecosystem | Web3 Foundation Grants - + @@ -16,7 +16,7 @@

    Contactโ€‹

    Team's experienceโ€‹

    Both applicants worked as Research Scientists at IBM for 7 years. Earlier, Dr. Moreno (full CV on [1]) was a postdoctoral researcher at CWI (Centrum Wiskunde & Informatica) in the Netherlands, and worked at the Pontifical Catholic University of Rio (PUC-Rio) in Brazil. Dr. Brandรฃo (full CV on [2]) worked at the TecGraf Institute, from PUC-Rio, during his doctoral studies. The team has published multiple research papers and patents, their background includes Web3, AI, Knowledge Engineering, Distributed and Decentralized Systems, Multimedia and Hypermedia Systems, Human-Centered Computing, among other research topics.

    For a complete list of peer-reviewed published papers and granted patents, please visit the following google scholar links

    Team Code Reposโ€‹

    MOBR Systems:

    Our personal accounts:

    Team LinkedIn Profiles (if available)โ€‹

    Google Scholar Profiles (Or other research indexer profile, ex. Researchgate)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Not initiated yet.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Literature review and conceptual framework specificationโ€‹

    Our approach will begin by conducting a comprehensive literature review to identify key concepts and principles in ontologies for blockchains. This includes studying the existing applications and ontological frameworks that have been developed for blockchain systems, as well as other relevant research in the fields of symbolic representation

    Once the key concepts and principles have been identified, the next step is to specify a conceptual framework that incorporates and relates these concepts and principles. This framework will be designed to express the fundamental entities and relationships that govern the Polkadot ecosystem, and it will be flexible enough to accommodate the ongoing evolution of the technology.

    NumberDeliverableSpecification
    0a.Copyright and LicensesMIT
    0b.Documentation/TutorialWe will provide a PDF document identifying and reviewing related work, concepts and principles in blockchain ontologies. For the ontology, the specification will be delivered as an OWL file with formal description of the Polkadot ecosystem abstractions.
    0c.MethodologyPDF document detailing how we carried out a systematic review of related blockchain ontologies, and the correlation with the main abstractions of Polkadot's conceptual framework.
    0d.InfrastructureWe will provide the list of all infrastructure requirements (text editors with proper versions, software packages, data packages, etc) that can be used to verify the deliveries with this milestone.
    0e.ArticleWe will write a draft article (along with source code) explaining what was achieved in this milestone.
    1.Literature surveyDocument identifying and reviewing related work, concepts and principles in blockchain ontologies
    2.Conceptual frameworkOntology in OWL format with formal description of the Polkadot ecosystem

    Milestone #2 โ€“ Case study for query engineโ€‹

    With the conceptual framework specified and developed, the next step will be applying it to a specific Polkadot-related use case scenario. This includes conducting a case study to explore the future application of the ontological framework to support building a controlled natural language (CNL) and a query engine in Polkadotโ€™s multi-chain ecosystem.

    NumberDeliverableSpecification
    0a.Copyright and LicensesUnlicense
    0b.Documentation/TutorialWe will provide a PDF document describing a use case to the future application of the ontological framework supporting the building of a controlled natural language (CNL) and a querying engine in Polkadot's multi-chain environment.
    0c.MethodologyThe use case will be developed based on our expert perspective and also requirements identified from the engagement with other blockchain experts. That is, the requirements for the query engine will be grounded in real-world experience needs.
    0d.InfrastructureWe will provide the list of all infrastructure requirements (text editors with proper versions, software packages, data packages, etc) that can be used to verify the deliveries with this milestone.
    0e.ArticleWe will write a draft article explaining what was achieved in this milestone.
    1.Case studyDocument describing case study on conceptual framework application with query engine

    Milestone #3 โ€“ Polkadot team brainstorming / workshopโ€‹

    An important aspect of creating an ontology is to engage with experts from application domains to gain their insights and perspectives. This engagement helps to ensure that the ontological framework is grounded in real-world experience and reflects the current understanding of representative personas in the applied fields. In this sense, a key step of the proposed approach is to present and discuss the ontology with the Polkadot team.

    NumberDeliverableSpecification
    0a.Copyright and LicensesCC BY 4.0
    0b.Documentation/TutorialWe will provide two PDF documents, one reporting scientific and technical findings and the other presenting reflections over the discussed content and action items
    0c.MethodologyThe methodology for the team discussion will be loosely based on a Design Thinking process. We will guide the team during discussion in order to extract relevant feedback from experts. The idea is to carry this activity remotely.
    0d.InfrastructureWe will suggest tool options for carrying out the collab session. That can be Mural or other equivalent free cloud collaborative tool available (e.g. Google Drive, MS Teams).
    0e.ArticleWe will write a full article detailing what was achieved in the project. The article will have an acknowledgment in the body of it stating the research was supported by Web3 Foundation. It will be public available on arXiv.org and submited to listed scientific venues
    1.Presentation deckSlide deck with reflections over the discussed content and action items

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Web3 Foundation Website

    We have work in progress assets being developed in our recently founded startup. More info can be found at: https://mobr.ai

    We also previously developed a technology that became widely adopted within IBM Research. It is a toolset to deal with knowledge engineering and ontology construction. More info can be found here:

    1. https://github.com/ibm-hyperknowledge
    2. https://ibm-hyperknowledge.github.io/possibility-link-demo-iswc2022/

    We have already submited proposals to Waves and VeChain grant programs.

    - + \ No newline at end of file diff --git a/applications/Koiverse.html b/applications/Koiverse.html index 2d0b36ba2b7..298ffe54459 100644 --- a/applications/Koiverse.html +++ b/applications/Koiverse.html @@ -4,13 +4,13 @@ Koi Metaverse | Web3 Foundation Grants - +
    Skip to main content

    Koi Metaverse

    Project Overview

    Overviewโ€‹

    Introductionโ€‹

    Koi Metaverse aims to unlock the next-gen GameFi metaverse economies and it is building the digital collectibles platform for virtual GameFi NFTs. It is a fish collection blockchain game that combines token economy and NFT assets. It consists of a series of smart contracts, and all of the in-game assets belong to its players. Players can play to earn by collecting high mining power fish and growing them, creating a positive self-circulation.

    If pure-bred mining fish is reproduced, you can lock it into the pictorial book to mine the governance token, and use it to participate in the other DeFi activities. Koiverse creates a variety of NFT assets in the form of fish images and aims to become the BearBrick in the blockchain GameFi space and the brand new Axie Infinity on the Polkadot network.

    Team Interestโ€‹

    Our team has more than 10 years of game development experience and 3 years of blockchain game development experience. The number of accumulated registered users in the previous games is over 50 million globally. The highest number of active unique users exceeded 1 million. Koi team is also experts in innovative gaming mechanisms, sidechain implementation, tokenization economics and decentralized wallet integration.

    We are creating new kinds of virtual assets on Blockchain. Certainly we are the true Metaverse believers and builders who have strong motivation to unlock the Next-Gen GameFi Metaverse Economies. In Metaverse powered by Blockchain, we have seen the following core disruptive innovations:

    • Blockchain infrastructure leads to the property rights revolution. With blockchain, we can imagine a world in which contracts are embedded in digital code and stored in transparent, shared databases so that everyone could have the real ownership of properties.
    • Non-Fungible Token (NFT) changes the types and rules of games. NFT is a new form of unique digital asset designed to show someone has ownership of a unique virtual asset. It will become a new trend of virtual assets for creating, trading and collecting.
    • Tokenization and crypto creates brand-new business models. Crypto unlocks new rules of business models in game, like the concept of Play-to-Earn (P2E) which created new types of jobs and professions in digital Metaverse economies.

    Project Detailsโ€‹

    Project Architectureโ€‹

    The technical architecture of the project:

    The gaming NFT protocols and Dapp consists of:

    • NFT Lottery Draw (NFT function)
    • NFT Auction Sale (NFT function)
    • NFT Minting (NFT function)
    • Fish NFT (game asset)
    • Fish Tank NFT (game asset)
    • Fish Breeding (game function)
    • Fish Mining (game function)
    • Pictorial Book Mining (game function)

    NFT Functionsโ€‹

    NFT Lottery Draw

    Typesโ€‹

    • name - activity name
    • nft - nft contract address
    • noin - coin contract address
    • price - fees needed to run lottery
    • total - total number of lotteries
    • remain - remnant quantity
    • limit - nft limited per person
    • startTime - activity start time
    • endTime - activity end time

    Functionsโ€‹

    • lottery() - lottery

    NFT Auction Sale

    Typesโ€‹

    • name - activity name
    • nft - nft contract address
    • coin - coin contract address
    • startTime - activity start time
    • endTime - activity end time

    Functionโ€‹

    • fishList() - read the fish list in the auction activity
    • fishGeneList() - read the fish gene list in the auction activity
    • bid() - users submit bids
    • refreshFishList() - refresh the fish list
    • getMyFish() - users acquired the bade fish

    NFT Minting

    Typesโ€‹

    • nft - nft contract address
    • coin - coin contract address
    • totalNft - current NFT quantities in mining pool
    • totalNftPower - current total NFT mining power in mining pool

    Functionโ€‹

    • myNft() - read staked NFT
    • getNft() - read one nft info
    • earned() - read mining profit
    • stakeNft() - stake nft
    • withdrawNft() - withdraw the staked nft
    • withdrawNftAll() - withdraw all staked nfts
    • getReward() - acquire mining reward

    NFT Assetsโ€‹

    Fish NFT

    • Each fish is composed of 14 genetic components: shape, color, pattern, eyes, mouth, pectoral fin, dorsal fin, caudal fin, decorations, invisible components, and breeding sequence.
    • The highest mining power of the fish is determined by the sum of each partโ€™s mining power, gear buff, and the cultivation level.
    • When certain fish genes match, a mining power bonus and pictorial books will be activated.

    Fist Tank NFT

    • The fish can grow up in fish tanks. The cultivation time cycles are 10 days, 30 days, and 90 days, which respectively come with a maximum 30%, 120%, and 400% mining power increase.
    • Each fish tank may have unique features and different capacities.
    • Fish tanks and fish cannot be sold during the lock period.
    • In the cultivation time, the fish cannot engage in mining or breeding.

    Game Functionsโ€‹

    Fish Breeding

    • The only way gamers can mint new fish NFT assets is to breed fish. The cost of the very first breeding is determined by the average mining power P of the parent fish and the average ecological mining power AP. The cost F=K*P/AP, tentatively K = 500.
    • The progeny genes are inherited from the parent fish genes, and each parent has a 50% chance to propagate its genes.
    • The scarcity of the fish gene is classified as normal, scarce, epic, and legendary. The scarce, epic, and legendary genes, respectively, have a 50%, 35%, and 25% chance to be inherited. There is a 1% chance to increase the gene scarcity level, or the genes will mutate into random and normal genes.

    Fish Mining

    • All fish with mining power can obtain reward tokens every day proportionately. The amount of reward token available to mine per day (M) is related to (F) the total sum of the fish (mining power>0) participating in mining. M=K*F^0.9๏ผŒK as a constant, tentatively K=50.
    • Only the fish that are not being sold, bred, or locked by pictorial books can participate in mining.
    • Every time a fish participates in mining, it loses 4% of the mining power until it reaches 0.

    Pictorial Book Mining

    • A gamer can activate a pictorial book when acquiring some pure-bred fish with the built-in suites.
    • You can start mining reward tokens if you lock the right fish into the pictorial book. The locked fish must have full mining capacity.
    • There are 4 levels to each fishโ€™s pictorial book: 0, 10, 30, and 90 growing up days in fish tanks.
    • When level 2, level 3 or level 4 fish are locked, the system automatically releases the low-level fish previously locked. You can only lock one fish, and you can double your points after collecting all level 4 fish, in all the colors, with the same suit.
    • The mined reward tokens are distributed according to the points and settled once a day. At the same time, the mining power is reduced by 4%. If the mining power is 0, then no more mining can be done.

    Front Endโ€‹

    Ecosystem Fitโ€‹

    Existing GameFi NFT projects mainly focus on the public chains, games and collectible publishing, Marketplace, etc. Popular projects working in this segment include Axie Infinity (NFT game), Chiliz (sports-oriented underlying public chain), Flow (general NFT issuance public chain), and Opensea (general marketplace). We will add more game functions than Axie Infinity and build on the Substrate framework. We also can collaborate with native Polkadot NFT marketplace RMRK and NFTMart.

    Team

    Team Membersโ€‹

    • Anetta Sultygova - Project Lead
    • Euglena Liu - Product Manager
    • Yuan Li - Full-stack Developer
    • Tao Liu - UI/UX Designer
    • Jelly Ji - Front-end Developer
    • Hongfeng Liu - Artistic Designer
    • Vladan Falcic - NFT Advisor

    Team Websiteโ€‹

    • Koi Metaverse Ltd. is a company registered in the British Virgin Islands.

    Team Experienceโ€‹

    Anetta Sultygova

    • 8-years project management and investing experience in the blockchain industry. She is good at structuring and organizing the teams around the projects.
    • Seasoned experience in NFT ecosystem and marketing strategy.
    • Marketing and community management in MILC, Realm, BloXmove and Metis etc.

    Euglena Liu

    • Product lead of fishchain and Paopaoyu (Top 10 web game on Renren โ€œChinese Facebookโ€).
    • 8-years gaming product design experience in the game industry.
    • Early player and investor in Axie Infinity ($AXS).

    Yuan Li

    • 10-years full stack software development experience
    • 5-years blockchain and smart contract development experience
    • Over 15 years of experiences in development and Management
    • Expert in Ethereum, Polkadot, Neo and other smart contract platforms.

    Tao Liu

    • 3-years of product management experience in the game industry.
    • 20-years of art design and animation experience.
    • Former Front-end Director of LightInBox, Fishchain and ShopperPlus.

    Vladan Falcic

    • Blockchain and crypto enthusiast, he entered the crypto space back in 2014 and was mostly involved in early stage projects.
    • In 2016, he started working with different projects, improving their marketing and establishing valuable partnerships.
    • As the CEO of Squares Capital, he is working with several startup projects, advising them, improving their marketing and building the community.

    Jelly Ji

    • 5-years experience in html5 and front-end stack development.
    • Expert in mobile game development, H5 game development and blockchain game development
    • Bsc in Information Management and Information System of Beijing University of Posts and Telecommunications

    Hongfeng Liu

    • Senior UI and animation designer.
    • 3-years experience in blockchain game development

    Team Code Reposโ€‹

    Team Linkedin Profilesโ€‹

    Development Roadmap

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-time equivalent (FTE): 4 FTE
    • Total Costs: 12,000 DAI

    Milestone 1 โ€”โ€” Koi Metaverse NFT Modules and Assetsโ€‹

    • Estimated Duration: 3 months
    • FTE: 4 FTE.
    • Costs: 12,000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation, video, medium articles & start creating the lightpaper of the project.
    0c.Testing GuideThe code will have proper unit-test and guid coverage for Koi Metaverse modules
    1smart contract: NFT Lottery DrawNFT lottery contract include: lottery function implemented by ink
    2smart contract: NFT Auction SaleNFT auction contract include: fishList, fishGeneList, bid, refreshFishList, getMyFish functions implemented by ink
    3.smart contract: NFT MintingNFT minting contract include: myNft, getNft, earned, stakeNft, withdrawNft, withdrawNftAll, getReward functions implemented by ink
    4.smart contract: Fishfish contract include: gene, birthday, power, reproduction, growth implemented by ink
    5.smart contract: Fish Tankfish tank contract include: capacity, totalPower, fishList implemented by ink
    6a.UI mock-upsThe UI design of product frontend and product workflow.
    6b.Fish Genes and ImagesThe UI design and gene system of fish NFTs.
    7.Front endImplement web front-end based on react.js and polkadot.js. Modules include: NFT Lottery Draw, NFT Auction Sale, NFT Minting, Fish and Fish Tank. Fish Mining, Fish Breeding.
    8.TestWe will provide a dockerfile to demonstrate the usage of our modules.

    Community Engagementโ€‹

    • Play to Earn: Koi Metaverse will also adopt the P2E model to inspire players of GameFi games. Through P2E, players can share the growth and development dividend of the Koi Metaverse.
    • Genesis Collection: Koi NFTs Genesis Collection Offering โ€” Phase 1: Newborn Genesis Collection is an effective way to start a project and have public awareness.
    • GameFi Communities: Koi Metaverse will collaborate with game P2E communities, including Yield Guild Games (YGG), A16, etc. to complete users acquisition and users growth.

    Future Plans

    Our project plans to become a parachain for the Polkadot network, which provides benefits from shared security and communications (XCMP). We will launch our game application Koi Metaverse first to complete the first adoption and then open our infrastructure layer Koi Network to support more game Dapps. The Koi Network will support marketplace, NFT DeFi, GameFi Hub and Cross-chain Gateway, etc.

    Additional Information

    - + \ No newline at end of file diff --git a/applications/Lastic.html b/applications/Lastic.html index 90c9bab7dd6..5ba09e203d2 100644 --- a/applications/Lastic.html +++ b/applications/Lastic.html @@ -4,7 +4,7 @@ Lastic | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ Instantanious coretime sales

    This mockup/UI design features the design of the page primary market for the Bulk sales. Primary market bulk sales

    **** We will create a frontend allowing users to see the current state of Coretime on Polkadot, including, but not limited to: Number of cores available, Number of cores assigned, Number of legacy cores assigned, Number of blocks in the Instantaneous Pool, Number of Cores parititioned, etc. Note: this will be made using dummy data. |

    Future Plansโ€‹

    On the Horizon: Frontend Development with Blockchain Integration:โ€‹

    Initiation Timeline: Post the release of W3F's branch on the Rococo testnet, followed by data availability for real-time functionality testing. Estimated commencement: 4 months post-Rococo testnet launch, with the mainnet integration slated 3-6 months thereafter.

    Developmental Milestones:

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Additional information:

    - + \ No newline at end of file diff --git a/applications/Libra.html b/applications/Libra.html index 0c549facbd9..6477f6717f6 100644 --- a/applications/Libra.html +++ b/applications/Libra.html @@ -4,7 +4,7 @@ Libra - Decentralized Payment Network | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ LRP Protocol helps the buyer to purchase with confidence. It also helps the seller to increase conversion and do proper order handling.
    Resolvers Network leverages the power of blockchain and the community to resolve transaction conflict in a quick and efficient method without involving any financial institution.

    Libra bridges the gap between blockchain and eCommerce to enable all people to exchange value and transact globally, securely, at significantly lower cost, and more inclusively than traditional financial systems allow.

    Project Detailsโ€‹

    The project's scope is to build three core components that define the foundation of Libra Network: LRP protocol, Resolver Networks, and Javascript SDK. From these components, people can easily integrate the cryptocurrencies payment to their business while their customers are protected by Libra Network.

    LRP protocolโ€‹

    LRP protocol allows buyer and seller to make a p2p payment while the cryptocurrencies of the buyer have locked until the seller delivers the order. The below diagram will explain the logic of LRP protocol when the sellers integrate with Libra Network.

    Project Libra-LRP Protocol

    For the LRP protocol, the data model for LRP protocol should be generic and flexible for any use cases. Besides, it should be small to store on-chain but need to provide enough information if needed (e.g. dispute case).

    Data modelโ€‹
    {
      "id": "uuid",
      "payer": "5ERjkQVj8M7v5UVZQ8qTbZ2qb1o5TgNXq9tXt2BsWF9jBpDu",
      "payee": "5GWeq3dqEp4gzZS8jnEzTdTtPYxAp4AMcvjdhJdse4nU8zb2",
      "amount": 1000,
      "currency": "LIBRA",
      "description": "This is charged by @Scale Tech",
      "status": "pending",
      "receipt_hash": "b55126a39f9b1170a32e6f61e4a694c45235e5ac11c05ecd6ff6395de6a11187",
      "created_at": 1640761503329,
      "updated_at": 1640761504444
    }
    State transitionโ€‹

    state-transition

    Resolvers networkโ€‹

    Although most payments can be processed on the LRP protocol, disputes are inevitable and they need to be resolved by humans. The estimated dispute rate of the traditional payment platforms is about 2%. A dispute occurs when buyer and seller cannot decide the outcome of the payment by themselves and the fund is still locked in the LRP protocol. We considered many of ideas and we believe the resolvers network is the best way to implement a decentralized dispute resolution.

    The dispute can be issued by the buyer and the seller can appeal the dispute. Both dispute and appeal action will need the fee estimated at $10 pay by Libraโ€™s token. A dispute will be resolved by a random resolver on the resolver's network. To become a resolver, a person needs to stake a required amount of Libraโ€™s token or create a candidate application and receive enough nominations from the community. 50% of the dispute fee is distributed to resolvers and the counterpart share to the nominators of the resolver.

    In the case that buyer or seller does not accept the final decision from the resolver, they will have 72 hours to decide to escalate the dispute or not. To request to escalate, they need to deposit $20 and the resolvers network will pick two more resolvers to re-investigate the dispute. After the investigation, the resolvers will vote for the final decision. If the final decision is different from the first resolver made, the first resolver will be slashed $20 to cover escalate fee and decrease the credibility. If the credibility is too low, the resolver will be banned permanently on the network.

    This diagram shows the whole dispute process

    Project Libra- Dispute process

    SDKโ€‹

    The SDK is indispensable for the productโ€™s adoption. It should be developer-friendly and easy to integrate with a few lines of the code. The interface of the SDK is listed below.

    Install

    npm install libra-sdk
    import Libra from "@libra-sdk";

    const libra = new Libra(config);

    Checkout

    Create a payment with the SDK

    const payment = libra.createPayment({
     payee,
     amount,
     currency,
     description,
     receipt
    });

    Cancel a payment (before the seller accept)

    libra.cancelPayment(payment.id)

    Complete a payment

    libra.complePayment(payment.id);

    Dispute a payment

    libra.dispute({
     paymentId: payment.id,
     evidence: {...}
    });

    libra.escalateDispute(disputeId);

    Sellerโ€™s dashboard

    Get payments

    libra.getPayments();

    Accept or reject a payment

    libra.acceptPayment(paymentId);

    libra.rejectPayment(paymentId);

    Confirm full fill the order

    libra.fullFill(paymentId);

    Appeal a dispute

    libra.appeal(disputeId);

    libra.escalate(disputeId);

    Governance dashboard

    Setup identity

    libra.setIdentity({
     displayName,
     legalName,
     email,
     website,
     ...
    });

    Apply resolver

    libra.apply({
     role: "resolver",
     application: {...},
     deposit: 100000,
    });

    Nominate

    libra.nominate({
     address,
     amount,
     ...
    });

    Resolve a dispute

    libra.approveDispute(disputeId);
    \\ OR 
    libra.rejectDispute(disputeId);

    Resolve an appeal

    libra.approveAppeal(disputeId);
    \\ OR 
    libra.rejectAppeal(disputeId);

    Ecosystem Fitโ€‹

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    (We're in the process of registering the legal entity)

    Team's experienceโ€‹

    AtScale is a team specialized in blockchain development. We aim to rely on blockchain technologies to solve real-world problems and facilitate blockchain-based products to mass adoption.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Due to privacy concerns, the team information will provide in private by email if requested.

    Development Status ๐Ÿ“–โ€‹

    Libra is founded and developed in the Polkadot APAC Hackathon 2021. We already built a proof of concept application and here is our hackathon submission:

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 - LRP Protocol Implementationโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationThe documentation includes: general concepts explanation, setup and run node guide, RPC specs
    0c.TestingAll of the code will be covered by unit and integration test suites with the testing instruction.
    0d.Live testnetThe live testnet with a few nodes and public RPC endpoints to test or connect more nodes.
    1.Substrate module: LRP palletThe LRP protocol implementation.
    2.Substrate module: Currencies palletThe extended module of ORML currencies allows creates and manages currencies by bonding some native tokens.
    3.Substrate based chainThe integration LRP protocol with substrate chain.

    Milestone 2 - Resolvers Network Implementationโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationThe documentation includes: general concepts explanation, setup and run node guide, RPC specs
    0c.TestingAll of the code will be covered by unit and integration test suites with the testing instruction.
    1.Substrate module: Identity palletThe identity pallet handles more specific fields of on-chain identity including identity credibility which is calculated by the actions that identity made on-chain such as transactions, dispute rates, dispute decisions... We will also add domain verification to prevent identity impersonation.
    2.Substrate module: Resolvers palletResolver's application and nomination logic.
    3.Substrate module: Dispute resolution palletDispute resolution implementation.
    4.Substrate chain integrationIntegrate identity pallet, resolvers pallet and dispute resolution pallet with current chain.

    Milestone 3 โ€” Javascript SDK Implementationโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationThe documentation is about the basic concepts, functions specs, and samples of how to use SDK to integrate with the Libra Network.
    0c.TestingThe unit tests and integration tests will cover at least 70% of the code.
    0d.CI/CDThe lint, tests, and release will run automatically on the Github actions. If a new version is available, it will be published on NPM.
    1.SDKThe set of Javascript libraries and utils that help front-end developers easy to integrate their web app with the Libra network. The specification of the SDK is listed in the project detail session.

    Future Plansโ€‹

    Once three components (LRP protocol, Resolvers Network, JS SDK) are done, we stand on a solid foundation and are ready to scale up.

    In the short term, we plan to launch the validation and testing phase:

    For the long term plan, we will:

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/LightSpell-proposal.html b/applications/LightSpell-proposal.html index ef46e0a97d4..9781db543af 100644 --- a/applications/LightSpell-proposal.html +++ b/applications/LightSpell-proposal.html @@ -4,7 +4,7 @@ LightSpell XCM API by ParaSpellโœจ | Web3 Foundation Grants - + @@ -32,7 +32,7 @@ | Support for transfers: | In three different scenarios | In two scenarios | | Support for local network configuration: | Fully implemented example network configuration that uses maintained Parachain-launch library | Not implemented | | Support for HRMP channel opening/closing: | Fully implemented | Not implemented |

    Unlike the already mentioned "Morph" platform ParaSpell focuses more on developers. ParaSpell features complete network install and startup configuration in one single command. This automatization ensures, that developers do not need to do any extra tasks when they wish to run development nodes locally. ParaSpell also allows developers to open and close HRMP channels between Parachains they connected. Like "Morph", ParaSpell can also transfer fungible tokens in three scenarios. From Parachains to Relay chain, from Relay chain to Parachains & from Parachains to Parachains.

    We are currently in talks with several Parachain teams that like the idea of unified SDK for XCM transfers as much as we do. SDK that unifies XCM can be very helpful for the entire ecosystem in our opinion. With the introduction of XCM API, this improves even further.

    Our target audiences are Web3 projects and starting/current blockchain developers.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Duลกan Morhรกฤ - Student, project Founder & Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava

    Michael Absolon - Student, XCM SDK & XCM API Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava

    Contactโ€‹

    Team's experienceโ€‹

    Team Code Reposโ€‹

    Team Github Profiles ๐Ÿง‘โ€๐ŸŽ“โ€‹

    Team LinkedIn Profiles ๐Ÿง‘โ€๐ŸŽ“โ€‹

    Development Status ๐Ÿ“–โ€‹

    The new XCM-API is in development and we are currently searching for the fastest server with the lowest cost requirements.

    SDK is currently released into the main and is in a version that is fully operable. There are still some tweaks we plan to add and make, they are not part of this grant however. UI-V2 currently runs on state-of-the-art technology version VueJS 3 and the newest version of Nuxt. It deprecated V1 and introduced a much smoother interface and modules brought from the sub-scaffold template ParaSpell contributed to. Docs are currently in ready state but there is still some tweaking to do.

    Sidenote: We have recently developed an article about Polkadot & Paraspell called Enhancing XCMP Interoperability Across Polkadot Paraverse and it was accepted to the International IEEE BCCA 2023 conference held in Kuwait.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 - Create LightSpellโšก๏ธ: XCM-APIโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both readme.md and official docs documentation
    0c.Testing and Testing GuideTesting guide will be mentioned in official docs & core unit tests will be provided
    0e.Create Medium article about development of LightSpellAdd article covering new features & improvements brought with LightSpell
    1.aIntegrate API for XCM functionalityUse Nest.js to integrate core XCM SDK functionality to send XCM messages
    1.bIntegrate API for Asset functionalityUse Nest.js to integrate core XCM SDK functionality to do Asset operations
    1.cIntegrate API for XCM Pallets functionalityUse Nest.js to integrate core XCM SDK functionality to query XCM Pallets of different Parachains
    1.dIntegrate API for HRMP functionalityUse Nest.js to integrate core XCM SDK functionality to open/close HRMP channels
    2.Integrate token authentificationIntegrate token authentification with limited requests to remove the possibility of DDOS (Bigger request limit can be requested for free via email provided in docs)
    3.aAdd core Integration testsAdd core Integration tests to ensure everything is working together as expected
    3.bAdd core Endpoint (e2e) testsAdd core endpoint tests to let the user try to use API without writing any code and also to demonstrate if API works
    4.Integrate LightSpell into ParaSpell docsAdd comprehensive guide for every feature that API will offer link

    Future Plans ๐Ÿ”ญโ€‹

    Once everything will be implemented according to the proposed plan application will still be under constant improvement as technology will progress. For example, once the XCMP protocol will be released we wish to deprecate the HRMP protocol we currently use for channels.

    The project goal is that XCM-SDK & XCM-API will serve dApp developers and UI will teach new substrate developers to use XCM and will serve existing substrate developers to test their freshly baked Parachains.

    The newly added XCM-API will simplify XCM-SDK integration and will be much faster than integrating XCM-SDK into dAPP directly. Both repositories will remain dependent on each other. Further maintenance funding for servers and keeping XCM API up to date will be requested from Polkadot treasury.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Personal recommendation

    Project achievements in chronological order โŒ›๏ธโ€‹
    - + \ No newline at end of file diff --git a/applications/LiisaPortfolioTracker.html b/applications/LiisaPortfolioTracker.html index fad98ed3e1e..7dc11b18941 100644 --- a/applications/LiisaPortfolioTracker.html +++ b/applications/LiisaPortfolioTracker.html @@ -4,7 +4,7 @@ Polkadot NFT Portfolio Tracker by Liisa - MVP | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ We have developed and deployed the Liisa NFT analytics platform, currently supporting ETH and MATIC NFTs, including both off-chain and on chain data visualizations and KPIs

    Are there are any teams who have already contributed (financially) to the project? Yes, our Incubator and VC

    Have you applied for other grants so far? No

    - + \ No newline at end of file diff --git a/applications/MAP-Bridge.html b/applications/MAP-Bridge.html index dffd8da0444..81d8f9d9332 100644 --- a/applications/MAP-Bridge.html +++ b/applications/MAP-Bridge.html @@ -4,7 +4,7 @@ Map Bridge | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Map Bridge

    • Proposer: zcheng9
    • Payment Address: 1CFM6QDvxwXEV3dUN9x2ftqq4rwAfkxN9W
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    This project deliver a bridge relay to connect Polkadot and other PoW chains(Ethereum specific in this proposal). The bridge relay can provide an non-interactive, succinct proof of POW of a bridged chain based on ULVP (ultra-light verification protocol) . And based on such proof, it can further verify inner state of certain account or transaction inclusion proof.

    Project Descriptionโ€‹

    • MAP-Bridge would implement a new data structure called merkle mountain range(MMR) which contain the information of all confirmed block headers. And the root of MMR would be include in the new mined block somewhere.
    • In order to achieve this, we have to include the most recently MMR root in the new mined blocks in both Ethereum and Map bridge(parachain in Polkadot). For MAP bridge we can simply include it in the block header. For Ethereum, we have three possible way: firstly we could propose a EIP to ensure block header of Ethereum including MMR root; secondly we could deployed a contract in Ethereum to maintain most recent MMR root; and the last choice is to use CHT root in Ethereum instead of MMR root to do the verification work. In our proposal, we prefer to use the second method.
    • MAP-Bridge is build on a verification module called Ultra-Light Verification Protocol (ULVP). ULVP origins from the paper "Flyclient: Super-Light Clients for Cryptocurrencies". Any node could verify the existence of any transaction or the balance of any account with very limited data through ULVP compare to SPV.
    • The verification mechanism is as following:
    • The verifier connects some randomly selected full node in the destiny chain (at least one of these must be honest) and request them sending their tail blocks and corresponding proofs. Then the verifier validates the proof with the longest tail block. If it is a valid proof, the verifier would select this tail block as his choice and save it for next step. Otherwise he would drop this full node and check the second-longest tail block. The verifier continues this steps until it finds the tail block with valid proof. Based on our assumption, he connects at least one honest prover. Thus this algorithm would eventually find the honest longest tail block.
    • The verifier connects some other randomly selected full node in the destiny chain and obtains the block header in specified height and the corresponding MMR branch proof of this header upon to the most recent MMR. The verifier has the root of the most recent MMR which include in the tail block header. He could then validate the MMR branch proof based on it. If he get the valid block header he can save it for next step, otherwise keep doing it for another full node.
    • This step is similar to SPV. The verifier connects some other randomly selected full node in the destiny chain. The he could request them sending the detail of the transaction in specified height with the merkle branch proof up to the transaction root in block header( for state of any account is similar since the state root is stored in the header too). After that he could check the validity of the merkle proof. If the check passed, he could be sure that this transaction is indeed included in the destiny chain. If not, he could try another full node. If none of them could provide valid proof, he would know this transaction is not included in the destiny chain yet.
    • More details of ULVP could be found Here.

    Ecosystem Fitโ€‹

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Chan
    • Seabook
    • LYU.L

    Team Websiteโ€‹

    MAP labs

    Team's experienceโ€‹

    • Dr. Chan received the Ph.D. degree in applied mathematics from Illinois Institute of Technology, Illinois, USA in 2017. His research interests include consensus algorithms, P2P protocol, cryptography, blockchain interoperbility.
    • Dr. Seabook is based in Australia and get his Blockchain PhD. from Australian Deakin University. He has more than 15 years of professional software design, architecture and development experiences. He has worked as Chief Technology Officer and Senior Architect in Telstra, Accenture, Qantas, eBay and Citibank.
    • LYU.L holds a master degree from Tsinghua University and also a member of China national blockchain and distributed ledger committee. He has more than 13 years of experience inlarge-scale computing and algorithm, with many patents such as consensus algorithm and blockchain transaction.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 month
    • Full-time equivalent (FTE): 3
    • Total Costs: $ 2 BTC.

    Milestone 1 Implement Substrate MMR Moduleโ€‹

    • Estimated Duration:1 month
    • FTE: 3
    • Costs: 1 BTC In this milestone, we will build Substrate-based MMR for MAP bridge and also provide the MMR proof generating and verifying method in runtime module . This is a preliminary for ULVP module which can verify the validity of tail block of a certain blockchain carry heaviest proof of work. Furthermore, we will implement the block header storage functionality. This would make the blockchain could manage the MMR๏ผˆsuch as appending new blocks into blockchain and retrieving the MMR based on the MMR root in a certain block header, etc. ๏ผ‰. We will provide proper unit-test for this milestone.
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.TestingThis milestone will have unit-test for MMR trie, MMR proof runtime api and MMR manager. In the guide we will describe how to run these tests.
    1.MMR Trie StructureWe will implement this MMR Trie based on the exist Library. We will fork this Repo and realize all the functionality we need based on that. Including customlized field in MMR node, customlized merging method and MMR manager.
    2.Substrae MMR proof runtime moduleDeliver MMR proof verification in substrate SRML runtime and provide the ability to generate and manage MMR.
    3.AppendBlockAppend the current block as leaf node into MMR. Method signature: Public bool Appendblock(Header blockheader)
    4.RetrieveMMRRetrieve the MMR based on the root provide. Method signature: Public *MMR RetrieveMMR(Hash root)
    5.GenerateProofGenerate the merkle branch proof in MMR. Method signature: Public Proof GenerateProof(MMR mmr, Leafnode leaf)
    6.VerifyProofByRootVerify if the proof is consistent with root. Method signature: Public bool VerifyBlockByRoot(Hash root, *Proof proof)

    Milestone 2 Integrate ULVP module into substrateโ€‹

    • Estimated Duration: 2 month
    • FTE: 3
    • Costs: $1BTC In this milestone, we will further implement the ULVP module and some add-on module. This would involving generating and verifying succinct proof, specifying the cross-chain transaction, implementing the cross-chain transaction pool, building P2P network based on libp2p. Once this milestone is accomplished, the whole feature of ULVP module is complete and could be used to verify inner state of certain account or transaction inclusion proof for other blockchain. We will include proper test and documentation for this milestone
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can import the protocol.
    0c.Testing GuideThis milestone will have unit-test for ULVP module to ensure functionality. In the guide we will describe how to run these tests.
    1.ULVP moduleImplement ULVP module to retrieve the transaction or state from another blockchain. We will realize all the three verification steps we mention above using the Substrate MMR module we finished in milestone 1.
    2.P2P Relay Substrate moduleImplement P2P Relay Substrate module which provide the functionality which could discover ethereum nodes and connect any ethereum node if the peer manager is not full. Once the connection has established, it use gossip to broadcast MAP parachain block announcement and cross chain transactions to ethereum, and receive message from ethereum. which contains ethereum block announcement, cross transactions, MMR Proof and Receipt Proof.
    3.Cross-chain asset transfer demoRealized a demo to enable token transfer between Polkadot parachain(MAP bridge) and Ethereum testnet. This need first deployed a contract in Ethereum testnet which maintain the MMR root of Ethereum. Next we need to deployed a mint contract in bridge parachain and a lock contract in Ethereum. If user lock some token in Ethereum to the lock contract, any node in the bridge parachain could verify this lock transaction. And the mint contract would mint the token in parachain if the lock transaction is indeed confirmed in Ethereum testnet.

    Future Plansโ€‹

    We plan to extend our bridge to most POW and POS type blockchains in the future. Through our bridge we could link more and more other blockchain systems into Polkadot Ecosystem .

    - + \ No newline at end of file diff --git a/applications/MIXER.html b/applications/MIXER.html index cf78453fb8b..3189c72270c 100644 --- a/applications/MIXER.html +++ b/applications/MIXER.html @@ -4,7 +4,7 @@ Webb Mixer | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ Filip Lazovic Shady Khalifa 1 other member

    Contactโ€‹

    Team's experienceโ€‹

    Our team has deep experience building on Substrate and growing experience building zero-knowledge proof based applications. I have been building on Substrate for 2 years and helped launch Edgeware. Shady worked on Sunshine Protocol as well.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement Substrate Modules and circuitsโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.Substrate module: SparseMerkleTree (SMT)We will create a Sparse Merkle Tree module that will support a standard interface for interacting with Merkle Trees
    2.Substrate module: MixerWe will create a Mixer module that will facilitate a deposit/withdraw functionality for mixing a token.
    4.Substrate chainModules SMT/Mixer of our custom chain will interact in such a way, allowing a user to deposit native tokens into the mixer and withdraw them with a valid zero-knowledge proof.
    5.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain

    Additional details about modules

    Goal

    To build a pallet on top of the zero-knowledge merkle membership pallet that supports the following functionality.

    To build a front-end interface for using this that supports creating and storing the secret data in the browsers local storage.

    https://github.com/kobigurk/wasm_proof

    Tasks

    Pallet:

    Circuit

    Zero-knowledge Circuit

    Merkle Treeโ€‹

    Definitions: Secret Key(S), Public key(P), Nullifier (N), Leaf(L), Hash function(H), Secret Key (SC), Public Key (PC), Merkle Root (R), Merkle Path (MP), Circuit Proof (ZKP)

    Commitments (leaves) in merkle treesโ€‹

    Public variables to Spend (fixed deposit tree)

    Private variables to Spend (fixed deposit tree)

    Public variables to Spend for each input coin (variable deposit tree)

    Private variables to Spend for each input coin (variable deposit tree)

    Public variables to Spend for each output coin (variable deposit tree)

    Private variables to Spend for each output coin (variable deposit tree)

    Tech Stack

    Future Plansโ€‹

    The team's future plans are to build zero-knowledge products with extensible UIs and composable runtime primitives. We want to explore governance in zero-knowledge and we see mixers as being the core primitives towards this pursuit.

    Additional Information โž•โ€‹

    Nope

    What work has been done so far?โ€‹

    Are there are any teams who have already contributed (financially) to the project?โ€‹

    Have you applied for other grants so far?โ€‹

    - + \ No newline at end of file diff --git a/applications/MIXERv2.html b/applications/MIXERv2.html index 045a19dcc31..81c8dcbee53 100644 --- a/applications/MIXERv2.html +++ b/applications/MIXERv2.html @@ -4,7 +4,7 @@ Webb Mixer Extended | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ Shady Khalifa Ahmed Korrim Nathan Barnavon

    Contactโ€‹

    Team's experienceโ€‹

    Our team has deep experience building on Substrate and growing experience building zero-knowledge proof based applications. I have been building on Substrate for 2 years and helped launch Edgeware. We also shipped an initial grant to build out the pallets for native token support using bulletproofs zero-knowledge arguments.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement multi-currency, multi-backend, multi-hash support in Substrate modules and Arkworks mixer circuitsโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.Substrate module: Multi-Asset support for mixerWe will extend the mixer for ORML libraries and pallet-assets libraries.
    1a.Substrate module: ORML supportPlug and play functionality for ORML tokens
    1b.Substrate module: Pallet asset supportPlug and play functionality for Asset module
    2.Substrate module: New ZKP backend supportWe will add new backends to our pallets to allow users more flexibility over their target ZKP system.
    2a.Substrate module: New ZKP backend supportGroth16 style proofs using BLS381, BN254
    2b.Substrate module: ZKP backend supportBulletproof style proofs using Curve25519
    2c.Substrate module: New ZKP hash function supportMore Poseidon configurations, MIMC
    3.Zero-knowledge circuitsWe will create new zero-knowledge circuits for mixer functionality using the Arkworks backend, which allows us to plug and play with different elliptic curves and SNARKs.
    3.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain

    Additional task details

    Pallet:

    Circuit

    Zero-knowledge Circuit

    Merkle Treeโ€‹

    Definitions: Secret Key(S), Public key(P), Nullifier (N), Leaf(L), Hash function(H), Secret Key (SC), Public Key (PC), Merkle Root (R), Merkle Path (MP), Circuit Proof (ZKP)

    Commitments (leaves) in merkle treesโ€‹

    Public variables to Spend (fixed deposit tree)

    Private variables to Spend (fixed deposit tree)

    Other public inputs for fee-based system (for relayers)โ€‹

    Tech Stack

    Milestone 2 โ€” Toolchain: implement relayer and WASM bindings for zero-knowledge gadgets, types API, dApp integrationโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    1.Relayer in RustWe will build a transaction relayer that supports the relaying transactions for a fee and add support for these new pallets.
    2.CLI in RustWe will build out a Rust based CLI for interacting with the mixer
    2a.CLI Support: Note storageCreation and storage of deposit notes handled by the CLI
    2b.CLI Support: Note spendingProof generation and transaction submission to relayers or directly to the chain handled by the CLI.
    3.WASM bindingsWe will build out necessary WASM compatible proof generation code to be reused in the browser for dApp support.
    3a.WASM bindings: Web Worker supportWe will build out a pipeline for integrating this logic into web workers.
    4.UI Support: Multi-Asset supportWe will build out multi-asset support in our UI for mixers of arbitrary token types.
    4a.UI Support: Multi-Asset designsThere will be nicely designed interfaces for utilising multi-asset support.
    5.UI Support: Proof generationWe will integrate WASM based proof generation bindings for generating zero-knowledge proofs in the browser application handled inside web workers.
    6.API Support: TypesWe will package all new types for supporting these pallest in Substrate chains in a well-documented API
    6a.API Support: Usage examplesWe will include examples for connecting to chains with these pallets / types and provide examples for interacting with them.

    Future Plansโ€‹

    The team's plans are to keep extending the mixer to support newer backends and a variety of elliptic curves for asset based applications, governance applications, and interoperable applications.

    Additional Information โž•โ€‹

    What work has been done so far?โ€‹

    Are there are any teams who have already contributed (financially) to the project?โ€‹

    Have you applied for other grants so far?โ€‹

    - + \ No newline at end of file diff --git a/applications/Maki.html b/applications/Maki.html index 271c6a45970..4827760c260 100644 --- a/applications/Maki.html +++ b/applications/Maki.html @@ -4,7 +4,7 @@ Maki | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ While for now I'm unsure the current projects on Polkadot/Kusama needs such mechanism, it is obvious some will need such anti-collusion and anonymous voting for its users.

    Project Detailsโ€‹

    Following the specifications of MACI as linked above, here is an overview of the architecture and core functionalities of Maki.

    Maki is a smart contract that allow its users to vote while making collusion among participant difficult (if the operator is honest) and retain censorship resistance, correct execution and anonymity of votes.

    Maki has two kind of users: one operator and 0..n voter(s) (also called user here under).

    The operator role is to deploy the contract (and publish his public key, known by all), start the sign-up period (which is done when the contract is deployed), process all the voters commands, generate the result of each commands, tally the votes and generate a zk-SNARK proof that the result is valid.

    The voter role is to sign-up for a vote and then vote.

    Secrecy of the votes are possible by using cryptographic operations. As described in the MACI specs, each users and the coordinator have a key-pair used to publish encrypted messages and for the coordinator to decrypt those messages.

    Overview :โ€‹

    Maki's Functions :โ€‹

    signUp allows a user to register for voting by sending his public key to the contract. There is no need for a given user to call this function multiple times.

    publishMessage allows a user to vote. A voter may use this multiple time to change his vote options, as long as the vote in not ended.

    processMessages function called by the coordinator to process all the users' messages, update the state root and provide a zk-snark proof.

    proveVoteTally to publish the vote result and the zk-snark proof of it. Called by the coordinator. Can only be called once the vote ended.

    verifyVoteTally to verify that the generated zkSnark proof is valid.

    Public functions are needed for the coordinator to process the votes off-chain (basically the contract's state such as stateTree, messageTree, etc.) and the voter to get the coordinator's key.

    Besides the contract, we will provide two circuits to build the zk-Snark proof off-chain, one for the correctness of message processing (proveStateCorrectness) and one for the vote tallying (proveVoteTallyCorrectness). The circuits will be written in circom and it will be used through a script that build and execute the compiled circuit. This is needed for the coordinator's functions processMessages and proveVoteTally.

    Maki has two merkle roots, one for the messageTree (which gathers submitted messages) and one for the stateTree (which gathers the mapping between the user public keys and the votes).

    Maki will be implemented as an ink! smart contract, so it will be developed in Rust with ink! library.

    Maki will not provide out-of-the-box choices of circuits used for zk-SNARK proof (as it may vary depending on the nature of the voting system), nor choices of the type of voting mechanism (non-quadratic votes, conviction votes, different tallying (such as what can be found on Polkadot and Kusama referenda), etc.). However this could be part of a maintenance program, a future plan, and/or another team may develop these features to meet their needs.

    The goal being to have a functioning contract, the circuit is not my main concern here.Therefore, an existing circuit will be reused (in Typescript) - most likely one that is implemented by MACI. I'll give full credits to their implementation, even if this requires some adaptations on my end.

    Ecosystem Fitโ€‹

    Maki can be used in any blockchain that supports ink! smart contracts.

    It can be reused - as provided or modified - by any blockchain, dApp, infrastructures, ... that wishes to provide a way to make quadratic votes for its users.

    I'm not aware of any similar project on Substrate. Despite that there are different existing voting mechanisms on Polkadot/Kusama, this one is the only one that would provide a quadratic, provable, anonymous and anti-collusion voting system.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Individual / Sole Proprietor

    Team's experienceโ€‹

    I'm a software developer with 5 years of relevant experience in C#/.Net, Java(with Spring/Hibernate), Typescript, React, C++, SQL and Angular, working mainly on DDD projects and lower-level projects (such as background-jobs services, multi-thread related projects). I have a master degree in Computer Science (University of Namur - Belgium).

    Here is an overview of different relevant project I've worked / working on :

    If anyone on your team has applied for a grant at the Web3 Foundation previously, please list the name of the project and legal entity here.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    As mentioned, this application is a response from the anti-collusion infrastructure RFP

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement Voter functionsโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can deploy the contract and use its functions. References, such as the MACI research page or the specs of MACI implementation, will be provided.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.Maki: constructor and internal stateContract internal state needed to work properly and its constructor
    2.Maki: signUp functionUser function to register for the vote (ink!)
    3.Maki: publishMessage functionUser function to vote (ink!)
    4.Maki: processMessage functionCoordinator function to proves that the messages have been correctly processed

    Note: 0d. not included, because it would be overkill to setup a whole environment on a docker image just to deploy the contract while other resources already exist for that.

    Note: As the implementation is based on others work (research and specification), we will give credits and link the needed parts of it.

    Milestone 2 โ€” Coordinator's functionsโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can deploy the contract and use its functions. References, such as the MACI research page or the specs of MACI implementation, will be provided.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0e.ArticleWe will publish a Medium article and the same article on SubSocial to explain what is Maki. The articles will be referenced on Reddit (/r/Kusama and /r/Polkadot) and on diverse Discord Server related to Polkadot (mostly the important and official ones).
    1.Maki: proveVoteTally functionCoordinator function to prove the result of the vote tally on-chain (ink!)
    2.Maki: verifyVoteTally functionFunction to verify the result of the vote tally and the proof of it (ink!)
    3.CircuitsCircuit used to generate the zk-Snark (in TypeScript and Circom) - this will be based (if not reused) on this work MACI and MACI. One circuit for proveStateCorrectness and one for proveVoteTallyCorrectness functions.
    4.Votes VerifierVerifier contract/function (in Rust/ink!) to verify that the proof is correct - this will be based on this work MACI. The verifier will be used by Maki

    Note: 0d. not included, because it would be overkill to setup a whole environment on a docker image just to deploy the contract while other resources already exist for that.

    Note: As the implementation is based on others work (research and specification), we will give credits and link the needed parts of it.

    Future Plansโ€‹

    I plan to deploy this contract on one of the parachain (for example on Shiden) of Kusama to ask the community what would be their preferred choice for the next development/feature/changes of Maki.

    Which led us to the long-term plan... That would be:

    These are just ideas. I would also like for the community (developers) to participate, re-use, enhance or create their own version of Maki.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? I've been part of the program once (polk-auction application)

    - + \ No newline at end of file diff --git a/applications/MangoBOX-Protocol.html b/applications/MangoBOX-Protocol.html index cd110af9506..62b2daa139d 100644 --- a/applications/MangoBOX-Protocol.html +++ b/applications/MangoBOX-Protocol.html @@ -4,13 +4,13 @@ MangoBOX Protocol | Web3 Foundation Grants - +
    Skip to main content

    MangoBOX Protocol

    • Team Name: MangoBOX labs
    • Payment Address: 0x33e69715988126eB3653bFAfd338320BE9A10cd0(USDC))
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    MangoBOX is a fork and upgrade of fund-raising protocol Juicebox on Ethereum. It rewrites the logic and functions of Juicebox in the smart contract language of Ink! and allows the ecological projects in Polkadot to raise funds from their community and introduce the Juicebox treasury management model into the Polkadot ecosystem. Anyone can utilize the MangoBOX platform to freely create a project fundraising page, customize the funding structure, customize how the project allocates funds and reward community members with tokens.

    Overviewโ€‹

    • If the name of your project is not descriptive, a tag line (one sentence summary).

    The Ethereum fundraising protocol Juicebox is the fundraising platform of the famous DAO organizations ConstitutionDAO and AssangeDAO, while the MangoBOX Protocol is a fork and upgrade of Juicebox. We introduce Juicebox into the Polkadot ecosystem and rewrite the logic and functions of Juicebox in the smart contract language of Ink!. MangoBOX allows all types of projects in the Polkadot ecosystem to raise funds from the community. Anyone can utilize the MangoBOX platform to freely create a project fundraising page, customize the funding structure, customize how the project allocates funds and reward community members with tokens.

    • A brief description of your project.

    Through MangoBOX, anyone or any organization can configure and deploy Ink! smart contracts with no need for coding and ultimately achieve the project's fund-raising and token allocation.

    Through MangoBOX, each payment made to the project by the community users will mint and allocate the project's Tokens to payers, and allocate a certain percentage of Token (retention rate) to a set of addresses preset by the project owner. The total number of Token minted for payment will be affected by the allocation discount rate. All funds received by a project will be considered as premium if it exceeds the funding target. These funds will become the community vault. Every Token holder can choose to how to allocate these capital premiums by redeeming(burning) their tokens.

    Projects crowdfunded on MangoBOX can configure Token distribution in multiple ways. For example a project with 0% discount rate, 10% redemption bonding curve, 10% retention rate and 1000DOT financing target is completely different from a project with 20% discount rate, 100% redemption bonding curve, 50% retention rate and 500DOT financing target. There can be many interesting configurations in these gradients, and there is no way for the project sponsor to know in advanc e what the best model will be, that simply because the vision and goals of each project are different, and that there is no precedent or data for decision-making. Each project can experiment on its own and find what works best for its needs.

    The core function of MangoBOX is fund-raising which contains flexible financing, capital allocation and exit mechanisms. The beauty of MangoBOX is that it enables dynamic ownership to transfer between project providers and project funders. By funding a project, community members can obtain the project's original tokens and become the partial owner of the project. This enables community members to benefit from being involved in the project and encourages them to help the project succeed.

    On the smart contract platforms built on Polkadot para-chains via MangoBOX, every project provider can raise and use funds transparently which ultimately helps the project providers and funders build a stronger trustful relationship.

    Each of every contribution, redemption, withdrawal and deposit on MangoBOX is transparent. MangoBOX makes the source and whereabouts of funds very clear, and allows the community to assess the value and risk of the project. This complies with DAO requirements and represents the spirit of Web3, from community to community.

    • An indication of why your team is interested in creating this project.

    On November 11, 2021, a group of crypto enthusiasts launched the ConstitutionDAO, in a bid to raise funds through the DAO to buy the first printed version of the U.S. Constitution auctioned by Sotheby's. As of November 19, Constitution DAO raised $47 millions worth of ETH with over 17000 contributors. During the fundraising process of ConstitutionDAO, contributors contribute a certain amount of ETH and will be rewarded with the corresponding PEOPLE Token. By voting, Token decides the usage of the copy of the ConstitutionDAO, including its exhibition venue and method.

    On February 8, 2022, AssangeDAO, a decentralized autonomous organization aiming to rescue Assange, raised more than 17,000 ETH. Vtalik Buterin, the founder of Ethereum, participated in the donation.

    The two DAO organizations, ConstitutionDAO and AssangeDAO, have also become the two most popular DAO organizations in the past six months, triggering a wave of development in the entire DAO industry.

    However, how did these two DAO organizations raise tens of millions of dollars and manage these capital funds ? They both made the same choice: Juicebox.

    Indeed, AssangeDAO and ConstitutionDAO are both DAO organizations built on the Juicebox platform which is responsible for fundraising, fund management, community token issuance and incentives. The huge success of AssangeDAO and ConstitutionDAO also indirectly proves that Juicebox is a trusted DAO capital management tool.

    Juicebox is a programmable treasury built on the Ethereum mainnet and a governance-minimized protocol that provides community funding for individuals and projects. In the crypto world, independent artists, developers, DAOs, and general public products, need a simple, convenient, fast, and secure way to capture the value they create, generate reliable cash flow from it, and then share it back to the community. Juicebox is one such fund raising and management platform.

    Juicebox offers a brand new solution for DAO treasury management and arranges the funds and its usage by the project in advance, and then raises funds from the community. According to the current operation, Juicebox has attracted over 500 DAO organizations to raise funds, and there have emerged ConstitutionDAO and AssangeDAO that drew the attention of the entire crypto community. It is fair to say that the treasury management model of Juicebox has been proven to be a success to a certain extent. Hence, we hope to introduce Juicebox's product model into the Polkadot ecosystem and this is why the Ink! version of MangoBOX came into being.

    • An indication of how your project relates to / integrates into Substrate / Polkadot / Kusama.

    We hope to introduce Juicebox's product model into the Polkadot ecosystem and now are building the brand new MangoBOX. We plan to utilize Ink! smart contracts to rewrite Juicebox's product functions and logic, and deploy the MangoBOX on all WASM supported para-chains on Polkdot and Kusama, to make all types of DAO organizations, independent artists, developers and more general public products achieve fund raising and management possible via MangoBOX.

    But meanwhile, MangoBOX is more than Juicbox's fork and duplicate. It has its own unique product logic which is an innovation and upgrade based on Juicebox's fundamental features. For example, the project provider of the Juicebox treasury has unlimited power to mint governance tokens, which poses a huge threat potential to the treasury of the entire community. Any unethical project provider can steal all the funds in the treasury through the unlimited token minting power. The MangoBOX product function can set a limit on the project provider's minting power, which greatly reduces the potential threat to the DAO treasury.

    Project Detailsโ€‹

    • Documents of the main functions possessed by the MangoBOX protocol
    NumberSubjectSpecification
    1.Deploy an NFT that represents ownership over a projectEach project within the MangoBOX protocol is represented as an ERC-721 NFT. Whoever is the owner of a project's NFT has access to [admin functionality]for that project within the protocol, which ultimately gives it control over the project's funds.
    2.Configure funding cycles for a projectFunding cycles define contractual constraints according to which the project will operate.
    3.Mint tokensBy default, a project starts with 0 tokens and mints them when its treasury receives contributions.A project can mint and distribute tokens on demand if its current funding cycle is configured to allow minting.
    4.Burn tokensAnyone can burn a project's tokens if the project's current funding cycle isn't configured to paused burning.
    5.Bring-your-own tokenA project can bring its own token, as long as it adheres to [IMBToken]and uses fixed point accounting with 18 decimals.
    6.SplitsA project can pre-program token distributions to splits. The destination of a split can be an Polkadot address, the project ID of another project's MangoBOX treasury .
    7.Protocol feeAll funds distributed by projects from their treasuries to destinations outside of the MangoBOX ecosystem (i.e. distributions that do not go to other MangoBOX treasuries) will incure a protocol fee.
    8.Custom treasury strategiesFunding cycles can be customized.
    9.Accept multiple tokensA project can specify any number of payment terminal contracts where it can receive funds denominated in various tokens. This allows projects to create distinct rules for accepting DOT, any ERC-20, or any asset in general.
    10.Forkability and migratabilityA project can migrate its treasury's controller to any other contract that adheres to [IMBController]. This allows a project to evolve into updated or custom treasury dynamics over time as it wishes.
    • Documents of configure funding cycles

    Funding cycles define contractual constraints according to which the project will operate.

    The following properties can be configured into a funding cycle:

    NumberSubjectSpecification
    1.Start timestampThe timestamp at which the funding cycle is considered active. Projects can configure the start time of their first funding cycle to be in the future, and can ensure reconfigurations don't take effect before a specified timestamp.Once a funding cycle ends, a new one automatically starts right away. If there's an approved reconfiguration queued to start at this time, it will be used. Otherwise, a copy of the rolled over funding cycle will be used.
    2.DurationHow long each funding cycle lasts (specified in seconds). All funding cycle properties are unchangeable while the cycle is in progress. In other words, any proposed reconfigurations can only take effect during the subsequent cycle.A cycle with no duration lasts indefinitely, and reconfigurations can start a new funding cycle with the proposed changes right away.
    3.Distribution limitThe amount of funds that can be distributed out from the project's treasury during a funding cycle. The project owner can pre-program a list of addresses to split distributions between. Treasury funds in excess of the distribution limit is considered overflow, which can serve as runway or be reclaimed by token holders who redeem their tokens.
    4.Overflow allowanceThe amount of treasury funds that the project owner can distribute on-demand.This allowance does not reset per-funding cycle. Instead, it lasts until the project owner explicitly proposes a reconfiguration with a new allowance.
    5.WeightA number used to determine how many project tokens should be minted and transferred when payments are received during the funding cycle. In other words, weight is the exchange rate between the project token and a currency during that funding cycle.
    6.Discount rateThe percent to automatically decrease the subsequent cycle's weight from the current cycle's weight.The discount rate is not applied during funding cycles where the weight is explicitly reconfigured.
    7.BallotA common implementation is to force reconfigurations to be submitted at least X days before the end of the current funding cycle, giving the community foresight into any misconfigurations or abuses of power before they take effect.
    8.Reserved rateThe percentage of newly minted tokens that a project wishes to withhold for custom distributions.
    9.Redemption rateThe percentage of a project's treasury funds that can be reclaimed by community members by redeeming the project's tokens during the funding cycle.A rate of 100% suggests a linear proportion, meaning X% of treasury overflow can be reclaimed by redeeming X% of the token supply.
    10.Ballot redemption rateA project can specify a custom redemption rate that only applies when a proposed reconfiguration is waiting to take effect.This can be used to automatically allow for more favorable redemption rates during times of potential change.
    11.Pause payments,distributions, redemptions and burnProjects can pause various bits of its treasury's functionality on a per-funding cycle basis. These functions are unpaused by default.
    12.Hold feesBy default,MangoBOX membership fees are paid automatically when funds are distributed out of the ecosystem from a project's treasury. During funding cycles configured to hold fees, this fee amount is set aside instead of being immediately processed.
    • Contract Architecture of the MangoBOX protocol

    The MangoBOX protocol is made up of 7 core contracts and 3 surface contracts.

    • Core contracts store all the independent components that make the protocol work.

    • Surface contracts glue core contracts together and manage funds. Anyone can write new surface contracts for projects to use.

    NumberSubjectSpecification
    1.MBTokenStoreManages token minting and burning for all projects.
    2.MBFundingCycleStoreManages funding cycle configurations and scheduling.
    3.MBProjectsManages and tracks ownership over projects, which are represented as ERC-721 tokens.The protocol uses this to enforce permissions needed to access several project-oriented transactions.
    4.MBSplitsStoreStores information about how arbitrary distributions should be split. The surface contracts currently use these to split up payout distributions and reserved token distributions.
    5.MBPricesManages and normalizes price feeds of various currencies.
    6.MBOperatorStoreStores operator permissions for all addresses. Addresses can give permissions to any other address to take specific indexed actions on their behalf, while confining the permissions to an arbitrary number of domain namespaces.
    7.MBDirectoryKeeps a reference of which terminal contracts each project is currently accepting funds through, and which controller contract is managing each project's tokens and funding cycles.
    8.MBControllerStitches together funding cycles and project tokens, allowing for restricted control, accounting, and token management.
    9.MBPayoutRedemptionPaymentTerminalManages all inflows of funds into the ecosystem.
    10.MBSingleTokenPaymentTerminalStoreManages accounting data on behalf of payment terminals that manage balances of only one token type.
    • Technology Stack

    • Web UI

      • JavaScript โ€“ the world's most popular programming language.
      • Vue โ€“ An approachable, performant and versatile framework for building web user interfaces.

    • Data Processing

      • PolkaApi โ€“ This library provides a clean wrapper around all the methods exposed by a Polkadot/Substrate network client and defines all the types exposed by a node .

    • Contract

      • ink! โ€“ ink! is an eDSL to write smart contracts in Rust for blockchains built on the Substrate framework. ink! contracts are compiled to WebAssembly.

      • cargo-contract โ€’ CLI tool for ink! contracts.

      • Contracts UI โ€’ Frontend for contract instantiation and interaction.

      • Substrate Contracts Node โ€’ Simple Substrate blockchain which includes smart contract functionality.

    • Some UI Mock-ups of MangoBOX protocol

    Some UI Mock-ups of MangoBOX protocol-01

    image

    Some UI Mock-ups of MangoBOX protocol-02

    image

    Some UI Mock-ups of MangoBOX protocol-03

    image

    Some UI Mock-ups of MangoBOX protocol-04

    image

    Some UI Mock-ups of MangoBOX protocol-05

    image

    Some UI Mock-ups of MangoBOX protocol-06

    image

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem?

    Under the leadership of Web3 and Parity team, after five years of development, the Polkadot ecosystem has entered a formal auction era for parachains, and more and more parachains have entered the operational stage, making Polkadot ecosystem flourish. Meanwhile, it has also entered into a new stage of development which is in great demand for applications on every para-chain to make the whole ecosystem truly prosper and create a Web3 world.

    In the world of web3, decentralized governance and transparent fund management are the most basic requirements of ecology, which are also the requirements for every ecological participant. When we saw the great success of ConstitutionDAO and AssangeDAO, we also saw the great value of juicebox. Therefore we created MangoBOX Protoco, using Ink! to reconstruct Juicebox's core logic and carry out some certain innovations and upgrades. We hope that when MangoBOX Protocol is fully created, it can serve various participants in the Polkadot ecosystem and provide a complete set of treasury management solutions.

    • Who is your target audience?

    Our main target audience are all types of DAO organizations, artists, DAPP development teams and public product developers. MangoBOX Protocol can provide fund-raising and capital management services for them.

    • What need(s) does your project meet?

    Whether it's for a project provider or a DAO organization, it is a complex and tedious process to create a treasury and issue tokens to community members and raise funds. The vast majority of the projects failed due to the lack of technical capabilities. MangoBOX system allows teams to configure and manage the whole fund-raising process with no need for coding, tackling the complexity of fund-raising from the community by the project providers.

    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

    In the Substrate/Polkadot/Kusama ecosystem, we have not found any similar product. But there are some project in DAO's frame, such as subDAO and Dorafactory, that can provide some certain DAO infrastructure products and create all types of DAOs. Only MangoBOX has treasury management as its core function to raise and allocate funds transparently.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Jason Zhao: Team leader, project architect, PM and technical leader. He has over 15 years of experience in Internet technology as a senior developer. He began to know Bitcoin in 2015 and gradually emerged himself in the R&D of blockchain technology. He started to notice Polkadot in 2021 and decided to focus on the development of the Polkadot ecosystem.
    • Frank Yu: Full stack IT developer, 10 years of experience in IT, in command of programming languages such as PHP,Java, C++. Looked into the study and development of Ethereum in 2018; Committed to the Polkadot ecosystem in 2021.
    • Owen Hu: Full stack developer, smart contract engineer, 8 years of experience in IT development, currently focuses on the R&D of the blockchain technology in Web3.
    • Kevin Luo: Full stack developer, front-end engineer, 6 years of IT experience, currently focuses on the R&D of the blockchain technology.
    • Alex Li: Senior designer , 10 years of experience in Internet design, maintains a high standard of design and art.

    Contactโ€‹

    • We are preparing to register a legal entity in Hong Kong.

    Team's experienceโ€‹

    We are a Web3 start-up team from Beijing, China with Jason Zhao as our team leader and technical leader. Our team members come from different fields, from architects, product managers to full stack developers. Although we do not have a rich experience in Web3, our team has never been short of strong execution and high technical development capabilities. Our endless enthusiasm for Web3 led us to the start-up wave. As traditional Web2 practioners, our team has been engaged in the IT development in China for the last decade. As soon as Web3 opened a window to a brand new world, we immediately seized the opportunity.

    We found that the crypto industry holds endless opportunities like no other industry can match. The core vision of crypto and Web3 is to provide everyone with a native and open-source digital economy. Web3 is structured on the basis of blockchain, smart contracts and oracles, which holds a great potential to build a brand new and open ecology.

    Our team has been devoted to the R&D on the Ethereum ecosystem and not until 2021 when the Polkadot para-chains began to be deployed and applied that we had a better understanding of the ideas, principles and technology of the Polkadot ecosystem. We realized that whether it's from the top-tier ideas or the bottom technical structure, Polkadot represents the future and that's why we decided to commit to the build-up of the Polkadot ecosystem. Now as all para-chain on Polkadot are being operational, there is an emerging demand for DAPP's deployment and bulid-up, which is our unprecedented opportunity.

    Meanwhile, we found that no matter which ecology started to build, the DAO organization is the most active force in each ecology, and DAO is the future of the crypto world. In particular, the huge success of ConstituionDAO and AssangeDAO confirms our high recognition of DAOs. Hence, we decide to reconstruct Juicebox's functions and logic, using Ink! smart contract to build MangoBOX protocol, which is our first step to building up the Polkadot ecosystem.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-Time Equivalent (FTE): 4FTE
    • Total Costs: 40000 USD

    This is the link of Juicebox's solidity code, we will use Ink to rewrite all the functional logic with reference to this code, and add some optimizations and innovations of our own.

    https://github.com/Mangoboxlabs/juice-contracts-v2

    Milestone 1 โ€” Ink! contract Modulesโ€‹

    • Estimated duration: 1 month
    • FTE: 4
    • Costs: 20,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide a basic tutorial that explains how a user can deploy and test our ink contract.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.Ink๏ผContract:In the first milestone, we mainly implement how to create a fundraising project.It mainly consists of two parts, the first part is to create an NFT to represent the ownership and management of the project.Each project within the MangoBOX protocol is represented as an ERC-721 NFT. Whoever is the owner of a project's NFT has access to [admin functionality]for that project within the protocol, which ultimately gives it control over the project's funds.The second part is the basic rules for initializing this project. It mainly needs to set the following parameters:Start timestampใ€ Durationใ€Distribution limitใ€Overflow allowanceใ€Weightใ€Discount rateใ€Reserved rate, etc. Here we need to clarify that,the NFT we developed here is not a standard ERC721 token, it represents a management authority.What we are doing is a DAO fundraising system, anyone can build a DAO organization to raise funds. When this fundraising system is established, it is necessary to have administrative rights to configure parameters for this organization. At this time, we did not directly set the management rights from the code, but abstracted the management rights into an NFT. Whoever owns the NFT can control the DAO organization and adjust the corresponding fundraising parameters.Such a logical design can make the management authority of the DAO organization very easy to transfer, which is very convenient for the project party to manage the project.

    Milestone 2 โ€” Ink! contract Modules and Frontend filesโ€‹

    • Estimated Duration: 1 month
    • FTE: 4
    • Costs: 20,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide a basic tutorial that explains how a user can deploy and test our ink contract.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains how to use our product.
    1.Ink๏ผContract:In the second milestone, we mainly implement how to manage the funds raised by the project. It also contains two parts. The first part is the allocation and management of funds. The project will allocate the raised funds to designated accounts according to the pre-determined settings. The second part is the management of governance tokens. Donors can burn the corresponding governance tokens to redeem a certain percentage of overflow funds.
    2.Frontend filesWe will provide front-end files and deployment tutorials.

    Future Plansโ€‹

    • how you intend to use, enhance, promote and support your project in the short term, and

    We first hope to develop the smart contract of the product. It will then proceed to deploy on a parachain for initial testing.

    • the team's long-term plans and intentions in relation to it.

    When our product starts testing, we hope to build our global community based on the Polkadot ecosystem, and start to incubate DAO organizations to start raising funds through our platform.

    Additional Information โž•โ€‹

    • How did you hear about the Grants Program?

    Web3 Foundation Website.

    • Work you have already done.

    We have deeply researched the function and logic of juicebox, and we hope to use ink! Smart contracts refactor it.

    • If there are any other teams who have already contributed (financially) to the project.

    NO.

    • Previous grants you may have applied for.

    NO.

    - + \ No newline at end of file diff --git a/applications/MangoSale_Protocol.html b/applications/MangoSale_Protocol.html index 6b148e867fc..30d5406b4b0 100644 --- a/applications/MangoSale_Protocol.html +++ b/applications/MangoSale_Protocol.html @@ -4,13 +4,13 @@ MangoSale Protocol | Web3 Foundation Grants - +
    Skip to main content

    MangoSale Protocol

    • Team Name: MangoBOX labs
    • Payment Address: 0x33e69715988126eB3653bFAfd338320BE9A10cd0(USDC))
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    https://github.com/w3f/Grant-Milestone-Delivery/pull/612

    Through the joint efforts of all team members, we have completed the development and submission of the first grant and also furthered our understanding of Polkadot ecology and the entire industry.

    MangoBOX labs is committed to the development of the DAO fundraising system, in the hope of developing a complete fundraising system. In the first stage, we developed an Ink! version smart contract of MangoBOX protocol based on Juicebox , which is a well-known project on Ethereum.

    However, in the actual process of development, we found some shortcomings of the Juicebox protocol as well : tokens can be issued additionally without restrain, the fundraising rounds are difficult to manage, and overall the protocol is relatively complicated to use. These characteristics are not conducive to the large-scale application of a Web3 product.

    After multiple rounds of research by our product team, we decided to conduct a more in-depth exploration in the field of DAO fundraising. We specialized in Ink! Smart contract version of MangoSale Protocol. MangoSale Protocol is a license-free protocol designated for project fair launch, which is considered as an open IDO platform. It is not limited to DAOs, but also applicable to various types of individuals or organizations. Compared to Juicebox, it's simpler and fairer to use. Any project party can raise the funds they want in different ways through the MangoSale Protocol.

    Overviewโ€‹

    • If the name of your project is not descriptive, a tag line (one sentence summary).

    MangoSale Protocol is based on Ink! A protocol developed by smart contracts that does not require permission and is used for the fair launch of projects belongs to an open IDO platform. Anyone, any community, and any organization can initiate token auctions and financing without permission, and carry out fair distribution of tokens.

    Based on Ink! version smart contracts, MangoSale Protocol is a permissionless , project fair launch oriented protocol that acts as an open IDO platform. Any individual, community or organization can start token auctions and financing without permission and implement token fair distribution.

    Well-known IDO platforms for inspiring MangoSale Protocol as below :

    โ€‹ 1. Pinksale๏ผš https://www.pinksale.finance/

    โ€‹ 2. Unicrypt: https://unicrypt.network/

    โ€‹ 3. Gempad: https://gempad.app/

    • A brief description of your project.

    As a permissionless fair distribution protocol, MangoSale Protocol is an open IDO platform which has the main following functions and features:

    • Permissionless and decentralized. Anyone can start the creation and auction of Token through the MangoSale Protocol and raise funds without any threshold or code base.

    • Multi-chain deployment. MangoSale Protocol will be deployed on multiple Ink! smart contracts supported para-chains in the future. The para-chain project owners can also deploy projects on their own.

    • Coexistence of multiple Web3 tools. MangoSale Protocol will provide at least three Web3 tools:

      1. MangoToken, Token factory can create Tokens with tax function.

      2. The MangoLock time lock function can lock up tokens in periods to realize the linear release of tokens.

      3. MangoAirdrop system. The airdrop system project owner can initiate airdrops for different users, which is conducive to expanding the group of currency holders.

    • Coexistence of multiple auction methods. MangoSale Protocol will support three different types of auctions to facilitate the launch of various natured projects, and the project initiators can choose freely according to their actual situation

      1. Launchpad: Token auction by a fixed price.

      2. Fair Launch: Token auction in the form of fair launch.

      3. Dutch Auction๏ผš Token auction in the form of Dutch Auction.

    • An indication of why your team is interested in creating this project.

    At present, there are more and more projects starting and financing in the encrypted world, and there also exist IDO platforms that provide services for various crypto projects. However, many IDO platforms are required to get permit, official review and KYC verifications from official authorities. This greatly hinders the scale of project initiation and sets various preconditions for the initiation of the project, making the process of project initiation tedious and difficult.

    In this context, MangoSale Protocol launched a permissionless IDO fair launch platform. Any individual, community or organization can start Token auctions and financing without permission and implement token fair distribution.

    At the same time, all smart contracts of MangoSale Protocol have been designed in advance. Anyone without code knowledge can complete the issuance and financing of tokens through a fixed template, which greatly simplifies the start-up process and enables all various projects to be completed as soon as possible.

    • An indication of how your project relates to / integrates into Substrate / Polkadot / Kusama.

    With its continuous expansion and especially the steady progress of parachain auctions, the Polkadot ecosystem has entered a new stage. It no longer only focuses on the construction of the underlying technology, but also has entered the stage of ecological construction in an all-round way. At this time, various types of project owners are required to develop on different parachains. This is also an important reason why we are now developing MangoSale Protocol.

    We hope to develop a permissionless project launch and fundraising platform for the overall ecology of Substrate / Polkadot / Kusama, so that all types of projects in different stages can start on their own with the minimal costs and simplest steps and finally raise appropriate funds. This is our hope and vision today.

    Project Detailsโ€‹

    • Documents of the main functions possessed by the MangoSale Protocol

    1. MangoTokenFactory: TokenFactory can not only create standard ERC20 tokens, but also create ERC20 tokens with special functions, i.e, ERC20 tokens with tax functions. Taxation can be divided into different modules, such as marketing wallet and repurchase burning. Project owners can initialize the token factory according to their actual needs.

    2. MangoLock: The time lock function is also one of the core functions of the startup project. Through time lock, tokens can be locked in periods to implement the linear release of tokens, which can fully gain the trust of the community and make the project Token issuance mechanism more transparent.

    3. MangoAirdrop system: Project initiators can use the airdrop system to launch airdrops for different users in the ecosystem to motivate ecosystem contributors, which will help expand the number of coin holders and benefit more community members;

    4. launchpad: Launchpad: Launchpad auctions Token at a fixed price, which is one of the most common auction methods. Launchpad has a soft cap and a hard cap. If the soft cap is not reached, the auction will be cancelled. If the soft cap is reached, the auction will be successful. The maximum fundraising amount is the hard cap value. Token auction price is calculated according to the price set in advance, and the exchange rate is fixed.

    5. Fair Launch: Token auctions are conducted in the form of Fair Launch, and the auction price is not fixed. Fair Launch has only a soft cap, and there is no cap on the amount of funds raised. At the same time, the Token auction is not carried out according to a fixed exchange rate but according to the total amount of funds raised at the end of the auction. If the amount of funds raised reaches the soft cap and the fundraising is successful, the total amount of funds raised divided by the total number of tokens provided will be the user's actual purchase exchange rate. The higher the overall funds raised, the higher the user's purchase exchange rate will be.

    6. Dutch Auction: Token auctions are conducted in the form of Dutch auction. Dutch auction is a special auction method, also known as "reduced price auction". It refers to an auction in which the bids for the auction target decrease in order from high to low until the first bidder answers (reaches or exceeds the reserve price). Choosing such an auction method can make the auction fairer.

    • MangoSale Protocol Functional Model Architecture Diagram

    • Mockups/designs of any UI components

    1.MangoTokenFactory:

    2.MangoLock:

    3.MangoAirdrop system:

    4.launchpad:

    5.Fair Launch:

    6.Dutch Auction:

    • Technology Stack

      • JavaScript โ€“ the world's most popular programming language.

      • Vue โ€“ An approachable, performant and versatile framework for building web user interfaces.

      • PolkaApi โ€“ This library provides a clean wrapper around all the methods exposed by a Polkadot/Substrate network client and defines all the types exposed by a node .

      • ink! โ€“ ink! is an eDSL to write smart contracts in Rust for blockchains built on the Substrate framework. ink! contracts are compiled to WebAssembly.

      • cargo-contract โ€’ CLI tool for ink! contracts.

      • Contracts UI โ€’ Frontend for contract instantiation and interaction.

      • Substrate Contracts Node โ€’ Simple Substrate blockchain which includes smart contract functionality.

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem?

    Under the leadership of Web3 and Parity team, after five years of development, the Polkadot ecosystem has entered a formal auction era for parachains, and more and more parachains have entered the operational stage, making Polkadot ecosystem flourish. Meanwhile, it has also entered into a new stage of development which is in great demand for applications on every para-chain to make the whole ecosystem truly prosper and create a Web3 world.

    In the world of web3, decentralized governance and transparent fund management are the most basic requirements of ecology, which are also the requirements for every ecological participant. We hope that when MangoSale Protocol is fully created, it can serve various participants in the Polkadot ecosystem and provide a complete set of treasury management solutions.

    • Who is your target audience?

    MangoSale Protocol can create and auction Tokens for different types of combinations and individuals without permission, and finally realize the fundraising.

    • What need(s) does your project meet?

    Whether it's for a project provider or a DAO organization, it is a complex and tedious process to create a treasury and issue tokens to community members and raise funds. The vast majority of the projects failed due to the lack of technical capabilities. MangoSale system allows teams to configure and manage the whole fund-raising process with no need for coding, tackling the complexity of fund-raising from the community by the project providers.

    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

    In the Substrate/Polkadot/Kusama ecosystem, we have not found any similar product. But there are some project in DAO's frame, such as subDAO and Dorafactory, that can provide some certain DAO infrastructure products and create all types of DAOs.

    โ€‹ More similar projects in Ethereum and BNB ecosystems:

    1. Pinksale๏ผš https://www.pinksale.finance/
    2. Unicrypt: https://unicrypt.network/
    3. Gempad: https://gempad.app/

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Jason Zhao: Team leader, project architect, PM and technical leader. He has over 15 years of experience in Internet technology as a senior developer. He began to know Bitcoin in 2015 and gradually emerged himself in the R&D of blockchain technology. He started to notice Polkadot in 2021 and decided to focus on the development of the Polkadot ecosystem.
    • Frank Yu: Full stack IT developer, 10 years of experience in IT, in command of programming languages such as PHP,Java, C++. Looked into the study and development of Ethereum in 2018; Committed to the Polkadot ecosystem in 2021.
    • Owen Hu: Full stack developer, smart contract engineer, 8 years of experience in IT development, currently focuses on the R&D of the blockchain technology in Web3.
    • Kevin Luo: Full stack developer, front-end engineer, 6 years of IT experience, currently focuses on the R&D of the blockchain technology.
    • Alex Li: Senior designer , 10 years of experience in Internet design, maintains a high standard of design and art.

    Contactโ€‹

    • We are preparing to register a legal entity in Hong Kong.

    Team's experienceโ€‹

    We are a Web3 start-up team from Beijing, China with Jason Zhao as our team leader and technical leader. Our team members come from different fields, from architects, product managers to full stack developers. Although we do not have a rich experience in Web3, our team has never been short of strong execution and high technical development capabilities. Our endless enthusiasm for Web3 led us to the start-up wave. As traditional Web2 practioners, our team has been engaged in the IT development in China for the last decade. As soon as Web3 opened a window to a brand new world, we immediately seized the opportunity.

    We found that the crypto industry holds endless opportunities like no other industry can match. The core vision of crypto and Web3 is to provide everyone with a native and open-source digital economy. Web3 is structured on the basis of blockchain, smart contracts and oracles, which holds a great potential to build a brand new and open ecology.

    Our team has been devoted to the R&D on the Ethereum ecosystem and not until 2021 when the Polkadot para-chains began to be deployed and applied that we had a better understanding of the ideas, principles and technology of the Polkadot ecosystem. We realized that whether it's from the top-tier ideas or the bottom technical structure, Polkadot represents the future and that's why we decided to commit to the build-up of the Polkadot ecosystem. Now as all para-chain on Polkadot are being operational, there is an emerging demand for DAPP's deployment and bulid-up, which is our unprecedented opportunity.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    • none available

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-Time Equivalent (FTE): 4 FTE
    • Total Costs: 26000 USD

    Milestone 1 โ€” Ink! contract Modulesโ€‹

    • Estimated duration: 1 month
    • FTE: 4
    • Costs: 12,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide a basic tutorial that explains how a user can deploy and test our Ink! contract.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains how to use our product.
    1.Ink! Contract:TokenFactoryTokenFactory can create ERC20 tokens with tax functions.
    2.Ink! Contract: MangoLockMangoLock can realize the lock-up and linear release of Token..
    3.Ink! Contract: MangoAirdropMangoAirdrop can implement different types of token airdrops.
    4.Front-end UIWe currently use the Vue.js framework for Front-end development . In the first milestone we will develop the front-end UI of these three parts: TokenFactory, MangoLock and MangoAirdrop.We will provide Front-end deployment tutorials for TokenFactoryใ€ MangoLock and MangoAirdrop .
    5.Front-end integration (e2e) testWe will use Cypress.io as an end-to-end testing framework for the Front-end automated approach test.

    Milestone 2 โ€” Ink! contract Modules and Frontend filesโ€‹

    • Estimated Duration: 1 month
    • FTE: 4
    • Costs: 14,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide a basic tutorial that explains how a user can deploy and test our Ink! contract.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains how to use our product.
    1.Ink! Contract: launchpadLaunchpad can conduct Token auctions at a fixed price.
    2.Ink! Contract: Fair LaunchFair Launch can conduct Token auctions in the form of fair launch.
    3.Ink! Contract: Dutch AuctionDutch Auction can conduct Token auctions in the form of Dutch auctions.
    4.Front-end UIWe currently use the Vue.js framework for Front-end development . In the second milestone we will develop the front-end UI of these three parts: launchpad Auctionใ€ Fair Launch Auction and Dutch Auction. We will provide Front-end deployment tutorials for launchpad Auction ใ€ FairLaunch Auction and Dutch Auction.
    5.Front-end integration (e2e) testWe will use Cypress.io as an end-to-end testing framework for the Front-end automated approach test.

    Introduction to the three auction functions:

    1. launchpad Auction:Launchpad auctions Token at a fixed price, which is one of the most common auction methods. Launchpad has a soft cap and a hard cap. If the soft cap is not reached, the auction will be cancelled. If the soft cap is reached, the auction will be successful. The maximum fundraising amount is the hard cap value. Token auction price is calculated according to the price set in advance, and the exchange rate is fixed.

    2. FairLaunch Auction: Token auctions are conducted in the form of Fair Launch, and the auction price is not fixed. Fair Launch has only a soft cap, and there is no cap on the amount of funds raised. At the same time, the Token auction is not carried out according to a fixed exchange rate but according to the total amount of funds raised at the end of the auction. If the amount of funds raised reaches the soft cap and the fundraising is successful, the total amount of funds raised divided by the total number of tokens provided will be the user's actual purchase exchange rate. The higher the overall funds raised, the higher the user's purchase exchange rate will be.

    3. Dutch Auction: Token auctions are conducted in the form of Dutch auction. Dutch auction is a special auction method, also known as "reduced price auction". It refers to an auction in which the bids for the auction target decrease in order from high to low until the first bidder answers (reaches or exceeds the reserve price). Choosing such an auction method can make the auction fairer.

    Future Plansโ€‹

    • how you intend to use, enhance, promote and support your project in the short term, and

    We first hope to develop the smart contract of the product. It will then proceed to deploy on a parachain for initial testing.

    • the team's long-term plans and intentions in relation to it.

    When our product starts testing, we hope to build our global community based on the Polkadot ecosystem, and start to incubate many organizations to start raising funds through our platform.

    Additional Information โž•โ€‹

    • How did you hear about the Grants Program?

    Web3 Foundation Website.

    • Work you have already done.

    We have deeply researched the function and logic , and we hope to use ink! Smart contracts refactor it.

    • If there are any other teams who have already contributed (financially) to the project.

    NO.

    • Previous grants you may have applied for.

    NO.

    - + \ No newline at end of file diff --git a/applications/MeProtocol.html b/applications/MeProtocol.html index a3f39e99813..7a3bc371bb3 100644 --- a/applications/MeProtocol.html +++ b/applications/MeProtocol.html @@ -4,7 +4,7 @@ Me Protocol | Web3 Foundation Grants - + @@ -21,7 +21,7 @@ Contact Email:ย wesley@meprotocol.io Website: https://meprotocol.io

    Team's experienceโ€‹

    We have founded and co-founded several tech companies (e.g. Kivu Technologies, Cognitive Architectures, Useful Technologies) and worked on a variety of complex software development projects spanning graph computing to blockchain based solutions.

    Team Code Reposโ€‹

    GitHub accounts of team members

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement the Core Parts of the Protocolโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user, brand or third party application can interact with our protocol for the various specified use cases
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a lite paper to describe the architecture and its implementation
    1.Build out the Pool ComponentWe will implement the Rewards Pool Component which contains the contracts, libraries and interfaces that describe and manage the sets of AMM pools for brand loyalty rewards. This component primarily consists of the pool contract, which manages all the logic relating to brand liquidity (swapping, adding, removing, multistage swapping, etc.), and the Pool initiator contract, which would create a pool every time a new brand reward is to be supported on our protocol. These are similar in concept to Uniswap Pool and Pool Deployer contracts, but with different requirements/implementation logic and no concentrated liquidity.
    Languages and framework: Ink!, Openbrush
    2.Build out the rewards factory componentWe will implement the Rewards Factory, which allows brands with or without Web3-based rewards to move some or all of their loyalty points to the blockchain using the PSP22 standard (and also PSP34/PSP1155 in the future). It contains the function for creating a new PSP22 token and keeping track of the associated brand.
    Languages and framework: Ink!, Openbrush
    3.Build out the Rewards Periphery ComponentWe will implement the Rewards Periphery Component that provides a form of incentivization to brands when their rewards are used to redeem offers across other brands. This component consist of two major contracts: Brand Bounty and Brand Treasury Contracts. Brand Treasuries are small fees paid by brand A to brand B when a customer from brand B chooses to redeem his/her reward with brand A. The treasury is a smart contract that holds these tokens, mapped to the appropriate brand. Brand bounties on the other hand are small amounts of reward tokens charged to a customer when he chooses to redeem that reward with another brand (typically swapping in our protocol). These small fees are stored in the Bounty Contract and when a bounty threshold is reached, they are issued as rewards to promote the issuing brand.
    Languages and framework: Ink!
    4.Build out the service payment componentWe will implement the Service Payment Component that brands and other integrating third-party applications will use to pay for the various services rendered to them through the protocol and business applications. This component consists of the payment/fee contract, which contains the logic to handle the reception of these tokens, mapped to the payer, and the logic to release these tokens when a paid service is rendered to the payer.
    Languages and framework: Ink!
    5.Build Out the Rewards Valuation Oracle ComponentWe will implement the Rewards Valuation Oracle Component, which helps to manage all external requests relating to rewards pricing and valuation in the protocol based on the supply and demand of these rewards in the pool. It consists primarily of the oracle contract that provides information on the valuation of rewards in our protocol.
    Languages and framework: Ink!

    Milestone 2 โ€” Adding the Protocol Peheripherals and Kickstarting the Frontend and Backend servicesโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user, brand or third party application can interact with our protocol for the various specified use cases
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a lite paper to describe the architecture and its implementation
    1.Build out the Protocol Access ComponentWe will implement the Access Component, which consists of contract routers that abstract the core protocol services and provide functions that brands, customers, protocol admins, and third-party applications can use to safely interact with the protocol. These are similar to the Uniswap router contracts, but instead of just one general contract, the contracts are split into Customer, Brand, Admin, and in the future Third-Party Contracts, based on the role of the requestor. A brand router, for example, will expose the functions that allow a brand to create a reward (using the reward factory), mint additional rewards or burn existing rewards, add or remove rewards from the liquidity pool, top up fee wallet, etc.
    Languages and framework: Ink!
    2.Build out the lens componentWe will implement the Lens Component that provides introspection into the protocol. This component is comprised of the Secretary and Loupe Modules. The Secretary Contract would provide business information like how many brands are connected to the protocol, total loyalty rewards in pools, etc. The Loupe Contract provides protocol architecture information, such as what functions the protocol supports and where these functions are deployed (it is an implementation of the EIP2535 DiamondLoupe Contract) etc.
    Languages and framework: Ink!
    3.Building out the Governance ComponentWe will implement the Governor Facet that will help to manage access control across the protocol and also help to manage governance rules for future proposals and updates.
    Languages and framework: Ink!
    4.Build out the Backend Service Components for the Me AppWe will implement some key utilities for the back-end services to be used by integrated apps, such as logging (Winston); data caching (Redis Cache); search indexing (Elastic search); database and connection (Postgres TypeOrm); mailing service (Nestjs nodemailer with sendgrid abi); image upload with (Fastify multipart); and entities and their relationships (Typescript, NestJs, PostgreSQL).

    Milestone 3 โ€” Rounding Up with the APP MVP and Integrating the Protocol with the APPโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user, brand or third party application can interact with our protocol for the various specified use cases
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a lite paper to describe the architecture and its implementation
    1.Build out the Asset Management Component of the Me APPWe will implement all the necessary screens, services and microservices that let brand customers to keep track of, earn and spend rewards in applications and also for brands to keep track of, distribute and manage their rewards in applications.
    Languages and framework: TypeScript, Nestjs, Reactjs, Polkadotjs.
    2.Build out the offers management component of the Me APPWe will implement all the necessary screens and provide all the necessary services and microservices that will allow brands to integrate their offers, create new offers and push them to applications and also allow brand customers to search offers, filter offers, view price, see offers whose rewards they have, redeem these offers with their rewards.
    Languages and framework: TypeScript, Nestjs, Reactjs, Polkadotjs, PostgreSql

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Was recommended that we apply by Daniel Cake-Baly from Parity Technologies.

    Previous grants: We received financial support in the form of an investment from the Blockchain Founders Group.

    - + \ No newline at end of file diff --git a/applications/Melodot.html b/applications/Melodot.html index 220fe3ebe66..4ed3dfc7015 100644 --- a/applications/Melodot.html +++ b/applications/Melodot.html @@ -4,13 +4,13 @@ Melodot: Incentive-compatible data availability layer | Web3 Foundation Grants - +
    Skip to main content

    Melodot: Incentive-compatible data availability layer

    • Team Name: ZeroDAO
    • Payment Address: 0xEBCDa7c73EB5Dd7a4314cFf395bE07EB1E24c046 (DAI)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Data Availability Layerโ€‹

    The current data availability layer scheme requires the assumption that the network has at least the minimum number of honest nodes.However, due to the need to prevent data retention attacks, the samplers are required to be anonymous, making it difficult to measure the number of samplers. At the same time, samplers are more concerned with data related to themselves, resulting in an uneven distribution of total active samplers over time. The assumption of a minimum number of honest nodes affects the robustness of the data availability layer.

    Challenging issues in the data availability layer also include: who will perform distributed generation, who will reconstruct the data, who will store the data, how long will the data be stored, and how to ensure that these tasks are well done.

    One possible approach is to delegate these tasks to consensus validators, but there is a lack of effective incentive mechanisms. For cost considerations, not performing distributed generation, data reconstruction, and data storage is the most profitable for validators. In addition, consuming too many resources of consensus validators is very unfavorable for scalability.

    Melodot introduces the role of farmers by combining PoSpace, alleviating the system's dependence on the minimum number of honest nodes assumption, and completing an incentive-compatible distributed generation and data storage scheme. Consensus validators now act more like light clients, improving future scalability. You can learn more from this preliminary whitepaper.

    Project Detailsโ€‹

    Architectureโ€‹

    Erasure Coding and KZG Commitmentโ€‹

    Melodot uses 2D Reed-Solomon for data expansion, providing better sampling efficiency. It generates KZG commitments in the row direction, avoiding fraud proofs, similar to Ethereum's Darksharding. Block headers contain KZG commitments and data locations for different apps, allowing light clients to sample or download only data relevant to themselves.

    Farmersโ€‹

    Farmers receive rewards through PoSpace, which is used to verify that participants have allocated a certain amount of storage space on their devices. The consensus mechanism is achieved through a time-memory trade-off approach, which has its origins in the Beyond Hellman paper and has been adopted for use in the Chia protocol. This method allows for a more efficient and secure consensus process compared to traditional energy-intensive mechanisms such as Proof of Work. Subspace improves PoSpace for storing "useful data" and is closely linked to KZG commitments. We are inspired by them, in contrast, Melodot's farmers receive rewards through PoSpace rather than reaching consensus. This incentive mechanism ensures that the network can still recover data when natural sampling samples are insufficient and guarantees data storage for at least a specific duration.

    Farmers need to complete the distributed generation of specified data, expanding the data generated by block proposers in the column direction. They then calculate the challenge eligibility through the generated data, similar to Chia's filter, with only a small portion of farmers eligible to further search for solutions. This design reduces the computation load on farmers, avoids missing the submission of solutions, and allows farmers to devote more bandwidth and capacity resources to data availability sampling and storage. In addition, farmers are more inclined to generate all specified data in a distributed manner, as each chunk represents a potential lottery ticket.

    Farmers use the committed space to store blob data and maintain its timeliness. New data receives more rewards, while expired data will not be rewarded. Upon obtaining challenge eligibility, farmers need to search for solutions in the stored data, including chunk, data proofs, space proofs, etc. The system adjusts the difficulty based on the reward claims situation. Ultimately, the rewards farmers receive are linearly related to the size of the stored data space and depend on whether they have correctly and promptly completed distributed generation and necessary data reconstruction.

    Lifecycleโ€‹

    Untitled

    A complete blob transaction includes:

    • Publishing a blob transaction, including the original KZG commitment
    • Block builders collect blob transactions and build blocks, erasure code data, and generate new commitments to be added to the block header
    • Consensus validators verify block validity and, along with farmers, perform preliminary availability sampling (not ensuring 100% validity, but with high probability of being valid), either rejecting or accepting the block
    • Farmers use the block data, commitments, and proofs learned in the previous step to generate specified columns in a distributed manner
    • When the block is finalized
      • Farmers with challenge eligibility complete solutions and claim rewards
      • Light clients and consensus validators perform sampling simultaneously
      • Farmers obtain more specified data from the network for storage and delete expired data

    Melodot is developed in phases, with the first phase not implementing the complete process.

    Componentsโ€‹

    In this phase, we will implement the following core components:

    1. Erasure-Coding

      A core module for erasure coding and KZG based on rust-kzg, including expanding data and generating commitments and proofs, verifying blob, batch verifying blobs, recovering data, verifying the correct expansion of 2D commitments, and expanding column data and witnesses.

    2. Melo-Store

      Interfaces for registering and managing applications, uploading data, and storing data validity data.

    3. Consensus-related extensions

    excutive_das pallet: An extension of the frame-excutive pallet for scheduling block execution and validation related to DAS

    system_das pallet: An extension of the frame-system pallet, adding new block header generation, actual data generation, and validation.

    1. Sampling Core

    The core crate that actually performs sampling, which several clients in the system depend on. This includes data availability sampling, obtaining and propagating data from the DHT network, and managing data through rocksdb.

    1. Light Client

    A light client that connects to the network and performs sampling based on the block state, including network implementation, distributed generation, data storage, and actual sampling.

    1. Melo-PoSpace

    A pallet for assigning distributed generation columns to farmers, verifying farmers' challenge chunk, and issuing rewards.

    1. Farmer Client

    Connects to the network, obtains raw data, and performs distributed generation; obtains challenges from the chain and searches for solutions to claim rewards.

    Non-Goalsโ€‹

    The goal of the first phase is to minimally implement a usable system and will not fully implement the details described in the whitepaper. The main differences are:

    PoSpace

    In the first phase, we will only implement a preliminary version of PoSpace, not including the complete PoSpace process. Subspace has done an excellent exploration in this regard. In the next phase of development, we should be able to reuse much of their work.

    Complete Distributed Generation

    This phase does not include complete distributed generation. Users still need to submit actual data transactions, so farmers and validators do not need to perform the first phase of sampling.

    Ecosystem Fitโ€‹

    Similar Projectsโ€‹

    There are currently several data availability layer projects, including Ethereum Danksharding, Celestia, Avail, and Eigen DA. Our main difference from them is the introduction of farmers, which solves many tricky problems faced by the data availability layer. Unlike Danksharding, we decouple an independent data availability layer, which is the same principle as Polkadot not supporting smart contracts. Celestia uses a Merkle encoding pattern, requiring fraud proofs and additional assumptions, which we avoid. Avail's data layout uses a 1.5D scheme, which is unacceptable in terms of sampling efficiency, as detailed in the Melodot white paper. Eigen DA is an Ethereum re-collateralization layer implementation of a data availability scheme, with limited public information available, but it should be in the form of a DA committee, which has its applicable scenarios, but is not the same as Melodot.

    Relationship with Polkadot and substrateโ€‹

    1. With Melodot as a data availability layer, any parallel chain can easily become a Rollup settlement layer. Polkadot brings more secure interactions between settlement layers, significantly increasing Polkadot's capacity.
    2. Other teams can develop their own data availability layers based on Melodot.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Daqin Lee
    • Zhidong Chen
    • Sober Man

    Contactโ€‹

    Team's experienceโ€‹

    Daqin Lee: Full-stack Developer, Rust and Substrate Developer, core developer of Melodot.

    Chen Zhidong: Full-stack Developer, Tesla Machine Learning Engineer, GoHack 2017 Hackathon First Prize, will serve as a technical advisor for Melodot.

    Sober Man: Embedded Engineer, with years of backend and embedded development experience.

    Team Code Reposโ€‹

    Development Statusโ€‹

    ZeroDAO previously developed the Ourspace project, which is a reputation system utilizing social relationships and received support from W3F. After that, we shifted our focus to calculating all social networks in Web3. In this process, we found that they were either expensive to interact with or difficult to securely use on-chain. Through in-depth analysis, we summarized these issues as a lack of visibility. Therefore, we temporarily paused the development of Ourspace (we will continue to develop it later) and focused on researching the "visibility" issue, discovering that rollup technology is a good solution to this problem. The data availability layer is the first step in achieving this, and after extensive research, we designed Melodot. The work we have completed so far includes:

    1. Whitepaper: Completed a preliminary whitepaper.
    2. Research: We conducted some research on Rollup and data availability layer projects, and you can see the project list here.

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4.5 months
    • Full-Time Equivalent (FTE): 1.5
    • Total Costs: 28,000 DAI

    Milestone 1 โ€” Erasure coding and KZGโ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: 5,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how the new functionality works and how they are used.
    0c.Testing and Testing GuideUnit tests will completely cover the Core functionality to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide Dockerfiles to demonstrate the full functionality of erasure coding and KZG commitments.
    1.melo_erasure_codingThe core part of the system, including 2D erasure coding and KZG commitment-related primitives and common interfaces.

    Milestone 2 โ€” Consensusโ€‹

    • Estimated duration: 1.5 months
    • FTE: 1
    • Costs: 7,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up a client, connect to the client management application and data through a browser, and create a local development chain.
    0c.Testing and Testing GuideHigher-level integration tests and unit tests for all modules. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide Dockerfiles to start nodes, create a local test network, and run all integration tests.
    1.Substrate pallet: excutive_dasModify the existing frame-executive pallet to support custom headers while ensuring all original tests continue to function.
    2.Substrate pallet: system_dasExtend the frame-system pallet to support the creation of extended headers.
    3.Substrate pallet: melo_storeA core pallet for handling data availability. Main features include: 1) Registering applications. 2) Allowing users to submit data metadata. 3) Validators accessing off-chain storage via OCW and reporting unavailable data. 4) Interface for creating extended block header.
    4.melodot-clientA substrate client containing a complete data availability layer. The DAS core features include: 1) Accepting user-submitted blob_tx, verifying if the data is correctly encoded, submitting the transaction, and publishing the data to a peer-to-peer network 2) Validators retrieving data transactions from the transaction pool and attempting to fetch the data from DHT to save locally.

    Milestone 3 โ€” Samplingโ€‹

    • Estimated duration: 1 month
    • FTE: 1.5
    • Costs: 7,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can start a light client and connect to the network.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide Dockerfiles to start a light client, connect to the local test network, and run all integration tests.
    0e.ArticleWe will publish an article explaining how Melodot works, how to run a local test network, and how to run a light client.
    1.Light clientA light client that connects to the network and efficiently performs sampling, stores sampling data, and maintains data availability confidence.
    2.melo_samplingA decoupled sampling module that provides core functionality related to data sampling.

    Milestone 4 โ€” Farmerโ€‹

    • Estimated duration: 1 month
    • FTE: 2
    • Costs: 9,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can run a farmer client and earn rewards.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article explaining the farmer part and the future plans for Melodot, as well as how to run a farmer client.
    1.melo_farmerImplementation of the farmer client, used to connect to the melodot-client, solve challenges, and distribute and store data.
    2.melo_PoSpaceA pallet used to assign distributed generation tasks to farmers and distribute rewards to farmers.

    Future Plansโ€‹

    In the near future, we plan to establish a company as the core development team. Our long-term plan is to build the entire ecosystem through a DAO, and we have already formulated a centralized version of the DAO to be developed after the launch of the Melodot testnet.

    Our short-to-medium-term plan (6 months) includes:

    Melodot

    • Launch the testnet
    • Identify and eliminate all possible security threats
    • Complete the full PoSpace and distributed generation

    SDK

    • Develop an SDK based on Substrate for quickly launching settlement layers and sequencer

    Additional Informationโž•โ€‹

    How did you hear about the Grant Program?

    Web3 Foundation website

    • Previous grant applications

    We have previously applied for ZeroDAO-node, which has now been renamed to (ourspace).

    - + \ No newline at end of file diff --git a/applications/Meta_Defender.html b/applications/Meta_Defender.html index 23fd766938d..e40efc5a00f 100644 --- a/applications/Meta_Defender.html +++ b/applications/Meta_Defender.html @@ -4,7 +4,7 @@ Meta Defender | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ Assume when that this situation arises, and the excess of claims over the Risk Reserve is ฮด, the new ฮท becomes

    TokenRemain includes the token frozen in the protocol of the underwriters who are able to underwrite for new policies, as well as the token of those underwriters who have stopped underwriting for new policies.

    โ€‹It can be seen that the value of ฮท decreases further, and the number of sTokens - representing the weight of capturing premium rewards, while bearing liability - that can be obtained for an equal amount of Tokens for underwriters joining the pool thereafter is increased . This is clearly due to the reduction in the actual underwriting capacity of the original underwriters following the erosion of the principal in the pool.

    4.3 Underwritten Assets Withdrawal Mechanismโ€‹

    4.3.1 Available Assets that can be Withdrawn by Underwritersโ€‹

    Underwriters can withdraw a portion of their unfrozen capital at any time before it is completely frozen. However, the frozen part needs to wait for the corresponding policy expiration to exit. The assets that can be withdrawn by the underwriter is calculated by the formula:

    โ€‹shadow is the amount of assets of the underwriters that has been frozen. However, the situation becomes more complicated when considering a policy that has expired which results in releasing part of frozen capital.

    4.3.2 Cancellation of Policiesโ€‹

    Along with the cancellation of policies which expire, the corresponding underwritersโ€™ frozen capital should be released. When a policy is generated, we record its lastProviderIndex and ฮ”accSPS. When it is cancelled, the protocol synchronises the latestUnfrozenIndex to the lastProviderIndex of this policy, and accumulates accSPSDown:

    โ€‹When calculating an underwriter's shadow, it is necessary to first determine the relationship between his index and latestUnfrozenIndex. When index<=latestUnfrozenIndex, it means that the capital being released already has the part of the underwriterโ€™s frozen capital. His shadow will be calculated by:

    4.3.3 After Underwriter Withdrawal of Assetsโ€‹

    In order to make the protocol easier to maintain and to reduce the cost of gas fee when users invoke the contract, Meta Defender currently requires the underwriter who would like to quit to withdraw all remaining liquidity at once (i.e., withdraw mentioned above).

    Of course, you may only want to "withdraw partially". It is very simple to implement this - you could simply withdraw in full and then re-join with your desired coverage amount. This saves the protocol from having to maintain a huge ledger, where the cost of gas would otherwise become unimaginable.

    When an underwriter withdraws assets, he or she needs to destroy all of his or her sToken.

    Suppose an underwriter P destroys all of his sToken, declaring that he has ended his status as an underwriter. Regardless of how much capital he has actually withdrawn (usually less than his original provided capital, i.e. ฮท*sTokenAmount, less than ), he can no longer continue to capture premium and no longer underwrite new policies, i.e., no longer "capture" new shadow.

    The protocol creates a "historical identity" for him, P', and records the following parameters:

    fsToken(frozen_sToken): the number of Tokens that this underwriter has not withdrawn, which will be then converted to sToken according to current ฮท;

    accSPS_P: the accSPS of P when it quits the protocol;

    index: the index inherited from P;

    sTokenAmount_P : the sTokenAmount inherited from P;

    SDebt_P: the sDebt inherited from P.

    It can be seen that the maximum amount that can eventually be released by P' is:

    ฮทโˆ—fsTokenโ€‹ ------ โ‘ ;

    The shadow inherited by P' from P is:

    sTokenAmount_P*accSPS_P - SDebt_P

    Or

    sTokenAmount_P*๏ผˆaccSPS_P - accSPSDown๏ผ‰------- โ‘ก;

    Obviously, at this point โ‘ก>=โ‘ .

    Thereafter, the Meta Defender protocol monitors for changes in โ‘ก. As the earlier policies gradually expire and are cancelled as well as the capital is unfrozen, the value of โ‘ก gradually decreases (of course, the relationship between index and latestUnfrozenIndex is taken into account, and โ‘ก is really reduced when index <= latestUnfrozenIndex.

    When โ‘ก < โ‘ , the difference between โ‘  and โ‘ก is the capital of P being unfrozen. P extracts it, updates the value of โ‘  to โ‘ก, and waits for the next unfrozen part.

    As accSPSDown increases, the value of โ‘ก eventually goes to zero. Zero is the minimum value of โ‘ก and cannot be a negative number.

    After โ‘  goes to zero, all residual capital of P finishes withdrawing.

    4.4 Leveraged Liquidity Mining Rewards Mechanismโ€‹

    The holder of sToken, i.e. the underwriter of Meta Defender, is entitled to the Leveraged Liquidity Mining rewards.

    In order to encourage underwriters to provide long-term, stable capital, sToken holders are required to hold their sTokens for a certain period of time (approximately 14 natural days, with minor variations depending on the speed of block creation on the mainnet) before they can participate in the withdrawal of this Rewards.

    After withdrawing from the Capital Reserve and destroying the sToken, the holder will lose the eligibility to withdraw the proceeds. The mining proceeds will be hosted separately by Meta Defender's governance contract and will be claimed from the pool for sToken.

    Ecosystem Fitโ€‹

    Meta Defender will use the stablecoin in parachains as the currency for buying cover, underwriting and for payouts of claims. Currently Meta Defender is planned to be deployed with ink! Smart contract and compatible with Substrate and XCM. Ultimately, we would like to provide insurance services to the main parachains and major protocols in the Polkadot Ecosystem. Also, by introducing XCM, we would like to achieve cross-chain insurance.

    Our Leveraged Mining component will cooperate with top liquidity mining protocols in Polkadot Eco, which will increase the TVL of those projects.

    We are planning to integrate the Blockchain Oracles function in the Polkadot Ecosystem๏ผŒe.g. Phala, which will expand our insured subject-matters to more off-chain scenarios.

    Our target audience will be the users who would like to buy covers for their digital assets in the Polkadot Ecosystem, as well as those who would like to utilise their idle capital to become an underwriter and gain proceeds from Liquidity Mining in the Polkadot Ecosystem and rewards from our insurance protocol.

    As the rapid development of Defi markets, asset holders are looking for an insurance protocol that can protect them when emergencies like theft, cyber attack and data leakage happen. Meta Defender is designed for providing such services.

    There is an insurance protocol called Nsure that received a grant from W3F. Meta Defender has following highlights compared to Nsure๏ผš

    Meta Defenderโ€™s pricing model is an upgraded Automated Market Maker Model purely based on the relations between supply and demand. Therefore, there is no need to manually adjust the factors for calculating the premium rates because it's auto-generated.

    Meta Defenderโ€™s Leveraged Mining will cooperate with Liquidity Mining protocols in the ecosystem while Nsure has their own capital mining pool. We believe, cooperating with top Liquidity Mining protocols in the ecosystem will maximise the returns with the capital that underwriters inject to the protocol.

    We are also planning to provide insurance service for more off-chain scenarios by integrating blockchain oracles, such as flight cancellation insurance.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Alvin: With a background in financial investing and insurance consulting, as well as working a Tech Lead in a Venture Capital, Alvin brings his varied experience to Meta Defender. Alvin is also the external consultant for two AI based projects of China Life Insurance Company, namely an operational decision making tool and a fraud detection technology. He also has massive experience in blockchain, by constructing a DEX and IDO platform. He would like to integrate his expertise in Web3.0 with knowledge in insurance industry and provide a better solution to Blockchain insurance.

    Angie: Angie is a Data Scientist in a ASX-listed Fintech in Australia. She has extensive experience in Finance industry since 2017 and has profound understanding regarding tech utilization in finance industry. Using her expertise, she co-designed the pricing model and business flow of Meta Defender. She is also a crypto enthusiast and fascinated by She masters Solidity, Python Vue.js and Node.js.

    0xdeadbeef: He is a web3.0 coder and researcher for more than 4 years. He has a master's degree from Shanghai Jiaotong University and a major in finance. He masters solidity, Golang, Rust, Python, and Nodejs. In his past working experience, he worked for a public chain company and researched and developed on-chain DeFi projects, especially in options markets. He has much experience in EVM compatible blockchains. Recently, he has been passionate about insurance, which may be a new area in DeFi. Through his working experience in the on-chain option market, he considered there are many similarities between options and insurance.

    Team Code Reposโ€‹

    Team Repo

    Team Member

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Basic Functionalitiesโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to deploy and use the ink! smart contract.
    0c.Testing GuideCore functions will be covered by unit tests, along with detailed explanation step by step.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.ink! smart contractAn ink! smart contract that will enable the digital assets holders to buy cover and the capital holder to become an underwriter.
    2.Front-end e2e testWe will use Cypress.io as an e2e testing framework for the Front-end automated test.

    Milestone 2 Substrate + XCMโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how Meta Defender protocol enables cross-chain insurances.
    0c.Testing GuideCore functions will be covered by unit tests, which will be considered as another way of explanation
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains the functionalities Meta Defender provides, which will cover: 1. auto-pricing model; 2. economic model of insuring and underwriting; 3. how we achieve cross-chain insurance through substrate and XCM and open source this part of code.
    1.Cross-chain supportEstablish a local parachain testnet and two local parachains A and B with sovereign account in each other. With smart contract deployed on A parachain, allow the user to buy cover and receive his claim from addresses on the B parachain through XCM.
    2.Manual of interaction between ink! and front-endWe will provide a manual regarding constructing an interface for the interaction between front-end and ink! smart contract & Polkadot.js wallet, just like what web3.js and ethers.js have done in the EVM ecosystem.

    Future Plansโ€‹

    Short-term plan: Expand the subject-matter insured. We plan to provide insurance on at least five parachains and/or products running on them in the Polkadot Ecosystem.

    Medium-term plan: With the aid of blockchain oracles function, to cover real-life off-chain cases. A potential use case can be flight cancellation insurance.

    Long-term: We would like to cooperate with professional security service providers and to undertake detailed risk analysis on the subject-matter insured and potential projects, which enables us to issue security rating reports and become the security rating agency in web3.0 realm.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Meta Defender is the first-place winner of Acala Hackathon: https://twitter.com/AcalaNetwork/status/1527290444379394049?s=20&t=u60vX2VZTWvSoZ1x62Y-sA

    Meta Defender is also in the 2022 cohort of Web3.0 Bootcamp supported by Web3 Foundation, Parity and Wanxiang Blockchain Labs.

    Since we have participated in a few activities in the Polkadot Ecosystem and have a profound understanding of the eco, we have been advised that we could apply for the grants program and grow with Polkadot.

    - + \ No newline at end of file diff --git a/applications/Multix-a-simple-UI-for-complex-multisig.html b/applications/Multix-a-simple-UI-for-complex-multisig.html index ede4f621529..1617549c042 100644 --- a/applications/Multix-a-simple-UI-for-complex-multisig.html +++ b/applications/Multix-a-simple-UI-for-complex-multisig.html @@ -4,7 +4,7 @@ Multix a simple interface for complex multisigs | Web3 Foundation Grants - + @@ -19,7 +19,7 @@ Selection_1151

    Once the first proposal approved, the multisig and its (abstracted) proxy are ready to use. Selection_1152

    Development Roadmap ๐Ÿ”ฉโ€‹

    This section should break the development roadmap down into milestones and deliverables. To assist you in defining it, we have created a document with examples for some grant categories here. Since these will be part of the agreement, it helps to describe the functionality we should expect in as much detail as possible, plus how we can verify and test that functionality. Whenever milestones are delivered, we refer to this document to ensure that everything has been delivered as expected.

    For each milestone,

    โšก If any of your deliverables is based on somebody else's work, make sure you work and publish under the terms of the license of the respective project and that you highlight this fact in your milestone documentation and in the source code if applicable! Teams that submit others' work without attributing it will be immediately terminated.

    Overviewโ€‹

    Milestone 1 - Create and manage multisig callsโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can create a multisig. The steps should be self explanatory for anyone having basic multisig knowledges.
    0c.Testing GuideThe scope of this project being too small, no testing will be done in a first step.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone..
    0e.ArticleWe will publish an article that explains the basics of multisigs and show the benefits of using this interface to create more complex multisigs.
    1.creation screenUsers will be able to create a multisig based on a list of signatories and a threashold.
    2.indexerTo provide a smooth user experience, a subsquid indexer will make sure to track multisig interractions. The Docker will be made available
    3.home screenThe home screen will allow to select the available multisig and see the signatories, the threshold along any pending request
    4.request approvalUpon reviewing pending approvals, users are able to approve pending approvals and submit the final extrinsic without any external communication with other signatories.
    5.pallet supportThe multisig will be based on the [mutlisig](https://github.com/paritytech/substrate/tree/master/frame/multisig) pallet, also using [proxy](https://github.com/paritytech/substrate/tree/master/frame/proxy) and [utility](https://github.com/paritytech/substrate/tree/master/frame/utility) pallets to handle the different flows.
    6.stackBoth front-end and back-end are using Typescript. The front-end is built using React, it will connect to a blockchain node for live information such as the pending proposals, and to user wallets such as Polkadot-js extension to allow users to sign extrinsics. The backend is made of a subsquid indexer that is tracking multisig interractions.

    Future Plansโ€‹

    As mentioned above, this is requesting the funding to get things started with a functionnal UI, wihout too many bells and whisles. Many needs have already been identified for institutions and DAOs. Chainsafe is dedicated to make this the stepping stone of a long road. Other features such as the flow to rotate signatories, make more complex extrinsics from the UI or add some proxies to the multisig can be added at next steps.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? At W3F and Parity's request

    - + \ No newline at end of file diff --git a/applications/NFTStore_Network.html b/applications/NFTStore_Network.html index 3daad41d015..f79d6ee2b84 100644 --- a/applications/NFTStore_Network.html +++ b/applications/NFTStore_Network.html @@ -4,13 +4,13 @@ NFTStore | Web3 Foundation Grants - +
    Skip to main content

    NFTStore

    • Proposer: NFTT Studio
    • Payment Address: 1AeR4htoGwDRMpw7S2TTrzjJxeGLZsopiE

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Introductionโ€‹

    NFTStore is an exclusive public chain for managing NFT assets. Users can not only issue their own NFTs, but also trade NFT transactions. The project is developed based on substrate 2.0. In the first phase of the design, we will write the business code at the runtime level. The project actually needs to consider whether to introduce the contract layer. In the economic model, we will fully give the token holders the transaction income on the platform Store. NFT is one of the important ways for the application of blockchain technology to approach life off-chain. We hope that this public chain will provide more possibilities for real-world assets on the chain. In addition, there are members of the team who have rich e-commerce experience. I believe that NFTStore has become the amazon.com of the blockchain and the best trading platform for digital assets in the world.

    Project Detailsโ€‹

    Architectureโ€‹

    NFTStore based on Substrate 2.0 and the Polkadot. Contains NFTStore node, pallet_nft, pallet_store and Front End.

    img

    • NFTStore Node is the customized chain node built by Substrate 2.0 .

    • pallet_nft is used to create and manage NFT assets.

    • pallet_store is responsible for NFT sales.

    • Front End provides Web UI for everyone to interact with the NFTStore. Front End will be built with React.

    • NFTStore Token $NFTT is the native token of the NFTStore, and it will play the role of governance and other utilities. $NFTT is necessary to secure and power the chain.

    Data Structureโ€‹

    img

    As shown above, NFT design adopts ERC721 protocolใ€‚

    Main pallet storage and methodโ€‹

    API-IDPallet NameStoragePublic Method
    1pallet_nft NFTMap get(fn get_nfts ): map hasher(blake2_128_concat) T::AcountId => NFT;pub fn create_nft(name:Vec<u8>,description:Vec<u8>, imageUrl:Vec<u8>, type:u8, amount:u256 )
    pallet_nftERC721:- safeTransferFrom(from:AccountId,to:AccountID,tokenId:u256,data:Vec<u8>)
    - safeTransferFrom(from:AccountId,to:AccountID,tokenId:u256)
    - transferFrom(from:AccountId,to:AccountID,tokenId:u256)
    - approve(approved: AccountId, tokenId:u256)
    - setapproveForAll(approved: AccountId, approved:bool)
    - getApprove( tokenId:u256)
    - isApproveForAll(owner: AccountId, operator:AccountId)
    - burn(from: AccountId, tokenId:u256)
    2 pallet_store StoreMap get(fn get_onsale):map hasher(blake2_128_concat) u8 =>Vec<NFT>;pub fn sell_setting(contractAddress:Vec<u8>, tokenId:u256, price:u256 )
    pub fn buy(contractAddress:vec<u8>, tokenId:u256)

    UIโ€‹

    img

    https://www.figma.com/file/o3N4WbUFlBPX8gXpAl4iBN/NFT

    Team ๐Ÿ‘ฅโ€‹

    Team Membersโ€‹

    • blackjooohn - CTO/Project Lead
    • MingMing - Product Director & FE
    • Dragon - Full-stack Developer

    No Legal Entity

    Team Experienceโ€‹

    blackjooohn

    • Over 15 years of experiences in Development and Management
    • Has plenty of experience in Software Development and Blockchain Development
    • Currently, focus on Cross-chain technologies

    MingMing

    • Former Product Manager in Baidu
    • Former Product Manager in Alibaba

    Dragon

    • Full-stack Developer
    • Over 20 years of experiences in Product Development and Management
    • Has plenty of experience in Software Architecture

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-time equivalent (FTE): 2
    • Total Costs: 0.4 BTC

    Milestone 1 โ€” Verify Production of Concepts (POC) and Implement Substrate Modulesโ€‹

    • Estimated Duration: 2 months
    • Full-time Equivalent (FTE): 2
    • Costs: 0.4 BTC

    In the first milestone, the features for the POC will be implemented and tested by limited users.

    The following features will be included:

    • NFTStore Node
    • Pallet_nft
    • Pallet_store
    • Front End
    NumberDeliverableSpecification
    0a.LicenseApache License 2.0
    0b.DocumentationDocuments containing the description of whole architecture design for NFTStore.
    0c.Testing GuideWe will provide a full test suite and guide for NFT .
    1a.Node RepoComplete the deployment of the basic public chain
    1b.NFTStore token$NFTT Complete the design of the economic model
    2a.Pallet_nftComplete the development of pallet_nft and realize the ERC721 standard. Related nft interfaces that need to be delivered
    2b.Pallet_storeComplete the development of pallet_store . Related store interfaces that need to be delivered
    3.Front EndComplete the development of the basic interactive page, the specific page can refer to: https://www.figma.com/file/o3N4WbUFlBPX8gXpAl4iBN/NFT
    4.Docker ImageThe NFTStore Network docker image contains the POC version running anywhere to verify the idea of the NFTStore.

    Future Plansโ€‹

    • In phase 1, our goal is to make it easy for users to create NFTs and trade their NFTs.
    • In phase 2, integrate more NFTs from other platforms on NFTStore through Polkadot cross-chain technology.
    • In phase 3, more integration with off-chain, such as holding art exhibitions
    - + \ No newline at end of file diff --git a/applications/NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.html b/applications/NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.html index ef70115cca2..60f43d31ba5 100644 --- a/applications/NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.html +++ b/applications/NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.html @@ -4,7 +4,7 @@ Protocol for NFT Migration and Data Exchange | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ So far, we have determined that the protocol must allow for the following features:

    Milestone 2 โ€” Checked Migration Processโ€‹

    We will write up the โ€˜Checked Migrationโ€™ process which includes a security protocol to ensure that both the sender and the receiver are satisfied with the migration outcome. This is especially important if NFT's are migrating from/to a trustless universe (eg : a public decentralized blockchain) toward/from a centralized/private universe. This process is NOT a fully decentralized trustless process itself in order to accomodate for a wide array of possible origin and destinations, but it does allow decentralized trustless outcomes while guaranteeing authenticity and ownership of the NFT at every step.

    The main purpose of this migration process is for NFT publishers to allow their users to effortlessly migrate their tokens with the least amount of efforts required. NFT publishers could offer users to do the whole migration with a single gas spending approve() from an NFT owner and the rest trough meta-transactions by the publisher. The publisher would then sign the migration as properly done after having minted and transferred the token on the destination blockchain. By essence, most NFTs are not trustless assets as their publishers own real world IP rights to them, and it is hence acceptable to use said publishers as relayers. This is standardizing a process that would otherwise require the publisher to update their original NFT smart contracts or NFT owners to burn their original NFT token in order to get a new one minted on the destination universe.

    Milestone 3 โ€” Trustless Migration Processโ€‹

    We will write up the โ€˜Trustless Migrationโ€™ process which is designed to be used when the destination universe have trutsless state reading capabilities of the origin universe.

    Milestone 4 โ€” Standard and Documentation for Cross-universe Migrationโ€‹

    We will write up the standard and documentation for cross-universe migration, which includes โ€œnecessaryโ€ and โ€œoptionalโ€ data for optimization. This is a summarized write up of both the previous milestones but writen as specifications for implementations, including the predicate and postulate of each message and what they mean in term of state on the source and destination universe.

    Future Plansโ€‹

    We will implement this standard for EVM-compatible chains. Our main goal is the ability for any Ethereum mainnet NFT to be painlessly migrated to Moonbeam on the Polkadot network.

    Additional Information โž•โ€‹

    This proposal is a part of the wider NFT.com venture.

    Learn more about our vision for the bridge here: link

    - + \ No newline at end of file diff --git a/applications/Nolik.html b/applications/Nolik.html index 20dc0bf207c..7ddd494c3e7 100644 --- a/applications/Nolik.html +++ b/applications/Nolik.html @@ -4,7 +4,7 @@ Nolik | Web3 Foundation Grants - + @@ -143,7 +143,7 @@ We also have been working on fundamental research and development of a framework that simulates the behavior of a blockchain on a network level.

    We've analyzed the most popular consensus algorithms (PoW, PoS, dPoS BFT, etc.) and blockchain platforms (Bitcoin, Ethereum, Cordana, Ripple, Waves, Hashgraph, etc.).

    I also was fortunate to be a speaker and moderator of technical panel discussions at Blockchain Economic Forum in Singapore and San-Francisco (cross-chain communication, mining, security, scalability, etc.) and to work with the Moscow blockchain community as head of educational Chain{Dev} project.

    Full-stack web developer, Python, JS, Docker, SQL, Blockchain. Rust experience: 3+ months, but moving fast.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Those are research documents that lead me to this project.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement Substrate Modulesโ€‹

    This milestone will allow the operation of a local dev chain.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation of the code and a basic tutorial that explains how a user can spin up one of our Substrate nodes.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Substrate module: Account RulesWe will create a Substrate module that will allow users to create a wite-list and a black-list of senders
    2.Substrate module: Message ValidationWe will create a Substrate module that will validate the message on sending stage to accept or reject it
    3.Substrate chainBoth modules of our custom chain will allow users to set up account rules and validate incoming messages on whether the senders have a right to send a message or not. In case of a rejected transaction user will get a related error message

    Milestone 2 โ€” Develop CLI toolsโ€‹

    This milestone will allow the usage of CLI tools, which are going to be written in Rust language. They will allow users to interact with the network by composing, sending, and accepting messages.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation** of the code and a basic tutorial that explains how a user can use our CLI tools and interact with a network.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to compile CLI tools for further usage
    0e.ArticleWe will publish an article that explains the idea of the protocol, how to deploy a local dev node and start messaging
    1.CLI: composeWe will create a CLI tool that will allow users to compose a message to one or several recipients
    2.CLI: sendWe will create a CLI tool that will allow broadcasting the message to the network
    3.CLI: getWe will create a CLI tool that will allow to download and read received messages if any
    4.CLICLI tools will allow users to compose messages, send them to recipients and read incoming messages on request

    Future Plansโ€‹

    Short-termโ€‹

    Long-termโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Personal recommendation of my friends:

    - + \ No newline at end of file diff --git a/applications/NuLink.html b/applications/NuLink.html index 44a57529765..079b85da025 100644 --- a/applications/NuLink.html +++ b/applications/NuLink.html @@ -4,13 +4,13 @@ NuLink | Web3 Foundation Grants - +
    Skip to main content

    NuLink

    • Proposer: Pawn
    • Payment Address: 0xf7410438ead9e89EEd5ca6e61a11E862C297ca0e

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Our project NuLink is trying to bridge the NuCypher Network to the Polkadot Ecosystem. The NuCypher Network is a decentralized network of nodes that perform threshold cryptography operations serving users with secrets management and dynamic access control; in particular, NuCypher currently offers a threshold proxy re-encryption solution that enables secure data sharing which can be used to construct content management platforms, secure messaging, encrypted NFTs, and many other applications.

    Through our project, users and applications from Polkadot could take advantage of NuCypher Network. For example, a user Alice in Polkadot could share her private data to another user Bob using the integration from our project, without worrying information leaking to any third party, thanks to NuCypher cryptographic assurance.

    The main components of the project are:

    1. A Nuproxy pallet which can retrieve the information of stakers and bonding workers from NuCypher contracts in Ethereum to Polkadot parachain;
    2. A Policy pallet which holds policy fees and distributes them to nodes of the network.

    Project Descriptionโ€‹

    • In the NuCypher Network, all the cryptography operations are currently performed in an off-chain side channel. We can reuse this side channel in our project. We only need to take care of the on-chain operation from Ethereum to Polkadot. The on-chain operation mainly includes two parts: Stakers need to register and get rewards on-chain, while Alice needs to grant access to Bob and pay fees to stakers on-chain. NuLink would focus on migrating the on-chain operation from Ethereum to the Polkadot parachain.
    • We will develop a Nuproxy pallet which can retrieve the information of stakers and bonding workers from Nucypher contracts in Ethereum. At the current stage we consider constructing a watcher network managed by the NuCypher team. The watcher network would relay such information to the Nuproxy pallet.
    • The watcher network is simply constructed by a single watcher node in the current version. The Nuproxy pallet would check the signature of the watcher node to pass the update request. And in the future we would expand the watcher network to a multi-signature network constructed by a certain number(say N) of watcher nodes. And their corresponding public key would be recorded in the Nuproxy pallet when first deployed. The update request must obtain more than the 2/3 signature of the total watcher nodes to be valid. The Nuproxy pallet would check the signature when receiving the update request. The locking period of Ursulas network is 1days, so the watcher network would send the update request at the same pace.
    • In the future we may use ETH-Polkadot bridge such as Snowbridge to retrieve such information from Ethereum instead of the watcher network. The details would be updated once we finish the design.
    • We would also develop a Policy pallet which can hold policy fees and distribute them in the Polkadot parachain. Through this pallet, Alice in Polkadot could issue a policy in the polkadot parachain and pay the policy fee in the Polkadot parachain. And the worker of Ursulas could withdraw the reward in the Polkadot parachain.

    Ecosystem Fitโ€‹

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Pawn
    • Sam

    Team's experienceโ€‹

    • Pawn: Currently pursuing a PHD degree in cryptography from UCAS. Familiar with most cryptographic technology such as Fully Homomorphic Encryption, Zero Knowledge Proof and Secure Multi-party Computation.
    • Sam: Tutor for Blockchain Engineer Lecture Hall of Internet Industry Research Institute of Tsinghua University; Former Huobi technical expert; proficient in DEFI project development, developer of KOKOSWAP, Perpexchange, TMK NFT, YFX.

    Team Code Reposโ€‹

    https://github.com/pawnz0/NuLink

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 6 month
    • Full-time equivalent (FTE): 2
    • Total Costs: 10,000 DAI.

    Milestone 1 Implement Nuproxy Palletโ€‹

    • Estimated Duration: 4 month
    • FTE: 2
    • Costs: 5,000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both documentation of the code and a basic tutorial that explains how a user can use the pallet.
    0c.Testing GuideThis milestone will have unit-test for each function to ensure functionality. In the guide we will describe how to run these tests.
    1.register_watcherThis function would record the public key of the watcher nodes and would be executed when the Nuproxy pallet first deployed.
    2.UpdateStakersThis function would provide the functionality of updating the information of current stakers and bonding workers of Ursulas network. It will be restricted to watchers.
    3.GetActiveStakersThis function would return a list of active stakers by random sampling.

    Milestone 2 Implement Policy Palletโ€‹

    • Estimated Duration: 2 month
    • FTE: 2
    • Costs: 5,000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both documentation of the code and a basic tutorial that explains how a user can use this pallet.
    0c.Testing GuideThis milestone will have unit-test for each function to ensure functionality. In the guide we will describe how to run these tests.
    1.CreatePolicyThis function would lock the fee for a specific policy for a locking period.
    2.RevokePolicyThis function would revoke a specific policy and refund the unconsumed policy fee depending on the locking period.
    3.MintThis function would computes and transfers the policy fee to the stakerโ€™s account
    4.WithdrawThe staker could call this function to claim the reward fee.

    Additional Information โž•โ€‹

    We have discussed this project with the NuCypher core team and got some technical support from the NuCypher team.

    We have implemented the watcher nodes independently and not funded by this proposal. The owner who deployed the Nuproxy pallet could either manually update the information from Ethereum, or use our watcher node updating it automatically. Here is the (link)the watcher nodes.

    Update & Amendmentsโ€‹

    2022/02/27โ€‹

    We underestimated the total work and the time-line has now been exceeded by several months. We have already submitted our work and are waiting for review.

    This amendment updates the name of the mirror pallet to the Nuproxy pallet, and the name of the Policy Management pallet to Policy pallet.

    We have decided to implement the watcher network as one single node in the current version. And we will keep working on this and support the multi-nodes network in the future.

    - + \ No newline at end of file diff --git a/applications/Omniverse DLT.html b/applications/Omniverse DLT.html index 8b5845c801c..68c8f6f4ee0 100644 --- a/applications/Omniverse DLT.html +++ b/applications/Omniverse DLT.html @@ -4,7 +4,7 @@ Omniverse DLT | Web3 Foundation Grants - + @@ -15,7 +15,7 @@ We will make the O-DLT an open source-protocol so that everyone in Polkadot/Kusama ecosystem can use it to publish their own omniverse tokens all by themselves. We will provide the following things to Polkadot/Kusama:

    The above components can be uses as single component for all developers of Polkadot/kusama.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    We are Dante Network team and our team is composed of several skilled Web3 geeks, and some of us have more than 10 years of technology working experience.
    We have got several hackathon rewards, especially the first prize in the Polkadot Asian Hackathon in 2022 summer.
    We have finished the first step of Dante Network granted by Web3 Foundation. Details can be found here and here.

    Team Code Reposโ€‹

    To be more clearly, we have created a new organization to manage the related code:

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Development Status ๐Ÿ“–โ€‹

    Before apply for this grant, we have done some neccessary researches and built some prototypes to verify them.

    After the simulation, we believe that the Omniverse DLT is achievable on Polkadot and other chains.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” O-DLT: Substrate Palletโ€‹

    โ— The default deliverables 0a-0d below are mandatory for all milestones, and deliverable 0e at least for the last one.

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.Documentation- We will provide docs to explain how O-DLT works in a high-level
    - We will provide dev docs to explain how to develop an O-DLT component in Substrate Pallet
    - We will provide tutorial docs to explain how to use it
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains what was done/achieved in this milestone as part of the grant.
    1.Substrate module: omniverse assetsWe will create a Substrate module that will manage the Omniverse tokens, which will be derived from standard pallet assets
    2.Substrate module: omniverse protocolWe will create a Substrate module that will manage the underlying omniverse functions like omniverse account, omniverse signature, omniverse verification, etc.
    3.Substrate chainModules omniverse assets, protocol of our custom chain will interact in such a way that can make creation, omniverse mint, burn, and transferring for o-tokens
    4.Off-Chain Tools: Operate the o-tokensWe will provide off-chain tools to operate o-tokens for both Substrate Pallets

    Milestone 2 โ€” Ink! tech stack and Omniverse Swapโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.Documentation- We will provide docs to explain how the Omniverse Swap based on O-DLT works in a high-level
    - We will provide dev docs to explain how to develop an O-DLT component in Ink! smart contract
    - We will provide tutorial docs to explain how to use the omniverse swap
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) to run Synchronizers along with the documentation of the setup.
    0e.ArticleWe will publish an article that explains what was done/achieved in this milestone as part of the grant.
    1.Substrate module: swapWe will create a Substrate module that will make exchanges for different o-tokens.
    2.Substrate chainModules omniverse assets, protocol & swap of our custom chain will interact in such a way that can make swaps between two different kind of o-tokens, user can add liquidity themselves, the O-AMM model can be calculated off-chain and verified on-chain.
    3.Ink! smart contract implementationWe will create the fully O-DLT protocol in Ink! tech stack. It will have the same functions as in Substrate Pallets
    4.Off-Chain SynchronizerWe will provide the source code and the executable program of the off-chain synchronizer.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    Firstly, we really appriciate the help and support we have got from Web3 Foundation, with which we have completed the first steps of Dante Network.

    Secondly, we want to report some new progresses and plans of Dante Network.

    Thirdly, as always, we highly endorse the philosophy of the Web3 Foundation. We are continuing to build more and deeper on Polkadot.

    - + \ No newline at end of file diff --git a/applications/OpenSquare-offchain-voting.html b/applications/OpenSquare-offchain-voting.html index 805e4c56926..3a8d455f3c1 100644 --- a/applications/OpenSquare-offchain-voting.html +++ b/applications/OpenSquare-offchain-voting.html @@ -4,14 +4,14 @@ OpenSquare off-chain voting for Polkadot ecosystem | Web3 Foundation Grants - +
    Skip to main content

    OpenSquare off-chain voting for Polkadot ecosystem

    • Team Name: OpenSquare
    • Payment Address: 0x4905083abdD13bd95345A871701Fd0b08AbD46d1 (USDT)

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    In short, you can see this proposed platform as snapshot in the polkadot ecosystem.

    Though Polkadot/Kusama and most other Substrate based chains have on-chain governance and runtime can be easily upgraded with democracy. We think this platform still make sense with following reasons:

    • Compared to the formal on-chain votes, this platform provides not so formal off-chain signed polls which may help token holders and community members engage more in the ecosystem building.
    • Compared to Polkassembly polls on post:
      • users have to sign their votes and the signed data will be stored on IPFS
      • users donโ€™t have to do any registration.
      • Different strategies can also be provided to calculate the final result, rather than simply count the vote numbers.
    • Not all on-chain systems with assets on Substrate based chains can upgrade with democracy, like assets issued on Statemine, ERC-20 assets which may be issued on Moonriver, Karura, Shiden, etc.

    Project Detailsโ€‹

    Off-chain votes will be an important part of OpenSquare collaboration platform. Other planned collaboration forms include bounties, payment QA, short term employment, etc. Key components in this proposal include:

    • Predefined spaces where users can create proposals. It will definitely include Kusama and Polkadot, current para-chains with very high possibility.
    • Proposal list in one space where users can view the closed or ongoing proposals.
    • Proposal detail page where users can view the detail and the signed votes.
    • A proposal discussion arena where users submit the signed messages and here we expect chaos.
    • An authoring page where users can create proposals, and set the corresponding snapshot height, start and end date(height).
    • Archive nodes interaction with which we read usersโ€™ balances on the corresponding snapshot block height.
    • A backed server to interact with the node(Polkadot, Kusama, etc), store the organized data to DB, handle IPFS storage, provide APIs to get data.

    os_grant_voting

    Some implementation notes:

    • We have to call polkadot.js extension to sign the voting/poll, and some discussion messages.
    • About voting power, since Polkadot/Kusama have proxy accounts, so we have to support proxy account vote on behalf of the original one.
    • In this proposal, we will implement balance of account and quadratic balance of account strategies for Polkadot and Kusama. It means if Alice's balance is 100 at one chain height, her voting power will be 100 and 10 by these 2 strategies.
    • We have a partnership with Crust, and we may store data to IPFS through decoo that crust granted.

    Ecosystem Fitโ€‹

    • Providing off-chain voting/polls to help token holders/community members engage more in ecosystem building.
    • Flexible strategies help produce different voting/poll results which bring us different opinions from the on-chain tallying methods.
    • snapshot is popular for Ethereum stack projects, mainly for governance, and currently we didn't see similar projects in Polkadot ecosystem.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Yongfeng Li(@wliyongfeng), Full stack developer
    • Chaojun Huang(@hyifeng), Full stack developer
    • Wentao Chen(@qiyisi), Full stack developer
    • Yizhou Xin(@YoshiyukiSakura), Full stack developer
    • Alcazar(@Popoulosss), Designer
    • Yaping Wu, BD and execution member

    You can see our team with this link.

    Contactโ€‹

    • Registered Address: 3 FRASER STREET #05-25, DUO TOWER, SINGAPORE 189352
    • Registered Legal Entity: OPENSQUARE FOUNDATION LTD.

    Team's experienceโ€‹

    We have more than 3 years experience with Substrate/Polkadot related tech stack. Our recently developing products include:

    • doTreasury. We can now see it as a treasury business explorer but it aims to improve the treasury mechanism with retrospection.
    • Statescan, a fungible asset explorer for Statemint implementation chains.
    • OpenSquare bounties business built on substrate. We got a grant for this, and please check details here.

    We are honored that either dotreasury or statescan get support from kusama or polkadot treasury, and our work about bounties is granted by w3f previously. We are confident to deliver a high quality and usable off-chain voting site.

    Team Code Reposโ€‹

    https://github.com/opensquare-network/

    Team members github accounts:

    Development Roadmap ๐Ÿ”ฉโ€‹

    Only 1 milestone in this proposal, while the main goal is to check the feasibility of off-chain voting in the polkadot ecosystem. We will put more features like more plugins and strategies in future proposals, but after this proposal we will launch it and make it available to the community.

    Milestone 1 โ€” Implement Basic off-chain voting/polls logic for Polkadot & Kusama

    • Estimated duration: 2 weeks
    • FTE: 3
    • Costs: 8,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.CodeCode will be open source, organized in one monorepo by yarn workspaces, hosted on OpenSquare github account. It will be implemented in JavaScript, React for fronted, koa for backend. Either fronted and backed will depend on polkadot.js, while fronted will also depend on extension-dapp to interact with polkadot{.js} extension.
    0c.DocumentationWe will provide a documentation site to explain necessary concepts, how this site work, and some user workflows.
    0d.Test casesCore functions will be covered by unit tests to ensure functionality and robustness. They will could be verified in simple npm scripts.
    1.User story 1Alice opens OpenSquare.io(domain not finally decided) and she can see spaces at least include polkadot and kusama. She can see a closed and ongoing proposal list after clicking a space.
    2.User story 2Alice will see the proposal description, votes records and the final result or analysis/distribution on a closed proposal page.
    3.User story 3Alice votes yes on an ongoing proposal with polkadot{.js} extension, she can see her vote and re-vote to override the previous one. The reason that she changed her vote is that she checked the discussion and found some related news.
    4.User story 4Alice created a proposal with the title โ€œShould there be a specified UI for the society features?โ€ and some description, and there are 2 choices: yes and no. She chose the voter balance as the final result strategy, while she can also choose sqrt balance as the strategy. With a very high sumed balance vote yes to Aliceโ€™s proposal, she now is very confident to seek more support to go on with following actions.
    5.User story 5Bob wanted to create a proposal at kusama height 1000, but failed, because his account has 0 balance. Anybody can create a proposal, but the minimum requirement is having at least 10 KSM at the target height.

    Future Plansโ€‹

    • Add more spaces, and in the future users may create their own space and customize it.
    • Support plugins and more strategies so users can customize the process and voting result.
    • Support voting by assets issued on statemine or erc-20 tokens.
    - + \ No newline at end of file diff --git a/applications/OpenSquare_paid_qa_protocol.html b/applications/OpenSquare_paid_qa_protocol.html index 05e13e20a56..736908a5938 100644 --- a/applications/OpenSquare_paid_qa_protocol.html +++ b/applications/OpenSquare_paid_qa_protocol.html @@ -4,7 +4,7 @@ OpenSquare Paid QA protocol | Web3 Foundation Grants - + @@ -39,7 +39,7 @@ will help build a trusted collaboration network. Check more details from our paper, though it's still a draft when writing this proposal.

    - + \ No newline at end of file diff --git a/applications/ParaSpell.html b/applications/ParaSpell.html index b72c02c3375..ad7edb8e10d 100644 --- a/applications/ParaSpell.html +++ b/applications/ParaSpell.html @@ -4,7 +4,7 @@ ParaSpell | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ Para to para screen

    Architecture ๐Ÿ—โ€‹

    Diagram

    Application is purposely designed to be as simple as possible. This guarantees, that all tasks can be done quickly and without extended searching. All necessary screens also feature notifications which will as a milestone explain be callback reactive. The loading screen is only present on the first application & network startup, once accessing the same screen after the application was loaded it will be skipped automatically. The screen serves to register necessary assets in parachain nodes. This is only required to be run once per network startup.

    Technology Stack ๐Ÿ’ปโ€‹

    Ecosystem Fit ๐ŸŒฟโ€‹

    There are not many XCM & XCMP related development tools released currently. We aim to aid this mostly empty space and help developers to understand XCM & XCMP as the current state-of-the-art technology by providing documentation and a user interface in which they can do development tasks more easily and faster.

    In Polkadot and Kusama ecosystem, there are few XCM & XCMP related Dapps in development. These rather focus on standard users mostly. One of mentioned type is called "Morph".

    Unlike the already mentioned "Morph" platform ParaSpell focuses more on developers. ParaSpell features complete network install and startup configuration in one single command. This automatization ensures, that developers do not need to do any extra tasks when they wish to run development nodes locally. ParaSpell also allows developers to open and close HRMP channels between Parachains they connected. Like "Morph", ParaSpell can also transfer fungible tokens in three scenarios. From Parachains to Relay chain, from Relay chain to Parachains & from Parachains to Parachains.

    Our target audiences can be Web3 projects & starting/current blockchain developers.

    Team ๐Ÿ‘ฅโ€‹

    Team members (In order of joining time)โ€‹

    Duลกan Morhรกฤ - Student, project Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava

    Viktor Valaลกtรญn - Supervisor, founder of KodaDot. Faculty of Informatics and Information Technologies STU in Bratislava

    Contact ๐Ÿ“žโ€‹

    Team's experience ๐Ÿ”Žโ€‹

    Team Code Repos ๐Ÿ“šโ€‹

    Team github accounts ๐Ÿง‘โ€๐Ÿ’ปโ€‹

    Team LinkedIn Profiles ๐Ÿง‘โ€๐ŸŽ“โ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉ๐Ÿ› โ€‹

    Overviewโ€‹

    Milestone 1 โ€” Cross-blockchain application for developersโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationInline documentation of code, as well as startup configuration with all necessary commands, included in repository
    0c.Testing GuideCore functionality & user guide will be covered in repository documentation
    0d.DockerFrontend Docker file will be ready
    0e.ArticleSoon to be released on IEEE + Medium article about development of ParaSpell
    1.Wallet loginDevelopers can use their Polkadot js extension wallets to execute transactions XCM from their accounts.
    2.aFull working fund transfer scenario 1Fully working transaction scenario 1 - Relay chain to Parachains
    2.bFully working fund transfer scenario 2Fully working transaction scenario 2 - Parachains to Relay chain
    2.cFully working fund transfer scenario 3Fully working transaction scenario 3 - Parachain to Parachain
    3.aCallback support 1Added callback data support so developers/users can see information about their XCM transactions from UI and in real-time.
    3.bCallback support 2Added callback data support so developers/users can see information about HRMP channel calls from UI and in real-time.
    4.ParaSpell SDKMove calls to separate NPM library
    5.Guide to add new nodes to application and networkSimplified and user-friendly wiki/guide for users to understand how to add new nodes to network startup configuration as well as to add/understand calls used in application

    Future Plans ๐Ÿ”ญโ€‹

    Once everything will be implemented according to the proposed plan application will still be under constant improvement as technology will progress. For example, once the XCMP protocol will be released we wish to deprecate the HRMP protocol we currently use for channels.

    In a long run, we also want to improve design, add new features that can be useful for developers, support for new nodes, and ability to add a new node from the user interface.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Personal recommendation

    About project success so far:

    - + \ No newline at end of file diff --git a/applications/ParaSpell_follow-up.html b/applications/ParaSpell_follow-up.html index bcc16d76b84..276b644c9bd 100644 --- a/applications/ParaSpell_follow-up.html +++ b/applications/ParaSpell_follow-up.html @@ -4,7 +4,7 @@ ParaSpell | Web3 Foundation Grants - + @@ -34,7 +34,7 @@ | Support for transfers: | In three different scenarios | In two scenarios | | Support for local network configuration: | Fully implemented example network configuration that uses maintained Parachain-launch library | Not implemented | | Support for HRMP channel opening/closing: | Fully implemented | Not implemented |

    Unlike the already mentioned "Morph" platform ParaSpell focuses more on developers. ParaSpell features complete network install and startup configuration in one single command. This automatization ensures, that developers do not need to do any extra tasks when they wish to run development nodes locally. ParaSpell also allows developers to open and close HRMP channels between Parachains they connected. Like "Morph", ParaSpell can also transfer fungible tokens in three scenarios. From Parachains to Relay chain, from Relay chain to Parachains & from Parachains to Parachains.

    We are currently in talks with several Parachain teams that like the idea of unified SDK for XCM transfers as much as we do. SDK that unifies XCM can be very helpful for entire ecosystem in our opinion.

    Our target audiences are Web3 projects and starting/current blockchain developers.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Duลกan Morhรกฤ - Student, project Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava

    Viktor Valaลกtรญn - Supervisor, founder of KodaDot. Faculty of Informatics and Information Technologies STU in Bratislava

    Contactโ€‹

    Team's experienceโ€‹

    Team Code Reposโ€‹

    Team Github Profiles ๐Ÿง‘โ€๐ŸŽ“โ€‹

    Team LinkedIn Profiles ๐Ÿง‘โ€๐ŸŽ“โ€‹

    Development Status ๐Ÿ“–โ€‹

    UI that uses XCM SDK has it's functionality implemented already which was main goal of our first proposal. We will shift it towards new version of Vue which is state of the art during fufillment of this proposal. SDK has beta pre-release phase released, it features all 29 nodes that implement xTokens pallet, ability to transfer to & from Relay chains, ability to open & close HRMP channels.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 - Improve ParaSpell UI 1/2 & ParaSpell SDK 1/3โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a usage explanation in readme.md
    0c.Testing and Testing GuideSDK Core UNIT tests will be provided for xTokens Pallet, HRMP pallet, polkadotXCM pallet
    0d.DockerDocker file that allows to test ParaSpell SDK through ParaSpell UI will be provided.
    1.Create scaffold template for Web3 projectsCreate template on Git for Web3 dApps to allow users to start developing and deploying in just minutes, this template will contain different libraries important for Web3 development already preinstalled. Languages planned to be used are Typescript. Stack that will be used is Vue3 (Nuxt 3), pnpm package manager, Polkadot API libraries (Use KodaDot packages if applicable), ParaSpell SDK, UI will consist of basic components (address input (checks if address entered is valid), ballance input (no longer necessity to input lenghty amounts, will have sum conversions) etc.. ), wallet management (PolkadotJS, Talisman, Subwallet), all other not mentioned libraries will be mentioned in readme of template and readme will be linked to delivery.
    2.Implement support for checking asset compatibility through asset palletEach node, that has ability to check which tokens it supports should be automatically queried for this data and SDK should be able to determine compatibility based on data queried.
    3.aAdd support for nodes without xTokens pallet IWe will implement support for transfer scenario Parachain to Relay chain for nodes that do not have xTokens pallet but have polkadotXCM prebuilt template pallet. (SDK will be able to determine which pallet to use on which Parachain automatically)
    3.bAdd support for nodes without xTokens pallet IIWe will implement support for transfer scenario Parachain to Parachain for nodes that do not have xTokens pallet but have polkadotXCM prebuilt template pallet. (SDK will be able to determine which pallet to use on which Parachain automatically)
    4.Make SDK easier to useMerge Parachain to Parachain & Parachain to Relay chain scenarios in SDK into one scenario that will be able to adapt based on details provided (if destination node id not provided, then assume transfer is for relay chain, also if token is compatible with relay chain), this will replace need for calling two functions for each scenario with only one function covering both scenarios eg. send() instead paratopara() & paratorelay()

    Milestone 2 - Improve ParaSpell SDK 2/3โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a usage explanation in readme.md
    0c.Testing and Testing GuideSDK Core UNIT tests will be provided for pallets mentioned previously, script that checks pallets, functionality to check data that does not change, builder pattern
    0d.DockerDocker file that allows to test ParaSpell SDK through ParaSpell UI will be provided.
    1.Add support for checking data that does not changeThere are things that do not change, such as base token configuration (Polkadot, DOT token, 10 decimals), (Astar, ASTR, 18 decimals) This can be imported from @polkadot/network library to have better support for different transfer scenarios
    2.Rewrite SDK to builder patternBest thing we can do to support multiple pallets and make it simplier for developers would be a Builder pattern functionality would look like: import { Builder } as โ€˜@paraspell/sdkโ€™ and then building of call would be something in sence: const call = Builder(api).from(โ€˜bsxโ€™).to(โ€˜ksmโ€™).teleportTokens(โ€˜KSMโ€™).addr('destinationAddr').sum(currencySum).asV3().build()
    3.Make a map of compatible <chain, pallet>Before each SDK release there should be a script that connects to the compatible nodes, checks all relevant available pallets xTokens, polkadotXCM, asset pallets, HRMP pallets) and saves them to the map.
    4.Use turborepoRemake package into monorepo for easier importing and cleaner use

    Milestone 3 - Improve ParaSpell UI 2/2 & ParaSpell SDK 3/3โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a usage explanation in readme.md
    0c.Testing and Testing GuideSDK Core UNIT tests will be provided for every scenario that SDK offers.
    0d.DockerDocker file that allows to test ParaSpell SDK through ParaSpell UI will be provided.
    0e.ArticleWe will publish Medium article about development of SDK
    1.Release new functionalityAbility to install new version of package from npm
    2.aUpdate ParaSpell UI IUpdate ParaSpell XCM UI Parachain to Parachain Scenario screen to be able to use new SDK (Add or remove some variables according to new requirements from SDK functions)
    2.bUpdate ParaSpell UI IIUpdate ParaSpell XCM UI Relay chain to Parachain Scenario screen to be able to use new SDK (Add or remove some variables according to new requirements from SDK functions)
    2.cUpdate ParaSpell UI IIIUpdate ParaSpell XCM UI Parachain to Relay chain Scenario screen to be able to use new SDK (Add or remove some variables according to new requirements from SDK functions)
    3.Add comprehensive Wiki guideWe will add Wiki guide, that will specify SDK implementation to another dApps, different SDK functionalities & Guide for Parachain creators that wish to add their freshly baked node to the list of compatible nodes.
    4.Use scaffold template from Milestone 1 to update UIThis will update ParaSpell UI from Vue 2 into Vue3 and nuxt. It will also be good demonstration for template usage & it will make UI more compatible with other dApps.
    5.Integrate suggestions from evaluationIntegrate suggestions regarding Wiki, module for asset conversions to not need to write so many 0s & replace button text Log in with: with account name once logged in

    Future Plans ๐Ÿ”ญโ€‹

    Once everything will be implemented according to the proposed plan application will still be under constant improvement as technology will progress. For example, once the XCMP protocol will be released we wish to deprecate the HRMP protocol we currently use for channels.

    In a long run, we also want to improve design of the UI, add new features that can be useful for developers and support for new nodes.

    Project goal is that SDK will serve dApp developers and UI will teach new substrate developers to use XCM and will serve to existing substrate developers to test their freshly baked Parachains.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Personal recommendation

    Project achievements in chronological order โŒ›๏ธโ€‹
    - + \ No newline at end of file diff --git a/applications/ParaSpell_follow-up2.html b/applications/ParaSpell_follow-up2.html index 577b106af18..60bb1d66b2e 100644 --- a/applications/ParaSpell_follow-up2.html +++ b/applications/ParaSpell_follow-up2.html @@ -4,7 +4,7 @@ ParaSpell | Web3 Foundation Grants - + @@ -39,7 +39,7 @@ | Support for local network configuration: | Fully implemented example network configuration that uses maintained Parachain-launch library | Not implemented | | Support for HRMP channel opening/closing: | Fully implemented | Not implemented |

    Unlike the already mentioned "Morph" platform ParaSpell focuses more on developers. ParaSpell features complete network install and startup configuration in one single command. This automatization ensures, that developers do not need to do any extra tasks when they wish to run development nodes locally. ParaSpell also allows developers to open and close HRMP channels between Parachains they connected. Like "Morph", ParaSpell can also transfer fungible tokens in three scenarios. From Parachains to Relay chain, from Relay chain to Parachains & from Parachains to Parachains.

    We are currently in talks with several Parachain teams that like the idea of unified SDK for XCM transfers as much as we do. SDK that unifies XCM can be very helpful for entire ecosystem in our opinion.

    Our target audiences are Web3 projects and starting/current blockchain developers.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Duลกan Morhรกฤ - Student, project Founder &ย Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava

    Michael Absolon - Student, SDK Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava

    Contactโ€‹

    Team's experienceโ€‹

    Team Code Reposโ€‹

    Team Github Profiles ๐Ÿง‘โ€๐ŸŽ“โ€‹

    Team LinkedIn Profiles ๐Ÿง‘โ€๐ŸŽ“โ€‹

    Development Status ๐Ÿ“–โ€‹

    SDK is currently released into main and is in version that is fully operable. There are still some tweaks we plan to add and make, they are mentioned below. UI-V2 currently runs on state-of-the-art technology version VueJS 3 and newest version of Nuxt. It deprecated V1 and introduced much smoother interface and modules brought from subscaffold template ParaSpell contributed to. Docs are currently in ready state but there is still some tweaking to do.

    Sidenote: We have recently developed article about Polkadot &ย Paraspell called Enhancing XCMP Interoperability Across Polkadot Paraverse and it was accepted to International IEEE ICBC 2023 conference held in Dubai.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 - Phase 3, make XCM SDK more efficient, add new nodes & rework Localhost network in UIโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a usage explanation in readme.md
    0c.Testing and Testing GuideSDK Core UNIT tests will be provided for xTokens Pallet, HRMP pallet, polkadotXCM pallet
    0d.DockerDocker file that allows to test ParaSpell SDK through ParaSpell UI will be provided.
    0e.Create Medium article about development of Phase 3 ParaSpellAdd article covering new features &ย improvements brought in Phase3
    1.Merge currencyId & currency in XCM TransfersMerge currency ID and currency symbol into one so user do not need to enther both. Raised in issue: https://github.com/paraspell/xcm-sdk/issues/16
    2.aAdd support for new compatible nodes in DMP Scenario (Downwards message passing)Check for new Parachain support & update Parachains, that have new compatibility with other Parachains in DMP Scenario & Update list of compatible Parachains accordingly
    2.bAdd support for new compatible nodes in UMP Scenario (Upwards message passing)Check for new Parachain support & update Parachains, that have new compatibility with other Parachains in UMP Scenario & Update list of compatible Parachains accordingly
    2.cAdd support for new compatible nodes in HRMP Scenario (Horizontall message passing)Check for new Parachain support & update Parachains, that have new compatibility with other Parachains in HRMP Scenario & Update list of compatible Parachains accordingly
    3.Rework Utils.ts to remove huge switch that constructs messageRework construct XCM message function to not have switch and be more efficient in construction - link
    4.aDeprecate Parachain-launch & replace it with Zombienet IReplace network startup configuration from Parachain-launch library into state of the art technology called Zombienet link1, link2
    4.bDeprecate Parachain-launch & replace it with Zombienet IIUpdate ParaSpell Docs
    5.Add suggestions we received in our previous grant evaluations (If not added already)Add suggestions from our phase1 and phase2 proposal evaluations if they were not added already

    Future Plans ๐Ÿ”ญโ€‹

    Once everything will be implemented according to the proposed plan application will still be under constant improvement as technology will progress. For example, once the XCMP protocol will be released we wish to deprecate the HRMP protocol we currently use for channels.

    In a long run, we also want to improve design of the UI, add new features that can be useful for developers and support for new nodes.

    Project goal is that SDK will serve dApp developers and UI will teach new substrate developers to use XCM and will serve to existing substrate developers to test their freshly baked Parachains.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Personal recommendation

    Project achievements in chronological order โŒ›๏ธโ€‹
    - + \ No newline at end of file diff --git a/applications/Parallel.html b/applications/Parallel.html index 77f5b1eb396..506081baf8c 100644 --- a/applications/Parallel.html +++ b/applications/Parallel.html @@ -4,7 +4,7 @@ Parallel Finance | Web3 Foundation Grants - + @@ -16,7 +16,7 @@ image image

    An overview of the technology stack to be usedโ€‹

    The lending protocol was inspired by compound protocol and our blockchain solution is developed on substrate 3.0, which allows for efficiency and scalability.

    Lending and Borrowing Workflowโ€‹

    image

    Interest Rate Modelโ€‹

    image

    Auto Liquidation Algorithmโ€‹

    image

    Staking Workflowโ€‹

    image

    Staking Rate Modelโ€‹

    image

    What your project is not or will not provide or implementโ€‹

    Ecosystem Fitโ€‹

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    (we are in the process of registering the legal entity)

    Team's experienceโ€‹

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement Cross-chain support for DOT and KSMโ€‹

    The major deliverable of for this milestone:

    NumberDeliverableSpecification
    0LicenseApache 2.0
    1.aSubstrate module: Loans palletLoans pallet will be implemented as a multi-assets lending protocol which offers lending and borrowing by using floating rate model. The full expected functionality is described here (โ…ข-1, โ…ข-2).
    1.bSubstrate module: Liquidation palletWe will implement a liquidation solution build with Substrate Off-chain Worker, which will calculate the health factor of each borrower's account and send a liquidation transaction automatically. The full expected functionality is described here (โ…ข-4.1).
    1.cSubstrate module: Price aggregation oracleWe will need to create an on-chain price aggregation pallet for the oracle prices from multiple sources that is queried by off-chain workers. The full expected functionality is described here (โ…ข-5).
    2.aIntegration with front-endWe will integrate our existing front end to the finalized substrate backend.
    2.bArticle/TutorialWe will create an article and a demo video that will explain how users can start using the platform for lending and borrowing DOT or KSM tokens.
    3.DockerWe will provide a dockerfile to demonstrate the lending functionality.
    4.Testing and DocumentationWhile we develop our module, we will ensure that our code has significant test coverage (>80%) to ensure quality and provide explanations on how the functions work for the community to review, as well as craft test guides.
    5.User TestingWe will conduct user testing to improve our product's UI and UX, to ensure that the borrowing and lending functionalities are intuitive. Initially, we will conduct qualitative user testing by observing 10-15 users who will use the v1 platform and provide a summary of the findings and improvements made based on insights.

    Other:

    Milestone 2 โ€” Enable Staking for DOT and KSMโ€‹

    The major deliverable of for this milestone:

    NumberDeliverableSpecification
    0LicenseApache 2.0 /
    1.aSubstrate module: Staking DOTWe will implement the on-chain staking pool for the staking process from the nominators. The full expected functionality is described here (IV-1, IV-3, IV-4).
    1.bSubstrate module: Unstaking DOTWe will implement a 28 days locking period for the unstaking process of DOT tokens from validators. The full expected functionality is described here IV-1, IV-4).
    1.cSubstrate module: Exchange RateWe will implement the process for issuing and trading DOT for xDOT with the users based on our exchange rate. The full expected functionality is described here (IV-4).
    1.dSubstrate module: Slashing ScenarioStaking tokens does have inherent risks of being slashed. We will implement our model that will change the exchange rate in case of slashing scenarios. The full expected functionality is described here (IV-6).
    1.eSubstrate module: KSMSince DOT and KSM will have similar code, we will mainly transfer over some of the previous development to allow for KSM staking.
    2Validator evaluation schemaWe will design the validator evaluation schema to select the outstanding validators. The full expected functionality is described here (IV-2).
    3.Integration with front-endWe will integrate our existing front end to the finalized substrate backend.
    4.Article/TutorialWe will create an article and a demo video that will explain how users can start using the platform for staking DOT and KSM. Additionally, we will also create tutorials for users to explain how they can earn "double interests" through staking and lending at the same time via xDOT and xKSM.
    5.Testing and DocumentationWhile we develop our module, we will ensure that our code has significant test coverage (>80%) to ensure quality and provide explanations on how the functions work for the community to review, as well as craft test guides.
    6.User TestingWe will conduct user testing to improve our product's UX and UI, to ensure that the borrowing and lending functionalities are intuitive. Initially, we will conduct qualitative user testing by observing 10-15 users use the v1 platform and provide a summary of the findings and improvements made based on insights.

    Other:

    Future Plansโ€‹

    Community Development:

    Product Development:

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/Plus-follow-up.html b/applications/Plus-follow-up.html index 563eebb71f1..82a5bc68003 100644 --- a/applications/Plus-follow-up.html +++ b/applications/Plus-follow-up.html @@ -4,13 +4,13 @@ Polkadot js plus / Nomination pools | Web3 Foundation Grants - +
    Skip to main content

    Polkadot js plus / Nomination pools

    • Team Name: Polkadot js plus
    • Payment Address: 0xa4Eff15578D1450912DED08c85679F453C45A710 (DAI)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    This is an application for a follow-up grant for providing POOL STAKING in "Plus:Polkadot js Plus Extension".

    polkadot{.js} plus extension intro

    Overviewโ€‹

    Polkadot js plus extension, or for short Plus, is actually the original Polkadot js extension, plus some new features. It is a user-friendly wallet to interact with the Polkadot/Substrate based blockchains/parachains through a browser. It allows users to access their account(s), which can also be used to interact with decentralized apps.

    We don't want to rebuild the wheel, we just want to perfect it, standing on the shoulders of giants like "polkadot js extension" and make it user-friendlier for users. The reason why we have decided to work on this project is every day user comments on social medias that complain "why the extension does not show the balance?", "It is too complicated for new/average users to work with", "It is too abstract", " why should we go to another web site to work with the extension?", " how could contribute to the crowdloans via extension?", and so on. Hence we started to work on the Plus extension to address such concerns/requests of the Polkadot community. Plus is based on Polkadot js extension, and get constantly updating with it. Both extensions can be run simultaneously, but with Plus you do not need to install the original extension, because Plus does whatever the original extension does even more.

    At the currant state our extension has the following features available:

    • Viewing balances (crypto/USD)
    • Transfering funds
    • Transaction history
    • Viewing an address as QR code
    • (Solo) staking
    • Crowdloans
    • Governance

    Recently, Parity Technologies staking team released a new pallet, named "Nominations pools", which will make pool staking available on Kusama, and Polkadot. Now, it is available on Westend, will be available on relay chains soon. Therefore, we have decided to be among the first to provide this new coming functionality for Dotsama community on Polkadot js plus extension.

    Project Detailsโ€‹

    With the new functionality the stakers on Kusama/Polkadot will have two options to stake their tokens, hence when click on easy staking in Polkadot js plus extension, solo or pool staking can be chosen.

    polkadot{.js} plus extension accounts

    polkadot{.js} plus extension staking index

    With Pool staking, stakers (delegators) with a small amount of tokens (e.g., 1 DOT) can pool their funds together and act as a single nominator. The earnings of the pool are split pro rata to a delegator's stake in the bonded pool.

    Ther following features will be available in pool staking:

    • auto vs manual staking (pool creation, join, nomination,etc.)
    • unstaking (unbonding, claim payout, redeem)
    • view own pool information (including pool name, Id, state, members Info, roles, and their accounts, reward/stash Id, and pool destroying)
    • view nominations (including selected validators information, its nominators, actives, oversubscribeds, and ability to re-nominate)
    • viewing pool staking general information (e.g., minimum to join/create, max pools, etc.)

    Where a delegator can easily contribute in pool staking automatically, and confirm it by entering the account password:

    polkadot{.js} plus extension pool stake

    polkadot{.js} plus extension pool stake confirm

    Similarly unstaking can be done, where unlocking bonds will be redeemable after a while depending on the chain:

    polkadot{.js} plus extension pool unstake confirm

    Pools information along with its roles and accounts can be presented in pooltab:

    polkadot{.js} plus extension pool staking pool tab

    The account(s) with root and nominator role can nominated validators for the deligated stashId, the nominated validators can be depicted in the nominations tab:

    polkadot{.js} plus extension pool staking nominations tab

    The general information that every staker/deligators needs to know can be summarized in info tab:

    polkadot{.js} plus extension pool staking info tab

    There would be also modules for manual pool selection/creation, manual validator selection, pool details information including pool's members' information, etc.

    Ecosystem Fitโ€‹

    Plus extension will be a user-friendly wallet to interact with the Polkadot/Substrate based blockchains through a browser. It allows users to access their Polkadot account(s), which can also be used to interact with decentralized apps. It is based on the original polkadot js extension, which injects a @polkadot/api signer into a page, along with any associated accounts.

    The difference with polkadot.js extensionโ€‹

    Polkadot.js extension is an official account management tool, but Plus extension will be not only an account management tool but also implements a series of common functions in Polkadot ecology, such as fund transfer, transaction histrory (including, send, recieve, bond, nominate, bond_extra, redeem, etc), easy staking, easy-to-operate on-chain governance modules, contribute to crowdloans, etc. This means that polkadot js plus can not only do what original extension does, but also independently complete the above mentioned functions, providing users with a one-stop experience, which polkadot.js extension does not have.

    From the perspective of UI experience, polkadot js plus tries to not just be more user-userfriendlier but also consistent with the previous taste of the users, who are already familiar with the original polkadot js extension. We try to make the UI more attractive to users, and also support all the languages that are currently existd on the original extension.

    Product direction and advantagesโ€‹

    Analogous to MetaMask, browser extension wallets are convenient to interact with DApps. Plus is positioned as a browser extension wallet and has a first-mover advantage in the product direction. It focuses on the Polkadot ecosystem and enables more users to participate in the Polkadot ecosystem through customized and truly friendly interactive experience.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Kami Ekbatanifard

    Contactโ€‹

    • Contact Name: Kami Ekbatanifard
    • Contact Email: ekbatanifard@gmail.com
    • Website: Plus extension is currently maintained on Github, no website has been created yet

    Plus extension is maintained by Kami Ekbatanifard, and no company entity has been created yet, the following is our communication information.

    Team's experienceโ€‹

    Kami has a Phd in software systems and works as a blockchain engineer, he has experince in developing applications mostly in private sources including centralized/decentralized crypto exchanges, NFT market on Ethereum utilizing filecoin, etc. He also has a research track which could be find listed here.

    Personal Code Repo:โ€‹

    Team LinkedIn Profileโ€‹

    Development Status ๐Ÿ“–โ€‹

    The current status of the implementation of Plus extension can be found here.

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 1 FTE
    • **Total Costs: 15,300 USD

    Milestone 1 โ€” Pool Stakingโ€‹

    • Estimated duration: 3 month
    • FTE: 1
    • Costs: 15,300 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use each of the implemented functionalities.
    0c.Testing GuideWe will conduct unit test on all modules to ensure they can function properly. In this guide, we will describe how to run these tests.
    0d.ArticleWe will write an article or tutorial that explains the work principle as part of the grant.
    1.StakeAuto and manual pool staking will be available
    2.UnstakeWhere members can unstake(unbound) thier funds (and redeem unbounded, and withdraw claimable as well)
    3.PoolJoin/Created pools information will be depicted, and it may be destroyed too
    4.NominationsWhere pools nominated validators are shown and pool's privileged users (roles) can nominate validators automaticaly or manually

    Future Plansโ€‹

    We have some plans to extend Plus features on parachains, as an example one plan is adding token swapping of Acala to Plus extension, supporting NFT on parachains like Efinity will be another plan for feature.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? In the initial stage of Plus, we presented it to the core developers of the original polkadot js extension on Github, there they suggested to apply for W3F grants.

    - + \ No newline at end of file diff --git a/applications/Plus-social-recovery-wallet.html b/applications/Plus-social-recovery-wallet.html index f34c6914193..5327ab3778b 100644 --- a/applications/Plus-social-recovery-wallet.html +++ b/applications/Plus-social-recovery-wallet.html @@ -4,13 +4,13 @@ Polkadot js plus / Social Recovery Wallet | Web3 Foundation Grants - +
    Skip to main content

    Polkadot js plus / Social Recovery Wallet

    • Team Name: Polkadot js plus
    • Payment Address: 0xa4Eff15578D1450912DED08c85679F453C45A710 (DAI)
    • Level: 3

    Project Overview ๐Ÿ“„โ€‹

    This is a proposal for the RFP titled Social Recovery Wallet, and in other words a follow-up grant for providing Social Recovey in "Plus:Polkadot js Plus Extension"

    polkadot{.js} plus extension intro

    Overviewโ€‹

    Polkadot js plus is Polkadot js extension, plus new features. It is a user-friendly wallet to interact with the Polkadot/Substrate based blockchains through a browser. It allows users to access their account(s), which can also be used to interact with decentralized apps.

    We don't want to rebuild the wheel, we just want to perfect it, standing on the shoulders of giants like "polkadot js extension" and make it user-friendlier for users. The reason why we have decided to work on this project is every day user comments on social medias that complain "why the extension does not show the balance?", "It is too complicated for new/average users to work with", "It is too abstract", " why should we go to another web site to work with the extension?", " how could contribute to the crowdloans via extension?", and so on. Hence we started to work on the Plus extension to address such concerns/requests of the Polkadot community. Plus is based on Polkadot js extension, and get constantly updating with it. Both extensions can be run simultaneously, but with Plus you do not need to install the original extension, because Plus does whatever the original extension does even more.

    At the currant state our extension has the following features available:

    • Viewing balances (crypto/USD)
    • Connecting to different endpoints
    • Transfering funds
    • Viewing transaction history
    • Viewing an address as QR code
    • Staking (Solo and Pool)
    • Crowdloans
    • Governance

    Based on the Social Recovery Wallet RFP, proposed by David Hawig from W3F, we have decided to provide this feature in the Polkadot js Plus extension.

    Project Detailsโ€‹

    With the new functionality the token holders will be able to make their accounts Recoverable. Almost all required information will be saved on-chain, utilizing Substrate/Recovery-Pallet.

    polkadot{.js} plus extension make recoverable

    and when you open the accounts page, a green shield icon indicates which account is already recoverable.

    polkadot{.js} plus extension recoverable icon

    Ther following features will be available as Social recovery wallet:

    • making an account recoverable
    • let users find their lost account Id using their on-chain identity (name, twitter, riot id, etc)
    • removing recovery from an account
    • initiating recovery for a lost account by a rescuer
    • showing an alert for a lost account, for which the recovery is initiated
    • let a lost account to close recovery and punish a malicious rescuer by gathering its deposit
    • let on-chain friends to vouche for their friend's lost account
    • let a rescuer account to claim recovery and set itself as a proxy of the lost account

    After an account holder determined their friends and set recovery delay and threshold, can make the account recoverable by confirming it using the account password:

    polkadot{.js} plus extension confirm making recoverable

    Similarly the user can remove recovery for a recoverable account using remove recovery tab:

    polkadot{.js} plus extension remove recovery

    To rescue a lost account, we have two identities, a rescuer and the lost account's friends, who can help to rescue the lost account:

    polkadot{.js} plus extension rescue tab

    A rescuer should start by intiating the recovery process, but usually when you lost your account you hardly remember the acount Id, hence, it should be possible to find the lost account using it's on-chain identity:

    polkadot{.js} plus extension iniTiate recovery

    When a malicious rescuer initiates the recovery for a lost account, we need to set an alert for the lost account, as can be seen below as a beating red shield .

    polkadot{.js} plus extension red alert

    Therfore, the lost account can close the recovery to protect their account.

    polkadot{.js} plus extension close recovery

    There would be also modules for friends to send their vouches, enabling claim recovery by a rescuer, modules for canceling recovery, taking over the lost account (as recovered), and etc. Finally, in a successful recovery attempt, the rescuer account will act as a proxy of the lost account.

    Ecosystem Fitโ€‹

    Plus extension will be a user-friendly wallet to interact with the Polkadot/Substrate based blockchains through a browser. It allows users to access their Polkadot account(s), which can also be used to interact with decentralized apps. It is based on the original polkadot js extension, which injects a @polkadot/api signer into a page, along with any associated accounts. The social recovery feature is definitely a blockchain requirement and can stop the nightmare for many normal (non-technical) end users.

    The difference with polkadot.js extensionโ€‹

    Polkadot.js extension is an official account management tool, but Plus extension will be not only an account management tool but also implements a series of common functions in Polkadot ecology, such as fund transfer, transaction histrory (including, send, recieve, bond, nominate, bond_extra, redeem, etc), easy staking, easy-to-operate on-chain governance modules, contribute to crowdloans, etc. This means that polkadot js plus can not only do what original extension does, but also independently complete the above mentioned functions, providing users with a one-stop experience, which polkadot.js extension does not have.

    From the perspective of UI experience, polkadot js plus tries to not just be more user-userfriendlier but also consistent with the previous taste of the users, who are already familiar with the original polkadot js extension. We try to make the UI more attractive to users, and also support all the languages that are currently existd on the original extension.

    Product direction and advantagesโ€‹

    Analogous to MetaMask, browser extension wallets are convenient to interact with DApps. Plus is positioned as a browser extension wallet and has a first-mover advantage in the product direction. It focuses on the Polkadot ecosystem and enables more users to participate in the Polkadot ecosystem through customized and truly friendly interactive experience.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Plus extension is maintained by Polkadot js Plus team, the following is our communication information.

    Team's experienceโ€‹

    We are a team of polkadot ecosystem enthusiasts that trying to make the polkadot most common needs much more accessible for end users. Kami has a Phd in software systems and works as a blockchain engineer and full stack developer, he has experince in developing applications mostly in private sources including centralized/decentralized crypto exchanges, NFT market on Ethereum utilizing filecoin, etc. He also has a research track which could be find listed here. Morteza, has a great resume in finantial systems and helps us as the CFO. Mehran is a blockchain reseacher, and helps us in more deep research in Polkadot ecosystem. Martin is a senior UX designer, and newly joined our team to help us improve the user experince of the extension. Amir is a test engineer, who helps to write different kinds of tests to ensure the smooth functioning of the extension.

    Personal Code Repo:โ€‹

    Team LinkedIn Profileโ€‹

    Development Status ๐Ÿ“–โ€‹

    The current status of the implementation of Plus extension can be found here.

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 3 FTE
    • **Total Costs: 45,900 USD

    Milestone 1 โ€” Social Recoveryโ€‹

    • Estimated duration: 3 month
    • FTE: 3
    • Costs: 45,900 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use each of the implemented functionalities.
    0c.Testing GuideWe will conduct unit test on all modules to ensure they can function properly. In this guide, we will describe how to run these tests.
    0d.ArticleWe will write an article or tutorial that explains the work principle as part of the grant.
    1.Make recoverableMaking an account recoverable, help find friends using on-chain identity, and showing related alerts
    2.Rescue accountEnaling a rescuer account to recover a lost account during a sequence of actions with the hlep of social friends
    3.Friends vouchesProviding facilities for friends to easily vouch for a lost account
    4.Takeover lost accountProviding facilities for the rescuer to be able to use the lost account as a proxy

    Future Plansโ€‹

    We have some plans to extend Plus features on parachains, as an example one plan is adding light client as an endpoint to Plus extension, supporting XCMP, and Governance 2 will be other plans for feature.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? In the initial stage of Plus, we presented it to the core developers of the original polkadot js extension on Github, there they suggested to apply for W3F grants.

    - + \ No newline at end of file diff --git a/applications/Plus.html b/applications/Plus.html index ce3bca289b6..bc95ffd5dcc 100644 --- a/applications/Plus.html +++ b/applications/Plus.html @@ -4,7 +4,7 @@ Plus: Polkadot js plus extension | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Plus: Polkadot js plus extension

    • Team Name: Kami Ekbatanifard
    • Payment Address: 0xa4Eff15578D1450912DED08c85679F453C45A710 (DAI)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Plus extension will be a user-friendly wallet to interact with the Polkadot/Substrate based blockchains through a browser. It allows users to access their Polkadot account(s), which can also be used to interact with decentralized apps. It is actually polkadot js extention, plus some new features. We don't want to rebuild the wheel, we just want to perfect it, standing on the shoulders of giants like "polkadot js extension" and make it user-friendlier for users.

    The reason why we have decided to work on this project is every day user comments on social medias that complain "why the extension does not show the balance?", "It is too complicated for new/average users to work with", "It is too abstract", " why should we go to another web site to work with the extension", " how could contribute to the crowdloans via extension", and so on. That's why we've decided to work on Plus extension to address such concenrs/requests of the polkadot community.

    Project Detailsโ€‹

    The new functionalities, that will be added to the original polkadot js extension are:

    • View balances
    • Transfer funds
    • Easy staking (auto stake/unstake/redeem funds and edit nominated validator list)
    • Contribute in crowdloans
    • View transaction history
    • View an address as a QR code
    • Governance (Referendums/Proposals voting, Treasury Tips, councils/motions )

    The UI of the already implemented/woking functionalities are as follows:

    Account page, which shows all accounts balances, and icon buttons to access some features:โ€‹

    account page screen shot

    Transfer funds pages, to enter/choose the recipient address, determine the transfer amount, and finally confirm transfer along with relevant alerts and tooltips:โ€‹

    transfer add recepient page screen shot

    transfer add amount page screen shot

    transfer confirmation page screen shot

    Staking pages, to stake, unskae, redeem, and even change your already nominated validators:โ€‹

    staking page screen shot

    staking confirmmation page screen shot

    View transaction history:โ€‹

    • The list of Transactions

    Transactions list page screen shot

    • Details of a transaction

    transaction detail page screen shot

    The UI of under developement features:โ€‹

    Viewing the auction and its crowdloans on different relay chains (polkadot, kusama, and westend testnet) to contribute on:โ€‹

    auction crowdloans search page screen shot

    auction crowdloans page screen shot

    auction crowdloans confirmmation page screen shot

    Governance, including Democracy, Council and Treasury:โ€‹

    Governance page screen shot

    Ecosystem Fitโ€‹

    Plus extension will be a user-friendly wallet to interact with the Polkadot/Substrate based blockchains through a browser. It allows users to access their Polkadot account(s), which can also be used to interact with decentralized apps. It is based on the original polkadot js extension, which injects a @polkadot/api signer into a page, along with any associated accounts.

    Competitive product analysisโ€‹

    Polkadot's browser extension wallet, the currently known competitors are Enzyme, Speckle OS, and Doter.

    Enzyme and Speckle OS have very limited features and not been maintained for a long time over a year. Dotter also has very limitted capabilities, so that the functional modules achieved by Plus extension's first milestone have exceeded Doter (Recently, we have completed the first milestone), and more functional modules that will serve the Polkadot ecology will be implemented in the plan.

    The difference with polkadot.js extensionโ€‹

    Polkadot.js extension is an official account management tool, but Plus extension will be not only an account management tool but also implements a series of common functions in Polkadot ecology, such as fund transfer, transaction histrory (including, send, recieve, bond, nominate, bond_extra, redeem, etc), easy staking, easy-to-operate on-chain governance modules, contribute to crowdloans, etc. This means that polkadot js plus can not only do what original extension does, but also independently complete the above mentioned functions, providing users with a one-stop experience, which polkadot.js extension does not have.

    From the perspective of UI experience, polkadot js plus tries to not just be more user-userfriendlier but also consistent with the previous taste of the users, who are already familiar with the original polkadot js extension. We try to make the UI more attractive to users, and also support all the languages that are currently existd on the original extension.

    Product direction and advantagesโ€‹

    Analogous to MetaMask, browser extension wallets are convenient to interact with DApps. Plus is positioned as a browser extension wallet and has a first-mover advantage in the product direction. It focuses on the Polkadot ecosystem and enables more users to participate in the Polkadot ecosystem through customized and truly friendly interactive experience.

    How to maintain the walletโ€‹

    In the near future, we will have someone in charge of maintaining the Plus extension, not only update it with the original polkadot js extension but also fix bugs, and even improve the experience๏ผŒto making Plus as close as possible to a mature browser extension in other ecosystems like MetaMask.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Kami Ekbatanifard

    Contactโ€‹

    • Contact Name: Kami Ekbatanifard
    • Contact Email: ekbatanifard@gmail.com
    • Website: Plus extension is currently maintained on Github, no website has been created yet

    Plus extension is maintained by Kami Ekbatanifard, and no company entity has been created yet, the following is our communication information.

    Team's experienceโ€‹

    Kami has a Phd in software systems and works as a blockchain engineer, he has experince in developing applications mostly in private sources including centralized/decentralized crypto exchanges, NFT market on Ethereum utilizing filecoin, etc. He also has a research track which could be find listed here.

    Personal Code Repo:โ€‹

    Team LinkedIn Profileโ€‹

    Development Status ๐Ÿ“–โ€‹

    The current status of the implementation of Plus extension can be found here.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 1 FTE
    • **Total Costs: 10,000 USD

    Milestone 1 โ€” Implement part 1 of functionalitiesโ€‹

    • Estimated duration: 2 month
    • FTE: 1
    • Costs: 7,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use each of the implemented functionalities.
    0c.Testing GuideWe will conduct unit test on all modules to ensure they can function properly. In this guide, we will describe how to run these tests.
    1.Show balance and address as QRcodeWe create view balance, to view your available and total balances in cryto and USD, also show your address as a QRcode
    2.Fund transferWe create Transfer fund to transfer funds from one account to another
    3.Tranaction historyWe create history where all transactions history can be viewd in different categories
    4.Easy stakingWe create easy staking to stake, unstake, redeem funds, and nominate validators
    5.Crowdloan contributionwe create crowdloan contribution to view auctions, bids, and active/winner crowdloans on Polkadot and kusama, where contribution can be done easily

    Milestone 2 โ€” part 2 of functionalitiesโ€‹

    • Estimated Duration: 1 month
    • FTE: 1
    • Costs: 3,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use each of the implemented functionalities.
    0c.Testing GuideWe will conduct unit test on all modules to ensure they can function properly. In this guide, we will describe how to run these tests.
    0d.ArticleWe will write an article or tutorial that explains the work principle as part of the grant.
    1.Referendums and ProposalsWe create these functionalities to enable viewing and voting for referendums and proposals
    2.Council and MotionsCouncil members and motions can be seen in this part
    3.Treasury and TipsWe create Treasury to view/submit proposals and tips

    Future Plansโ€‹

    After we finish these 2 milestones, we will publish Plus extension to Chrome and Firefox browser addon market, we have some plans to extend Plus features on parachains, as an example one plan is adding token swapping of Acala to Plus extension, supporting NFT on parachains like Efinity will be another plan for feature.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? In the initial stage of Plus, we presented it to the core developers of the original polkadot js extension on Github, there they suggested us to apply for W3 grants.

    - + \ No newline at end of file diff --git a/applications/Plutonication.html b/applications/Plutonication.html index af8f931d45f..3b42777a228 100644 --- a/applications/Plutonication.html +++ b/applications/Plutonication.html @@ -4,7 +4,7 @@ Plutonication | Web3 Foundation Grants - + @@ -109,7 +109,7 @@ Last week, I had a chance to represent Ajuna at the Token2049. So, I was showing off all of the projects that have built on the Substrate.NetApi so far ^^.

    Is Plutonication made just for PlutoWallet?โ€‹

    Can you share some user numbers or other metrics that show adoption of PlutoWallet?โ€‹

    Regarding deliverable 4.1, you mean polkadot.js apps, not the extension, correct?โ€‹

    Wallet Connect does have both a Dapp integration guide and a wallet integration guide for Polkadot. Can you compare to this and what is missing that your solution would provide?โ€‹

    You point out that the only way to connect a mobile wallet to a Dapp is through Substrate Connect or Vault, but afaik mobile wallets such as Talisman and Fearless will also let you connect.โ€‹

    How do you plan to get developers to use your solution?โ€‹

    - + \ No newline at end of file diff --git a/applications/PolkaKey.html b/applications/PolkaKey.html index 556fa83837f..d2bc8c78c7f 100644 --- a/applications/PolkaKey.html +++ b/applications/PolkaKey.html @@ -4,13 +4,13 @@ PolkaKey | Web3 Foundation Grants - +
    Skip to main content

    PolkaKey

    • Proposer: @HiZhaoYun
    • Payment Address: 1NUYKUgjDrzXox7ebeT6xkFN5A64S419Xm

    Project Description ๐Ÿ“„โ€‹

    When user claim their DOTs, they need a native Polkadot address. Now, there are several ways to generate a Polkadot address. Polkadot.js and Polkadot.js browser plugin is less secure than using Subkey. Subkey is secure, but it is ecommended for technically advanced users who are comfortable with command line and compiling Rust code, it is not recommended for general users.

    PolkaKey planned to provide a secure and simple way to generate a Polkadot address for general and technically advanced users.

    PolkaKey is a desktop app build with Electron and can run on three platforms (MacOS, Windows, and Linux).

    PolkaKey can generate a Polkadot address without internet connection. In fact, we also recommend that users use it when disconnected from the network. It is secure than using Polkadot.js and Polkadot.js browser plugin.

    PolkaKey will bringing smooth UX to Polkadot, it is simple than subkey.

    PolkaKey is open source for full transparency, so anybody can audit.

    PolkaKey will never save any info locally, the private key is self-owned.

    Team ๐Ÿ‘ฅโ€‹

    • Members: Xianyun Zhao
    • LinkedIn Profiles: Sorry, we really rarely use LinkedIn in China.
    • Code Repos: https://github.com/w3finance/PolkaKey
    • Website: coming soon
    • Legal Structure: BoBao Technologies co. LTD
    • Team's Experience: Xianyun has 5 years of developing experience and similar with cross-platform apps development, currently i am working on a wallet project that designed for Polkadot ecosystem.

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 3 weeks + 2weeks
    • Total Costs: 0.5 BTC ~+ 0.1 BTC~

    Milestone 1โ€‹

    • Estimated Duration: 2 weeks
    • Costs: 0.35 BTC
    NumberDeliverableSpecification
    1.UI for showcaseCreate working prototype which can demo the whole workflow
    2.Function implementationGenerate a Polkadot/Kusama address via PolkaKey. Setting functions, include:Language(Chinese + English). Online/Offline Event Detection

    Milestone 2โ€‹

    • Estimated Duration: 1 week
    • Costs: 0.15 BTC
    NumberDeliverableSpecification
    1.Prepare for releaseAdd unit test, we use jest as our test runner. Fix issue on github, release the MVP version

    ~Milestone 3~โ€‹

    • ~Estimated Duration: 2 weeks~
    • ~Costs: 0.1 BTC~
    NumberDeliverableSpecification
    1.Add a Chinese + English tutorialThis tutorial is mainly about how to build an Electron app with Polkadot.js API. The tutorial will first be available on the github Wiki. If possible, i hope to publish this tutorial on Polkaworld and Substrate Dev Hub
    - + \ No newline at end of file diff --git a/applications/PolkaSignIn.html b/applications/PolkaSignIn.html index c9e8701f10e..cfc6145eedb 100644 --- a/applications/PolkaSignIn.html +++ b/applications/PolkaSignIn.html @@ -4,7 +4,7 @@ Polka SignIn | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ auth0 team has make a proposal

    to ask the user to sign such a magic string with injected signers and provides it as an access tokens for Applications. Instead of verified by authorization server who holds the approval of resource owner (user), it should be verified in a decentralized way.

    Project Detailsโ€‹

    Sign in Participantsโ€‹

    Workflowโ€‹

    The workflow works the same with or without OAuth specification. Only the 4th step will differ.

    1. A user sends a request to a service provider.
    2. The service provider sends a callback address, the sign-in challenge, and required permissions to the user.
    3. The user connects to the injected signer.
    4. injected signed to sign the challenge, and send the signature together with the public address, an access token specifying the scopes like expire time, back to the callback address. With OAuth Implementation, the access token is compliant with the OAuth standard.
    5. The service provider validates the signature, if successful, the user signed in,
    6. If there is no related user information in the database, the service provider will lookup for the user information from Identity Registrar, if related TEXT records are found for this address, the information will be imported into the service providerโ€™s database.

    Sign-in Flow

    Implementationโ€‹

    1. Sign-in Request

      User want to sign in the dApp by send a simple request with identity chain type, eg: DOT, KSM, ETH etc.

      The payload is required since each chain has its own algorithmic mechanism.

      request payload(1)

      {
          "identity-type": "dot"
      }

    2. Authentication Requirement

      dApp will return the callback info. The callback endpoint is used by Identity provider to send signature data to dApp.

      {
          "identity-type": "dot",
          "callback-endpoint": "http://dapp.com/login/callback",
          "scope": ["xxx", "yyy"],
          "chanllenge": xxxxxxxxxx",
      }

    3. Connect to Signer

      User sends request to the Identity Provider (Injected Signer like : Polkadot.js Extension, Metamask, Parity Signer ...).

      This action will call up a browser extension or some other external applications.

      {
          "identity-type": "dot",
          "callback-endpoint": "http://dapp.com/login/callback",
          "scope": ["xxx", "yyy"],
          "chanllenge": xxxxxxxxxx",
      }

    4. Provide Signature The Identity Provider will generate the Signature data.

      {
          "identity-type": "dot",
          "public-key": "xxxxxxxx",
          "account-signed": "xxxxxxxxxx",
          "scope": ["xxx", "yyy"],
      }

      explains:

      The Identity Provider will send the signature data to the callback endpoint of dApp by step #3.

    5. Validation

      The dApp receives the signature data and do the verification.

      ```
      {
          "identity-type": "dot",
          "public-key": "xxxxxxxx",
          "account-signed": "xxxxxxxxxx",
          "scope": ["xxx", "yyy"],
      }
      ```

      Verification Steps:

    6. Lookup Identity

      The dApp gets the account address . It can retrieve the related information of account from the external service providers , such as ENS, Polkadot/Kusama Identity Registrar, etc.

    Ecosystem Fitโ€‹

    There is few solution combine the OAuth and self-custody wallet, and no such solutions in the Polkadot ecosystem. With our solution and the ecosystem tools like polkadot.js extension and Parity Signer, the substrate account could be used to sign in any web2 or web3 platform which support OAuth, user also do not need to input all his information once registered in a new platform, the information could automatically be fetched from the info records in identity pallet, which could gain huge adoption of Substrate account in Web2 world.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Litentry Technologies GmbH is a Berlin-based technology company, the team builds the identity-related infrastructure of Web3, builds a Decentralized Identity Aggregation protocol across multiple networks, it features a DID indexing mechanism, and a Substrate-based credit computation network. The protocol provides a decentralized, privacy-preserving interoperable identity aggregation service that mitigates the difficulty of resolving agnostic DID mechanisms. The team has lots of experience in the DID field and has a strong background in Web3 technology. Current products include Litentry Network, My Crypto Profile, and a Governance-focused mobile App.

    Team Code Reposโ€‹

    Github accounts:

    Development Status ๐Ÿ“–โ€‹

    The development is not started yet.

    Development Roadmap ๐Ÿ”ฉโ€‹

    As the project is small, we only have 1 milestone to be finished.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1a.ResearchSurvey and discuss with related team 20 FTE hours
    1b.Standard DevelopmentCreate the specification w/o OAuth 20 FTE hours
    1c.Create LibraryCreate a Javascript/Typescript library 50 FTE hours
    1d.Real Use CaseIntegration with a dApp as first use case 30 FTE hours

    The hourly pay rate is 50 USD/hour

    In total is 120 hours, and the total payment will be 6000 USD equivalent USDT.

    Future Plansโ€‹

    We planned to have a web app for user to manage the access control of the logged platforms, and enable user to curate the profile information in the future.

    It would be great to integrate with popular auth solutions in web technology, like passport (node js), next-auth (next.js).

    - + \ No newline at end of file diff --git a/applications/Polkadart.html b/applications/Polkadart.html index 28250105cd8..ae374737e42 100644 --- a/applications/Polkadart.html +++ b/applications/Polkadart.html @@ -4,7 +4,7 @@ Polkadart | Web3 Foundation Grants - + @@ -31,7 +31,7 @@ Protect \ Tenor \ Excel

    - + \ No newline at end of file diff --git a/applications/Polkadot-Dart.html b/applications/Polkadot-Dart.html index a297656d198..5dc43c11b2f 100644 --- a/applications/Polkadot-Dart.html +++ b/applications/Polkadot-Dart.html @@ -4,13 +4,13 @@ Polkadot-Dart | Web3 Foundation Grants - +
    Skip to main content

    Polkadot-Dart

    • Proposer: Michael So

    • Payment Address: 3PbhNyWhiSTwb58fc5uYhg2mV2vJ34KwAJ

    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Dart has advantages in native development.

    Dart is a computer programming language developed by Google, which is used in the development of web, server, mobile apps and the IoT. Dart is an object-oriented, class-defined, single-inheritance language. Dart is a general programming language developed by Google, which was later recognized as a standard by ECMA (ECMA-408). It is used to build web, server, desktop and mobile applications. Its syntax is similar to C language and can be translated into JavaScript, interfaces, mixins, abstract classes, reified generics, optional typing and sound type system .

    Dart is very positive for Polkadot. Currently Polkadot-JS (hereinafter referred to as JS API) provides developers with a complete JS API for interacting with the Polkadot. Both Web and App can call JS API. But the problem is that in App development and design, developers must provide a built-in browser interface on the front end, and then use JavaScript to implement JS API calls. The web is embedded in the app, which will cause the front-end page to load slowly, the development framework is not easy to maintain, and the native functions cannot be fully invoked.

    Flutter and Dart are born for cross-platform applications development. As Dart is using in the development of Flutter, we propose that using Dart language to develop tools for Polkadot/Substrate will be a better solution.

    As a new framework, there are not many blockchain SDKs suitable for Flutter. Ethereum provides web3dart, which is a relatively complete Dart implementation. It contains important features such as JSON RPC encapsulation, offline signature, ABI encoding and decoding, and its goal is to provide a dart version of web3.js, which can meet the needs of most Flutter applications to connect to the Ethereum blockchain.

    Similarly, we also found that there is currently no Polkadot SDK suitable for the development of the Flutter framework, although we have seen that some members of the community use Flutter/Dart to implement some wallets or some scattered tools, which is not a complete interactive implementation. For example, encoding and decoding, crypto standards, api design, etc., should all follow the design of Polkadot-JS and be completely migrated to the Dart language.

    Similar to polkaj (Java version), we will develop the Dart version and name it Polkadot-Dart.

    Project Detailsโ€‹

    To complete the porting, we follow the project structure of Polkadot-JS.

    There are some differences between Dart and Javascript, and the project needs to be compatible. For example, The "wasm" compiled by Rust-lang is used in Polkadot-JS . As for dart, we use dart:ffi for communication. All Rust-native libraries will be compiled to .so for Linux/Android system, .a or .framework for iOS/MacOS, and .dll for Windows.

    And for the extension packages, we must realize that it is only available for WebApp based on JavaScript browsers. As for Dart/Flutter, we have to find another way to interact with WebApp and have other solutions for JavaScript app/Dapp, please refer to Pocket4D WIKI .

    Therefore, we defined Dart project like Polkadot-JS .

    Polkadot-JSPolkadot-Dart
    wasmRust bindings
    @polkadot/wasmcrypto
    common
    @polkadot/utilsutils
    @polkadot/util-cryptoutil_crypto
    @polkadot/keyringkeyring
    @polkadot/networksnetworks
    @polkadot/x-fetch* not needed
    @polkadot/x-randomvalues* not needed
    @polkadot/x-textdecoder* not needed
    @polkadot/x-textencoder* not needed
    api
    @polkadot/api-contractapi_contract
    @polkadot/api-deriveapi_derive
    @polkadot/apiapi
    @polkadot/metadatametadata
    @polkadot/rpc-corerpc_core
    @polkadot/rpc-providerrpc_provider
    @polkadot/typegen* not needed
    @polkadot/type-known* not needed
    @polkadot/typestypes

    Technology Stacksโ€‹

    Dart/Flutter, Rust

    Ecosystem Fitโ€‹

    Similar projects:

    We have created Polkadot-Dart, which, combined with Flutter framework, can greatly reduce the barrier to participation for cross-platform developers, as well as reduce the complexity of cross-platform application development and maintenance. In addition, the cross-platform experience of Polkadot-Dart's users is also improved.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Michael So
    • Zhongdan Wei

    Team Websiteโ€‹

    SHANGHAI NIEPAN INFORMATION TECHNOLOGY CO., LTD., a startup company focusing on blockchain development in China.

    Team's experienceโ€‹

    • Michael So, founder of FireStack, Serial entrepreneur. He devoted to blockchain for many years, leading token investment, wallet, blockchain game platform and other projects, and has accumulated rich experience in blockchain theories and practice.
    • Zhongdan Wei, front-end architect, proficient in Flutter. As a leading member in Hellobike, he led the team to develop the Mobike Applications and makes it easy and fast to add flutter to existing mobile applications.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    None.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 5 months
    • Full-time equivalent (FTE): 5.3
    • Total Costs: 1.48 BTC

    Milestone 1 โ€” Porting common and wasmโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 0.56 BTC
    NumberDeliverableSpecification
    0LicenceMIT
    1bindings/cryptoRust binding and implements @polkadot/wasm
    2util_cryptoPorting and implements @polkadot/util-crypto
    3utilsPorting and implements @polkadot/utils
    4keyringPorting and implements @polkadot/keyring
    5networkPorting and implements @polkadot/network
    6testsUnit tests for deliverables above

    Milestone 2 โ€” Porting apiโ€‹

    • Estimated Duration: 1 month
    • FTE: 1
    • Costs: 0.00 BTC
    NumberDeliverableSpecification
    0migrationmigrate all existing code to Null Safety
    1rpc_corePorting and implements @polkadot/rpc
    2rpc_providerPorting and implements @polkadot/rpc_provider
    3metadataPorting @polkadot/metadata

    Milestone 3 โ€” Porting apiโ€‹

    • Estimated Duration: 1.5 month
    • FTE: 1
    • Costs: 0.00 BTC
    NumberDeliverableSpecification
    0typesPorting @polkadot/types
    1api_derivePorting @polkadot/api-derive
    2api_contractPorting @polkadot/api-contract
    3apiPorting @polkadot/api
    4testsUnit tests for deliverables above
    5pub.devPublish to pub.dev for v1.0.0-dev1

    Milestone 4 โ€” Publishingโ€‹

    • Estimated Duration: 1.5 month
    • FTE: 1.3
    • Costs: 0.92 BTC
    NumberDeliverableSpecification
    0testsIntegration tests for all milestones
    1documentationsDocumentations for all packages
    2pub.devPublish to pub.dev for v1.0.0

    Community Engagementโ€‹

    We are buiding our community on https://www.yuque.com/?language=en-us and newsletters will be regularly updated soon.

    What has been done so far?โ€‹

    Milestone 1โ€‹

    StatusNumberDeliverableSpecification
    โ˜‘0LicenceApache 2.0
    โ˜‘1bindings/cryptoRust binding and implements @polkadot/wasm
    โ˜‘2util_cryptoPorting and implements @polkadot/util-crypto
    โ˜‘3utilsPorting and implements @polkadot/utils
    โ˜‘4keyringPorting and implements @polkadot/keyring
    โ˜5networkPorting and implements @polkadot/network
    โ˜‘6testsUnit tests for deliverables above

    Future Plansโ€‹

    Maintainanceโ€‹

    1. Keep following the upgrade of Polkadot-JS and Substrate, and supporting latest upgrades as soon as possible.
    2. Seperate the rust/dart binding libs and other implementations to serveral packages, the native binding libs should be minimize and stable for long term, just like @polkadot/wasm does. And we should be focusing on upgrading the features.

    Products and ecosystemsโ€‹

    1. We have a plan of making a wallet app, using Polkadot-Dart as its main dependency, which has been communicated with many parachains, to prepare for linking into Parachains and lowering the threshold for users to use.
    2. We also have another substrate-based project called Pocket4D, combining Polkadot-Dart and other components, we plan to build a new decentralized network. And Polkadot-Dart will be one of our client side core dependency.
    3. The main purpose of this lib is to co-operate with ecosystem partners, especially Parachains, we need to build and test with them and fit their needs.

    Additional Information โž•โ€‹

    Are there are any teams who have already contributed (financially) to the project?โ€‹

    No.

    Have you applied for other grants so far?โ€‹

    Pocket4D

    - + \ No newline at end of file diff --git a/applications/Polkadot-Protocol-Conformance-Tests.html b/applications/Polkadot-Protocol-Conformance-Tests.html index 520c238ea7a..0f95545b6d5 100644 --- a/applications/Polkadot-Protocol-Conformance-Tests.html +++ b/applications/Polkadot-Protocol-Conformance-Tests.html @@ -4,13 +4,13 @@ Polkadot Protocol Conformance Tests Research Proposal | Web3 Foundation Grants - +
    Skip to main content

    Polkadot Protocol Conformance Tests Research Proposal

    • Team Name: LimeChain
    • Payment Address: 15reUHgnkE9QeH9zUoduCVYAbksTmQXvpMd6L95rBhTNFuGw (USDT)
    • Level: 3

    Project Overview ๐Ÿ“„โ€‹

    This research proposal is in response to the currently open Polkadot Protocol Conformance Tests RFP.

    Overviewโ€‹

    Polkadot has made substantial progress over the last few years in terms of client diversification. Currently, there are 4 existing host implementations with varying features and protocol support: Polkadot by Parity, Kagome by Soramitsu, Gossamer by ChainSafe, and Fruzhin by LimeChain. Having a healthy client diversity is beneficial to every blockchain protocol as it becomes more decentralised and less bug-prone. Neglecting these aspects has resulted in halting block production for some blockchain protocols in the past.

    The nature of software is such that it's never perfect, and bugs happen. Therefore, multiple host implementations come with a higher probability of implementation-specific issues. It's important for a blockchain protocol that takes great pride in its decentralisation, such as Polkadot, to have a protocol compliance testing suite that verifies the behaviour of each implementation. The more comprehensive the testing suite is, the stronger security guarantees the protocol can provide.

    The goal of this project is to prepare for the redesign of the existing conformance tests repository. Our team envisions the redesigned testing suite to be easily extensible and flexible, welcoming contributors to enhance it with their domain-specific knowledge. Concerns have been raised regarding the "adapter" approach that the existing testing suite has taken and that the chosen language (Julia) is out of sync with the one for Polkadot (Rust). This proposal aims to lay the groundwork for resolving these issues by delving deep into the biggest obstacle that stands in the way: finding the correct level of abstraction and tooling that will be the cornerstone for every kind of test scenario.

    Project Detailsโ€‹

    A host-agnostic approachโ€‹

    A conformance testing suite should be host-agnostic, meaning that, for the most part, the tests shouldn't be concerned with the specific Host implementation against which they are being executed. The Host exposes several interfaces that enable conformance testing; however, itโ€™s a complex piece of engineering, and there will always be protocols and functionalities without an exposed interface. Moreover, there are integration tests that can't be conducted using an API. These scenarios are as important as the previous ones because the Host can't function properly if the modules don't work seamlessly with one another.

    Host APIโ€‹

    The Host API consists of a set of functions that the Host exposes to the Runtime. These functions are used to access external resources for various purposes, including storage access, manipulation, memory allocation, and more. If a method within the API contains a bug, it has the potential to push the Host into an incorrect state transition. Such a scenario could lead to undefined consequences, particularly if a significant number of nodes experience the same issue.

    SCALEโ€‹

    Substrate employs a lightweight and efficient encoding and decoding mechanism to optimise the transmission and reception of data across the network. This protocol, known as the SCALE codec, plays a vital role in serialising and deserialising data. It serves as a critical component for data transfer across the peer network and facilitates communication between the Runtime and the Host. Consequently, the presence of comprehensive tests for SCALE encoding and decoding holds immense significance in ensuring the proper functionality of the Host.

    State Trieโ€‹

    The state trie is another crucial part of the Host. A radix-16 state is the data structure that Substrate uses to store the state of the blockchain. Without thoroughly tested state trie functionalities, the Host may transition to an incorrect state and get slashed if it's a block producer.

    BABE & GRANDPAโ€‹

    BABE & GRANDPA are the bread and butter of the consensus-reaching module for Polkadot. However, finding the right tools and approach to test the block production and finalisation protocols independently of the Hostโ€™s environment is a challenge that is yet to be overcome by any team.

    Zombienetโ€‹

    Zombienet aims to be a testing framework for Substrate-based blockchains, providing a CLI tool that allows users to spawn and test ephemeral networks. The assertions used in the tests can include on-chain storage, metrics, logs, and custom JavaScript scripts that interact with the chain

    Our team has successfully utilised Zombienet to run PVF conformance tests as part of another W3F grant. This is the reason why we believe that Zombienet has the potential to be the go-to framework for running conformance tests on the Hosts. The research is going to focus on Zombienet, as well as on the new Zombienet SDK.

    Research Scopeโ€‹

    The main focus of the research will be on investigating each of the aforementioned protocols and functionalities and how they can be tested in a host-agnostic manner. Based on our preliminary research and the work we've conducted on the PVF conformance testing suite, our team believes that Zombienet can serve as the foundation for the testing suite. The team will examine whether Hosts and Zombienet have the required feature set to support such testing scenarios. If this is not achievable, the team will document the missing components so that they can be identified and potentially contributed in a future proposal.

    Our team acknowledges that, for certain Hosts, having the Host API, SCALE, and State Trie as standalone artifacts could be beneficial for Host developers during the early phases of their implementation. However, this proposal primarily focuses on adopting a host-agnostic approach for Hosts that are already functioning with the already existing tests. Depending on the research outcomes, our team may subsequently introduce a new proposal involving the redesign of the conformance repository. In this redesign, the tests would be separated into a standalone artifact and transformed into Zombienet tests.

    Ecosystem Fitโ€‹

    By delivering a research document containing insightful information about the necessary steps to commence the redesign of the Polkadot Conformance Testing repository, we aim for it to serve as a catalyst to initiate the development process

    Initially, the Polkadot Conformance Testing repository will be situated in close proximity to the realm of Polkadot Hosts. Its primary target audience will be Host developers seeking comprehensive testing for their Hosts. Other individuals who might find this project valuable include experts from the Polkadot specification team, who can contribute their expertise in specific scenarios.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Viktor Todorov
    • Maksim Dimitrov
    • Kristiyan Veselinov

    Contactโ€‹

    • Registered Address: Bulgaria, Dragan Tsankov 23A, 1113, Sofia, Bulgaria
    • Registered Legal Entity: LimeLabs Ltd.

    Team's experienceโ€‹

    At LimeChain, we possess considerable expertise in developing various tools, including Gosemble, a framework for building Substrate compatible Runtimes in Go, Fruzhin, a Host implementation in Java, a framework for runtimes in AssemblyScript, a framework for runtimes in AssemblyScript. On top of that, weโ€™re working on a Parachain Validation Conformance Testing suite, have substantial experience in Rust/WebAssembly developer tooling from Matchstick and actively contribute to infrastructure projects in Cosmos and Hedera Hashgraph.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    No actual development has been made for this RFP. However, the team has spent a significant amount of time delving into the Hostโ€™s specification as part of the Java Host implementation we're currently working on. Additionally, our work on the PVF conformance testing suite has enhanced our understanding of how to address challenging-to-test sections of the code.

    Development Roadmap ๐Ÿ”ฉโ€‹

    The primary framework under consideration for this research will be Zombienet, as it already provides the groundwork for these types of tests. Each of the steps outlined below will be dedicated to investigating the creation of Zombienet tests for the specified functionalities. The team will also document in the research report the development steps required to enable testing of the specified functionality using Zombienet.

    Outlined below are the testing scenarios for each Host module that will be the focus of the research:

    1. Host API
      1. Trie
    2. SCALE
      1. SCALE encoding
      2. SCALE decoding
    3. State Trie
      1. Trie encoding
      2. Trie decoding
    4. BABE
      1. Block import
      2. Block validation
    5. GRANDPA
      1. Block import
      2. Block validation

    Overviewโ€‹

    • Total Estimated Duration: 8 working weeks
    • Full-Time Equivalent (FTE): 2
    • Total Costs: $49280

    Milestone 1 โ€” Polkadot Conformance Testing Suite Researchโ€‹

    • Estimated duration: 8 working weeks
    • FTE: 2
    • Costs: $49280
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation, as well as README file with how the suite can be executed. Additional information will be provided on how to contribute.
    0c.Testing and Testing GuideDocumentation will be provided that showcases how the testing suite can be executed for different scenarios and hosts.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains what was done/achieved as part of the grant.
    1.Host API ResearchResearch the feasibility of using Zombienet as the framework for executing Host API tests.
    2.SCALE ResearchResearch the feasibility of using Zombienet for conducting SCALE encoding and decoding tests.
    3.State Trie ResearchResearch the feasibility of using Zombienet for conducting State Trie encoding, decoding and generation tests.
    4.BABE ResearchResearch the feasibility of using Zombienet for conducting BABE tests.
    5.GRANDPA ResearchResearch the feasibility of using Zombienet as the framework for conducting GRANDPA tests.
    6.Research FindingsA research document will be delivered documenting the teamโ€™s findings, as well as outline a high-level path forward for the conformance testing suite.

    Future Plansโ€‹

    Based on the research findings, our team could formulate a proposal for implementing these tests and restructuring the conformance testing suite with the new approach, and/or contributing the necessary features that would enable Zombienet to be utilised for these purposes.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    At LimeChain, we have been contributors to the Polkadot ecosystem for the last 3+ years as we believe in a multi-chain future, based on interoperability and decentralisation. Principles that are built into the core of the Polkadot network. We possess considerable expertise in developing various tools, including Gosemble, a framework for building Substrate compatible Runtimes in Go, a framework for runtimes in AssemblyScript,, and Parachain Validation Conformance Testing. Additionally, we have substantial experience in Rust/WebAssembly developer tooling from Matchstick and have actively contributed to infrastructure projects in Cosmos, Near, Filecoin, Ledger and Hedera Hashgraph.

    - + \ No newline at end of file diff --git a/applications/PolkadotSnap.html b/applications/PolkadotSnap.html index d653c454da8..ca0855fac4a 100644 --- a/applications/PolkadotSnap.html +++ b/applications/PolkadotSnap.html @@ -4,7 +4,7 @@ Polkadot Snap Made by Keystone Wallet Team | Web3 Foundation Grants - + @@ -34,7 +34,7 @@ Grants are 10k USD.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a dapp developer can use this library to use the MetaMask flask as the wallet for the user.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DemoWe will publish an demo to show how to use this library for the dapp developers
    0e.ArticleWe will publish an article that explains how to use this wallet adaptor and MetaMask Flask to interact with Polkadot dapps.
    1.js sdkBuilding the snap application Provider and js sdk which wraps the snap application and provides an injected object for the Dapp developer. Writing the documentation for the Dapp developer.

    Milestone 2:โ€‹

    In milestone two, we will develop the Polkadot Wallet. It will also use our snap and provide functionality like transferring assets like DOT/KSM. Staking etc.

    Here is the feature list for this Polkadot Wallet.

    1. Users can use this wallet to manage their assets like DOT/KSM.
    2. Users can use this wallet to track their transaction history.
    3. Users can use this wallet to manage their NFTs.
    4. Users can use this wallet to contribute the Crowdloans
    5. Users can use this wallet to stake their DOT/KSMs.
    6. This wallet will support both Polkadot and kusama chains.

    The Polkadot wallet we will build which will rely on Polkadot snap to interact with MetaMask. First We will design the new user interface to provide an good experience for the users. Second, we will build this wallet application. It will be our long-term supported product. To hit this milestone, two month full-time work is needed for all our dev/pm on the software side (Aaron Chen - CTO of Keystone, Zhang XiaoChun - Product Manager, Tian li - Software Engineer), 0.5 month full-time work is needed for our QA engineer & UI/UX designer (Xia MengYun- QA Engineer, Zhang XiaoChun - UX Designer). Grants are 20k USD.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can manage their assets with this wallet application.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ApplicationWe will publish the wallet application that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains how to use this application for the whole Polkadot community.

    Future Plansโ€‹

    Once MetaMask merged its Snap function to the normal version, BTCSnap (developed by Keystone) will be promoted as one of top 3 Snaps on its main page where our snaps would get a huge exposure. In a short term, we plan to develop a series of snaps for different chains and make a โ€œSnaps Bundleโ€ upon our Bitcoin Snap where users could easily switch to different snaps for different chains in one place. In the long term, weโ€™ll continue to build various snaps, not only for transactions, but also Defi, NFT, Game etc for different chains to enrich the Keystone Snaps ecosystem and obviously Polkadot will be one of our top priority.

    - + \ No newline at end of file diff --git a/applications/Polkadot_Web_UI.html b/applications/Polkadot_Web_UI.html index 0083ec3ad1b..5c9c9cdf0e0 100644 --- a/applications/Polkadot_Web_UI.html +++ b/applications/Polkadot_Web_UI.html @@ -4,7 +4,7 @@ Polkadot UI Web Identicon + Angular Identicon | Web3 Foundation Grants - + @@ -24,7 +24,7 @@ | 2. | Web_Identicon | implementation of the web component + Testing | | 3. | publishing into NPM registry | | 4. | Documentation/ Tutorials | Documentation and Tutorials on usage example for both Angular and Web Identicon |

    Future Plansโ€‹

    Once the packages validated and deployed, we will enrich the ecosystem by :

    - + \ No newline at end of file diff --git a/applications/Polkaholic.html b/applications/Polkaholic.html index 4058408c97b..47d2c6a260d 100644 --- a/applications/Polkaholic.html +++ b/applications/Polkaholic.html @@ -4,7 +4,7 @@ Polkaholic.io's Multi-Chain Substrate Block Explorer | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ The browser-based code can be tested directly on the site, whereas logs of the server-side code will be exposed in the UI (which objects passed vs failed a verification function).

    Both forms of code will have almost identical core and rely on the polkadot JS API to do RPC calls like this, which gets the block.

    Disclaimer on limitations of verifiability:

    Precise deliverables for each milestone are shown in yellow cells in Section 2 and are referenced below.

    Milestone 1 โ€” Implement Verifiability for Chain, Block, Extrinsics, Accountsโ€‹

    We will deliver verifiable functions concerning:

    NumberDeliverableSpecification
    0A.LicenseGNUv3
    0B.DocumentationWe will provide: (a) inline documentation of the core crawling and indexing processes (b) how to setup polkaholic.io from an empty Google Cloud project
    0C.Testing GuideWe will post a Google Doc to show the above verifiable functions in action: (a) For the browser-based Verification functions, this doc will show how each key site area has a "Verify" button which will show the browser-based code and run the check for the key object (block, extrinsic, account for that page), returning whether the test passed or failed; (b) For the server-based Verification functions, we will document how to configure run the continuous verification, how pass/fail are logged in the database and exposed in the UI.
    1.UI Augmentation: Browser-based JS for VerifiabilityFor all site areas shown in Section 2 "Milestone 1" Deliverables, we will add browser-based code to verify results by utilizing Polkadot RPC calls to WS Endpoints.
    2.Backend Augmentation: Server-side JS for VerifiabilityFor all key pages, we will publish similar server-side code that also verifies results.
    3.Blog PostWe will publish blog posts that show the results of our UI Augmentations.

    We expect any observed failures in verification to result in indexing fixes.

    Milestone 2 โ€” Implement Verifiability for Account Rewards, Transfers, Crowdloans (Direct), Proxy + Multisig accountsโ€‹

    NumberDeliverableSpecification
    0A.LicenseGNUv3
    0B.DocumentationWe will provide inline documentation of the continuous verification processes implemented in Milestone 1 and 2
    0C.Testing GuideWe will augment the Google Doc Testing Guide to show the above verifiable functions in action for the new site areas covered by the verification functions.
    1.UI Augmentation: Browser-based JS for VerifiabilityFor all site areas shown in Section 2 "Milestone 2" Deliverables, we will add browser-based code to verify results by utilizing Polkadot RPC calls to WS Endpoints.
    2.Backend Augmentation: Server-side JS for VerifiabilityFor all site areas shown in Section 2 "Milestone 2" Deliverables, we will publish similar server-side code that also verifies results.
    3.Continuous TestingUsing the server, Continuous random checks on every chain will be applied, outputting verification rates for each chain indexed.
    4.Blog PostWe will publish blog posts that show the results of our UI Augmentations.

    Same as above, but executing on a different set of verification functions:

    Again, we expect any observed failures in verification to result in indexing fixes targeted

    Milestone 3 โ€” Implement Verifiable Timeline UI for XCM Transfers and Messages [UMP, DMP, HRMP]โ€‹

    Similar to the above, in this milestone we develop tooling for XCM Transfers + Messages, which we believe to be central to the success of the Polkadot ecosystem. We propose to build an XCM Timeline UI with verifiability of XCM transmissions for the 3 "common" XCM protocols (DMP, UMP, HRMP) that are already widely between several dozen parachains. A prototype timeline can be seen here and is linked from the XCM Transfers page which shows all indexed XCM Transfer. This XCM Timeline UI and existing XCM Transfer Indexing will be backed by 3 core verification functions that we will develop:

    which each will verify that a extrinsic's XCM message(s) are routed through a relaychain / parachain specific to one of these 3 protocols. A simple verification process will involve verifying whether the XCM Message from a sending chain has the expected extrinsics/events/traces on receiving and downward chains.

    We will attempt to adapt our XCM Timeline tool to support XCM instructions that contain XCM messages (transferReserveAsset, depositReserveAsset, initiateReserveWithdraw, initiateTeleport) within that scope, thus potentially involving more than 2 chains.

    We will restrict our XCM timeline tool to DMP, UMP, and HRMP/XCMP and our restrict our scope to existing v2 and v3 messages.

    NumberDeliverableSpecification
    0A.LicenseGNUv3
    0B.DocumentationWe will provide: (a) inline documentation of the XCM Indexer and how the matching process between sending and receiving chains works for XCM Messages; (b) APIs for retrieving indexed XCM messages + transfers with XCM v2+v3
    0C.Testing GuideWe will augment the Google Doc Testing Guide to (a) explain how the XCM Timeline UI "Verify" functionality can be accessed and used to test each of the 3 XCM protocols in scope; (b) explain how recursive XCM messages within the same scope can be covered.
    1.UI Augmentation: XCM Messages VerifiabilityUsing the same approach as in Milestone 1 and 2, we will augment the Polkaholic.io with browser-based JS and server-side JS to support verifiability of XCM Results.
    2.Continuous TestingUsing server-side JS, continuous random checks on recent XCM Messages chain will be applied, outputting verification rates.
    3.Blog PostWe will publish a blog posts that demonstrate the Polkaholic.io XCM Messages and Transfers API and new Timeline functionality.

    We expect any observed failures in verification and the XCM Timeline tool to result in indexing fixes targeted at XCM specifically.

    Future Plansโ€‹

    Polkaholic.io intends to operate its multi-chain block explorer for Polkadot users long-term, as well as supporting parachain developers and dapp developers with XCM tooling and APIs that just work.

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/Polkawatch.html b/applications/Polkawatch.html index 5d843a01058..1c35ec41ad6 100644 --- a/applications/Polkawatch.html +++ b/applications/Polkawatch.html @@ -4,13 +4,13 @@ Polkawatch | Web3 Foundation Grants - +
    Skip to main content

    Polkawatch

    • Team Name: Valletech AB
    • Payment Address: 0xA39bD6af74f8c317F45137d2ED7F4e13176d916B (ETH/DAI)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Polkawatch is an Encode Hackaton Finalist project that received a runner up nomination. See 3 minutes final pitch video here.

    Overviewโ€‹

    Polkawatch tagline is: Polkadot's decentralization is everybody's job.

    Polkawatch will provide decentralization analytics about Polkadot. Allow all stake-holders to gain insights about where network activity is taking place (regional, network provider, validator group, nominator segment, etc).

    With Decentralization insights the community can act to improve decentralization regardless of their role: Adjust Nomination, Start Validation in new Networks / Geographies, etc.

    Polkawatch is built on top of Substrate Block Explorers (i.e. SubQuery) adding an extra analytic layer.

    Polkawatch crosses chain data with external datasources and traces weak on-chain relations. Initially for Polkadot, Polkawatch could be used for any substrate blockchain.

    Why Polkawatch? All started by helping a validator of the 1000 validator programme design a strategy to improve its share of network activity/election. We identified centralization as a problem and opportunity. As preliminary data shows more than 50% of activity in just 2 cloud providers and/or nations. Validators with poor network share could be the decentralized answer to this problem.

    Unavailability Slashing takes place if at least 10% of active validators go offline. There is precedent of swift deplatforming by cloud providers and sudden regulation change by Countries. Nominators need to be aware that supporting "too centralized" validators poses significant more risk than nomating validators in network and countries below the 10% threshold. It also makes our community stronger and more resilient.

    Project Detailsโ€‹

    Lucene inverted index is the core technology component of many Analytics Engines, Its capability to parallelize ingestion and query is unprecedented. This project has a clear functional scope but it is also an interesting experiment in term of building an Analytic Engine for a substrate blockchain.

    • The main data structure is a collection of fully "decorated" Reward events/documents. By "decorating" a reward we mean to add to the event everything we know by analyzing the blockchain, and crossing its data with external data sources. The collection of events is then indexed on a Lucece Inverted Index to facilitate its analytics.
    • The following mock-ups, based on unaudited polkawatch prototype data, show the target analytics to provide, distribution of network activity by: Geographic and Computing Network, Validator Group and Nominator Segment, Tables with broken down data and generic information about the dataset.
    • The following Architecture Diagram Shows the main Components:
      • Indexer: Will read and index the blockchain using a Lucene Inverted Index. The main Event to trace is the reward event. Will be decorated with all data that can be deduced from the blockchain crossed with external datasources: Geographic and Networking data.
      • Live Query Server: Will provide an API interface to the Indexed data, ready to be consumed by the DAPP and the DPP Publisher.
      • Distributed Data Pack Publisher: Will publich to IPFS Polkawatch Queries of general interest, those related to general network status. The Data Pack is presumed immutable for a given last processed block number, and must be "IPFS friendly", i.e. once an Era has been claimed completely its reward data should be inmutable.
      • DAPP: The DAPP will consume mainly the IPFS DPP, although it may also consume Substrate RPC to learn about the Network Status and Objects of User interest (Wallet). It could potentially also request advanced queries to the Live Query Server, although most queries are expected to be ready as a DPP.
    • The API to be provided by the Live Query server each entry point (Query) represents a set of filters and aggregations to apply to lucene queries. This component can be fairly generic, in the sense that each entrypoint can be mapped to a lucene query with the help of a templating engine.
    • The technology stack to be used will be Javascript/TrueScript for the Live Query Server and DPP publisher, React+Gatsby for the DAPP, Material UI for the UI components, Gitlab will be used for CI/CD, and IPFS/IPFS Cluster for publishing.
    • During the Hackaton Subquery and Elasticsearch were used as base components for the indexer. This choices will be re-visited after reviewing all indexers in the community and also other lucene databases such as Apache Solr.
    • What your project is not or will not provide or implement
      • This project will not create a Generic Indexer based on Lucene Inverted Index but rather extend, complement or fork an existing indexer in our community.
      • This project will not provide a generic staking dashboard or wallet, but rather focus on the analytics, grand view and support the decision making related to the nomination and validation activities.

    Ecosystem Fitโ€‹

    Polkawatch will use a blockchain indexer, modify or extend it for a particular analytic use case, based on Lucene inverted index. This project may be of interest to decide if inverted indexes or analytic capabilities should be built into indexers in a more generic way.

    The Polkadot ecosystem needs effective decentralization and polkawatch can help. The community is already debating about this, and visibility of network activity will enrich the debate.

    This project sits next to blockchain explorers, but its output will be graphic, analytic instead of detailed transactional.

    Similar Projects

    • Yieldscan analyzes staking from a yield performance point of view. Polkawatch will focus on decentralization.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Rafael del Valle Lopez
    • David Bellhoff

    Contactโ€‹

    • Registered Address: Blรฅmesv. 26, 186-47 Vallentuna, Sweden
    • Registered Legal Entity: Valletech AB, Org. Num: 5590673694

    Team's experienceโ€‹

    Rafael have over 20 years experience creating Software Product, Services and Ventures. In the last years has started to contribute to Open Source projects in the Infrastructure field. A significant contribution to Open Nebula was the Python Bindings, now part of the official distribution. More recently the Privaz.io project was created with the goal to facilitate the adoption of Private Clouds by small projects.

    David has a background in Geographic Information Systems and data science. His first Programming languages were Python and R which he used to build a geographic database and to run statistic models for simulations. Later he learned Javascipt and Typescript and has built web applications with different stacks (Postgresql, Django, Mongodb, node.js, React). In 2021 he started learning Rust and completed the Substrate Developer Academy in November. He is also a core contributor to the DEGEN project of Bankless DAO.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    A development prototype was created during the encode hackaton, the purpose was mainly to establish viability of Polkawatch and gather community feedback. Multiple strategies where tested/implemented during the 3 week development time in seek of viability.

    The prototype is a "hack" of a SubQuery project where a Lucene (elastic) index server is introduced. Several data structures are introduced to trace weak event releationships and map with external databases (GeoIP). A minimal dApp to present the data was also introduced and is available at https://polkawatch.app

    The current prototype has been useful is gathering feedback from participants about the potential of this project.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 10 weeks
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 28,500 USD

    Milestone 1 โ€” Data Management Modulesโ€‹

    • Estimated duration: 5 weeks
    • FTE: 2
    • Costs: 14,250 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up the project deliverables.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) / Dockercompose that can be used to test all the functionality delivered with this milestone.
    1.Indexer ExtensionIndexer Node Module/Extension with additional required capabilities: Inverted Index and weak relationship tracing. The relationship "traces" will be available for later user to "trust and verify".
    2.Live Query ServerLQS Node Module that provices a programatic interface to the indexer, implemented in Typescript/Javascript. The implementation will be generic and template based, mapping entrypoints to lucene filters and agregations.
    3.Gitlab PipelinesContinuous integration deliverables will be created for automated build and test of each module. Continuous delivery will include steps to update docker images of the deliverables.

    Milestone 2 โ€” Data Presentation Modulesโ€‹

    • Estimated Duration: 5 weeks
    • FTE: 2
    • Costs: 14,250 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up the project deliverables.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a blog post about Polkawatch, it will include information about: how to check the effective decentralization of the network, how to check the effective decentralization of a nominator and how to adjust the nomination to better contribute to decentralization of the network. A companion Video tutorial will also be provided.
    1.DDPDistributed Data Pack builder node module, implemented in Typescript/Javascript. Will use the LQS to build IPFS friendly data to be consumed by the DAPP.
    2.DAPPDistributed Application Node/React module, implemented in Typescript/Javascript. React based DAPP, built with a modern and fresh UI toolkit (such as Material UI or Chackra). Gatsby will be used to efficiently pack the DAPP.
    3.Gitlab PipelinesContinuous integration deliverables will be created for automated build and test of each module. Continuous delivery will include steps to update docker images of the deliverables and publish IPFS updates.

    Future Plansโ€‹

    Polkawatch will be used to raise awareness of decentralization of the network in the community.

    We plan to work with validators to improve their network share in the cases in which they improve the decentralization of the network.

    Ideally the data provided by Polkawatch could result in a Validator alliance with a decentralization brand promise such as avoiding crowded geographies or IP networks/cloud providers.

    We would also like to see decentralization turned into active economic policy. The same way that unavailability is slashed, validating in underrepresented geographies or IP networks could be rewarded. In that sense, we would like Polkawatch to become a tool to assist in policy decision making.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We found out in the Web3 Foundation Website.

    - + \ No newline at end of file diff --git a/applications/Primis.html b/applications/Primis.html index 71ad0ae57e9..9d95aede781 100644 --- a/applications/Primis.html +++ b/applications/Primis.html @@ -4,13 +4,13 @@ Primis | Web3 Foundation Grants - +
    Skip to main content

    Primis

    • Team Name: Primis
    • Payment Address: 0x0Ad212E301AD590f4E70dA0c0Aa2912273cB4098 (USDC)
    • Level: 1

    Project Overviewโ€‹

    Overviewโ€‹

    Primis Desktop provides a one-stop Web3 integrated client for the Polkadot ecosystem.

    Primis Web3 Desktop for Polkadotโ€‹

    Primis Wallet

    Primis Desktop Wallet is the best tool to manage multi-chain assets on the Polkadot ecosystem, such as Polkadot, Kusama, and other parachains. Asset management mainly includes digital/NFT assets checking, sending, receiving, and trading records on the Polkadot ecosystem.

    P2P Chat

    Primis Desktop provides encrypted chat groups for Polkadot ecosystem users to discuss decentralized Gov2 governance and Proposal freely. ZK-Proof technology will be combined into Primis chat groups to offer more privacy and decentralized DAO governance space.

    Primis Desktop could automatically create encrypted chat groups for Polkadot ecosystem DApps, each DApp has its own independent chat group.

    • Channels For Chatimage
    • P2P Chatimage

    Subscribe

    Primis Desktop also is a place for users to subscribe to Polkadot decentralized notifications like EPNS. Initially, Primis Desktop will provide asset change notifications for Polkadot, Kusama, and other parachains. More on-chain DApps notifications to exploit in the future.

    Primis Web3 PNS Browser

    Primis Desktop will gestate a Chrome-compatible PNS browser for the Polkadot ecosystem, allowing Polkadot ecosystem users to access Web2 pages and interact with Web3 DApps freely. Primis Web3 PNS Browser supports Polkadot ecosystem PNS domainsโ€™ resolution and visit.

    Unlike traditional browsers such as Chrome, Brave, and Web2 centralized Cloud Service, Primis Web3 PNS Browser is based on a data relay network, where access and application data are transmitted to clients or Primis terminals through a relay network of Primis nodes.

    DApp Self-Hosting Platform

    Primis Desktop provides the plug-in function. All DApps on the Polkadot ecosystem can integrate and deploy on the Primis relay node network and upgrade and confirm through the reliable connection contract in a smart contract to ensure applicationsโ€™ security.

    Due to being the first Web3 desktop, Primis will interact with Polkadot's Web3 Ecosystem and bring the brand-new desktop concept to web3 users of Polkadot.

    All of our teammates truly believed in the Web3 Revolution! That's why we want to boot this Web3 project.

    Tech Stackโ€‹

    Supported Chains: Polkadot, Kusama, and other Parachains such as Acala, Astar, and Moonbeam.

    Client language: Electron, React

    Server language: Nodejs

    P2P language: Golang

    Ecosystem Fitโ€‹

    Primis is the first blockchain project known as the web3 desktop. And we want to attract more other ecosystems' web3 users to Polkadot ECO. Since primis is based on the concept of Web3, it has strong relationships with the most famous web3 organization W3F, and must be born here.

    Teamโ€‹

    Team membersโ€‹

    Primis team has rich experience in the fields of the public chain, infrastructure, and defi. Team members' info will be released after reviewing.

    Contactโ€‹

    • Registered Address: This info will be released after reviewing
    • Registered Legal Entity: Also, this info will be released after reviewing.

    Team's experienceโ€‹

    Primis team has developed some blockchain projects, like Metauce

    Team Code Reposโ€‹

    Github

    Team LinkedIn Profiles (if available)โ€‹

    This info will be released after reviewing

    Development Statusโ€‹

    Primis Team already completed the designing work of Primis Desktop and started working on Milestone 1 Tech Tasks.

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 6 weeks
    • Full-Time Equivalent (FTE): 3 FTE
    • Total Costs: 10,000 USD

    Milestone 1 - Polkadot ECO Walletโ€‹

    • Estimated duration: 6 weeks
    • FTE: 3
    • Costs: 10 ,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe would provide an inline document of code and tutorial docs that explain how users can install it.
    0c.Testing GuideUnit tests will cover all core functions to ensure functionality and viability.ย We will describe how to run the tests in the tutorial.
    0d.DockerWallet application does not require Docker, and we would provide a client for users to install under Windows/MacOS system.
    1.Build app structureWe will have the core structure of the application in place.
    2.Implement wallet viewCreate, import, view, and transfer functions will be provided by the integrated Polkadot wallet.
    3.Build Polkadot ECO walletChecking, sending, receiveing assets of Kusama, Moonbeam, and Acala will be provided for Primis users.
    4.NFT assets managementNFT assets can be viewed, sent, and received under Primis.
    5.Setup Primis NFT avatarUsers can set NFTs as their wallet avatars.

    Future Plansโ€‹

    Short-term: After finishing all milestones, the users' amount of Primis web3 desktop will be over 50K.

    Long-term: The most influenced Web3 desktop

    Additional Informationโ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/PrivaDEX_aggregator.html b/applications/PrivaDEX_aggregator.html index 90433b74c1d..fc50fd881ec 100644 --- a/applications/PrivaDEX_aggregator.html +++ b/applications/PrivaDEX_aggregator.html @@ -4,14 +4,14 @@ PrivaDEX: Cross-Chain DEX Aggregator MVP | Web3 Foundation Grants - +
    Skip to main content

    PrivaDEX: Cross-Chain DEX Aggregator MVP

    • Team Name: OCamlMyCaml
    • Payment Address: 13BpdtqDLM25KfCb5ttYy1opDP1sHmUNQka8QZi5DqQ3UGAV (Polkadot - USDT)
    • Level: 3

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    PrivaDEX is a cross-chain DEX aggregator that enables cross-chain trading and unifies Polkadot's fragmented DeFi ecosystem.

    DeFi in Polkadot is frustratingly fragmentedโ€‹

    There are currently five parachains that each hold 10-35% of Polkadot's total DEX TVL, with four more parachains that plan to soon launch (or have recently launched) their flagship DEX. Despite having so many trading venues available, 80% of DEX users trade on a single parachain - and are thus limited to 10-35% of the available trading opportunities [1]. Pie chart

    The reason is simple; cross-chain trading is far too cumbersome. Executing a cross-chain swap is a 5 minute endeavor that requires several DEX swaps, manually bridging tokens, and waiting for all the transactions to be processed [2]. In short, DeFi in Polkadot is frustratingly fragmented.

    [1] Based on results from surveys like this one, collected from users of StellaSwap, BeamSwap, ArthSwap, and AcalaSwap.

    [2] Coming from a trading background, Kapil developed and ran systematic trading strategies in the Polkadot ecosystem a few months ago. At the time, liquidity was particularly scarce in light of the Nomad bridge hack and the Acala hack, necessitating multi-venue trading. Nevertheless, he found it impossible to systematically trade cross-chain due to the lack of existing automation.

    PrivaDEX defragments DeFiโ€‹

    PrivaDEX automates cross-chain messaging and smart order routing so that traders donโ€™t spend those 5 minutes manually executing one cross-chain trade. Now it's one step.

    By pooling liquidity from several DEXes across chains, PrivaDEX has access to more liquidity than any existing DEX. Further, it optimizes order splitting/routing to minimize price impact and achieve the best prices for users. PrivaDEX makes it 1-click-easy to efficiently trade across parachains.

    Project Detailsโ€‹

    Architectureโ€‹

    Technical flow

    Moving left to right in the above diagram, the development stack consists of

    1. Typescript and GraphQL for the blockchain indexing to generate price feeds
    2. Phat Contract Rust code, which looks like ink! smart contract code and acts like an AWS Lambda (off-chain stateless/serverless computing)
    3. React for the swap UI

    Proof-of-Conceptโ€‹

    We have developed a proof-of-concept for the executor module here. This PoC, implemented in a Phat Contract demonstrates the following steps:

    1. The user sends the sourceToken to the protocol.
    2. The protocol XCM asset transfers this token amount to the destinationChain.
    3. The protocol swaps sourceToken for destinationToken on the remote chain's Uniswap-like DEX.
    4. The protocol transfers destinationToken from its escrow account to the user's wallet on destinationChain.

    Existing Code and Design Documentsโ€‹

    Please check out the main repo. It contains some of the source code we have already written as well as design documents (in README files) for the incomplete items.

    Ecosystem Fitโ€‹

    Serving DEX users on every parachainโ€‹

    While Polkadot is designed for interoperability amongst chains, most XCM development efforts (e.g. X-Tokens/XTransfer pallets, bridges, remote execution) largely still serve developers, not lay end users.

    PrivaDEX is intended for DEX users on every Polkadot parachain. It enables users to conveniently trade cross-chain and efficiently trade intra-chain.

    Comparing to EVM DEX aggregatorsโ€‹

    There are no similar DEX aggregators in the Polkadot ecosystem. Other blockchains have DEX aggregators that generally fall under two categories:

    1. Intra-chain DEX aggregator like 1Inch: these find optimal routes by consolidating data from multiple DEXes on a single chain. There is no cross-chain component.
    2. Multi-chain DEX aggregator like Rango Exchange: these have poor (1) support for non-EVM chains, (2) UX, and (3) quality of routing solutions. PrivaDEX addresses these three shortcomings:

    (1) PrivaDEX has built-in Substrate and EVM compatibility and thus can uniquely integrate with any parachain (and associated XCMP channels).

    (2) PrivaDEX requires the user to sign just one transaction. Multi-chain aggregators like Rango require the user to sign a transaction each step of the way. This makes for a huge UX difference: users should be able to click a button and walk away, not need to stay on a webpage for minutes and sign multiple transactions along the way.

    (3) PrivaDEX smart order router logic involves splitting the route to optimize for price impact (which becomes a significant consideration where liquidity is relatively low). Rango never splits routes to optimize for price impact. Note that this is not a simple add-on feature because it is also a result of their requirement that a user sign every transaction - they would have to ask the user to sign 2-3x as many transactions to account for these split routes!

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Kapil Sinha
    • Ayan Bandyopadhyay
    • Bradley Justice

    Contactโ€‹

    • Registered Address: We do not have a registered address
    • Registered Legal Entity: We do not have a registered legal entity

    Team's experienceโ€‹

    Kapil, Ayan, and Bradley had earlier built DealDex, an investing platform for Web3 angel syndicates. Before that, they had built RTCanary, a video conferencing analytics platform.

    Kapil developed trading systems for a large trading firm and later personally developed and ran systematic strategies on StellaSwap and BeamSwap.

    Ayan improved security and developed UI for Robinhood and later at CoinTracker.

    Bradley developed automation infrastructure, focusing on fault tolerance and failover scenarios, at Microsoft Power Automate.

    Team Code Reposโ€‹

    The main source code repo (check out the progress thus far!) is at

    Team GitHub accounts:

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Market Research & Inspirationโ€‹

    Kapil personally felt the need for a user-friendly aggregator when he was systematically trading on Moonbeam's DEXes from August to September 2022. Scaling any strategy on a single venue was impossible. Low liquidity meant high price impact, and diminishing marginal returns meant high opportunity cost. Manually swapping tokens and bridging them from various UIs took too much time and manual involvement.

    Parity's Rae Deng summarized the need for a DeFi aggregator in Polkadot in this Polkadot forum post:

    [There is a need for a] DeFi aggregator like 1inch or Matcha using XCM. Right now the liquidity is scattered on different parachains. It would be helpful to have a DeFi aggregator which can find the best route to swap assets by leveraging liquidity on different parachains.

    Current Progressโ€‹

    We have developed a proof-of-concept here.

    The work-in-progress source code and design docs (in README files) are in the main repo. We have made good progress on the price feed, chain metadata store, and network graph generation. Together, these components allow us to auto-generate a network graph of the ecosystem with real-time prices.

    You can find a snapshot of this token graph (comprising Polkadot, Moonbeam, and Astar; scraping data from StellaSwap, BeamSwap, and ArthSwap) that we auto-generated here (raw data is here).

    Development Roadmap ๐Ÿ”ฉโ€‹

    We had started development in the first week of October, so we have made good headway towards achieving the below milestones.

    Overviewโ€‹

    • Total Estimated Duration: 5.5 months (~2.5 more months)
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 55,000 USD

    Milestone 1 โ€” Network graph generator APIโ€‹

    Note: This milestone is largely completed. You can find a sample output snapshot of a graph comprising Polkadot, Moonbeam, and Astar here (raw data is here).

    • Estimated duration: 1.5 months
    • FTE: 2
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can call the API to generate an execution plan.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. There will be a standalone example that calls the API and generates a graph dot file.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test the API delivered in this milestone.
    1.Price feed for ArthSwapWe will create a GraphQL API to scrape prices from ArthSwap's constant product AMM contracts.
    2.Price feed for StellaSwapWe will create a GraphQL API to scrape prices from StellaSwap's constant product AMM contracts.
    3.Price feed for BeamSwapWe will create a GraphQL API to scrape prices from BeamSwap's constant product AMM contracts.
    4.Rust GraphQL clientThis Rust client will construct queries for the above GraphQL APIs and deserialize responses into Rust-native structs.
    5.Chain metadata storeThis Rust crate will contain bridge, chain, DEX, and token metadata for the Polkadot ecosystem necessary to construct a complete network graph.
    6.Graph libraryWe will heavily leverage the existing Rust graphlib library but make modifications to support no_std.
    7.Network graph constructionThis will combine GraphQL queries and the chain metadata store to create the graph using the above graph library.

    Milestone 2 โ€” Execution plan generator APIโ€‹

    An execution plan is a series of steps (e.g. swap ASTR for DOT on Arthswap, transfer DOT to Polkadot relay, etc.) to convert sourceToken on sourceChain to destinationToken on destinationChain.

    • Estimated duration: 1 month
    • FTE: 2
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can call the API to generate an execution plan.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. There will be a standalone example that calls the API and generates an execution plan.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test the API delivered in this milestone.
    1.Smart order router algorithmThe SOR will find the optimal path through the graph created in the previous milestone, outputting a GraphSolution.
    2.GraphSolution to ExecutionPlan converterThis Rust crate will translate a GraphSolution into an ExecutionPlan e.g. convert directed graph edges [ARSW -> ASTR, ASTR -> DOT, DOT_Astar -> DOT_Polkadot] into abstract instructions that can be used to submit transactions and extrinsics later.
    3.ExecutionPlan validatorThis Rust module will check invariants in the outputted ExecutionPlan to ensure it is valid and executable.

    Milestone 3 โ€” Executor Moduleโ€‹

    The executor module is Phat Contract code that actualizes the above execution plan, submitting transactions and extrinsics to perform swaps, bridges, and transfers.

    FAQs on Phat Contractโ€‹

    What is Phat Contract?

    • Phat Contract is a decentralized off-chain computation framework developed by Phala Network. Note that there is zero connection between Phat Contract and the Phala blockchain, as this framework is entirely off-chain.

    Why use Phat Contract?

    • Phat Contract allows us to securely store our protocol's keys (both wallet secret keys and off-chain storage API keys) in the contract (via the Trusted Execution Environment). As a result, we can submit transactions/extrinsics from a decentralized and transparent computing environment instead of a centralized service.

    How can we evaluate Phat Contract?

    • We will place all business logic in separate modules, and create a thin Phat Contract wrapper that ties the components together. That means that every logical component can be run from a standard computer because it will be normal Rust code (similar to Substrate blockchain code). In fact, one can even perform an end-to-end test (that moves and swaps real tokens) from a local environment since secret keys can be kept locally.
    • Estimated duration: 1.5 months
    • FTE: 2
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can call the Phat Contract execute the next step of their cross-chain swap.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to generate the WASM code. Note: Phat Contract runs in a Trusted Execution Environment and local deployment is not well supported yet. We will provide instructions on how to run this component via the Phat Contract UI.
    1.Rust Ethereum interface utilsThis Rust mod will provide helper utilities to construct Ethereum transactions and parse Ethereum transfers.
    2.Rust Substrate interface utilsThis Rust mod will provide helper utilities to wrap RPC calls (e.g. to query nonce, runtime version, block hash) and deserialize them into Rust-native structs.
    3.Substrate extrinsic signature and construction utilsThis Rust mod will handle the various chains' signature schemes (Sr25519 and ECDSA), and construct extrinsics using those signatures and payloads. This code will leverage components of subxt but note that we cannot use it as-is because of limited memory constraints in a Phat Contract. This means that we will need to write our own low-level code to encode extrinsics correctly.
    4.Phat Contract controller/driverAs the event driver that runs in the Phat Contract, this will have functions to process each supported ExecutionStep and create the appropriate transactions/extrinsics. It will also expose this processStep function to the caller.

    Milestone 4 โ€” Consolidated backend API and swap UIโ€‹

    The backend API ties together the above components and builds in a scheduler to handle multiple sequential steps, exposing REST functions that can be called from a browser. The swap UI provides a frontend for this API.

    • Estimated duration: 1.5 months
    • FTE: 2
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use the API to execute their cross-chain swap.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerN/A. The main deliverables are the UI and its REST backend (that connects to the Phat Contract, which cannot be run locally), so containerization provides little value.
    0e.ArticleWe will publish an article/workshop that explains how to DEX users on how they can use PrivaDEX to perform cross-chain swaps and intra-chain aggregated swaps.
    1.S3 API for executorBuilding on Phat Contract's S3 example code here, this S3 API will perform state management for the executor e.g. keeping track of the status of an ExecutionPlan.
    2.Executor module schedulerLeveraging Phat Contract's rollup scheduler and the above S3 API, this scheduler will manage state and call the appropriate processStep function (from the previous milestone) for pending swaps. Note that Phat Contract inherently is stateless and because it requires wait times between block inclusion, it performs one step at a time.
    3.QuoteGetter APIThis API will be called by the UI to estimate a quote before the user requests a swap. It will construct the network graph and call the smart order router (as defined in the previous milestones), and estimate a quote based on the computed route.
    4.SwapRequest APIThis API will be called by the user via UI to transfer funds to the protocol and initiate the swap ExecutionPlan.
    5.GetSupportedChainTokens APIThis API will be called by the UI to generate a list of tokens (and chains) from/to which the user can swap.
    6.Swap UIThis Uniswap-like UI will use the APIs defined in this milestone for its backend calls. It does not require a database but will be hosted by a cloud provider. The frontend will leverage existing code e.g. components from the Uniswap interface.

    Future Plansโ€‹

    We will manage a Discord channel to communicate directly with end users. Closer to the end of the MVP development, we will make announcements to prepare for our launch.

    Long-term, we intend PrivaDEX to be a cross-chain DeFi hub for Polkadot. We will continue to improve the product and develop new features (e.g. parallel processing of execution steps to decrease slippage) to improve trade execution.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Rob Habermeier recommended that we explore Web3 support and reach out to Parity Growth. Nicolas Arevalo advised me further to apply for a Web3 grant!

    We have applied for a grant from the Moonbeam Foundation that is more focused on providing value to the Moonbeam EVM ecosystem.

    - + \ No newline at end of file diff --git a/applications/Profond.html b/applications/Profond.html index 1b581eb4e31..8889ba8f6fc 100644 --- a/applications/Profond.html +++ b/applications/Profond.html @@ -4,14 +4,14 @@ [Profond.ai](http://Profond.ai) - No Code Builder for artists and developers to build, validate, and scale their dApp. | Web3 Foundation Grants - +
    Skip to main content

    Profond.ai - No Code Builder for artists and developers to build, validate, and scale their dApp.

    • Team Name: Profond AI, Corp.
    • Payment Address: 0x92710b669eA59b348cfbe6dcA8682DAabfB5f06A (USDC)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Profond.ai is web3 tools to help developers and creators to build, validate, and scale their dApps. We provide smart contract builder (NFT and token), analytic, and indexer.

    Weโ€™re focusing on emerging chain and we aim to onboard millions of developers by making it easier onboarding for users to create smart contracts.

    Project Detailsโ€‹

    Weโ€™re inspired by Pagoda.co, no code builders in the Near Ecosystem. It provides:

    1. No Code Builder: Create smart contracts for Token and NFT
    2. Indexer (coming soon): To help successful projects and enterprises scale their dApp.
    3. Analytics (coming soon): Data analytics for smart contracts, covering volume, users, transactions, and gas fees.
    4. API Analytics (coming soon): To get data from analytics.

    Currently, weโ€™re building MVP for users to create NFT and Token. Analytics, API and Indexer is still under development.

    Weโ€™re planning to add more parachains from Polkadot and Kusama to our platform. Hereโ€™s our current MVP: http://console.profond.ai/

    Create NFT CollectionNFT ToolsNFT Tools, currently require users to manually upload the collection via NFT-Up, weโ€™re working to make it drag&drop

    Untitled (2) Token/Coin tools. Weโ€™re looking at the example when we creating 1 million XOIN token (see โ€œCoin Mintingโ€ section)

    AnalyticsExample of smart contract analytic. In this image, weโ€™re doing analytic on marketplace.paras.near.

    Ecosystem Fitโ€‹

    We aim to launch on Polkadot and Kusama, hereโ€™s what problem weโ€™re trying to solve:

    • For creators, creating a smart contract for their NFTs and tokens is hard. Especially in relatively new WASM smart contracts like ink! .
    • For UI developers, blockchain development is too complex. Furthermore, each chain has its own complexity.
    • Limited tooling for Polkadot and Kusama ecosystem.
    • For emerging chain, we help them create smart contract templates.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • CEO & Founder: Adhiguna Mahendra
    • Product Lead & Founder: Ekki Rinaldi (Ekki)
    • Full-stack Developer & Founder: Rizky Irfianto (Irfi)
    • Database Engineer & Founder: Bagas Prakasa
    • Full-stack Developer: Ade Yusup
    • Smart Contract Engineer: Amajid Sinar (Jedi)
    • Business Development: Vincent Salaka

    Contactโ€‹

    • Registered Address: 2810 North Church Street, Wilmington, Delaware 19802
    • Registered Legal Entity: Profond AI, Corp.

    Team's experienceโ€‹

    Our founders weโ€™re building the biggest NFT marketplace in the Near ecosystem (Paras NFT Marketplace) and recently integrated with Astar Network. As builder and part of NFT community, we understand what builders need (especially FE engineer) and for artist who want to launch their on NFT. Our team led by tech veteran who had experience working in Silicon Valley, Adhiguna Mahendra, with 20+ years of experience.

    We helped grow the NEAR NFT ecosystem by contributing to NFT with open-source projects such as NFT smart contract standard, marketplace smart contract, vesting smart contract, and so on as you can see on the projectโ€™s repo: https://github.com/parasHQ/

    Hereโ€™s our recent works:

    Paras Launchpad: https://launchpad.paras.id/ - NFT Launchpad in Astar using ink!

    Arkana Raffler: https://arkana.gg/

    Pipapo Ticketing System: https://pipapo.io/

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    PoC โ†’ Hereโ€™s our current MVP http://console.profond.ai/

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: Duration of the whole project (e.g. 2 months)
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: $10.000

    Milestone 1 โ€” No code smart contract builderโ€‹

    • Estimated duration: 1 month
    • FTE: 2
    • Costs: 4,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide documentation page on how to create NFT (PSP34) and FT (PSP22) smart contract with our interface. API documentation for project settings will also be provided.
    0c.Testing and Testing GuideAll functions will be covered with full integration test, testing guide will also be provided.
    0d.ArticleWe will publish anย article that explains the no code builder
    1.No Code NFT Creation (ink!)Allows users to create NFT collection smart contract (PSP34) using ink! in one of WASM supported Parachains. User will be able to login with Polkadot Wallet (SubWallet, polkadot.js, Talisman) and then deploy smart contract with provided code hash. The code hash will be uploaded using selected templates from OpenBrush PSP34 Smart contract. We are abstracting the technical details from users, users just need to upload NFT images, set metadata, and pay gas fee to deploy the smart contract. We will be using useInkathon for wallet and transaction, Next.Js for frontend framework, and OpenBrush for smart contract templates.
    2.No Code Fungible Token Creation (ink!)Allows users to create NFT collection smart contract (PSP34) using ink! in one of WASM supported Parachains. User will be able to login with Polkadot Wallet (SubWallet, polkadot.js, Talisman) and then deploy smart contract with provided code hash. The code hash will be uploaded using selected templates from OpenBrush PSP22 Smart contract. We are abstracting the technical details from users, users just need to set metadata and pay gas fee to deploy the smart contract. We will be using useInkathon for wallet and transaction, Next.Js for frontend framework, and OpenBrush for smart contract templates.
    3.Project Management ModuleAllows users to create more than one projects. We are using NestJS for backend framework.
    4.Multichain IntegrationAllows users to choose between Polkadot Parachains and Kusama

    Milestone 2 Example โ€” Analytics and APIโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 6,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide documentation page on how to create basic NFT collection (PSP34) using our no-code builder and creating a fungible token (PSP22).
    0c.Testing and Testing GuideAll functions will be covered with full integration test, testing guide will also be provided.
    0d.ArticleWe will publish anย article that explains the analytics and API usage
    1.Analytic FunctionalityAdd on-chain analytic for the smart contract.
    2.REST API ServiceAPI for users to get the data analytic.

    Future Plansโ€‹

    Experimenting in business model. We have two kind of ideation we want to validate:

    1. Indexer service, providing RPC for dApp to cut their operational costs
    2. Royalties enforcement for each NFT created.

    On top of that, we aim to onboard more emerging chains and big chains like Solana and Ethereum.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/QRUCIAL_DAO.html b/applications/QRUCIAL_DAO.html index 2b16ea982d1..37afdf719ef 100644 --- a/applications/QRUCIAL_DAO.html +++ b/applications/QRUCIAL_DAO.html @@ -4,7 +4,7 @@ QRUCIAL DAO | Web3 Foundation Grants - + @@ -21,7 +21,7 @@ The increase and decrease of every individual auditor is relative to the ร‰lล‘ score of the original auditor and the one re-auditing a project.

    High ranked auditor wins:

    Low rated auditor wins:

    What is the CCTF talent pool?โ€‹

    CCTF provides a proven track record of hackers solving challenges and based on their reputation, they are awarded as manual auditors in the QDAO ecosystem.

    Ecosystem Fitโ€‹

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    QRUCIAL is a web3 security DAO.

    This is the first time we apply for a grant.

    Six aka David Pethes is a co-founder of QRUCIAL. He is a web3 researcher and security expert and founded the largest crypto hacking competition in the world โ€“ CCTF โ€“ two years ago. He has more than 9 years experience in IT penetration testing and got several global certifications. Since 2021 he is Regional Head Ambassador for Eastern Europe of Polkadot. Since 2013 he is into blockchain and keeps improving his skills through related projects since then.

    ra33it0 aka Sebastian Kraus is a co-founder of QRUCIAL. He is also the founder and strategic mind behind a multitude of companies. His activities range from carbon-neutral real estate with OLYMP to Cryptocurrency Marketing with Elfzntrollz and information security QRUCIAL aiming to make Web3 more secure. Back in 2016, he became interested in blockchain and hacking and has since refined his skills in the field.

    Wigy is an ex-Parity Substrate developer. He is working as a blockchain developer since 2016. His main interests are Rust development, architecture, incentive systems and wallet implementations.

    Silur is working at the Hungarian Academy of Sciences (MTA) as cryptographer, was an early Ethereum developer and still works on cryptocurrency projects.

    knockoff is linux system administrator and junior rust developer.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We have started the development already, details can be found under this repository: https://github.com/Qrucial/QRUCIAL-DAO

    The PoC is working, and we want to move forward in developing a live testnet version.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement substrate runtime and core modulesโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Substrate runtimeThe runtime config and compilable code for QRUCIAL DAO.
    2.Substrate pallet: ExoSysCore system that handles the extrinsics that request ExoTool execution.
    3.Substrate pallet: AuditorRepReputation system for the manual auditors who verify the output recorded by ExoSys.
    4.Substrate report storageIncludes the tools exogenous to the Substrate system, it is connected through the glue/proxy.
    5.Substrate pallet: governanceWe plan to use a similar governance system as Polkadot, but plan to focus more on a meritocratic side. It needs to be decided if we use the democracy pallet as it is or we modify it to use reputation for weights.

    Milestone 2 โ€” Implement Exogenous tooling and hardened node systemโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains QRUCIAL DAO (what was done/achieved as part of the grant). (Content, language and medium should reflect your target audience described above.)
    1.ExoSys DeamonThis is the glue system which listens to events on QRUCIAL DAO and executes the requested tools.
    2.QRUCIAL DAO FrontendFrontend development for accessing the functionalities. Design will look like this
    3.ExoTool - CCAImplement Clippy and Cargo Audit as an exotool package for ink!/WASM smart contract audits.
    4.ExoTool - OctopusImplement Octopus as an exotool for bytecodes (WASM and Solidity)

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Personal recommendation from Achim Schneider and Jonan.

    Here, you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    - + \ No newline at end of file diff --git a/applications/QSTN.html b/applications/QSTN.html index 3415cd3130b..869c1ef24a6 100644 --- a/applications/QSTN.html +++ b/applications/QSTN.html @@ -4,7 +4,7 @@ QSTN | Web3 Foundation Grants - + @@ -39,7 +39,7 @@ https://youtube.com/c/realorrin (41,000 followers)

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 Example โ€” Implement Substrate Modulesโ€‹

    NumberDeliverableSpecification
    0a.LicenseOpen Source
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can generate a Polkadot.JS wallet during on boarding, connect this wallet to our web application, mint and/or transfer NFTs from our marketplace to their specified DOT wallet and save their "survey ID" on a local substrate chain as immutable proof of completion
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a Medium article that documents our transition to Polkadot and details how users of QSTN can connect their DOT wallet to our application, mint & transfer purchased media onto the DOT blockchain as well as save their survey ID on-chain on a local substrate chain.
    1.Survey palletWe will create a Substrate module that will allow users to complete a survey, earn a zero knowledge proof upon completion and then connect their Polkadot JS wallet in order to withdraw the pre-defined reward amount by interacting with the pallet.
    2.Survey palletWe will create a Substrate module that will allow business to create a survey and then connect their Polkadot JS wallet in order to fund the pallet for respondents.
    3.Survey pallet UIWe will create a new UI for DOT users to be able to connect their Polkadot JS wallet, interact with the pallet to withdraw or fund survey rewards and mint their respective NFT media onto a local substrate chain.
    4.Substrate chainThe survey pallet of our custom chain will interact in such a way to allow users to connect their DOT wallet to our application, withdraw DOT and then mint media on a local substrate chain [1.] and these transactions take place within our new UI [3.] with proof recorded by our ZKP [5] after being funded by the business [2] and recorded in the data wallet [6]
    5.ZKP Proof GenerationWe will create an API for the Cubby data wallet to generate zero knowledge proofs upon survey completion on the Substrate chain - this ZKP will be the "receipt" to verify users are eligible to connect their wallet and withdraw rewards from a particular survey contract.
    6.Data WalletWe will open source our data wallet which is an authorizathion layer within QSTN allowing users to interact and generate zero knowledge proofs upon survey completion on DOT - this wallet interacts with the pallets deployed by our local substrate node through our API.

    ...

    Future Plansโ€‹

    1. Developing the Cubby Data Wallet, which will replace user profiles, enabling users to authorize data requests directly from a Chrome extension wallet. This feature enhances user control over their data and streamlines the authorization process.
    2. Creating the Cubby File Storing Platform, a decentralized storage solution powered by Filecoin. Users and businesses can securely store their files, with the owner holding the only decryption key, ensuring privacy and exclusive access.
    3. Collaborating with NYU, L'Orรฉal, and Estรฉe Lauder to test and refine our platform by incentivizing their respective communities, helping us gather valuable insights and optimize our offerings.
    4. Expanding our clientele beyond web3 startups to include larger legacy brands and marketing agencies. Our goal is to establish QSTN as the "go-to" self-service marketing tool for a diverse range of businesses seeking innovative and effective solutions.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    - + \ No newline at end of file diff --git a/applications/RainbowDAO Protocol ink Phase 1.html b/applications/RainbowDAO Protocol ink Phase 1.html index 16cce505807..e2a1c32012e 100644 --- a/applications/RainbowDAO Protocol ink Phase 1.html +++ b/applications/RainbowDAO Protocol ink Phase 1.html @@ -4,14 +4,14 @@ RainbowDAO Protocol ink! Phase 1 | Web3 Foundation Grants - +
    Skip to main content

    RainbowDAO Protocol ink! Phase 1

    • Team Name: Rainbowcity Foundation
    • Payment Address: 0xC2dA4D5813978BbC43d81e905dE6C98767526EdF (DAI)
    • [Level] 2

    Project Overview ๐Ÿ“„โ€‹

    RainbowDAO Protocol ink! is a series of smart contracts based on DAO infrastructure authorized and developed by the Rainbowcity Foundation. On the foundation of substrate development ecology, it focuses on the creation of web3 basic kits. These smart contracts are all created by the Ink! Framework. Anyone can create and manage their own DAO through RainbowDAO protocol. RainbowDAO protocol can build not only independent DAOs, but also parent DAOs, child DAOs and alliance DAOs. What's more, it can create management departments within DAOs to achieve multi-level management.

    Rainbow DAO Protocol ink! has built a complete web3 basic kit technology stack revolving around the DAO ecosystem, involving 12 items and 60 independent web3 kit systems. These 12 items are DAO Organizational Management System, DAO Token Management System, DAO Personnel Management System, DAO Treasury Management System, DAO Voting and Proposal Management System, DAO Contribution Management System, DAO Financial Management System, DAO Fundraising Management System , DAO marketing management system, DAO NFT ecological management system, DAO internal DeFi management system and DAO ecological tool management system. The 12 ecosystems contain 60 independent management modules, each of them can be combined and interact with each other for different function.

    Each module is developed based on the Ink! Framework, and we hope to realize the vision of a complete DAO organization Lego. It will take about 2 years to develop all the modules in DAO technology stack. We will divide the entire development plan into different phases. This grant application is the first phase of our development. We hope to realize the development of the basic module of the Rainbow DAO protocol and the creation of the DAO framework.

    Overviewโ€‹

    DAO is more than a set of smart contracts. In essence, it is a social organization, a physical network composed of individuals with a common purpose. The code of the same smart contract, used by different groups, may demonstrate huge differences in work. Members of DAO can either abide by the established rules or change them through collective decision-making. That sparks differences among DAOs. Obviously, members in DAO is the dominator in DAO classification.

    We did some research and collected the information about DAO in the encrypted world and initially divide DAO into eight major types:Protocol DAOใ€Investment DAOใ€Media DAOใ€Develop DAOใ€NFT DAOใ€Company DAOใ€Government DAO and Tool DAO.

    image

    As the crypto world continues to prosper and innovate, various forms of DAO organizations that are guided by distributed ideas have emerged. These DAO organizations are exploring first-line governance methods in their own ways, and continue to carry out various forms of organizational innovation and system innovation. In order to better serve these different types of DAO organizations, DAO tools that focus on developing DAO infrastructure have emerged. It is hoped that through this DAO tools, the operation and governance of the DAO organizations can be better realized.

    This DAO tool products have an extensive application, including but not limited to the construction of DAO framework, management of voting, proposal, bounty and multi-signature wallet management. Nowadays most of them zoom in Ethereum, such as aragon and DAOstack for DAO framework, gnosis-safe for Ethereum multi-signature wallet management, Snapshot for off-chain voting, etc.

    Except for Ethereum, we are glad that tool DAO platforms showed up in DAOs of Polkadot, such as subDAO and dorafactory. They are working for a better ecosystem of Polkadot.

    In the past year, with the explosive growth of various DeFi protocols and NFT protocols, various governance DAOs have achieved considerable development, accompanied by explosive growth in the demand for DAO tools. But after half a year of research, we found that although there are already many tool-based DAO projects in the encryption world, most tool-based DAO projects are still in the initial stage of industry development and there are many problems. At the same time, the entire industry of DAO also has various difficulties.

    After half a year of research, we have especially summarized some of the problems existing in DAO tool products and the current dilemmas in the DAO industry. In response to these problems and dilemmas, we have specially proposed our solution, which is the current RainbowDAO protocol.

    • Problems in DAO tool productsโ€‹

      In the last half a year, however, our team tried nearly all DAO tool products on the market. We discovered, DAO tool products are faced with the following problems:

      image

      • 1. Single product functionโ€‹

        The function of most of the DAO tool products is too simple,incapable of managing sophisticated coordination. Take the product for DAO framework, for example, what it provide is merely the building of DAO, DAO voting and fund management. Besides, we see no function for department management in any DAO framework, let alone Parent DAO , Child DAO and Alliance DAO. The current DAO tools products are far from satisfying the needs of sophisticated coordination.

      • 2. Low expansibilityโ€‹

        Most of the current DAO tool products have poor expansibility and cannot achieve functional upgrading. DAO will develop while the tool it initially used won't, which forces the DAO give up previous experience and select a new tool. That's a common problem in DAO industry.

      • 3.Low compatibilityโ€‹

        Most of the DAO tool products are not compatible, rendering collaborative governance impossible. The reasons are, on the one hand, different DAO tools are developed by different teams with divergent concepts, it is difficult for multiple products to cooperate with each other; on the other hand, the development standards of various DAO tools are different. Without a unified api or development document, DAOs can only use one or more products in isolation according to their actual needs.

      • 4.Low diversityโ€‹

        DAO tool products, most of them, can only meet the common requirements of DAOs, but cannot satisfy the diversified and differentiated needs yet diversification and differentiation are the characteristics of these different types of DAOs.

      • 5.Low operabilityโ€‹

        We found that most of the current DAO tool products generally have the characteristics of low operability, and users generally have poor experience in using them. Especially for some novice users, it is even more difficult to use these DAO tools.Low operability gave rise to poor experience for users. The design logic and details of these products is the key. That means development teams need take into consideration user experience.

      • 6.Poor innovationโ€‹

        We found that most of the current DAO tool products generally have the characteristics of poor innovation. The functional models of these products are all the same. They did not essentially solve some of the common pain points in the DAO industry. Most of them are similar. They haven't essentially conquered the difficulties in DAO industry. In the end, the products developed were not usable and reduced to a tool for capital speculation.

    • The difficulties in DAO industry.โ€‹

      After half a year of research, we found that although DAO represents the future, the current DAO field is still at a very early stage, and there are still a lot of problems and difficulties. We have now summarized some of the difficulties that currently exist in the DAO industry, mainly as follows:

      image

      • 1. How to establish a reasonable organizational structure while insisting on decentralizationโ€‹

        Any healthy and promising organization requires a clear structure and reasonable division of labour, which is often sophisticated and multi-layered. The current DAO tools can only carry out some primary collaborations, and cannot handle more complex or deep-level collaborations.We always believe that a true DAO organization needs to adhere to the thought of decentralization, but also needs a clear organizational structure.

      • 2. How to encourage participation of community membersโ€‹

        A large number of token holders do not care about the community's proposals and voting results. What they are interested is the price of the token. Therefore, the participation rate of many proposals is very low, and the performance of overall community governance is poor.

      • 3.How to guarantee a fair votingโ€‹

        A decentralized community is composed of multiple stakeholders, including whales, ordinary holders, investors and speculators. Their interest is different. In voting, in some cases, one token is one vote. And for other cases, one person is one vote. Both of the two models cannot safely protect voting fairness.RainbowDAO protocol offers different options in voting rights to refine the governance of the entire DAO system.

      • 4.How to quantify the contribution of community membersโ€‹

        At present, there are few good DAO tools to quantify the contribution of the members of the DAO. We believe this kind of tool is essential to DAO governance. We can establish generalized or differentiated bounty systems or reputation systems, credit systems, medal systems, honor systems, etc., to motivate community members to make more contribution.

      • 5.How to improve efficiency and strengthen power of execution while insisting on decentralizationโ€‹

        DAO community is decentralized and simultaneously loose in governance. Everyone is the own of the community but everyone can refuse to work. Thatโ€™s way many people donโ€™t believe in community. We need effective management, pragmatic collaboration system and tools and proper division of labor. We need a set of web3 tools to build a division of labor system, a work reporting system to improve the work mechanism referring to the existing experience in the company system. We always believe that the essential difference between DAO and company lies mainly in the decentralization of decision-making, rather than the decentralization of jobs or functions.

      • 6.How to successively conduct collective decision-makingโ€‹

        We always believe that the decentralization of decision-making is achieved by collective voting. But many of the members cannot decide whether they should support the proposal. One of the most important reasons is that they have no access to valid data. This requires various types of voting aids tools.

      • 7.How to establish a reasonable financial systemโ€‹

        DAO requires the participation of all members, which cannot be achieved without fund support. DAO needs a system for community fund allocation to deal with problems like the number of departments and its working groups, the budgets of these departments, their tasks, the application for expenses and so on. Financial management policy is a crucial part in RainbowDAO protocol.

      • 8.How to generate income for DAO and get income for its membersโ€‹

        DAO needs income to maintain high vitality and at the same time mobilize all its members to create income.In this regard, RainbowDAO protocol made some innovation. Members in some DAOs need to pay for membership. Then the service fee become the income of the DAO. Members can get a share of the fee if he managed to attract more people to join the DAO.

      To truly conquer these difficulties, we believe the most important thing is to provide these DAOs with universal and diversified DAO tools to make DAO governance systematic. That is also the mission for us to create RainbowDAO protocol today.

    • RainbowDAO Protocol ink! solution.โ€‹

      In the past two years, members of the Rainbowcity Foundation team have been conducting in-depth research on the DAO field. We hope to carry out in-depth innovation on the basis of existing products in the industry and develop tool products that truly meet the needs of the DAO market. At the same time, because the Ethereum community has the most mature DAO community, we have always focused on the Ethereum ecosystem for development, using Solidity as the development language for smart contracts.

      However, after research in the last six months, we found that the cost of using the Ethereum chain is constantly increasing, and the scalability of the underlying design of the Ethereum chain itself is not suitable for the large-scale development of DAO tools, so we will Focus on Polkadot ecology.

      After careful evaluation, we decided to fully embrace the Polkadot ecology initiated by Mr. Gavin Wood, adopt the substrate blockchain framework, and use the ink! framework to develop a series of products based on the DAO infrastructure facilities. We specially launched the RainbowDAO Protocol ink!, dedicated to solving the pain points and difficult problems in the industry, and boosting the DAO ecology towards real prosperity.

      And at the same time, apply for grant funding from the web3 foundation in phases to obtain development funds and achieve strategic cooperation and collaboration with the web3 foundation.

      In RainbowDAO protocol , we put forward the concept of DCV, which is the focus of the development of all DAO tools.

      image

      DCV, DAO Controlled Value, means that the value is not controlled by any single individual or centralized entity, but by DAOs at different levels. Through the DAO governance contract, DAO can control every core parameter and decision switch in the protocol, and ultimately the holder of the governance token can decide the direction of the entire DAO through voting.

      At the same time, in RainbowDAO protocol, there are different types of DAOs, including parent DAOs, child DAOs, alliance DAOs and departmental DAOs, so that more different types of participants can join in the construction of the DAO community to give full play to the power of communities.

    Project Detailsโ€‹

    In view of the current problems and difficulties in the Dao industry, in order to better meet the needs of the Dao industry and develop Web3 suite tools in line with the actual operation of Dao, Rainbowcity Foundation specially developed a series of protocols: RainbowDao Protocol ink!.

    The following are the details of the : RainbowDao protocol:

    image

    • Three major innovations of RainbowDAO protocolโ€‹

      • 1. Governance Dao functionโ€‹

        In RainbowDAO protocol, we innovatively developed the function of Governance DAO, which gave wings to the expansion of the entire protocol. The governance DAO function is mainly reflected in two points:

        The first point is that the entire RainbowDAO protocol is controlled by a governance DAO. We will issue governance token RBD. The holder group of RBD is the governance group of the RainbowDAO protocol. The group of RBD holders decides the modification of the parameters of the entire RainbowDAO protocol through referendum voting, and continuously upgrades the protocol itself.

        The second point is that each independent DAO created through the RainbowDAO protocol will generate a governance DAO and bind the corresponding governance token. The governance DAO manages the independent DAO and is responsible for the modification of the DAO parameters. Through this governance DAO finally realize the upgrade and expansion of this independent DAO.

        The combination of these two points makes the entire protocol no longer a fixed protocol, but an protocolt that is constantly upgraded through governance. In this way, the entire protocol can truly have vitality and growth.

      • 2. RainbowCore functionโ€‹

        We innovatively developed the RainbowCore function and used it as the authority control center of the RainbowDAO protocol. The RainbowCore module is divided into four parts, Role management, Authority management , Route management, and Rainbowcore.

        The Role management contract is responsible for managing different roles in the protocol, the Authority management contract is responsible for managing the permissions corresponding to these roles, and the Route management contract is responsible for the address management of all contracts in the entire protocol. The Rainbowcore contract is the entry management of these three contracts, overall planning and coordination.

        The four major functions of the RainbowCore module build the RainbowDAO protocol into a whole that can be flexibly matched with different roles and different permissions, and finally can achieve unlimited expansion and upgrade of the protocol.

      • 3. DCV controller functionโ€‹

        We have also innovatively developed the function of the DCV controller, which enables the entire RainbowDAO protocol to have unlimited scalability. DCV is the core function of RainbowDAO protocol. Each DAO is based on the management of DCV, and each DCV is an independent treasury system.

        We have innovatively developed the DCV controller function. Each controller is a series of existing rules written by smart contracts to complete the specified contract operations. In this way, the management of DAO has unlimited scalability. Through the DCV controller function, each DAO itself can flexibly control the assets in the DCV.

    image

    • Eight features of RainbowDAO protocolโ€‹

      • 1. Modularityโ€‹

        Each function of RainbowDAO protocol can exist as an independent module, which can easily trigger upgrading and evolution of the protocol.

      • 2. Plug-inโ€‹

        Each module of the RainbowDAO protocol is very flexible like a plug-in.

      • 3.Composabilityโ€‹

        Each module of the RainbowDAO protocol can be combined with each other. Some simple modules can work together to form a powerful module.

      • 4.Scalabilityโ€‹

        Based on the modular combination, the RainbowDAO protocol has very strong scalability and new functions can be added through the addition of modules.

      • 5.Detachabilityโ€‹

        The modules of the RainbowDAO protocol can be disassembled to achieve the simplification of DAO functional modules and adapt to actual needs.

      • 6.Interoperabilityโ€‹

        Each module of the Rainbow DAO protocol is can interact with each other.

      • 7.Flexibilityโ€‹

        The RainbowDAO protocol can be combined, extended, and disassembled. This gives the RainbowDAO protocol strong scalability. The protocol can be adjusted according to the actual situation of each DAO.

      • 8.Growthโ€‹

        Based on the first 7 characteristics, the RainbowDAO protocol will evolve into a living system that can upgrade infinitely with a decentralized idea.

    image

    • Eight concepts of RainbowDAO protocolโ€‹

      After half a year of research, we found that although DAO represents the future, the

      • 1. Decentralizationโ€‹

        It is the soul of the RainbowDAO protocol. The protocol itself and DAOs of all levels are decentralized .

      • 2. Trust-freeโ€‹

        RainbowDAO protocol adheres to the idea of "code is law". All rules are constructed by code with no need for intermediary.

      • 3.Censorship-Resistantโ€‹

        All rules of the RainbowDAO protocol are set by code to achieve complete on-chain governance, and the value of all assets is controlled by the chain.

      • 4.Transparencyโ€‹

        The RainbowDAO protocol realizes complete on-chain governance. All data is clearly displayed on the chain.All data is transparent.

      • 5.No need for permissionโ€‹

        The RainbowDAO protocol is composed of countless rules that have been set up in advance. They are constructed by smart contracts on the chain. Anyone can use the RainbowDAO protocol to build a DAO without permission.

      • 6.Opennessโ€‹

        RainbowDAO protocol is a set of open protocols and these protocols can interact with internal modules and external protocols.

      • 7.Popularityโ€‹

        RainbowDAO protocol can be applied to various types of DAOs, large or small in size.

      • 8.Inclusivenessโ€‹

        The RainbowDAO protocol can be employed by different types of people. We always hope to build the RainbowDAO protocol into a viable, growing, and warm protocol.

    image

    • Twelve items of RainbowDAO protocolโ€‹

      In order to better serve the entire DAO ecological infrastructure, we built a complete web3 basic suite technology stack around the entire DAO ecosystem, involving a total of 12 major items and 60 independent web3 suite systems.

      The 12 major items include 60 independent management systems, each of which is an independent module, and all modules form a complete DAO infrastructure service technology stack. Each module can be used independently, and different modules can combine with each other, which truly realizes the vision of DAO Organization Lego.

      This is our grand plan for the entire DAO infrastructure. The entire plan is too large, we will develop it in stages, and the overall development is expected to be completed in 2 years. This first grant applied for us to focus on the first item of the whole development.

      • 1. DAO Organizational Management Systemโ€‹

        Basic system of RainbowDAO protocol for the establishment and management of DAOs. It is the basis of all the other items of RainbowDAO.We can not only build the simplest DAO, but also a very large and complex DAO. Including but not limited to independent DAO, parent DAO and child DAO, as well as alliance DAO.

      • 2. DAO Token Management Systemโ€‹

        This part is mainly related to the various modules of token management. At present, various DAO infrastructures rarely have slightly complicated token management systems, which makes it impossible to realize the management and coordination of some complex tasks. In response to such pain points, in the RainbowDAO protocol, we design a variety of different forms of token management functions. Including but not limited to ERC20 Token Factory, Token Airdrop Management System, Token Locked Management System ,Token Exchange Management System, Multi-signature Wallet Management System.

      • 3.DAO User Management Systemโ€‹

        Itโ€™s about the the member management of the entire RainbowDAO protocol. This management pattern can be employed in all independent DAOs, they can choose one or more parts of the system and they can combine these parts for their own use. Currently, thereโ€™re merely some simple functions there. We will develop more sophisticated ones based on the reality of RainbowDAO protocol.

      • 4.DCV Management Systemโ€‹

        DCV, DAO Controlled Value, is one of the core management system of RainbowDAO protocol. In the early stage, we design only relatively simple management functions of DCV. With the improvement of the protocol, we will design diversified DCV controllers for better management.

      • 5.DAO Voting and Proposal Management Systemโ€‹

        Proposals can be divided into different types, and the corresponding processes will be different. For example, some proposals have two options, support or oppose, some proposals need to elect different candidates, and the voting result is determined by the number of votes. This requires us to consider the difference of proposal types and make different templates.

        Under the rules of different DAOs, some voting rights can be calculated by token, one token is one vote; some are calculated by voter, one person is one vote. These different programs can all be applied to different governance environments.

      • 6.DAO Contribution Management Systemโ€‹

        DAO's contribution management is mainly to guide community members to contribute to the governance of DAO through appropriate methods, and to give full play to the enthusiasm and initiative of community members. Most community members want to contribute to the community, but suffer from methods and approaches that have not contributed, and cannot get incentives through contributions.

      • 7.DAO Finance Management Systemโ€‹

        The system is about some financial tools that may be used in DAO management, in financial procedure and policy-making to make the overall capital flow more transparent and orderly.

      • 8.DAO Fundraising Management Systemโ€‹

        Use different tools to raise funds for DAO from different channels.Only DAO has sufficient funds to support its long-term stable development. Therefore, diversified fundraising tools are a necessity for DAO operations.

      • 9.DAO Marketing Management Systemโ€‹

        With DAO as the center, various marketing platforms or competition platforms are opened to encourage users to carry out promotion and ultimately lift the popularity of DAO.

      • 10.DAO NFT Management Systemโ€‹

        To create a set of tools for the production and circulation of various NFTs. We will take DAO as the center to build a prosperous NFT ecology on the basis of Polkadot.

      • 11.DAO DeFi Management Systemโ€‹

        We will develop various DCV controllers to control the funds in DCV, and participate in diversified DeFi activities, which can maximize the efficiency of the use of funds in DCV and increase the rate of return of funds.

      • 12.DAO Ecological Tools Management Systemโ€‹

        It's about various ecological tools in DAO. Instead of focusing on a specific field, it involves all aspects of the overall operation of DAO. The tools can be technical or service-oriented.

    image

    • Function product display of RainbowDAO protocolโ€‹

      In this chapter, we will show the product functions of the RainbowDAO protocol, especially the structure and logical relationship. We hope to let people understand the framework of RainbowDAO function through this frame diagram.

      The RainbowDAO protocol is part of the DAO Basic Framework protocol. Anyone can create an independent DAO through the RainbowDAO protocol. A three-part extension can be carried out through an independent DAO, and finally it can be upgraded infinitely.

      • 1. Scale up: Alliance DAOโ€‹

        An independent DAO can join a Alliance DAO. In this product structure diagram, we first virtualized several alliances. For example, we have established a project on the Polkadot main chain. Based on this project, we have established a DAO. This is an independent DAO. Our independent DAO can join the Polkadot Ecological Alliance DAO , which is an Alliance DAO. Similarly, projects on the kusama main chain can also join the Alliance DAO on the kusama main chain, and each parachain can set up an independent Alliance DAO to attract projects on the parachain to join the parachain Alliance DAO.

        Similarly, whether it is the Polkadot chain, the kusama chain, and each parachain, they are all built using the substrate framework. We can establish a substrate ecological Alliance DAO. The Polkadot Ecological Alliance DAO, the Kusama Ecological Alliance DAO, and the Alliance DAOS of various parachains can all join this substrate Ecological Alliance DAO, Ultimately realize the sharing of resources.

        This example is the Alliance DAO established from the perspective of development technology. According to the differences in DAO attributes and types, we can also establish investment Alliance DAO, media Alliance DAO, social Alliance DAO, and so on. Similarly, we can also establish Alliance DAOs in different regions through regional differences. The European Alliance DAO, the Asian Alliance DAO, the American Alliance DAO, and so on.

        In Alliance DAO management, an independent DAO can freely choose to join an Alliance DAO or leave an Alliance DAO without the permission of the Alliance DAO. There are no rigid management and ownership requirements between each other.

      • 2. Scale Out: Parent DAO and Child DAOโ€‹
    Each independent DAO can establish its own Child DAO. In fact, this is equivalent to the relationship between the parent company and the subsidiary. Each Child DAO belongs to an independent DAO in terms of attribution, and is exactly the same as an independent DAO in terms of functional modules. The Parent DAO has the right to manage the Child DAO.Unless the  Parent DAO agrees to the independence of the Child DAO through a referendum, the Child DAO cannot exist independently.

    Child DAO is created by the Parent DAO, the Parent DAO has the authority to control the Child DAO, the Child DAO of the Child DAO can also be managed by the Parent DAO, and so on. Child DAO has management authority to directly belong to Child DAO, and cannot be cross-level management. Example: Parent DAO A creates Child DAO B, Child DAO B creates Child DAO C, and Child DAO C creates Child DAO D. The Parent DAO A has the management authority of B, C, D, and Child DAO B has the management authority of Child DAO C. But Child DAO B does not have administrative rights to Child DAO D. The Parent DAO can perform cross-level management of Child DAOs, but cross-level management between Child DAOs is not possible.
    • 3.Scale In: DAO department managementโ€‹

      Each independent DAO can establish a department belonging to this independent DAO, which means that this independent DAO can establish its own clear organizational structure. This is also the core function of the RainbowDAO protocol that we have always emphasized. We have always believed that any DAO cannot have only one department, but should have multiple departments working together.

      In the RainbowDAO protocol, each department established by an independent DAO is also equivalent to an independent small DAO, with various basic functions of the DAO. But it is not an independent DAO in nature, but a sub-department within an independent DAO. In our overall product planning, the management authority of these sub-departments is more in the form of multisig smart contracts, and a multisig committee is responsible for managing this department, rather than through voting for all DAO members. This is the decentralization mechanism of DAO management, which decentralizes the overall power to the department for processing.

      In the same way, a department can continue to set up departments to further decentralize and distribute power. Establish collaborative work with complex tasks through the department's layers. This is the most basic function we think a large DAO must have.

      In the same way, a department can continue to set up departments to further decentralize and distribute power. Establish collaborative work with complex tasks through the department's layers. This is the most basic function we think a large DAO must have.

      We also give examples in the framework diagram to facilitate everyone to understand our product logic. First of all, we established an independent DAO. In the department management of this independent DAO, we established five independent departments. They are the Human Resources Management Committee DAO, the Financial Management Committee DAO, the Technology Management Committee DAO, the Operation Management Committee DAO, and the Investment Management Committee DAO. These five departments are responsible for the specific operations of this independent DAO.

      At the same time, these five independent departments are divided into different groups under each department, and continue to refine the division of labor. For example, the Human Resources Committee DAO is divided into two groups: the organizational structure management group and the salary management group; the Financial Management Committee DAO is divided into the budget management group and the fund use management group; the Technology Management Committee DAO is divided into the technology development management group and Grant supports these two groups; the operation management committee is divided into the brand management group and the event promotion management group under the DAO; the investment management committee is divided into the project review management group and the foreign investment management group and so on.

      Most of these management groups also exist in the form of a multisig management committee. This is also a function of DAO's decentralization to the following independent departments. Complex coordination must be achieved through refined division of labor, which is the same nature as the operation of a company. Only with clear division of labor and clear responsibilities can it be possible to improve efficiency and execution.

    image

    • Design mechanism of RainbowDao protocolโ€‹

      Through the above series of information, we have learned about the grand plan of RainbowDAO protocol, which is a huge project that allows DAO to expand infinitely and upgrade infinitely. So how is the RainbowDAO protocol constructed as a whole? What is the structure of the protocol itself? In this part, we focus on sharing with you the architecture design of the RainbowDAO protocol itself, so that everyone can clearly know the implementation method of the RainbowDAO protocol.

      We can understand the design architecture of the RainbowDAO protocol from three parts.

      • 1.Tier 1 Architecture: RBD Governance Daoโ€‹

        The first layer of the RainbowDAO protocol consists of RBD governance DAO. RBD belongs to the governance token of the RainbowDAO protocol. The holders of RBD constitute the DAO and are responsible for the governance and management of the entire RainbowDAO protocol. RBD governance DAO coordinates all the parameters and conditions of the RainbowDAO protocol. The holders of RBD voted to determine the modification and optimization of each parameter of the RainbowDAO protocol, and realize the expansion and upgrade of the RainbowDAO protocol. The RBD governance DAO belongs to the overall control center of the RainbowDAO protocol, and all management powers belong to the owners of all RBD governance tokens.

      • 2.Tier 2 Architecture: Basic Protocol Layerโ€‹

        The second layer of the RainbowDAO protocol is the basic part of the protocol, not the part of the DAO created by the protocol. Basic Protocol Layer mainly contains six parts, one is the rainbow core contract, the second is the membership management contract, the third is the revenue management contract, the fourth is the web3 suite tool contract, the fifth is the DCV controller contract, and the sixth is the DAO factory contract. The DAO factory contract also belongs to the third layer of the RainbowDAO protocol, which is mainly used to control and manage the DAO created by the protocol.

        Rainbow core contract consists of four parts, role management contract ,authority management contract, routing management contract and rainbowcore management contract . This is the permission control center of the RainbowDAO protocol, which manages the permissions and roles of the entire protocol, and is responsible for the upgrade of the RainbowDAO protocol.

        The membership management contract is responsible for managing the members of the protocol as a whole. One is to manage the identity information of the members, and the other is to manage the recommendation relationship of the members. The recommendation system and membership management modules are developed from this.

        The revenue management contract belongs to the revenue management control center of the RainbowDAO protocol. RainbowDAO protocol itself will set a series of income categories, such as calling the contract requires payment of DOT as a contract usage fee, DCV will charge a certain percentage of the treasury usage fee and so on. In this way, the RainbowDAO protocol can generate revenue in a variety of ways. The more people who use the protocol, the more income they can get. The final income will also be proportionally returned to the holders of RBD governance.

        Tool contracts related to Web3 belong to the management center of tool contracts. For example, ERC20 token manufacturing factory contract, multisig wallet management contract, token airdrop contract, token lock-up contract and so on. In the future, all tool contracts can be placed under this large module.

        The DCV controller contract belongs to the controller management center of the Rainbow DAO protocol. Various controllers can be made here, especially when it comes to DeFi management.

      • 3.Tier 3 Architecture:DAO Factoryโ€‹

        The above contract parts belong to the overall level of the RainbowDAO protocol. The third layer belongs to the DAO Factory contract, which is mainly used for the batch creation and management of DAO.

        The DAO Factory contract can be divided into three parts .

        The first part belongs to the DAO type contract. The DAO type is divided into three types: independent DAO, Alliance DAO, and Child DAO, which directly determines the most basic nature of the established DAO.

        The second part belongs to the DAO initialization contract, which is used for DAO creation and initialization information.

        The third part belongs to the DAO management contract, which belongs to the basic management of the contract after the establishment of the DAO.

        The DAO management contract is mainly divided into 7 modules.

        The first module is the DAO basic setting contract, which is mainly responsible for the setting of DAO basic information;

        The second module is the DAO authority management contract, which is mainly responsible for the authority, role management in this DAO and the termination and liquidation of DAO;

        The third module is mainly the DAO member management contract, which is responsible for the member management of this DAO, including the entry threshold and the deletion of members, etc.;

        The fourth module is the DAO treasury management contract, which is mainly responsible for DAO's treasury management ;

        The fifth module is the DAO voting management contract, which is mainly responsible for a series of voting rights related settings;

        The sixth module is the DAO proposal management contract, which is mainly responsible for DAO proposal management;

        The seventh module is the DAO department management contract, which is mainly responsible for department management of DAO.

      These three parts constitute the basic framework of the RainbowDAO protocol. In the future, the RainbowDAO protocol will be continuously upgraded and expanded on the basis of these basic frameworks, and will become the infrastructure of the DAO industry.

    Ecosystem Fitโ€‹

    Help us locate your project in the Polkadot/Substrate/Kusama landscape and what problems it tries to solve by answering each of these questions:

    image

    • Where and how does your project fit into the ecosystem?

      First of all, the Rainbowcity Foundation chose the Polkadot ecology of Dr. Gavin Wood. From a long-term perspective, we have a total of three levels of planning to integrate into the Polkadot ecosystem through three steps.

    • In the first step, we will develop a series of smart contracts that belong to the DAO infrastructure based on the ink! framework. This is RainbowDAO Protocol ink!. All protocols exist in the form of smart contracts, so that they can be widely deployed on any Parachains and independent public chains developed based on Polkadot, Substrate and Kusama networks.

    • In the second step, we will develop based on the parachains of Polkadot and Kusama, transform some of the smart contracts involving the underlying architecture into the form of a pallet, and we will create a parachain that belongs to the DAO infrastructure. Part of the DAO infrastructure exists in the form of pallets, and part of the DAO infrastructure exists in the form of ink! smart contracts. Pallet involves the creation of DAO facilities at the lower level of the parachain, while smart contracts tend to create DAO tool types with greater flexibility. In this way, we will build a parachain based on the DAO infrastructure and rely on this parachain to build an ecosystem. The project parties deployed on this parachain all use RainbowDAO Protocol ink! for project governance, building a fully community-driven, decentralized governance parachain.

    • The third step is that in the next 3 to 5 years, with the stable development of Rainbow DAO's smart contracts and parachains, we will start to build an independent public chain of Rainbowcity based on the substrate framework with an independent consensus mechanism. The ecosystem will be further built on the basis of the independent public chain of Rainbowcity. The focus of the ecosystem is on the token economy and community governance, with DAO governance as its soul. We will migrate a series of physical industries to the Rainbowcity independent public chain, which is a further extension and expansion of the substrate ecosystem.

    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

      • First, for ourselves, we will initiate our independent project RainbowDAO based on RainbowDAO Protocol ink! in good time, committed to the creation of DAO infrastructure, and truly serve the Polkadot DAO ecosystem.

      • Second, any project party who wants to create a project based on Substrate / Polkadot / Kusama. Because our protocol exists in the form of a smart contract, allowing anyone to use it. Therefore, any project party can refer to, modify or directly deploy our code to provide DAO infrastructure for the entire Polkadot ecosystem. We treat all participants with a completely open attitude.

      • Third, any parachain builder can directly adopt our code and deploy it on their parachain to provide DAO infrastructure for the project parties on their parachain.

      • Fourth, when RainbowDAO Protocol ink! is deployed on a large scale in the Polkadot ecosystem in different ways, any type of DAO can use our protocol to create their DAO, and help them operate and manage their own DAO to the greatest extent.

    • What need(s) does your project meet?

    Provide DAO infrastructure and web3 tool suite for various types of DAO.

    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

    We found that there are already DAO infrastructure-based projects in the Polkadot ecosystem, such as subDAO and dorafactory. At the same time, there are also a large number of related projects in the Ethereum ecosystem, such as aragon and DAOstack focusing on the DAO framework, gnosis-safe focusing on the management of multi-signature wallets, and snapshot platform Snapshot focusing on off-chain voting. Compared with these existing projects, RainbowDAO Protocol ink! can handle more complex DAO governance and collaboration. Our protocol itself is more extensible, more flexible, more vital, creative and innovative. For specific details, please refer to the three innovations, eight features, and eight concepts of the RainbowDAO protocol described in the text above. These are our core competitiveness, and are also the basis for the continuous development and evolution of our products.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    We have an experienced and powerful development team of 11 members. Here, we briefly introduce the members of our development team.

    • RainbowKun: Team leader, Chief Architect, Product Manager๏ผŒthe overall builder of the Rainbowcity concept. The founder of the Rainbowcity Foundation, a strong believer and supporter of Satoshi Nakamoto and Bitcoin. He is fully committed to the construction of web3 ecology and Bit Civilization.
    • Ivan Vian: Technical team leader, Full-stack developer, Rust and solidity full-time developer,10 years of technical experience, 5 years of blockchain development experience.
    • Harris Wong: R&D team leader, Full-stack developer, Rust and solidity full-time developer,8 years of technical experience, 4 years of blockchain development experience.
    • Alexunder: Full-stack developer, Rust and solidity full-time developer, 6 years of technical experience, 3 years of blockchain development experience.
    • Dickenson: Full-stack developer, Rust and solidity full-time developer, 5 years of technical experience, 3 years of blockchain development experience.
    • Sylvanus: Full-stack developer, Rust and solidity full-time developer, Senior front-end development engineer,5 years of technical experience, 2 years of blockchain development experience.
    • Lawrence: Full-stack developer, Rust and solidity full-time developer ,4 years of technical experience, 2 years of blockchain development experience.
    • Michael: Full-stack developer, Rust and solidity full-time developer, Senior front-end development engineer,4 years of technical experience, 2 years of blockchain development experience.
    • Jasper: Assistant Product Manager, assist the architect in the planning and design of blockchain products, with 2 years of product design experience.
    • Peke: Junior developer, new scholar of blockchain technology,Rust and solidity full-time developer, 2 years of technology development experience, 6 months of blockchain development experience.
    • Echo: Chief UI designer, front-end designer, chief designer of various products of Rainbowcity. 5 years of senior design experience.

    Contactโ€‹

    • Registered Address: 5001 Beach Road #07-37 Golden Mile Complex Singapore 199588.
    • Registered Legal Entity: RAINBOWCITY FOUNDATION LTD.

    Team's experienceโ€‹

    We have a full-time team of more than 20 people, including 11 full-time development teams, mainly Ethereum ecological development. Since 2019, under the leadership of RainbowKun, our team has prepared the Rainbowcity project entirely with our own funds. Rainbowcity is committed to building a digital city-state based on token economy and community governance. The core idea of Rainbowcity is DAO. We hope to build Rainbowcity into a trillion-dollar super-economy through 10 years of development, and create a virtual city-state based on the blockchain, and create a free state that adheres to the spirit of bitcoin, and to create a new civilization for mankind.

    Rainbowcity is a DAO, and the design of the entire project is centered on DAO. In 2020 and 2021, the main work of our team is to design the Rainbowcity project and develop Rainbowcity DAO. In the past, we focused on the Ethereum market and built the entire ecosystem of Rainbowcity on the Ethereum main chain and L2 network in the form of smart contracts. Therefore, our team mainly develops RainbowcityDAO smart contracts based on solidity.

    In the past year, we have developed a complete product of RainbowcityDAO in solidity language. The entire product has more than 100 smart contracts, including more than 60 core contracts, more than 20 coordinator contracts for contract deployment, and more than 30 interface contracts. The development workload is one of the largest projects in the Ethereum ecosystem.

    However, when we fully developed the RainbowcityDAO contract, after a comprehensive evaluation by our team, the Ethereum ecosystem could not support the operation of the entire Rainbowcity project. On the one hand, the cost of using the Ethereum main chain is getting higher and higher, on the other hand, the overall performance and future scalability of the Ethereum main chain cannot support the operation of the Rainbowcity project.

    At this time, we are faced with multiple choices in the future development direction. One is to continue to stick to the Ethereum ecosystem, wait for the maturity of the Ethereum L2 network, and build the Rainbowcity ecosystem on the basis of the L2 network. The second is to build a completely independent public chain by ourself, and build the Rainbowcity ecology in the form of our own public chain. The third is to choose other emerging public chains in the market.

    After various investigations, we chose the Polkadot ecosystem created by Dr. Gavin Wood to conduct a comprehensive investigation on the Substrate, Polkadot and Kusama ecosystems. We pay particular attention to the ideas and concepts of the Parity team and the web3 foundation team led by Dr. GavinWood to see if these concepts are decentralized. As we learn more about Dr. GavinWood, we find that Substrate and Polkadot are our best choices.

    Therefore, in June 2021, we made the biggest decision of our team in the past three years to suspend our development and research in the Ethereum ecosystem and join the Substrate and Polkadot ecosystem created by Dr. Gavin Wood. Our developers have also begun to switch development languages, starting from the original solidity to Rust and ink!. This is the most important decision our team has made in the past three years. Abandoning the familiar technology and learning new development technology is also a major challenge for our development team. However, we are not afraid of this challenge, and actively embrace this challenge. We firmly believe that Substrate and Polkadot belong to the future of blockchain.

    At the same time, inspired by the relationship between Substrate and Polkadot, we have also adjusted the product structure. The original Rainbowcity was an independent project, an independent DAO, and our development was also based on this DAO. All our development needs are the needs of the project itself, and these DAO tools cannot meet the general needs of other DAOs. Inspired by the relationship between Substrate and Polkadot, we decided to abstract the product that was originally only applicable to RainbowcityDAO and make it applicable to various DAOs. This is why we launched RainbowDAO Protocol ink! today. Our team has been conducting research internally for the past six months, and now we have a preliminary and complete system.

    In order to quickly integrate into the Substrate and Polkadot ecosystem, we decided to participate in the grant application of the web3 foundation to start our Polkadot journey. Through the grant application of the web3 foundation, participants in the entire Polkadot ecosystem can have a more systematic understanding of our development philosophy and future vision. We hope to use the grant platform as our first step to integrate into the Polkadot ecosystem, show our strength and our grand vision step by step, and become a part of the Polkadot ecosystem.

    At the same time, in the past two years, due to the need for project confidentiality, our development team has not released any project information. The github accounts of all our members are also newly registered, so there is not much history. In order to let the web3 foundation grant team have a simple understanding of our development capabilities, we uploaded the previously developed RainbowcityDAO project source code to github.

    It is our regret that these codes were abandoned without formal use. We will start the creation on Polkadot from scratch. Of course, we will not completely abandon the development on Ethereum. In the future, we will also develop the solidity version of the RainbowDAO protocol simultaneously.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    • No

    Development Status ๐Ÿ“–โ€‹

    Our leader RainbowKun is a believer in Satoshi Nakamoto and Bitcoin. He has been thinking about the philosophy of Bitcoin for the past four years. Since July 1, 2021, he spent 3 months writing more than 50 original articles on Bitcoin thoughts, and published them on the Bitcointalk forum created by Satoshi Nakamoto, sparking a series of extensive discussions. This is also the underlying idea that we initiated the creation of the Rainbowcity project and the RainbowDAO protocol. Now we choose a few links for everyone to read, so that everyone can better understand the thoughts of Rainbowcity:

    For the past two years, we have been developing RainbowcityDAO products on the Ethereum network. Here are some UIs we designed for your reference.

    image

    image

    image

    image

    image

    image

    image

    Development Roadmap ๐Ÿ”ฉโ€‹

    The entire RainbowDAO Protocol ink! is a huge project, involving 12 large modules and 60 small modules. It is estimated that it will take one to two years to complete the development. We decompose some core modules into 3 to 5 different phases, develop step by step, and apply for grant support from the web3 foundation.

    In the first phase of our overall development, we mainly completed the basic framework part of the RainbowDAO protocol. The first part is the protocol layer of the RainbowDAO protocol itself, and the second part is the RainbowDAO factory contract, which is used for the construction of the DAO Factory. Both parts are basic functions, and the extended function part is not involved for the time being. When our first phase is completed and the RainbowDAO protocol can operate normally, we will develop various extension modules.

    Overviewโ€‹

    • Total Estimated Duration: 8 weeks
    • Full-Time Equivalent (FTE): 8
    • Total Costs: 48000 USD

    Milestone 1โ€‹

    • Estimated duration: 3 weeks
    • FTE: 8
    • Costs: 20,000 USD

    For the first milestone, we focused on developing some basic contracts of RainbowDAO Protocol ink!, that is, the underlying structure of the entire protocol. Including governance DAO contract, ERC20 factory contract, multisig management system contract, user management system contract, income category management contract, role management contract, authority management contract, routing management contract, rainbowcore management contract, etc., a total of 9 systems.The name, function or quantity of the final developed contract may be different from the estimate in this table. At that time, the actual developed code shall prevail.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can deploy our smart contract and experience specific innovative features.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article on medium detailing our philosophy in DAO infrastructure construction and our exploration in Polkadot ecology.
    1.ink! Contract: GovnanceDAOThis contract is the overall governance DAO contract of the RainbowDao protocol. The holder of the RBD controls this contract, adjusts the parameters of the entire protocol through voting, and realizes the upgrade of the protocol.
    2.ink! Contract: erc20FactoryThis contract is an ERC20 factory contract. Even people who do not understand the code can issue their own ERC20 tokens through this factory contract. The smart contract has the function of token issuance and block statistics, which facilitates the calculation of voting weight and the implementation of voting delegation.
    3.ink! Contract: multiSignThis contract is a multi-signature management contract. Anyone or any DAO can build a multisig system for the management of funds.
    4.ink! Contract: userManageThis contract is a user management contract. Manage user registration, user management, and referral relationships for the entire protocol.
    5.ink! Contract: incomeCategoryThis contract is an income category management contract. Mainly used to calculate the income category and income ratio of the protocol.
    6.ink! Contract: roleManageThis contract belongs to the role management contract and is mainly used to manage the role of the protocol.
    7.ink! Contract: authorityManageThis contract belongs to the authority management contract and is mainly used to manage the authority of the protocol.
    8.ink! Contract: routeManageThis contract belongs to the routing management contract and is mainly used to manage and replace the contract address of the protocol.
    9.ink! Contract: rainbowcoreThe Rainbowcore contract is the entry management of these three contracts,roleManage ,authorityManage and routeManage ,overall planning and coordination.
    10.protocol UIWe will deliver the UI of the first milestone with the contract.

    Milestone 2โ€‹

    • Estimated Duration: 5 weeks
    • FTE: 8
    • Costs: 28,000 USD

    For the second milestone, we focused on the development of DAO factory contract related functions, and the front-end page, and the interaction between the front-end and the contract. The name, function or quantity of the final developed contract may be different from the estimate in this table. At that time, the actual developed code shall prevail.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can deploy our smart contract and experience specific innovative features.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article on medium detailing our philosophy in DAO infrastructure construction and our exploration in Polkadot ecology.
    1.ink! Contract: daoFactoryThis contract is the DAO factory contract, which is mainly used for the initialization and creation of DAO.
    2.ink! Contract: templateThis contract is a template contract for basic template management.
    3.ink! Contract: daoManageThis contract is the basic management contract for the created DAO, which coordinates the management of the DAO.
    4.ink! Contract: daoCategoryThis contract is a type contract of DAO, used to manage the type of DAO.
    5.ink! Contract: daoProposalThis contract is used to manage DAO proposals.
    6.ink! Contract: daoVoteThis contract is used to manage DAO voting.
    7.ink! Contract: daoUsersThis contract is used to manage the users of the DAO.
    8.ink! Contract: daoVaultThis contract is used to manage the DAO's treasury.
    9.protocol UIWe will deliver the UI of the second milestone with the contract.

    Future Plansโ€‹

    • Follow the steps to develop a series of DAO infrastructure smart contracts to provide infrastructure services for the entire DAO ecosystem of Polkadot.
    • Start to create the RainbowDAO community and continue to promote the core ideas of the RainbowDAO protocol in various media.
    • Prepare parachain auctions for Kusama and Polkadot, and build a parachain with DAO infrastructure and web3 tools as the core.
    • In the long run, use the substrate framework to build a Rainbowcity public chain with an independent consensus mechanism.

    Additional Information โž•-โ€‹

    How did you hear about the Grants Program?

    Through the official website of the Web3 Foundation.

    • Wheter there are any other teams who have already contributed (financially) to the project.

    This project is independently developed by our team.

    • Previous grants you may have applied for.

    We have not applied for other funds.

    - + \ No newline at end of file diff --git a/applications/RareLink.html b/applications/RareLink.html index 4686ea32d17..e7369ca529f 100644 --- a/applications/RareLink.html +++ b/applications/RareLink.html @@ -4,7 +4,7 @@ RareLink Protocol | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ No

  • Have you applied for other grants so far? No

  • Are there any other projects similar to yours? To the best of our knowledge, there is no project about dynamic NFT that is similar to our project. Please let us know if there are any.

    • - + \ No newline at end of file diff --git a/applications/RedStone Network.html b/applications/RedStone Network.html index 9f95c5b3ecb..7c4b9e9b31a 100644 --- a/applications/RedStone Network.html +++ b/applications/RedStone Network.html @@ -4,7 +4,7 @@ Redstone Network | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Redstone Network

    • Team Name: Redstone Network
    • Payment Address: 0x24cfc36f699dacc5cb652630ddd894a8df658233 (Ethereum ERC20 USDT)
    • Level: 2
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    We are sincerely requesting a funding grant from the web3 Foundation to build a transaction firewall that will function as a last resort security barrier when user asset protection solutions fail. There have been several serious security incidents recently, including major asset losses due to the theft of private keys on the harmony and Ronin bridges. In the blockchain world, having a mnemonic or private key for an account is equivalent to getting ownership of that address; when a hacker obtains a user's mnemonic or private key, he or she is able to take all the assets in a short period of time without any problem, a situation that obviously should not exist all the time. When this problem is not solved or alleviated, the Web3 world is full of uneasiness and suspicion, and this situation will make it difficult for the Web3 world to gain larger scale support and popularity.

    The Redstone Network is a network of trigger circuits where users combine and arrange simple atomic trigger components according to certain rules and processes to eventually implement a series of automated operational circuits. We propose transaction firewall middleware that can function between any blockchain network, regardless of the cross-chain mechanism and network topology used to execute asset transfers, and regardless of the type of assets traded, we will construct a firewall of different security levels for users. With the help of triggers and machine learning technologies, we will provide users with passive defense and proactive alerting capabilities.

    We will work with parallel chains in Polkadot/Kusama to build and deploy the firewall function to enable a higher level of security for parallel chain asset interactions within the ecosystem; in addition, we can work with project parties or wallets in other ecosystems to provide them with this unique defense mechanism, ultimately reducing the risk of asset security across the Web3 world.

    Project Detailsโ€‹

    For the transaction firewall functionality, Redstone Network will build a set of on-chain/off-chain trigger components and their implementations. In general, users will not be aware of the firewall's operation, and the firewall will truthfully notify users of potential security risks when there are triggered alarms on the chain.

    Passive defense and active alarmsโ€‹

    • We build a series of stateless atomic trigger components, including on-chain triggers (quantity trigger, time trigger, price trigger), off-chain triggers (mail trigger, discord trigger, slack trigger) and off-chain message interaction components, which are responsible for actively obtaining external information or pushing messages to a specified server.;

    • Analyze transaction characteristics and behavior, design transaction protocol analyze the transaction characteristics and behavior, design the transaction protocol, check whether the basic information and check information of the transaction match through protocol parsing, and initially determine the validity of the transaction;

    • according to the trigger and the transaction protocol, with the idea of social recovery and multiple signatures, formulate different security level trigger policies for users, including power grabbing mechanism, freezing mechanism and alarm mechanism.

    Intelligent termination of transactions with evil address monitoringโ€‹

    The user-configured security scheme can effectively defend against known security problems, but not against unknown or unconfigured behaviors. By analyzing the transaction data recorded in the database under the chain, the transactions are analyzed according to the dimensions of transaction time, transaction frequency, transaction address, transaction direction, and transaction amount, and if the transaction behavior is different from the daily behavior, the meltdown mechanism will be triggered and alarmed; receiving the supervision instruction from a chain, the address that is doing evil and the derived address will be dynamically analyzed and the transaction meltdown mechanism will be triggered.

    For the application scenario of transaction firewall, it is mainly divided into token assets and NFT assets. Users can choose the type of asset that needs to be configured with the firewall, either for a certain token, or to protect the account that issues NFT assets.

    In addition, the transaction firewall feature is not dependent on any application, any architecture and any address type restrictions, making it flexible to handle a variety of new attack methods that are known or have not yet emerged in the future, as it aims to study the security of A to B transfers.

    Technology stack

    • Rust: Develop on-chain trigger/defense/alert modules
    • Go/Python: Develop off-chain analysis/trace/alarm modules

    Ecosystem Fitโ€‹

    This project will be developed, deployed and run based on the Substrate framework. Unlike other trigger projects, with the advanced features of OCW, we are able to provide users with an advanced on-chain alert push mechanism, which will help shorten the time for users to get critical information. At the same time, rooted in Polkadot/Kasuma ecology, as a parallel chain, the trigger interface on it will provide additional application features for all parallel chains, and with the help of relay chains, it can facilitate unique transaction defense capabilities for other parachains. We note that we are entering a completely new area that will provide an unprecedented protection experience for the blockchain space once our project is in actual operation.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Bin Guo
    • Li Smith
    • yiwei Shi
    • Leon

    Contactโ€‹

    (we are in the process of registering the legal entity)

    • Registered Address: N/A
    • Registered Legal Entity: N/A

    Team's experienceโ€‹

    Bin Guo

    • Over 9 years of experience in software development and project management, engaged in work related to blockchain and big data, and worked in a core research institution of State Grid (Fortune 500).
    • Polkadot senior ambassador, Substrate Evangelist, and early participants in the Polkadot ecosystem.
    • Github: https://github.com/AmadeusGB
    • Email: amadeusgb123@gmail.com

    Smith Li

    • Over 9 years of working experience in various aspects of computer programming.
    • Worked in the blockchain industry for 3+ years, a blockchain development engineer, familiar with polkadot, bitshares, fabric, etc.
    • Hackathon winner as a team tech leader: Winners of Polkadot Hackathon 2022.
    • github: https://github.com/baidang201

    yiwei Shi

    • Art and management background, worked for Hearst, MSN, responsible for market and product, more than one year of blockchain development experience, familiar with computer science, cryptography and different economic mechanisms, good at Go and Rust developmentใ€‚Hackathon winner as a team member: Winners of Polkadot Hackathon 2022
    • Github : https://github.com/shiyivei
    • Email : shiyivei@outlook.com

    leon

    • Over 7 years of working experience in web development experience ande more than one year of blockchain development experience, familiar with FrontEnd, good at Js,Ts and Rust development.Hackathon winner as a team member: Winners of Polkadot Hackathon 2022
    • github: https://github.com/walle233

    Team Code Reposโ€‹

    We have forked substrate-template repository code to implement on-chain triggers (quantity triggers, time triggers, price triggers) and off-chain triggers (email triggers, slack triggers) with the help of decentralized off-chain communication components, in addition, we have implemented a simple oracle machineใ€‚

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 20000 USD

    Milestone 1 Example โ€” Multiple passive defense mechanisms, as well as on-chain and off-chain alerting mechanismsโ€‹

    • Estimated duration: 1 month
    • FTE: 2
    • Costs: 8,000 USD
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide inline documentation for the code and a tutorial for users on how to configure the in-chain passive defense step, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article to explain the concept, design and implementation of the design in Grant and how to use these features in the blockchain)
    1.Passive_Defense PalletWe will provide users with stateless and application-independent protective features, and this module will be implemented through Substrate Pallet:
    transaction limit configuration: configure in advance the limit of transferring a transaction amount and limit the frequency of transactions within a specified time; protect users from suffering significant losses for a short period of time when their private keys are stolen.
    Freezing configuration: advance configuration of freezing transaction time, freezing transaction type, and whether the freezing command can be withdrawn; when the user realizes that the private key has been stolen, the freezing operation will be triggered immediately to help the user further reduce losses.
    Capture account authority configuration: configure in advance N friend addresses and M for friend operations to take effect; when the user realizes the private key has been stolen, let the account freeze first and contact their friends as soon as possible. When more than M friends vote to pass, the authority of the stolen account will be taken over and any transaction will be executed only after N friends vote. This way even if the hacker steals the private key, he will not be able to transfer money effectively.
    2.Active_Alarming PalletWe will provide users with on-chain and off-chain alerting functions. This module will be implemented through Substrate Pallet:
    On-chain alarm configuration: Any transaction that exceeds the limit will send an alarm event; for example, the user can configure that when N transactions exceeding the limit amount occur within a period of time, an off-chain alarm notification will be triggered; the user can configure, a period of Within a certain time, different times will trigger different alarm methods.
    Off-chain triggering alarms: Provide users with three off-chain notification methods: Mail, Slack, and Discord. For example, general alarms are sent to Mail, important alarms are sent to Slack, and critical alarms are sent to Discord to achieve hierarchical management of alarms.

    Milestone 2 Example โ€” Intelligent meltdown mechanism, including abnormal trading meltdown, evil trading meltdownโ€‹

    • Estimated Duration: 2 month
    • FTE: 2
    • Costs: 12,000 USD
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article explaining the concept, design and implementation of smart meltdowns and how to use these features in the blockchain)
    1.Analyzer ModuleWe will provide users with off-chain transaction analysis functionality, and this module will be implemented via the Go/Python programming language๏ผš
    Users can choose whether to enable the off-chain transaction analysis function. The module records and analyzes user transaction characteristics based on a counter, and uploads to the blockchain when abnormal results emerge from the analysis. When a potentially abnormal transaction occurs, the user can choose, based on advance configuration, whether the module simply alerts when an abnormal transaction is reported, or freezes the account until the user comes to deal with the problem on their own. In this case, the hacker does not trigger any on-chain restrictions, only the off-chain transaction analysis detects the anomaly
    2.Tracker ModuleWe will provide users with off-chain transaction analysis functionality, and this module will be implemented via the Go/Python programming language.
    This module implements the function of tracking the transaction records of a certain address at a certain time period, helping users to assist in analyzing the loss of the current address from the hacking attack, as well as analyzing the chain through which the hacker transferred the funds.

    Future Plansโ€‹

    Conceptualizing the application with the trigger concept, implementing the transaction firewall first, and refining our design based on user feedback. Implementation steps.

    • develop on-chain/off-chain triggers for firewall requirements.
    • refining the firewall design based on user feedback.
    • implementing cross-chain transactions and providing transaction protection for cross-chain links.
    • configure different levels of defense strategies based on implementation experience.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? How did you hear about the Grants Program? We heard about the Grants Program from the Web 3 Foundation Website, as well as personal recommendations from Polkadot community members.

    - + \ No newline at end of file diff --git a/applications/Relation-Graph.html b/applications/Relation-Graph.html index 2536f2d491b..d54b3c4f422 100644 --- a/applications/Relation-Graph.html +++ b/applications/Relation-Graph.html @@ -4,7 +4,7 @@ Relation Graph | Web3 Foundation Grants - + @@ -16,7 +16,7 @@ 2ใ€Mask complex all on-chain operations with sparql; 3ใ€sparql as blockchain.

    It supports the following specifications:

    arch.png

    Usage

    1. SPARQL Update

    Call extrinsic sparql_update with SPARQL for insert, update, delete operations.

    Try SPARQL update in Pallet Interactor as follows.

    Sample SPARQL: insert a record for person P001

    INSERT DATA
    {
       :P001 :name "Luna" ;
             :gender "Female" ;
             :age 35 ;
             :birthdate "1986-10-14"^^xsd:date ;
             :friends :P2, :P3 .
    }

    Changes to existing triples are performed as a delete operation followed by an insert operation in a single update request. The specification refers to this as DELETE/INSERT

    Sample SPARQL: update age to 36 for person P001

    DELETE
    { :P001 :age ?o }
    INSERT
    { :P001 :age 36 }
    WHERE
    { :P001 :age ?o }

    Sample SPARQL: delete all properties of person P001

    DELETE WHERE
    {
    :P001 ?p ?o .
    }

    Sample SPARQL: delete partial properties of person P001

    DELETE WHERE
    {
    :P001 :age ?age;
          :name ?name .
    }
    1. SPARQL Query

    Call RPC sparql_query with SPARQL for query operations.

    curl -H "Content-Type: application/json" \
        -d '{"id":1, "jsonrpc":"2.0", "method": "sparql_query", "params": ["SELECT ?name ?age  WHERE { :P1 :name ?name; :age ?age .}"]}' \
        http://localhost:9933

    Ecosystem Fitโ€‹

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Crypto and commodity trader

    5+ years of blockchain experience

    CFA, ACCA

    Visiting researcher at Imperial College NUS

    15+ years of experience in cloud computing, bigdata and large-scale distributed systems.

    Led team of 200+ members AsiaInfo, HP, AWS

    Former CMO at Patract Labs

    9+ years of marketing and operation and experience

    former core development engineer of IBM, AWS and other companies,

    10+ years of back-end development experience, Problem solving Bigdata

    former product leader of top blockchain companies,

    6+ years of project experience in finance, logistics, social networking, games products

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Milestone 1 โ€” Relation Graph deploy as pallet๏ผŒcontains insert,query,delete and updateโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation and a tutorial of use and deploy pallet
    0c.Testing GuideWe will add unit tests to cover all basic logic.
    1.wasm packageWe will create a wasm package that can deployed as pallet,contains insert,query,delete and update

    Milestone 2โ€” Expand the basic functions of database๏ผŒcontains ACL,OGM and subgraphโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will enhance inline documentation and create a tutorial of ACL,OGM and subgraph.
    0c.Testing GuideWe will add unit tests to cover all ACL,OGM and subgraph.
    0e.ArticleWe will publish an article that explains function and structure of Relation graph,and helping developers understand it.
    1.wasm packageWe will create a updated wasm package that can deployed as pallet,contains ACL,OGM and subgraph.

    Milestone 3 โ€” Finish use case๏ผŒscaffold and demo for Relation Graph (scaffold is a package of technique tools for building and using the relation graph easily)โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide documentation of use case๏ผŒscaffold and demo for Relation graph
    0c.Testing Guidewe wil provide functional tests to ensure scaffold functionality and robustness. In the guide, we will describe how to run the scaffold.
    1.package of scaffoldWe will create a package of scaffold ,developer can easily and quickly bulid their business function.
    2.demoA demo to show the process use the scaffold,built by js+rust.It will contains simple UI.
    3.open source codethe actual pallet as open source code.

    Future Plansโ€‹

    - + \ No newline at end of file diff --git a/applications/Roloi.html b/applications/Roloi.html index 4e28ffdcdab..afa7b2ec3c1 100644 --- a/applications/Roloi.html +++ b/applications/Roloi.html @@ -4,7 +4,7 @@ Roloi | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ 5-demo-stream 6-demo-stream

    Technology Stackโ€‹

    7-tech stack

    The UI will be a Next.js Progressive Web App (PWA) that enables both support for desktop and mobile devices, providing a smooth user experience.

    The current version of the smart contract was built using Rust and CosmWasm. We will migrate the smart contract to an ink! version.

    Data modelsโ€‹

    Roloiโ€™s smart contract provides the necessary features to stream tokens and withdraw from created streams.

    The main model is the โ€œStreamโ€:

    Methodsโ€‹

    create_stream

    Input* recipient_wallet * end_date * fundsAction: updates contract storage with a new stream.

    recipient_stream_withdraw

    Input* stream_id * withdrawal_amountAction: validates withdrawal request. If valid, returns funds to recipient.

    Ecosystem Fitโ€‹

    Project fitโ€‹

    Smart Contract DApp

    Target audienceโ€‹

    Own user base, including:

    Solutionsโ€‹

    Similar projectsโ€‹

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Foundersโ€‹

    We are Brian and Pablo, Software Engineers with a Degree from the National Technological University (UTN) from Buenos Aires, Argentina, and have more than 10 years of experience as developers for many different projects. We are currently working at a software factory from Buenos Aires as Full-stack Developers and Team Managers for US traditional finance clients like Morgan Stanley, Visa and JP Morgan.

    5 years ago we founded NeoPower, our own software company to work for different clients building freelance teams of designers, developers and testers.

    We work with different web and mobile technologies such as .NET, Java, Node.js, React, Angular, SQL, MongoDB. And different infrastructures including AWS and Azure. We started our crypto journey more than 2 years ago by learning Solidity and then Rust to build smart contracts for different blockchains.

    CGOโ€‹

    Hernรกn S. Hermida (aka Milstein) is a DeFi enthusiast who started his crypto journey more than 2 years ago. Currently he hosts #DeFiSpace a weekly Twitter Spaces cycle, with more than 25 episodes, interviewing builders from different multi-chain projects.

    He is an active participant in many crypto communities such as DeFi Argentina and NFTamina.

    Hernรกn joined the Roloi team to help with the growth and networking strategy, leveraging his knowledge about DeFi and communities.

    Development Status ๐Ÿ“–โ€‹

    Progressโ€‹

    Roloi started its journey as a protocol for the Terra ecosystem. During 2 months we developed the first version of the platform.

    We built a first version for the Terra ecosystem including UI and Smart contract.

    We also created a Youtube Demo video.

    After the Terra ecosystem crashed, we decided to pivot and explore other opportunities.

    Pivotingโ€‹

    We decided to pivot and continue building Roloi on Polkadot since we believe that itโ€™s the most beneficial decision for Roloi in the long term.

    Smart contractโ€‹

    We are currently researching the ecosystem. We defined a strategy to migrate our Rust smart contract to Polkadot by building an ink! smart contract.

    UIโ€‹

    We are working on creating our own UI abstractions to easily integrate any blockchain in Roloi. This includes:

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Migration of smart contract from CosmWasm to ink!โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationOur code will include inline documentation for each smart contract method.
    0c.Unit testsCore functions will be fully covered by unit tests to ensure functionality and robustness.
    1.Smart contract source codeWe will deliver the migrated version of the Roloi smart contract (ink! + Substrate). The following features will be included.
    1a.Create streamFunction that creates a stream by using a recipient wallet, an amount and an end date. The stream will have a unique ID and will store both the original balance and the current one (after withdrawals).
    1b.Withdraw from streamFunction that validates if the requested amount is available and, in that case, pays the amount to the recipient.
    1c.Get stream by IDFunction that returns the stream information.
    2.ArticleMedium article explaining the development experience while migrating from CosmWasm to ink!

    Future Plansโ€‹

    8-future plans

    Some features included in our roadmap:

    Our roadmap will vary depending on user and investors feedback. We will prioritize features needed in the Polkadot ecosystem.

    Additional Information โž•โ€‹

    Grants Programโ€‹

    We heard about the Grants Program through Twitter, and through personal recommendations from Parity developers we decided to apply for an initial grant to start building our product on Polkadot.

    NeoPowerโ€‹

    Web: https://www.neopower.digital/

    Roloi is the first blockchain project from NeoPower, the software company we founded 5 years ago.

    Our goal for NeoPower is to become a community-based Web3 focused company that provides:

    Investors supporting Roloi would also be supporting NeoPower to help onboard local talent to Web3.

    At NeoPower we focus on Security and User Experience (UX) to build the best products.

    - + \ No newline at end of file diff --git a/applications/RubeusKeeper.html b/applications/RubeusKeeper.html index 3e837a86a78..276124d5a46 100644 --- a/applications/RubeusKeeper.html +++ b/applications/RubeusKeeper.html @@ -4,14 +4,14 @@ Rubeus Keeper | Web3 Foundation Grants - +
    Skip to main content

    Rubeus Keeper

    • Team Name: Bela Supernova
    • Payment Address: 0xC0d28794eA40Ce9b9F4B62a1B2Bb42FD34b7d305 (USDT)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    This application is not in response to an RFP, but it fully complies with a potentially interesting project โ€œSign-in with your Polkadot, Kusama, etc. accountโ€ mentioned in Open Source Polkadot Stack page in the โ€œ browser extensionsโ€ section.

    Overviewโ€‹

    Remembering passwords from all resources is a challenging task. It doesnโ€™t need any introduction as all Internet users use passwords dozen times a day. The most common, but less reliable way of password managing is using the only password for all resources โ€“ not a good idea, but true. The other one, next most popular โ€“ using password managers built in your browser. Quite reliable for low critical data, but for privacy critical data this is not the way to store passwords as there are several ways for third parties to obtain passwords from these centralized systems. Users that value privacy usually use offline desktop applications for managing passwords โ€“ itโ€™s safe, but has disadvantages as different devices wonโ€™t sync, so one has to manage them separately.

    The aim of this project is to develop a decentralized password manager that stores data in a blockchain and uses personal Polkadot wallet credentials to access the passwords manager dApp. Saved passwords will be added automatically to appropriate forms on websites after logging in with userโ€™s wallet private key in the browser extension.

    Project Detailsโ€‹

    The Rubeus Keeper dApp will consist of two functional modules:

    1. An Ink! smart contract for seัure password storage using a Polkadot or Kusama account. Just log in to your Polkadot wallet and get access to your passwords DB. The smart contract will includes methods for writing and getting passwords, as well as categorizing.
    2. A browser extension for password managing: registration, log in, password generation, categorizing, saving, retrieving, autocomplete functionality.

    Under this MVP we consider security in the next attack vectors:

    1. Transferred data unauthorized interception and decryption (categories, URLs/logins, passwords).
    2. Malicious data substitution by a node. To solve the above mentioned tasks the data will be encrypted using the ChaCha20-Poly1305 streaming algorithm with message authentication. The protocol is standardized by IETF in RFC 7539, in software implementations it is much more efficient and faster than AES.

    Rubeus schema 3

    Ecosystem Fitโ€‹

    The Rubeus Keeper dApp will be used by all the community and even all Internet users as it simplifies and secures daily interaction with web applications โ€“ web2 or web3 โ€“ our dApp will be comprehensively useful. The target audience is โ€œa web userโ€.

    In the Open Source Polkadot Stack we see the Logion network project, that represents a separate parachain with very wide functionality. Unlike Logion we offer a simple Ink! contract and an extension that can be used in any Substrate based parachain with no need for setting nodes and etc. Fast, easy and no need for a separate wallet.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Sergey Cymbal, MBA, CEO at Bela Supernova d.o.o
    • Dmitrii Putilov, Blockchain Department Director at Bela Supernova d.o.o
    • Ilia Shavrin, Full stack software developer at Bela Supernova d.o.o
    • Anton Shramko, Full stack software developer at Bela Supernova d.o.o
    • Ksenia Baranova, QA Lead at Bela Supernova d.o.o
    • Alexey Vexin, Project Manager at Bela Supernova d.o.o
    • Anton Borisov, DevOps Engineer at Bela Supernova d.o.o

    Contactโ€‹

    • Registered Address: Cesta v Mestni log 55, Ljubljana 1000, Slovenia
    • Registered Legal Entity: BELA SUPERNOVA, sistemske reลกitve d.o.o.

    Team's experienceโ€‹

    Sergey Cymbal is an experienced executive, leader and visioner responsible for the most disruptive innovations initiatives across Oil/Gas, Utilities, and Telcos. Ex-member of winter Olympics HQ, responsible for digitalization, Smart grid evangelist. Blockchain early follower, participates in several crypto initiatives.

    Dmitrii Putilov has over 17 years of experience leading the teams creating and maintaining high availability sites. His portfolio contains creation of the robee.io investment platform included in top500 in coinmarketcap.

    Ilia Shavrin is a solution architect and full stack software developer with over 12 years of experience in high load enterprise applications. His most recent focus is on blockchain and creation of decentralized applications.

    Anton Shramko is an experienced developer with 7 years of experience on various positions, including solution architect in Krypton. Anton active contributor to open source and blockchain communities, he is also a frequent speaker in DevCon conferences.

    Ksenia Baranova is an QA test engineer with over 5 years of experience. Ksenia has exceptional knowledge and skills in the field. She is highly referred within this team, as well as by her former teams.

    Alexey Vexin is a product owner and a project manager with 15+ years of experience in managing complicated telecoms and IT projects in Telco, Utilities and Governmental sectors with deep focus on business process management. Led a dozen of national scaled projects for IT systems implementation and industry scaled technology development, standardization and implementation.

    Anton Borisov is a DevOps Engineer with broad experience. For over 15 years Anton was supporting, administering, and maintaining secure networks, servers, and clusters. He also has versatile experience with CI/CD, IT Infrastructure Monitoring, and Kubernetes on-premise and in Cloud. One of the most recent projects Anton participated in was building a first on chain casino.

    Bela Supernova has delivered a W3f grant earlier: OCEX

    BSN also has 2 active projects under FileCoin, Chainlink and Tgrade grants.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    We plan to execute 2 deliverables in two milestones:

    • an Ink! smart contract for password storage;
    • a browser extension for password management (tested under Chrome browser).

    The project will be supported by a team of 2 developers, 1 UI/UX designer, 1 DevOps engineer and 1 QA.

    Overviewโ€‹

    • Total Estimated Duration: 2,5 months
    • Full-Time Equivalent (FTE): 3 FTE
    • Total Costs: 30,000 USDT

    Milestone 1 โ€” Design and development of a smart-contract and a testing pageโ€‹

    • Estimated Duration: 1,5 months
    • FTE: 2 FTE
    • Costs: 22,000 USDT
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can run our smart contract and send test transactions, which will show how the functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.Ink! smart-contractAn Ink! smart-contract for password storage and use: โ€œadd password (title, url, username, password, comment)โ€, โ€œdelete passwordโ€, โ€œget passwordโ€, โ€œadd categoryโ€, โ€œdelete categoryโ€, โ€œget categoriesโ€. Stored data will be encrypted using the ChaCha20-Poly1305 streaming algorithm with message authentication.
    2.Test pageA test page for running functional tests: categories (get data from a blockchain, decrypt received data, unzip and get passwords, categories list render, passwords list render by categories); save password (data entry form, data serialization, zip data, data encryption, send transaction); show balance. The test page will be developed using JavaScript.

    Milestone 2 โ€” Design and development of a browser extensionโ€‹

    • Estimated Duration: 1 month
    • FTE: 1 FTE
    • Costs: 8,000 USDT
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can run our smart contract and send test transactions, which will show how the functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness under the Chrome browser. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains what was achieved, how to use the new Dapp and what are the benefits of using the system
    1.Browser extensionA Chrome browser extension MVP for password management: a registration page (login with a Polkadot wallet private key and set a master-password); login page (using master-password); categories (get data from a blockchain, decrypt received data, unzip and get passwords, categories list render, passwords list render by categories); save password (data entry form, data serialization, zip data, data encryption, send transaction); password generation window, show balance. The extension will be developed using JavaScript.
    - + \ No newline at end of file diff --git a/applications/Rubeus_keeper_st2.html b/applications/Rubeus_keeper_st2.html index 8528ec7140f..7f0ef9e942b 100644 --- a/applications/Rubeus_keeper_st2.html +++ b/applications/Rubeus_keeper_st2.html @@ -4,7 +4,7 @@ Rubeus Keeper stage 2 | Web3 Foundation Grants - + @@ -16,7 +16,7 @@ Reps: Rubeus Ink! smart contract Rubeus client

    Development Roadmap ๐Ÿ”ฉโ€‹

    We plan to execute 3 deliverables in three milestones:

    The project will be supported by a team of 2 developers, 1 UI/UX designer, 1 DevOps engineer and 1 QA.

    Overviewโ€‹

    Milestone 1 โ€” Design and development of text notes storage methodsโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure new functionality and robustness. In the guide, we will describe how to run these tests.
    1.Ink! smart-contractThe Rubeus smart-contract supplemented with new methods for text notes storage and use: โ€œadd note (title, contents)โ€, โ€œdelete noteโ€, โ€œget notesโ€ and โ€œupdate noteโ€.
    2.Extension โ€œnotesโ€ tabAn MVP for the Chrome browser extension tab for text notes management: notes list (get data from a blockchain, decrypt received data, unzip and get text notes, text notes list render); save a text note (data entry form, data serialization, zip data, data encryption, send transaction), delete a text note, update a note.

    Milestone 2 โ€” Autocomplete (autofill) feature developmentโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can run our smart contract and send test transactions, which will show how the functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains what was achieved, how to use the new Dapp and what benefits what are the benefits of using the system
    1.Browser extension autofill featureWe will develop additional functionality for the browser extension: - registration and authorization forms tracking; - suggestion to generate and save a password; - generation of a random password with user-defined rules; - autofill password forms on websites (tested on 5+ different web sites). To access passwords and manipulate them while the extension pop-up is closed we will rearrange the extension and transfer some logic to the service worker;
    2.Password generation toolWe will develop a tool for a random password generation with user-defined rules.

    Sample image of a password generation tool:

    Rubeus st2 pswd gen

    Future Plansโ€‹

    In the future plans for Rubeus we see widening of its functionality: from remembering credit cards credentials to answers for recovery questions. Everything that should be remembered for a personal use and complies with GDPR could be stored with Rubeus. A 2FA feature is also in our plans. All this should be developed under a later stage of the project.

    - + \ No newline at end of file diff --git a/applications/RubyProtocol.html b/applications/RubyProtocol.html index cdc4c3fd968..ab98b154399 100644 --- a/applications/RubyProtocol.html +++ b/applications/RubyProtocol.html @@ -4,7 +4,7 @@ Ruby Protocol | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ Dylan Dewdney is a longtime crypto enthusiast (2011). In 2017 he co-founded Harbour DAO, which became an open-standard set of tools for building governance structures and voting mechanisms on ERC-20. Later, as Chief Evangelist of Beam and Head of Growth for AdEx, he was a key part of their GTM and general growth strategies. Dylan is a respected peer among many different projects and areas of business.Dylan is also the project lead and CEO of DeData project Kylin Network.

    Team Code Reposโ€‹

    Team Linkedin Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement Cryptographic Modulesโ€‹

    The main deliverable of this milestone includes:

    NumberDeliverableSpecification
    0a.LicenseApache License 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.Article/TutorialWe will publish a medium article that explains the functionality of the proposed cryptographic library and substrate pallet delivered in this milestone.
    1.Cryptographic modulesWe will implement the cryptographic modules including inner product functional encryption and quadratic polynomial functional encryption [MSHBM2019] and the associated zero-knowledge proof [ZeroPool]. The cryptographic modules will be written in Rust and modified from the rust version of CiFEr library. We will build privacy-preserving classification and neural networks based on these modules. We will also implement a substrate pallet that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key.
    2.BenchmarkPerform unit tests on the individual algorithms to ensure their safety. Benchmark on the gas cost and throughput of the proposed module.
    3.DockerWe will provide a dockerfile to demonstrate the usage of our modules.

    Milestone 2 โ€”โ€” Client Implementation and Integrationโ€‹

    The main deliverable of the milestone is the client that can trigger the aforementioned cryptographic modules and the micropayment scheme and the necessary UI to enable the users to interact with all these algorithms.

    NumberDeliverableSpecification
    0a.LicenseApache License 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.Article/TutorialWe will publish a medium article that explains the functionality of the proposed client and UI delivered in this milestone.
    1.Client modulesWe will implement the client to support the key distribution and decryption of the functional encryption scheme [MSHBM2019]. The client will also generate the transaction that can trigger the aforementioned cryptographic modules and the micropayment scheme [MDJM2019], such as the encrypted functional key and zero-knowledge proof. We will provide a basic UI to take inputs from the users for all these algorithms and receive the outputs. More specifically, the UI will enable the data owner to input the raw data to generate the signed ciphertext and upload it to the cloud server. The UI will also allow the data purchaser to retrieve the functional key from the key authority and the ciphertext from the cloud and then perform the decryption. The UI will also register a qualified data source and allow a data owner to join the data monetization program when he/she meets the data source and the data owners to request a signature from a registered source, which will then be verified on-chain. Finally, it will also allow these entities to interact with the substrate module with the inputs and outputs defined in our architecture.
    2.BenchmarkPerform unit tests on the individual algorithms to ensure their safety. Benchmark on the latency and usability of the proposed client functionalities.
    3.DockerWe will provide a dockerfile to demonstrate the usage of our modules.

    Community Engagementโ€‹

    Future Plansโ€‹

    We will hire at least 8-10 more devs in the next three months. Meanwhile, we will apply for the Substrate Builder's Program. After that, Ruby Protocol wants to become a parachain for the Polkadot network. We have some preparations for auction and we may design a community-wide LPO.

    In phase 1, we will complete the implementation of cryptographic modules as a substrate pallet that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key.

    In phase 2, our goal is to deliver the micropayment scheme and enable the users to interact with all these algorithms in a working product.

    Finally, our goal is to provide an essential open API and SDK from a high-level perspective with the above tools, fully powering the data monetization framework on Polkadot.

    Additional Information โž•โ€‹

    Referenceโ€‹

    [GPSW06] Goyal, V., Pandey, O., Sahai, A., & Waters, B. (2006, October). Attribute-based encryption for fine-grained access control of encrypted data. In Proceedings of the 13th ACM conference on Computer and communications security (pp. 89-98).

    [GGGJKLZ14] Goldwasser, S., Gordon, S. D., Goyal, V., Jain, A., Katz, J., Liu, F. H., ... & Zhou, H. S. (2014, May). Multi-input functional encryption. In Annual International Conference on the Theory and Applications of Cryptographic Techniques (pp. 578-602). Springer, Berlin, Heidelberg.

    [GKPVZ13] Goldwasser, S., Kalai, Y., Popa, R. A., Vaikuntanathan, V., & Zeldovich, N. (2013, June). Reusable garbled circuits and succinct functional encryption. In Proceedings of the forty-fifth annual ACM symposium on Theory of computing (pp. 555-564).

    [ALS2016] Agrawal, S., Libert, B., Stehle, D.: Fully secure functional encryption for inner products, from standard assumptions. In: Annual International Cryptology Conference. pp. 333{362. Springer (2016).

    [B2017] Bourse, F. (2017). Functional encryption for inner-product evaluations (Doctoral dissertation).

    [B2018] Vitalik Buterin, https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477, 2018.

    [BCTV2013] Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. Succinct non-interactive zero knowledge for a von Neumann architecture. In Proceedings of the 23rd USENIX Security Symposium, Security '14. Available at http://eprint.iacr.org/2013/879.

    [BMEB2016] Bataineh, A. S., Mizouni, R., El Barachi, M., & Bentahar, J. (2016, June). Monetizing Personal Data: A Two-Sided Market Approach. In ANT/SEIT (pp. 472-479).

    [CGW2015] Chen, J., Gay, R., & Wee, H. (2015, April). Improved dual system ABE in prime-order groups via predicate encodings. In Annual International Conference on the Theory and Applications of Cryptographic Techniques (pp. 595-624). Springer, Berlin, Heidelberg.

    [FVBG17] Fisch, B., Vinayagamurthy, D., Boneh, D., & Gorbunov, S. (2017, October). Iron: functional encryption using Intel SGX. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (pp. 765-782).

    [LCFS2017] Ligier, D., Carpov, S., Fontaine, C., & Sirdey, R. (2017, February). Privacy Preserving Data Classification using Inner-product Functional Encryption. In ICISSP (pp. 423-430).

    [MDJM2019] Mehta, S., Dawande, M., Janakiraman, G., & Mookerjee, V. (2019). How to sell a dataset? pricing policies for data monetization. Pricing Policies for Data Monetization (August 1, 2019).

    [MSHBM2019] Marc, T., Stopar, M., Hartman, J., Bizjak, M., & Modic, J. (2019, September). Privacy-Enhanced Machine Learning with Functional Encryption. In European Symposium on Research in Computer Security (pp. 3-21). Springer, Cham.

    [PHGR2013] Parno, B., Howell, J., Gentry, C., & Raykova, M. (2013, May). Pinocchio: Nearly practical verifiable computation. In 2013 IEEE Symposium on Security and Privacy (pp. 238-252). IEEE.

    [RDGBP2019] Ryffel, T., Dufour-Sans, E., Gay, R., Bach, F., & Pointcheval, D. (2019). Partially encrypted machine learning using functional encryption. arXiv preprint arXiv:1905.10214.

    [RRS2013] Reimsbach-Kounatze, C., Reynolds, T., & Stryszowski, P. (2013). Exploring the economics of personal data-a survey of methodologies for measuring monetary value.

    [SC2017] Agrawal, Shashank, and Melissa Chase. "Simplifying design and analysis of complex predicate encryption schemes." Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, Cham, 2017. [SGP2018] Sans, E.D., Gay, R., Pointcheval, D.: Reading in the dark: Classifying encrypted digits with functional encryption. IACR Cryptology ePrint Archive 2018, 206, (2018).

    [TZLHJS2017] Florian Tramer, Fan Zhang, Huang Lin, Jean-Pierre Hubaux, Ari Juels, and Elaine Shi. โ€Sealed-glass proofs: Using transparent enclaves to prove and sell knowledge.โ€ In Security and Privacy (EuroS&P), 2017 IEEE European Symposium on, pp. 19-34. IEEE, 2017.

    - + \ No newline at end of file diff --git a/applications/SEOR-code-less-smart-contract-platform.html b/applications/SEOR-code-less-smart-contract-platform.html index 240dc234464..74c0122d5e5 100644 --- a/applications/SEOR-code-less-smart-contract-platform.html +++ b/applications/SEOR-code-less-smart-contract-platform.html @@ -4,7 +4,7 @@ SEOR code-less smart contract platform | Web3 Foundation Grants - + @@ -22,7 +22,7 @@

  • Step2 - Enter the required parameters to deploy

    • Advantagesโ€‹

    Overall planโ€‹

    We expect to implement a codeless smart contract platform that can support multiple chains through four phases.

    Implementation content of this grant application: We will use this grant to advance the development of the first and second phases. For details, please refer to the milestone section.

    Ecosystem Fitโ€‹

    No

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Team Websiteโ€‹

    Team's experienceโ€‹

    Our team is made up of leaders, core development engineers, and community developers of leading blockchain enterprise and projects Onchain, Ontology, TRON, and Bitkeep. We have rich technical accumulation and in-depth understanding in the blockchain field. We are working on blockchain's standardize and protocolize, and will provide a complete infrastructure solution to enable blockchains to powered various fields.

    Team Code Reposโ€‹

    https://github.com/SealSC

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 - Multi-chain smart contract setโ€‹

    NumberDeliverableSpecification
    1.LicenseApache License 2.0
    2.Contract set RepositoryA git repository containing the source code of 4 contracts: parameterized ERC20, liquidity mining, contract deployer and Uniswap protocol connector. These smart contracts are all developed to realizes parameterized during deployment, not copy the standard contract such as ERC20 directly. All of contracts will be will be implemented using both solidity and ink! technologies.
    3.Testing GuideAll contracts will have a proper unit-test coverage (min 80%) to ensure the robustness and safety of the contract. All of the test cases, test codes and test guide will be add to the repository.
    4.DocumentationRelated documents such as interface definitions, usage instructions, deployment tutorials, etc. of the contract set. These documents will be added to the git repository, and a pdf file download link will be provided on the project website.

    Milestone 2 - Multi-chain SERO-JS-SDKโ€‹

    NumberDeliverableSpecification
    1.LicenseApache License 2.0
    2.SDK code repositoryA git repository of SEOR-JS-SDK implemented using TypeScript. The SDK uses a unified interface to support the interaction between front-end DApp and substrate nodes, Ethereum nodes and other blockchain nodes of different architectures, allowing developers to access different chains with minimal changes without modifying the logic.
    3.Testing GuideThe SDK with have enough unit-test coverage(min 80%) to ensure functional integrity and robustness. All of the test cases, test codes and test guides will be added to the repository.
    4.Multi-Chain SupportSupport interactions with multiple public chains, including Polkadot, Ethereum, Ontology, EOS. At least the following wallets will be supported: polkadot{.js} extension, MetaMask extension, imToken, ONTO. We will provide several web page to proof the chains and wallets was supported by this SDK.
    5.DocumentationThe SERO-JS-SDK tutorial and documentation guide users how to quickly get started using it, and provide as detailed use cases as possible. These documents will be added to the git repository, and a pdf file download link will be provided on the project website.

    Milestone 3 - Multi-chain codeless smart contract platformโ€‹

    NumberDeliverableSpecification
    1.LicenseApache License 2.0
    2.Code-less smart contract platform DAppA code-less smart contract platform DApp will be deployed under a second-level domain name of this project. The DApp's UI part will be implement by VUE, and it will have a custom designed UI to uniform different chain's interface. The interactive with these chains will be supported by SEOR-JS-SDK. Through this DApp, users can deploy the contract implemented in Milestone 1 without coding to the parachains supporting smart contracts or directly to Ethereum, and contract interaction can be carried out in the platform powered by SEOR-JS-SDK.
    3.Testing GuideThe DApp with have enough unit-test coverage (min 80%) to ensure functional integrity and robustness. All of the test cases, test codes and test guides will be added to the repository.
    4.Multi-Chain SupportThe DApp will support at least 4 public chains: Polkadot, Ethereum, Ontology and EOS. Users can interactive inside the DApp with those chains through different wallets which supported by SERO-JS-SDK: polkadot{.js} extension, MetaMask extension, imToken, ONTO
    5.DApp tutorialProvide a detailed tutorial of DApp so that users can learn about platform functions through this tutorial, and can use the platform for contract deployment and interaction.

    Future Plansโ€‹

    - + \ No newline at end of file diff --git a/applications/SaaS3.html b/applications/SaaS3.html index 72c074cdb40..4e87b3c13d9 100644 --- a/applications/SaaS3.html +++ b/applications/SaaS3.html @@ -4,13 +4,13 @@ SaaS3 | Web3 Foundation Grants - +
    Skip to main content

    SaaS3

    • Team Name: SaaS3 Lab
    • Payment Address(USDT): 5Fv5fgxcWkRhddCwtsZbQt8JGKaezLorwLkkS6y2TuJ1wFs1
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Summary: SaaS3 is a protocol in layer2 that is highly scalable, crypto incentivized, and results in a solution that can serve as a decentralized APIs (dAPI) middleware to provide off-chain services to blockchain smart contracts.

    Brief Introductionโ€‹

    Background

    Dilemma of web3 Ecosystem - With functionalities yet to become full-fledged, Web3.0 applications need a rethink of development stacks. For instance, most of the web2 projects and dependencies are based on Java, C++, PHP, etc., while web3 requires another totally different technical stacks such as Solidity, Motoku, or Substrate on EVM / WASM which hinders web2 developers to build web3 applications.

    image

    Our solution - SaaS3 Oracle

    SaaS3 aims to deliver a highly scalable, crypto token incentivized and fully decentralized software as a service (SaaS) network which results in a solution that allows anyone to define and deploy customized oracles according to their Dapp needs. SaaS3 is devoted to transforming traditional web2 API to web3 dAPI.

    Essentially, SaaS3 is an TEE powered oracle infrastructure that allows anyone to define and deploy custom oracles according to their Dapp requirements. SaaS3 utilizes TEE technologies, while still enabling decentralization, trustless and secure computation by the secure hardware guarantee of Intel SGX chipset designs and by delegated proof of stake (DPoS) consensus.

    Therefore, such an infrastructure is not only for oracles that provide data feeds but also any type of computation which requires safe exchange of data.

    Examples:

    1. Any data feed:
      • Price of assets (ERC20/NFTs) on CEX and DEX.
      • Random Numbers
      • Weather reports, price of rent of an apartment, supply chain data, FIFA match results...
    2. Cross-chain data:
      • Bridges and cross-chain relayers
    3. Computation
      • Decentralized off-chain computation to enable truly decentralized metaverses and games
    4. Any Dapp that requires trust:
      • Custodian account managed by TEE for GameFi users that allows them to interact with the blockchain with only web2 api requests.

    SaaS3 enables Dapps to become as versatile as any other web2 application available today on the internet. As a result, the SaaS3 project will bridge web2 APIs to web3 dAPIs to flourish web3 ecosystem and achieve creator economy in a decentralized and trust-minimized way. This grant will allow us to develop several ink! smart contracts and a pallet for DAO management.

    Integration into Polkadot / Kusamaโ€‹

    • We planned to developed a parachain on Polkadot as SaaS3 DAO multichain governance centers.

    • The major component dRuntime will be implemented in ink!. https://github.com/SaaS3-Foundation/dRuntime-fat

    • Collaboration with Phala Network: We have partnered up with Phala Network which is a prominent parachain on the Polkadot ecosystem who will be providing SaaS3 with 15,000+ active TEE miners to enable trustless, permissionless and secure computation for our oracle infrastructure.

    Team Motivationโ€‹

    Our team has rich experience in web3 ecosystem, and we are dedicated to achieve secure and decentralized oracles.

    Protocol Detailsโ€‹

    Mockups/designsโ€‹

    The following figures show UI design of SaaS3:

    • Marketplace: explore open oracles and their details.

      • Marketplace-bg1@2x
      • Marketplace2@2x

    • Oracles deployment: deploy oracles within few clicks.

      • Deploy Oracles@2x
      • Deploy Oracles-10@2x

    • User Profile: view user information, wallet information, stake information, and deployed oracles.

      • Profile-planA1@2x

    Technology Stackโ€‹

    • Substrate
    • TEE
    • gRPC
    • Rust
    • ink!

    SaaS3 Protocolโ€‹

    SaaS3 protocol constructs a permissionless oracle network (PoN) to eliminate centralized computation resources to deliver developers the ability to create their customizable oracle (dAPI) by one-click permissionlessly and hostlessly.

    Permissionless Oracle Network (PoN)

    In PoN, four roles are involved: creator, miner, staker, and requester, and each role should accommodate SaaS3 protocol to stake and contribute to maintaining the high-quality services as shown in the following figure.

    Screenshot 2022-11-12 at 4 41 30 PM
    • Creator is the role of submitting dRuntime to create an oracle (dAPI) service, who can be any kind of off-chain service providers such as crypto exchanges, events organizers, or software developer.
    • Staker is anyone participating in the delegated proof of stake (DPoS) mechanism.
    • Miner acts as the computational worker to execute dRuntime on the hardware. TEE workers in Phala Network will be adopted in SaaS3 ecosystem to undertake this critical mission.
    • Requester calls the SaaS3 protocol to request off-chain services such as particular data feeds or off-chain computation results.

    Decentralized Serverless Runtime (dRuntime)

    In SaaS3, dRuntime (Decentralized Serverless Runtime) is a concept against centralized deployed runtimes which are centralized on cloud computing servers. dRuntime can be deployed on miner networks in a decentralized way by SaaS3 oracle launchpad. The launchpad is a Dapp for oracle creators to create their oracle with one click. Particularly, the creators should integrate the dAPI programs and settings into the dRuntime on the launchpad. Therefore, one oracle can be executed by multiple miners to achieve off-chain services instead of trusting an off-chain single point.

    There are four phases for dRuntime execution:

    1. Request: The Dapp smart contracts will call the protocol contract to request a specific off-chain service. The protocol contract will record the request specifications in blockchain event logs.
    2. Filtering: For each on-chain request, the protocol will generate a lightweight PoW (LPoW) task. The miners will compete to win the execution permissions by solving the LPoW task. The fastest 3 miners will win the execution permissions to run the API. Besides, the winners should be in the top-100 stake list, in other words, they should have a good amount of token stakes.
    3. Execution: The 3 winners in the last phase execute the corresponding API to retrieve the off-chain services.
    4. 3-zkc: An on-chain verification is performed with three minersโ€™ responses to aggregate the final output with the reward/slash on miner stakes.

    Architectureโ€‹

    SaaS3 architecture
    • Target Chain: SaaS3 protocol will be deployed on multiple blockchains, such as Polkadot and Kusama.
      • Dapp: decentralized applications which adopt SaaS3 oracle.
      • SaaS3 Protocol: a proxy smart contract which accept requests from Dapp and push them to Phat Rollup Anchor.
      • Phat Rollup Anchor: a smart contract built by Phala Network. It performs offchain rollup and commuicates to a phat contract dRuntime. Repo: https://github.com/Phala-Network/phat-offchain-rollup
    • SaaS3 Launchpad: a web-based Dapp which allows oracle creators to one-click launch their customizable oracle hostlessly and permissionlessly. By using Factory contract, oracle creators can deploy dRuntime phat contract easily.
    • Phat contract: the innovative programming model enabling off-chain computation which is created by Phala Network. Itโ€™s also known as Fat Contract as a practice of the "Fat Protocol and Thin Application" concept, and for its rich functionalities compared with existing smart contracts. Phat Contract uses Rust-based ink! language.
      - Offchain Scheduler: a phat contract built by Phala Network.
      - dRuntime: dRuntime (Decentralized Serverless Runtime) is a concept against centralized deployed runtimes which are centralized on cloud Computing servers. It can be deployed on miner networks in a decentralized way by SaaS3 oracle launchpad.
    • Phala Workers: are the TEE computation nodes with intel SGX chips which provide a hardware-encrypted sandbox for program executions with privacy-preserving and trustful computations.
    • Web2: includes all web2 services which provide API services, such as pricing reporting, event news, graph rendering and deep learning.

    Private Oracleโ€‹

    Phala network is exploited in SaaS3 as a decentralized computational infrastructure with hardware-encrypted TEE chips. Trusted Execution Environment (TEE) is a special area in some processors that provides a higher level of security including isolated execution, code integration, and state confidentiality. Thus, the oracle creators can easily store the API key or private data inside the fat contract which cannot be leaked out or be visible to miner operators.

    Private oracle is a particular kind of dAPI that only can be requested by the oracle creators themselves. Regardless of public oracles which only provide public data feeds, there is a large market for private oracles to connect blockchains with private off-chain services. To our knowledge, SaaS3 is the first oracle platform to support private oracle setup with a high-security architecture and one-click fast development.

    SaaS3 DAOโ€‹

    SaaS3 DAO refers to the decentralized autonomous organization (DAO), a governance body established with a full-fledged mechanism for token economics.

    Since the SaaS3 protocol will be deployed on multiple blockchains, each blockchain should have its own SaaS3 DAO. To manage different DAOs among multiple blockchains, SaaS3 will launch a Polkadot crowdloan to register a dedicated SaaS3 DAO parachain. The following figure demonstrates the multi-DAO structure.

    Multi-DAO Structure

    Treasury

    Each SaaS3 DAO has a treasury to maintain a pool of tokens that come from the commissions of dAPI subscription fee, and malfunction scrutiny and are designated funds for court jury rewards, protocol maintenance, and other DAO events.

    DAO treasury receives tokens when:

    • An oracle malfunctions due to inherent design flaws.
    • A miner node malfunctions due to miner dishonesty.
    • For each successful fulfillment of a dAPI subscription, the treasury receives a commission from a portion of the subscription fee payable by the user.

    For each court ruling, the treasury sends to the Jury as a reward for their participation in the governance. Since SaaS3 protocol is a multi-chain deployment, SaaS3 DAO parachain on Polkadot has the largest treasury to manage other treasuries among multiple blockchains.

    Court DAO

    A court as a component of a decentralized autonomous organization has been adopted as a medium of governance to consolidate consensus, justify DAO legitimacy and improve governance.

    On the Court DAO, there is a team of Jury members, consisting of 101 API creators that contribute most to the SaaS3 ecosystem which can be quantized by their API earnings. The court DAO receives the lawsuit from suing actors, composed of users and miners. The Jury members will make a judgment on the lawsuit by voting. If the suing actors win the lawsuit, the entities being accused will be penalized, the suing actor will be compensated for their loss and Jury members will be rewarded for their contribution to the case.

    Court DAO is charged with settling disputes regarding the performance of dAPI to hold dishonest actors accountable. Where there is a dAPI user who experiences a dAPI malfunction and fills a claim at Court DAO for scrutiny, Court DAO commences processing the case. Court DAO is seated by a group of jury members, who receive rewards for rulings. Rulings at Court DAO result in two outcomes; either the party who has filed the claim wins and the liable party has their staked tokens slashed, or the claim is dismissed.

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem?

      • SaaS3 provides a native and secure oracle solution to Dapps, empowering all DeFi projects in Polkadot / Kusama ecosystem.
      • SaaS3 holds potential for interaction with other parachains of Polkadot / Kusama such as Phala(Oracle Miner) and Moonbeam(Oracle User).

    • Target Audience: Dapp developers and parachain developers. SaaS3 oracle allows them to define and deploy customized oracles according to their Dapp needs.

    • What need(s) does your project meet?

      • Although web2 applications are highly dependent on centralized libraries and technical stack, they have a potential case of monetization if migrated to web3 as decentralized web3 dAPI through SaaS3 protocol.
      • SaaS3 brings millions of Dapp users, providers of computing resources and creators into a harmony and an organic ecosystem, with lowered costs and reliable services.
      • SaaS3 facilitates the privacy computation and TEE adoption in web3.

    • Compared to similar projects:

      • In Substrate / Polkadot / Kusama ecosystem:

        • Kylin Network: It offer less secure oracle solution, and its oracle nodes are neither permissionless nor decentralized .

      • In related ecosystems:

        • Chainlink: It is not dynamic, and it is hard to create customized oracle. Also, it does not have decentralized computation.
        • API3: Permission and centralized host server required.
        Competitor chart

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    The core team members are top Ph.Ds in computer science who are technical and experienced.

    • Steven is a Ph.D. in artificial intelligence and vice president of SaaS3 to build dRuntime on p2p network and financing-related works. Currently, he is an blockchain researcher and blockchain developer. He has written computer programs since he was 14 and got many hackathon awards in the past.

    • Rocky is the CTO of SaaS3 undertakes SaaS3 protocol design. Currently, he is the presidential postdoctoral fellow in NTU and chief scientist in Singapore Smart City Project. Previously, he was an AI researcher at UCB. Besides, he is also a visiting lecture professor of NTU, NUS. He is also the winner of over 10 hackathons.

    • Nael is the CPO of SaaS3 to guarantee the high-quality features of dRuntime. He also helps SaaS3 to find more partners to build communities. Besides, he is the founder of Chapa which is an online payment gateway with 30k customers that empowers small merchants and large businesses to accept digital payments from their customers via their APIs. Previously, he was the manager of crypto community manager and market researcher in world-leading companies.

    • Israel is the core developer of SaaS3 and undertakes the development of the creator submission network. Besides, he is the CTO of Chapa. He is the founder of Colimo City. Previously, He was the AI researcher in Google Brain, MILA of Turing Award Winner Yoshua Bengioโ€™s Lab. He has 4 years of experience in AI development.

    • Tianyi, Song is the core developer of SaaS3, and a former dev team manager of SkyCloud Co., Ltd. He is an expert in cloud computing development and has a lot of experience in bridging web2 to web3.

    Contactโ€‹

    • Registered Address: 71 Nanyang Dr, NTU Innovation Center, Singapore 638
    • Registered Legal Entity: SaaS3 Foundation LTD.

    Team Code Reposโ€‹

    GitHub accounts of all team members.

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 2
    • Total Costs: 10000 USDT

    Milestone 1 โ€” dRuntime in ink!โ€‹

    • Estimated duration: 1 month
    • FTE: 2
    • Costs: 5000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide a basic documentation that explains how dRuntime works, and how users can use SaaS3 oracle.
    0c.Testing GuideWe will provide a full test suite and guide for testing SaaS3 oracles.
    0d.DockerWe are not able to provide a Dockerfile, because dRuntime is written in Phat Contract, and it is finally compiled to WASM.
    0d.ArticleWe will publish an article that explains the whole workflow of SaaS3 protocol.
    1.dRuntime-fatdRuntime implementation in Phat Contract which is a superset of ink!.
    Functionspub fn handle_rollup() Entry point for Phat Rollup Anchor
    pub fn config(rpc, anchor) Configure the rollup target.
    Structsstruct Config { rpc, anchor, url, apikey }
    Storagepub struct Oracle { owner, config }

    Milestone 2 โ€” SaaS3 DAO Palletsโ€‹

    • Estimated Duration: 2 months
    • FTE: 2
    • Costs: 5000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and basic tutorials that explains and guides to SaaS3 DAO.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests for pallet-DAO
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains the usage of SaaS3 DAO.
    1.pallet-courtA pallet of court DAO, dAPI user raise sue to determine the punishment of malfunction miners / services and return sue claimed tokens to dAPI user.
    Functionspub fn submit_sue(origin, value, eid) dAPI User submit sue claims for malfunction.
    pub fn vote_sue(origin, value, eid, sid) Jury evaluates and votes the sue submission to determine punishment.
    pub fn process_sue(origin, sid) Process the accepted sue claims of dAPI user to slash malfunction miner / dAPI. The tokens will be paid to dAPI user and treasury with a ratio.
    Structpub struct Sue{sid, eid, claims, statement}
    Storagepub type SueList = StorageValue<_, BoundedVec<SueId, MaxSueNum>, ValueQuery>; List of all sue claims.
    EventsSueSubmitted { user, value, eid }
    SueVoted { user, value, eid, sid }
    SueCompleted { sid }
    2.pallet-treasuryA pallet of SaaS3 DAO treasury. It sends or receives token based on different situations. It is built on top of FRAME Treasury Pallet, with some additional functionalities.
    Functionspub fn receive(origin, value, category) Receive tokens with categorized reason, such as commission fees and miner node malfunctions.
    pub fn claim_rewards(origin, value) Court Jury members claim their rewards for their contribution in Court DAO.
    Storagepub type JuryRewards = StorageMap<_, Twox64Concat, AccountId, Rewards, OptionQuery>; Mapping from account id to rewards which can be claimed.
    EventsReceived {from, value, category }
    Claimed { user, value }
    3.UI & FrontendThis part is implemented by substrate front-end template. The frontend web interface contains DAO procedures related functions which including user sue judgement. A special document website is developed to guide entities to participate in DAO events.

    Future Plansโ€‹

    • Initially, Phala will be exploited as the oracle miner provider, but SaaS3 will build the own TEE chain in the future.
    • Continue developing and polishing the project to flourish SaaS3 ecosystem to burst the web3 world based on Polkadot / Kusama / Substrate multi-chain system.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Web3 Foundation Website

    Related Files

    Other Grants

    • IPFS Open Grant (Accepted)
    - + \ No newline at end of file diff --git a/applications/ScoutCoinFabrik.html b/applications/ScoutCoinFabrik.html index 544349a0e8d..380bff580ad 100644 --- a/applications/ScoutCoinFabrik.html +++ b/applications/ScoutCoinFabrik.html @@ -4,13 +4,13 @@ Scout CoinFabrik | Web3 Foundation Grants - +
    Skip to main content

    Scout CoinFabrik

    • Team Name: CoinFabrik (Nektra S.A)
    • Payment Address: 0xf488039EDe6B38D7689fDCC6A9FC2dd0EF39D54e (USDT)
    • [Level]: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Scout: Security Analysis Tool

    We are building an extensible open-source tool (or set of tools) to assist Rust Polkadot / Kusama smart contract developers to detect common security issues and deviations from best practices. To improve coverage and precision, we will persist in research efforts on static and dynamic analysis techniques.

    This tool will help developers write secure and more robust smart contracts.

    Our interest in this project comes from our experience in manual auditing and our usage of comparable tools in other blockchains.

    Project Detailsโ€‹

    We have already conducted research work with the Universidad de Buenos Aires to better comprehend the current status of analysis tools built for Rust, while foreseeing different lines of development.

    We are currently working on tools to assist developers to apply best practices and to identify possible vulnerabilities.

    Ecosystem Fitโ€‹

    We believe we can bring value to the Polkadot / Kusama community by offering a tool to detect security bugs from a development perspective. By including this tool in their toolchain, Polkadot / Kusama developers will be assisted to remove bugs in their code, raising the quality and security of their smart contracts.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Ariel Wassbein, Head of Reaseach
    • Valeria Caracciolo, Business Develpoment
    • CoinFabrik's development and auditing team - when required.

    Contactโ€‹

    • Registered Address: Dr. Emilio Ravignani 2394, C1425 CABA, Argentina
    • Registered Legal Entity: Nektra S.A.

    Team's experienceโ€‹

    We are a research and development company specialized in Web3, with a strong background in cybersecurity. Founded in 2014, we have worked on over 180 blockchain-related projects, EVM based and also for Solana, Algorand, and Polkadot. Beyond development, we offer security audits through a dedicated in-house team of senior cybersecurity, currently working on code in Substrate, Solidity, Clarity, Rust, and TEAL.

    Our team has an academic background in computer science and mathematics, with work experience focused on cybersecurity and software development, including academic publications, patents turned into products, and conference presentations. Furthermore, we have an ongoing collaboration on knowledge transfer and open-source projects with the University of Buenos Aires.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We have been working on different aspects of the tool:

    • Research on security analysis tools for Rust-based blockchains.
    • Listing common vulnerabilities and usability issues in different systems and technologies.
    • Tools to assist developers.

    We briefly validated the idea of the development described in this application with David Hawig and Bhargav Bhatt from Web3 Foundation, who encourage us to apply for this grant.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1 month
    • Full-Time Equivalent (FTE): 5 FTE
    • Total Costs: 15,000 U$D

    Milestone 1: Proof of Conceptโ€‹

    • Estimated duration: 1 month (Day 1 to Day 30)
    • FTE: 5
    • Costs: 15,000 U$D
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a report, listing relevant security issues introduced in smart contracts developed with ink!. This will include a summary of findings and how the results were procured, a detailed description of each vulnerability/best practice, and links to the code that exemplifies them.
    0c.Testing and Testing GuideNo tests with be produced at this stage.
    0d.DockerDoes not apply at this stage.
    0e.ArticleWe will upload to our blog a report summary.
    1ResearchProducing a curated list of vulnerabilities, best practices, and enhancements related to smart contracts written in ink!, considering the list of analysis categories currently used for our manual smart contract audits.
    2DevelopmentProducing code examples and snippets of smart contracts written in ink! for each type of vulnerability from the list mentioned in 1. Research.
    3DevelopmentProof of concept code detecting some (relevant) issues included in the list of vulnerabilities and best practices.

    Future Plansโ€‹

    (Our original plan was to apply for a 3 months grant, to reach a public release of the tool. But we were advised to apply for a shorter objective, so we are presenting only Milestone #1 from our plan) After completing this first milestone, we are planning on applying for 2 additional iterations to reach a tool prototype (Milestones #2) and public release (Milestones #3). Our mission is to continue to work on improving automated and assisted tools for finding security vulnerabilities and writing more secure code. Our objective is to help the Polkadot / Kusama community produce better and more secure code with these tools.

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Richard Casey from Parity brought this program to our attention. Our inquiries were addressed by David Hawig and Bhargav Bhatt, who also gently advised us on this presentation.

    - + \ No newline at end of file diff --git a/applications/ScoutCoinFabrik_2.html b/applications/ScoutCoinFabrik_2.html index 378be75f7df..fe2645269e9 100644 --- a/applications/ScoutCoinFabrik_2.html +++ b/applications/ScoutCoinFabrik_2.html @@ -4,13 +4,13 @@ Scout CoinFabrik | Web3 Foundation Grants - +
    Skip to main content

    Scout CoinFabrik

    • Team Name: CoinFabrik (Nektra S.A)
    • Payment Address: 0xf488039EDe6B38D7689fDCC6A9FC2dd0EF39D54e (USDC)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Scout: Security Analysis Tool

    We are building an extensible open-source tool (or set of tools) to assist ink! smart contract developers detect common security issues and deviations from best practices. To improve coverage and precision, we will persist in research efforts on static and dynamic analysis techniques.

    This tool will help developers write secure and more robust smart contracts.

    Our interest in this project comes from our experience in manual auditing and our usage of comparable tools in other blockchains.

    Project Detailsโ€‹

    We have already conducted research work with the University of Buenos Aires to better comprehend the current status of analysis tools built for Rust, while foreseeing different lines of development.

    We are currently working on tools to assist developers to apply best practices and to identify possible vulnerabilities.

    Ecosystem Fitโ€‹

    We believe we can bring value to the Polkadot / Kusama community by offering a tool to detect security bugs from a development perspective. By including this tool in their toolchain, ink! developers will be assisted to remove bugs in their code, raising the quality and security of their smart contracts.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Ariel Wassbein, Head of Reaseach
    • Valeria Caracciolo, Business Develpoment
    • CoinFabrik's development and auditing team - when required.

    Contactโ€‹

    • Registered Address: Dr. Emilio Ravignani 2394, C1425 CABA, Argentina
    • Registered Legal Entity: Nektra S.A.

    Team's experienceโ€‹

    We are a research and development company specialized in Web3, with a strong background in cybersecurity. Founded in 2014, we have worked on over 180 blockchain-related projects, EVM based and also for Solana, Algorand, and Polkadot. Beyond development, we offer security audits through a dedicated in-house team of senior cybersecurity professionals, currently working on code in Substrate, Solidity, Clarity, Rust, and TEAL.

    Our team has an academic background in computer science and mathematics, with work experience focused on cybersecurity and software development, including academic publications, patents turned into products, and conference presentations. Furthermore, we have an ongoing collaboration on knowledge transfer and open-source projects with the University of Buenos Aires.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We have been working on different aspects of the tool:

    • Research on security analysis tools for Rust-based blockchains, applicable to ink! Smart contracts
    • Listing common vulnerabilities, best practices, and enhancements related to smart contracts written in ink!
    • Producing code examples and snippets of smart contracts showing the mentioned issues.
    • Built a PoC (proof of concept) of a tool that identifies relevant security issues.

    We briefly validated the idea of the development described in this application with David Hawig and Bhargav Bhatt from Web3 Foundation, who encourage us to apply for this grant.

    We have finished the first milestone of this project (Milestone 1 of ScoutCoinFabrik PoC), accomplishing all the deliverables listed in the milestone table.

    Please note, however, that this milestone is the second grant associated with the same project: ScoutCoinFabrik. The first grant focused on the toolโ€™s PoC, and in this second grant we aim to develop a prototype.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 5 weeks
    • Full-Time Equivalent (FTE): 5 FTE
    • Total Costs: 30,000 USD

    Milestone 1: Prototypeโ€‹

    • Estimated duration: 5 weeks
    • FTE: 5
    • Costs: 30,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationDocumentation hosted on a separate webpage.
    0c.TestingIntegration testing. Specific tests for every linting detector based on code examples and snippets of smart contracts.
    0d.DockerDoes not apply at this stage.
    0e.ArticleWe will upload a report summary to our blog.
    1.aResearch and DevelopmentVulnerability examples. In addition to the examples developed in Milestone 1 of ScoutCoinFabrik PoC, we will develop more code examples and snippets of vulnerabilities, best practices, and enhancements related to smart contracts written in ink!.
    1.bResearch and DevelopmentFurther example versions of vulnerabilities developed in Milestone 1 of ScoutCoinFabrik PoC. This step is geared to provide a wider set of examples, therefore improving our ability to measure the precision of our prototype and any other ink! vulnerability detection tool.
    2.aDevelopmentBuilding a prototype that improves over the development of Milestone 1 of ScoutCoinFabrik PoC, detecting more classes of vulnerabilities and improving in precision on existing detectors. We are to build a prototype that can analyze Rust code to detect vulnerabilities in ink! smart contracts and possibly in pallets and other pieces of code. This builds over this proof-of-concept tool we've built and delivered as part of a grant for the web3 foundation by:
    a) Moving from a proof-of-concept (PoC) tool to a robust tool that integrates with a popular IDE (VSCode), includes a CLI, etc,
    b) We will improve on the precision of the detectors we included in the PoC reducing the rate of false positives, and
    c) We will add more detectors in order to have a reasonable coverage of the relevant security vulnerabilities that happen in smart contracts.
    2.bDevelopmentCommand line interface for the prototype. For this prototype, we want to develop a simple command line interface like the one used in other static analyzers from other blockchains (eg: Slither, Rustle).
    In particular, we will develop the possibility to run the prototype on smart contract files or directories.
    The base command will be: cargo scout file_name.rs
    We will also include options for running subsets of detectors and triggering errors for CI/CD workflows.
    2.cDevelopmentVSCode integration for the prototype. Our VSCode development will list security issues, highlight issues with squiggles and hover-over descriptions. We will seek compatibility of this development with other relevant ink! extensions such as Ink! Analyzer.
    3EvaluationPrototype validation against a selection of projects deployed on testnet or mainnet in order to evaluate detector precision. Evaluation report and detector improvement.

    Future Plansโ€‹

    (Our original plan was to apply for a 3 milestones grant, to reach a public release of the tool. But we were advised to apply for a shorter objective) After completing the PoC in our first milestone (Milestone #1), we are now applying for this second milestone to reach a tool prototype (Milestone #2). We envison a third milestone together with a public release (Milestone #3). Our mission is to continue to work on improving automated and assisted tools for finding security vulnerabilities and writing more secure code. Our objective is to help the Polkadot / Kusama community produce better and more secure code with these tools.

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Richard Casey from Parity brought this program to our attention. Our inquiries were addressed by David Hawig and Bhargav Bhatt, who also gently advised us on this presentation.

    - + \ No newline at end of file diff --git a/applications/Security_Marketplace.html b/applications/Security_Marketplace.html index e5c59ae795d..e4d7422faff 100644 --- a/applications/Security_Marketplace.html +++ b/applications/Security_Marketplace.html @@ -4,7 +4,7 @@ Security Marketplace | Web3 Foundation Grants - + @@ -71,7 +71,7 @@ the platform's deployment untill reliable auditors emerge on the platform who have been actively contributing to the community to make this process decentralised in true sense.

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Through RFP Portal.

    - + \ No newline at end of file diff --git a/applications/Shivarthu.html b/applications/Shivarthu.html index a7187e35942..336be88e846 100644 --- a/applications/Shivarthu.html +++ b/applications/Shivarthu.html @@ -4,7 +4,7 @@ Shivarthu | Web3 Foundation Grants - + @@ -45,7 +45,7 @@ Write the source code

    Long-term: Onboard people into the app, and improve it taking feedback from the community. Enhance the app, provide upgrades when required.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/Societal.html b/applications/Societal.html index dab44308238..062df035faf 100644 --- a/applications/Societal.html +++ b/applications/Societal.html @@ -4,14 +4,14 @@ Societal - MVP - Phase 1 | Web3 Foundation Grants - +
    Skip to main content

    Societal - MVP - Phase 1

    • Team Name: Societal Labs Ltd.
    • Payment Address: Ethereum - USDT: 0xcDcCF94f10d8A7165C1A336DD3795430a6CDE530
    • Level: 2

    Project Overviewโ€‹

    Overviewโ€‹

    Societal is an all-in-one Decentralized Autonomous Organization (DAO) creation and management platform. Societal allows all types of groups or communities to build their own online, transparent, and decentralized organization. Societal bundles all of the tools required to create and manage a DAO in one place. Creators will be empowered to construct a DAO with fungible, non-fungible, or a combination of governance tokens. Societal also offers DAO management tooling features like treasury management, specialized governance, task boards, legal structuring, and accounting. This removes the need to utilize siloed platforms to manage the operations of a DAO. Whether a creator is looking to build a DAO for their organization, raise and deploy investment capital, or decentralize governance of an NFT project, Societal has the necessary tooling for a seamless end-to-end experience.

    Utilizing Polkdaotโ€™s layer-0 infrastructure and ecosystem, Societal will provide DAOs with both maximum functionality and a cohesive user experience. With features including agnostic token compatibility, zero gas fees, a freemium entry point, and a SaaS-based membership pricing, Societal combines best-in-class features into one vertically integrated product. With integrations into DeFi, privacy, and identity protocols, Societal will enable web3 organizations to seamlessly transition and manage their DAOs into the future.

    The Societal team has been building in the Polkadot ecosystem for the last year. While at a previous Polkadot project, the Societal team noticed a lack of integrated DAO tooling - not only in the Polkadot ecosystem, but in the broader web3 industry as a whole. After analyzing how we might transition and manage our previous project into a DAO, there was no clear path. This, along with the team being both members and council members of various DAOs and noticing the lack of infrastructure, we decided to build a solution - Societal.

    Project Detailsโ€‹

    Societal Labs has been designing the product vision of the Socital platform for quite some time. We will go over the project details and blockchain architecture in this application and provide references below for more in-depth context.

    In Societal's final state, it will offer four main services; Create, Transition, Transfer and Manage. Create will allow any web3 user to create their own DAO. Transition will allow protocols to progressively move towards community ownership. Transfer will allow DAOs to transfer their DAO from an expensive siloed chain to the Sociteal platform. Manage will provide DAOs all the required product features to manage their organization, whether it is a small investment club or a large community-governed protocol.

    Societal will offer a wide range of features to create and manage a DAO. The features are split into three categories; Operations, Treasury, and Governance. The Operations features are: job & task boards, payroll, customizable feeds, legal tooling, on-chain reputation, and web & mobile application. The Treasury features are as follows: treasury wallets (multi-sig), DeFi integrations, on-chain cap table, accounting and private asset integrations. The governance features are: zero gas fee governance, proposal calendar, built-in governance models, governance treasury execution, and private voting.

    Societal will vertically integrate with projects to advance its tech stack and product offering, something not seen in most web3 projects today. For example, Societal can integrate DeFi services by working with projects like Acala, Parallel, and Composable Finance, which will allow for active treasury management for DAOs managed with Societal. For private assets and voting, projects like Manta and Phala can provide privacy-enabling functions like zero-knowledge proofs and trusted execution environments to make this possible. For on-chain credentials, projects like KILT and Litentry can provide KYC and member credentialing services that can be used by DAOs for governance and recruiting.

    The Societal platform will host a vast network of DAOs and eventually offer a Cross-DAO Marketplace. DAOโ€™s onboarded onto the platform will have access to a network of individual DAOs, along with any associated sub-DAOs or guilds. When a DAO has a task that needs to be completed, they will have the ability to post this task to the entire Societal network. This will reach the collective network of sub-DAOs or guilds that may have the ability to complete the required work. The interconnection of DAOs on the Societal platform will open up never before seen opportunities in collaboration across the web3 DAO, sub-DAO, and guild ecosystem.

    Finally, Societal plans to progressively transition into a DAO itself. Once the token is launched, a community-run treasury will grow over time until the entire network is owned and operated by the community.

    For more information, please refer to the following resources:

    • Societal Whitepaper here
    • Societal Docs here
    • Societal Testnet Requirements Doc here
    • UI Mockups (High Res.) here

    UI Mockups:

    Ecosystem Fitโ€‹

    As it stands today, the DAO landscape within the Polkadot ecosystem is not as mature as other ecosystems such as Ethereum and Solana. This is due to insufficient DAO creation and tooling infrastructure in the ecosystem. Currently, the Polkadot ecosystem does not have the creation, governance, treasury management, and payroll tooling products as other major blockchains. By building these tooling products on Polkadot, both the Polkadot DAO landscape and the broader DAO management tooling space is primed for innovation by utilizing the unique technical abilities that Substrate provides.

    The target audience of the Societal application are web3 users who require a platform to easily create and manage their DAO. Using the technical capabilities that Substrate provides, Societal will design our chain to be token agnostic, allowing current MetaMask users to easily connect to our chain and start using the governance application right away. By doing this, our project will meet the needs of the Polkadot community to create their own DAOs and have the tools to manage them as seen in other ecosystems.

    The projects like Societal in the Polkadot space are Polkassembly, SubDAO, and DoraFactory. Societal differs from these projects in multiple ways. First, Polkassembly is not building their own parachain and is only a governance platform for large Polkadot projects. Societal wants to allow any web3 user to create their own DAO - not just catering to large established protocols. SubDAO has recently been focusing on smart contract deployments on multiple chains and does not appear to be building a parachain. Societal will build its own parachain and use the technical capabilities of Substrate to be truly token agnostic, connecting with widely used wallets such as MetaMask, to avoid doing multiple chain deployments via smart contracts. Dora Factory is similar to Societal in the sense that they are building their own parachian, however we plan to offer zero gas fees and a SaaS based pricing model to enhance our user's experience. Societal will also seek to integrate with other parachains, having cross-chain smart contract execution.

    Teamโ€‹

    Team membersโ€‹

    • Graeme Fox
    • Tyler Gellatly
    • Max Kudinov

    Contactโ€‹

    • Registered Address: 707 5 St SW Unit 500, Calgary, AB, Canada T2P 0Y3
    • Registered Legal Entity: Societal Labs Ltd.

    Team's experienceโ€‹

    Graeme Fox is the former Director of Business Development at Ruby Protocol, a privacy project building with the Substrate framework. During this role, he gained extensive knowledge of both the Polkadot ecosystem and its technology stack. Prior to this, Graeme was the Lead Product Manager at Connectus. During this time, he was in charge of both internal and external development teams that created a web-based application using a MERN stack development, along with a supporting phone application on iOS and Android. It was during this role when Graeme was first introduced to blockchain development, as the main product line integrated with the Corda Blockchain to allow for automatic and secure payments following the completion of specific KPIs. Graeme has held other engineering roles in the past and holds a Bachelor of Engineering from Dalhousie University. He lives and breathes the entrepreneurial mindset, being involved in early-stage startups for the last four years.

    Tyler Gellatly has been building and scaling early stage start-ups for the last 4+ years. He was employee #1 and Director of Operations & Partnerships at Cuboh (a YC-backed SAAS middleware operating within the ghost kitchen industry) More recently, Tyler helped found Ruby Protocol, a novel privacy protocol building on the Substrate framework, and is still involved in a strategic advisory capacity. Currently, he sits on the DAO council for the Illuminati Collective, which currently has a 1000 ETH treasury under management. Tyler holds a Bachelor of Commerce from the University of Victoria, specializing in corporate strategy and finance. A well-rounded business operations leader with a background in finance, operations, capital fundraising, and strategic partnerships, Tyler is mission driven to bring web3 communities together at scale by utilizing blockchain technology.

    Max Kudinov is the CEO of Magic Powered, a software development firm building multiple web3 projects. Max has a passion for governance projects and was the Project Lead for the development of Astro DAO, an all-in-one DAO creation and management platform built on Near. From this experience, Max has excellent understanding of Rust and how he would like to improve upon the Astro DAO project. Max has highly experienced web3 and rust developers on his team, ready to start the development of this project.

    Team Code Reposโ€‹

    Org:

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine. Team:

    Team LinkedIn Profiles (if available)โ€‹

    Development Statusโ€‹

    Before applying for the Web3 Foundation Grant, the Societal team conducted the following research:

    • Reviewed the list of ideas that the Web3 Foundation could be interested in Funding here, our focus was on governance and treasury management UI
    • Reviewed the list of improvement proposals and the one that stood out the most for our current roadmap was XCM library & tools
      • The focus for Societal will be automatic cross-chain smart contract execution following an approved governance proposal on the Societal chain
    • Spoke with Robin Ejsmond-Frey and Amit Joshi from the Parity team regarding the development of Societal and the Web3 Grant application

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4 months
    • Full-Time Equivalent (FTE): 3 FTE
    • Total Costs: 30,000 USDT

    Milestone 1 โ€” DAO Factory Palletโ€‹

    • Estimated Duration: 2 months
    • FTE: 3
    • Costs: 20,000 USD

    The main delivery of this milestone will be the DAO Factory Pallet. This pallet will allow someone to create a DAO on the Societal Network, where the DAO consists of a governance token, treasury and governance system.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and create a DAO.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a tutorial that explains how to create a DAO.
    1.Substrate module: DAO FactoryThis substrate pallet will create a DAO. While creating a DAO, the user can create a token for the DAO, setup a treasury and select a governance system.
    2.Client ModulesMinor UI updates will be made, to allow the user to interact with the pallet. However, the major UI creation will be completed in milestone 2.

    Milestone 2 โ€” Governance & Treasury Dashboardโ€‹

    • Estimated duration: 2 months
    • FTE: 3
    • Costs: 10,000 USD

    The main delivery of this milestone is to have an easy to use and interactive UI for users to create a DAO and manage its governance and treasury.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a tutorial that explains the UI of the Societal platform and how to use the application.
    1.Client ModulesWe will create a client facing UI that will interact with the Societal chain. The main function of the dashboard will be for the creation of the DAO, and manage its goverance & treasury.
    2.Substrate chainIn this milestone the Substrate chain will be built and the necessary pallets will be implemented. The pallets that will be included are: DAO FACTORY, System, Support, Executive, Assets, Authority Discovery, BABE, Balances, Democracy, Elections, Referenda, GRANDPA, Indices, Membership, Multisig, Nicks, Proxy, Scheduler, Transaction Payment, and Treasury

    Notes: Please note that the list of pallets is not exhausted. Some pallets may need to be added or removed from the MVP. However, based on my initial research the pallets listed above will be the required pallets for the Societal chain.

    Future Plansโ€‹

    Societal plans to secure fundraising and expand the development team. After the completion of the milestones stated above, Societal plans to expand the product offering by implementing a DAO Market Place and a Mobile App for DAO management. Ideally Societal will be able to secure another Web3 grant for these milestones, along with integrations for private voting and identity voting based on links to the RFPs. From there, Societal would also like to apply for the Substrate Builders Program, establishing itself at the go to DAO and governance platform. Finally, Societal will progressively transition into a DAO itself and release control to the community.

    Additional Informationโ€‹

    How did you hear about the Grants Program?

    Societal heard about the Grants Program from our time building in the Polkadot Ecosystem.

    Additional Information:

    • Work you have already done?
      • The information provided in this application encompasses most of the work done on this project. Other work done on the project has been based around design, website development and fundraising.
    • If there are any other teams who have already contributed (financially) to the project?
      • Yes, all the founders of Societal Labs have contributed financially to the project.
    • Previous grants you may have applied for?
      • No other grants have been applied for.
    - + \ No newline at end of file diff --git a/applications/Solang_Playground.html b/applications/Solang_Playground.html index a1a1e2600e2..23628beb186 100644 --- a/applications/Solang_Playground.html +++ b/applications/Solang_Playground.html @@ -4,7 +4,7 @@ Solang Playground | Web3 Foundation Grants - + @@ -30,7 +30,7 @@ d. Improved Solang's parser resilience.

    2- Worked on Solang as part of a previous W3F grant.

    Github Handleโ€‹

    LinkedIn Profileโ€‹

    Development Status ๐Ÿ“–โ€‹

    The project can be considered as a helper project for Hyperledger Solang. Designing the milestone structure was based on some existing IDE structures and design choices. To achieve the desired result, various open-source projects will be integrated. A list of these projects and their use are briefly documented in this notion page.

    There were also talks, via mail, with members from the foundation explaining interest in the project.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1: Solangโ€™s language server integrated in a Solidity Web Editor Clientโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.Documentation- We will provide both inline documentation of the client code and a readme that shows the build steps of the language server .wasm binary.
    0c.Testing and Testing Guide- The functionalities of the .wasm language server will be tested against the existing test suite of the current language server to ensure robustness.
    - Evaluators can fire up the docker container locally and try to edit Solidity source files with smarts provided from the language server.
    0d.DockerA docker image will be provided so that an evaluator can easily set it up an try out the client locally.
    0e.Solang Playground ClientWe will provide a functional web editor in which a developer can edit and save Solidity source files with the help of Solang's language server.(documented code base).
    Note: To make things clear, this milestone only invovles the integration of the language server into the client. It does not involve compiling or deploying contracts.โ€‹

    Milestone 2: Solang Playground Backend Serviceโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a readme that shows how to run and interact with the actix web server.
    0c.Testing and Testing Guide- Unit tests to be provided to test for the compilation result of the web server. The unit tests will be a part of the server's source code.
    - Test scripts for the client's compile functionality.
    0d.Docker- A Docker container will be provided for the actix web server.
    - A Docker compose script to be provided to build both the client container and the backend container and set their networking.
    1.Initial skeleton- The client should have a compile functionality in which the bytecode and metadata can be viewed. This would be done by the interaction with the backend server implemented in this milestone.

    Milestone 3: Substrate node interactionโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationAdded code to the client will be documented. Steps for deploying and interacting with a smart contract will also be provided at this point.
    0c.Testing and Testing Guide- A testing suite will be provided to ensure that the front-end sends the correct requests (compile, deploy and test) with correct parameters. The tests will ensure the contracts are deployed and could be interacted with as expected.
    0d.DockerSince this milestone is considered added functionality to the client (milestone 1), the docker provided in the first milestone would be updated and a new container for the client will be provided.
    1.First Working Version- At this point, a Solidity developer should be able to edit, compile, deploy and interact with a smart contract through the IDE without installing any components.

    Milestone 4 Solang IDE Improvementsโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and update the readme of the playground with the newly added functionalities
    0c.Testing and Testing GuideThe added functionality will be tested against the test suite provided in milestone 4
    0d.DockerSince this milestone is considered added functionality to the client (milestone 1), the docker provided in the first milestone would be updated and a new container for the client will be provided.
    0e.ArticleI will share a blog-post on multiple platforms inviting Solidity developers to try out Solidity on Substrate using the IDE.
    1.IDE Improvements1- Call a specific function by the click of a button, alongside with the required parameters. E.G. similar to contracts UI. (Only possible on the Substrate side)
    2- Initializing the work-space with an example contract in a Solang project file structure ready for deployment and interaction.

    Future Plansโ€‹

    Future improvementsโ€‹

    1- Removing the Backend Component:โ€‹

    Removing the Back-end component of the web IDE consists of a collection of tasks:

    2- Making the IDE visually attractiveโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    I have already completed a grant under this program. I was first introduced to it by my mentor Sean Young and the awesome Cyrill leutwiler.

    - + \ No newline at end of file diff --git a/applications/Solang_developer_experience_improvements.html b/applications/Solang_developer_experience_improvements.html index 0da91f42281..ac625ac6548 100644 --- a/applications/Solang_developer_experience_improvements.html +++ b/applications/Solang_developer_experience_improvements.html @@ -4,7 +4,7 @@ Solang developer experience improvements. | Web3 Foundation Grants - + @@ -15,7 +15,7 @@ Grace period(Time allocated for events that are not pre-calculated, like emergencies or unexpected work): 1 month

  • Full-Time Equivalent (FTE): 0.5 FTE (20h per week)

  • Total Costs: $5,000

    • Milestone 1: Improve debug buffer usageโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationI will provide both inline documentation of the code and some basic instructions of how a Solidity developer can utilize the debug buffer. I will also provide documentation of the newly added runtime errors.
    0c.Testing and Testing GuideI will add unit tests to Solang's Substrate integration tests. The tests will ensure that the output of the omitted debug buffer is as expected(regarding prints, API calls, runtime errors and overall structure). Also, I will make sure that running Solang's test suite via cargo test --workspace produces no failing tests.
    0d.DockerThere will be no independent DockerFiler for this milestone, because Solang has its own DockerFile, which can be used to test the mentioned functionalities.
    1.Use structured data in the debug bufferCompleting this issue will result in a well structured debug buffer.
    2.Print execution errors in the debug bufferNow that the debug buffer is well structured, runtime errors can be inserted in it for the user to debug.
    3.Execution errors to be passed with source file and line numberInstead of having an arbitrary error emitted on the debug buffer, the line number of the instruction will be inserted so that the dev will have an easier debugging experience.
    4.Bug FixFix Bug: Substrate Integration tests fail to compile with -g

    Milestone 2: Implement Solang projects:โ€‹

    Time Estimate: 2 months FTE (Full time Equivalent): 0.5 Cost: 2,000 USD

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationI will provide both inline documentation of the code and some basic instructions of how a Solidity developer can utilize the command solang new and the Solang.toml file to provide compiler configuration
    0c.Testing and Testing GuideI will add unit tests to Solang's Substrate intergation tests. The tests will ensure that the generated contract runs as expected on the configured chain. The tests will also ensure other information like contract author and version are correctly inserted the Solang.toml.
    0d.DockerThere will be no independent DockerFiler for this milestone, because Solang has its own DockerFile, which can be used to test the mentioned functionalities.
    0e.ArticleI will write a blog post that describes the two milestone, the target audience would be Solidity developers who want to try out Substrate.
    1.Implement Solang projectsThe functionalities mentioned under Solang Improvement Project Details: Solang Projects will be delivered.

    Assurance That the Current Project Owners Are Willing to Review/Accept Your Contributions:โ€‹

    Discussions with project owner Sean Young and maintainer Cyrill Leutwiler resulted in that the issues presented above would be reviewed and merged.

    Current and Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Recommendation from Solang's maintainers Sean Young and Cyrill Leutwiler

    - + \ No newline at end of file diff --git a/applications/SpellRouter-proposal.html b/applications/SpellRouter-proposal.html index 5d3e2697149..32487ad2c17 100644 --- a/applications/SpellRouter-proposal.html +++ b/applications/SpellRouter-proposal.html @@ -4,7 +4,7 @@ SpellRouter - XCM Router by ParaSpellโœจ | Web3 Foundation Grants - + @@ -32,7 +32,7 @@ | Support for HRMP Channel operations | Integrated users can open & close HRMP channels on their local chain (Useful feature for devs) | Not integrated | Not integrated| | Support for checking details that do not change | Integrated & also be covered with some error handling eg (too little amount being sent, not sufficient for XCM transfer) | Integrated in the form of a small "map" for different Tokens & Node IDs | Integrated in form of Map|

    We are currently in talks with several Parachain teams that like the idea of unified SDK for XCM transfers as much as we do. SDK that unifies XCM can be very helpful for the entire ecosystem in our opinion. With the introduction of XCM API and soon XCM Router this improves even further.

    Our target audiences are Web3 projects and starting/current blockchain developers.

    As SDK is also fully developed and its metrics are available to the public we can see, that it is still used a lot by developers in the ecosystem (Even after the API release).

    Screenshot 2023-10-16 at 18 50 37

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Duลกan Morhรกฤ - Student, project Founder &ย Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava

    Michael Absolon - Student, XCM SDK & XCM API Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava

    Contactโ€‹

    Team's experienceโ€‹

    And here is a certificate in physical form:

    certificate

    Team Code Reposโ€‹

    Team Github Profiles ๐Ÿง‘โ€๐ŸŽ“โ€‹

    Team LinkedIn Profiles ๐Ÿง‘โ€๐ŸŽ“โ€‹

    Development Status ๐Ÿ“–โ€‹

    We are currently finishing maintenance tasks and issues that are open in XCM SDK, XCM API and Docs repositories. After that, we wish to shift our focus to the development of an XCM Router which we already have laid out the structure for and we have basic functionality laid into small steps that will help us achieve making this state-of-the-art technology.

    As there are no XCM Routers currently in the ecosystem, this challenging task motivates us to fill the gap once again (Just like with XCM API).

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 - Create XCM Router and move all three tools into Monorepoโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both readme.md and official docs documentation
    0c.Testing and Testing GuideTesting guide will be mentioned in official docs
    0e.Create Medium article about development of early RouterAdd article covering early XCM Router version
    1.aIntegrate early version of XCM Router IThis version will contain additional detail about exchange Parachain (XCM Router will not select exchange automatically yet, the developer has to select from a provided list). The first version will feature functions like patterns to create calls. See an example of function pattern
    1.bIntegrate early version of XCM Router IICompared to the first version, this version will feature a Builder pattern to enhance the developer experience. See an example of builder pattern
    2.Update docs to cover early XCM Router versionAdd comprehensive guide that covers usage of early XCM Router version
    3.Create unit tests for XCM RouterCreate unit tests for core features in XCM Router

    Milestone 2 - Enhance XCM Router and feature automatic tool updatingโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both readme.md and official docs documentation
    0c.Testing and Testing GuideTesting guide will be mentioned in official docs
    0e.Create Medium article about development of latest XCM RouterAdd article covering new features &ย improvements brought with SpellRouterโ˜„๏ธ
    1.Integrate automatic exchange chain selection into XCM RouterIntegrate automatic exchange chain selection into the router (If the user wishes they can manually insert it otherwise Router will select automatically). XCM Router will try to select an exchange with the best pool/price. To see the difference between automatic and manual selection feel free to see the following image
    2.Integrate XCM Router into LightSpell XCM APIIntegrate core functionality of XCM Router into LightSpell XCM API
    3.aUpdate unit tests for new XCM Router functionalitiesUpdate unit tests for new XCM Router functionalities
    3.bCreate integration tests for XCM RouterCreate integration tests for core features in XCM Router
    3.cUpdate integration, unit and e2e tests for LightSpell XCM APIAdd new integration,unit & e2e tests for core LightSpell XCM API XCM Router integration
    4.aCover latest automatic exchange chain selection in XCM Router section (Docs)Add comprehensive guide covering automatic selection in XCM Router section
    4.bCover XCM Router integration in XCM API section (Docs)Cover XCM Router integration in LightSpell XCM API Section

    Future Plans ๐Ÿ”ญโ€‹

    Our focus will always remain on developer experience as well as being open source, completely free, common good and helpful to others. Another future goal that we try to keep is to continue innovating in the XCM area - bringing new state-of-the-art tech.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Personal recommendation

    Project achievements in chronological order โŒ›๏ธโ€‹
    - + \ No newline at end of file diff --git a/applications/SpiderDAO.html b/applications/SpiderDAO.html index 447629879b6..32551e9e33c 100644 --- a/applications/SpiderDAO.html +++ b/applications/SpiderDAO.html @@ -4,7 +4,7 @@ SpiderDAO Grant Proposal | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ Our founding team has covered all costs accrued thus far out-of-pocket. We have an investor on the sidelines who will cover any shortfall that may arise between the use of this grant and our next source of funding, whether that be the General Grants program or a VC-led private sale.
  • Have you applied for other grants so far? No
  • How can I get involved? Anyone looking to get involved is more than welcome to reach out to info@spiderdao.io Telegram groups and community creation/outreach will occur once the testnet is in use and we are preparing to launch.
    • - + \ No newline at end of file diff --git a/applications/Standard_Protocol.html b/applications/Standard_Protocol.html index a3e9a78abbf..5eed04e6806 100644 --- a/applications/Standard_Protocol.html +++ b/applications/Standard_Protocol.html @@ -4,7 +4,7 @@ Standard Protocol | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ prices are stored in the state, and oracle providers are updated in each era.

    market module /marketโ€‹

    Market module in standard protocol manages pair for automated market maker(AMM) between collateral and its stablecoin meter(MTR).

    vault module /vaultโ€‹

    Vault module in standard protocol is a collateral debt position engine where

    Ecosystem Fitโ€‹

    Standard protocol will act as the catalyst for other parachain's financial activities for enabling leverage trading and Arbitrage in AMM created from liquidation. It will also open a protocol for synthetic asset market with decentralized oracle ecosystem.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Hyungsuk Kang, team leader

    Standard protocol is being made with Apache 2.0 license. Legal entity is being built in Singapore right now.

    Team's experienceโ€‹

    Hyungsuk is Plasm network's core developer. He developed Subswap, AMM in substrate, and he wants to extend it to make the next finance in Polkadot ecosytem using XCM module and collateral debt position. He is also kernel and tendermint fellow.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    As a synthetic asset protocol,Standard protocol heavily depends on the oracle for maintaining the system. Oracles should be formed in a sustainable way to be motivated for people to provide computing power. To reward the network participant, Standard protocol proposes new PoS reward system by splitting block rewards from block validators to oracle providers.

    Milestone 1 - Middleware for data submission and runtime integrationโ€‹

    This milestone focuses on building a oracle provider client middleware which submits off-chain data to the blockchain. An authoritive module for testing connection between oracle provider and the protocol is provided in this phase. Then, Standard will extend the oracle module to distribute reward from session callback connected between pallet_session and pallet_staking. When oracle provider submits outliers or does not submit values that are out of sync from other oracle providers, a slash can be applied from anyone to report. Outliers are detected with IQR method.

    Oracle provider clientโ€‹

    As chainlink and other oracle solution has a middleware or submitting client from off-chain, Standard also has its oracle client. Oracle provider client is actually a bot that uses polkadot-js api to submit information in oracle module in a certain periods(e.g. 2 hour, 4 hour). For example, to send an oracle xt from an oracle client,

    // Loads config
    import LumenConfig from "@digitalnative/lumen-config";
    // Fetch functions for acquiring off-chain data
    import fetchData from "@digitalnative/lumen-fetch";
    // Submit function for submitting data to on-chain
    import submitData from "@digitalnative/lumen-submit";
    // Async Apis for polkadot
    import { ApiPromise, WsProvider } from "@polkadot/api";

    const runClient = async (dir) => {
      const cron = require("node-cron");
      const config = LumenConfig.default({ dir });
      const { events } = config;
      events.emit("client:start");
      const api = await polkadotApi(config);
      // register cron job to execute in every minute
      cron.schedule("*/90 * * * * *", async function() {
        events.emit("client:next");
        // fetch data
        const data = await fetchData(false, config);
        // Submit data
        await submitData(data, config, api);
      });
      // Declare cron job has been set
      events.emit("client:init");
    };

    export default runClient;

    async function polkadotApi(config: LumenConfig) {
      const provider = new WsProvider(config.rpc);
      const definitions = require("@digitalnative/type-definitions/opportunity");
      let types = definitions.types[0].types;
      const api = await new ApiPromise({
        provider,
        types,
      });
      await api.isReady;
      return api;
    }

    Here is the overall workflow for the client operation, and add-ons and options are expected to be added in each function in the library.

    Unit testsโ€‹

    Standard protocol applies test driven development(TDD) on building runtime modules for the grant. Here are unit tests that will be done along the development in the runtime module.

    Oracleโ€‹

    oracle in milestone 1 should achieve:

    To check this, oracle provider module should have these test functions:

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDocumentation will introduce how to install the oracle and participate to get block reward
    1.Oracle clientOracle client to receive information from external sources then submit information regularly to substrate runtime
    2.Modified Oracle moduleOracle module to register operators and batch
    3.Unit test codesUnit test codes in tests.rs in each runtime module
    4.Npm binaryWe will provide a npm binary for oracle providers to install and run an oracle client
    5.DockerfileDockerfile for running Standard protocol binary will be provided

    Milestone 2 - PoS oracle reward distributionโ€‹

    This milestone focuses on including session callbacks related to sessions in implementations of SessionManager trait in pallet-staking module, and all related module will be tested with its separate implementation of SessionManager connected to pallet-session in a mock environment.

    Vaultโ€‹

    Vault in milestone 2 should have a trait for dependency Injection:

    pub trait RebaseCallback {
        fn rebase(); // where it initiates rebase in the session
    }

    The dependency injection will take place in the pallet-staking's config as well as the oracle

    impl pallet_custom_staking::Config for Runtime{
        ...
        type Rebase = RebaseCallback; // for vault rebase
        type Oracle = OracleCallback; // for oracle callback used as same as staking callbacks
    }

    where the it will be included in pallet-staking module's SessionManager trait implementation in end_session function like:

    /// In this implementation `new_session(session)` must be called before `end_session(session-1)`
    /// i.e. the new session must be planned before the ending of the previous session.
    ///
    /// Once the first new_session is planned, all session must start and then end in order, though
    /// some session can lag in between the newest session planned and the latest session started.
    impl<T: Config> pallet_session::SessionManager<T::AccountId> for Module<T> {
     fn new_session(new_index: SessionIndex) -> Option<Vec<T::AccountId>> {
      frame_support::debug::native::trace!(
       target: LOG_TARGET,
       "[{}] planning new_session({})",
       <frame_system::Module<T>>::block_number(),
       new_index
      );
      Self::new_session(new_index)
     }
     fn start_session(start_index: SessionIndex) {
      frame_support::debug::native::trace!(
       target: LOG_TARGET,
       "[{}] starting start_session({})",
       <frame_system::Module<T>>::block_number(),
       start_index
      );
      Self::start_session(start_index)
     }
     fn end_session(end_index: SessionIndex) {
      frame_support::debug::native::trace!(
       target: LOG_TARGET,
       "[{}] ending end_session({}) with rebase",
       <frame_system::Module<T>>::block_number(),
       end_index
      );
                    T::Rebase::rebase();
      Self::end_session(end_index)
     }
    }

    vault in milestone 2 should achieve:

    To check this, vault module should have these test functions:

    Oracleโ€‹

    oracle will replicate the pallet-staking module regarding election of the oracle provider and the reward logic. However, there will be difference in how the elected provider(or validator) is allocated to the slot. The module only accepts the stash account to submit oracle data once validate() tx has been finalized.

    For example, there will be addition in the select_and_update_validators function code

    /// Select the new validator set at the end of the era.
     ///
     /// Runs [`try_do_phragmen`] and updates the following storage items:
     /// - [`EraElectionStatus`]: with `None`.
     /// - [`ErasStakers`]: with the new staker set.
     /// - [`ErasStakersClipped`].
     /// - [`ErasValidatorPrefs`].
     /// - [`ErasTotalStake`]: with the new total stake.
     /// - [`SnapshotValidators`] and [`SnapshotNominators`] are both removed.
     ///
     /// Internally, [`QueuedElected`], snapshots and [`QueuedScore`] are also consumed.
     ///
     /// If the election has been successful, It passes the new set upwards.
     ///
     /// This should only be called at the end of an era.
     fn select_and_update_validators(current_era: EraIndex) -> Option<Vec<T::AccountId>> {
      if let Some(ElectionResult::<T::AccountId, BalanceOf<T>> {
       elected_stashes,
       exposures,
       compute,
      }) = Self::try_do_election() {
       // Totally close the election round and data.
       Self::close_election_window();

       // Populate Stakers and write slot stake.
       let mut total_stake: BalanceOf<T> = Zero::zero();
       exposures.into_iter().for_each(|(stash, exposure)| {
        total_stake = total_stake.saturating_add(exposure.total);
        <ErasStakers<T>>::insert(current_era, &stash, &exposure);

        let mut exposure_clipped = exposure;
        let clipped_max_len = T::MaxNominatorRewardedPerValidator::get() as usize;
        if exposure_clipped.others.len() > clipped_max_len {
         exposure_clipped.others.sort_by(|a, b| a.value.cmp(&b.value).reverse());
         exposure_clipped.others.truncate(clipped_max_len);
        }
        <ErasStakersClipped<T>>::insert(&current_era, &stash, exposure_clipped);
       });

       // Insert current era staking information
       <ErasTotalStake<T>>::insert(&current_era, total_stake);

       // collect the pref of all winners
       for (i, stash) in elected_stashes.iter().enumerate() {
                    <Slots<T>>::insert(i, stash.clone()); // allocating slots for elected oracle provider
        let pref = Self::validators(stash);
        <ErasValidatorPrefs<T>>::insert(&current_era, stash, pref);
       }
                

       // emit event
       Self::deposit_event(RawEvent::StakingElection(compute));

       log!(
        info,
        "๐Ÿ’ธ new validator set of size {:?} has been elected via {:?} for era {:?}",
        elected_stashes.len(),
        compute,
        current_era,
       );

       Some(elected_stashes)
      } else {
       None
      }
     }

    Also, slash module function should include verifier from milestone 1.

    /// Slash the validator for a given amount of balance. This can grow the value
     /// of the slash in the case that the validator has less than `minimum_balance`
     /// active funds. Returns the amount of funds actually slashed.
     ///
     /// Slashes from `active` funds first, and then `unlocking`, starting with the
     /// chunks that are closest to unlocking.
     fn slash(
      &mut self,
      mut value: Balance,
      minimum_balance: Balance,
            slot: SlotIndex,
     ) -> Balance {
      let batch = Prices::get(_id).unwrap();
      let value = batch[_slot as usize];
      let det = Self::determine_outlier(batch, value);
      ensure!(det, Error::<T>::NotOutlier);
      let pre_total = self.total;
      let total = &mut self.total;
      let active = &mut self.active;

      let slash_out_of = |
       total_remaining: &mut Balance,
       target: &mut Balance,
       value: &mut Balance,
      | {
       let mut slash_from_target = (*value).min(*target);

       if !slash_from_target.is_zero() {
        *target -= slash_from_target;

        // don't leave a dust balance in the staking system.
        if *target <= minimum_balance {
         slash_from_target += *target;
         *value += sp_std::mem::replace(target, Zero::zero());
        }

        *total_remaining = total_remaining.saturating_sub(slash_from_target);
        *value -= slash_from_target;
       }
      };

      slash_out_of(total, active, &mut value);

      let i = self.unlocking.iter_mut()
       .map(|chunk| {
        slash_out_of(total, &mut chunk.value, &mut value);
        chunk.value
       })
       .take_while(|value| value.is_zero()) // take all fully-consumed chunks out.
       .count();

      // kill all drained chunks.
      let _ = self.unlocking.drain(..i);

      pre_total.saturating_sub(*total)
     }
    }

    Unit test

    Unit tests are all identical with the staking module's test in that all logics are identical regarding slash, reward and validation.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0c.DocumentationDocumentation will introduce how to nominate
    1.Vault moduleVault module will declare dependancy injection trait to use session callback in pallet-staking module and the test code with separate SessionManager implementation will be provided
    2.Modified Staking modulepallet_staking module which has two config trait for rebase callback and oracle staking callback will be provided
    3.Oracle modulesame as staking module including curve integration but difference in slot allocation and separate slashing verifier will be included
    4.Unit test codeUnit test codes in tests.rs in each runtime module with separate SessionManager implementation
    5.DockerWe will provide a dockerfile to demonstrate the full functionality of Standard protocol chain

    Future Plansโ€‹

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/Starry_Network.html b/applications/Starry_Network.html index 2531f907ccc..b58b50f7d80 100644 --- a/applications/Starry_Network.html +++ b/applications/Starry_Network.html @@ -4,13 +4,13 @@ Starry Protocol | Web3 Foundation Grants - +
    Skip to main content

    Starry Protocol

    • Proposer: Starry Network
    • Payment Address: 0xe29DE8c6088d241647e6456F8b4755a3D0f7c8B1

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    It is well known that most NFTs are traded either directly or by auction, and the single NFT limit the flexibility of NFTs in some ways.

    Splittable NFT will bring liquidity, lower barriers to entry and more possibilities to NFT ecosystem. For example, buying SubNFTs on bonding curve will allow for better pricing of works, while NFTs that are otherwise very expensive can be collected by more people, it is also possible to purchase a group of NFT tokens and contribute to the management of this group of NFTs.

    Starry provides some solutions for splittable NFTs, such as: splitting Single NFT into some SubNFTs, splitting Single NFT into some fungible tokens, and splitting a group of NFTs into some fungible tokens and managing them using dao.

    Project Detailsโ€‹

    The Starry Protocol contains four parts: Pallet_NFT, Pallet_SubNFT, Pallet_EX, Frontend

    Architectureโ€‹

    Pallet_SubNFT

    An NFT Wrapper to split NFTs into SubNFTs or fungible tokens, or a set of NFTs into fungible tokens( without DAO). Here is demo page.

    Pallet_NFTDAO

    Split a set of NFTs into fungible tokens and manage the NFTs in a DAO way, such as adding more NFTs or selling NFTs. Here is demo page.

    Pallet_EX

    exchange NFT (including buying SubNFTs with bonding curve/one price) and send royalties generated by each transaction to the creator. Here is demo page.

    FrontEnd

    Interaction with users. Here is a demo

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Poria - Full-stack Developer

    Contactโ€‹

    • No Legal Entity

    Team's experienceโ€‹

    Poria

    • Full-stack Developer
    • Expertise in using JS, PHP, Python, Rust
    • Have written blockchain with DAG structure in JS

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2.5 months
    • Full-time equivalent (FTE): 1
    • Total Costs: 10000 DAI

    Milestone 1 Example โ€” Implement Substrate Modulesโ€‹

    • Estimated Duration: 2.5 months
    • FTE: 1
    • Costs: 10000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache License 2.0
    0b.DocumentationDocuments containing the description of whole architecture design for Starry
    0c.Testing GuideProvide a full test suite and guide for NFT. The code will have unit-test coverage (min. 70%) to ensure functionality and robustness.
    0d.Article/TutorialWrite an article or tutorial that explains the work done as part of the grant on medium.
    1a.Node RepoComplete the deployment of the basic public chain
    2a.Pallet_SubNFTComplete the development of pallet_subNFT, relize the split, transfer, burn and recover mechanism
    2b.Pallet_NFTDAOComplete the development of Pallet_NFTDAO, relize the split NFTs, and dao mechanism
    2c.Pallet_EXComplete the development of pallet_ex, relize the bonding curve and one price mechanism
    3.Front EndComplete the development of the basic interactive page in React, the demo is demo
    5.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain
    6.PSPAdd a Polkadot Standards Proposal about Splittable NFT

    Future Plansโ€‹

    • Implementing auction functions (English auction, Dutch auction).
    • Adding auctions to NFT DAO.
    • Add comments, favorites and data analysis to Starry to improve the Starry ecosystem.
    • Simplify the usage process and make NFT more friendly to newcomers.
    • Implementing cross-chain transmission NFT.
    • Lead the community to hold online exhibitions and comment on good NFT works, using tokens to promote these beneficial behaviors.

    Additional Information โž•โ€‹

    • What is the difference between SubNFT and Erc-1155?

      erc-1155's multiple NFT is Semi-fungible tokens, these tokens use same token_id.

      SubNFT splits single NFT into different NFTs, each SubNFT has its own token_id. As a result, subNFT is even rarer and suitable as a collector's item.

      For example, we can use Semi-fungible tokens to create general admission tickets for a concert, and then use SubNFT to create commemorative tickets.

    • What is the difference between SubNFT and Erc-721?

      subNFT is also erc-721 token

    • Perhaps you may be confused with how nft dao works, here is an example to explain it:

      Alice created the token named DOGE with a set of NFTs related to the Doge meme, but she did not want to manage this set of NFTs herself, so Alice created the Doge NFTS DAO.

      Bob was very happy with Doge and created NFT related to Doge, at this time he saw Doge NFTS DAO, so he thought it would be a great thing to put his work into this DAO, so he launched a proposal with this NFT and hoped to get 2000 DOGE in return.

      Charlie likes Doge-related NFTs and holds many DOGE. One day, Charlie saw an NFT that he thought would be helpful for the appreciation of DOGE, so he bought it on Starry and then initiated a proposal in DAO to add the NFT and hoped to get 1500 DOGE to make up for the loss (of course he could have done without the 1500 DOGE).

      Dave was an active participant in the Doge NFTS DAO and when he looked at the proposals he saw Bob and Charlie's proposals and thought they were great proposals, so Dave used a certain DOGE to agree to both proposals.

      Since most people agreed with Bob and Charlie's proposal, the proposed NFTs were added to the NFTs managed by the DAO and the corresponding DOGEs were minted for Bob and Charlie.

    - + \ No newline at end of file diff --git a/applications/StorageHub.html b/applications/StorageHub.html index 23041a15bcb..ef191f3c384 100644 --- a/applications/StorageHub.html +++ b/applications/StorageHub.html @@ -4,13 +4,13 @@ StorageHub Grant Application | Web3 Foundation Grants - +
    Skip to main content

    StorageHub Grant Application

    • Team Name: Moonsong Labs
    • Payment Address: USD Wire Preferred
    • Level: 3

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    • Tagline Describer

      • StorageHub is a decentralized storage public good parachain optimized for file based storage and larger data sets that are not suitable to be stored directly in standard parachain storage. The proposed parachain will provide developers in the Polkadot ecosystem with an alternate decentralized and substrate-based storage solution and functionality.

    • Purpose

      • The goal of this project is to provide storage for web3 applications and protocols within the Polkadot & Kusama ecosystems. Unlike other storage protocols that focus on end user or enterprise storage scenarios, StorageHubโ€™s feature set optimizes for web3 application storage use cases. StorageHub aims to provide a decentralized storage option that allows web3 applications to store large files and large data sets in a cost efficient way without sacrificing decentralization properties.

    • Problem

      • Storage oriented chains, like Filecoin and Arweave, have emerged to provide more efficient and decentralized storage capabilities. However, these chains are standalone chains, and are not designed to interoperate with other chains. The problem is that web3 apps need smart contract logic and compute to be combined with storage to make a complete solution, but smart contracts and compute generally reside on different chains (e.g. Ethereum Mainnet, L2 rollups, Parachains) vs. on the storage optimized chains (Filecoin, Arweave). In response, these storage chains have tried to bolster their smart contract capabilities (e.g. Filecoinโ€™s FVM, Arweaveโ€™s Smartweave), but they have and will continue to be hard pressed to convince all compute and smart contract activity to migrate to their chains.

      • The ideal scenario would be to combine smart contract execution from e.g. a Substrate based Polkadot parachain such as Moonbeam or Astar with storage from a storage optimized chain like Arweave. If we look at NFT scenarios as an example, this is happening. The scenario is that you have an NFT contract on Mainnet, that has a pointer to a JPEG via an Arweave URL. The problem is that this is a one-way pointer between 2 independent systems. It is up to the application to mediate interactions between the 2 chains in the client. There is no awareness or connection between the contract and the JPEG other than the URL pointer in the contract. What if the contract could update access to and ownership of the actual data itself? What if the contract could read and act on the data stored? Simple functionality like this would open up a large number of new scenarios. End user UX could be substantially improved by removing the need for the user to understand and interact directly with both the contract and the storage blockchains, using potentially different accounts, keys, etc.

    • Vision

      • StorageHub is a storage optimized parachain that is designed to work with other Polkadot & Kusama parachains. It focuses on storing data in an efficient and decentralized way, while allowing that storage to be accessed, used, and managed by other parachains. It will be possible for users to directly interact with the storage on the chain, but StorageHub also seeks to natively interoperate with existing parachains via XCM.

    • Inspiration

      • Amazon S3

        • (https://en.wikipedia.org/wiki/Amazon_S3) was a key building block of web2 cloud infrastructure that greatly eased and improved data storage in web2 applications. With S3 devs could store arbitrarily large amounts of data in their apps without needing to get bogged down with storage infrastructure or scaling concerns. StorageHub seeks to do something similar for web3 devs building on Polkadot.

      • Filecoin

        • (https://filecoin.io/) is a storage optimized chain that creates a 2 sided marketplace of storage providers and storage consumers. The project is responsible for key innovations such as ipfs and libp2p, among other things. In many ways filecoin sets the standard for decentralized storage in the web3 space. Although the protocol seems focused on trying to compete with cloud and other centralized storage providers.

      • Arweave

        • (https://www.arweave.org/) is a storage optimized chain like filecoin, but that emphasizes permanent storage vs creating a time based storage marketplace. Users pay once to store data on arweave forever. It is popular to use for metadata associated with NFTs, among other things.

      • Project Greenfield

        • (https://github.com/bnb-chain/greenfield-whitepaper/blob/main/README.md) is a storage optimized chain designed to work with the BNB chain. It was born out of practical needs that the state of BNB chain is already many terabytes large and there is a need to offload unnecessary storage from the main BNB chain. There are lots of good cross chain ideas in Greenfield including having storage on Greenfield represented as NFTs on BNB chain which can be managed and whose ownership can be changed.

    Project Detailsโ€‹

    • Design and Implementation Principles

      • StorageHub will be a Substrate-native implementation deployed to both Kusama and Polkadot.
      • It will be a public good chain that uses DOT for fees, governance, and other utilities.
      • It will offer native XCM support such that parachains can interact with stored data and metadata in a trustless way..
      • End users and Dapps should be able to store and retrieve stored data from the chain.
      • The chain will create a 2 sided marketplace of storage providers and storage consumers.
      • A minimum of N copies of any given piece of data should be stored such that the system can survive the loss of some copies without losing the original dataset. Erasure encoding or similar technique could be optionally used to achieve this.
      • On the tradeoff spectrum between decentralization vs performance, we opt to always maintain good decentralization properties even if that means less performance is possible.
      • There will need to be a network of storage providers that supply storage to the blockchain.
      • The parachain will track metadata about the data being stored, and facilitate payments between the data owner and the storage provider.
      • A set of metadata associated with any stored data will be managed by StorageHub. This will allow the data owner to control access, and to transfer ownership of the data to other parties.
      • StorageHub doesnโ€™t aim to have smart contract functionality itself. Rather it strives to integrate, work with, and complement other smart contract or native parachains.
      • In creating the design for StorageHub, we will leverage previous research into polkadot and substrate based filestorage solutions such as:

    • Key Questions and Anticipated Challenges

      • Existing storage networks focus more on storage but less on user accessibility to that data. But storage without accessibility isnโ€™t that useful to users. Can we incorporate outside accessibility guarantees into the protocol?
      • What type of storage will it provide? Only immutable hash/value type or will it support mutable references (like a filesystem, useful to store/manage a web service or page)
      • What kind of XCM interaction (API) do we want to support?
        • XCM (mostly HRMP) costs may make some scenarios prohibitive.
        • Given the costs of XCM, to what degree does it make sense to store metadata on StorageHub vs on the controlling chain?
      • What do sustainable economics look like for storage providers, especially given that a public good chain wonโ€™t have a token to help bootstrap this side of the market?
      • How is data provided and stored without increasing PoV? This will most likely need to be a combination of offchain workers and a separate storage system. Regular substrate state canโ€™t be used for larger data storage, it would be used to keep tracking information about where and what data is stored.
      • What does this new data provider node look like and how does it work with other node types supporting the system?
      • How will the system ensure that enough copies of a given piece of data are present and available, given that storage provider nodes can go offline at any time.
      • How is it checked that data providers have the data they are being paid to store? What are the consequences of failing this check?
      • How do you manage censorship of data?
        • Different kinds of data that could be subject to take down requests. Data that e.g. a political party doesnโ€™t like. Data that is illegal in a given jurisdiction due to copyright or similar. Data that is both illegal and morally offensive.
        • Perhaps OpenGov tracks could be used for censorship takedowns.
        • Or data storage providers could be given censorship controls, and a permissionless staking design would make it so token holders could vote out providers that are out of line with community censorship standards.

    Ecosystem Fitโ€‹

    • Where and How Does StorageHub Fit In

      • There are currently no native Polkadot decentralized storage solutions and StorageHub aims to fill that gap.
      • Crust provides an incentive layer on top of existing storage protocols like ipfs. Whereas StorageHub seeks to be a storage provider itself.
      • StorageHub will be natively accessible by other parachains via XCM.

    • Target Audience

      • StorageHub is targeted for chains, contracts, teams and individuals that require data storage of larger datasets, and who value that storage being decentralized, censorship resistant, and permanent as long as storage fees are paid.
      • StorageHub will prioritize web3 developers that want to incorporate decentralized storage into their applications. This means a focus on APIs, SDKs, developer docs and education.
      • StorageHub will secondarily provide a reference application which allows users to directly interact with the system, storing data and managing data storage.

    • Use Cases

      • NFT, NFT marketplace, and Metaverse metadata storage
      • Dapps that require data storage
      • Personal and enterprise data storage - same as other storage chains.
      • DAO owned data assets - DAOs operating on existing parachains can manage access to and ownership of data assets on StorageHub.
      • โ€œTrueโ€ NFTs that can have the entirety of their associated data assets on-chain via a combination of an e.g. NFT contract and StorageHub stored assets.
      • Markets for data sets using NFT marketplaces.
      • New types of smart contracts that can act on StorageHub stored data on an one off or continuous basis

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Team Leader: Derek Yoo
    • Team:
      • Alan Sapรจde
      • Chase Williams
      • Olivia Smith
      • Engineers to be hired

    Contactโ€‹

    • Registered Address: 1500 District Ave Burlington, MA 01803
    • Registered Legal Entity: Delaware C Corp

    Team's experienceโ€‹

    • The Moonsong Labs protocol engineering team has deep expertise in Substrate, EVM, cross chain technologies, and launching parachains on Kusama and Polkadot. Our team is the core engineering team for the Moonbeam Network and have made significant contributions to the ecosystem, such as contributions to Frontier, the Moonwall testing framework, parachain-staking pallet, and xcm tools. The engineering team is made up of 13+ engineers and is rapidly growing.ย 

    • Team Example Code Repos:

    • Team LinkedIn Profiles:

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 Months
      • Milestone #1: 1 Month
      • Milestone #2: 1 Month
    • Full-Time Equivalent (FTE): 2.5
    • Total Costs: $84,500 (USD)

    Milestone #1: Research & Designโ€‹

    • Estimated duration: 1 Month
    • FTE: 2.5
    • Costs: $42,250 (USD)
    NumberDeliverableSpecification
    0a.Copyright and LicensesCC BY 4.0 / GPLv3
    0b.Research & Investigation Understand and clarify key requirements via conversations with key stakeholders
    Study existing solutions and designs to see what technologies and approaches can be leveraged vs. being created
    Research decentralized storage competitive projects, including but not limited to Filecoin, Arweave, Sia, Storj as well as existing storage work in the Polkadot ecosystem
    Examine trade offs other decentralized storage providers have made including, but not limited to retrieval times, small v. large files, resiliency, cost efficacy, security & privacy, redundancy, user learning curve and environmental sustainability
    Begin to design features compatible with Polkadotโ€™s technical approach and philosophy
    The research & design document will include the gathered requirements and the list of researched solutions & features that could meet those requirements, as well as all supporting evidence and documentation that led to those proposed requirements and features. The document will also expand its research on the โ€œKey Questions and Anticipated Challengesโ€ section
    0c.Feature Analysis In depth research of the technical feasibility of key features and components
    Evaluation of proposed feature sets, inclusive of a detailed compatibility/tradeoff matrix leading to a clearly defined set of proposed StorageHub features
    Stakeholders will be asked to provide feedback on those compatibility/tradeoffs and to help choose a good combination of features
    Definition and documentation of key use cases and scenarios
    0d.Article* The main deliverable for the first month is v0.5 of the research & design document. The research and design document will include the feature analysis, proposed MVP feature set including key use cases, and address the points in (0b.) and (0c.)

    Milestone #2: Technical Deliverablesโ€‹

    • Estimated Duration: 1 month
    • FTE: 2.5
    • Costs: $42,250 (USD)
    NumberDeliverableSpecification
    0a.License TypeCC BY 4.0 / GPLv3
    0b.Documentation For the second milestone we will provide v1.0 of the research & design document. The v1.0 document will include a high level technical design & architecture of StorageHub, including major subsystems, incorporating and building upon research from the first v0.5 milestone
    This v1.0 research and design document will be shared with key stakeholders to obtain specific feedback that will help us continue to refine StorageHub
    * In addition to this, we will also begin to build prototype code that supports and tests the v1.0 technical design considerations. A basic tutorial will be included that explains how a user can run our prototype code and send test transactions
    0c.Testing & Testing Guide Software developed for this milestone will be prototype quality, and thus will not have the tests required for production deployment. However, the prototype code will be sufficient to demonstrate viability or compatibility of key aspects of the design approach
    As outlined in (0b.), a basic tutorial will be included that explains how a user can run our prototype code and send test transactions
    0d.Docker* We will provide a Dockerfile(s) that can be used to run the prototype associated with this milestone
    0e.Prototype Code We will create a Substrate and or RUST prototype to validate proposed designs described in the v1.0 design doc. In particular, the approach for the data provider role, and being able to store data in a redundant fashion, and retrieve data from the provider
    The source code for the prototype will be delivered as part of the second month milestone. The prototype will have limited features (e.g. not decentralized, limited API, etc) or might not be complete but will provide sufficient functionalities to demonstrate key parts of the proposed design
    * We will provide a Dockerfile(s) that can be used to run the prototype associated with this milestone
    0f.Resource Estimation & Planning Estimate the time, budget, and resources required to implement a minimum viable feature set for the project
    Break down the feature into smaller tasks or user stories
    Create a proposed project plan that includes implementation milestones, and responsibilities
    Include proposed next steps in the research and design doc
    0g.Article The main deliverables for this milestone are defined as below
    Progressing the v0.5 document to a v1.0 state outlined in section (0b.)
    A Substrate and or RUST prototype to validate proposed designs described in the v1.0, outlined in section (0e.)
    A basic tutorial will be included that explains how a user can run our prototype code and send test transactions outlined in section (0c.)

    Future Plansโ€‹

    • We are currently in the process of hiring fulltime resources that will be dedicated to this engineering effort.
    • The intended long term plan is to successfully complete this initial grant to then set us up to apply for a follow on long term grant
    - + \ No newline at end of file diff --git a/applications/Stylograph.html b/applications/Stylograph.html index 7eb1cbec60b..e657c95e722 100644 --- a/applications/Stylograph.html +++ b/applications/Stylograph.html @@ -4,13 +4,13 @@ Pallet Stylograph | Web3 Foundation Grants - +
    Skip to main content

    Pallet Stylograph

    • Team Name: GenesisDAO by Deep Ink Ventures GmbH
    • Payment Address: Ethereum Mainnet, 0x918a4363C35156c8F85F86795a79189e5A1ef557, USDC
    • Level: 3

    Overviewโ€‹

    Stylograph [ stahy-luh-graf, -grahf ]

    A writing instrument for applying ink to paper.

    Stylograph is a framework aimed at enhancing the functionality of substrate-based chains in the Polkadot ecosystem with plugin-like functionality.

    By using the ink! programming language, third party developers can extend the core functionality, while focussing on the domain logic.

    The total ask for this proposal is $100,000 and it is planned to have a subsequent development to use this functionality within Genesis DAO (see the last grant, future plans section).

    Project Detailsโ€‹

    Introductionโ€‹

    A group of people surrounding Ken Thompson and Dennis Ritchie were quite busy at Bell Laboratories shaping the world as we know it today. They invented a milestone in programming languagesโ€Šโ€”โ€ŠC, the breakthrough operational system Unix, the first shell, UTF-8 and a long list of others that alone would have been enough to receive a Turing award.

    How were they so productive? Of course, the density of talent at Bell Labs was as high as within the Beatles (before John married)โ€Šโ€”โ€Šbut one tiny detail helped drive them. And that can be summed up in one word: focus. Finding out what holds the application together in its innermost folds and excelling at that. It takes writing programs that do one thing and do it well. Today, this set of guiding principles is popularly known as the Unix philosophy.

    This fundamental building block of system design is what guides Substrate development today. The Polkadot ecosystem is a set of domain-specific chains that focus on building the infrastructure for the web3 universe.

    The ink! programming language can be run on Substrate chains, either as a core value proposition - with the chain being an ecosystem for protocols developed in ink! on top of it - or as second class citizens - with protocols being able to build on top of the domain logic.

    Stylograph introduces a third use-case by utilizing ink! as a configuration language to alter the domain specific language itself by introducing a simple and straightforward framework to inject loosely-coupled hook points into your pallets that will call smart contract functionality in registered contracts on the contracts pallet.

    Motivationโ€‹

    Deep Ink Ventures is building a system parachain for the Polkadot ecosystem that is building infrastructure for Decentralized Autonomous Organizations - Genesis DAO.

    At Genesis DAO we are committed to the Unix philosophy.

    We focus on the DAO management with the core components of creating and running DAOs, overseeing token issuance and DAO treasury and having a rock-solid proposal and voting infrastructure.

    However, DAOs can have small and granular requirements that do require small tweaks and adjustments. Sometimes on-top protocols like Yield Aggregators require additional functionality. Some of those changes may be deal breaking for technical use cases or legal reasons and therefore a hard requirement for newly founded DAOs.

    The core team ultimately has to decide what features are reasonably part of an unbloated core and there is no one-size-fits-all solution to a lot of problems. This is where Stylograph comes to the rescue.

    Framework Components Overviewโ€‹

    The following is an overview of the architecture we build and is merely to sketch the scope and general concept. Implementation details may vary.

    pallet_stylographโ€‹

    This pallet acts as an abstraction layer on top of pallet_contracts in order to conveniently create callback based implementations.

    The pallet will have initial support for ink!. The concept is easily extendable for other languages such as Solidity or ask! that can be added.

    image

    Since Substrate does not know about the structure of smart contracts deployed in ink! beforehand, Substrate developers utilizing Stylograph need to register the function signature they want to support for callbacks.

    This is a one-liner in the chain specs:

    Stylograph is now aware of a function given by signature, function name or trait definition and knows its associated gas limit.

    image

    With the callback defined, the core developers now can add callback functions into their pallets that extension developers can utilize.

    For example, the function above may alter the original vote in order to come up with a more complex algorithm (and it is therefore valuable to carefully select the arguments for the callback function for extension developers to be flexible).

    An example might be something like this:

    image

    The next part is the registration of extensions by accounts - the second argument given in the callback above.

    The Substrate node implementation can decide how they want to interpret this - e.g. if the extensions are per account or if the account represents an entity on the chain. The latter is true for Genesis DAO where the account needs to be the owner of the DAO. Each DAO can register its own hookpoints to tweak the core to its needs.

    image

    The framework now has all the information at hand to execute a fully abstracted _pallet_contracts::bare_call _and to handle errors associated with it:

    1. The user calls the extrinsic of the implementing pallet. In the case of GenesisDAO that might be the dao_votes pallet to intercept the voting process in order to alter the majority voting to a different decision system.
    2. This pallet executes the callback that takes the information given from the dao_votes panel and looks up the callback definitions registers.
    3. It constructs a call to the ink! contract defined.

    image

    The gas fees are therefore called by the person utilizing the functionality - the user calling the initial extrinsic.

    ink! Stylograph Facade Builderโ€‹

    The aforementioned information is enough to automagically generate a full boilerplate contract as template that Substrate chain developers can use to deploy a sample contract and to write a macro that defines the interface that the runtime expects.

    This contract can be released to the extension developer community to use as a boilerplate template. They can as well import the trait for the contract to be sure that they are compatible with the specs defined by the runtime.

    image

    We therefore are building a CLI tool to package a versioned ink! crate with installation steps and base documentation that can be published with a new runtime release of the chain to give protocol and extension developers a headstart to extension development. Both the chain and the contract will depend on those traits as dependency to identify the interface.

    image

    Additional Developmentโ€‹

    As this is planned to be part of our to-be-planned-system-parachain, we are as well pushing the development of the main chain within this proposal.

    Token Transferโ€‹

    Currently we rely on wallet extensions and polkadot.js.org to transfer DAO tokens around that reside on Genesis DAO. We have a primitive frontend UI in our MVP but would like to expand this to a more user friendly interface.

    We have already created some designs to show the direction, but this would include full wireframes, designs + additions to our backend services and, of course, the dApp:

    image

    Council Managementโ€‹

    Weโ€™ve already created the multisignature part of council and treasury management within our product / wireframe and design department and want to roll out a Gnosis Safe - Style interface for this as part of the treasury management.

    We are using pallet_multisig for this and currently council members need to go via polkadot.js.org, not the most user friendly interface in the world.

    This would again include the full wireframes, desings and code changes in the backend and frontend. We have already implemented the multisig part.

    image

    DAO Dashboard Add-Onโ€‹

    We are createing a few designs to make the DAO Dashboard more friendly and intuitive for users and want to do the frontend implementation as well as the respective adjustments to the APIs of our backend service.

    image

    Ecosystem Fitโ€‹

    While we have drafted this pallet with the next iteration of the Genesis DAO chain in mind (here are some planned plugins and extensions for inspiration), the presented functionality is carefully abstracted into a reusable component system.

    Stylograph is to Substrate what plugins and and extensions were for CMS, Shops in web2 - a smooth way for third parties to extend the core functionality for a chain. It enables Substrate developers to concentrate on doing their domain logic well whilst their users and protocols building on top maximize flexibility and time-to-market.

    You can think of this as the inverse to chain extension. While chain extension gives plugins a way to interact with the underlying core logic, stylograph gives chain developers an easy framework to make their core extendable with plugins and extensions via smart contracts. They can be used by any chain that wants to have a growing extension ecosystem.

    Teamโ€‹

    Contactโ€‹

    • Deep Ink Ventures GmbH, registered with the commercial register at the local court of Berlin, HRB 247342

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4-5 month
    • Full-Time Equivalent (FTE): 3-4 FTE
    • Total Costs: $ 100,000

    Development Status ๐Ÿ“–โ€‹

    The development will happen on https://github.com/deep-ink-ventures/genesis-dao-node as we test the functionality in a full chain, but the pallet will be released as it's own crate.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Milestone 1โ€‹

    • Estimated duration: 3 month
    • FTE: 3-4
    • Costs: 70,000
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a can integrate the pallet and start working with
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.BenchmarkingWe will provide benchmarking & weights for the pallet
    0e.State of the art Tech StackWe will use next.js/react for all frontend components, python / django for the backend services and rust for developing the substrate components
    1.Pallet DevelopmentDevelop the pallet as specified within the pallet_stylograph section above.
    2.Frontend Integration: Dashboard Add-OnDevelop full wireframes and designs + Frontend, Backend integration, deployed on https://genesis-dao.org.
    3.Frontend Integration: Token TransferDevelop full wireframes and designs + Frontend, Backend integration, deployed on https://genesis-dao.org.

    Milestone 2โ€‹

    • Estimated Duration: 2 month
    • FTE: 3-4
    • Costs: 30,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a can integrate the pallet and start working with
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.State of the art Tech StackWe will use next.js/react for all frontend components, python / django for the backend services and rust for developing the substrate components
    1.Facade BuilderDevelop the code generator for smart contracts as specified above in the ink! Stylograph Facade Builder section.
    2.Refrence ImplementationWe will provide a sample implementation alongside with pallet_contracts on the Genesis DAO test chain to demonstrate the functionality.
    3.Frontend Integration: Councils ManagementDevelop full wireframes and designs + Frontend, Backend integration, deployed on https://genesis-dao.org.

    Future Plansโ€‹

    Our future plan is to include (and therefore maintain and extend) this pallet within our Genesis DAO Chain. The exact game plan is laid out here.

    - + \ No newline at end of file diff --git a/applications/SubDAO-Chrome-Extension.html b/applications/SubDAO-Chrome-Extension.html index 202c8d3442e..d88f229ecf9 100644 --- a/applications/SubDAO-Chrome-Extension.html +++ b/applications/SubDAO-Chrome-Extension.html @@ -4,7 +4,7 @@ SubDAO Chrome Extension | Web3 Foundation Grants - + @@ -21,7 +21,7 @@ This project can provide a wallet for every parachain and dapp. Also, it will provide DAO management features for all DAO members. At last, it will provide social features for everyone who wants to try web 3.0.

  • What need(s) does your project meet?
    The project meets at least two needs. The first one is a better wallet as an extension of browsers. The other one is a tool that provides a smooth experience for DAO management.

  • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

    • There are no similar projects in the Polkadot ecosystem yet, and even we already have several wallets for Polkadot. There is a similar project like Aragon in the Ethereum ecosystem compared to SubDAO, but there is no chrome extension with wallet integrated yet. Also, there is Maskbook in the Ehtereum ecosystem that provides features to post encrypted messages on different social networks. The SubDAO Chrome Extension is mainly built for the Polkadot ecosystem and provides wallet, social network, and DAO management features.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    The team is the one who applied SubDAO.

    Qiang

    Marvin Tong

    Dajun

    John Xie

    Tallone

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    The DAO-related smart contracts are partially implemented in the SubDAO plan. Those contracts can be found in https://github.com/SubDAO-Network/subDAO-contracts.

    We have already designed some UI/UX as the shown previous section, and the full extension relies on the features provided by SubDAO. Milestone 1 of SubDAO is already finished and accepted.

    Development Roadmap ๐Ÿ”ฉโ€‹

    In the first milestone, we planned to make the SubDAO Chrome Extension be useable for every parachain. The following features will be available:

    The wallet Feature provides the wallet-related features for the chains in Substrate / Polkadot / Kusama ecosystem, including mnemonic management, send and receive tokens, etc.

    The DAO provides GUI to interact with SubDAO directly in extension without opening any webpage in browser; also, it includes voting now in social network posts.

    The Social Network provides the feature to post encrypted messages on Twitter and Facebook. We modify the encryption method from the original idea.

    Overviewโ€‹

    Milestone 1 - The first published versionโ€‹

    NumberDeliverableSpecification
    0a.LicenseAGPL
    0b.DocumentationWe will provide a basic tutorial that explains how a user can install our chrome extension.
    0c.Testing GuideWe will provide a testing guide on how to use our chrome extension
    0d.ArticleWe will publish an article describing our chrome extension and how to use it.
    1.Source CodeThe extension will be implemented in JavaScript. We will provide the source code of this extension which will provide the 1) features for wallet, such as 1.1) mnemonic management, 1.2) adding custom tokens, 1.3) transfer token from one account to another and 1.4) supporting tokens on Polkadot/Kusama, 2) features to 2.1) post encrypted messages on social network such as Facebook and Twitter, 3) features for DAO management, such as 3.1) listing current available DAOs, 3.2) listing my DAOs, 3.3) create vote in my DAOs, 3.4) do voting in my DAOs and 3.5) view vote results in DAOs.
    2.Build instructionWe will provide a doc about building this chrome extension from source code.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We get this information from the w3f website.

    - + \ No newline at end of file diff --git a/applications/SubDAO_Network.html b/applications/SubDAO_Network.html index 90ba788efee..b019ae504bd 100644 --- a/applications/SubDAO_Network.html +++ b/applications/SubDAO_Network.html @@ -4,13 +4,13 @@ SubDAO | Web3 Foundation Grants - +
    Skip to main content

    SubDAO

    • Proposer: SubDAO Labs
    • Payment Address: 3FcJjvzazcpgmJkesdAfx333fyCudxuAe7

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Introductionโ€‹

    SubDAO is a Cross-chain Platform built by SubDAO Labs to link DAO and DApp on Polkadot. It will be the infrastructure to maintain DAO and to connect DApp with DAO in the world of Web3.0 powered by Substrate and Polkadot.

    The SubDAO will run as a parachain to provide specific services. The various DAO templates and SubDAO Airfone will alleviate the burden on developers to maintain DAOs and to create very DApps linked with DAOs.

    The initial governors of a DAO can easily create a cross-chain DAO by only a few clicks without any tech skills at all. Developers who are willing to build DApps can give the governance to communities by using SubDAO to create the very DAO connected to DApp through SubDAO Airfone.

    Integrationโ€‹

    SubDAO is a customized chain based on the Substrate 2.0 Framework and will run as a parachain on Polkadot. The OCW (Off-chain Worker) provides the ability to access the off-chain world, which would empower the DAOs to access external data rather than only On-chain data, such as the price of stable coins, the contributions on Github, and so on.

    Team Interestโ€‹

    The initial members of the SubDAO Labs team are big fans of Web3.0 technology. They come from different areas, ranging from full-stack developer, product manager, project management to cryptocurrency early adopters. DAO is the ideal governance model in the mind of the team. Creating and maintain a DAO is not so easy, especially to make a DAO working across different chains. But with the help of Substrate 2.0 and Polkadot, the team thinks it is the time now.

    Creating a DAO is not a new thing to the guys involved in the blockchain world, just like shooting a man to the Moon is not news to the fiction novel readers nor people. But the opportunity for everyone to easily travel forth and back between the Moon and the earth is making a big difference! All the team trying to do is to build a cheap, reliable, and fast enough vessel for people to travel between the Moon and the earth even further between Mars and the Earth. The team wants to provide a cheap, reliable, and fast enough way to let everyone being able to create DAOs and DApps across different chains.

    Project Detailsโ€‹

    Architectureโ€‹

    With the state-of-art technology, SubDAO Labs can achieve the goal based on Substrate 2.0 and the Polkadot. The SubDAO project contains SubDAO node, Template Library, SubDAO Guard, Asset Vault, SubDAO Airfone, and Front End.

    img

    • SubDAO Node is the customized chain node for the SubDAO network built by Substrate 2.0. It's the fundament of the SubDAO network that contains the basic functionalities as a normal chain node but also provides the ability to fetch external data needed for DAO governance with the OCW (Off-chain Worker) from Substrate 2.0 Framework.

    • Template Library is the key component of the SubDAO network. It is comprised of multiple contracts. The main functionalities of Template Library are managing and providing various DAO Templates for different types of organizations. Everyone has the right to define new DAO Templates according to their needs, and the SubDAO network provides some default DAO Templates such as Voting Template, Fund Template, VC (Venture Capital) Template and so on.

    • SubDAO Guard is the original DAO of the SubDAO network. It provides basic management functionalities. Every member of the SubDAO network can get involved in the SubDAO network governance through SubDAO Guard.

    • Asset Vault is the smart contract providing the basic features of manage assets for each DAO. Working together with DAO Template, the Asset Vault manages all kinds of assets, including the assets needed by creating a new DAO, the assets deposited by the governors of a DAO, and other assets.

    • SubDAO Airfone is the SDK for developers to connect their DApps with the DAOs created by themselves or others. It will be provided as a Javascript library at the beginning, and in other languages later. Developers can use the SubDAO Airfone to interact with the SubDAO network directly or built their DApps with the connection to DAO.

    • Front End provides Web UI for everyone to interact with the SubDAO network. All the users need to do is open the webpage deployed by the SubDAO Labs team or by users themselves and click the buttons following the manual. Front End will provide such functionalities as creating a new DAO, define a new DAO template, withdraw personal assets, voting in DAO, and so on. Front End will be built with NodeJS.

    • SubDAO Token $SDT is the native token of the SubDAO Network, and it will play the role of governance and other utilities. $SDT is necessary to secure and power the SubDAO Network. The SubDAO Network may hold an IPO and reward community members for helping our auction with $SDT tokens during the Parachain Auction.

    Scenariosโ€‹

    • Scenario to Create a New DAO
      img

    As shown above, the steps to create a new DAO are marked. The DAO governor calls the smart contract of the SubDAO Guard to choose a proper DAO template from the DAO Template Library. After the governor fills the basic information required by template such as name, description, the rules of governance, initial members, and so on and deposits the initial fund to the Asset Vault, the SubDAO Guard contract will create the very DAO according to the chosen template and filled information. All extra information, such as images, texts, and files, will be stored in a decentralized storage network like IPFS.

    • Scenario to Attend a New DAO
      img

    Generally speaking, there are two kinds of ways to interact with DAO contracts. The first way to get involved with a specific DAO is using the Front End created by the SubDAO Labs to interact with all the DAOs on the SubDAO Network. The second way is using the SubDAO Airfone. The SubDAO Airfone will hide all the details of calling smart contracts for users and is used by DApps since the developers of DApps can customize their scenario according to their needs.

    The Open SDKโ€‹

    Our ultimate goal is to provide an essential open SDK (the SubDAO Airfone) from a high-level perspective together with the above components, fully powering the ecosystem of DAO across chains on Polkadot. With the functionality of the Open SDK, anyone involved can utilize DAO and DApp.

    The benefits of an open SDK are beyond criticism. The Open SDK will be an extension of both the DAO's capabilities and the value of the DApps through the whole Polkadot universe. We hope to build a framework whereby any Decentralized Autonomous Organizations can live, and any Decentralized Apps can use in the Polkadot ecosystem.

    Substrate / Polkadot Integrationโ€‹

    The whole SubDAO Network builds on top of the Substate 2.0, and the Polkadot ecosystem is essential to what SubDAO Network is trying to achieve. The SubDAO Network will be connected to the Polkadot ecosystem as a parachain, sharing the Polkadot underlying consensus, and protected by the network performance of Polkadot and Substrate.

    The off-chain worker is a new feature in the Substrate Framework that allows the SubDAO Network to interact with off-chain data.

    The node in the SubDAO Network is built with OCW (Off-chain Worker) enabled. The figure below shows how it will work with external data (for example, the contributions on Github).

    img

    In the figure above, the SubDAO Node includes an OCW pallet that interacts with external HTTP service (Github Http Wrapper). Since the OCW pallet is a general component, most of the processing work of external data is moved out of OCW to decrease the complexity of implementation and give the ability to the DAO governors who wanna use specific data sources for their DAO. The external HTTP service (Github Http Wrapper) will fetch the data such as contributions for a user in a project or repository from Github.com and feed the OCW pallet in the SubDAO Node.

    All smart contracts mentioned above will be implemented with Ink or EVM. Since the SubDAO Node includes OCW (Off-chain Worker), Ink is essential due to Ink is the only way to interact with pallets currently. Thanks to Ethereum, Solidity is widely used over several years, and most of the developers are already familiar with EVM. So in the SubDAO Network, most of the smart contracts will be implemented using EVM to decrease the difficulties for new developers on the Polkadot ecosystem.

    img

    As shown above, those contracts interacting with pallets will be implemented with Ink, and others will be with EVM. Later in future versions, when developers get familiar with Ink, the whole project will upgrade to use Ink only.

    For EVM, we will choose Frontier as the evm pallet.

    The Pallet Implementationโ€‹

    The function provided by the pallet to get off-chain data is requestOffchainData.

    1. requestOffchainData

    • desc: smart contract requests the off-chain data, the SubDAO network nodes will send data to the SubDAO chain through OCW integrated later.
    • params: HTTP wrapper URL, JSON params
    • return: dataId

    Ecosystem Fitsโ€‹

    In the area of Decentralized Autonomous Organizations, there are many mature DAOs maintained in different ways with different tools or platforms, such as Maker, The DAO, and The LAO. Also, there are some other tools to help governors building a DAO, such as Aragon. Aragon is a project providing tools to create and the governor a DAO, but only available on Ethereum.

    SubDAO is quite different and evolved from other DAO related projects. The goal of SubDAO is to create a (1) cross-chain platform providing (2) general and customized functionalities to govern a DAO (3) connecting to DApp with the ability to (4) access off-chain external data.

    Team ๐Ÿ‘ฅโ€‹

    Team Membersโ€‹

    • Qiang - CTO/Project Lead
    • Marvin Tong - Product Director
    • Dajun - System Architect/Substrate Developer
    • John Xie - Full-stack Developer
    • Tallone - Full-stack Developer

    Team Websiteโ€‹

    No Legal Entity

    Team Experienceโ€‹

    Qiang

    • Over 13 years of experiences in Software Development
    • Chief Solution Architect in Tencent
    • Former Team Lead in IBM
    • Core Developer of Smart Cloud / HSLT
    • Code Contributor of KVM
    • Community Contributor in RedHat

    Marvin Tong

    • Founder and CEO of Phala Network
    • Former Product Manager in Tencent
    • Former Product Manager in DiDi

    Dajun

    • Over 12 years of experiences in Development
    • Former Senior Software Engineer in Alibaba
    • Core Developer of Wetez and StaFi.io

    John Xie

    • Full-stack Developer
    • Over 15 years of experiences in Development and Management
    • Has plenty of experience in Software Development and Blockchain Development
    • Currently, focus on Cross-chain technologies

    Tallone

    • Full-stack Developer
    • Over 20 years of experiences in Product Development and Management
    • Has plenty of experience in Software Architecture
    • Currently focused on Blockchain Development and Cross-chain Technologies

    Team Code Reposโ€‹

    Team Linkedin Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-time equivalent (FTE): 4
    • Total Costs: 0.9 BTC

    Milestone 1 โ€” Verify Production of Concepts (POC) and Implement Substrate Modulesโ€‹

    • Estimated Duration: 2 months
    • Full-time Equivalent (FTE): 4
    • Costs: 0.9 BTC

    In the first milestone, the features for the PoC will be implemented and tested by limited users.

    The following features will be included:

    • SubDAO Node with OCW to fetch simple data
    • Template Library with basic functionalities
    • SubDAO Guard
    • Default Voting Template
    • Asset Vault
    • Front End

    The implementation of off-chain workers of the Substrate Framework will be built and validated. The designed off-chain data is the contributions on Github.

    NumberDeliverableSpecification
    0a.LicenseApache License 2.0
    0b.DocumentationDocuments containing the description of whole architecture design for SubDAO Network.
    0c.Testing GuideWe will provide a full test suite and guide for the POC.
    1.SubDAO Node RepoSubDAO Node is built on top of Substrate 2.0 as a customized module written in Rust will use the very consensus protocol. A new pallet using OCW will be implemented to fetch off-chain data as designed to provide such data for DAOs.
    2.Ink! ContractsContracts will be developed with ink!
    2a.SubDAO Template LibraryThe SubDAO Template Library contract maintains SubDAO Templates. All DAOs can be created by using the templates in this library. The default templates will be provided, and the custom template will be supported in the future version.
    2b.SubDAO GuardAnother set of contracts to maintain the SubDAO (the original DAO for the SubDAO Network). Any community member can get involved through SubDAO Guard at any time.
    2c.SubDAO Voting TemplateThe very basic template supported by the SubDAO network, and it's the first template included by the SubDAO template library.
    2d.SubDAO Asset VaultIt's the contract to provide assets management functionalities for all DAO. It's the initial vault for SubDAO itself.
    3.Front EndThe webpage provides all the functionalities for the SubDAO network except the off-chain worker and will be implemented with polkadot.js in NodeJS.
    4.Docker ImageThe SubDAO Network docker image contains the POC version running anywhere to verify the idea of the SubDAO Network.
    5.Medium PostsArticles will be post on medium to expose this project.

    Community Engagementโ€‹

    SubDAO's future community engagement strategies include:

    • Publish more articles on Medium and other leading media channels to expose our project.
    • Launch an Ecosystem Development Lead Program to recruit and get more contributors involved in our project.
    • Join Polkadot related on-line and off-line events in the Polkadot community to expose our project.
    • Bounty Program for General Community to attract more people into our project.
    • DApp Hackathon to get more DAOs and developers.

    Future Plansโ€‹

    Marketing and Community Plansโ€‹

    • The SubDAO Network will run as a parachain of the Polkadot Network.
    • Hire 3-4 more developers in the next two months, and set up our core dev team.
    • Hire 1 marketing adviser to set up our marketing team.
    • Support DAOs for the Polkadot network.

    Development Plansโ€‹

    • In phase 1, our goal is to achieve all the designed functions and provide the basic voting for all DAOs.
    • In phase 2, more DAO templates will be implemented, such as the Fund Template and the VC (Venture Capital) Template, and the SubDAO Airfone will be included for developers to connect their DApps with DAOs.
    • In phase 3, the SubDAO Network begins to provide services for any kind of DAO with customized DAO templates while we plan to release a new version with low-cost functionalities to the public.
    • Finally, our goal is to provide the essential platform with the Open SDK to facilitate the ecosystem on Polkadot.

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/SubDAO_PolkaSign.html b/applications/SubDAO_PolkaSign.html index ab5195379af..a95045a4ae2 100644 --- a/applications/SubDAO_PolkaSign.html +++ b/applications/SubDAO_PolkaSign.html @@ -4,7 +4,7 @@ PolkaSign | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ Anyone who need sign contract with others, include indivaduals, companies, DAOs and other kind of organization.

  • What need(s) does your project meet?
    The project meets the need of signing contract with decentralization, immutability, and transparency. It provides the way for DAOs to sign contracts with DAO members and contributors.

  • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

    To sign a contract with the help of blockchain technologies is not fresh. There are similar projects in the Ethereum ecosystem, such as OpenLaw, EthSign. But there is no similar project in the Polkadot ecosystem yet. PolkaSign is the first one to provide electronic agreement signing for individuals, companies, and DAOs.

    • Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    The team is the one who applied SubDAO.

    Qiang

    Marvin Tong

    Dajun

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    We have already designed some UI/UX as the shown previous section, and the rest works will be done in next two months.

    Development Roadmap ๐Ÿ”ฉโ€‹

    We planned two major versions.

    Version 1: The goal of first version is to provide a usable PolkaSign, the users can upload PDF agreement files and co-sign with other signers. It contains the features of store agreement files in decentralized storage, sign contract with smart contract, sharing the contracts waiting for sign.

    Version 2: The goal of second version is to provide a common PolkaSign for other substrate chains. To co-work with other chains to integrate PolkaSign.

    Overviewโ€‹

    In this application, we planned to provide the first version of PolkaSign. The main features are 1) store agreement files in decentralized storage, 2) sign contract with smart contract and 3) sharing the contracts waiting for sign. It will contains smart contract with ink!, web app as client and codes to interact with decentralized storage system.

    Milestone 1 - The first usable versionโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a basic tutorial that explains how to use.
    0c.Testing GuideWe will provide a testing guide on how to test it.
    0d.ArticleWe will publish an article describing our ideas.
    1a.PolkaSign ClientPolkaSign Client will be implemented as web app.
    1b.PolkaSign Smart ContractPolkaSign Smart Contract will be implemented with ink!. The Unit tests of contracts will be included.
    2.Build instructionWe will provide a guide of building PolkaSign from source code.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We get this information from the w3f website.

    - + \ No newline at end of file diff --git a/applications/SubGame_Network.html b/applications/SubGame_Network.html index 039da701081..d3419d11841 100644 --- a/applications/SubGame_Network.html +++ b/applications/SubGame_Network.html @@ -4,7 +4,7 @@ SubGame Network | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ modules

    Scenariosโ€‹

    transfer

    As shown above, we will realize the chip exchange of $SGB in the first stage, and the ETH exchange in the later stage, and the chips of each address can also be freely transferred

    playgames

    Players can build their own games or participate in other peopleโ€™s games. Each game has a gameplay designed in the pallet-gametemplates. The first pallet-gametemplates will be continuously designed and adjusted during the first development stage.

    First Game Templateโ€‹

    Ecosystem Fitโ€‹

    At present, there is no real decentralized game platform, but more decentralized games. Unlike the past, this time we are going to build a truly decentralized game ecological platform.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    No Legal Entity

    Team's experienceโ€‹

    Shanfeng Xie

    QiangKai

    ZheSheng

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 : The testnet is completed and the first playable game template is builtโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationDocuments containing the description of whole architecture design for SubGame Network.
    0c.Testing GuideWe will provide a full test suite and guide for SubGame node manage and game template library api.
    1a.SubGame NodeProvide node compilation and installation instructions, start the test network
    2a.pallet-chipsThe Chips module has been developed and you can use Chips to participate in the game
    Storage:Chips get(fn get_chips): map hasher(blake2_128_concat) T::AccountId => u32;
    Function:1)pub fn transfer_chips(origin,chips:u32)->dispatch::DispatchResult

    2)pub fn sgt_to_chips(origin,pay:T::Balance)->dispatch::DispatchResult
    2b.pallet-gametemplatesComplete the basic module design and development of the template library, and complete the first game template
    Storage:Templates get(fn get_templates): Vec<Template>;

    TemplateMap get(fn get_templatemap):map hasher(blake2_128_concat) u32 => Template;
    Functions:No public function
    2c.pallet-gamecenterManagement of Game Template instances
    Storage:CurrentGameinstances get(fn get_gameinstances): map hasher(blake2_128_concat) u32=> Vec<GameInstance>;

    HistoryGameinstances get(fn get_gameinstances): map hasher(blake2_128_concat) u32=> Vec<GameInstance>;

    PlayMap get(fn get_playmap): map hasher(blake2_128_concat) AccountId=> u32;
    Functions:1)pub fn play_game(origin, instance_id:u32, chip:u32,data:u32)->dispatch::DispatchResult

    2)pub fn create_game(origin, template_id:u32)->dispatch::DispatchResult
    2d.pallet-gametemplates-guess-hashcomplete the first game guess hash template
    Storage:Games get(fn game_list): map hasher(blake2_128_concat) T::GameIndex => <GameInfo>;

    BetList get(fn bet_list): map hasher(blake2_128_concat) T::GameIndex => Vec<BetInfo>;

    GameCount get(fn game_count): T::GameIndex;

    DrawMap get(fn draw_map): map hasher(blake2_128_concat) T::BlockNumber => Option<T::GameIndex>;
    Struct:GameInfo <Owner, BlockNumber, DrawBlockNumber, Amount>

    BetInfo <Account, GameIndex, Amount, GameMode>
    Functions:No public function
    3a.Front EndIn the first stage, the basic development of the game center will be completed, and the first core game interaction process will be completed
    3b.UI mock-upshttps://www.figma.com/file/hbwDsOVkP5tJqCnl7v0Smr/Subgame-center
    3c.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    3d.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain and front end

    Future Plansโ€‹

    Marketing and Community Plansโ€‹

    Development Plansโ€‹

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/SubGame_Network_m2.html b/applications/SubGame_Network_m2.html index e9954c54050..1a7eb31d521 100644 --- a/applications/SubGame_Network_m2.html +++ b/applications/SubGame_Network_m2.html @@ -4,7 +4,7 @@ SubGame Network m2 | Web3 Foundation Grants - + @@ -24,7 +24,7 @@ We will provide this game A pallet to users for lease. This is a sample pallet. There will be more pallets that can be leased in the future. This kind of pallet will use pallet-lease to control func permissions in func. Functions

    - `demo(NftId) -> DispatchResult`: Using this function will check the lease pallet, if there is no permission, it will display `Error::PermissionDenied`.
    - `call_success(NftId) -> count`: Record the number of successful call func.
    - `call_fail(NftId) -> count`: Record the number of fail call func.

    Ecosystem Fitโ€‹

    At present, there is no real decentralized game platform, but more decentralized games. Unlike the past, this time we are going to build a truly decentralized game ecological platform.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    No Legal Entity

    Team's experienceโ€‹

    Shanfeng Xie

    QiangKai

    ZheSheng

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 2 : Build a module leasing platformโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationDocuments containing the description of whole module leasing platform.
    0c.Testing GuideWe will provide testing methods for lease module.
    1a.pallet-leaseYou can use this pallet to lease assets and control lease-related permissions.
    1b.pallet-stake-nftYou can use this pallet to generate exclusive NFT tokens for other pallets.
    1c.pallet-nftWe replicate this NFT Pallet in order to comply with our lease platform.
    1d.pallet-gameAThis is a sample game module for display on the lease platform.
    2a.Front EndWe will provide a user interface for users to use, so that users have a good experience. This part will also be included in the dockerfile.
    2b.UI mock-upshttps://www.figma.com/file/7ZUQSuAfNrrmq5s3LSIFik/SubGame?node-id=3649%3A62086
    2c.TutorialWe will also provide tutorials on how to use the client.
    2d.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain and front end

    Future Plansโ€‹

    Marketing and Community Plansโ€‹

    Development Plansโ€‹

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/SubIdentity.html b/applications/SubIdentity.html index 2e6cb4ba951..ff245fff3c0 100644 --- a/applications/SubIdentity.html +++ b/applications/SubIdentity.html @@ -4,7 +4,7 @@ SubIdentity | Web3 Foundation Grants - + @@ -14,7 +14,7 @@

    Technology Stackโ€‹

    Ecosystem Fitโ€‹

    This project is meant to provide an Identity Directory for all substrate-based chains, that implement the Identity pallet.

    Similar Project

    What makes us different

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    We have years of experience in bringing ideas to life with a user-centered focus using blockchain and mobile technology. We have worked closely with a large number of customers to implement their solutions and therefore have already gained experience with blockchain technologies. Our most relevant projects are among others:

    We look forward to contributing to the web3 ecosystem with an open source project next.

    Team Code Reposโ€‹

    Source code will be in:

    Team profiles:

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    RFP

    A concept and initial design was created as part of this application and can be found in the Project Details chapter.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Design and Implementation of the Basic Applicationโ€‹

    A basic application with a responsive design is developed which supports querying by address and identity fields. A user can query identities from Polkadot or Kusama. When a search returns multiple results a list view is displayed. If there is only one search result or one identity is selected from the list view, a detailed identity view is displayed.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use the application.
    0c.TestingCore functions will be covered by unit tests as far as reasonably applicable to ensure functionality and robustness. In the documentation, we will describe how to run these tests.
    1.Concept and designWe will create a high-fidelity, responsive, pixel perfect design for a search, a list view and a detailed identity view
    2.Implement logic for querying identitiesImplement logic to receive identities from a substrate-based chain implementing the Identity pallet
    3.Implement UI for search and list viewBuild UI with Vue.js
    4.Implement UI for detailed identity viewBuild UI with Vue.js

    Milestone 2 - Offline mode and performance improvementโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and update the basic tutorial that explains how a user can use the application.
    0c.TestingCore functions will be covered by unit tests as far as reasonably applicable to ensure functionality and robustness. In the documentation, we will describe how to run these tests.
    1.Implement offline modeEnable a user to connect to a local node and fetch identities from there
    2.Implement UI for node selectionEnable a user to select the node from the UI
    3.Implement URL param logicURL Parameters can specify which cards are visible and in which order
    4a.Performance improvementFocus on improving the web applications performance to maximize usability e.g. by storing fetched information from a local node to IPFS if a users pinata key was provided
    4b.Backend DevelopmentImplement backend with e.g. Node.js to increase performance through indexing; Provide an API for frontend
    4c.Consume APIUse the provided API in frontend to increase performance

    Milestone 3 - Implementation of default plugins and direct interactionโ€‹

    A flexible, expandable and component-based application is developed, that supports the following default plugins: basic info, governance, treasury and validator. It is possible to directly interact with the underlying account by sending tokens to it. Manual and automated quality assurance is done.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and update the basic tutorial that explains how a user can use the application.
    0c.TestingCore functions will be covered by unit tests as far as reasonably applicable to ensure functionality and robustness. In the documentation, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains what was done as part of the grant.
    1a.Implement logic for default plugins - backendImplement logic to get information for default plugins governance, treasury and validator on backend, provide API for frontend
    1b.Implement logic for default plugins - frontendImplement logic to to get information for default plugins governance, treasury and validator; Consume provided API
    2.Implement components for displaying default pluginsImplement UI for displaying default plugins
    3.Implement logic for sending tokensImplement logic to get balance of current account and make a transaction to displayed identity; consider transaction fees; use an open protocol (e.g. wallet connect) to establish a secure connection to a wallet
    4.Implement UI for sending tokensImplement UI for sending tokens, including a button to trigger a transaction, an input field and a display of balances and fees
    5.Quality AssuranceManual and automated QA

    Future Plansโ€‹

    After we have provided a flexible, expandable and component-based application with the above-mentioned functions as part of milestones 1, 2 and 3, the development of further components as plugins could follow, as suggested in the RFP in the Additional Plug-in Ideas chapter. In addition, TDSoftware can undertake maintenance tasks as part of a maintenance grant.

    Additional Information โž•โ€‹

    This is our first application for an open source project to innovate the web3 Ecosystem.

    - + \ No newline at end of file diff --git a/applications/SubsCrypt.html b/applications/SubsCrypt.html index e2edee53d74..41fe1d4bbe1 100644 --- a/applications/SubsCrypt.html +++ b/applications/SubsCrypt.html @@ -4,7 +4,7 @@ SubsCrypt | Web3 Foundation Grants - + @@ -25,7 +25,7 @@ We have designed a secure and user-friendly auth mechanism that users and providers can easily use it.

    Users have to choose a pair of token and passphrase, which we recommend having a common token(more than 16 chars) in every provider that they subscribe but have a different passphrase(can be small). Users will submit sha256(token+passphrase) to the contract, and whenever they want to authenticate themselves, they have to provide these token and passphrase in a view function( which is not a transaction, so it's not on-chain and free). They also have to once set their sha256(token+passphrase) for using the SubsCrypt dashboard without a wallet. The authentication with a wallet is checked by the blockchain address sender.

    First milestone: we will design(it is almost done right now) and implement our smart contract, and we will also design XD files of UI, and we will write our white-paper in this milestone(including the test unit).

    The main functions that will be deployed on the chain in this milestone are as follow:

    FunctionDescriptionParamsReturnsState mutability
    addPlanThis function is for providers to add their plans; each plan has duration, price, max refund percent that they are willing to lock in contract and withdraw after that the subscription period has finished.list of durations, list of prices, list of max refund percentNonechange state
    editPlanThis function is for providers to edit their plan. (Old subscriptions are not affected by this change)index of their plan, new duration, new max refund percent, new priceNonechange state
    changeDisableThis function is for providers to edit their plan that changes the active or deactivate status of their plan(so people can or can't subscribe in that plan)plan indexNonechange state
    subscribeThis payable function is for users to subscribe to their desired service and plan; they have to provide a hash of their password (the auth mechanism will be explained thoroughly in Auth Section) and provider address and plan index and some metadata that is encrypted by the public key of the provider(users can trust providers to share their data with but nobody else can know that data)provider address, plan index, the hash of pass, An optional encrypted metadataNonechange state(payable)
    refundThis function is for users to refund their subscribe anytime they want and instantly withdraw the rest of their money(maximum amount of refund is indicated by max refund percent that provider had set for that plan)provider address, plan indexNonechange state
    withdrawThis function is for providers to withdraw the amount that is now ready to withdraw(this is the money that we lock in the contract when a user subscribes to a plan according to max refund percent, and when their plan is finished, that money can be withdrawn). We used an optimized LinkedList solution, which is really cheap to execute and fast.Noneamount of money you are paidchange state
    checkSubscriptionThis function is for users or anyone to check that if a user has an active subscription in a specific plan of a provideraddress of the user, address of provider, plan indexreturn booleanview
    checkAuthThis function is used to check if the given combination of token and passphrase can authenticate a specific user for a provider(the auth mechanism will be explained thoroughly in Auth Section)address of the user, address of provider, token, passphrasereturn booleanview
    retrieveWholeDataWithPasswordThis function is used to get every subscription record of a user with their token and passphrase, which first have to be set in setSubsCryptPass function(this token and passphrase is only worked to login in SubsCrypt website to have a whole review of your account)address of the user, token, passphrasereturn whole records of a userview
    retrieveWholeDataWithWalletThis function is the same as the above function with a slight difference that it is used with user wallet to trigger the contract directlyNonereturn whole records of a userview
    retrieveDataWithPasswordThis function is used to get every subscription record of a user only related to a specific provider with their token and passphrase is set once they subscribe to their chosen plan of that provideraddress of the user, address of provider, token, passphrasereturn whole records of a userview
    retrieveDataWithWalletThis function is the same as the above function with a slight difference that it is used with user wallet to directly trigger the contractaddress of providerreturn whole records of a user-related to that providerview

    Second milestone: we will implement the UI Dashboard(Vue.js) and UI modules(ES6 and pure js) regarding our XD design in the previous milestone.

    Third milestone: Implementing our RestAPI backend in Node.js to provide an API layer to interact with our contract(it is optional to use this API), we will also implement our third-party libraries for Django and node.js to interact with our backend and implement the required functionality to make the integration for developers easier(including test unit).

    Overviewโ€‹

    Milestone 1 โ€” Smart Contractโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    1.Contract Implementationwe will implement the contract and deploy it to a test net.
    1.1Contract codeimplementation of contract
    1.2High-level APIwe will provide an API of contract
    1.3Documentationfull documentation of API that explains how to connect to and use it.
    1.4Testing GuideThe code will have unit-test coverage (100%) to ensure functionality and robustness. In the guide, we will describe how to run these tests
    2.ArticleWe will write an article or tutorial that explains the work done in this milestone as part of the grant.
    3.Design Front-End componentdesign UI and UX of front-end component with adobe xd.
    4.white-paperfull description of roadmap and technical specification of this project
    5.Polkadot Standards Proposals (PSPs)we will pull request a PSP in this milestone containing our implementations

    Milestone 2 โ€” UIโ€‹

    NumberDeliverableSpecification
    1.UI DashboardA dashboard to manage user's subscriptions and also refund them
    1.1UI Dashboard for usersA dashboard to manage user's subscriptions and also refund them
    1.2UI Dashboard for adminsA dashboard to manage user's customers and create a coupon or see related charts, etc.
    2.ES6 Module for developersDevelopers can use this module to integrate our service into their websites
    2.1Implementation of ES6 Module for developerswe will write an ES6 Standard module
    2.2Documentation of ES6 ModuleWe will provide both inline documentation of the code and a basic tutorial that explains how a developer can integrate our module into their projects
    3.Unit TestWe will provide unit tests to cover our ES6 Module

    Milestone 3 โ€” Back-end librariesโ€‹

    NumberDeliverableSpecification
    1.Backend RestAPIwe will provide a RestAPI to facilitate the connection to blockchain. it will be used to check the subscription or retrieve any data from the contract.
    1.1Backend RestAPI Implementationwe will provide a RestAPI to facilitate the connection to blockchain. it will be used to check the subscription or retrieve any data from the contract.
    1.2Backend RestAPI DocumntaionA fully comprehensive documentation to use our RestAPI
    1.3Backend RestAPI Unit testThe code will have unit-test coverage (100%) to ensure functionality and robustness.
    2.Third Party librariesWe will provide some library to make integration of our service easier in different backend stacks by connecting to our Backend RestAPI
    2.1Node.js LibraryA high-level library to use our service in Node.js
    2.2Node.js Library documentationA fully comprehensive documentation to use our library
    2.3Node.js Library Unit testThe code will have unit-test coverage (100%) to ensure functionality and robustness

    Future Plansโ€‹

    when we finish this project successfully, then we will try to make our substrate pallet to become a standalone blockchain, and if everything goes well, we will try to be a PolkaDot parachain.

    Works currently Doneโ€‹

    Modal Component UI dashboard
    - + \ No newline at end of file diff --git a/applications/Subsembly-GRANDPA.html b/applications/Subsembly-GRANDPA.html index 92291f24b59..d51de9a8a52 100644 --- a/applications/Subsembly-GRANDPA.html +++ b/applications/Subsembly-GRANDPA.html @@ -4,7 +4,7 @@ Subsembly - Support for GRANDPA | Web3 Foundation Grants - + @@ -15,7 +15,7 @@ 2) Having support for the Runtime-to-Consensus Engine Messages 3) Implementing required modules/pallets (session, offences)

    Project Detailsโ€‹

    Runtime APIsโ€‹

    Subsembly must implement the following Runtime APIs to have full support for GRANDPA:

    Runtime-to-Consensus Engine Messagesโ€‹

    GRANDPA utilises consensus digest items for various events. The following is a list of the digest items emitted related to GRANDPA: Untitled (20)

    Scheduled Change & Forced Change

    Every pallet/module has an on_finalize hook that is called whenever a block is finalised. In the case of GRANDPA, once the on_finalize is called, the Runtime must check whether there is a PendingChange (forced or scheduled) that must be deposited. If there is - a new DigestItem of type Consensus with the GRANDPA_ENGINE_ID must be added in the block.

    On Disabled

    The ConsensusLog is deposited once the Session module calls the on_disabled method. The GRANDPA module must simply deposit the log whenever it is called from the Session module.

    Public Functionsโ€‹

    The following public functions, eligible for calling from the client side are:

    Dependencies & Prerequisitesโ€‹

    It is important to note that GRANDPA relies on the Session, Offence and minimal Staking modules. The Session module is configured to have a certain range of blocks and every time on_initialize is called, the module checks whether the session should end. If it has to end, the module rotates the session changing the validators.

    The offences module tracks reported offences and the Staking module must provide the implementation of the offence - slashing the users for their misbehaviour.

    Ecosystem Fitโ€‹

    Subsembly provides an alternative way for developers to build Runtimes. More specifically, it enables developers with TypeScript/JavaScript knowledge to build on top of the Substrate ecosystem.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    LimeChain is a blockchain development company with 100+ completed projects and strong focus on blockchain development infrastructure. LimeChain has built tools for different protocols and networks such as Ethereum, The Graph, Polkadot, EOS, Aeternity and Corda. Some of the projects LimeChain has worked with are Celo, P&G, Universe.xyz, The Graph, Dapper Labs, Hedera and Maker among others. LimeChain is also embedded into the Polkadot developer ecosystem, particularly with building AssemblyScript developer tools. The team has built a SCALE Codec implementation, Account-based AssemblyScript Runtime PoC and the Subsembly framework.

    Team Code Reposโ€‹

    LimeChain's Substrate related repositories:

    Team's GitHub profiles:

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    The team already spend time on implementing GRANDPA, by updating the Subsembly CLI and spec builder to support GRANDPA authorities configuration. Reference

    Development Roadmap ๐Ÿ”ฉโ€‹

    Described below is a practical approach to the implementation of the GRANDPA module along with the the other auxiliary modules that are required.

    1. Session
      1. Implement session period configuration (n number of blocks)
      2. Implement an on_initialize hook called when the block is initialized. It must check whether the session must end; if it ends, rotate_session is called.
      3. Implement a service for tracking the Historical changes of session keys in order to verify proofs
      4. Implement rotate_session
    2. GRANDPA - Session
      1. Implement on_new_session handler
      2. Implement schedule_change
      3. Implement on_finalize hook
        1. Pending changes added in the state from schedule_change must be deposited as logs.
    3. Session
      1. Implement set_keys method. The extrinsic must be signed. The caller gets their provided keys set into storage for eventual usage in the next sessions
      2. Implement purge_keys method. Removes the session keys of the function caller. Takes effect after the next session starts
    4. GRANDPA - Consensus Messages
      1. Add on_finalize hook - If the current block is X, pending scheduled authority changes for the same block must be executed and an event must be deposited

    At this point, the following features should be supported by the module:

    The last part is to add support for equivocations.

    1. Equivocations - Reporting voter misbehaviour. The reporting of equivocations results in offences and slashe
      1. Implement a service for verifying the equivocation_proofs - verifying the offender keys against the proof
      2. Implement a method for verifying the equivocation proof by making sure that both votes target different blocks and the signatures are valid
      3. Implement Reporting Service for offences that reward the sender
      4. Implement Offences module that tracks offences
      5. Implement minimal Staking module that provides an implementation for slashing on_offence as OffenceHandler

    Overviewโ€‹

    Milestone 1 โ€” Sessionโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 license
    0b.DocumentationWe will provide both inline documentation of the module as-well as update the official documentation of Subsembly.
    0c.Testing GuideDue to the complex nature of testing AS code, functions that have the ability to be unit tested will be fully covered to ensure functionality and robustness. In the guide, we will describe how to run these tests. We will provide testing information as-well - how one can set keys, purge them and verify that the session rotates.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test the functionality delivered with this milestone.
    1.Session periodWe will start the work on Subsembly session module. The end-users will be able to configure the session period configuration through the module. The period will be represented in n number of blocks.
    2.on_initialize hookWe will extend the on_initialize hook to be calling the session's on_initialize logic.
    3.Historical session serviceWe will implement a Historical session service for storing new sessions, starting sessions and ending sessions. The service will have a mechanism for proving that a given validator was part of a session at a given index.
    4.rotate_sessionWe will implement the logic for rotating the session in the context of GRANDPA.
    5.Session set_keys extrinsicWe will implement the set_keys extrinsic. The extrinsic must be signed. The caller gets the provided keys set in to the sotrage for the eventual usage in next the sessions
    6.Session purge_keys extrinsicWe will implement the purge_keys extrinsic. Removes the session keys of the function caller. Takes effect after the next session starts.

    Milestone 2 GRANDPA Iโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 license
    0b.DocumentationWe will provide both inline documentation of the module as-well as update the official documentation of Subsembly.
    0c.Testing GuideDue to the complex nature of testing AS code, functions that have the ability to be unit tested will be fully covered to ensure functionality and robustness. In the guide, we will describe how to run these tests. We will provide testing information as-well - how someone can verify that sessions are being changed, as-well as verify that consensus logs are being deposited.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test the functionality delivered with this milestone.
    1.on_new_session hookWe will create a new GRANDPA module that will implement the on_new_session handler.
    2.schedule_changeWe will implement the schedule_change logic that adds a Pending Change into the state.
    3.on_finalize hookWe will implement the on_finalize hook that will be called once a block is finalized and will check whether there are pending changes that must be set deposited as consensus logs.

    Milestone 3 GRANDPA II - Equivocationsโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 license
    0b.DocumentationWe will provide both inline documentation of the module as-well as update the official documentation of Subsembly.
    0c.Testing GuideDue to the complex nature of testing AS code, functions that have the ability to be unit tested will be fully covered to ensure functionality and robustness. In the guide, we will describe how to run these tests. We will provide testing information as-well - how someone can cause equivocation by a malicious node and verify that he is receiving a reward.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a guide in the Subsembly docs file, how one can run their Substrate node that uses Subsembly Runtime having GRANDPA enabled.
    1.GRANDPA equivocation_proofs serviceWe will implement a services for verifying the equivocation_proofs - verifying the offender keys against the proof. Method for verifying the equivocation proof by making sure that both votes target different blocks and the signatures are valid.
    2.reporting serviceWe will implementa reporting service for offences that reward the sender.
    3.offences moduleWe will implement an offences module that tracks offences.
    3.Minimal staking moduleWe will implement a minimal staking module that provides an implementation for slashing on_offence as OffenceHandler

    Future Plansโ€‹

    LimeChain will be resolving any critical bugs that may arise. We would like to extend the framework by adding new pallets in the future. Our plan is to continue the development of the framework with support for BABE and after that, having support for Parachains. The end goal of Subsembly is to support the full set of foundational features that enable developers to create Substrate networks (with the option for both Aura and BABE + GRANDPA's finality) as-well as Polkadot parathreads and parachains.

    Additional Information โž•โ€‹

    LimeChain has been a long time contributor to the Substrate ecosystem mainly focused on developer tooling. Due to our involvement in the space we are working with various clients, developing smart contracts and working on parachains.

    - + \ No newline at end of file diff --git a/applications/Substrate_Move_System_Pallet_1.html b/applications/Substrate_Move_System_Pallet_1.html index b397571b381..298deb27bf7 100644 --- a/applications/Substrate_Move_System_Pallet_1.html +++ b/applications/Substrate_Move_System_Pallet_1.html @@ -4,13 +4,13 @@ Substrate Move System Pallet (part 1) | Web3 Foundation Grants - +
    Skip to main content

    Substrate Move System Pallet (part 1)

    • Team Name: Eiger
    • Payment Address: Fiat 14.04.2023, 16:50 UTC+3
    • Level: 3

    Project Overview **๐Ÿ“„**โ€‹

    This application is a response to the Move Smart Contract Pallet RFP.

    Overviewโ€‹

    Some terminology first:

    • Substrate Move System Pallet - A Substrate system pallet that can be used as a building block for substrate-based chains, it exposes interfaces to interact with the Move virtual machine.

    • Substrate Move - A Move language fork that is Substrate compatible.

    Objectives:

    • The goal is to provide a Substrate system pallet that allows to deploy and interact with Smart Contracts written in the Move language, by providing a Move Virtual Machine (MoveVM) as a pallet.
    • We plan on exploring a fork of the Move language, so itโ€™s adjusted to work with the Substrate ecosystem, as well as developing a Substrate system pallet that allows the execution of Move smart contracts.
    • The project directly improves the growth potential of the Substrate based ecosystem by providing support for one of the most modern smart contract programming languages and VM types out there - Move.
    • We are interested in creating this project because we are firm believers in the modular vision of web3, and only by collaborative efforts on improving and unifying the technology between different chains and the languages, will we get better products as an outcome.

    Goal - Level up the growth possibilities of the Substrate ecosystem by providing a way to develop and execute Move smart contracts on Substrate.

    This is the first phase of a 3-phase development program:

    1. In-Depth Exploration and Assessment of MoveVM and Substrate Integration
    2. MoveVM compatibility work and Subtrate Pallet development
    3. Finalising the Substrate-Compatible MoveVM

    Project Detailsโ€‹

    Prior work

    We are basing the core architecture and many of the design decisions on the Pontem networks developed system pallet for Move VM. They had maintained their own fork of the Diems Move language, which was used as the base execution layer for their version. Both of these repositories have not been maintained for a very long time already.

    โ™ป๏ธ We aren't seeking to maintain any of the existing codebase; rather, we aim for a full revival through a new greenfield project. Our rationale for this stems from the substantial advancements made in the Rust, Substrate, and Move ecosystems since Pontemโ€™s latest commits from over a year ago. We believe that handling potential code rot due to the passage of time might be more labor-intensive than starting afresh and drawing upon existing projects for more current guidelines.

    Documentation of core components, architecture

    1. Substrate Move:

      The first part of the project will be a MoveVM fork, as some major changes will need to be made to the codebase for it to be substrate compatible. For example:

      • no_std compatibility: Making it lightweight and suitable for use in Substrate runtimes.
      • wasm32ย target compatibility: Adapting all the VMโ€™s different components to work efficiently and securely on the wasm32 target architecture.

      We plan on creating and maintaining the fork in a manner that would allow us and the community to easily follow and track changes from the upstream, thus making the maintenance and change tracking to be much simpler.

      At the time of writing this application, we suspect that this will be needed because this is what also Pontem had to do to support it in their version. This will be further researched and assessed during the first milestone.

    2. Move VM system pallet:

      The second part of the project will be a Substrate virtual machine pallet in Substrate. This is a modular component that is needed to integrate a specific new VM into a Substrate runtime. It will serve as a bridge between the runtime and the Move VM, managing resources and translating data or actions between the two environments.

    API specifications

    As a minimum, we plan on providing all of the RPC calls that the Pontem crate did. As the team progresses with the implementation, we might add or remove RPC calls as we best see fit.

    Move language has a concept of โ€œgasโ€ for executing contracts, whereas Polkadot uses โ€œWeightsโ€. Each Move transaction invocation requires providing a gas limit for execution, and itโ€™s necessary to be able to transform the values between weight and gas:

    • mvm_gasToWeight
    • mvm_weightToGas

    Estimating gas for different operations:

    • mvm_estimateGasPublish
    • mvm_estimateGasExecute

    Working with the primitives of the Move language:

    • mvm_getResource
    • mvm_getModuleABI
    • mvm_getModule

    Tech stack

    We plan on using Rust for developing the system pallets and using existing Move language smart contracts for end-to-end testing of the whole workflow.

    Notes

    Because the Move language requires a fork to work with Substrate chains, and modifications to the address size, there might be incompatibilities with deploying existing Move Smart Contracts from other chains that make use of the address properties size, as well as the compiled ABI and bytecode for those contracts might be invalid. To deploy on our MoveVM system pallet, the forked toolchain must be used to re-compile all smart contracts. The address size of Move language is configurable via a feature switch with 32-bits being one of the options.

    Ecosystem Fitโ€‹

    Move is a smart contract programming language that emphasizes access control and scarcity, offering some unique advantages over other popular VMs in blockchain ecosystems.

    The importance of bringing the MoveVM to Polkadot was recognized over two years ago when Pontem Networkย started working on aย Move virtual machine palletย to execute Move smart contracts on Substrate-based chains. Although they discontinued the project and haven't updated the codebase for over a year, the W3F still keeps this RFP, which serves as evidence that porting the MoveVM is crucial for the future of the Polkadot network.

    We concur with this perspective and have actually been actively researching the MoveVM - exactly with a similar idea of helping port it over to other chains.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Roberts Ivanovs (Github,ย Linkedin) is a Rust Software Engineer at Eiger. He has extensive experience using Rust for performance-sensitive backend work, the IoT industry, web development, and Solidity/dApp development.
    • Tomek Piotrowski (Github, Linkedin) Software Engineer at Eiger, specializing in Rust-based applications. With a strong background in software development, he has spent recent years focusing on the Rust programming language. At Eiger, Tomasz actively contributes to the advancement of Rust-based blockchains and their ecosystems.

    Contactโ€‹

    • Registered Address: Linnankatu 3 A 24, 20100 Turku, Finland
    • Registered Legal Entity: Eiger Oy****

    Team's experienceโ€‹

    Web3 promises to upgrade the very foundations of our society โ€“ from money, finance, and governance to media, gaming, and science. To deliver on that promise, decentralised technologies are to be integrated into the everyday experiences of billions of people. For engineering, this is a mountain of a challenge.

    Eiger was founded to develop infrastructure for web3 mass adoption. We help technology companies improve and integrate the core technologies of web3 to meet the climbing demands for scaling and performance.

    We currently employ 25+ senior web3 engineers across the globe and work with some of the most ambitious organisations in the industry, including Forte, Aleo, and XRP Labs, to name a few.

    Team Code Reposโ€‹

    As mentioned in the Teams section, Eiger already has extensive experience developing large infrastructural projects. Some chosen examples:

    Development Status ๐Ÿ“–โ€‹

    We have not yet started our own development, we are still in the research phase.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1 month
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 48 000 USD
    • Starting Date: 10/07/23

    In-Depth Exploration and Assessment of MoveVM and Substrate Integrationโ€‹

    Goal: Research Pontem Move VM solution, Move language and its ecosystem, and document all findings. Prepare a repository for developing the Substrate Move system pallet.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 and MIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleContent: article that explains all of the research and findings done in the research phase, and how it shapes the project in the future. The research would include:
    • analysis of the Pontem Move fork,
    • analysis of the Pontem MoveVM system pallet, evaluating its architecture and design decisions,
    • analysis of the current Move language restrictions, ABI and understanding if forking the language is still necessary,
    • analysis of the potential effects of forking the language and the toolchain if it is deemed necessary.
    Medium: A markdown design decision document in the repository.
    1.System Pallet: Substrate MoveWe will create a Substrate system pallet that will provide the RPC calls as the initial interfaces for interacting with the Move VM. The Move VM port itself will not be implemented, all of the methods will be empty stubs.
    Solid code practices will be in place: CI/CD, tests, documentation, linting, and publication of the library to http://crates.io.
    2.Rust crate: Substrate MoveForking the Move VM if deemed necessary. The alterations would include everything to create the virtual machine Substrate-compatible.
    3.Rust crate: Substrate Move documentationDocumentation of the alteration made for the MoveVM to be Substrate-compatible. Also, the whole process of how it was ported will be described, either in form of markdown documentation or detailed commenting on GitHub issues and PRs.

    Future Plansโ€‹

    This is the first phase of a 3 steps development plan:

    1. In-Depth Exploration and Assessment of MoveVM and Substrate Integration
    2. MoveVM compatibility work and Subtrate Pallet development
    3. Finalising the Substrate-Compatible MoveVM

    The next step will be to submit a grant proposal to continue this work - creating the first iteration of a pallet capable of receiving, storing and executing Move smart contracts.

    We hope that upon the completion of all phases of creating the Substrate Move System Pallet , it will open doors for further collaboration and community input on the project. We strive to have the codebase well documented so that others might join in and contribute.

    While there are no long-term plans set in stone for the usage of this pallet, we have had incredibly exciting discussions about creating a parachain, possibly a common good parachain (system parachain), that utilizes this MoveVM implementation and would run MoveVM contracts. As we near the completion of this initial development, we will be discussing these future plans more in-depth.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    We learned about it when looking at open RFPs by the web3 foundation on their website.

    We wanted to get back up to date on what is happening in the Polkadot ecosystem, and working on grants, specifically RFPs, has been a great way to do so.

    Looking to apply to other RFPs currently open as well. Stay tuned!

    - + \ No newline at end of file diff --git a/applications/Substrate_Move_System_Pallet_2.html b/applications/Substrate_Move_System_Pallet_2.html index f6f5711a04f..7be76b0990a 100644 --- a/applications/Substrate_Move_System_Pallet_2.html +++ b/applications/Substrate_Move_System_Pallet_2.html @@ -4,7 +4,7 @@ Substrate Move System Pallet (part 2) | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Substrate Move System Pallet (part 2)

    • Team Name: Eiger
    • Payment Address: Fiat 14.04.2023, 16:50 UTC+3
    • Level: 3

    Project Overview **๐Ÿ“„**โ€‹

    This application is a response to Move Smart Contract Pallet RFP and a follow-up to our previous work on the RFP.

    Overviewโ€‹

    ๐Ÿ“– Terminology: Substrate Move System Pallet - A Substrate system pallet that can be used as a building block for substrate-based chains, it exposes interfaces to interact with the Move virtual machine. Substrate Move - A Move language fork that is Substrate compatible.

    • The goal is to provide a Substrate system pallet that allows to deploy and interact with Smart Contracts written in the Move language, by providing a Move Virtual Machine (MoveVM) as a pallet.
    • The project directly improves the growth potential of the Substrate based ecosystem by providing support for one of the most modern smart contract programming languages and VM types out there - Move.
    • We are interested in creating this project because we are firm believers in the modular vision of web3, and only by collaborative efforts on improving and unifying the technology between different chains and the languages, will we get better products as an outcome.

    Goal - Level up the growth possibilities of the Substrate ecosystem by providing a way to develop and execute Move smart contracts on Substrate.

    This is the second phase of a 3-phase development plan:

    1. In-Depth Exploration and Assessment of MoveVM and Substrate Integration
    2. MoveVM compatibility work and Subtrate Pallet development
    3. Finalising the Substrate-Compatible MoveVM

    Project Detailsโ€‹

    Prior work

    We are basing the core architecture and many of the design decisions on the Pontem networks developed system pallet for Move VM. They had maintained their own fork of the Diem Move language, which was used as the base execution layer for their version. Both of these repositories have not been maintained for a very long time already.

    โ™ป๏ธ We aren't seeking to maintain any of the existing codebase; rather, we aim for a full revival through a new greenfield project. Our rationale for this stems from the substantial advancements made in the Rust, Substrate, and Move ecosystems since Pontemโ€™s latest commits from over a year ago. We believe that handling potential code rot due to the passage of time might be more labor-intensive than starting afresh and drawing upon existing projects for more current guidelines.

    Documentation of core components, architecture

    1. Substrate Move:

      The first part of the project will be a MoveVM fork, as some major changes will need to be made to the codebase for it to be substrate compatible. For example:

      • no_std compatibility: Making it lightweight and suitable for use in Substrate runtimes.
      • wasm32ย target compatibility: Adapting all the VMโ€™s different components to work efficiently and securely on the wasm32 target architecture.

      We created the fork of Move VM in a manner that allow us and the community to easily follow and track changes from the upstream, thus making the maintenance and change tracking to be much simpler.

    2. Move VM system pallet:

      The second part of the project will be a Substrate virtual machine pallet in Substrate. This is a modular component that is needed to integrate a specific new VM into a Substrate runtime. It will serve as a bridge between the runtime and the Move VM, managing resources and translating data or actions between the two environments.

    API specifications

    As a minimum, we plan on providing all of the RPC calls that the Pontem crate did. As the team progresses with the implementation, we might add or remove RPC calls as we best see fit.

    Move language has a concept of โ€œgasโ€ for executing contracts, whereas Polkadot uses โ€œWeightsโ€. Each Move transaction invocation requires providing a gas limit for execution, and itโ€™s necessary to be able to transform the values between weight and gas:

    • mvm_gasToWeight
    • mvm_weightToGas

    Estimating gas for different operations:

    • mvm_estimateGasPublish
    • mvm_estimateGasExecute

    Working with the primitives of the Move language:

    • mvm_getResource
    • mvm_getModuleABI
    • mvm_getModule

    Tech stack

    We plan on using Rust for developing the system pallets and using existing Move language smart contracts for end-to-end testing of the whole workflow.

    Notes

    Because the Move language requires a fork to work with Substrate chains, and modifications to the address size, there might be incompatibilities with deploying existing Move Smart Contracts from other chains that make use of the address properties size, as well as the compiled ABI and bytecode for those contracts might be invalid. To deploy on our MoveVM system pallet, the forked toolchain must be used to re-compile all smart contracts. The address size of Move language is configurable via a feature switch with 32-bits being one of the options.

    Ecosystem Fitโ€‹

    Move is a smart contract programming language that emphasizes access control and scarcity, offering some unique advantages over other popular VMs in blockchain ecosystems.

    The importance of bringing the MoveVM to Polkadot was recognized over two years ago when Pontem Networkย started working on aย Move virtual machine palletย to execute Move smart contracts on Substrate-based chains. Although they discontinued the project and haven't updated the codebase for over a year, the W3F still keeps this RFP, which serves as evidence that porting the MoveVM is crucial for the future of the Polkadot network.

    We concur with this perspective and have actually been actively researching the MoveVM - exactly with a similar idea of helping port it over to other chains.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Karlo Mardeลกiฤ‡ (GitHub, LinkedIn) is a Software Engineer at Eiger and has experience with telecommunications and low-level drivers in C/C++. These days his expertise has shifted to blockchain technology and P2P protocols, where he primarily uses Rust to tackle exciting problems.
    • Piotr Olszewski (GitHub, LinkedIn) is a Software Engineer at Eiger, and has over 13 years of professional experience, with a strong academic background in distributed computing. He has a large bag of experiences, ranging from military appliances, cryptographic projects, telecommunication software to embedded platforms. During his career, Piotr took different roles, from developer to team and tech leader. His main tools are C/C++ and Rust.

    Contactโ€‹

    • Registered Address: Linnankatu 3 A 24, 20100 Turku, Finland
    • Registered Legal Entity: Eiger Oy****

    Team's experienceโ€‹

    Web3 promises to upgrade the very foundations of our society โ€“ from money, finance, and governance to media, gaming, and science. To deliver on that promise, decentralised technologies are to be integrated into the everyday experiences of billions of people. For engineering, this is a mountain of a challenge.

    Eiger was founded to develop infrastructure for web3 mass adoption. We help technology companies improve and integrate the core technologies of web3 to meet the climbing demands for scaling and performance.

    We currently employ 25+ senior web3 engineers across the globe and work with some of the most ambitious organisations in the industry, including Forte, Aleo, and XRP Labs, to name a few.

    Eiger is part of the Equiilibrium group. We have been working under the Equilibrium brand for the past 4 years and only last year created the Eiger brand to focus on implementation engineering. Eiger/EQ was one of the main contributors in all of these endeavours.

    Team Code Reposโ€‹

    As mentioned in the Teams section, Eiger already has extensive experience developing large infrastructural projects. Some chosen examples:

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 96 000 USD
    • Starting Date: 04/09/23

    Milestone 1 - MoveVM compatibility work and Subtrate Pallet developmentโ€‹

    • Estimated Duration: 2 months
    • FTE: 2
    • Costs: 96 000 USD

    Goal: Create a customised Move VM solution for the Substrate ecosystem, using the knowledge gained during the first milestone. The deliverable will be a pallet capable of receiving, storing and executing Move smart contracts.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 and MIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Rust crate: Substrate MoveForking the Move VM, as deemed necessary from the research done during the first milestone. The alterations will include everything to create the virtual machine Substrate-compatible. We will also provide extensive documentation of how the whole process is designed and how it is to be maintained.
    2.System Pallet: Substrate Move SP adds Move functionalityIntegrating the Move VM runtime within the custom pallet, ensuring compatibility with the Substrate blockchain and Move smart contract execution.
    3.System Pallet: Substrate Move SP APIs to interact with the Move VMDeveloping an API that enables developers to interact with the Move VM on Substrate-based chains, allowing them to deploy, execute, and manage Move smart contracts.

    Future Plansโ€‹

    This is the second phase of a 3-phase development program:

    1. In-Depth Exploration and Assessment of MoveVM and Substrate Integration
    2. MoveVM compatibility work and Subtrate Pallet development
    3. Finalising the Substrate-Compatible MoveVM

    The next step will be to submit a grant proposal to finalize this work - finishing up the pallet and making sure it works properly and can be utilized by other developers .

    We hope that upon the completion of all phases of creating the Substrate Move System Pallet, it will open doors for further collaboration and community input on the project. We strive to have the codebase well documented so that others might join in and contribute.

    While there are no long-term plans set in stone for the usage of this pallet, we have had discussions about possibly creating a parachain, possibly a common good parachain, that utilizes this MoveVM implementation and would run MoveVM contracts. As we near the completion of this initial development, we will be discussing these future plans more in-depth..

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    We learned about it when looking at open RFPs by the web3 foundation on their website.

    We wanted to get back up to date on what is happening in the Polkadot ecosystem, and working on grants, specifically RFPs, has been a great way to do so.

    Looking to apply to other RFPs currently open as well. Stay tuned!

    - + \ No newline at end of file diff --git a/applications/SydTek.html b/applications/SydTek.html index 6df1bdaed35..fbaf3cd914a 100644 --- a/applications/SydTek.html +++ b/applications/SydTek.html @@ -4,7 +4,7 @@ Peer-Reviewed Academic Journal Article and Dissemination - Digital Inheritance in Web3: A Case Study of Soulbound Tokens and Social Recovery Pallets within the Polkadot and Kusama Ecosystems | Web3 Foundation Grants - + @@ -21,7 +21,7 @@ A message from David Hawig on 6/7/22.

    Hi Justin,

    Sorry for the late reply. Regarding souldbound tokens and social recovery, thatโ€™s actually something we already have in our ecosystem with rmrk (see
    https://twitter.com/bitfalls/status/152929818658155725) and the social recovery pallet on kusama (https://github.com/paritytech/substrate/tree/master/frame/recovery). But it would be interesting for someone to actually look into it and explore it in more detail and potential future applications. Also most people are probably not aware that this already exists on kusama.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” State of the Industry on soulbound tokens and digital inheritanceโ€‹

    NumberDeliverableSpecification
    0.RightsAll developed materials and raw data will be publicly accessible and public domain via a GitHub repository. Milestone 1 is research oriented and as such there is no code to test.
    1.Overview of SBTsWe will provide an overview of the current state of the soulbound tokens throughout a number of blockchain ecosystems, along with service providers of Web3 digital inheritance offerings such as Safe Havenโ€™s Inheriti solution.
    1a.Specific CoverageCoverage will span historical information regarding soulbound tokens, information regarding the theoretical application of the Social Recovery Pallet for digital inheretance, academic sources, and recent developments.

    Milestone 2 โ€” Interviews and Data Collection with Phala Network, RMRK, and Parity Technologiesโ€‹

    NumberDeliverableSpecification
    0.RightsAll developed materials and raw data will be publicly accessible and public domain via a GitHub repository. Milestone 2 is research oriented and as such there is no code to test.
    1.InterviewsThe SydTek team will interview members of Phala Network, RMRK and Parity Technologies to identify ways users can leverage SBTs and the Social Recovery pallet within the Polkadot and Kusama ecosystems for digital inheritance.
    1a.Specific CoverageSpecific deep dives will propose models and approaches users can leverage to develop proposed solutions of SBT wallets, as well as additional use cases for the Social Recovery pallet.

    Milestone 3 โ€” Peer Reviewed Academic Journal Article Publicationโ€‹

    NumberDeliverableSpecification
    0.RightsAll developed materials and raw data will be publicly accessible and public domain via a GitHub repository. Milestone 3 is research oriented and as such there is no code to test.
    1.Submit to OA journalThe SydTek team submit the completed journal article for publication in a peer-reviewed open access journal to ensure the research is available for everyone.
    1a.Specific CoverageThe team will hold virtual sessions for univerisities such as Georgetown University in Washington, DC in the United States, McGill University in Montreal, Canada, and at the Kings College School of Law in London, UK to share the findings of the study. These events will also be recorded and held in the metaverse.

    ...

    Future Plansโ€‹

    Upon completion of the journal article, the team will look to apply for a grant from the Treasury to promote the article in-person at academic conferences and at universities. After the dissemination of the foundational case study for soulbound tokens and the Social Recovery pallet at institutions and university blockchain clubs globally, we have plans to conduct follow-up research with law students and academic researchers in the field of Law on the potential legal impacts of soulbound tokens on estate law. As Justin Goldston is an Graduate Advisory Board Member at Georgetown University, Law Professors at Georgetown are curious about the impact of NFTs within the legal practice. Additionally, after a presentation for faculty members from the Smeal College of Business and the Dickinson School of Law at Penn State University, which can be seen here https://bit.ly/3AQiH0C on sustainable impacts of the metaverse, Professors from the Dickinson School of Law are also looking to conduct research on NFTs, the metaverse, and law. After the completion and publishing of the original article, the team looks to conduct a follow-up study of the legal impacts of soulbound tokens. Next, we also look to continue to work with the team at Phala to build out a proof of concept with Intentionally Designed Solutions for the Kusama ecosystem with hope that this concept could be moved to Polkadot once the Social Recovery pallet is available on Polkadot. To continue the awareness of the Social Recovery pallet and the proposed digital inheritance tool, we mentioned the concept to Ray Lu - the Founder of Bit.Country - and we hope to introduce this tool within the Bit.Country metaverse within the Polkadot and Kusama ecosystems. Finally, with the recent annoucement that the Klaytn blockchain has developed a strategic partnership with Parity, in an effort to demonstrate the interoperability of Substrate, we will also work with Neo Yiu and Dr. Sangmin Seo on integrating the proposed solution into the Klaytn metaverse.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Webinar by David Hawig and David suggested we look into the Social Recovery pallet and SBTs within the Kusama ecosystems via email.

    Milestone budget breakdown Please refer to the following link for a description of the budget for each milestone.

    https://docs.google.com/spreadsheets/d/1D6gmQcR7YP9PuHF0SKAKdlQzApzQwj7n/edit?usp=sharing&ouid=114750148283862506967&rtpof=true&sd=true

    - + \ No newline at end of file diff --git a/applications/Syncra.html b/applications/Syncra.html index 04ea29a05b9..5dbe62c4737 100644 --- a/applications/Syncra.html +++ b/applications/Syncra.html @@ -4,7 +4,7 @@ Syncra x Web3 Foundation | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ Main technology stack here will be TypeScript, and Node.js Express for creating a server that can be deployed and hosted on most of the available hosting services. The reason behind this is the ease of implementation, and the availability of various libraries and technologies that can be added on top of it. This service won't receive many calls, rather act as a relayer that reads data on-chain, and then submits data/send calls to Smart Contracts on-chain, without further need for external calls. As a core tool for creating calls to Smart Contracts, we will leverage Polkadot.js Contracts API.
  • SDK JavaScript and TypeScript will be fundamental programming languages of this part, while NPM registry will be used for publishing the package itself. The SDK will be basically a wrapper of the certain functions that call Smart Contracts, and Backend. It will require the developer to add configuration, such as API Key to access our backend, Smart Contract Factory address, as well as the ABI files, that will serve as an instruction for calling each Smart Contract. We are not going to hardcode those in the SDK, as in the future, the platform may be deployed on different chains in the Polkadot ecosystem. Moreover, the Smart Contracts can be upgraded, or created with different set of rules and methods.
  • SDK Documentation The entire documentation for implementing SDK in the given project, will be built using Docusaurus that leverages JavaScript and TypeScript.

    • Hosting and Infrastructureโ€‹

    All of the code will be open-source, and available under our organizational repositories address

    Syncra Repositories

    Frontend application from the MVP part will be available under the address below

    syncra.xyz

    Example demo of on-chain automation service is going to be hosted most probably on the Railway service, and it will connect with one of the instances of Data Base, hosted on the Atlas MongoDB service. The files stored on IPFS will leverage Web3 Storage services.

    SDK bundle on the other hand, will be published on the official npmjs registry

    Documentation will published on the GH Pages

    Risksโ€‹

    There are several known risk that we are aware of, and will try our best to find solutions to prevent those scenarios from happening. Nevertheless, it is worth noticing those potential fields, which could have been improved for better safety.

    Ecosystem Fitโ€‹

    Given the importance of scalable, and customisable DAO infrastructure, which many protocols needs, we want to introduce Syncra. As a easy to use, modular, reliable, and customisable platform we believe, that is crucial element of the ecosystem. Leveraging undisclosed voting, treasury management, on-chain automation, and many others we might bring a real value.

    Our project aim to be the ecosystem standard for DAOs on Polkadot, Kusama, Aleph Zero and any Subsrate based ecosystem.

    Teamโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Przemysล‚aw Paczoski

    Lead, front-end, and quality engineer with more than 6 years of experience in the field. Working on numerous projects with companies like XTB, Docplanner, Dfns, and others. He participated in a few NFT initiatives in addition to his professional activities, where he received practical expertise in creating projects from the ground up. He actively participate in hackathons and won awards in various categories.

    Krzysztof Kuczma

    Software engineer with over than 5 years of experience. Knowledgeable in front-end, and backend technologies, alongside Azure and GCP ecosystems. Working on projects for large financial institutions. Since 2020, exploring web3 projects, participating in hackathons in which winning awards. Passionate about knowledge sharing, in which he is running the YouTube channel about programming.

    Paweล‚ Kowalewski

    Software Engineer, with experience in several blockchain technologies including projects based on Lightning Network. Prior to his software engineering career, he was an Academician and an Automotive Technician. The co-host of the YouTube channel โ€œDevs in Chainsโ€, focused on topics related to web3, web development, and Blockchain. He has attended numerous hackathons and won awards in various categories.

    Jan Kuczma

    An Alumni of the University of Sussex with Bachelorโ€™s at Computer Sciences with focus on AI and Computer Architectures. In the academic course, he participated in several hacking events and I developed various software projects including developing a 3D game in Unity and designing and implementing Machine Learning models in Python. His final year he become interested in Blockchain technologies and started learning smart contracts development. He quickly become proficient in this matter.

    Team Code Reposโ€‹

    Syncra Organization: https://github.com/SyncraDAO

    Smart Contracts: https://github.com/SyncraDAO/modular-dao

    Backend: https://github.com/SyncraDAO/Liberum-Backend

    All developments within the Web3 Foundation Grants Program will be open-sourced from day one on GitHub.

    Team GitHub Profilesโ€‹

    Team LinkedIn Profilesโ€‹

    Development Statusโ€‹

    The project is currently in early-stage development. We achieved a proof-of-concept solution during the HackOnChain hackathon in Berlin, and then decided to rebuild it from scratch, aiming for a minimum viable product soon.

    Part of the MVP is almost finished. We aim to deploy the solution on the Aleph Zero testnet within a couple of weeks. The landing page, designs, and part of the application are almost complete.

    We are currently focusing on legalising the entity, marketing, pitch decks, whitepapers, and many other things.

    Development Roadmapโ€‹

    Overviewโ€‹

    Milestone 1โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationA clear overview of the software's architecture and components, as well as its main functions and capabilities. Technical details, including programming language, technologies, frameworks, libraries, and services.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that introduces to the solution with all the guidelines included.
    1.DAO Smart Contracts (OpenZeppelinsโ€™ like) Governance StandardsSet of traits with default implementation for basic DAO feature such as voting power mechanisms based on psp22 and psp34, proposal creation and execution, quorum, proposal creation threshold and role-based proposal creation and execution. Both Smart Contracts written in ink! with OpenBrush will be provided, as well as the documentation explaining each part, with the tutorial of creating a new custom Governance Smart Contract.
    2.On-chain Automation ToolSource code as a Template with the Scheduler, and Smart Contracts caller will be provided. Moreover, as an example at least one instance of such a relayer will be deployed, and prepared for testing.

    Milestone 2โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationA clear overview of the software's architecture and components, as well as its main functions and capabilities. Technical details, including programming language, technologies, frameworks, libraries, and services.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that introduces to the solution with all the guidelines included.
    1.SDKNPM package with ready wrapped functions, for creating custom GUI for the DAO platform based on Syncra will be provided. The package will be also published on the NPM registry. It will cover the workflow of connecting with our services, and creating the whole workflow, from creating the DAO, to adding proposals, and voting on them.
    2.SDK DocumentationClear overview, instructions, and explanation of each SDK's part will be documented in the documentation that will be available publicly for everyone.

    Future Plansโ€‹

    After completing the grant, our goal is to establish a seamless process for creating and managing DAOs, with a great user experience. Additionally, we aim to enable protocols to integrate our solution into their systems using an SDK.

    Our next steps include:

    Additional Informationโ€‹

    How did you hear about the Grants Program?โ€‹

    Web3 Foundation Website, and Personal Recommendation.

    Work you have already doneโ€‹

    Previous grants you may have applied forโ€‹

    - + \ No newline at end of file diff --git a/applications/TPScore.html b/applications/TPScore.html index bdbd81844ca..b9abac24ab9 100644 --- a/applications/TPScore.html +++ b/applications/TPScore.html @@ -4,13 +4,13 @@ TPScore | Web3 Foundation Grants - +
    Skip to main content

    TPScore

    • Team Name: TPScore
    • Payment Address: 0xa8E10a8E6EEfB7175fB529b24e1a0b8DdBD29510 (USDC)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    This application is in response to the RFP Data Analysis Tools for Substrate-based Blockchains

    Overviewโ€‹

    TPScore simplifies TPS Data Analysis for non-technical users in the Polkadot Ecosystem.

    TPScore aims to provide non-technical users in the Polkadot ecosystem with an accessible and user-friendly platform for analyzing TPS (Transactions per Second) data. Our goal is to bridge the gap between technical intricacies and user-friendly visualization, empowering individuals to make informed decisions about blockchain adoption, investment, and development.

    Adoption levels and community engagement are vital indicators of a blockchain's success. They directly impact the attractiveness of a network and its potential for growth. While social media followers, media coverage, and developer activity are commonly considered metrics, the true measure of adoption lies in TPS. TPS is a robust metric that correlates with the economic activity on a blockchain, making it a crucial parameter for understanding and evaluating different chains.

    When users choose a blockchain for investment or development purposes, conducting a thorough analysis of each chain is essential. Polkadot's unique architecture and scalability prospects, with its interconnected parachains, offer a vast ecosystem of possibilities. However, determining the TPS of Polkadot and its 40+ parachains is currently a complex task that requires technical knowledge and data analytics expertise. This creates a significant barrier for non-technical users and even presents challenges for those with technical know-how, as gathering TPS data for multiple parachains can be time-consuming.

    TPScore aims to simplify the process of TPS analysis by providing an intuitive and user-friendly analytics website. We remove the need for users to perform complex ETL (Extract, Transform, Load) work or possess specialized data analytics skills. Our platform presents TPS numbers for the Polkadot Relay chain and parachains in a readily understandable format, accessible to anyone. We empower individuals to effortlessly access and compare TPS data across different parachains, enabling them to make informed decisions regarding investments, project selection, and engagement within the Polkadot ecosystem.

    Project Detailsโ€‹

    The final state of the project will consist of two key components:

    1. ETL System: This component will be responsible for fetching data from the blockchain, transforming it, and storing it in a relational database.

    2. User Interface (UI) with data visualizations: The UI will provide a user-friendly interface to access and analyze TPS data. It will include visually appealing and informative visualizations of the data, reducing users barier to understanding blockchain metrics.

    The initial version of TPScore, which will serve as a POC, will cover the Relay chain and 38 parachains. The UI interface will be designed to be accessible on both desktop and mobile devices, ensuring a seamless user experience across various platforms.

    To fetch blockchain data, we will leverage two methods:

    1. Subscan API (list of parachains accessed with Subscan API)
    2. Public endpoints (list of parachains accessed by public endpoints)

    1. ETL Systemโ€‹

    We will retrieve blockchain data using either the Subscan API or connect to the public endpoints of parachains using the Substrate interface library.

    To ensure streamlined and efficient data processing, we will leverage Apache Airflow.

    To calculate the average TPS, we will take the number of transactions within the last 100 blocks. We will fetch raw data at regular intervals of every 10 minutes. This raw data will then undergo processing within Airflow's DAGs using Python Operators, ensuring efficient data transformation and preparation.

    Finally, the processed data will be stored in a MySQL database to be later picked up by Next.js framework.

    2. User Interface (UI) with data visualizationsโ€‹

    We will use Next.js as our full-stack framework. It allows us to both retrieve data from MySQL database and render React app on a server.

    To visualize data, we will use a simple and concise UI: the grid of cards with the blockchain's name and TPS. We expect one common use case: users go to our website and scan through all chains to find a desired one. So we will simplify this process by adding handy sorting and filtering.

    Architectureโ€‹

    Architecture diagram

    Database schemaโ€‹

    UI Designโ€‹

    Desktop Designโ€‹

    Desktop UI design

    Mobile Designโ€‹

    Mobile UI design

    Technology stackโ€‹

    1. Apache Airflow
    2. Python + Data Analysis Libraries
    3. Next.js & React

    Out of scope detailsโ€‹

    During this stage, our focus will be solely on the Polkadot ecosystem, and we won't be providing coverage for the Kusama ecosystem. This decision allows us to concentrate on testing the market fit of our Proof of Concept (POC) within the Polkadot network.

    Additionally, we will exclude a specific set of parachains from our analysis (out of scope parachains). These parachains are either not yet live on the mainnet or lack a public endpoint for data access.

    Ecosystem Fitโ€‹

    Our project addresses a critical gap within the Polkadot ecosystem by providing comprehensive data visualization and analysis tool. Currently, obtaining data from Substrate-based blockchains relies on block explorers that offer a limited set of metrics or require technical skills to access and transform raw data from parachain endpoints. Recognizing this challenge, we aim to simplify the life of Polkadot ecosystem users with easy access to sophisticated network metrics for analyzing network parameters and comparing blockchains.

    Our target audience comprises advanced blockchain users who seek convenient access to comprehensive network metrics but lack the technical expertise or time to perform complex analyses independently. We understand their need for intuitive tools that enable efficient evaluation of blockchain networks, helping them to make informed decisions.

    As of the time of this application, no tools exist for checking TPS across the Polkadot Relay chain and parachains. However, there are 2 similar projects, ETHTPS and RealTPS, which focus on the Ethereum and other layer-1 networks. The presence of these projects indicates the existence of user needs and market fit. Unfortunately, both of these projects do not cover Polkadot ecosystem and fall short in terms of user-friendliness, highlighting the need for improvement in its UI design.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Ilya Andreev
    • Nikita Grechino

    Contactโ€‹

    • Registered Address: no registered address
    • Registered Legal Entity: no registered entity

    Team's experienceโ€‹

    Ilya Andreev has 4+ years of experience in product management, out of which 3 years were spent in P&G focusing on the management and development of Big Data solutions. He has been in the blockchain industry for 3+ years with more than a year working full-time in one of the startups in the DotSama ecosystem.

    Nikita Grechino is a Fullstack engineer with more than 5 years of experience. He has been working in the blockchain space since early 2022, focusing on the development of the front-end interface for crypto trading platforms.

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    This project is a response to RFP Data Analysis Tools for Substrate-based Blockchains

    Up until now, our primary focus has revolved around two key objectives:

    1. Finding product-market fit
    2. Ensuring credible API/endpoints availability for the Polkadot ecosystem

    1. Finding product-market fitโ€‹

    Max TPS has long been a core indicator of blockchain performance and speed. Numerous articles and blogs compare the maximum TPS of different networks, highlighting its significance (Article 1, Article 2, Article 3, etc.). However, max TPS is often based on theoretical calculations rather than real network utilization, making real-time TPS measurement a more valuable alternative. Notably, projects like ETHTPS and RealTPS already track TPS outside the Polkadot ecosystem, indicating a growing interest in real-time TPS tracking.

    2. Ensuring credible API/endpoints availability for the Polkadot ecosystemโ€‹

    We have successfully identified methods to retrieve data from the Polkadot Relay chain and 38 parachains. We will utilize the Subscan API or connect to the public endpoints of parachains using the Substrate interface library. It is important to note that locating functional parachain endpoints may be challenging for average blockchain users, as there is no centralized source providing all parachain endpoints. Moreover, certain parachains lack public endpoints and will be excluded from this POC. However, we may consider including them in future versions by directly engaging with the respective parachain teams.

    For a detailed list of the parachains accessed through the Subscan API, parachain endpoints, and the out-of-scope parachains, please refer to the provided link

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-Time Equivalent (FTE): 2
    • Total Costs: 10,000 USD

    Milestone 1 - ETL Systemโ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: 5,000 USD
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Database schemaWe will implement the schema in MySQL database.
    2.Airflow DAGsWe will create Airflow DAGs for data gathering and calculation of TPS metrics.

    Milestone 2 โ€” User Interface (UI) with data visualizationsโ€‹

    • Estimated Duration: 1 month
    • FTE: 1
    • Costs: 5,000 USD
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains how to use TPScore product and how it was build.
    1.Data accessWe will access the MySQL database from our Next.js app and process data on the server to make the client as lightweight as possible.
    2.UIWe will build UI according to the designs and test it thoroughly under different conditions.

    Future Plansโ€‹

    Our primary goal for this project is to develop a POC and validate our assumptions regarding its market fit and appeal to Polkadot users. If we receive a positive response from the community, we intend to dedicate more time and resources to further develop the project.

    In future versions, we have identified several potential features to consider:

    1. Including support for Polkadot parachains that are currently out of scope for the POC by directly engaging with the respective parachain teams.
    2. Incorporating historical data and visualizations to observe the TPS dynamics of specific parachains or the relay chain over time.
    3. Expanding the project to include data from the Kusama Relay chain and its associated parachains.
    4. Enabling easy comparisons by incorporating data from other non-Substrate-based blockchains.
    5. Extending the project beyond TPS tracking to include other valuable parachain-related data that is typically challenging to retrieve without technical expertise.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    We learned about it via Web3 Foundation Website. We've been closely monitoring the DotSama ecosystem for more than a year, we've read documentation, tested various projects/parachains, and participated in staking. After getting a deeper understanding of the technology and the ecosystem we decided to test our own idea and build a POC of a data analytics website for the Polkadot ecosystem.

    This application is a logical next step in our continued interest in Substrate-based chains and Polkadot in particular.

    - + \ No newline at end of file diff --git a/applications/TREX_Network.html b/applications/TREX_Network.html index fbe2cf3be1c..c153062c317 100644 --- a/applications/TREX_Network.html +++ b/applications/TREX_Network.html @@ -4,7 +4,7 @@ TREX - Timed Release Encryption Xing chains | Web3 Foundation Grants - + @@ -24,7 +24,7 @@ It includes the following software:

    1. A demo blockchain node (GitHub Repo);
    2. A demo block index engine (GitHub Repo);
    3. A WASM library for the demo of dTRE technology (GitHub Repo);
    4. A demo app to use the dTRE technology as a Chrome extension (GitHub Repo);

    The demo mentioned above is deployed on AWS and may be accessed with a web link. It is worth noting that Our final release will use a different type of technology based on hardware encryption.

    In the current stage of TREX development, we are working on the following software with the Rust programming language to deliver public test-net and main-net:

    1. TREX node software that supports fundamental blockchain functionalities, consensus, and keyholding;
    2. The customized TREX archive software scans the blockchain and unlocks encrypted data, and releases it according to its preset clock (GitHub repo);
    3. The TREX API library to submit dTRE data as a form of Substrate extrinsic to TREX nodes (GitHub repo);
    4. The infra-as-code (IaC) TerraForm script to deploy the TREX test-net and backend services (GitHub repo);

    Since we are working on a new version of TREX node software using confidential computing technology, we need to rewrite our consensus code and design the off-chain worker code for keyholding. The first version of the demonstration of dTRE will be built as a side-chain in an existing decentralized network since it has tested its implementation using off-chain workers within the TEE. However, we will have to develop some specific pallets to support our tokenomics. Thus, our network cannot be a side chain in its final formation. Unlike other networks using confidential computing technology, we are not supporting general computing in TEEs but focus on dTRE technology built on top of confidential computing hardware.

    We are not working on a universal public chain like ETH or Polkadot that serves as layer-0 infra. Our parachain only focuses on providing a specific decentralized infra service - the decentralized timed-release encryption for cross-chain applications.

    We are not building a smart contract platform but provide APIs to any cross-chain smart contracts if using dTRE technology.

    We are not going to build a web or mobile application for end-users (e. g. decentralized strategy markets), but we are working with our business partners by providing them dTRE infra services and integration toolchains. Moreover, we are trying to attract more third-party developers to our network and the Polkadot ecosystem to develop various dApps based on the dTRE technology and Polkadot cross-chain technology.

    We are not providing infrastructure for general confidential computing but only focus on dTRE technology with confidential computing hardware.

    Ecosystem Fitโ€‹

    Our final goal is to create a new frontier of dAPPs with dTRE technology in the Web3 domain. The Polkadot ecosystem provides very comprehensive and advanced support for cross-chain interoperability. With Polkadot relay chains, bridges and parachains, arbitrary data could be encrypted with our dTRE technology and transferred across various blockchains, and triggered future events on any other blockchains. The Polkadot multi-chain network allows us to explore the full potential of our dTRE technology since it may be integrated with the whole web3 network and create a large number of new dApps.

    Our target audience is whoever needs to send a temporarily confidential message in the future. It could have a list of applications/businesses including but not limited to

    1. Decentralized strategy market (to replace the centralized service like tipranks.com )
    2. Decentralized prediction market (to replace the centralized service like predictit.org )
    3. Universal key escrow (encrypted arbitrary crypto key to hold the escrow fund and release in the future)
    4. Decentralized voting system (encrypted ballot and reveal it in the future)
    5. Decentralized blind bidding (encrypted all bids and reveal in the deadline to find the final bid winner)

    Any creators and developers with the above applications could be our target audience. For example, they could be parachains and dApps that provide decentralized trading platforms, strategy markets, prediction markets and so on.

    Essentially, the world needs decentralized reputations to open a new Web3 frontier. Our dTRE technology helps dApp dev and owners build up their decentralized reputations and creates marketplaces for temporarily confidential data. Therefore, the early access privilege to the dTRE data can be traded so that the reputed content creator can sell their strategies or predictions. Additionally, the dTRE technology can support a range of new Web3 applications that need features for timed data release.

    No, according to our best knowledge, we are creating all new decentralized applications in the Web3 domain. We don't see similar projects in blockchains providing decentralized timed-release encryption (dTRE) services. We believe that the dTRE technology will radically change many existing centralized applications since it builds up a trustless and permissionless mechanism to send a message to the future and create markets for early access or subscription.

    The Integritee Network pioneers confidential computing in Web3 as a project in the Substrate / Polkadot / Kusama ecosystem. It provides remote attestation services for us to build a fully decentralized tech stack. Although the TREX network uses the same type of confidential computing technology as theirs, the TREX network anchors on a different kind of service, working with another category of clients. We will eventually grow into two different types of projects in the same ecosystem.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Leo Yu: Serial entrepreneur of crypto technology startup companies with several successful entrepreneurial projects and good investment returns. Excellency at integrating international resources and having an outstanding strategic development vision. Proficiency in communication with global clients and team coordination skills. Resume

    Fanghao Yang: former researcher & software engineer in IBM Research, US DOE national lab at Princeton University, worked with a few startup companies leading a team of developers. See the LinkedIn page below.

    Oscar Wang: Serial entrepreneur with more than ten years of business management and marketing experience covering markets from technology to manufacturing. More than five years of experience as a general manager of large-scale enterprises, with excellent skills in solving complex problems, business planning, team management, and interpersonal skills, strong learning ability in new fields, and firm team-oriented. Resume

    Xingqiu Yuan: chief research scientist in US DOE national labs for distributed computing and large-scale HPC software design. See the LinkedIn page below.

    Jake Jian: former Morgan Stanley analyst and Accenture consultant team lead. Directors and senior management of many prestige IT companies. See the LinkedIn page below.

    Dan Yin: 10+ years of experience in the development of fintech services and software Resume.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    The early version of dTRE technology uses PoW consensus, which is no longer suitable for today's climate change and energy crisis. We are actively working on the new node software leveraging confidential computing hardware to achieve the same or even better results.

    It is in progress to be integrated with our business partners to support the deployment of the dTRE technology in existing platforms with the rabbitMQ message broker.

    Tested and successfully submitted dTRE data to the TREX blockchain node.

    Development Roadmap ๐Ÿ”ฉโ€‹

    In the current stage, our first milestone is to deliver an early demonstration using confidential computing hardware for decentralized timed-release encryption. We will develop our first demo as a side-chain in a decentralized network that supports off-chain workers in TEEs. We request a level-1 grant for the early demonstration and will work on the next level in the following application. We have accumulated solid experience in development with the Substrate framework, so we believe that we can implement our network at a fast pace.

    At the next level, our second milestone is integrating the TOCW with our network under our particular consensus and mechanism. We will also implement key splitting as a third milestone to enhance the security and reliability of our system at the next level. Finally, our fourth milestone is the implementation of XCMP for cross-chain applications.

    Overviewโ€‹

    Milestone 1 โ€” Implement TREX network as a Polkadot para-chainโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT License
    0b.DocumentationWe will provide both inline documentation of the code, API documentation and a basic tutorial that explains how a dApp user can publish his timed-release data on the blockchain.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an online documents that explains how this module works as described in the following figure.
    1.TREX key-holder (off-chain worker)A TREX off-chain worker (named as "key-holder") in TEE so that client can safely send encrypted data to the network and send the shielded key to the key-holder. The key-holder worker is remotely attested by a decentralized network so that the worker node cannot manipulate the release of the encrypted data. The "key-holder" node will provide a key-holder service to hold the key piece inside the TEE and release it until it expired.
    2.TREX nodeA TREX core node provides pallets and APIs so that a key-holder can publish its remote attestation reports on the chain and other clients can access the report to verify its TEE. The TREX node also provides APIs to post timed-released data and expired keys to unlock those datas.
    3.CLI toolA CLI tool to provide basic blockchain and TEE functionalities like generation of accounts, checking account balance and getting public key for shielding encryption key.

    Future Plansโ€‹

    In the short term, our team is working on landing the first dTRE infrastructure on the Web3 frontier and promoting the technology in the Polkadot/Substrate ecosystem.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website and Twitter.

    - + \ No newline at end of file diff --git a/applications/Tellor.html b/applications/Tellor.html index 393f9950199..d3837e86308 100644 --- a/applications/Tellor.html +++ b/applications/Tellor.html @@ -4,7 +4,7 @@ Tellor | Web3 Foundation Grants - + @@ -22,7 +22,7 @@ The underlying oracle design will follow the same structure as Tellor on other chains, namely a game theoretic design where data is put on-chain by staked reporters who are liable to lose their stake if disputed. The system can be as fast as participants desire, but like other blockchain architectures, is more secure the slower the oracle use is since it allows more time for disputes.

    Tellor architecture of the smart contracts can be found in the TellorFlex github repository or in our whitepaper. Information on the Tellor Reporter (node) software can be found in the Tellor Docs.

    Prior work or research on the topic: The team received an Ethereum foundation grant for researching bridges as the team was initially designing a cross-chain decentralized derivative protocol. There were no available decentralized oracles at the time and that prompted the team to design and build a decentralized oracle, which soon was dubbed Tellor. Tellor has been live on Ethereum mainnet since August 2019 and the team has continued to iterate to increase decentralization, token dependency, and improve upon governance. We have launched on several chains as of May 2022, including Ethereum, Polygon, Arbitrum, Algorand, and corresponding testnets.

    What your project is not or will not provide or implement: Tellor will launch the system and help design/solve any specific integration for users in the substrate ecosystem. We will initially help bootstrap a network of reporters, however Tellor is a system that is designed to run without any team intervention. Being crypto-economically incentivized, reporters will stay in networks that provide enough incentives/rewards for them to provide data. Tellor can provide the software for reporters to run, however the size of the network will largely depend on whether users are active in the system and funding oracle reporters. It is important for the web3 ecosystem and tellor to work together to ensure enough usage and monitoring is enabled on the system once it is launched.

    Ecosystem Fitโ€‹

    Ecosystem Needs and Fit - For a long time the Tellor team has been fans of the Polkadot ecosystem and their pursuit of decentralization. The values of security, transparency, and truly open and decentralized networks is something that Tellor was built upon and lines up perfectly with the ecosystem built here. Oracles are a necessity for decentralized applications to meet their full potential and to expand the interoperability between chains. Although there are competitors, Tellor is an oracle built on the values which align with projects built on Polkadot. We provide the needed infrastructure for chainsโ€™ use cases to expand, while at the same time remaining uncompromising in our approach towards censorship resistance and decentralization.

    Target Audience - The target audience is developers needing connections to off-chain data. Whether itโ€™s connections to other non-XCM connected chains, or even straight web2 off-chain data, Tellor can provide the ecosystem with a general purpose oracle that can handle any data, at any speed, for any use case. The initial goal is for the Tellor oracle pallet to be included/added to parachains so that developers can use it to access off-chain data in any smart contract structure on the ecosystem.

    Similar projects - A similar project to Tellor is the Chainlink Substrate oracle pallet. Tellor also provides off chain data however, Tellorโ€™s design differs greatly in areas where it matters. Mainly, the Tellor oracle has a greater (actual) degree of decentralization, is crypto economically incentivized versus reputation based, and is completely flexible for the needs of any data type or frequency. In addition, once the network of reporters is bootstrapped, there is minimal team intervention needed. Anyone can become a reporter by staking, anyone can dispute the validity of the data for a fee, and the user can incentivize reporters to quickly add or replace the data they need by posting a reward. The system is permissionless, as well as sybil and censorship resistant.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Our team consists of 7 developers and 3 non-technical team members. 3 of us are cofounders - Brenda Loya CEO, Nick Fett CTO, and Michael Zemrose CSO.

    The developers of Tellor have years of blockchain specific coding experience.

    Contactโ€‹

    Team's experienceโ€‹

    The Tellor team has broad experience working in blockchain technology. The founders have been in the space for a decade now and have authored research papers, performed audits, been active members of DAOโ€™s, and worked on several L1 paradigms over the years. The main Tellor repo has most of our work, however individual achievements of those in the company are their own.

    Team Code Reposโ€‹

    Github profiles of our dev team:

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    The smart contract structure for Tellor is finished for most EVM chains, but will need specific changes. Initial design discussions have been had with Robin, Frank Bell, and Guatam and we have specifications and even some base work done around the design.

    Development Roadmap ๐Ÿ”ฉโ€‹

    MilestoneDescriptionStackResourcesFunding
    1Develop and launch Tellor core contracts on an EVM parachainSolidity / javascript2 devs20,000
    2Create and test oracle pallet and complete documentation with usage examplesRust / Solidity2 devs20,000

    Overviewโ€‹

    Milestone 1 โ€” Launch Tellor core contracts on an EVM parachainโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1Develop Controller contractsWe will provide a set of solidity smart contracts with the functionality described above in the Project Details
    2Develop Parachain integration contractWe will provide an integration contract

    Milestone 2 โ€” Create and test oracle pallet and complete documentation with usage examplesโ€‹

    Details: A new Substrate pallet will be required which includes the core oracle data reporting and querying logic as well as staking rewards and payment logic, ported from the existing tellorFlex (oracle), AutoPay and UsingTellor (consumer) smart contracts. All the logic within the pallet will simply use the token of the parachain. Any parachain user can create and fund feeds, which are fulfilled by oracle reporters which have deposited a stake to the Oracle contract on the smart contract parachain. Once completed, integrating and testing the pallet and the controller contracts will take significant work and documentation in order to make a robust and user-friendly oracle module.

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1Substrate Oracle pallet design and integrationWe will provide the Substrate oracle pallet
    2Tests and a guide for testing functionallity of the the pallet with integration of a mock project on selected parachainsWe will provide tests and a guide to test cross functionality of the system for interactions between the EVM chain and consumer chain and oracle pallet (meaning test the functinallity between milestone 1 and 2 delivarable 1 - solidity contracts, pallet, XCM)
    3Documentation/ Usage ExamplesWe will provide documenatation and usage examples for the system.

    Future Plansโ€‹

    Tellor plans to work with the Polkadot ecosystem as they grow to identify new and better set-ups for the oracle structure on the system. Another key piece to the ongoing support is working directly with builders to get them integrated and create a large set of sample code and existing users that can help make Tellor the secure choice of oracle on the network. Weโ€™ll accomplish this by:

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    You can find more information about the program here.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    We talked to Rohan at a few events about building on Polkadot and he recommended we apply! Weโ€™ve been in touch with Robin Ejsmond-Frey, Frank Bell, and Guatam from Parity who have done significant work with us in developing the specifications and design for the build.

    - + \ No newline at end of file diff --git a/applications/Treasureland.html b/applications/Treasureland.html index 41d89ea4b8f..1ce5891fdb3 100644 --- a/applications/Treasureland.html +++ b/applications/Treasureland.html @@ -4,13 +4,13 @@ Treasureland | Web3 Foundation Grants - +
    Skip to main content

    Treasureland

    • Project Name: Treasureland
    • Team Name: dego-labs
    • Payment Address: 0xd2b2755a4bDCAF415E9a74e3EfE41D23D2F70C53
    • Status: Terminated

    ใ€

    Project Overview ๐Ÿ“„โ€‹

    Treasureland is a NFT publishing and trading platform, where users can mint their own NFT with one click and can buy, sell or auction multiple on-chain NFT. Treasureland aims to connect producers and consumers with a decentralized approach, becoming the value hunter in the crypto-world and the best entrance to the world of Web 3.0.

    Overviewโ€‹

    Core functions are as follows:

    • Trading market
    • Auction
    • Multiple protocols integration
    • API

    Project Detailsโ€‹

    Technical architecture of the project:

    architecture

    Essential supported functions include:

    To provide multi-chain markets tradingโ€‹

    Support users put up offers on various coins, and many protocols are allowed including NFT721, NFT1155 so far.

    HotPotato Auctionโ€‹

    Auction in the HotPotato fashion is supported, which is able to reward every participants of the auction.

    Creating NFT asset with one clickโ€‹

    NFT minted by users can contain different digital contents and assets, or it can be a crypto artwork, a game prop, a certain amount of cryptocurrency or a combination of the above.

    NFT blind boxesโ€‹

    Airdrop blind boxes, providing the fun of a scratch-off.

    Ecosystem Fitโ€‹

    Different from OpenSea, we have a Dutch auction mode and a unique blind box mode. It became very popular after it went online on Ethereum and BSC, with a total of 100 thousands participating addresses from both platforms.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    TeamWebsiteโ€‹

    Team's experienceโ€‹

    Manyofourteammatescome from gaming industries with more than 10 years of experience in the industry and, in the year of 2018, officially join us at theblockchain industry. Many Dapps have beenmade oneth, eos,tron,iostsince then and enriched our blockchain developing experience.

    โ€‹

    Team Code Reposโ€‹

    Contactโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 9 weeks
    • Full-time equivalent (FTE): 4
    • Total Costs: 12K DAI

    Milestone 1 โ€” NFT protocol, trading, auctioning,mintingโ€‹

    • Estimated Duration: 9 weeks
    • FTE: 4
    • Costs: 12K DAI
    NumberDeliverableSpecification
    0a.LicenseApache License 2.0
    0b.DocumentationDocuments containing the description of whole architecture design for NFTStore.
    0c.Testing GuideWe will provide a full test suite and guide for project
    1a.Pallet_treasureland_tradetrade module include: createOrder, cancelOrder, buy implemented by rust
    1b.Pallet_treasureland_auctionauction module include: startAuction, bid,addVerifyAuctioneer implemented by rust
    1c.Pallet_treasureland_mintingminting module include: mint implemented by rust
    2.Front endImplement front-end based on React will support polkadot-js extension, functions๏ผšNFT display, sale, auction, minting and other modules
    3.TestFunctional test and bug fix

    Future Plansโ€‹

    Following are the realization of NFT fragments trading, Blind box, Dao governance, NFT cross-chain bridges, etc.

    Additional Information โž•โ€‹

    We have already deployed the core function to Ethereum and BSC networks, the project website is:https://www.treasureland.market/

    Up to now, the details of the trading on BSC are as follows:

    • NFT transactions: 14,706
    • NFT trading volume: 8598.5 BNB (350K $)
    • Service fee๏ผš171.97 BNB (7K $)
    - + \ No newline at end of file diff --git a/applications/TreasuryTracker.html b/applications/TreasuryTracker.html index f5cb1ea6ac7..3b0f70b35a2 100644 --- a/applications/TreasuryTracker.html +++ b/applications/TreasuryTracker.html @@ -4,7 +4,7 @@ TreasuryTracker | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ Prior to the proposal, careful planning and design were undertaken to create UI mockups that accurately represent the intended functionality of the platform. These mockups serve as a guide for the development process, ensuring that user experience and visual aesthetics align with the project's objectives and future plans.

    On-Chain Data Reading: Initial testing and development of functions for reading on-chain data have been performed. This represents a crucial step in achieving the project's goals, as it allows for accurate and real-time retrieval of referenda and treasury data directly from the blockchain.

    Research and Community outreach: Comprehensive research has been conducted to understand the needs of the community, the gaps in existing solutions, and the potential challenges in implementing the project.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 Example ๏ฟฝ Basic functionalityโ€‹

    โ— The default deliverables 0a-0d below are mandatory for all milestones, and deliverable 0e at least for the last one.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use the application and its various features.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains what was done/achieved as part of the grant
    1.Backend DevelopmentA node module that allows the CakePHP framework to pull the relevant data directly from the blockchain via WSS/RPC.
    2.Frontend DevelopmentA CakePHP framework that interacts with database contents rendering some pages and providing API results to portions of the javascript elements for dynamic rendering.
    3.Integration and TestingThe final milestone is focused on integrating the backend with the frontend, and conducting extensive testing to ensure everything functions as intended.

    Features Includedโ€‹

    Future Plansโ€‹

    The TreasuryTracker analytics portal is set to bring a significant change to how OpenGovernance data is tracked, analyzed, and presented. However, the development of a proof of concept (POC) under this grant proposal represents only the first phase in our strategic roadmap for the platform. We have a comprehensive set of short and long-term plans intended to maximize the potential of this project:

    Short-Term Plansโ€‹

    After delivering a working POC, we plan to work on extensive user feedback collection and rigorous testing to further enhance and refine the platform. We aim to make necessary modifications and improvements based on this feedback to ensure the platform aligns with the needs and expectations of the community. Promotion and support will be crucial at this stage, and we intend to conduct extensive outreach to raise awareness about the project and encourage its use among our target audience.

    Long-Term Plansโ€‹

    As for the long-term vision, we plan to further expand the data collected and the analytical capabilities of the platform. This expansion will provide a broader range of data analytics. A particular focus will be put on enhancing the user interface and overall user experience inspired by our existing graphical mockups. The focus will be on presenting platform data in a more modern and user-friendly UI to enhance user interaction and understanding. This redesign process will prioritize clarity, ease-of-use, and intuitive navigation to best serve the platform's diverse audience.

    In addition to the live analytics side, we're exploring the idea of producing periodic reports (e.g., quarterly or annually) that provide a comprehensive review of the OpenGovernance referenda on Polkadot and Kusama networks. These reports can serve as invaluable resources for the community, giving in-depth insights into trends and significant happenings in the ecosystem.

    Ultimately, our goal is to make TreasuryTracker a go-to platform for all OpenGovernance data analysis and reporting needs. As the platform grows and matures, we'll continue to identify and explore new opportunities to further its reach and impact within the Polkadot and Kusama ecosystems.

    Additional Featuresโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website and personal recommendation

    - + \ No newline at end of file diff --git a/applications/UMC-Tokenscribe.html b/applications/UMC-Tokenscribe.html index 81939f03785..aee2a15bb79 100644 --- a/applications/UMC-Tokenscribe.html +++ b/applications/UMC-Tokenscribe.html @@ -4,7 +4,7 @@ UMC - Tokenscribe | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ As we know, the draft EIP1337 proposed a way to implement token subscription for ERC20 tokens. But from the view of users, EIP1337 is not the secure way to implement token subscription. This application is aimed to propose a specification of secured token subscription which is the key feature of UMC - Universal Membership Community.

    Integrationโ€‹

    The secured token subscription will be implemented with Ink!.

    Team Interestโ€‹

    We are dapp developers and we want to design a subscription feature for our project to manage users' membership with the secured token subscription. Our project is aimed to build a universal membership network which is can be used for both on-chain and off-chain services, such as Shopping Mall Memberships.

    Project Detailsโ€‹

    With EIP1337, all the subscription status-related information is managed by a subscription contract, which will expose the users to the risks just like the situation of subscription in the telecom age and the early age of the internet. Most scamming cases are let users subscribe to some uncertain subscriptions while users cannot cancel those subscriptions due easily. The main idea is to track and manage the subscription in token contract rather than subscription contracts to achieve the goal of securing users' assets.

    Interface Specificationโ€‹

    The standard methods of ERC20 should be implemented as part of the token with the subscription feature.

    The following methods also should be implemented.

    subscribe

    - desc: subscribe the specific service.
    - params: contract address, interval, extra data
    - return: success
    unsubscribe

    - desc: unsubscribe the specific service.
    - params: contract address, data
    - return: success
    subscriptionStatus

    - desc: return the status of specific subscription.
    - params: user address, contract address
    - return: the status of subscription
    subscriptionInterval

    - desc: return the interval of specific subscription.
    - params: user address, contract address
    - return: the interval of subscription
    executeSubscription

    - desc: execute the subscription for a specific address if pass the check.
    - params: user address
    - return: success
    validSubscriptions

    - desc: return the list of current valid subscriptions.
    - params: user address
    - return: the list of current valid subscriptions

    Ecosystem Fitโ€‹

    EIP1337 Draft is the only one proposed in EIPs for token subscription, but still not widly used since approved six monthes before.

    ERC20 with Ink! is the sample code of ERC20 token in Ink!.

    At the very beginning stage of Ink! and Polkadot ecosystem, it's good to add token subscription as the common interface for tokens.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    No Legal Entity

    Team's experienceโ€‹

    Gala

    Davies

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement Draft Specificationโ€‹

    The draft specification and a demo will be provided.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationThe draft specification.
    1a.Demo code repoThe demo code with Ink!.
    1b.TutorialThe tutorial of how to use.
    2.ArticleAn article on media channels.
    3.PSPSubmit a Polkadot Standards Proposal.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    A draft idea of this specification was discussed with several other developers.

    - + \ No newline at end of file diff --git a/applications/Validator_Monitoring_Service.html b/applications/Validator_Monitoring_Service.html index 21ad5c2c5fa..0826cf87d0c 100644 --- a/applications/Validator_Monitoring_Service.html +++ b/applications/Validator_Monitoring_Service.html @@ -4,13 +4,13 @@ Validator Monitoring Service | Web3 Foundation Grants - +
    Skip to main content

    Validator Monitoring Service

    • Team Name: P2P.ORG Validator
    • Payment Address: 0xE22211Ba98213c866CC5DC8d7D9493b1e7EFD25A (USDC)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Our application seeks to fund the development of a monitoring platform for validator operators.

    Overview and Ecosystem Fitโ€‹

    Validator Monitoring Service is a monitoring platform designed to track the performance of validators in the Polkadot and Kusama networks.

    In the existing ecosystem of the Polkadot network, there is a lack of comprehensive historical information available about how validators perform as ParaValidators and their participation in consensus. Public scanners like Subscan offer limited insights into validator performance, with scarce information such as earned points and rewards displayed only after an era's end. This limitation prevents the use of existing scanners as real-time monitoring tools.

    However, active participation in consensus is crucial for upholding network security. Each consensus round relies on obtaining 2/3 precommits, and validators failing to reach this threshold cannot contribute to blockchain security. If numerous validators encounter participation issues, it can reduce block production speed, adversely affecting the overall network.

    We truly believe that every validator operator should understand their role and significance in ensuring blockchain security.

    Furthermore, the information provided by public scanners predominantly focuses on individual addresses and specific events. At the same time, it allows for retrieving on-chain data such as reward payments and rewards points for a particular account. Scanners generally lack the capability to compare these rewards with those of other validators. This limitation hinders a comprehensive understanding of a chosen validator's performance relative to others in the network.

    Our monitoring service effectively addresses this challenge by providing real-time data on validator performance and enabling performance comparisons with other validators.

    Moreover, besides public scanners, there are several existing solutions available for validator monitoring, such as P.A.N.I.C., Polkalert, B-Harvest, nmonpolkadot, Polkadot-K8s-Monitor, Polkadot-Watcher, ex-1KV Telegram Bot, as well as, grant-supported dashboards Cyclops. Our solution stands out due to several significant differences:

    1. Out-of-the-box Solution: Unlike many existing applications that require hosting arrangements, our platform offers a hassle-free experience. Users can effortlessly try our product and assess its suitability for their needs by simply interacting with our Telegram bot and setting up a live dashboard. This accessibility enhances the popularity and adoption of our solution.
    2. Comprehensive Data: While most solutions provide standard on-chain data such as reward points, reward amounts, and on-chain events like offences or payouts, our platform goes beyond that. We offer unique data, including information on participation in the consensus, the selection of a para-validator, and para-validator points per session (not just per era). This granular data provides users with a more comprehensive understanding of validator performance.
    3. Ongoing Support: Many existing applications are developed by small teams and may need more ongoing support, with some repositories needing to be updated. In contrast, we are one of the largest validators in the network, and we commit to supporting and maintaining our validator monitoring platform. Additionally, we utilize the same system for our internal purposes, ensuring its reliability and continuous improvement.

    Potential usersโ€‹

    Our monitoring system caters to various parties within the community who can derive significant benefits from its usage:

    1. Validator Operators: Our service is a valuable tool for validator operators, particularly small teams and independent validators who may lack the time and resources to develop their monitoring systems. For instance, meeting the strict requirements of programs like the 1KV program can be challenging for small and independent validators. With our monitoring system, they gain the ability to track an extensive range of metrics. By leveraging our service, validator operators can thrive within the decentralized ecosystem and enhance performance.
    2. Nominators: Nominators play a crucial role in the network by selecting validators to nominate. Our service provides nominators with detailed performance comparisons among different validators. They can evaluate critical metrics such as consensus participation, and block production efficiency relative to other validators. Our service empowers nominators to make informed decisions when choosing validators to nominate, optimizing their returns, and actively contributing to the network's health.
    3. Foundation: By having access to comprehensive information on validator participation in consensus, block production efficiency, and other crucial metrics, the Foundation can identify and address any security vulnerabilities or potential risks promptly. This proactive approach helps to maintain a robust and secure network for all participants. Moreover, the Foundation can offer greater transparency to the community regarding validator performance

    Lastly, our team possesses extensive experience in maintaining validators within the Polkadot and Kusama networks, and we have developed the necessary monitoring and maintenance tools. We firmly believe that this knowledge should be shared for the benefit of the entire network rather than being kept private. Therefore, we seek a grant to further develop our monitoring system and contribute to the network's advancement.

    Project Detailsโ€‹

    We have developed a comprehensive monitoring platform as a service. This platform provides validator operators with an effortless monitoring solution, saving them valuable time and effort. With our service, operators can focus on other critical aspects of validator operations, knowing that their monitoring needs are taken care of.

    Our system could be depicted in the following picture:

    Our current solution already offers a Grafana instance, which serves as a powerful dashboard. This dashboard displays real-time metrics of validators, enabling users to access and analyze the data easily. To simplify the setup process, we have integrated our platform with a user-friendly Telegram bot, @p2pvalidator_monitoring_bot. Through this bot, users can quickly configure their personal dashboards by selecting the validators they wish to monitor.

    The live dashboard provides users with a comprehensive overview of all essential metrics related to their validators. These metrics are updated automatically every 20-40 seconds, ensuring real-time visibility into the performance of validators. This rapid update frequency enables users to respond to any changes or issues that may arise promptly.

    Furthermore, we understand the importance of historical data in analyzing validator behavior and identifying potential issues. Therefore, our platform collects and stores data on all active validators for up to one month. This means that users have access to historical performance data, allowing them to conduct in-depth analyses of their validators over time. Such insights are invaluable for optimizing performance and addressing any emerging concerns.

    In conclusion, our monitoring platform provides validator operators with a hassle-free solution, streamlining the monitoring process and offering real-time and historical data to support informed decision-making and efficient operations.

    System workflowโ€‹

    A user initiates a conversation with a Telegram bot and selects from options such as creating a new dashboard or connecting to support. When the user inputs the validator addresses they wish to monitor on the dashboard, our system verifies the authenticity of these addresses, confirming that they belong to validators. Then, the system generates the dashboard and sends the user their access credentials. Subsequently, the system resets the client's session to prevent potential 'double' events. This involves preserving the user's current position in the workflow, for instance, preventing the triggering of a dashboard deletion before its creation.

    Upon receiving a user's request to deploy a dashboard, their specified validator addresses are recorded in a key-value file (values.yaml) associated with their Telegram ID and subsequently committed to Git. ArgoCD, set to check the repository every 5 minutes, will recognize if there isn't a Grafana instance associated with the particular Telegram ID and proceed to deploy a new instance. As ArgoCD prepares the dashboard, GitHub Actions concurrently monitors the availability of this new instance. Once the instance is fully operational, GitHub Actions triggers a notification to the client, providing them with their login credentials.

    Our data collection process is anchored on utilizing exporters from the Blockchain. These exporters operate incessantly, amassing raw data directly from the Blockchain. Each exporter functions as an HTTP web endpoint for the scrapper, supplying plain text with specific metric values. Subsequently, this data is channeled into the Victoria Metrics cluster using VM insert, which timestamps each value. Ultimately, designated data is selected by a specific dashboard (Grafana instance) using VM select.

    In our current implementation, we provide insights on the following key metrics:

    • General indicators: we track session/era progression and staking data.
    • Validator data per epoch: we provide information on rewards points, active validators, and their position in the active set.
    • Era and epoch points for ParaValidators: we monitor ParaValidator points earned and their relation to the network's average, median, and 95th percentile.
    • Finality metrics (GRANDPA): we track blocks' prevotes and precommits, and their ratio to ideally processed blocks.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Team Code Reposโ€‹

    Project repo:

    Team's experienceโ€‹

    The P2P development team, part of the reputable validator and non-custodial staking platform P2P, is the main driving force behind our monitoring solution. P2P is well-known for its expertise in validating Substrate-based networks such as Polkadot, Kusama, Moonbeam, and Moonriver, as well as other networks like Solana (Lido in Solana) and Cosmos (Neutron).

    As a team, we have already successfully completed a grant for the development of Multiblockchain ETL, an indexer specifically designed for substrate-based networks. This indexer allows for the efficient indexing of events, extrinsics, blocks, and staking data from the on-chain environment. We actively maintain and update the Multiblockchain ETL indexer, ensuring its reliability and functionality. The code for this project is publicly available on GitHub.

    Given P2P's established expertise and solid reputation in the industry, we are well-equipped to carry out further development of our monitoring tool. Our focus remains on delivering a monitoring solution that brings significant benefits to the community, promoting transparency and empowering validator operators and stakeholders.

    Contactโ€‹

    • Registered Address: P.O. box 2775, 67 Fort Street, Grand Cayman, KY1-1111, Cayman Islands
    • Registered Legal Entity: P2P Staking, a Cayman Islands Company, registration number 381601

    Development Status ๐Ÿ“–โ€‹

    Current service already offers a convenient and user-friendly experience through a Telegram bot named @p2pvalidator_monitoring_bot. This bot serves as the gateway to our comprehensive validator monitoring capabilities, covering various aspects of validator performance.

    At the core of our product, we have developed an exporter that takes raw data and translates it into a format compatible with Victoria Metrics, our chosen data storage solution. The data is securely stored for one month, during which it is transformed into meaningful metrics. These metrics are then transmitted to Grafana dashboards, providing users with a visually appealing and informative monitoring interface.

    Through the Telegram bot, users have access to a range of features. On the user's side, they can deploy a personal dashboard, allowing them to monitor their validators efficiently. They also have the ability to destroy their personal dashboard when needed. Additionally, the bot provides support options, enabling users to seek assistance and receive prompt replies.

    On the admin side, there are several options available for managing the system. These include the ability to deploy/destroy Grafana instances, and ban/unban specific users. Admins can also engage in support-related tasks, such as replying to support inquiries and closing support conversations as necessary.

    By utilizing our Telegram bot, users can easily interact with our monitoring tool, deploy personalized dashboards, access support, and enjoy a seamless monitoring experience. Meanwhile, admins have the necessary tools to manage the system and provide timely assistance to users efficiently.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-Time Equivalent (FTE): 1.5 FTE
    • Total Costs: $29,000

    Milestone 1 โ€” Events and Dashboard UXโ€‹

    • Estimated duration: 1 month
    • FTE: 1.5
    • Costs: 14,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide a documentation page about how to self-host events exporter, grafana setup dashboard instance.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to run events exporter locally, set up Grafana instance, and auto-removing tool.
    1.Events exporterWe will create an events exporter (all on-chain events) to show events in the dashboard related to the selected validator addresses. This feature will track all on-chain events and present related events in the user's dashboard for their selected validator addresses.
    2.Telegram bot UI + support chat upgradesWe aim to rebuild user inference of a bot to add more interaction opportunities with the service. As well as we will improve communication with support. Instead of the current one-message ticket system, we will implement a more interactive conversation mode allowing for multiple messages dialog.
    3.Create a landing pageWe will create a landing page to ease user onboarding to the service.

    Milestone 2 โ€” Expand the functionalityโ€‹

    • Estimated Duration: 1 month
    • FTE: 1.5
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide a tutorial page that explains how a user can set up monitoring for selected validators. We show how our functionality works and give reasoning and explanations for all metrics that are shown to the user.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to self-host the telegram bot and check the functionality.
    0e.ArticleWe will publish an article that explains the user flow of our system and promotes using monitoring for validators operators.
    1.Telegram bot adding alerting based on eventsWe will introduce a feature that allows users to subscribe to specific events. This means users can opt to receive Telegram notifications when their chosen validators receive rewards, are elected into the active set, and more.
    2.Improve UX DashboardWe plan to streamline Grafana's interface by removing surplus controls, enhancing the quality of our charts, and implementing Kiosk mode. We aim to bolster security through provisioning measures, such as enforcing password changes for users.
    3.Cover monitoring for parachainsWe will add the support of the most popular parachains such as Moonbeam, Moonriver, Acala, Karura, Astar, Shiden
    4.Auto-remove instancesWe will develop a system that identifies and removes inactive Grafana instances.

    Referral Program (optional)ย ๐Ÿ’ฐโ€‹

    Not applicable

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Web3 Foundation Website and previous grants: Multiblockchain ETL

    - + \ No newline at end of file diff --git a/applications/Web3Box.html b/applications/Web3Box.html index b3288b1fb26..ac568e3bf10 100644 --- a/applications/Web3Box.html +++ b/applications/Web3Box.html @@ -4,13 +4,13 @@ Web3Box | Web3 Foundation Grants - +
    Skip to main content

    Web3Box

    • Team Name: Web3Box Labs
    • Payment Address: 0x2755213c8435F15D9929101357686a9C1Bec280A (USDC)
    • Level: 1

    Project Overviewโ€‹

    Overviewโ€‹

    The dashborad client for all assets management and display of the Polkadot Ecology.

    Project Detailsโ€‹

    Key Modulesโ€‹

    1. Dashboard/Multi-chain Wallet
    • Relay chains & Parachains Assets Management
    • Relay chains & Parachains Assets Portfolio

    Web3Box Dashboad Preview

    image

    Ecosystem Fitโ€‹

    1. Web3Box allows Polkadot ecosystem users to access Polkadot eco multi-wallet and check out the real-time polkadot dashboard in one-stop.

    2. Follow-up: Web3Box provides Polkadot users with risk assessment of parachains, so that Polkadot users can timely and accurately understand the risks of parachains; select the parachainsย with low risks for users to avoid those with high risks when making investment decisions.

    Teamโ€‹

    Team membersโ€‹

    • Name of team leader: Web3Box Founder Eric
    • Names of team members: Web3Box Marketing Director Andrew
    • More devs would be announced after passing the review

    Contactโ€‹

    • We will update after passing the review

    Team's experienceโ€‹

    Web3Box team is very experienced in software development and project operation. Team members are all aimed to be involved in Web3 Revolution. Team members have been participated in the defi project https://github.com/netswap, Netswap official website https://netswap.io/

    Team Code Reposโ€‹

    https://github.com/web3box-labs

    Development Statusโ€‹

    Web3Box has confirmed the overall architecture. And now, Web3Box is confirming the feature development points based on the architecture. At the same time, frontend UI design work is undergoing.

    Tech Detailsโ€‹

    • Client language: Electron.js React.js
    • Server language: Node.js
    • Build tool: Webpack

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 6 weeks
    • Full-Time Equivalent (FTE): 2
    • Total Costs: 10,000 USD

    Milestone 1 - Dashboard / Multi-chain Walletโ€‹

    • Estimated duration: 6 weeks
    • FTE: 2
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can install and operate Web3Box client.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article in our official Medium that explains what was done/achieved as part of the grant.
    0e.Implementations of APIs from third parties1. Using API from Subscan to get on-chain data, which would be implemented in the module of Dashboard Latest Transactions (Check out the Dashboard Preview) 2. Using API from Chainlink to get the real-time price of Polkadot assets, which would be implemented in the module of Dashboard Market (Check out the Dashboard Preview)
    1.Dashboard:Statistics and display of Polkadot users' assetsStatistics and display of the value of Polkadot usersโ€™ onchain assets, statistics and display of the value of input assets & output assets
    2.Dashboard:Assets pie chartPolkadot users' asset distribution pie chart
    3.Dashboard:Latest transaction displayView the lastest asset transactions of Polkadot users
    4.Dashboard:Real-time assets priceReal-time display of Polkadot eco assets' price
    5.Electron-based Multi-chain Wallet:Support Polkadot multi-chain assetsPolkadot ecological multi-chain wallet, including Polkadot, Kusama, Moonbeam, Astar, Acala, Phala, Litentry, etc.
    6.Electron-based Multi-chain Wallet:Polkadot multi-chain assets managementMulti-chain asset management, including asset sending, receiving and transaction record query

    Note

    • Web3Box team will finsih Milestone1, and then start the next Milestone about Risk Assessment, more details about risk assessment will be announced by the follow-up grant applicaiton.

    Future Plansโ€‹

    • In the short term, Web3Box team will complete the Milestone on time.
    • In the long term, Web3Box is aimed to become the most secure and comprehensive Web3 Portal Desktop Client.

    Additional Informationโ€‹

    How did you hear about the Grants Program? Twitter

    - + \ No newline at end of file diff --git a/applications/Web3Go.html b/applications/Web3Go.html index 93cf6b6d668..c8e7d1274c4 100644 --- a/applications/Web3Go.html +++ b/applications/Web3Go.html @@ -4,7 +4,7 @@ Web3Go | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Web3Go

    • Team Name: Web3Go
    • Payment Address: 0xD57e28773c92E6fB9D9Fb164889886cd360074BE(USDT)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Web3Go is an open data platform that focuses on the formatting, visualization, sharing, and collaborative analysis of the on-chain data generated in the Polkadot ecosystem.

    Due to the explosion of Defi, NFT, and metaverse, there is massive amount of data generated on the blockchain every day, which is very important information for the media companies, investment institutions, and blockchain participants. However, it is difficult for non-professionals to obtain and understand these data. Beyond all doubt, data is valuable. Our project is to build a data platform for the Polkadot ecosystem and provide a series of toolsets so that everyone can easily create visualized results of data analysis. We are able to track smart contracts on-chain, and various parameters like stakings and CDPs of different Defi protocols, NFT circulation, and cross-chain assets on Polkadot ecosystem, and make these data formatted and persisted. With the help of the smart contract on Substrate parachain, non-professionals can publish their data needs on the platform and use rewards to motivate professionals to help them perform data analysis; for professionals, they can publish their own professional analysis for everyone to use paid or for free. In the second situation, they can get the reputation from the community. In the end, we broke the monopoly of some existing companies on data analysis and interpretation, so that everyone can truly enjoy the true value behind blockchain data.

    We believe that with the development of Polkadot ecosystem, more on-chain data will be generated and the value behind the data is giant. Currently, there is still a gap between professional users and common participants in terms of the technical know-how of data. Using the infrastructure and tools provided by Web3Go, everyone can easily create, publish and share their point of view in the form of nice charts based on the real data which has been formatted from the blockchain.

    The interpretation and analysis of data should not be in the hands of certain centralized professionals, but rather all users should have a say and benefit from it. Our vision is to build a Polkadot-based data analytics infrastructure, toolset, and incentive system where everyone can publish and be rewarded for related data tasks. Finally, an open and free data platform will be built to surface the signals of what is happening in the Polkadot system.

    Project Detailsโ€‹

    Architectureโ€‹

    Componentsโ€‹

    1. Indexer: an indexer of blockchain is used to extracts the on-chain data and saves the data in the database in formatted manner. Since the Polkadot network is composed of relay chain and parachains, each parachain can define its own Event or call, so each indexer of the parachain must be adapt to its metadata. So there will be multiple instances of the indexer of Polkadot.

    2. Data Board: data board is the visualization result of data analysis created by analysts or community member, which can display the analyzed and customized information on the Polkadot ecosystem such as a token transaction or holders, an NFT transfer, and history of the transaction, the statistics of a Defi protocol, or some special event like parachain auction, and governance.

    3. Contract on Substrate: We will use smart contracts on the Substrate nodes to demand, publish, share and reward the data activities within Web3Go. There are primarily two kinds of players involved in the smart contract: data demander, who has a need of professional, visualized results of data analysis regarding events that happened on the blockchain. Data demanders will publish the needs through the contract with bounty to incentive whoever fulfill these needs; on the other hand, data analyst, who has professional knowledge and skills can take on data tasks, or they can publish and share any data board they have created to the community in a paid or free manner. This smart contract will incentive more people to contribute to the data activities in the ecosystem since those who create more valuable data boards will gain a higher reputation.

    4. Query Module: The data query module provides a user interface to the data analyst to generate data boards. Because data stored on the blockchain is in the form of key-value pair, it is very hard to use and analyze the on-chain data directly. With the UI provided by the query module and along with the chart display module, the analyst can take advantage of the formatted data and visualize it in an automatic and customizable manner. The data will also be automatically synchronized with the blockchain, so updates will be reflected on the data board in real-time.

    5. Chart Display Module: The chart display module is used to visualize the result of data analysis and is the main component of the data board. The chart display module can provide different charts like bar charts, pie charts, scatter plot, and so on.

    6. Subscription Module: For each created data board, the data demander of this data board can subscribe to the notification signaled from this board. The notification can be triggered by a big transaction of a token or an APR vary of a Defi protocol. This module provides the functional for the subscription.

    7. Label/Tag Module: this module will give the address different labels basing on its historical activities on the blockchain, e.g. token transfer, Defi participation, etc. It is survied that at least more than 50% of the total addresses on Blockchain are inactive. So this module will filter the active address according to its activities such as "Big Whale", "High Activity" and so on. The labeled addresses are a very good dataset that can be monitored to signal what is happening on the blockchain.

    8. Data Mining Module: data mining module is used to look for regulations and patterns in large batches of data come from blockchain. data mining is widely used in some traditional industries like Retail, manufacturing, financial and financial insurance, but we believe that this technology will benefit the blockchain industry as well. The module will dig through historical data to discover hidden connections and predict future trends in the specific area of the blockchain, like token price prediction, Defi earns prediction, etc.

    9. Community Module: The community module is a public place where data activities participants can communicate. For example, data demanders can publish their demands, the data analysts can take on the tasks or share their own data boards, and the most welcome data boards will be listed here.

    Technologiesโ€‹

    • Subquery is a blockchain indexer for Polkadot, Kusama, and other parachains. We will rebuild and customized this framework to fulfill our requirements.
    • Node.js
    • Docker
    • Substrate
    • Rust
    • Machine Learning
    • Python

    PoCโ€‹

    A web application with three data boards has been built as a proof of concept. We have used the architecture mentioned above to index three kinds of tokens: LIT, ATA, and POLS. With nice charts and tables, the transaction, holders are visualized and some addresses have been labeled according to the labeling rules; the second data board lists the crowdloan event on Kusama networks. This data board lists the contribution and participants for each project which attends the crowdloan event; the third data board tracks the CDP(collator debt position) status of Karura lending system and provides the real-time status of each account.

    Ecosystem Fitโ€‹

    We have found several successful data analysis projects in the Ethereum ecosystem. Each project focuses on a specific area: Defi tracking, token tracking, wallet profile tracking. But currently, there is no data analysis project designed for Polkadot. Due to the unique structure of the Polkadot network, there will be more interesting data generated in the network, so we believe the whole community needs a data analysis tool as soon as possible.

    Similar projects

    What makes us different is,as a part of Web 3 community and Polkadot ecosystem:

    • The first project focuses on the data analysis for Polkadot world
    • Designed to let everyone can benefit from the value of data in the Polkadot world and make the valuable data public to everyone, not in the hand of one centralized project
    • An incentive mechanism that gets everyone involved and participates in the data activities.
    • A comprehensive analysis not only focuses on one area but will include all data like a cross-chain asset, governance, auction, Defi, staking, and token.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Hao Ding: VP of Litentry. MSc of University Stuttgart.
    • Yifei Wu: Substrate lead of Litentry. PhD of Tokyo University.
    • Han Zhao: Substrate core dev of litentry. MSc of University Stuttgart.
    • Minqi Wang: Backend and contract developer. Master of University Columbia.
    • Yunjian Bian: Software Architect of Litentry. Bachelor of University Suzhou.

    Contactโ€‹

    • Registered Address: T5-1023, Europe and America Finance City, Yuhang district, Hangzhou, Zhejiang of China
    • Registered Legal Entity: Hangzhou Liteng Network Technology Co., Ltd.

    Team's experienceโ€‹

    All team members of Web3Go are from Litentry. Litentry is a DID (distributed identity) solution provider in the Polkadot ecosystem. Litentry has been granted a grant from the Web3 Foundation.

    Web3Go team members have strong engineering background: Han Zhao, Yifei Wu and Minqi Wang are responsible for the development of Litentry's parachain (https://github.com/litentry/litentry-parachain), Hao ding and Yunjian Bian are responsible for the on-chain data indexing And front-end and back-end development. (https://github.com/litentry/data-analysis)

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    • WebSite: visit this url: https://www.web3go.xyz can take a look at the current developement progress of the website.
    • Data board-Karura CDP: This data board tracks and visualizes the real-time CDP information of Karura, and provides the historical analytics and real-time CDP status of each participant.
    • Data board-KSM crowdloan: This data board tracks and visualizes the real-time Kusama crowdloan on each lease, including the total amount of each project, address, and amount of each contribution.
    • Data board-ERC20 Token: This data board tracks and visualizes the real-time and historical transactions, amounts, and addresses of ERC20 tokens including LIT, ATA, and POLS with analysis.
    • UI Mock-ups: here saved the UI design and mock-up of Web3Go, it is keep updating.
    • Semi-automatic chart generation: This module is to let users can generate visualized charts automatically by simply writing SQL language based on our existing indexed and formatted data. Currently the supported chart is bar chart, line chart, and pie chart. The word "semi-automatic" means that the user has to write SQL to generate the chart.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 40,000 USD

    Milestone 1 โ€” Website, customizied indexer,Semi-automatic chart generation and databoardsโ€‹

    • Estimated duration: 2 month
    • FTE: 2
    • Costs: 25,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use the existing data board, and use the UI to create/publish their own customized data board
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains the concept and vision of Web3Go
    1.aIndexerWe will develop our customized indexer on the top of Subquery to make it more compatible to our scenario in below two areas: 1. Handle data/event and extract the result to external storage: currently the indexed data is saved in the built-in Postgres database due to the design of the framework of Subquery. And we have to retrieve the data from Postgres to our database again, it is very inefficient. We are going to build two new modules: the post-process module and the logic handling module, which can directly save the data to our database directly according to our logic module. in this way, the data and logic part can be decoupled.
    1.bIndexer2. Enable HTTP/HTTPS module to retrieve external data when fetching block: currently, the framework does not support retrieving data externally during fetching the block. But this case happens from time to time: retrieving the NFT metadata from IPFS can be one example. We will implement this module on top of the Subqeruy existing framework.
    2.UI Module:general WebAppWe will continue on the development of the web application to implement: user sign-in/sign-up, categorization of data board, social interactions functionality including like and share, subscription of a specific event comes from a specific data board, UI redesign and refinement, documentation and tutorial.
    3.3 more Data Boards:We will create 3 more data boards of other projects in Polkadot ecosystem that have already won the bid in the Kusama auction(or Polkadot auction if it happens), so we will have more valuable data boards on our platform and user collect their board basing on our data and tools. Three projects are planned to index: RMRK(NFT circulation), Moonriver(stake tracking) and Parallel(Defi tracking). (The projects might be changed but the number of data boards is fixed)
    4.UI Module: semi-automatic chart generationThis part is the core value of Web3Go, which can help users generate charts based on existing data. We will optimize the UI and make the chart more charming and easy to use.
    5.Support more Kusama Token:We will support the token analysis for KSM, MOVR, KAR, kUSD, Heiko instead of ERC20 token.

    Milestone 2 โ€” More databoards, fully-automatic chart generationโ€‹

    • Estimated Duration: 8 months

    • FTE: 2

    • Costs: 9,000 USD

      NumberDeliverableSpecification
      0a.LicenseApache 2.0
      0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use the existing data board, and use the UI to create/publish their own customized data board
      0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
      0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
      0e.ArticleWe will publish an article/workshop that explains the concept and vision of Web3Go
      1.UI Module:support more charts in semi-automatic chart generationwe will continue optimizing the automatic generation of charts, to make it support more kinds of charts like scatter charts, area charts, and tables.
      2.UI Module:fully-automatic chart generationWe will enhance the user interaction of generating charts, provide the "drag and create" module for the user to generate charts. In this case, the user can generate charts with the same complexity as writing SQL can do. This functionality will provide a more easy way for the user to generate complicated charts who does not know program with SQL.

    Future Plansโ€‹

    • As our vision is to let "everyone enjoy the value behind the blockchain data", we will design the token economics to let more people involved in the whole data board activities. The rough idea is to design three kinds of roles: data demander, data analyst, and data validator, and introduce the token incentive to incentive the community to create more customized and interesting data boards, and this will be done through the parachain system. We have already started doing the research on the token economics design, and after this grant is finished, parachain development will be started.
    • As our team is a sub-team of Litentry, so we have a strong development team , operations team, a 60k+ community, and have a good relationship with most of the projects in the Polkadot ecosystem. All of the above has provided us a strong foundation of success. we want to be the best data analysis project in the Polkadot ecosystem, and even collect more data across other public chains in the future.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Web3 Foundation Website and personal recommendation.

    - + \ No newline at end of file diff --git a/applications/Whiteflag-on-Fennel.html b/applications/Whiteflag-on-Fennel.html index f87f2251986..a199720745e 100644 --- a/applications/Whiteflag-on-Fennel.html +++ b/applications/Whiteflag-on-Fennel.html @@ -4,7 +4,7 @@ Fennel Protocol | Web3 Foundation Grants - + @@ -26,7 +26,7 @@ The basic architecture was designed with extensibility in mind; identity and signaling applications should be able to easily build on the runtime with expanding available features and continued support for existing features.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We heard about the Grants Program from the Web 3 Foundation Website, as well as personal recommendations from Polkadot community members.

    Our first grant was completed in the first quarter of 2022 and built out the basis for our blockchain and the first set of Whiteflag features.

    - + \ No newline at end of file diff --git a/applications/XPredictMarket.html b/applications/XPredictMarket.html index 0c02604da35..b2d9d093dd3 100644 --- a/applications/XPredictMarket.html +++ b/applications/XPredictMarket.html @@ -4,7 +4,7 @@ X Predict Market | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ Having worked in the crypto currency exchange, most of our team members have become seasoned smart contract developers after their experience in DeFi lending and DEX development. Our team members are proficient in Rust, C++, Solidity, Java, JavaScript and other development languages. Among whom Liang Wenzhu is certified by the Parity substrate course as Outstanding Student and has led other members of the team to systematically study substrate.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    We have completed the planning of the product prototype, the design of the UI diagram, and the technical architecture, and are beginning to develop.

    Documents about the technical architecture can be viewed at the following link๏ผš

    https://github.com/XPredictMarket/docs/blob/master/Technial.md

    For product UI diagrams, you can check the following links:

    https://github.com/XPredictMarket/docs/tree/master/ui

    White paper link๏ผš

    https://x-predict.com/X_Predict_market_Whitepaper_en.pdf?v=1.0

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestoneโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation of the code and basic tutorials. It explains how the team creates predictions and how users make predictions.
    0c.Testing GuideWe will conduct unit test on all modules to ensure they can function properly. In this guide, we will describe how to run these tests.
    1.Creating proposal moduleThis module provides a method for creating prediction proposals using specific parameters, such as prediction topics, options, settlement currency, transaction fee ratio, and prediction period.
    2.Prediction participation moduleThis module provides the functions of using settlement tokens to participate in predictions, swapping prediction tokens, and providing and removing liquidity.
    3.Results uploading moduleThis module provides the function of submitting results through stake node.
    4.Market settlement moduleAfter the results are officially announced, users predicted correctly can exchange their prediction tokens with settlement tokens with equivalent value.Users who provide liquidity automatically remove liquidity after the end and share fees.

    Future Plansโ€‹

    1. In the second phase of the product development plan,multiple incentives are designed for users. In addition to gain rewards by predicting correctly, users also have rewards for predictive mining, staking, predicted leaderboard, liquidity providing and yield farming, and etc. Also, there are additional rewards for prediction topic creators and community nodes. The specific rules of this part of the reward are introduced in the white paper.

    2. In the third phase of the product development plan.The platform will open up community autonomous nodes, and reporting and supervision mechanisms. Each user will be able to become a governance node by staking governance tokens. The governance node can upload the results and share the revenue from withdrawal fee. The governance node is authorized to upload results and accept the supervision of the entire network. When the result submitted by the node is different from reality, any user can initiate a report through pledge, the reported person will be punished, and the reporter will be rewarded.

    3. In the third phase of the product development plan.Optimize an easier-to-use stake node. In order to encourage more non tech-savvy users to explore the stake node, we will develop a graphical operation interface for the common users to upload results after staking tokens, pass the review and become a staking node.

    4. In the third phase of the product development plan.Add the governance voting pool of the parameters and development of the platform it self. The range of voting concludes the settings of some parameters of the platform, future revisions, iterative upgrades of the platform, such as adding new features.

    5. In the fourth phase of the product development plan, a more designated and user-friendly dashboard will be added to display platform statistics.

    6. In the fourth phase of the product development plan, More than simple prediction, it is a way for actively socialize and interact with passion. Users will be able to discuss topics by predicting topics, and join a forum-style communication system, with social functions such as friendsโ€™ group and group chats.

    - + \ No newline at end of file diff --git a/applications/Xcavate.html b/applications/Xcavate.html index 18c5f78151f..7066974080b 100644 --- a/applications/Xcavate.html +++ b/applications/Xcavate.html @@ -4,7 +4,7 @@ Xcavate | Web3 Foundation Grants - + @@ -49,7 +49,7 @@ https://www.linkedin.com/in/neeraj-choubisa-a4952b202/ https://www.linkedin.com/in/ren%C3%A9-h%C3%BCrter-36084b249

    Development Status ๐Ÿ“–โ€‹

    We have been heavily involved in learning all things associated with the Polkadot & Kusama Ecosystem. This has been coupled with the idea of bringing land and property from its current state into the web3 ecosystem. We have been meeting with top-level industry leads, government officials and developers. Robin Ejsmond-Frey and Nico Morgan from Parity have been a tremendous help by supporting us with information about the W3F grant application process and recommendations to attend Hackathons and the Polkadot Decoded Event London. As well as as number of forums to help our substrate development knowledge.

    We have been taking time to play with Substrate to form initial local nodes. We feel we are now ready to build the initial POC for this project in the Rococco test environmenment.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Initial POC of lending protocolโ€‹

    We will build on the excellent work we have achieved developing the Real Estate NFT marketplace for the hackerearth.com hackerthon.

    In the first milestone, the features for the PoC will be implemented and tested by limited users. We will adapt FRAME pallets to create a unique structure of a central community loan pool that acts as a risk reducer to allow individual loan stakers to lock and unlock native XCAV coins quickly and easily, rather than being committed to the full term of a particular loan. This will provide an attractive low risk investment opportunity and increase community confidence in the network while eliminating any delay in providing the funds to the real estate development project, once all the necessary checks have been completed. This loan pool structure could be applied to many different chains in future projects. The execution of various stages of the dApp specific logic will built using ink! smart contracts.

    NumberDeliverablesSpecification
    0a.LicenseApache 2.0
    0b.DocumentationThe documentation will be provided to show the whole architecture of the Xcavate Network.
    0c.Testing and Testing GuideThe testing guide will be provided to test each component.
    0d.VS Code InstructionsWe have struggled to create docker images and a container, which allows interaction between the frontend, backend & node however VS code is working as expected.
    0e.TutorialWe will write a tutorial about how to use Xcavate Network.
    0f.ArticleWe will write an article published on media channels.
    1Xcavate Node RepoWe will create a customized chain node with Substrate 2.0 Framework.
    2Xcavate Loan App RepoAll smart contracts will be written in Ink! to handle all the on chain runtime events related pallet functions such as; 1) Assess loan application criteria 2) Creation and management of multisig wallet 3) Minting and transfer of LAND NFTs 4) Defining and executing the loan APR structure 5) Monitor and execute real estate build stage checks 5) Deliver tranches of loan amounts to wallets 6) Manage the loan repayment and NFT transfer.
    3.Loan management pallet Manage loan application Land details' Registration Manage loan interest percentage * Based on land and experience Approve/Reject request
    4.Staking pallet User can stake native token Calculate APR * Distribute payouts
    5.DAOThe PoC will have a basic voting structure to ensure rewards can be given to the real estate build stage checkers (As we progress in to the MVP stage this will be expanded to form a full governance structure).

    Future Plansโ€‹

    We are talking to Subwallet about integrating the KILT protocol DIDs in to their wallet for a smoother and simpler user experience. Once we have built the initial POC then on to the MVP and GTM. We have already started the white paper as well as developed a pitch deck to demonstrate the potential of the system to; investors, partners and eventually XCAV coin holders. We have started a social media campaign in order to build a community now and through the dApp build & testing stages.

    Additional Information โž•โ€‹

    We will be attending the 2023 Polkadot Decoded event. We are keen to network and expand our partnerships across the Dotsama Ecosystem, while helping to build much needed real estate investment opportunities to a global population.

    - + \ No newline at end of file diff --git a/applications/ZK-Snarks tutorial.html b/applications/ZK-Snarks tutorial.html index e27e21278aa..4e93143de5f 100644 --- a/applications/ZK-Snarks tutorial.html +++ b/applications/ZK-Snarks tutorial.html @@ -4,7 +4,7 @@ ZK-Snarks tutorial | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ | 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | | 1. | The pallet | Pallet allows storing a verification key and the proof on the blockchain and run the on-chain verification. With the first milestone we will provide a dummy version mechanism, which is going to be replaced with the grooth16 in the next milestone. | | 2. | Blog post | With the first blog post we would like to focus on describing the audience the Zk-Snarks concept: A/ what are the zk-snarks, B/ describing the โ€œBobโ€ problem and how they can solve it. C/ describing the process of creating proof D/ creating a โ€œcircomโ€ example where we generate a proof. |

    Milestone 2โ€‹

    Implement the on-chain proof verification mechanism followed by series of educational materials.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a tutorial (which will be a part of the blog post) that explains how a user can (for example) spin up Substrate nodes and upload a verification key and the proof. This will show how the new functionality works.
    0c.Testing and Testing GuideWe will provide unit tests for the proof verification mechanism.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Research notesMathematical calculations based on Groth16
    2.Groth16 proof verification methodImplement Groth16 proof verification method which will be used by pallet
    3.DemoCreate a demo, where we will use a 3-rd party tool to verify a solution & where we Alice could be rewarded for finding a solution.
    4.Circuits in circomPrepare a circuits in circom, which will describe our problem
    5.Blog post: Tutorial Groth16 (Part 1)describing the groth16 & running "circom proof" from previous post with the Rust Unit test / CMD
    6.Blog post: Tutorial Pallet (Part 2)updating the pallet with the groth16 & running an example from the previous tutorial with the PolkaJS
    7.Youtube videoYoutube video tutorial explaining the concepts from the blog posts
    - + \ No newline at end of file diff --git a/applications/Zeeve_Parachain_deployment_zoombienet_testing_automation.html b/applications/Zeeve_Parachain_deployment_zoombienet_testing_automation.html index f2ac6853805..c0b5fb0ecf0 100644 --- a/applications/Zeeve_Parachain_deployment_zoombienet_testing_automation.html +++ b/applications/Zeeve_Parachain_deployment_zoombienet_testing_automation.html @@ -4,13 +4,13 @@ larch - Zombie-net Automation | Web3 Foundation Grants - +
    Skip to main content

    larch - Zombie-net Automation

    • Team Name: Zeeve

    • Payment Address: Ethereum (USDT/USDC) 0x5E1257E928aa42E3D0cd9E2A7537E37D108D811B

    • Level: 2

    Overviewโ€‹

    Blockchain adoption is happening at a very rapid rate, with a lot many use cases being implemented and seeing the light of the day. The concept of the parachain enables the possibilities further. While we focus on building the use cases, code them and implement the business logic of it, including the creation of Parachain and then further logic running upon it, we majorly underestimate the DevOps activity to deploy, maintain, scale and manage the parachain itself. This includes initial launch of the parachain, its thorough testing using Zombie-net and scaling it further by providing support for users to create and deploy validator, full and archive nodes with ease as well as to have secure RPC endpoints. The most deficit we see is around advanced analytics and proactive monitoring to ensure a production grade incident management of networks and nodes.

    Project Detailsโ€‹

    Zeeve will provide a GUI tool to setup the new Substrate zombie-net network with in-depth and flexible configurations in few clicks supporting K8 and native VMs whichever fits the parachains better.

    A GUI will be built to allow a quick setup of the relaychain, parachain with zombie-net with the desired capabilities to test multiple configurations. This in turn will allow the developers and parachain teams to try multiple chain configurations while setting up the parachains with Zombie-net, as well as to choose different nodes to try and test for the best possibilities on the parachain.

    This not only will allow configurations on the parachain side but will also allow you to pick from a set of predefined DSL templates on Zombie-net as well as upload the new templates without needing to write the code. The graphical control panel will support all the other configurations or operations required to enable the developer or parachain team to test with as much flexibility as required. These operations include:

    • Start - Start the network with configured info (templates)
      • Start the network for either evaluation or testing
    • Delete - will stop the processes and delete it
    • View Info - view execution logs and command

    Test result and logs

    The interface will allow the developer to test and see live logs of the test run, post run results and logs on the aforementioned interface. Furthermore, a stack of Prometheus and Grafana will allow easy monitoring of the Zombienet.

    Templating

    The control panel will also allow the developer or the parachain team to one-click replicate one of the existing zombie-net configurations, save as template or pick from previously saved template and re-create a new test with some rapid tweaks to it.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Ghan Vashishtha

    • Sankalp Sharma

    • Jasti Sri Radhe Shyam

    • Antar Basu

    • Swati Sharma

    • Gowrish K

    • Abhishek Kumar

    Contactโ€‹

    • Registered Address: 1603 Capitol Ave Ste 310, Cheyenne 82001, WY

    • Registered Legal Entity: Zeeve Inc.

    Team's experienceโ€‹

    Founded by a team of experienced professionals and entrepreneurs from industry, Zeeve's co-founders collectively have over 45+ years of experience in technology, product development, and various business verticals. Zeeve has built an enterprise-grade no-code Blockchain Infrastructure Automation platform that enables Enterprises, Blockchain Startups, Blockchain Consulting Companies and Web3 Developers to deploy Blockchain nodes and Decentralised Apps within minutes, and manage them with advanced analytics and real-time alerts. In June 2022, the Startup raised $2.65 Million in a Seed Round from Leo Capital and Blu Ventures. It plans to deploy the funds towards product development, augmenting the technology team and enhancing its reach among DApp developers and global corporations, please consider visiting our prior work.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Before applying for the Web3 Foundation Grant, the Zeeve team has built a DevOps automation for Polkadot and other substrate chains, also created substrates based relay chains:

    • Automated Polkadot deployments including validator nodes, archive nodes here

    • Automated Kusama deployments including validator nodes, archive nodes here

    • Created a relay chain on substrate with some customisations done at the core to accommodate the tokenomics and custom reward mechanism here

    • Published a blog post about the usage and implementation of parachains

    • The focus for Zeeve will be automating the parachain deployments, dedicated node setups and help with faster testing with zombie-net.

    • Spoke with David Hawig, Richard Casey and Gautam Dhameja from the Parity team regarding the development of Zeeve and the Web3 Grant application

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4 months

    • Full-Time Equivalent (FTE): 4 FTE

    • Total Costs: 30,000 USD.

    Milestone 1 โ€” Implement Core Zombie-net Automationโ€‹

    • Estimated duration: 60 days

    • FTE: 4

    • Costs: 20,000 USD

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) create a new Substrate based Zombie-net nodes and initiate testing, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.Standalone ExecutableWill provide standalone executable that start the GUI service and other corresponding
    1.Initial AutomationWe will build the core GUI driven automation to create and deploy the substrate based Zombie-net configurations including relaychain and parachain configurations.
    2.ConfigurationParachain configuration is critical and complicated, we will provide the GUI based pick and choose for genesis parameters and chain configs to start with parachain setup for the desired Zombie-net
    3.Node type supportImplement setup of all node types including Full node, Validator node and Collator node for the respective relay chain and parachain within the configured Zombie-net.
    4.Cloud agnostic setupThe larch setup will be cloud agnostic and it can be installed on the choice of cloud (Linux x86_64 based), instructions and documentation will be provided for the same.
    5.Network ManagementImplement the larch tool with a user-friendly interface, features for execution info, network deletion, template cloning, and management, along with robust error handling, for seamless setup of networks and templates.

    Milestone 2 โ€” Monitoringโ€‹

    • Estimated Duration: 20 days

    • FTE: 2

    • Costs: 10,000 USD

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) create a new Zombie-net, test and setup monitoring for it, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.Standalone ExecutableWill provide standalone executable that start the GUI service and other corresponding
    0e.ArticleUsing our PR channels, we will publish an article that explains the high-level overview of automation as part of the grant, followed by a set of extensive examples.
    1.Design monitoring strategyThe Zombie-net doesn't provide any embedded monitoring tool, we will with the zombie-net setup automation, automatically setup prometheus and Grafana while configuring the zombie-net.
    2.Setup DashboardThe deployment done for Prometheus and Grafana will show standard Dashboard having system resource and zombie-net specific details shown on the aforementioned Grafana GUI Dashboard.
    3.ActivityThe system will log all the activities and operations perform by the different users.

    Application Mockupโ€‹

    Following are the mockups for high-level application operations, these are subject to change during development basis the requirement and behaviour.

    Dashboardโ€‹

    Dashboard

    Zombie-net network listโ€‹

    List all created Zombie networks

    Create a new Zombie-netโ€‹

    Zombie-net Settings

    Zombie-net Relaychain Configuration

    Zombie-net Parachain configuration

    Zombie-net Collator configuration

    Zombie-net HRMP configuration

    Relaychain, Parachain, specfile and WASM templatesโ€‹

    Zombie-net Configuration templates

    Zombie-net WASM image templates

    User activity and operation historyโ€‹

    User activity and operation history

    Technology Stackโ€‹

    • ReactJS

    • NodeJS

    • Apache/Nginx

    • TailwindCSS

    • System Scripts

    • Kubernetes/Podman/Docker

    • Prometheus, Grafana, Telegraph

    Future Plansโ€‹

    • We will promote the project by giving talks in the community, writing tutorials and videos.

    • We will spread the project in Zeeve's developer and client community of 15K+

    • We will also work closely with the developers and clients of the Parity ecosystem for getting feedback and refine our project.

    • Our long-term plan is to make the tool become one of the default Parachain tools for the Parity ecosystem.

    • We will also add more followup, integration with the Zeeve enterprise platform allowing more flexibility for enterprises to built and deploy use case or application specific parachains.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website / Parity team / a conversation with Richard Casey.

    - + \ No newline at end of file diff --git a/applications/ZeroDAO_Network.html b/applications/ZeroDAO_Network.html index 64e63869d6b..9fe6201dc55 100644 --- a/applications/ZeroDAO_Network.html +++ b/applications/ZeroDAO_Network.html @@ -4,13 +4,13 @@ ZeroDAO Network | Web3 Foundation Grants - +
    Skip to main content

    ZeroDAO Network

    • Team Name: ZeroDAO
    • Payment Address: 0xEBCDa7c73EB5Dd7a4314cFf395bE07EB1E24c046

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    We define ZeroDAO as a public resource, including a social network, a reputation system. the ZeroDAO social network solves the incentive dilemma that currently exists in blockchain social networks, while incentivizing good behavior makes good behavior disappear. Imagine what Twitter would look like if you could get $1 for posting a tweet. Two-factor theory even concludes that security, salary, fringe benefits, good pay is not Motivators but Hygiene factors. Hygiene factors that do not give positive satisfaction or lead to higher motivation.

    ZeroDAO social network solves the incentive dilemma by amplifying social motivation and internalizing external motivation.

    In the ZeroDAO network, we still quantify user contributions and settle them into Tokens, which we call social currency. It is frozen and at some point assigned to users trusted by the owner, it is also social currency and goes on to be shared. The user's social motivation is amplified. We use to shared information, now we share value.

    ZeroDAO social network brought us the reputation system and we proposed the TIR algorithm to compute the graph and obtain the reputation of each user. TIR is difficult to compute but easy to verify on-chain. This feature makes ZeroDAO's reputation system completely decentralized. At the same time, it has strong ability to prevent Sybil Attack to meet the security needs of financial products and on-chain governance. ZeroDAO also brings credit finance, zero-cost payments, and other applications to the blockchain.

    Project Detailsโ€‹

    Social Networkโ€‹

    1. The application quantifies user contributions and transfer social currency to A. Pending Token is frozen and cannot be used.
    2. The system periodically distribution of A's social currency to its trusted [B,C,D]. A small part of social currency is unlocked to the owner.
    3. Forming a value-sharing network. B, C & D also share their social currency, forming a value sharing network.
    Social Currencyโ€‹

    • Reserve Reserve the owner's free balance. The percentage can be adjusted by the community.
    • Share Transfer to the social currency of users trusted by the owner.
    • Fee Analyst's fee.
    • Burn Share to all users.
    • Reward pool Used to solve the verifier's Dilemma.

    Reputation Systemโ€‹

    TIR( Trust-Influence-Reputation ) Algorithmโ€‹

    The TIR algorithm is inspired by Google's text retrieval algorithm for search engines. It is used to replace the vulnerable PageRank algorithm and has similar capabilities to TrustRank, but is simpler to compute and requires no iterations. TIR draws on its idea by finding high-impact users in the network as seed users, setting the highest score for them, and then passing the reputation on to other users through trust relationships.

    The TIR algorithm relies on two assumptionsโ€‹
    1. High-influence users are less likely to trust fake users
    2. The longer the trust, the more credible it is
    Procedures of calculationโ€‹

    1. The set of nodes with the largest number of passes through all the longest shortest paths in the graph is selected as the seed users. The larger the network and the higher the account retention amount, the more difficult it is to cheat.
    2. For example, we want to calculate the reputation of user D.
    3. Set the reputation of the seed user to ๐‘…max , get the reputation of the seed user in the last round ๐‘…seed0.
    4. Calculate the shortest weighted path Seed -> A -> D from the seed user to theD user.
    5. The path weight is the natural logarithm of the difference between the reputation values of the two users in the last round, and the minimum value is 1.
    6. Calculate the reputation ๐‘…a1 passed at node A : Take the initial reputation value of Seed, divide it by the number of users Trusted by Seed, and divide it by the path weight.
    7. Calculate the path weight from node A to node D in the same way and calculate the reputation of the final pass to node D. The sum of the reputation values of all seed passes is the final reputation of the target user.
    Easy to verifyโ€‹

    The TIR algorithm is extremely resource intensive to run on the blockchain, but verification is very simple, with the core verification requiring only 20 or so lines of code in substrate.

    Sybil Attack resistanceโ€‹

    So far, the algorithm is still not able to prevent Sybil Attacks.

    The algorithm will pick to cheat nodes when the attacker constructs a graph that is more favorable to it (e.g. more fake nodes and trust). Although we can raise the cost of an attack by setting higher account retention balances, raising fees, or raising gas, and expecting the network to be large enough so that the attacker does not have enough wealth or benefit to attack the network. But this also raises the cost for honest users, which is not elegant, and does not guarantee mathematical security.

    Hall of Fameโ€‹

    ZeroDAO uses a simple approach. By electing the Hall of Fame through the community, the distance from the Hall of Fame is added to the seed selection algorithm. The attacker has zero or very little reputation, while users who need more than a certain reputation can participate in the election. The attacker cannot join the Hall of Fame and cannot be seed, and the attack fails. We computed circles, a social network with 100,000 on-chain users, which was also subject to sybil attacks. We selected only 20 Hall of Fame users and the algorithm worked well. You can find the calculation results here for round3 without the Hall of Fame, and round4 with the Hall of Fame.

    challengeโ€‹

    The reputation system is implemented through a challenge model. The system has two roles, analyst and validator. The analyst updates the reputation after staking. The validator monitors the correctness of the data and can challenge the result after staking and upload the path. At this point the system still does not compute the path. Other validators, if they find errors in it, only need to point out errors in individual paths. The system verifies the calculations and determines who is correct at this time. The sub-challenge mode significantly improves the efficiency of the system.

    collusion attackโ€‹

    Collusion only affects social finance and has little to no impact on reputation systems. The collusion attack here is the unlock of social currency that should be frozen through dishonest trust relationships. First, ZeroDAO allows users to not share, just like in the real world, where they have the right not to share but lose certain conveniences in using the eco-product. We have the following options.

    • Minimum number of trusts: For example, if Alice trusts 3 users and the minimum number of trusts is 20, then the amount allocated to each user is not 1/3 but 1/20 of the total amount. the remaining part is waiting for the next allocation. So users who do not want to share only need to trust as few other users as possible. After the minimum trust number is exceeded, the amount will be split very small and transaction costs (gas) will become significant.
    • Burn: Partial burn substantially increases the cost of evil nodes.
    • Front-end SDK: Wallets or security agencies can monitor user behavior off chain, give warning messages in the UI for risky users, and prevent other users to trust.
    • Negative propagation: The TIR algorithm supports propagating negative values to users who trust the evil user.

    Applicationsโ€‹

    The social finance, reputation system and zero-cost payment will lead to many exciting applications.

    • Traditional social network transformation: The ZeroDAO network doesn't care where the Dapp's data is stored, so it is very adaptable and traditional social networks only need to add a Trust button to connect to the ZeroDAO network.
    • Radical Social Network: Reputation systems and trust relationships make possible a new model of social networking, and we propose a reverse communication social network, where users post content that is not pushed to the feeds of their followers, but to the feeds of their trusted people. This may sound difficult to understand, but if you look at it in detail, you will see that this is an exciting new social network, as explained in more detail in the light white paper.
    • Governance: Sybil have been blocked, and now you can safely use the Quadratic Voting (e.g. Quadratic funding platform). You can also go experiment with more interesting modes of governance.
    • Super Bank: Super bank is another banking model other than central bank, commercial bank. It runs on blockchain through smart contracts, it has credit financial capability, directly facing users, instantly sensing user behavior, and adjusting interest rate with every transaction. It has deterministic expectations, including a flexible total amount of issuance, deterministic interest rate changes, and therefore can effectively sense the economic crisis. Even in the event of an economic crisis, he possesses deterministic self-recovery. It is finding equilibrium in every transaction, so there is no Minsky moment.
    • Zero-cost payment: A payment model where the user didn't pay anything. Especially when the minimum trust number is exceeded. Social finance includes institutional accounts, which do not participate in the calculation of the reputation system and are allocated the amount directly to the free balaner. users have nothing to lose in the payment process, thus increasing the participation rate of the charity. It is very useful in other donations, such as donations to open source communities. However, it is currently limited to payments to trusted institutions, and large-scale commercial use ( e.g. in pay-per-month music applications, decentralized storage payments ) needs to Solving collusion attack.

    Ecosystem Fitโ€‹

    Social Networkโ€‹

    There are about 20+ well-known blockchain social networks, which we did research on in 2020, and ZeroDAO's social network is different from them in the following ways.

    ZeroDAO social finance is the underlying economic systemโ€‹

    We don't care about the product form of the social network, whether it has comments, how the content is presented, how users interact, etc., or how he stores it, whether it uses IPFS or exists on its own servers. We only work on the more core and underlying economic systems and user relationships.

    ZeroDAO's incentive model has been radically improvedโ€‹

    Reputation Systemโ€‹

    A reputation system built on a blockchain essentially refers to the extent to which the system can trust a user. A reputation system in a broad sense includes identity verification, credit rating, and so on. There are a very large number of projects that intend to build reputation systems, and there are several broad categories, each with corresponding case; for the sake of brevity, specific applications are not listed here.

    • Evaluation: Two types are included, one with specific purposes, such as evaluation between buyers and sellers in a buying relationship, evaluation between DAO collaboration members, evaluation between demand and supply sides in a Witkey system. The problem is the low coverage and poor data standardization. The other type is voting without a specific purpose, which suffers from the problem that users lack a fundamental motivation to vote. Overall, it is also a good direction if there is a simple and effective enough way to counter attacks and standardize all data from an ecological point of view. In comparison, ZeroDAO has more coverage, more uniform data, and more security.
    • Personal Currency: Applications based on personal currencies are usually able to guarantee the validity of the relationship through certain economic models. This is one of the better categories to build a reputation system, and in fact, ZeroDAO's previous solution used exactly this approach. Each user can issue a personal currency and add liquidity in the form of x * y = k. A trust relationship graph is constructed between users through a complex economic system. However, in discussions with the community, it became clear that we were imposing too much responsibility on users, making them very confused about the act of trust. The most fundamental problem with this approach is that its security relies too much on the design of the economic system and always assumes that the economic system works perfectly. In fact, the incomplete contract will induce to constant problems in complex economic systems. The economic system would have to be tired of tinkering with and making the economic system more and more complex. We have abandoned this approach.
    • Social Network: ZeroDAO's reputation system is built on top of that. Most blockchain social networks claim to be able to build reputation systems. But computing centrality on-chain consumes too many resources. When the network is large, it is still too expensive even for Off-Chian Workers. ZeroDAO combines an economic system with the TIR algorithm to achieve a truly high-availability, sybil-resistant reputation system.
    • Other: It is also possible to build a reputation system by means of a computational marketplace similar to TrueBit that computes some kind of data on a large scale. There is already a peer-review based project being built. However, TrueBit's calculation method itself has some limitations.

    ZeroDAO reputation system is positioned as the core of a on-chain reputation system to meet the needs of most applications and has a high adoption rate. It is simple and reliable and does not require cumbersome operations for users. Third parties can also add other reputation systems on top of ZeroDAO reputation system according to their needs.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Daqin Lee
    • Zhidong Chen

    Contactโ€‹

    Team's experienceโ€‹

    Daqin Lee: Full-stack Developer๏ผŒRust And Substrate Developer

    Chen Zhidong: Full-stack Developer, Tesla Machine Learning Engineer๏ผŒGoHack 2017 Hackathon First Prize

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    Algorithm validationโ€‹

    We built a simple application to validate the algorithm and perform tuning, and show the results of the computation. It synchronized Circles-UBI on-chain user data and relationship data from theGraph, and we simulated the calculation of reputation for all users using the TIR algorithm and also calculateds Betweenness Centrality, PageRank, Article Rank, Degree Centrality, Harmonic Centrality, Eigenvector Centrality, Closeness Centrality.

    We computed data at different data sizes several times in our development environment. And a website was deployed to demonstrate how the selection of Hall of Fame users affects the calculation. You can also query the reputation of any user in the application, as well as the shortest path between users. We are still tuning the algorithm, so if you find significant deviations in the data, please contact us.

    Website: https://socircles.info

    Front-end: https://github.com/ZeroDAO/socircles-ui

    Back-end: https://github.com/ZeroDAO/socircles-backend

    Management: https://github.com/ZeroDAO/socircles-admin

    White Paperโ€‹

    We currently have a light white paper.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 7 weeks
    • Full-Time Equivalent (FTE): 3.5 FTE
    • Total Costs: 15,000 DAI

    Milestone 1 Example โ€” Implement Substrate Modulesโ€‹

    • Estimated duration: 7 weeks
    • FTE: 3.5
    • Costs: 15,000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works. And a tutorials on when to use social finance design guidelines.
    0c.Testing GuideWe will provide a full test suite and guide for ZeroDAO node manage
    1.Pallet: refresh-reputationRefresh user's reputation
    StorageFees: StorageMap<_, Twox64Concat, T::AccountId, (u32, Balance), ValueQuery>;
    Records: StorageDoubleMap<_, Twox64Concat, T::AccountId, Twox64Concat, T::AccountId, Record<T::BlockNumber,Balance>, ValueQuery>;
    Structpub struct Record<BlockNumber,Balance>
    Functionspub fn new_round(origin: OriginFor<T>) -> DispatchResultWithPostInfo
    pub fn refresh_reputation(origin: OriginFor<T>, user_scores: Vec<(T::AccountId,u32)>) -> DispatchResultWithPostInfo
    pub fn receiver_all(origin: OriginFor<T>) -> DispatchResultWithPostInfo
    2.Pallet: reputationMaintain the user's reputation for the last two rounds and set reputation system information
    StorageSystemInfo: StorageValue<_, OperationStatus<T::BlockNumber>, ValueQuery>
    LastChallenge: StorageValue<_, T::BlockNumber, ValueQuery>
    ReputationScores: StorageMap<_, Twox64Concat, T::AccountId, [ReputationScore;2], ValueQuery>
    Structpub struct OperationStatus<BlockNumber>
    pub struct ReputationScore
    Functionspub fn set_duration(origin: OriginFor<T>,duration: T::BlockNumber) -> DispatchResultWithPostInfo
    fn mutate_reputation(target: &T::AccountId, reputation: u32)
    fn new_round() -> DispatchResult
    fn get_reputation_new(target: &T::AccountId) -> Option<u32>
    fn refresh_reputation(user_score: &(T::AccountId,u32),round: u32) -> DispatchResult
    fn last_refresh_at(now: &T::BlockNumber)
    fn check_update_status(update_mode: bool) -> Option<u32>
    fn last_challenge_at(now: &T::BlockNumber)
    fn end_refresh(now: &T::BlockNumber) -> DispatchResult
    3.Pallet: seedsA simple function to set seed user for root account
    StorageSeeds: StorageMap<_, Twox64Concat, T::AccountId, u32, ValueQuery>;
    SeedsCount: StorageValue<_, u32, ValueQuery>;
    Functionspub fn add_seed(origin: OriginFor<T>,new_seed: T::AccountId) -> DispatchResultWithPostInfo
    pub fn remove_seed(origin: OriginFor<T>, seed: T::AccountId) -> DispatchResultWithPostInfo
    fn get_seed_count() -> u32
    fn is_seed(seed: &T::AccountId) -> bool
    4.Pallet: trustAllows users to manage trust relationships, cache relationship data during reputation refreshes, calculate user paths and scores
    StorageTrustedList: StorageMap<_, Twox64Concat, T::AccountId, UserSet<T::AccountId>, ValueQuery>;
    TrustTempList: StorageMap<_, Twox64Concat, T::AccountId, TrustTemp<T::AccountId>, ValueQuery>;
    Structpub struct TrustTemp<AccountId>
    Functionspub fn trust(origin: OriginFor<T>, target: T::AccountId) -> DispatchResultWithPostInfo
    pub fn untrust(origin: OriginFor<T>, who: T::AccountId, target: T::AccountId) -> DispatchResultWithPostInfo
    fn get_trust_count(who: &T::AccountId) -> usize
    fn get_trust_count_old(who: &T::AccountId) -> usize
    fn is_trust(who: &T::AccountId, target: &T::AccountId) -> bool
    fn is_trust_old(who: &T::AccountId, target: &T::AccountId) -> bool
    fn get_trust_old(who: &T::AccountId) -> Vec<T::AccountId>
    fn computed_path(users: &Vec<T::AccountId>) -> Result<(u32,u32), DispatchError>
    5.Pallet: challengesAllow users to initiate a challenge or sub-challenge after staking, the system verifies the sub-challenge, and the challenge is successful to receive the earnings.
    StorageChallenges: StorageMap<_, Twox64Concat, T::AccountId, Challenge<T::AccountId, T::BlockNumber>, ValueQuery>;
    LastUpdate: StorageValue<_, T::BlockNumber, ValueQuery>;
    SubChallenges: StorageMap<_, Twox64Concat, T::AccountId, Progress<T::AccountId>, ValueQuery>;
    Paths: StorageDoubleMap<_, Twox64Concat, T::AccountId, Twox64Concat, T::AccountId, Path<T::AccountId>, ValueQuery>;
    Structpub struct Pool
    pub struct Progress<AccountId>
    pub struct Challenge<AccountId, BlockNumber>
    pub struct Path<AccountId>
    Functionspub fn start_challenge(origin: OriginFor<T>, target: T::AccountId, analyst: T::AccountId, quantity: u32) -> DispatchResultWithPostInfo
    pub fn upload_path(origin: OriginFor<T>,target: T::AccountId,seeds: Vec<T::AccountId>,paths: Vec<Path<T::AccountId>>) -> DispatchResultWithPostInfo
    pub fn start_sub_challenge(origin: OriginFor<T>, target: T::AccountId, quantity: u32) -> DispatchResultWithPostInfo
    pub fn receiver_challenge(origin: OriginFor<T>, target: T::AccountId) -> DispatchResultWithPostInfo
    6.Front EndComplete the development of the basic interactive page in vue๏ผŒand the interface will be available in Chinese as well as English.
    7.Substrate chainAll the above modules of our custom chain will interact with each other to provide an MVP. there will be APIs to set seeds, allow sending social currency to users, update reputation, launch challenges and receive earnings.
    8a.DockerWe will provide a Dockerfile to demonstrate the full functionality of our chain
    8b.ArticleWe will write an article or tutorial that explains the work done as part of the grant.

    Future Plansโ€‹

    short termโ€‹

    • Alpha Network
    • Algorithm tuning
    • Solving the Verifier's Dilemma
    • Optimize economic system design
    • Integrating Quadratic Voting, MACI and Reputation Governance to Launch Hall of Fame Voting
    • Implement seeding algorithm for user selection

    long termโ€‹

    • Ecosystem

    • Brand And Market: Achieving the positioning of public resources

    • DAO: Operates entirely through DAO

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Announcement by another team.

    • Wheter there are any other teams who have already contributed (financially) to the project.
      • No
    • Previous grants you may have applied for.
      • No
    - + \ No newline at end of file diff --git a/applications/ZeroPool.html b/applications/ZeroPool.html index e5f2321786a..387869deae8 100644 --- a/applications/ZeroPool.html +++ b/applications/ZeroPool.html @@ -4,13 +4,13 @@ ZeroPool Phase 2 | Web3 Foundation Grants - +
    Skip to main content

    ZeroPool Phase 2

    • Proposer: snjax
    • Payment Address: DAI ERC20: 0xb6F9F891497C0B72a8A817f3D3E3C721fca6f9CC

    Project Descriptionโ€‹

    ZeroPool is the first fully anonymous solution for the Ethereum. One can deposit, withdraw, and make transactions inside the project. ZeroPool supports ERC20 and ERC721. We hide the whole graph of the transaction. Gas cost is pretty attractive in our solution (15-40k per transaction), because we are using optimistic rollup.

    All these points explain benefits for the community. True anonymity on the blockchain becomes possible with ZeroPool.

    We are interested in cooperation with Web3 because we will be able to make zkSNARK and privacy technologies more attractive and clear for developers. Also, we will be able to attract more users and attention to our project.

    Private transactions are a rather atypical development for blockchain. There are two differences from common dApps: our dApp needs to manage local client/browser-side database and zkSNARK prover requires heavy computational complexity. We need to optimize the solutions not only at the opcodes level and algorithms but also at a more high level, like interactions between all components (UI, cryptography, local database, blockchain).

    Here is a tech description, how our solution works: State of Zeropool - scaling anonymous transactions for Ethereum.

    Team membersโ€‹

    • Igor Gulamov / Applied cryptography, architecture, rust

    https://github.com/snjax

    igor.gulamov@gmail.com

    Igor is responsible for cryptography, architecture, coordination, and team management. Also, Igor is responsible for research and finding out the best way of adapting ZeroPool for Web3.

    • Alexandra Gulamova / Business development, community, UX, administrative

    Non-technical tasks for our interaction requires a separate person. All applications, reports, coordination questions. Also, it is needed to follow up with the community to adopt and support this project.

    • Dmitry Vdovin Rust/wasm developer

    https://github.com/voidxnull

    Dmitry has experience in the development of wasm and rust applications, backend and microservices, interacting with the blockchain.

    Rust/wasm developer is full-time, he is responsible for developing wasm part of the client-side application and also there are client-side bases among the tasks. It takes a lot of time and affords.

    • Samuele Landi Rust/blockchain developer

    https://github.com/samuelelandi

    Samuele has experience in rust, blockchain, and polkadot development.

    Rust/blockchain developer builds relayer and maybe some parts of the pallet, which is needed for cryptography adapting for the final product.

    • Anton Pegov Frontend developer

    https://github.com/antonpegov

    Anton has experience in fronted (including fronted for Ethereum DApps).

    We need a separate position for the frontend developer because the scope of skills of other team members does not imply strong frontend skills. Anton covers this scope giving time for others to work hard on the codebase.

    Team Websiteโ€‹

    Team's experienceโ€‹

    Igor is the tech lead of the team. Igor is responsible for core parts such as ZeroPool architecture and SNARKs.

    Igor has great experience in research and product creations. He started as a researcher in physics at the same time he created some IT products for the b2b sector. Igor came to the blockchain as VP Eng in BANKEX Foundation and then became CTO there. Also, Igor has great experience in blockchain research (https://ethresear.ch/u/snjax/) and built Fawkes-Crypto library, providing development zkSNARKs as native applications in pure Rust.

    Dmitry has a strong experience in rust. He worked on different IT projects before.

    Anton is responsible for the frontend. He has perfect experience and skills in UX/UI. He worked for international IT companies. Also, he has experience in blockchain. He created a frontend for several dApps.

    Samuel has great experience in IT. He worked in application-directed cryptography. So he has deep knowledge of encryption, communication protocols, and coder of original communication protocols for encrypted communications. Also, Samuel worked on several blockchain projects with Polkadot (Substrate), Ethereum, and Bitcoin.

    Alexandra is responsible for product development and cooperation with other teams and companies. Alexandra has great experience in IT projects and business development. Also, she is responsible for non-coding questions in the project.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmapโ€‹

    • Total Estimated Duration: 4 months
    • Full-time equivalent (FTE): 3 FTE
    • Total Costs: 63000 DAI

    Milestone 1 โ€” Implement zkSNARK circuit and cryptography for private transactionโ€‹

    • Estimated Duration: 2 months
    • FTE: 3
    • Costs: 36000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 and MIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can sign, proof and verify the transactions.
    0c.Testing GuideWe will build a testing environment to demonstrate functionality. Proved transactions could be verified in substrate pallet application (1)
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.zkSNARK circuit and cryptography libraryWe will create a library for proving and verifying private transactions, compatible with the substrate pallet

    The solution is based on Fawkes-Crypto library. We implement a join-split transaction with hidden inputs from a merkelized anonymity set. Also we are going to support spending, receiving and decryption keys, like in ZCash.

    The resulting software will be available to sign and prove, encrypt and decrypt transactions :

    • deposits
    • withdrawals
    • transfers

    Milestone 2 โ€” Implement private transactions contract for substrate pallet and client libraryโ€‹

    • Estimated Duration: 2 months
    • FTE: 3
    • Costs: 27000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 and MIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can execute private transactions on the substrate node. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.Substrate module: private transactionsWe will deliver a working module, demonstrating private transactions in the substrate chain
    2.Wallet library:The js&wasm wallet library will support interaction with the contract (perform transactions and view the state) from the frontend side.
    3.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain

    The contract will support transfer, deposit, and withdrawal for multiple assets (DOTs, tokens, presented on the parachain). All transfers are private (balances, user accounts, asset types, transaction graph are hidden).

    Future Plansโ€‹

    • Trusted setup
    • Audit
    • Support assets from other para chains for private transfers
    - + \ No newline at end of file diff --git a/applications/Zombienet-Explorer.html b/applications/Zombienet-Explorer.html index 2d4fa41f870..6957c0a4fa2 100644 --- a/applications/Zombienet-Explorer.html +++ b/applications/Zombienet-Explorer.html @@ -4,7 +4,7 @@ Zombienet Explorer: Multi-Chain Substrate Block Explorer (based on Polkaholic.io) | Web3 Foundation Grants - + @@ -16,7 +16,7 @@ operation. Because some XCM instructions can contain XCM messages themselves recursively, and may "Transact" encoded call, there may be many different chains initiated by a single extrinsic generating a "tree" of activity. After seeing a few cases of ump/dmp and transact in the wild, it became clear that the "XCM Transfer" approach would not be too simplistic.

    Distributed Tracing + Remote Execution.

    Zombienet incorporates Distributed Tracing tools from Grafana Tempo+Jaegar, which are well matched to XCM's recursion capabilities. At present, reasoning about what is going on between chains is accomplished by looking at a lot of raw logs and undecoded messages between chains. Substrate chains that operate as "shards" or on each others unique functionality will increasingly rely on remote execution, but this future cannot be realized until tools exist. Zombienet with Zombienet explorer aims to serve this goal.

    Open source LCD

    Having an open-source Zombienet explorer using lowest common denominator code (Nodejs + Mysql, not React Typescript or BigTable) may support faster analytics, and more extensibility. Someone who knows only a bit of Javascript+SQL and completed their first Substrate pallet should be able to add their own chain indexing and user interface to Zombienet Explorer and do simple mysql analytics. We have about 5-10 key big classes so Level 7 fellows aren't required to achieve this goal.

    Zombienet

    After adding XCM Remote Execution indexing for Moonbase Alpha/Beta, we thought it would be possible to do a Shiden-Moonriver bidirectional remote execution (using Astar remote_transact and Moonbeam 5004 System Contract), but there is significant complexity in derived accounts in this case. Astar's Dino Pacandi led us to explore XCM Remote Execution within Zombienet following this; Moonbeam's Gorka provided 2 Moonbase configuration included here. From this effort, it became clear that complex XCM interoperabilty testing between parachains would be done in ZombieNet and a more extensible ZombieNet explorer would be required.

    Team ๐Ÿ‘ฅโ€‹

    Team members / Contactโ€‹

    Team's experienceโ€‹

    Key engineers Sourabh Niyogi and Michael Chung have developed Polkaholic.io since Fall 2021. Prior to building Polkaholic.io, Sourabh and Michael worked in decentralized social networking protocol development + privacy-preserving contact tracing (Wolk), mobile advertising real-time bidding algorithm design and analytics (CrossChannel/MdotM). Sourabh has founded social + web advertising startups (Social Media Networks) in the SF Bay and spent time doing computational cognitive science and machine vision research at MIT. Michael hails from UC Berkeley.

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Zombienet Explorer code is a simplified version of Polkaholic.io run entirely in a local environment (local Mysql, pure Docker). Most of the engineering work thus consists of deleting all code that is useless, documenting what remains to support Substrate devparachain contributions, and testing that the Zombienet explorer is useful specifically to support parachain developers testing their single chain, and multiple chains interacting with other with XCM Transfers and Remote Executions in EVM + WASM contexts.

    Beyond having a clean and well documented Zombienet Explorer code base, we have 2 key demonstrations:

    Overviewโ€‹

    Milestone 1 โ€” Core Zombienet Explorer Code, Working Zombienet Explorer for 2 EVM+WASM parachainsโ€‹

    NumberDeliverableSpecification
    0a.LicenseGNUv3
    0b.DocumentationProvide: (a) inline documentation of the core crawling and indexing processes (b) how to setup Zombienet Explorer using Docker compose for Astar + Moonbem chains
    0c.Testing GuideUpdate README showing how to do remote executions between 2 Moonbase parachains and 2 Shibuya parachains within Zombienet, and visualize them with Jaeger
    0d.DockerDocker compose file composed of mysql, Jaeger/tempo setup
    1.Zombienet Explorer Site AreasDevelopment of Polkaholic.io Core Site Functionality.
    2.Support for Distributed TracingDevelopment of Jaeger/tempo tracing.

    See Zombienet Substrate Block Explorer - Milestone 1

    Milestone 2 โ€” Chainparser Refactor, 3 parachains, 30 TOMLโ€‹

    NumberDeliverableSpecification
    0a.LicenseGNUv3
    0b.DocumentationProvide inline documentation for (a) all working chain parsers (b) XCM indexing mechanics
    0c.Testing GuideUpdate README of how the chain parsers actually work, with astar (WASM) + moonbeam (EVM) as core examples.
    0d.DockerDocker compose file composed of mysql, Jaeger/tempo setup.
    1.Support for 2 Parachain ParsersDevelopment of 2 Parachain Parsers: Astar + Moonbeam
    2.Test 20 Zombienet ConfigsGenerate a report of our attempts to have working single parachain TOML beyond Shibuya + Moonbase with 20 TOMLs, using binaries available from our full nodes

    In the construction of Polkaholic.io, we have implemented generic parsers for popular pallets used by multiple chains (e.g. xTokens, polkadotXcm, xcmPallet, tokens, asset, system etc, assetRegistry) but found it was difficult to do this for all parachains: there is just too much custom activity.

    In our vision, parser for commonly-shared pallet only needs to be implemented once. Developers are welcomed to submit PR for commonly-shared generic parsers which have high impact. In addition, each parachain team can also tweak certain aspect of the indexing machinery + supporting UI for their own parachain by building a chain-specific parser for their own purposes and adding it to Zombienet Explorer.

    We will develop 2 representative parachain parsers: Moonbeam + Astar that demonstrate how substrate developers can extend the Zombienet explorer to support their own pallets and parachins.

    We will also test 20 Zombienet configurations using recently compiled binaries. See Zombienet Substrate Block Explorer - Milestone 2 for an exhaustive list.

    Future Plansโ€‹

    Colorful Notion aims to see this project have contributions from as many Substrate parachain teams as possible, similar to how parachains submit PR to Polkadot.js, except specifically with chain parsers + UI views added by more parachains. Our expectation is that by having parachain specific code developed by parachains, we may have this functionality brought back into Polkaholic.io's multichain block explorer and other projects that need to do analytics/UI.

    With sufficient interest as different parachain teams instrument their parachains for XCM interoperability, we would welcome doing follow on work on:

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/ajuna_network_follow_up.html b/applications/ajuna_network_follow_up.html index 7642ee96ef4..8d7cb38d071 100644 --- a/applications/ajuna_network_follow_up.html +++ b/applications/ajuna_network_follow_up.html @@ -4,7 +4,7 @@ Ajuna Network Follow up | Web3 Foundation Grants - + @@ -23,7 +23,7 @@ The service Layer project can be deployed to a server as DOTNet application offering node storage information as RestAPI to the UnitySDK GameEngine. The Service Layer can add a persistent layer to store node storage, with a Database which is already supported and documented.

    PoC/MVP or other relevant prior work or research on the topicโ€‹

    Our alpha game is already running, check out our webpage (https://dotmog.com/).

    The basic part of the open-grant has been developed as framework for our flagship game, as we where focusing on the game it self the API lakes inline comments and might be a little complicated to jump in with out a good documentation or tutorials.

    A lot of our previous work on the World of Mogwais is being used as PoC for the current project, the game logic we created WoMNetCore is reused where it makes sense or refactored to match better, here an old PoC. We used the CryptoKitties on Substrate as our first crash course into Rust and luckily it had a theme in common with our vision from 2017 old whitepaper.

    Ecosystem Fitโ€‹

    I think currently there are no such projects in the substrate ecosystem, at least we don't know of any. The setup should enable an easy start in to game development with substrate.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Artists:

    Contactโ€‹

    Team's experienceโ€‹

    The team consists of three experienced developers, one project manager / designer and additionally two supplying artists working on illustrations and 3D models. In past projects the team has already worked together on different projects one of them is mogwaicoin which has been live since 2018 and on the game on top The World of Mogwais. Besides that both devs have a background in reverse engineering of games and creating automations or simulators, like sabberstone. Our project manager is working in the financial sector in the same role for years as he is supporting the team. Based on the work of darkfriend77 Sabberstone simulator a lot of research and publications have been done in the AI domain (google: sabberstone research ai) or even ai competitions. Our passion is about creating games and/or enhancing the gaming experience for us.

    Team Code Reposโ€‹

    Other projects lead and maintained by the teammembers

    Adding a polkadot related commit here .. https://github.com/usetech-llc/polkadot_api_dotnet/pull/10

    Active organisations of the teammebers

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1: SubstrateNetApi โ€” Rework and Documentation of the Substrate .NET APIโ€‹

    SubstrateNetApi is the base API and it needs a dedicated documentation to allow better adoption and also simplify custom needs, like integration to other blockchain types and more examples and inline documentation.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.Enhance APIGeneric handling of Types & Metadata, Custom Pallet & Type support
    1a.Enhance APIExtend Generic Types for Vec & Option
    1b.Enhance APIImplement Extension Custom Pallets & Types for PolkaDot, Kusama, DOTMog & UniqueNetwork
    1c.Enhance APIGeneric Approach on Encode & Decode of Types
    1d.Enhance APIImplement Rust special enums, who are used like structs
    2.SchnorrkelReintegrate Schnorrkel, into SubstrateNetApi
    2a.SchnorrkelPublish Schnorrkel project, with proper licensing as nuget package
    2b.SchnorrkelImplement SR25519, similar to ED25519 in SubstrateNetApi
    3.MnemonicAdd mnemonic seed, in SubstrateNetApi
    3a.MnemonicAdd mnemonic seed, recovery on lost password or wallet file
    6.DocumentationDocumentation referencing prev. milestone 1 https://github.com/w3f/Grant-Milestone-Delivery/pull/102#issuecomment-795929390
    6a.Inline DocumentationAdd inline documentation to make code more understandable
    6b.WikiAdd a structured wiki, include components and workflows, ex. updateing blockchain metadata, implementing custom pallets, implementing custom types ....
    6c.TypesWiki documentation on workflow for adding types and maintaining the api
    6d.NodeAdd documentation how to setup live node-template testing, for extrinsic
    6e.Custom TestAdd documentation for custom pallet and type testing
    7.Ajuna NetworkInternet appearance of the Ajuna Network, under www.ajuna.io
    7a.Ajuna NetworkArticle and Blog about this open grant and the deliverables, at least one deep dive post into each milestone subject area, SubstrateNetApi, GameEngine, ServiceLayer & ConnectFour (if accpeted)

    Milestone 2: GameEngine โ€” Implement Basic GameEngine Domain Driven Design (DDD) & Implement Basic Bot's for Load and Game Testingโ€‹

    Game Engine is the logic layer for games and provides the necessary informations for the presentation layer that is in unity. To avoid having storage accessed by players all the time, we provide a service layer that keeps global storage changes uptodate an creates event handling which can be subscribed by the representation layer for updates or animations.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.PalletGameEventSystem(events on blocknumber based not on extrinsic), Matchmaker(Queue up, Ranked and non ranked, create matches)
    2.Game Engine
    2a.Game EngineConcept game engine and architecture (Domain Driven Design) and Implement basic and generic game Entities
    2b.Game EngineAccount, Player, Wallet (Private Key Encryption / Mnemonic Restore
    2c.Game EngineAsset Transfer, Buy/Sell, Auction
    2d.Game EngineGameEventSystem (events on blocknumber based not on extrinsic), Matchmaker (Queue up, Ranked and non ranked)
    2e.Game EngineEvent System, for game changes for games in Unity you need trigger points for animations and datachanges, this need to be decoupled, so you have an easy access to them in Unity.
    2f.Game EngineCustom Game Logic layer
    3.Service Layer
    3a.Service LayerConcept service layer (Domain Driven Design)
    3b.Service LayerImplement service layer global storage access over SubstrateNetApi
    3c.Service LayerImplement service layer for all mentioned Entities (Account, Player, Wallet, etc.), register changes and creation of entities
    3c.Service LayerImplement service layer extension to use a light weight database as a persistence layer
    3d.Service LayerCreate event system for storage changes, this is needed for example to trigger presentation layer updates or animations, like egg hatching animation when gameevent triggers
    4.Rest APIAdding service Layer Rest API, accessing Game data
    5.Basic BotImplement Basic Bot, that plays Connect Four with an human like strategic
    6.TutorialService layer, Docker setup, Rest API & Multithreaded Bot testing of Game and Performance
    7.GeneratorSince substrate monthly-2021-10, types are fully disclosed in the metadata, which allows to generated more or less everything for the service layer
    7a.MetaDataDecode Node exposed Metadata into a json format readable and interpretable for the generator, json file of the node exposed metadata
    7b.GeneratorAjuna.NetApiExt Generator, including all Types
    7c.GeneratorStorage Generator, including all Pallets
    7d.GeneratorRest Generator, including all Pallets

    Milestone 3: Unity โ€” Substrate SDK for Unity, Documentation, Templates and Tutorial Videoโ€‹

    Creating a Free Unity Asset in the Assetstore, will allow access to Substrate for game devs, it will take some iterations to provide an out-of-the-box solution and the fast paced susbtrate develoment might create additional maintanance work during the on going project. The goal is to provide an end to end working Asset that uses the node-template and allows access to alice and bob account and balances in a mobile deployable project on unity.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.UnityFree Substrate SDK for Unity in the Asset store
    1a.UnityTemplate Wallet, integrated over the ServiceLayer and the GameEngine, including functionalities (Creating Wallet (Private Key Ed or Sr), using a Mnemonic seed), Restoring Wallet, Transfering Coins, Balance Update, Error handling)
    1b.UnityTemplate with On chain GameEvent and Pallet Matchmaker, where User can queue up to a match and animations that are executed on on chain game events
    1c.UnityTemplate example for Event handlin, balance changed, sending extrinsic in Unity
    2.UnityTutorial for building and connecting with Unity including connection, wallet decription and balance in Unity
    3.AssetAsset Documentation like (https://assetstore.unity.com/packages/tools/utilities/blockchain-sdk-by-enjin-124133)
    3a.AssetTutorial video on implementing a new chain and accessing it with unity
    3b.AssetTutorial video on adding a custom pallet and accessing it in unity
    3c.AssetIntegration Guide of adding a new function in a pallet, adding it as custom pallet function to SubstrateNetApi, adding custom storage access to Service Layer, and adding access in game engine to the new function for unity

    Milestone 4: Complete Game "Connect four", as Tutorial from scratch on Substrate and Unity playable on Mobile (Player vs. Player)โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.Pallet & UnityPallet: Connect four, Matchmaker, Multiplayer, TimeBased Turns
    2.UnityProvide fully functional Multiplayer playable "Connect Four" for Mobile (Android), playable with bots and as real player
    3.UnitySDKProviding a performance test setup that creates 1000 bots playing the game concurrently
    4.UnityYoutube Videos serie Step-by-Step Connect four on Substrate Mobile

    Future Plansโ€‹

    We are working towards the goal of creating a modular gaming blockchain with reusable components that game devs can use and enhance.

    - + \ No newline at end of file diff --git a/applications/anagolay-project-idiyanale-multi-token-community-contributions-for-verified-creators.html b/applications/anagolay-project-idiyanale-multi-token-community-contributions-for-verified-creators.html index 6143beda40f..b23451e42e8 100644 --- a/applications/anagolay-project-idiyanale-multi-token-community-contributions-for-verified-creators.html +++ b/applications/anagolay-project-idiyanale-multi-token-community-contributions-for-verified-creators.html @@ -4,7 +4,7 @@ Project Idiyanale - Multi-token community contributions for verified creators | Web3 Foundation Grants - + @@ -162,7 +162,7 @@ IdiyanaleChain-->>Extension: Success Extension-->>Alice: Tip successful Note over Alice,Extension: Confetti ๐Ÿฅณ

    Anagolay Browser Extension Mockup:

    Tipping_Extension.png

    Future Plans

    As the members of the SBP we have already solid understanding what we are building in next 1 year. Next improvements that are related to this grant are building more Strategies, a UI for the creators similar to OpenCollective. We will also improve the Extension integrating a DEX, ( Polkadex is a possibility ), and much more. All this goes hand-in-hand with our Mission and Vision to bring the decentralized Rights management, protect the creators IPs.

    Additional Information โž•

    How did you hear about the Grants Program?

    We had successfully delivered previous grant PR-719.

    - + \ No newline at end of file diff --git a/applications/anagolay-project-idiyanale-phase-1.html b/applications/anagolay-project-idiyanale-phase-1.html index a7291a310f5..afa32891dfc 100644 --- a/applications/anagolay-project-idiyanale-phase-1.html +++ b/applications/anagolay-project-idiyanale-phase-1.html @@ -4,7 +4,7 @@ Anagolay Project Idiyanale - Phase 1 | Web3 Foundation Grants - + @@ -23,7 +23,7 @@ | 3. | Anagolay CLI: Operation Part 1 | See here | | 4. | Operation: op_file | See here | | 5. | Rust demo crate - Part 1 | Part 1 of the rust demo crate. Setup the initial structure for the demo as a lib and binary. |

    Substrate module - an_operationโ€‹

    We will create a Substrate pallet that will contain the storage and extrinsics for creating the Operations and OperationVersions and their storage items. The storage items include all the stores we will need (not 100% decided yet) and mapping storage for OperationVersion <-> Operation. The list of extrinsics is not 100% defined yet and what we have might be subject to change, but what we have defined is the following:

    Extrinsics:

    Storage:

    V1 of Operation is explained here

    โ—€๏ธ Go back to Milestone 1

    Operation - op_fileโ€‹

    We will create an Anagolay operation called file. This operation can take a string or a file buffer. In the case of the string, it will read the file and return the file buffer instance, in the case of a buffer it will return the correct instance. This way we can make sure that all targeted environments are using the same file reading approach and correct return data. Of course, the wasm will accept the ArrayBuffer and it will be correctly returned for any other operation that is executed after in the browser environment. Nodejs and Rust can simply pass the file path as a string and the op_file will read it.

    โ—€๏ธ Go back to Milestone 1

    Anagolay CLI: Operation Part 1โ€‹

    The purpose of the CLI is to build the Operation artifacts, rehost the repository, store all the links to the Anagolay chain.

    We will implement this list of features:

    The following code snippet illustrates how the process should look like.


     > anagolay operation publish
    Packing the operation op_file ... 
    Packing is done โœ…

    Publishing ...
    Publishing is done โœ…

    Saving to the Anagolay network...
    Saving is done โœ…


    Operation published and the ID is bafybeifcmrf2ulnwdrhjpkwi2ifbixegegcs22rqbvlzhlcfklzw2ye4fu

    โ—€๏ธ Go back to Milestone 1

    Milestone 2 โ€” Implementing the Workflow pallet, execution, manifest generation, and CID and Multihash Operationsโ€‹

    NumberDeliverableSpecification
    0a.LicenseAll an_ prefixes will be GPLv3, all op_ Apache2
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a developer can create Operations and their versions. How to store them on the chain and query them
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains what was done as part of the grant, with the focus on the developers' community
    1.Substrate module: an_workflowSee here
    2.Benchmarks: an_workflowCreating the benchmarking
    3.Anagolay CLI: workflow manifest generationSee here
    5.Operation: op_cidSee here
    6.Operation: op_multihashSee here
    7.Workflow: executionSee here
    8.Demo nodejs app part 1Creating the nodejs app which will use implemented operations as WASM and produce the CID of an image
    9.Rust demo crate - Part 2Creating the rust crate which will use the implemented Operation as a rust library to read a file and generate the CID.

    NOTE: All the apps, Nodejs, and Rust demo crate when executed must produce the same CID. WHY? Because if they use the same data and the same Workflow they must produce the same output. Same Workflow means using the same Operation manifest which means using the same Operation Version. 100% the same code execution!

    Substrate module - an_workflowโ€‹

    We will be implementing the an_workflow pallet which will contain extrinsics and storage. This pallet is used to store and retrieve the Workflow manifest which is then used by developers to create or verify the set of proofs. The Workflow execution depends on this pallet and its storage. For Workflow explanation click here.

    Anagolay CLI: Workflow manifest generationโ€‹

    We will build an interactive CLI which will be used to generate the Workflow manifest, validate it and store it on the chain. The CLI will be written in Typescript for Nodejs environment and published on IPFS and maybe NPM. The exact structure is not yet defined but here is the idea of what it should look like:


     > anagolay workflow create
    Please select the starting operation from the list:
    โœ…: op_file
    ๐ŸŸข: op_multihash
    ๐ŸŸข: op_cid

    Do you want to add a dependency? (Y:n)
    Please select the next operation from the list:
    โœ…: op_multihash (blake3)
    โœ…: op_multihash (sha2)
    โœ…: op_multihash (blake2b)

    Enter Workflow name: Anagolay Image PoE workflow
    Enter Workflow description: Proof of existence for any image with multiple identifiers

    Are you done? (Y:n)

    Saving to the Anagolay network...

    Workflow created with the ID: bafybeifcmrf2ulnwdrhjpkwi2ifbixegegcs22rqbvlzhlcfklzw2ye4au

    As you can see the second question shows only the operations that can be connected to the previously selected operation. Example of the "Image PoE Workflow" is here

    โ—€๏ธ Go back to Milestone 2

    Operation - op_cidโ€‹

    We will create an Anagolay operation called op_cid. This takes any Multihash type and generates the CID with the multicodec set as RAW and the multibase set as base32.

    Operation - op_multihashโ€‹

    We will create an Anagolay operation called op_multihash. The Operation takes a buffer and creates the multihash instance. Possible multihashes will be sha2-256, blake2b-256, and blake3

    Workflow: executionโ€‹

    Execution of the Workflow manifest created in #3. We will implement basic recursive and automatic execution of the Workflow only for SYSTEM Operations. The execution will load all the dependencies and execute them in the correct order. We will NOT implement any kind of optimizations like caching or memoization to gain a boost in speed.

    Future Plans

    Later, we will implement the social aspect of the Operation and Workflow credibility creating the revenue streams for developers who will be testing the Operations and the developer who creates the Operation. This is part of the Reputation system for the Developers, Operations, and Workflows.

    Additional Information โž•

    How did you hear about the Grants Program?

    We already applied for a grant which got selected and approved. The details are in the Project Overview

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    - + \ No newline at end of file diff --git a/applications/ares_protocol.html b/applications/ares_protocol.html index 47447186579..6774cea8534 100644 --- a/applications/ares_protocol.html +++ b/applications/ares_protocol.html @@ -4,14 +4,14 @@ Ares | Web3 Foundation Grants - +
    Skip to main content

    Ares

    • Proposer: jiyilanzhou
    • Payment Address: 3EDZ47i4ro1cgGqjXsyduuYyLrUesCgekw

    Project Overview ๐Ÿ“„โ€‹

    Ares is a predictive machine project based on Substrate, with the trustless and verifiable under chain real data use a decentralized approach for smart contracts, parachain or other projects in the ecosystem of the Polkadot.

    It is a decentralized oracle network that consists of oracle pallet for parachain and validator, aggregator, reputation council pallet for Ares chain.

    Overviewโ€‹

    Ares consists of parachain plug-in, validator, aggregator, reputation council, proof of fraud. If parachain use our services, it needs to integrate our oracle pallet, The result of the request passed to the caller through a callback. We scan the parachain events caller about the pallet in our chain, use rpc or websocket request via off-chain worker, Aggregators randomly selected through VRF, which aggregates data from multiple sources. and submitted data to the parachain via extrinsic. Aggregators packing parachain extrinsic and receipts in ares chain via off-chain worker.

    img

    Aggregator needs to pledge certain assets, Every time the aggregator submits a correct data, its reputation value will grow. The reputation value and pledge will be weighted, from which we choose the members of council. council can only approve and reject proof of fraud submitted by validator. Default is to approve, the council does not need to work on every block, only needs to deal with disputes when validator fraud proof arise. Validator nodes can verify, if validator found the data is incorrect, submit proof of fraud to council. if council check up, ther it will reward validator and slash aggregator, its reputation will be degraded.

    The functions of aggregator committees are similar to Babe, and reputation council are likely Grandpa which finality the correctness of the data. Most nodes can become member of aggregators committees. It only takes few tokens to staking. The validator who submit proof of fraud need pay a small fee, it protects against DOS attacks.

    Project Detailsโ€‹

    Ares is designed as decentralized oracle network. First of all, Ares will provide basic ares pallet runtime which allows substrate built parachain/blockchain to interact with.

    • define ares Trait which contain Event, Callback.
    • define storage operator, request, result and error types
    • request external data, contains parameters and methods for how to request them.
    • describes how to integrate into parachain.
    • Aggregator scans the extrinsic in the parachain, use off-chain worker requests the data, and submits result extrinsic to parachain.
    • Aggregator packing parachain extrinsic and receipts on ares chain.
    • Validator validate data and submit proof of fraud.
    • Council reward and slash according to proof of fraud.
    • Aggregator, Validator, Council use off-chain worker getting external data

    Ecosystem Fitโ€‹

    Although the Off-chain worker can do part of the oracle job, However it can't guarantee the authenticity and reliability of the data, Ares can provide randomness and correctness of data sources through multi-party data aggregation and anti-attack and auditing of data sources

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Keric: 8+ years development experience, proficient in public chain and cross chain development, proficient in using go and rust, p2p network expert.
    • Eric: 20 years of experience in protocol stack formulation and development, research work related to big data and blockchain, and robot quantification experience.
    • Daniel: 11 years of work experience in IoT software development and management, familiar with contract and DAPP development.
    • Scott: More than 7 years of software development experience, proficient in /Java/Golang/node, etc. engaged in blockchain research and development, familiar with eos/eth.
    • Andy Ray: 10 years of Internet entrepreneurship experience, 5 years of blockchain industry experience, proficient in the secondary market, economic model design.
    • Fred: Over 13+ years of Embedded Network Technology Experience in multiple technological systems including Hardware networking, software networking, and server-side applications.

    Team's experienceโ€‹

    We implemented the POW + DPOS consensus integrated with ethereum, used tendermint to provide finality in blockchain system with golang. Recently, we implemented a rust pos blockchain, it uses vrf select validators and libp2p network. We have enough experience to solve the centralization problem of Oracle.

    Team Code Reposโ€‹

    Team Websiteโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 weeks
    • Full-time equivalent (FTE): 1.5
    • Total Costs: 0.5 btc

    Milestone 1 โ€” Implement ares low palletโ€‹

    • Estimated Duration: 3 weeks
    • FTE: 1.5
    • Costs: 0.5 btc

    In this milestone, We will implement ares oracle proof-of-concept, A oracle pallet for parallel chain calls.

    NumberDeliverableSpecification
    1.oracle palletrequested data, generated events, and callbacks to data, which implement aggregate price on chain, multi assets price and offchain work get price througth Data warehouse api, it use subsrate-node-template
    2.scannerscanner parachain oracle request via block event, parse the specific request data๏ผŒScanner is written in js
    3.providerdata warehouse returns the correct request data use http request๏ผŒ Data warehouse written in java and used js provide to on chain callback
    4.TestingThis milestone will have unit-test for pallet impemented, simulated all functions.
    5.example for demonstrationProvide parachain oracle pallet integrate example, integrate videos and the front-end into the deliveries
    6.DocumentationWe will provide parachain integrate oracle pallet documentation and basic code example that show how developers use the pallet

    Future Plansโ€‹

    If basic functions have been completed, Ares will provide decentralized pallet, including:

    • Multiple data source weight calculation
    • Random aggregators using VRF
    • Proof of fraud verify based on BFT voting
    • Reputation council slash
    • Aggregator staking and Validator incentive
    • Authority management of aggregator submitted data

    Additional Informationโ€‹

    We expect any developer who is interested in Ares protocol join us and build an efficient framework.

    - + \ No newline at end of file diff --git a/applications/assemblyscript-scale-codec.html b/applications/assemblyscript-scale-codec.html index 0021df9dc2f..3acd55cafb1 100644 --- a/applications/assemblyscript-scale-codec.html +++ b/applications/assemblyscript-scale-codec.html @@ -4,14 +4,14 @@ SCALE Codec Implementation | Web3 Foundation Grants - +
    Skip to main content

    SCALE Codec Implementation

    This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

    • Proposer: LimeChain
    • Payment Address:
      bc1q8x95fuz6t767ugkn2vnwlz3e0q2rwc4xw9ede4 (when it comes to payment, letโ€™s test out the address with a small amount first)

    Project Description ๐Ÿ“„โ€‹

    SCALE is a lightweight codec for binary serialization and deserialization used in Substrate. Currently there are Rust, Python, Golang, C++ and JavaScript implementations of the codec. The goal of the project is to deliver AssemblyScript implementation as a separate library.

    The library will be required for encoding/decoding Polkadot Wasm Executor <> Wasm Runtime blob calls and more specifically:

    • Wasm Runtime blob compiled from AssemblyScript parsing runtime function calls from the Wasm executor.
    • Wasm runtime blob compiled from AssemblyScript calling the Polkadot Runtime Environment API (Host API).

    The library is a prerequisite for an AssemblyScript framework that generates runtimes or any runtime implemented in AssemblyScript loaded into a Polkadot Host.

    LimeChain is a blockchain-agnostic development company with a strong focus on developer tooling. We see Polkadot as an exciting technology and we hope to be able to help the developer community through various dev tools and implementations.

    Team ๐Ÿ‘ฅโ€‹

    • Members: Daniel Ivanov, Lyubomir Kiprov, Christian Vesselinov
    • LinkedIn Profiles: Daniel, Lyubomir, Christian;
    • Code Repos: https://github.com/Daniel-K-Ivanov; https://github.com/bakasura980; https://github.com/thcrnk
    • Website: https://limechain.tech
    • Legal Structure: Legal Structure: LimeLabs Ltd., incorporated in Bulgaria, Dragan Tsankov 23A, 1113, Sofia, Bulgaria
    • Team's Experience: Since 2017, LimeChain has worked on 50+ blockchain projects, including a strong track record of building developer tools for different protocols such as Ethereum, EOS, Aeternity and Corda. Some of the companies LimeChain has worked with are Celo, P&G, Raiffeisenbank, Status, Dapper Labs and Maker among others. The proposed developer team in particular also has experience with Substrate.

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 17 days
    • Full-time equivalent (FTE): 1.5
    • Total Costs: 1.181 BTC

    Milestone 1โ€‹

    • Estimated Duration: 17 days
    • FTE: 1.5
    • Costs: 1.181 BTC
    NumberDeliverableSpecification
    1.Implementing the LibraryDelivering a library that supports encoding/decoding the following types: fixed-width integers (signed and unsigned - 8, 16, 32, 64), bool, Big Int, Bool Array, Byte Array, Int Array, String Array, BigInt Array, Hash, Tuple.
    2.Unit TestsProvide unit tests for all of the supported types.
    3.DocumentationREADME file describing how to import, use and run tests for the library.

    Additional Information โž•โ€‹

    LimeChain hopes to become an important part of the Polkadot development ecosystem, supporting the network with different developer tools and integrations. AssemblyScript implementation of the SCALE Codec would be the companyโ€™s first project on Polkadot, and along with a potential AssemblyScript implementation, would drastically help our team in its onboarding with the tech stack while adding value to the developer community right away.

    Although there are other implementations of the codec, each one of them serves different purposes. Each of these projects delivered the codec in different languages. We think that having AssemblyScript implementation of the codec will benefit the development of an AssemblyScript Runtime Generation framework.

    • Are there any teams who have already contributed (financially) to the project? No
    • Have you applied for other grants so far? Not in the Polkadot ecosystem. LimeChain has received and delivered on grants from The ETH Community Fund, Maker DAO and Aeternity.
    - + \ No newline at end of file diff --git a/applications/asylum.html b/applications/asylum.html index b916b751021..4b433a09135 100644 --- a/applications/asylum.html +++ b/applications/asylum.html @@ -4,7 +4,7 @@ Asylum | Web3 Foundation Grants - + @@ -43,7 +43,7 @@ Blockchain dev since 2021.

    Horacio Lex - Blockchain developer at Supercolony. Software engineer since 2018. Master of Science in Applied Mathematics. Has worked in data science and game development. Former Ubisoft employee was working on HUD/UI & gameplay systems. Programming languages are Python, C++, Rust. Blockchain developer since 2021.

    Team Code Reposโ€‹

    Members:

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Asylum was firstly implemented on the Solana Ignition hackathon in its initial idea. After that, the project received its first positive feedback from game developers and multiple VCs and Supercolony venture studio entered the project as a co-founder. Was held two strategical sessions, the concept was largely clarified and reworked. For now, we already have such partners as Darvinia Network and Evolution land (first DeFi game) and conversations with games such as Eizper Chain, Wind metaverse, SpaceFalcon.io. Also, we have already raised the first money from Mempool ventures and speaking with other VCs (Hillrise Group, Woodstock Fund, 500 Startups, and others).

    Materials which was implemented during the time of the hackathon:

    Actual concept materials

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Basic in-game NFT items standard and web-appโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a repository with documentation for the defined standard of NFT metadata in the format of text docs (most likely in .md). Also, examples of metadata will be provided.
    0c.Testing GuideFor implemented standard unit tests will be provided along with a guide on how to run them.
    0d.Docker-
    0e.Article-
    1.Item standard definitionThe definition of the in-game item standard will consist of three parts: JSON schema, descriptive documentation, and examples of usage. Standard properties will be described below in the subparagraphs.
    1.12D visualizationNFT item created with the proposed standard will have the ability to have a visual interpretation in form of a 2D image.
    1.23D visualizationNFT item created with the proposed standard will have the ability to have a visual interpretation in form of a 3D model.
    1.3Multiple visual interpretationsNFT item created with the proposed standard will have the ability to have multiple visual interpretations, both for 2D or 3D visualization types. Interpretations will be stored under the different tags, for example, "2d-pixeled-inventory-view" or "3d-realistic-equipped".
    2.Asylum Core palletWe will deliver the implementation of the described standard. It will be pallets, which will implement base operations with item
    3.Connection libraryWe will deliver the JS library, that will cover functionality of Asylum Core pallet.
    4.Web applicationWe will create a web application that will give an ability to interact with mentioned pallets: create and update template and mint test NFT items. Related to the proposed UI mockups, the "templates section" will be implemented

    Milestone 2 โ€” Extended web-app and testing gamesโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.Documentation-
    0c.Testing GuideFor manually testing we will provide a basic tutorial that explains how a user can interact with the testing environment - go through a "happy path" which includes running a node, hosting web-app and games, minting the NFT in specified standard and trying to use it in two games.
    0d.Docker-
    0e.Article-
    1.Web applicationWe will extend a web application to make it correspond provided mockups.
    2.Unity integrationWe will provide a simple library for Unity (SDK) for integration of the Asylum on-chain ecosystem (Asylum Core pallet) into the game client.
    3.Game AWe will create a 2d web-faced platformer game sandbox in pixeled style with a small "level" space. A player will have a possibility to move, equip items from the inventory (inventory refers to the assets in the user's wallet), and use items (where applicable). The game will use NFT items minted on the Asylum Core pallet via the Unity library.

    Future Plansโ€‹

    As was described in the 'Overview' section, Asylum is a big project which has ambitious plans for the future. The milestones described in this grant application are about to become the first step for building a huge ecosystem for crypto gaming. We are planning to create a follow-up grant where we will describe one more game to show interoperability and extend our ecosystem.

    In our plans, the launch of the Asylum platform is set for the end of the 2022 year, but we are planning to support and extend our product long-term. Also, we would like not only to build but also empower real metaverse gaming by creating Asylum Studio - an independent team that will develop games on top of the Asylum ecosystem.

    Materials:

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Personal recommendation from the Supercolony.

    - + \ No newline at end of file diff --git a/applications/asylum_follow_up_1.html b/applications/asylum_follow_up_1.html index faf11fecbdf..5edc4724156 100644 --- a/applications/asylum_follow_up_1.html +++ b/applications/asylum_follow_up_1.html @@ -4,7 +4,7 @@ Asylum | Web3 Foundation Grants - + @@ -21,7 +21,7 @@ Programming languages are JS, Java, Python, Rust, C++. Blockchain dev since 2021.

    Horacio Lex - Blockchain developer, Supercolony.

    Software engineer since 2018. Master of Science in Applied Mathematics. Has worked in data science and game development. Former Ubisoft employee was working on HUD/UI & gameplay systems. Programming languages are Python, C++, Rust. Blockchain developer since 2021.

    Team Code Reposโ€‹

    Members:

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Current status of the Asylum development - finalization of the PoC. Mainly previous work were delivered within our first grant application

    1. Creator studio - link

    Web application for NFT artists and game/space developers. Delivered within our first grant application. Now goining throught redesign stage.

    1. Connection library

    TS library for connection with Asylum node. Fully delivered within our first grant application.

    1. Unity SDK

    Library for integration of the Asylum ecosystem into the unity engine. Delivered within our first grant application.

    1. Asylum node

    Currently includes pallet that implements Metaverse object standard (now called "asylum-core") and pallet for game/spaces distribution ("asylum-game-distribution"). Delivered within our first grant application.

    1. Metaverse object standard

    Now called "Asylum stadard", will be renamed in process of separation standards from Aslum to IMP. The basic version of the "Metaverse object standard" from IMP. Fully delivered within our first grant application.

    1. Testing game A - 2d platformer "Ninja rian"

    Build of the 2d testing game with integration with Asylum node. Delivered within our first grant application.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Previous workโ€‹

    Milestone 1 โ€” Basic in-game NFT items standard and web-appโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a repository with documentation for the defined standard of NFT metadata in the format of text docs (most likely in .md). Also, examples of metadata will be provided.
    0c.Testing GuideFor implemented standard unit tests will be provided along with a guide on how to run them.
    0d.Docker-
    0e.Article-
    1.Item standard definitionThe definition of the in-game item standard will consist of three parts: JSON schema, descriptive documentation, and examples of usage. Standard properties will be described below in the subparagraphs.
    1.12D visualizationNFT item created with the proposed standard will have the ability to have a visual interpretation in form of a 2D image.
    1.23D visualizationNFT item created with the proposed standard will have the ability to have a visual interpretation in form of a 3D model.
    1.3Multiple visual interpretationsNFT item created with the proposed standard will have the ability to have multiple visual interpretations, both for 2D or 3D visualization types. Interpretations will be stored under the different tags, for example, "2d-pixeled-inventory-view" or "3d-realistic-equipped".
    2.Asylum Core palletWe will deliver the implementation of the described standard. It will be pallets, which will implement base operations with item
    3.Connection libraryWe will deliver the JS library, that will cover functionality of Asylum Core pallet.
    4.Web applicationWe will create a web application that will give an ability to interact with mentioned pallets: create and update template and mint test NFT items. Related to the proposed UI mockups, the "templates section" will be implemented

    Milestone 2 โ€” Extended web-app and testing gamesโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.Documentation-
    0c.Testing GuideFor manually testing we will provide a basic tutorial that explains how a user can interact with the testing environment - go through a "happy path" which includes running a node, hosting web-app and games, minting the NFT in specified standard and trying to use it in two games.
    0d.Docker-
    0e.Article-
    1.Web applicationWe will extend a web application to make it correspond provided mockups.
    2.Unity integrationWe will provide a simple library for Unity (SDK) for integration of the Asylum on-chain ecosystem (Asylum Core pallet) into the game client.
    3.Game AWe will create a 2d web-faced platformer game sandbox in pixeled style with a small "level" space. A player will have a possibility to move, equip items from the inventory (inventory refers to the assets in the user's wallet), and use items (where applicable). The game will use NFT items minted on the Asylum Core pallet via the Unity library.

    Scope of this Grantโ€‹

    Milestone 3 โ€” Interoperable gamesโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationImprove documentation for Unity SDK, describe new features with managing 3D items and items drop
    0c.Testing GuideGuide through the interoperability of game mechanics between two games and association of Blueprints with in-game items, specified by Game Client
    0d.DockerCurrent Docker setup doesn't require additional changes
    0e.Article-
    1.Unity SDK
    1.1Unity SDKImplement the ability to use Unity SDK in Standalone mode (without React build). We're going to utilize Ajuna Unity SubstrateClient and integrate it with Asylum pallets.
    1.2Unity SDKImplement Unity Editor Extension to operate with Asylum pallets in Editor mode. This will be the first iteration of the editor extension, where a developer can specify the seed phase, connect to the Asylum chain, query Asylum entities, and mint Asylum Items.
    1.3Unity SDKRefactor Unity SDK to support both use cases: inside React app and Standalone mode.
    1.4Unity SDKImplement UML Class diagram of Unity SDK high-level classes
    1.5Unity SDKImplement asynchronous assets loading to reduce lags during the game
    1.6Unity SDKImprove Unity SDK example documentation: show two possible usages of the plugin (inside React and Standalone mode), a guide on editor extension usage
    2.3D Game
    2.13D GameImplement a 3D Diablo-like game in Unity 3D, which utilizes Unity SDK
    2.23D GameImplement the ability to parse and render GLB/GLTF 3D models
    2.33D GameImplement the ability to render 3D animation and effects based on Tags and Interpretations
    2.43D GameImplement in-game Items drop logic with on-chain minting. There will be scripted in-game actions (e.g. open a chest, defeat an NPC), which triggers the on-chain minting of Item and handles its result
    3.In-game items associationThis deliverable is related to the Creators Studio web app
    3.1In-game items associationImplement the ability to create Blueprint with specific Interpretations required by Game Client to associate it with in-game item
    3.2In-game items associationImplement the ability to adapt existing Blueprint and add missing Interpretations, required by Game Client to associate it with in-game item
    3.3In-game items associationImplement a 3D model viewer to check uploaded 3D Interpretations
    4.RenamingsAccording to the latest comments and product design discussions, we are making the following renamings: Template -> Blueprint, Game -> Space, Game Developers Console -> Creators Studio

    Milestone 4 โ€” Public availabilityโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationOrganize all distinct documents in one single resource using existing documentation tools and make it public available.
    0c.Testing GuideGuide for Players WebApp: describe how user can configure wallet and achieve tokens to enter Asylum platform
    0d.Docker-
    0e.Article-
    1.Game back-end exampleWe will implement a back-end for delivered games (milestones 2 and 3) that will track user actions and decide about items minting. In the future, this back-end is planned to be deployed on TEE (as an L2 solution) to make it secure and potentially decentralized.
    1.1Game back-end exampleImplement game back-end as substrate offchain worker and call it Asylum offchain minter. To make minting possible, blueprints issuer should insert their keys into the keystore as keys for offchain minter.
    1.2Game back-end exampleImplement minting control. Offchain minter will submit a mint transaction with parameters from the mint request (blueprint_id, item receiver) from player.
    1.3Game back-end exampleImplement minting request validation. Offchain minter will validate item mint request: game should support a blueprint, which mint is requested and player should own a Ticket, which gives him an access to the game
    1.4Game back-end exampleImplement anti-bot protection. Offchain minter will store last player actions, such as movements, to guarantee that game was played honestly. Mint request will be rejected if some anomaly is found.
    1Unity SDK
    1.1Unity SDKUpdate Editor Extension to load Blueprint Interpretations as assets and display them in Unity custom editor window
    1.2Unity SDKImplement ability to place and interact with Blueprint images and 3D models on the scene
    2.Players WebAppImplement WebApp for players, where user can run games and see/manage his obtained NFTs. Application will be based on Creator Studio app. It's the first iteration of Players WebApp, the next stage is 3D world with Avatar and multiplayer capabilities
    2.1Players WebAppImplement ability to view player's ASLM balance
    2.2Players WebAppImplement Discourd bot, where player can request ASLM tokens and link it with Players WebApp
    2.3Players WebAppImplement page, where user can buy Tikets and launch Spaces
    2.4Players WebAppImplement page, wheere user can view his obtained NFT items

    Future Plansโ€‹

    As was described in the 'Overview' section, Asylum is a big project which has ambitious plans for the future. The milestones described in this grant application are about to become the first step for building a huge ecosystem for the Metaverse.

    Here you could find Asylum roadmap roadmap

    Materials:

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Personal recommendation from the Supercolony.

    - + \ No newline at end of file diff --git a/applications/bdwallet.html b/applications/bdwallet.html index 22cc50de852..be606ac0cce 100644 --- a/applications/bdwallet.html +++ b/applications/bdwallet.html @@ -4,13 +4,13 @@ BD Wallet | Web3 Foundation Grants - +
    Skip to main content

    BD Wallet

    • Payment Address: 3FfrG9FrZXmPikEYJ9FdHPoRZ2nPjMY45W
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    The full name of BD Wallet is Black Diamond Wallet, It is a multi coin crypto wallet enables blockchain developers to build their DApps and wallets natively without having to worry about the low-level implementation details.

    Unlike other wallets, we also support centralized wallets which we call cloud wallets. Through the cloud wallet, we provide users with functions such as project rating, easy-to-operate staking, and DeFI vaults. Currently, the cloud wallets has served over 70,000 blockchain industry users.

    Cloud wallets can be considered as wallet implementations with partial centralization features, keeping their cryptocurrency for users, similar to "PayPal". Cloud wallets exist to reduce users who have no experience in using cryptocurrency wallets. They donโ€™t need to know any implementation details about the wallet, such as mnemonic words, secret keys, etc., users can directly transfer and receive encrypted currency through the account registered in our cloud wallet (the account may be a mobile phone number or email) And use other services, it is more friendly to novice users. According to our research, many users in China have this requirement. They need a simple and easy-to-use wallet and don't need to record mnemonics and secret keys by themselves.

    And we also have HD wallet to choose from to meet the needs of high-end users.

    Now, we intend to fully support the Polkadot ecosystem and contribute to the prosperity of the Polkadot ecosystem

    Overviewโ€‹

    BD Wallet which formerly known as Black Diamond Ratings, was created in January 2018, it is the first jury-type blockchain project rating in the world, with more than 500 professional reviewers, all of whom are senior practitioners in the blockchain industry. The rating range includes exchange ratings, cryptocurrency ratings. Currently, it has accumulated 17,000+ ratings, it is the largest cryptocurrency rating agency in China.

    On August 15, 2020, the company strategically merged with Bi Da Wallet and officially changed its name to Black Diamond Wallet. Black Diamond Wallet has now developed into a digital open financial one-stop solution platform integrating cryptocurrency storage, financial service, project rating and industry social contact.

    We have a professional review team to look for high-quality projects on the market and put them on the rating database. Users or project issuers can also submit project information to us, which can be included in the project database after passing the review.

    At the same time, we have a team of professional reviewers to score and rate the items in the rating library, as well as to post comments. The reviewer is a professional blockchain practitioner or cryptocurrency investor. It takes 3 years of industry experience and more than 500,000 encrypted assets to be eligible to serve as a reviewer, and provide relevant certificates to the BD team for review. Provide this rigorous screening mechanism to ensure that each reviewer is professional and to ensure fair and impartial scoring and rating of projects. Of course, the reason why reviewers will actively participate in our project review is because we will give a certain amount of HZT token rewards for high-quality reviews.

    Combining ratings and wallets is where our BDWallet is innovative. We provide users with professional project ratings. Users can view the project profile, reviewer evaluations, and reviewer ratings of related currencies through our rating library, so as to deepen usersโ€™ understanding of the project and avoid users not knowing the project. The situation makes blind investment decisions.

    And users can leave a comment under each rating, and other users can also see the message, so that users can increase their stickiness and frequency of use of the wallet. Users not only use the wallet as a tool, but also a channel for obtaining and understanding project information.

    BD Wallet will fully support the construction and development of the Polkadot ecosystem:

    1. Launch a special version of Polkadot ecosystem project Rating, in order to let more users know about Polkadot and other Polkadot related projects.
    2. Put the service of DOT Staking online to help the construction of Polkadot Node.
    3. Support DOT, KSM and other polkadot ecosystem hot projects token recharge and withdrawal.
    4. Support Polkadot ecosystem DAPP access in the future, making more users to use Polkadot Eco's DAPP easily.

    Project Detailsโ€‹

    • cloud wallet

    • hierarchical deterministic wallet

    Ecosystem Fitโ€‹

    In the current market, there are products in the same type of BD Wallet, such as imtoken, cobo wallet, math wallet.

    BD Wallet has its own unique characteristics.BD Wallet Provides the world's first jury-style rating service. It is the countryโ€™s largest rating agency and has the countryโ€™s largest rating data. BD Wallet also has a social function, which facilitates information sharing and exchange between users.

    Most of the cryptocurrency users in China do not have basic blockchain knowledge, and do not know how to participate in node construction, mortgage, voting, and nomination operations. BDWallet provides lower operating thresholds for users, compared to other Polkadot Wallet, users only need to care about the interest rate that can be obtained when participating in staking in BDWallet. We help users implement investment details.

    And BDWallet pioneered the shared staking model. When user A invites user B to participate in DOT staking, user A can obtain corresponding HZT token rewards. HZT token is the governance currency issued by our wallet. Through this incentive model, more users will spontaneously invite DOT holders to participate in DOT Staking, so that more people will participate in the ecological construction of the DOT community.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Iori Zuo: Lead the team, responsible for project coordination and strategic planning.
    • Steve Li: ui designer.
    • Jie Li: Senior Software Engineer.
    • Robert Li: Senior Software Engineer.

    Team Websiteโ€‹

    • Company name: Fuzhou Wakanda Information Technology Co., Ltd.
    • Registered address: Room F-S309-05, 3rd Floor, Annex Building, F Zone, Fuzhou Software Park, No. 89 Software Avenue, Gulou District, Fuzhou City, Fujian Province, China

    Team Code Reposโ€‹

    Team experienceโ€‹

    • Our team members are all come from the Internet industry, and have worked for Baidu, Tencent, Bit Age and other first-tier Internet companies and first-tier digital currency exchanges, which have developed hellokimi blockchain game platform and linkbit token airdrop tool, and focused on technology research and development in the field of cryptocurrency wallets in 2018.

    Development Roadmap ๐Ÿ”ฉโ€‹

    1. Cloud wallet fully supports the Polkadot ecosystem

      • Support deposit and withdrawal of DOT, KSM on cloud wallets
      • Support the Polkadot ecosystem projects rating
      • Support DOT Staking service to help users participate in Polkadot verification and nomination more easily

    2. Complete the development of bd-Wallet-core.

      bd-wallet-core is open source library that implements low-level cryptographic wallet functionality for many blockchains. It will fully support the coins of the Polkadot ecosystem, so that to make it easier for developers to enter the Polkadot system.

    3. Complete the development of Hierarchical Deterministic Wallet, including:

      • Deposit and withdrawal of Polkadot ecosystem coins (including at least DOT, KSM)
      • Polkadot Dapp Browser

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-time equivalent (FTE): 3.5 FTE
    • Total Costs: 1.35 BTC

    Milestone 1 โ€” Complete fully support of cloud wallet for Polkadot ecologyโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 0.3 BTC
    NumberDeliverableSpecification
    0.Support deposit and withdrawal of DOT and KSM on cloud walletWe will build DOT and KSM nodes and interface with polkadot-js on the server side to support the deposit and withdrawal of DOT and KSM tokens. At the same time, we will also launch a corresponding deposit and withdrawal portal on the app side. Once users log in the app, they can launch corresponding operations, such as recharging dot and participating in Staking.
    1.Support Polkadot ecosystem project ratingWe will launch the project rating of polkadot ecosystem on the app. After logging in to the app, users will be able to rate the projects which they are focusing on or knowing. After the rating is published, other
    2.Support dot stakingWe will open the dot staking portal on the app side to help users participate in Polkadot verification and nomination, but do not have relevant experience. The staking page will demonstrate the corresponding annualized earnings.

    Milestone 2 โ€” Complete bd-wallet-core developmentโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 0.55 BTC
    NumberDeliverableSpecification
    0.api designDesign the api that will be used by the decentralized wallet, including mnemonics, address generation, derivation, transaction signatures, etc.
    1.documentationInstructions and examples for use.
    2.unit testWrite for each unit test.
    3.DOT, KSM and other coins supportInterface with mainstream coins that support the polkadot ecology, such as DOT and KSM.
    4.Publish to project libraryRelease our origin source library to the NPM central repository for developers to import and use

    Milestone 3 โ€” Complete bd-wallet developmentโ€‹

    • Estimated Duration: 1 month
    • FTE: 2.5
    • Costs: 0.5 BTC
    NumberDeliverableSpecification
    0.UI designThe UI of the Hierarchical Deterministic Wallet is designed to provide good interaction experience for users
    1.Wallet constructure designThe constructure design of the wallet. The APP contains local storage strategy, broadcast node management, multi-coins management and other services. The server should provide API interface which supporting multiple chains and in charge of obtaining transaction records, transaction status and other information
    2a.Transaction function developmentThe core function of wallet is to develop the coin management and charging related functions of app
    2b.DApp browser developmentThe development of dapp browser based on polkadot Ecology will serve as the flow entrance of polkadot ecology DAPP
    3.share stakingTo complete the development of shared staking, users can invite friends to participate in Polkadot staking through WeChat sharing, and get hzt rewards
    4.releaseProject published available for download and use by users

    โ€‹

    Future Plansโ€‹

    1. In the upcoming wallet development program, we will develop the decentralized wallet, and also fully support for polkadot Ecology Dapp access.
    2. We plan to establish polkadot (China) Technology Alliance in China to study and promote the technology and concept of polkadot and appeal more developers to join in the ecological development of polkadot and work together to achieve the vision of web 3.0 as soon as possible. At present, multiple exchanges and media companies such as AEX, BKEX, Safe Custody, and token damo have jointly initiated the establishment of Polkadot (China) Technology Alliance
    3. We have focused on the study of the deployment of asset synthesis protocols on the Polkadot Network, in order to map real-world physical assets onto the blockchain, which we feel is a very large market, and we will invite more developers to participate in this study
    4. In future plans, we consider voting on the chain to elect our reviewers. In this way, we believe that our rating mechanism will be more transparent and credible

    Additional Informationโ€‹

    So far, we have completed the development of Black Diamond Wallet cloud wallet, which can provide users with multiple services, such as staking, social networking, rating, defi mining and others. Currently, it has fully supported for polkadot, at the same time we have been preparing for the creation of the polkadot (China) Technology Alliance.

    - + \ No newline at end of file diff --git a/applications/binary_merkle_tree.html b/applications/binary_merkle_tree.html index cc9aaf5d553..f228a08e24c 100644 --- a/applications/binary_merkle_tree.html +++ b/applications/binary_merkle_tree.html @@ -4,7 +4,7 @@ Binary Merkle Tree | Web3 Foundation Grants - + @@ -45,7 +45,7 @@ where he is developing a brand new, highly scalable, cloud development platform, which is already being used by some high profile clients. As of late, Kin has redirected his focus towards blockchain and has been developing DeFi arbitrage bots in his spare time. Over his career, Kin has worked on a wide range of novel solutions to complex problems and is always looking to solve the next big challenge.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    The project has not started yet. We have defined the requirements and designed the solution as described above in this note.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 - Binary Merkle Tree Libraryโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Binary Mekrle Tree LibraryWe will create a binary merkle tree library that operates over a HashDB backend and is generic over the hasher. It will implement the interfaces as described above in this note.

    Milestone 2 - Integration of binary merkle tree library into substrateโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Binary Mekrle Tree Substrate IntegrationWe will integrate the binary merkle tree library into substrate such that it can be used as a child tree.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/bit_country.html b/applications/bit_country.html index 5445dcb7152..9eb78cb290e 100644 --- a/applications/bit_country.html +++ b/applications/bit_country.html @@ -4,7 +4,7 @@ Bit.Country by MVP.STUDIO | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ Frontend - ReactJs
    Backend - .NET Core, C# & Mongol DB.

    Ecosystem Fitโ€‹

    Bit.Country concept is uniquely invented and inspired by the decentralisation paradigm. It will fit in well for growing and scaling the Polkadot/Substrate community.

    With our incubated EduTech business Industry Connect, and the prospected outcome of the project, naturally, it will bring more blockchain enthusiasts to Polkadot/Substrate community worldwide.

    Combined with our community being introduced to Polkadot/Substrate through their education and internship experience, we will be enabling new developers interested in blockchain to get a head start on Polkadot and Substrate.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Full-timers

    Part-timers

    Team Websiteโ€‹

    The legal structure of Bit.Country team will be setup in blockchain friendly jurisdiction.

    Team's experienceโ€‹

    Ray Lu

    Justin Pham

    Shannon Christie

    Daniel Choi

    Juanita Strydom

    Kai Zhang (Technical Advisory)

    Alan Liang (Technical Advisory)

    Grants Received In The Past

    *Callaghan Innovation, a Crown entity of New Zealand, has the task of making New Zealand business more innovative.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Key Profiles from the tech team

    Development Roadmap ๐Ÿ”ฉโ€‹

    Short Summaryโ€‹

    We plan to build a full-fledged solution that is ready to bring 1400 internal users and 50K external users by Aug 2021. Our web app (dapp) requires a truckload of development and testing to ensure it is attractive to classic internet users. We will explore more and work with the Substrate Builders Programme team to build the solution.

    We believe Bit.Country will bring many people to the ecosystem.

    Overviewโ€‹

    Milestone 1 โ€” Create Country Fundamentals & Infrastructure to Onboard Classic Internet Usersโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation, video, medium articles & start creating the lightpaper of the project.
    0c.Testing GuideThe code will have proper unit-test coverage for Country pallets and automated testing coverage for the dapp using Cypress.
    1.Substrate module: CountriesIt manages country profiles, map and ownership. e.g. NewCountry, TransferOwnership
    2.Substrate module: EconomiesIt manages the country's fund, rewards, minting country-specific tokens or importing external tokens.
    3.Bit.Country testnet nodeUsers can run bit.country nodes, sudo can perform hot upgrade.
    4.Bit.Country Dapp - CountryUsers would be able to create an off-chain country with description, theme and going through a name reservation & validation process.
    5.Dapp - User RegistrationOff-chain User can register on the web app and manage the profile and password etc. We've basic code developed, and will add more features so it will work with country security.
    6.Dapp - Country ExplorerUsers can explore countries by searching keywords and tags or simply browsing by population or activeness. Develop features to support list view and grid views.
    7.Dapp - Country MembershipUsers can join a country and apply for residency. Country owner approval functions. User wallets display tokens, assets.
    8.Dapp - Country BlockOwners can create blocks and set the topic and description for the block in a country. Block creation page needs features such as preview 3d world.
    9.Dapp - Country Block PlannerOwners can plan the buildable sections of a block. Utilizing more intuitive UI with 3d preview feature.
    10.Dapp - Country MapResidents can explore blocks like a grid map. Users can navigate to the neighboring block in 9-grid block navigator.
    11.Dapp - Country EconomyOwners can setup off-chain economic rules for incentivizing activities. Create incentive processor to calculate incentive amount and allocate to users. This incentive data will also be used for the data provider in Substrate Oracle for settling incentives on-chain.
    12.Dapp - Country OwnershipList owners of the country ranked by their ownership. Use more intuitive graphics to present the insights.
    13.Dapp - Country Block PostUser can create posts onto the timeline for different level of privacy i.e. public, country level, block level and private. Post can be liked and commented. Post can be shared on external social media to onboard more public users. This will need to work with our caching layer for scalability. Implement infinite scroll.
    14.Dapp - Country Block 3D ViewUsers can enter the 3D view of the block and conduct basic activities such as walk and jump in a customized scene in the browser.
    15.Docker / UATWe will demonstrate the full functionality of our chain and our dapp on UAT / a dockerfile.

    Community engagementโ€‹

    Future Plansโ€‹

    We plan to become a parachain on the Polkadot network eventually, especially when our Bit.Country community gains momentum on Kusama.

    Our team is also planning of building mobile apps in the future so users can access their communities and marketplace on their mobile devices.

    At the moment, we are evaluating Dapp-IPFS-Pallets (Completely decentralized) architecture to host bit.country. We may create a R&D sub-product in the near future.

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/bit_country_m2.html b/applications/bit_country_m2.html index 1197961a2b4..74fba716093 100644 --- a/applications/bit_country_m2.html +++ b/applications/bit_country_m2.html @@ -4,13 +4,13 @@ Bit.Country Milestone 2 (Follow up grant after M1 delivered) by MVP.STUDIO | Web3 Foundation Grants - +
    Skip to main content

    Bit.Country Milestone 2 (Follow up grant after M1 delivered) by MVP.STUDIO

    Development Roadmap ๐Ÿ”ฉโ€‹

    Changes summaryโ€‹

    There are some changes from the original application. The reason of the changes that some UI features that was not aligned on our roadmap and we shifted more focus on delivering public testnet and canary network.

    Here are summary of changes

    • Remove 3D map and continuum UI out of the application scope.
    • Adjusted Continuum Governance Protocol.
    • Added Buying Continuum Spot with fixed cost.
    • Added Sign to support NFT.
    • Added Multi tokens local marketplace.
    • Added Benchmarking.
    • Adjusted the cost.
    • Adjust the FTE.

    Summaryโ€‹

    Since completing the first milestone for Bit.Country, we have developed multiple proof of concepts for newer features such as Continuum (the map of bit countries), the marketplaces and NFT minting.

    We have also developed the virtual world further, implementing collaborative building, material packs, persistance of changes and general tweaks to the UI and experience. Currently undergoing basic user testing and demoing to interested parties.

    Other work has included changes to the design and layout of the DApp; improved sharing experience for posts and content created on the bit country timelines; migration to improve scalability.

    The team has also been applying for a number of accelerators, and receiving attention/interest from multiple VCs, funds and KOLs. Currently, oversubscribed so negotiating with them to determine the initial round allocations. The team has recently been accepted into the Berkeley Blockchain Xcelerator cohort of 2021. Currently in talks with VCs, funds and KOLs who have reach to over 40 million fans. If you are interested to hear more about our current progress, please email us at hi@bit.country

    Considerationsโ€‹

    We have been investigating the possibility of using decentralized storage for more aspects of bit country content and storage needs, a basic proof of concept is being worked on.

    The team has been reconsidering the block planner for a bit country and its related block theme feature as part of milestone 1. We are now looking at separating the logic to enable a smoother experience between users who wish to use a predesigned template or build from scratch.

    Tech Stackโ€‹

    Blockchain: Substrate/Rust

    Overviewโ€‹

    • Total Estimated Duration: 6 weeks
    • Full-time equivalent (FTE): 4 FTE.

    Milestone 2 โ€” Continuum Protocol (Universal Map) & NFT Centric Token Economy. Goal: public testnetโ€‹

    • Estimated Duration: 6 weeks
    • FTE: 4
    • Costs: 24,000 USD

    *Note: We should submit this application ealier, due to the workload required by Kusama NFT Gallery, we have decided to help the community for the upcoming Chiba Art Gallery.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation, video, medium articles & creating more content in the lightpaper of the project.
    0c.Testing GuideThe code will have proper unit-test coverage for pallets.
    1.Substrate module: ContinuumThis pallet handles the Continuum protocols for shaping the map of the bit countries.
    1a.Spot Good Neighbor (Auction) ProtocolControls which users are able to participate in auctions for spots, allows existing neighboring spots to have their say on a potential occupier of the new spot.
    1b.Spot with fixed priceCreating more flexibility for the Continuum Slot by allowing governance to enable buy now option for Continuum Spot which allows Metaverse to occupy Continuum Spot through buying with fixed price instead of Auction.
    1c.Spot Good Neighbor (Governance) ProtocolGovernance voting only enabled when bit countries secured the spot on Continuum, once local governance enabled, residents in the local governance has the ability to raise disputes, change their local economic model which can be voted on and actioned. Designed to improve neighborhood quality.
    2.Substrate module: NftPromotionOur network is designed to support NFT and its promotion. This pallet manages NFT campaigns that we will create to incentivize NFT creators, traders and minters. (e.g. subsidies on costs or other incentive)
    3.Substrate: NFT Minting - ExtendedWhile using ORML trait as a base, we will be implementing co-creator, origin details, NFT-Future-Event (e.g. time capsule), Smart Contract Enabled NFT (e.g. give NFTs programmability).
    4.Substrate: NFT Sign Support - ExtendedThis will allow NFT get supported by their supporters who willing to sign with their signatures to show supports.
    5.Substrate: NFT BenchmarkingThis will ensure appropriate weights will apply based on number of NFTs minting and extrinsics.
    6.Substrate: Auction BenchmarkingThis will ensure appropriate weights will apply to auction extrinsics.
    7.Connected to RococoBecome a parachain on Rococo, requires frequent migrations to the newest version of pallets and reapplication for the parachain. Aim to be included as soon as possible.
    8.Local NFT MarketDevelop the local bit country marketplace (like a subset of the platform-wide marketplace) for local market and value creation. Some items will only be able within the local NFT market, encouraging users to belong to quality bit countries. Included functionality: listing items, searching, auctions, purchases, rentals
    9.Multi token in local NFT MarketAllow local bit country NFT market accepts their own token or using network token when listing, bidding, auctioning or interact with local Marketplace.
    10.Docker / UATWe will demonstrate the full functionality of our chain and our dapp on UAT / a dockerfile.
    - + \ No newline at end of file diff --git a/applications/blackprint-js.html b/applications/blackprint-js.html index fec5a257223..a7dfdb6eb8d 100644 --- a/applications/blackprint-js.html +++ b/applications/blackprint-js.html @@ -4,7 +4,7 @@ Integrating Polkadot.js with Blackprint | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Integrating Polkadot.js with Blackprint

    • Team Name: Blackprint
    • Payment Address: 0xE8b5923f891C5d42eBF9f385DDDFA4a8A74cb9AA (DAI)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Note: "node" does refer to Blackprint's node, not blockchain's node

    Blackprint is a visual programming tool that can help developers interact with libraries by simply connecting nodes in realtime without the need to code. Developers themselves will need to use Blackprint Engine and load required modules to execute exported JSON of node, cable connections, and embedded data.

    Blackprint hopefully can help the development of Metaverse, frontend development, as well as automation such as bots that connect to multiple blockchains. Blackprint itself is planning to expand to support several programming languages such as JavaScript, PHP, Golang, and Python. But this proposal is currently only for JavaScript as Blackprint is still trying to improve.

    Project Detailsโ€‹

    Technology stackโ€‹

    • JavaScript (Browser & Node.js)
    • Polkadot.js's library
    • Blackprint does have 2 main component:
      • Engine: Designed for managing data flow between nodes and can be run on Browser/Node.js/Deno
      • Sketch: Can be used for creating node editor and modify node connections
    • Blackprint Editor: An IDE that combine the sketch and the engine and provide another tools on the GUI to make the development more easier

    Architectureโ€‹

    Below is the current architecture on how Blackprint works. Architecture

    Note: engine does refer to Blackprint Engine, and not JavaScript's V8 engine

    Blackprint Sketch is a minimal node editor where the user can interact (move, click, manage cable connection) with the nodes and it's depends on Blackprint Engine. Modifying node/cable from the sketch in real time will change engine's behavior to manage data flow between nodes.

    The data changes from the engine will trigger JS Module (the orange colored shape) for interact with Polkadot.js's library. JS Module is an additional module/addons for Blackprint, when it's loaded it will registering node for sketch and engine. Polkadot.js's library then will handle the connection between parachain and the current environment (Browser/Node.js).

    Minimum Viable Product (MVP)โ€‹

    Please scroll down again if you prefer to see some video example instead

    MVP

    The screenshot above is taken from Blackprint Editor that using nodes from this MVP module. The module itself is already usable for browser, but the module haven't been published on NPM. Because currently it's still in development, I have put a few example to try it on the repository.

    Some explanation for the screenshot above

    The process is begin from WebSocket connection, after it get connected to the network the Provider and API port will have an value and will trigger the other port like Blocks Event and Transfer node. Blocks Event will then subscribing for new block event, and will update it's UI automatically for visualisation. When the Transfer node has value for API, Address, Value port, it will create a unsigned transaction into Txn port. The filled Txn port will send the value to another node like Txn Payment Info and Send Transaction node. The Send Transaction will need to be triggered manually by calling Submit port and also the Provider port need to be connected with port from WebSocket. The Browser Wallet node is required for asking permission for accessing Polkadot.js extension, and the Signer node can be used after the permission was granted.

    Each port has it's own type data, the details can be seen by hovering the port with a cursor.

    Example: Listening to new blocksโ€‹

    https://user-images.githubusercontent.com/11073373/148692354-3a9ffad4-ef5e-4fa5-9bdb-d8d07b5b59e9.mp4

    With the current MVP, we can listen to new blocks/head by connecting to the parachain via WebSocket. By using Ctrl + Right Click on the API port, we can get a list of suggested node. The Blocks Event then will use the API to subscribe to chain_subscribeNewHeads with help of Polkadot.js's library. The output value (Number port) of Blocks Event will be updated everytime the block number has changed, the New port is supposed for call a function/trigger. At the end of video, I also opened the Chain info explorer to see if the number was match with the current network state.

    Example: Retrieve transaction fee/infoโ€‹

    https://user-images.githubusercontent.com/11073373/148692778-bdf3e096-64d3-43e4-ac7c-38c7785de8cd.mp4

    From the video, I'm creating a Transfer node that can be used for creating unsigned transaction. It will only executed after all required port is filled. I'm then trying to retrieve the payment info for the Txn and sign it by using dummy signer. The Txn Payment Info node then will update it's value for the output port (Info). The output is an Object.

    Limitation of the project:โ€‹

    • Blackprint doesn't generate JS script/code dynamically and can only operate if the custom node is already registered with Blackprint Engine from an external/loaded module.
    • Blackprint Sketch can export the sketch into JSON, and the users can import it to Blackprint Engine for Browser/Node.js. The engine itself will need the JS module to interact with Polkadot.js's library.

    Ecosystem Fitโ€‹

    Blackprint can be used as a playground for experimenting with Polkadot.js library. Like creating their own program without writing code for doing transaction, signing/encrypting data. But just by simply load the module and begin connecting nodes interactively. For production use, they can easily export to JSON and import it on their target environment (browser/Node.js).

    Hopefully users with no knowledge about how create transaction into blockchain may find this helpful for getting started by learning the concept first. It can also help dApp and metaverse developers.

    In the future of metaverse, I hope it can also help users who don't have programming background can easily program it's own logic with the available nodes realtime inside the game/world.

    For example like non-programmer who want to:

    1. Collaboratively creating in-game ATM that can connect to different blockchain via RPC
    2. Trigger transaction when interacting with in-game shop and able to see how the data flow works with Blackprint

    The above is just my vision for the future. I haven't created any prototype of it yet, but it may be possible if some Metaverse project adopted Blackprint for its project.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    I experienced to work as a freelancer since 2015. My experience with web development is about ยฑ7 years since that. I'm also familiar with Golang, PHP, and Python. I usually create open source library on GitHub, and some closed project on GitLab.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Note: Polkadot.js nodes for Blackprint is the JS module I mentioned on Architecture section

    At the time of writing this proposal. Currently Blackprint is already usable, but it's still unstable and being optimized for better performance and design. It's already trying to follow semantic versioning and may only introduce breaking changes on increment of v0.*.0.

    Below is the repository about current development.

    Currently the MVP can be run on browsers. The support for Node.js is still work in progress and may be delivered on Milestone 3. The current MVP may already contain nodes that will be delivered for Milestone 1 and Milestone 2, I'm still preparing to create the unit test and some example before I deliver it.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: ยฑ6 months
    • Full-time equivalent (FTE): 1 FTE
    • Total Costs: 9,200 DAI

    Milestone 1 โ€” Connection and data encryption nodes for Browserโ€‹

    • Estimated duration: ยฑ3 weeks
    • FTE: 1
    • Costs: 4,000 DAI
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationI will provide inline documentation of the code and simple example that can be imported to the Blackprint Editor
    0c.Testing GuideDelivered node will be fully covered by unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerWe will use GitHub Action/Workflow instead, for manual UI testing/interaction we can use Blackprint Editor
    1.HTTP & WebSocket nodeAble to connect to parachain's test/mainnet (including: Polkadot/Kusama/Westend) by specifying the RPC URL
    2.Event nodeAble to listen for new blocks/heads of the connected parachain node
    3.Mnemonic/seed importer nodeAble to convert mnemonic into private key (seed) that can be used for decrypting data or signing data, the private key is in the Keyring
    4.Encrypt, Decrypt nodeAble to encrypt data with public key, and able to decrypt data with private key. Public key and private key is in the Keyring
    5.Sign, Verify nodeAble to sign data with private key, and able to verify data with public key. Public key and private key is in the Keyring
    6.PackageI will submit the JavaScript package/module to NPM registry so it can be loaded browser via CDN

    Milestone 2 โ€” Basic transaction nodes for Browserโ€‹

    • Estimated Duration: ยฑ3 weeks
    • FTE: 1
    • Costs: 2,000 DAI
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationI will provide inline documentation of the code and simple example that can be imported to the Blackprint Editor
    0c.Testing GuideDelivered node will be fully covered by unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerWe will use GitHub Action/Workflow instead, for manual UI testing/interaction we can use Blackprint Editor
    1.Event nodeAble to listen for balance changes for an account from WebSocket RPC that connected to parachain
    2.Browser ExtensionAble to use browser extension for signing data and obtain account list
    3.Balance transfer nodeAble to transfer balance from an account to another account where the unsigned transaction itself can be signed with Keyring's keypair or browser extension
    4.Payment info nodeAble to obtain payment information from an unsigned transaction
    5.PackageI will submit the JavaScript package/module to NPM registry so it can be loaded browser via CDN

    Milestone 3 โ€” Add support for Node.jsโ€‹

    • Estimated Duration: ยฑ4 month
    • FTE: 0.8
    • Costs: 3,200 DAI
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationI will provide inline documentation of the code, add/improve nodes documentation from Milestone 1 and 2 for both Browser and Node.js
    0c.Testing GuideDelivered node will be fully covered by unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone for Node.js
    1.NodesDelivered nodes from Milestone 1 and 2 can be run on Node.js environment, and exported JSON from the Blackprint Sketch can be imported and executed from Node.js
    2.PackageI will submit to NPM registry so it can imported and used for Node.js

    Note: I may need time to also maintain Blackprint

    Future Plansโ€‹

    • Add Blackprint node for some feature from Substrate Metadata
    • Finishing Blackprint's roadmap
    • Build more nodes for Blackprint to make it more suitable as a development tools or IDE
    • Build a community server on Discord to grow from individual developer into a team
    • Because Blackprint is also still unstable and polkadot.js library may also have some changes on the future, I'm willing to update and maintain the the delivered nodes.

    At the time writting -- when having many nodes and cable, users may find Blackprint looks complicated because currently they can't arrange the cable. Because of that, on the future I'm going to improve the UI/UX for managing cable.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?
    I heard about the Grants Program from Web3 Foundation's website when doing research about Polkadot's Parachain Rollout.

    Additional information that I think may relevant to this application:

    • I'm planning to implement custom node for ethers.js as I already know how to use the library, but currently I more motivated to Polkadot because of this Grants Program.
    • When doing research about Arweave, I also created custom nodes for Arweave. It's already usable on Blackprint Editor and can be imported on Blackprint Editor together with other nodes. But currently it has no tests or documentation.
    - + \ No newline at end of file diff --git a/applications/bldg_app.html b/applications/bldg_app.html index de7aca1937e..b3355a27696 100644 --- a/applications/bldg_app.html +++ b/applications/bldg_app.html @@ -4,7 +4,7 @@ BLDG App | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ โ€“ The Bldg App MVP is live โ€“ http://bldg.app/
  • Are there are any teams who have already contributed (financially) to the project? โ€“ No
  • Have you applied for other grants so far? โ€“ No
    • - + \ No newline at end of file diff --git a/applications/blockchainia.html b/applications/blockchainia.html index 0a094295863..41433a76501 100644 --- a/applications/blockchainia.html +++ b/applications/blockchainia.html @@ -4,13 +4,13 @@ Blockchainia | Web3 Foundation Grants - +
    Skip to main content

    Blockchainia

    • Team Name: Blockchainia
    • Payment Address: 0xf246aede3d892234b52c9bb6f246ab0ac8c0491d (DAI)
    • Level: 2

    Project Overviewโ€‹

    Overviewโ€‹

    Blockchainia delivers the benefits of digital ownership straight to gamers fingertips. Our infrastructure will enable developers to create games for gamers that decide to take ownership of their digital achievements. The Blockchainia library of pallets enables affordable pay-to-play games that forever immortalize gamings greatest moments on-chain. As an eventual competitive gaming metaverse, Blockchaina's ecosystem includes a community hosted online multiplayer infrastructure including a game engine that will interact directly with our gamechain for user moderated online gaming.

    Our Milestone 1 open-source pallets will enable:

    • a web based online multiplayer PvPvE first-person shooter (Player vs Player vs Environment (AI) Enemy)
    • the engine that drives interactions between server and client
    • a leader board that aggregates in-game earned on-chain statistics by week, month, and year.
    • air dropped NFTs earned by completing in game tasks and leader board achievements
    • environment enemies spawned from on-chain NFT assets that funnel spoils back to its owner's wallet
    • a player prompt to create a wallet upon exit or completion
    • community driven DAO that manages the online server infrastructure

    Future milestones will include updates to:

    • an evolving and expanding list of features through our open-source substrate pallet library
    • Two games that use our pallets to share in game items between them
      • an evolving JRPG that explains our gamechains "lore"
      • an evolving arcade style online multiplayer PvPvE

    While there are other gaming projects in the ecosystem, ours differs in various ways. First, we will break the stigma gamers associate with NFTs through a fun JRPG. Non-playable character "blocks" will explain their purpose as well as the metaverse they inhabit in their on-chain existence. However, not all is as it seems in the troubled world of Blockchainia. Players will make their way through seasonally released updates to uncover the deep lore, rescue these NPC blocks, and discover the fun that digital ownership brings to the future of gaming. The items and experience earned in this JRPG will be stored on-chain to the users wallet and available in our arcade PvPvE. We have acquired the URL Blockchainia.gg as the landing page for both of these games.

    Other similar projects in the ecosystem are Ajuna and Bajun. We plan to build off of Ajuna's Layer 1 solution, and expand on their layer 2 and 3 solutions with our own side chain.

    We differ in that we have the behavioral and marketing background to rapidly onboard users, as well as a product that can create a niche for itself in currently over-saturated market. Mark Zuckerberg tried and failed to create a metaverse with endless resources because he fails to realize the human utility of the technology of his time. We have the right team and the right vision to bring the metaverse to fruition, through a fair and economical value proposition that helped NBA Jam (Midway Games) earn 1 billion dollars to Jurassic Park's (Amblin Entertainment) 395 million in 1993, in quarters (.25USD). We believe we can minimize the cost to consumers by operating our sidechain at the lowest cost possible while allowing a DAO driven public server community to earn a reasonable fee for hosting the online multiplayer infrastructure of the games in our ecosystem. This fee will eventually approach a real market value which will add value to the various fungible tokens used throughout the ecosystem.

    We will create free-to-use Unity assets that compliment our tech stack to allow independent developers to duplicate our model and optionally distribute their games via our distribution architecture or use our reputation based, community moderated online-multiplayer infrastructure.

    Project Detailsโ€‹

    Architecture Diagramโ€‹

    Blockchainia Architecture

    Technologies Usedโ€‹

    • Rust
    • Substrate
    • ink! Smart Contracts
    • Node.js Front End
    • C#
    • Unity
    • Adobe Creative Suite
    • Blender

    Ecosystem Fitโ€‹

    Our target audience includes game developers and gamers. Our initial target will focus on indie gamers who would like to remove the overhead realized by releasing their games through traditional distribution channels. Using our infrastructure, developers can release their game free-to-try. Developers will release an NFT collection of playable characters at the same time which grants players full access to decentralized features that will change the way gamers think about the accomplishments and items they earn in game.

    To do this, we will create or modify many existing parts of the Polkadot ecosystem, including browser wallets, chain browsers, and our own parachain optimized for handling real-time game events as on-chain transactions. Our project will have a touch point on almost all levels of the Polkadot stack.

    In future updates, we plan to develop a decentralized means of distribution that allows game developers to release directly to consumers. Our DAO-driven community will engage with developers and provide valuable feedback on desired features, games, and the direction of Blockchainia as a whole.

    Teamโ€‹

    Team membersโ€‹

    Contactโ€‹

    • Registered Address: 502 W 7th St, Suite 100, Erie, PA 16502
    • Registered Legal Entity: Blockchainia LLC

    Team's experienceโ€‹

    Ed Andersonโ€‹

    Ed has three years of software engineering experience developing and renovating the full stack of an enterprise scale system. He holds a B.S. in Computer Science from the University of Pittsburgh, where his Capstone requirement included implementing a MVP token concept, PittCoin, which relied on a bounty-program to connect students to community-sourced homework solutions, the tokens earned from which could be exchanged for extra credit from their professors. He also has five years of experience as the creator and manager of the Katz Business Research Center, during which he oversaw the implementation and successful completion of over one thousand market research and consumer behavior studies and focus groups.

    Matt Dennisโ€‹

    Matt is an entrepreneur with over 10 years of sales and operational experience in the Computer Security and Blockchain industry. He holds a B.S. in Computer Forensics and Information Security, and as certifications in multiple levels of the web3 tech stack.

    Will Chastkaโ€‹

    Will has a passion for gaming, ever since his first gaming console, a sega Saturn, playing virtual fighter 2 and Shinobi Legends, to Starcraft and DOTA. His passion for crypto extends decentralized finance, gaming, and many other applications. He previously held position as Community and Marketing Manager for CryptoAquatics NFT project, and holds a Master's in Business administration from the University of Pittsburgh and a M.S. in Business Analytics from Carnegie Mellon University.

    We plan to leverage all of our experience and industry connections to build a heavily engaged community to gain market share through exploiting an emerging niche in the market with improved technology, our parachain.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Statusโ€‹

    We have begun development on a server authoritative online multiplayer game engine that allows for a dedicated server to interact with a game client and perform the prediction and interpolation to reduce perceived latency enough to allow for a seamless game play experience. We will be adding these repositories below over the next few weeks. When the game is in its first "playable" state we will begin experimentation with Ajuna's service layer for our on chain interactions, building on top of their service layer to implement our custom pallets and interact with a custom game chain.

    Development Roadmap ๐Ÿ”ฉ

    Overviewโ€‹

    • Total Estimated Duration: Continuous

    • Full-Time Equivalent (FTE): 2

    • Total Costs: $25,000

      Milestone 1 โ€” Basic MVPโ€‹

    • Estimated duration: 15 weeks development

    • FTE: 1 FTE

    • Costs: $25,000 USD

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. This project also includes creating documentation to will allow our community to test and involve themselves in our multiplayer gaming infrastructure. We hope to receive and respond to feedback on this community documentation in Milestone 2.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. Unit tests will be written for relevant game server functionality. Unit tests will be written for the DeathToll pallet. In each guide (in each project's Github repo), we will describe how to run these tests. Manual integration testing will be through in-game functionality (i.e, Given an enemy is eliminated on server, the proper state functions are executed on chain, and the leader board updates through the in-game chain browser)
    0d.DockerWe will provide Dockerfiles that can be used to run and test all the functionality delivered with this milestone. This will include a deployable "Full Node" that encases both a game server and substrate node. These will interact with our game client and substrate parachain respectively. A successful MVP will allow a game client to register events on the game server (Server-Authoritative model), which is then written to the parachain ledger. Upon completion of the initial game "level", an "accolade" NFT will be deposited via ink! smart contract to the wallet that completed the required in-game tasks.
    1.Substrate module: Game Engine EventsThe Game Events Substrate module will contain functionality for asynchronously administering the the match between the game server and blockchain node. It is likely that we will break this into multiple pallets, one for core gaming functionality, and one specific to the needs of the DeathToll game-type. The initial pallet features include functionality to create, administer, and write the outcome of a match to the chain, updating the wallets of all players with their earned experience (which is key to the economy of Blockchainia). This module will work on top of Ajuna's service layer to aggregate and marshall game state information relevant to tracked leader board statistics and write to chain. These events will include in game events like player eliminations, deaths, attacks attempted/missed, wins, and other in-game achievements in our continuously expanding list of features. Eventually, this list of configurable features will allow a server owner to run game types similar to those seen in other first-person shooters, like death match, hostage rescue, and capture the flag. The configurable nature of our servers will allow our community to self-explore and find a region of our community that suits their personal play style and temperament.
    2.Unity Game Engine and Configurable Server/ClientWe will embed our substrate based chain interactions into our game engine. While the game client and server communicate to drive game play, the game server will also publish certain events to the game chain via Ajuna's Service layer. Each of these processes will initially be deployable via docker container. The game server architecture will operate from a community driven DAO implemented with existing society and membership pallets available in the Substrate store. The value in the deliverable for the game/server lies in its online multiplayer architecture. We will use a server authoritative model embedded with our web3 backend via the substrate modules created in deliverable 1. We will layer these on top and alongside services provided by Ajuna to interact with our game chain. To start a match, the server must request that a "match" be created on chain via ink! smart contract after collecting a nominal fee from connected players. The server will also request the information necessary to spawn environment enemies in the game map from owned NFTs on chain at random. Lastly, players will spawn and game play will begin. In game events, such as when a player eliminates another player or environment enemy, will be written to chain. These streams of game commands which make up the packets sent by the client to the server are used to compensate for latency with methods like prediction and interpolation. Our engine will be similar to that used in Quake (id Software, Microsoft) and Half-Life (Valve, Sierra Studios), using various methods to compensate for latency and ensure a pleasant user experience, the key difference being that interactions leading to specific events will be logged to the chain. With this advancement in technology, Blockchainia will redefine how streamers and creators interact with their followers, and re-imagine how games can interact with a player. Gamings greatest moments will be immortalized on chain, allowing players the chance to engrave their accomplishments on web3's Stanley Cup, our eternal sliding time window leader board. Milestone 1 begins with a simple MVP to onboard users and test our engine before expanding on our functionality and appealing to a broader market. We will receive community feedback on how to fairly and equitably handle situations including server crashes and moderation of hacking and toxicity. This will lead to a code of conduct in deliverable 2 as we expand our features to include a map and item builder, as well as a strong in-game economy. We will also expand on a configurable set of features that affords future web3 game developers to configure our engine for their own games and expand on its features.
    3.Unity AssetsBesides the NFT playable characters released in our games collections, all assets created by our team will be released free to use by other developers who would like to use our ecosystem to create their own games and mods. These will include wall and floor textures, doors, environment enemies, and other sprites used throughout our games.

    Future Plansโ€‹

    NumberDeliverableSpecification
    1.Oculus VR PortWe plan to port our PvPvE and JRPG to Oculus VR. This will be used to expand into a metaverse of gamers, lead by a community of streamers and industry leaders who moderate their servers and influence the direction of our development team through their position in our community DAO.
    2.Front End ExpansionOur initial browser will be embedded into the game client itself. We plan to expand this to an iOS and Android apps for viewing leader boards, displaying accomplishments, and trading collectibles.
    3.Community ExpansionUsers who are invited to the DAO will be encouraged to run their own reputable server/node to grow their community and earn money from the pay-to-play architecture. Owners will create a hierarchy of moderators called "admins" that will ensure fair, fun, and competitive game play throughout our ecosystem. Owners/Servers who do not fulfill their commitments to the greater community will have their influence slashed.
    4.Automate integration testingAutomated integration tests for all game server/blockchain interactions.
    5.Substrate module: DeathToll Game Events ExpansionWe will add new features to the DeathToll Game Events Substrate module in seasonal updates. The features added will be driven in part by the community that plays the game, in the form of the DAO created during Milestone

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website / LinkedIn

    - + \ No newline at end of file diff --git a/applications/bounce-protocol.html b/applications/bounce-protocol.html index ef3ac408121..7aebd8b95fe 100644 --- a/applications/bounce-protocol.html +++ b/applications/bounce-protocol.html @@ -4,13 +4,13 @@ Bounce Protocol | Web3 Foundation Grants - +
    Skip to main content

    Bounce Protocol

    This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

    • Team Name: Bounce
    • Payment Address: bc1qwm44hpv8qyvmwpcupqwn4rx52xzt5qr9lremhz
    • Status: Terminated

    The above combination of your GitHub account submitting the application and payment address will be your unique identifier during the program. Please keep them safe.

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Bounce is a decentralized auction platform, incorporating liquidity mining, decentralized governance and staking mechanisms. The first principle of Bounce is scarcity of resources, which creates a competitive swap environment.

    The idea of โ€œswapโ€ originated from Uniswap, where infinite liquidity is provided for participants. While this is a great and concept, Bounce focusses on the opposite scenario instead.

    Bounce provides a competitive environment, for a limited supply of tokens or other assets like NFT's. The assets can be auctioned off in various ways, such as:

    • Token sales: Various types of auctions where a limited amount of tokens are auctioned off with different auction principles and time limits, such as fixed price (fixed swap auction), decreasing price (Dutch auction) or hidden price (sealed-bid auction)

    • NFT auctions: NFT's are auctioned off with similar auction principles as token sales. However, there is usually a lower number of NFT's (or only a unique piece) for sale.

    We will run Bounce chain as standalone chain first, then join in Kusama/Polkadot network when parachain mechanism is ready.

    Ethereum contracts vs Substrate modulesโ€‹

    NumberEthereum contractsSubstrate modules
    1.high gas feelow tx fee
    2.hard to upgradeeasy and seamless module upgrade
    3.poor governancestrong governance
    4.payout manually by userpayout automatically by call on_finalize() or offchain_worker()
    5.hard to prevent scam auction poolsintroduce social module to prevent scam auction pools

    Project Detailsโ€‹

    Ecosystem Fitโ€‹

    Bounce is currently only viable decentralized auction protocol that is live on Ethereum and Binance Smart Chain

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Jack Lu
    • seiya1192

    Contactโ€‹

    • Registered Address: Three Embarcadero Center, Promenade Level Suite P5, San Francisco, CA 94111
    • Registered Legal Entity: Bounce DAO Limited

    Team's experienceโ€‹

    Jack Lu: Based in San Francisco, Haozheng "Jack" Lu is the investment director at NGC and founder of Bounce Finance. Jack specializes in researching blockchain mechanisms for generating decentralized consensus and real-world implications provided by blockchain. Jackโ€™s invaluable presence at the company is defined by his abilities to analyze economic and social models behind projects, while also exploring the game theoretical topics including incentive provisions, industrial organization and market microstructure on blockchain and smart contract. Jack is an Economics support to NGC portfolio projects , helping with research in economics of information and economics of cloud computing.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-time equivalent (FTE): 2 FTE
    • Total Costs: 0.9 BTC

    Milestone 1 โ€” Implement Substrate Modules and Bounce Chainโ€‹

    • Estimated Duration: 2 month
    • FTE: 2
    • Costs: 0.9 BTC
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.Substrate module: fixed-swap-auctionImplement the core function of fixed swap auction
    2.Substrate module: sealed-bid-auctionImplement the core function of sealed bid auction
    3.Substrate module: dutch-auctionImplement the core function of dutch auction
    4.Substrate module: english-auctionImplement the core function of english auction
    5.Substrate module: nftImplement an ERC1155-like asset module
    6.Bounce chainImplement a blockchain based on Substrate and include ERC20 & NFT asset and auctions modules
    7.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain

    Future Plansโ€‹

    • We will integrate EVM module into Bounce Chain to support Ethereum ERC20 tokens.
    • We will implement more type of auctions like lottery auction, social verified auction, etc.

    Additional Information โž•โ€‹

    Possible additional information to include:

    • What work has been done so far?

      Bounce dApp product on Ethereum and Binance Smart Chain.

    • Are there are any teams who have already contributed (financially) to the project?

      No

    • Have you applied for other grants so far?

      No

    - + \ No newline at end of file diff --git a/applications/bright_treasury.html b/applications/bright_treasury.html index 36ba6ab2425..e11c7afc491 100644 --- a/applications/bright_treasury.html +++ b/applications/bright_treasury.html @@ -4,13 +4,13 @@ BrightTreasury | Web3 Foundation Grants - +
    Skip to main content

    BrightTreasury

    • Team Name: Bright Inventions
    • Payment Address: 0xC1bE52Df4d34f86594cFaF69D374e2C48194d1cC

    Project Overviewโ€‹

    BrightTreasury logo

    BrightTreasury - a web app for handling the network treasury module.

    Overviewโ€‹

    The aim of the BrightTreasury project is to create a standalone web application along with a PWA representation that would allow performing basic actions on the Treasury module of Polkadot and Kusama Substrate networks (with a potential to support any Substrate-based network with Treasury module). It would allow a more intuitive and lightweight flow of submitting proposals as well as an overview of the Treasury related actions.

    Our focus will be on the regular userโ€™s actions rather than the council perspective for this first release. We want to attract more professionals who could contribute to the community with their ideas and skills but at the same time may not be as fluent in blockchain customs and terminology.

    Based on the discussions with the Substrate networksโ€™ users and council members as well as analysis of the comments under Polkadot and Kusama proposal submissions, we identified areas that caused most issues in the Treasury funding process from the userโ€™s perspective. The main needs that were brought up were:

    • more intuitive proposal submission flow, with clearer indication of a proposal idea being subject to the community discussion, before submitting to blockchain and committing with bond funds
    • one place for following the submitted proposals, their status and the results of motions
    • a unified discussion forum to leave comments about submitted proposals as well as their draft versions (ideas)
    • implementation of the new bounties funding mechanism

    Following these needs, we propose a solution that will benefit the Substrate chains communities.

    Project Detailsโ€‹

    The application will have the proposal lifecycle as its main focus - starting from a more approachable proposal definition, clearly stated two phases of the submission (an Idea for preliminary discussion and the formal Proposal after blockchain confirmation) followed by an intuitive overview of the submitted proposals and their state.

    Technology stack: NestJS and React

    In addition to the currently available functionality within the Treasury module, we plan to introduce supplementary features that can benefit the user experience.

    What is more, as we understand that visual aspects are crucial when talking about user experience, we have prepared the clickable designs that illustrate the main flow we wish to implement. Please find it under the following link: https://xd.adobe.com/view/0bb66d6e-5797-40bc-aa29-c6f71131f402-5ee5/

    Features will include:

    1. Treasury overview
      1. Summarise treasury info
      2. Display spend period stats

        3. Spend period stats

      3. Show ideas/proposals details

        4. Show ideas/proposals list details

        Show ideas/proposals details

        • Link to proposal details in other services
        • Milestones

          • Milestones

        • Link to in-app proposal details with discussion
        • Related motions
        • Subject of proposal
        • Reason of proposal
        • Reward and bound
        • Proposerโ€™s information
        • Portfolio
        • Nets of submission
      4. Show approved proposals
    2. Submit proposal
      1. Submit an idea - for discussion
      2. Submit a proposal to blockchain
    3. Integrated motions overview
    4. Switching between networks (+ an overview of proposals shared between Substrate chains)
    5. Login in-app
    6. History in-app (past proposals accepted/rejected)
    7. Bounties

      8. Bounties

      1. Add a new bounty

        2. Bounties

      2. Nominate a bounty curator
      3. Set a bounty status
      4. Reward a bounty
    8. Mobile responsive UI (tablet & phone) & Progressive Web App (PWA)

      9. Tablet

      Mobile

    Ecosystem Fitโ€‹

    Currently, the Treasury module is a part of the general network management tool. We plan to separate it and develop an independent service, with a more streamlined and intuitive flow and presentation. Such a platform would be more approachable for the users from outside of the blockchain community and have a potential for simpler promotion of the Treasury funded actions.

    Main distinguishing features:

    • a more intuitive, two-step flow for submitting proposals (Idea -> Proposal)
    • in-app module for more detailed proposal descriptions (like adding milestones) connected with proposal related discussion and - reporting progress on approved proposals
    • clear overview of the submitted proposals matched with derived motions and their results
    • historical overview of the past spending periodsโ€™ proposals that were submitted using the app
    • the first app with dedicated bounties implementation
    • in-app login

    Teamโ€‹

    Team membersโ€‹

    • Agnieszka Olszewska - Technical Lead, blockchain specialist
    • Alisa Kashytska - UI/UX design
    • Szymon Miloch - fullstack developer
    • Daniel Makurat - fullstack developer, blockchain specialist
    • Katarzyna ลukasiewicz - Project Manager

    Contactโ€‹

    Bright Inventions is a limited liability company based in Gdansk, Poland. Company was founded in 2012 by Daniel Makurat and Michaล‚ ลukasiewicz.

    Full address details:

    Bright Inventions Sp. z o. o.

    ul. Jana Matejki 12

    80-232 Gdaล„sk, Poland

    info@brightinventions.pl

    www.brightinventions.pl

    Company registration number: 0000687244

    VAT EU: PL5842761920

    REGON: 367805647

    Bright Inventions is a team of 50 full-time onsite developers, project managers & UX/UI designers - experts in mobile and web applications, systems integration, IOT devices and Blockchain platforms.

    We believe that building a software product is about people working together in a collective way. By offering complex support โ€“ mobile and web development as well as IT consultancy we try to eliminate roadblocks towards engaging clients as partners at every step of the process.

    We support startups, digital agencies as well as medium to big businesses. We cooperate with startups, accelerators and incubators. Whatever the client profile is, we always aim to establish a satisfying partnership for both sides. Since 2012 we have built software for more than 40 businesses worldwide.

    Team's experienceโ€‹

    • Agnieszka - she is a senior backend developer with main interest in data modelling. She started her software development career 10 years ago and from then she began discovering a lot of new technologies. Among them there are JavaScript, TypeScript, React, Postgres, Node.js, NestJS. Most recently sheโ€™s been engaged in developing blockchain based solutions with Substrate.
    • Alisa - a UI/UX designer with a passion for digging deep into the product domain and understanding the user's perspective. She has worked on the design for multiple web/mobile solutions and lately has been responsible for UI redesign of Parity Building Blocks Android and web apps.
    • Szymon - a positive and ambitious software developer who has developed a passion for both Android and web, with experience in Kotlin, React, Node.js and Nest.js among other technologies. Always open to opportunities and projects where he can find something new to learn. Experienced in working in international teams.
    • Daniel - his main areas of experience is development of data processing software and configurations. He develops in TypeScript, Node.js, NestJS. Heโ€™s been a part of the development teams working on blockchain solutions for Parity projects.
    • Kasia - she has been working with agile methods for over 10 years, both as a researcher and a practitioner. She believes in teamwork and a power of user centered mindset. With experience in leading international projects, she knows how to support and encourage timely and high quality deliveries.

    Team Code Reposโ€‹

    https://github.com/bright/bright-tresury

    Team LinkedIn Profilesโ€‹

    Development Roadmapโ€‹

    The development of the specified user stories will be broken into 3 milestones, each taking 1 month to complete.

    Definition of Done for each user story:

    • Unit tests passed
    • Code has been reviewed by peer
    • Acceptance criteria were met
    • Internal QA has been performed
    • Documentation has been written
    • Screens are responsive and prepared both for desktop and PWA (mobile and tablet)
    • Browser compatibility
      • Chrome from 70 upwards
        • ย ย 
      • Safari from 12 upwards
      • Firefox from 57 upwards
        • ย ย ย 
      • Edge from 42 upwards

    At the end of each milestone:

    • The user stories listed for the given milestone have been implemented both on frontend and backed and the DoD criteria were met, allowing the user to perform the defined actions
    • The functionality has been deployed to stage environment, accessible for testing purposes

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-time equivalent (FTE): 1
    • Total Costs: 28 500 DAI

    Milestone 1 โ€” Idea creating & Proposal submission & in-app loginsโ€‹

    • Estimated Duration: 1 month
    • FTE: 1.1 FTE
    • Costs: 10 450 DAI

    The main goal of this milestone is to implement the core flow of the app, that is the Proposal lifecycle. As a result the user will be able to create an Idea, add all the necessary details, create Milestones for an Idea, make it public and decide to submit the Idea to the blockchain, turning it into a formal Proposal. The status of the Proposal will be then updated based on the data returning from the API. To perform these actions a user will need to be logged in, however browsing through ideas and proposals will be available to everyone.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide inline documentation of the code and a basic tutorial that explains how to set up and run the project.
    0c.Testing GuideThe code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests.
    1.User Story 1As a user, I can sign up and sign in to the app
    2.User Story 2As a logged in user, I can create an idea and publish it or save as a draft.
    3.User Story 3As an idea owner, I can edit my draft idea and publish it to the community for viewing
    4.User story 4As an idea owner, I can edit my idea.
    5.User story 5As an idea owner, I can add/edit/remove milestones.
    6.User story 6As an idea owner, I can submit my idea as a proposal (signing and submitting one transaction).
    7.User story 7As an idea owner, I can turn each milestone separately to a proposal (signing and submitting a separate transaction for each milestone). One milestone at a time.
    8.User story 8As an idea owner, I can edit my ideas as long as the proposal is not closed (rejected or submitted).
    9.User story 9As an unlogged user I can view all ideas.
    10.User story 10As an unlogged user I can view details of an idea.
    11.User story 11As an unlogged user I can view the details of proposals and their votings. (In this milestone, there will be no in-app history of transactions made outside of the app. Once a proposal is rewarded, itโ€™s voting result will not be visible in the app. This will be available in the milestone 3)
    12.User story 12As an unlogged user I can view proposals listย 
    13.User story 13As an unlogged user I can view the details & status of proposals
    14.Stage environmentWe will provide an online staging environment with a local Polkadot node to demonstrate the full functionality of our app.

    Out of scope: council votingโ€‹

    Milestone 2 โ€” discussions panel & treasury overview & multiple networksโ€‹

    • Estimated Duration: 1 month
    • FTE: 0.9 FTE
    • Costs: 8 550 DAI

    The goal of this milestone is to add more features to the ideas and proposals handling. The ideas as well as proposals will have the discussion functionality added and it will be possible to add them to multiple networks as well, as the representation of multiple blockchain networks feature will also be implemented at this stage. What is more, an overview of the treasury statistics will be presented for each network respectively.

    NumberDeliverableSpecification
    1.User story 14As a user, I can switch between networks and see data for the selected network.
    2.User story 15As an idea owner, I can add an idea and milestones to multiple networks.
    3.User story 16As an idea owner, I can submit my proposal into multiple networks (signing and submitting one transaction for each added network).
    4.User story 17As an idea owner, I can submit each milestone separately as a proposal into multiple networks (signing and submitting a separate transaction for each milestone for each added network). One milestone at a time.
    5.User story 18As a user, I can view stats of the treasury module
    6.User story 19As a logged in user I can discuss the idea.
    7.User story 20As a logged in user I can see notification about new comments (in my idea and in ideas I have discussed on)
    8.User story 21As a logged in user I can get email notifications about new comments (in my idea and in ideas I have discussed on)

    Milestone 3 โ€” Bounties & in-app historyโ€‹

    • Estimated Duration: 1 month
    • FTE: 1 FTE
    • Costs: 9 500 DAI

    The main goal of this milestone is implementation of the bounties mechanism. Users will be able to add and browse through bounties, votings for their curators and check the current status. The curators will be able to accept (or reject) their nominations and manage the bountyโ€™s status. Additionally, in this milestone we plan to add a basic integration with Polkassembly. It will be possible to see the description of a proposal/bounty published on Polkassembly. We will also include the history feature based on the data from Polkassembly, which would allow users to browse through closed proposals and bounties, in addition to in-app ideas. What is more, we plan to prepare the Milestone 1 and 2 features for production environment and deploy them, so they would be already fully functional to the Polkadot and Kusama proposals.

    NumberDeliverableSpecification
    1.User story 22As a logged in user I can create a bounty proposal
    2.User story 23As an unlogged user I can view voting on approving/rejecting the proposal
    3.User story 24As an unlogged user I can view proposed curator and voting on assigning them
    4.User story 25As a curator I can accept the nomination
    5.User story 26As a curator I can reject the nomination
    6.User story 27As a curator I can award the bounty with a chosen beneficiary
    7.User story 28As a curator I can extend expiry date of a bounty
    8.User story 29As a user I can claim the payout of the bounty (the reserved amount will be paid out to the beneficiary account)
    9.User story 30As an unlogged user I can view the bounty proposal status
    10.User story 31As a curator I can edit the contextual info of a bounty (title, description, people who do the work) and report progress.
    11.User story 32As a user, I can view the details and voting history of closed proposals (only for Polkadot and Kusama networks)
    12.User story 33As a user, I can view the details and voting history of closed bounties (only for Polkadot and Kusama networks)
    13.User story 34As a user I can see the proposalโ€™s description published on Polkassembly.
    14.User story 35As a user I can see the bountyโ€™s description published on Polkassembly.
    15.User story 36As a user I can use the Milestone 1 and Milestone 2 features in production environment
    16.User story 37As a user I cannot edit my idea once the associated proposal is closed (rewarded or rejected)

    Community engagementโ€‹

    It is our priority to make the BrightTreasury app a living part of the communityโ€™s life and as such, we plan on several informational activities such as:

    • We want to ask Polkadot blog team to kindly agree on us publishing two articles on their blog (https://polkadot.network/blog/): one at the beginning of the project, second as a tutorial at the end of the project
    • We will also submit an article to Medium at the end of the project, presenting the application and its potential contribution
    • Two blog posts on our Bright Inventions blog https://brightinventions.pl/blog

    Future Plansโ€‹

    In future, we plan to include a Tips mechanism as well, with a similar intuitive approach.

    What is more, we would like to further integrate with Polkassembly to allow a two-way communication. We plan to display proposals and bounties created using BirghtTreasury (along with their details and discussions) in Polkassembly as well and update any changes in both services.

    - + \ No newline at end of file diff --git a/applications/c++polkadot-light-client.html b/applications/c++polkadot-light-client.html index 9f81f8abe7e..bde601b86ac 100644 --- a/applications/c++polkadot-light-client.html +++ b/applications/c++polkadot-light-client.html @@ -4,7 +4,7 @@ Polkadot Light Client in C++ | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ Define embedding environment interface such as bindings in JavaScript

    Specifications for multichain supportโ€‹

    Specify scope and support for Parachain and Relay chain

    JSON-RPC service APIsโ€‹

    Define APIs to be supported* (submitting transactions, watching transactions / blocks / accounts, etc)

    As the RPC API is currently unstable (see PSPs#41), specification must be written first.

    Components specifications / selectionโ€‹

    Networking (likely cpp-libp2p)
    Database (likely SQLite)

    *Web3 Foundation input required

    Ecosystem Fitโ€‹

    This is an alternate implementation to the WASM light node in Smoldot.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    Equilibrium discussed with David Hawig on different implementation on Polkadot host, C++, AssemblyScript and Zig. After initial research, Equilibrium has decided to apply for the C++ implementation of the light node.

    Development Roadmap ๐Ÿ”ฉโ€‹

    To achieve the final implementation, the project is broken down into 2 phases:

    This proposal is only for Phase 0 and will culminate with the delivery of a detailed specification for the light client implementation in Phase 1.

    Overviewโ€‹

    Milestone 1 โ€” Substrate Module Researchโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT
    0b.FormatMarkdown (mdBook)
    0c.PublishedGitHub, GitHub Pages
    1.Cryptographysecurity advantages over connecting to 3rd-party node, limitations compared to full client
    2.Runtime environment requirementsfor browser and Node.js
    3.JSON-RPC APIsminimal run-time access interface
    4.Dependencieslibraries for cryptography, networking, build

    Future Plansโ€‹

    From here we would move on to the implementation of the light client node in Phase 1. We expect Phase 1 to be completed by a larger team at Equilibrium.

    - + \ No newline at end of file diff --git a/applications/cScale.html b/applications/cScale.html index 110c2df259c..32b23e19dc5 100644 --- a/applications/cScale.html +++ b/applications/cScale.html @@ -4,13 +4,13 @@ cScale | Web3 Foundation Grants - +
    Skip to main content

    cScale

    This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a > (such as this one) can be removed.

    See the Grants Program Process on how to submit a proposal.

    • Team Name: Matthew Darnell (Individual)
    • Payment Address: 15ssDeS9peN9a3rDwFrV19YJ8oRffmphaE (BTC)
    • Level: 1
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    • cScale is a SCALE codec implementation in C
    • Currently there does not seem to be a working standalone implementation of this serialization codec in C
    • A SCALE implementation would allow for the development of more desktop applications communicating with Substrate nodes
    • I am developing this because I am interested in creating a simple and secure desktop Substrate wallet
    • I already have a generally working product that I would also like to improve as I get suggestions

    Project Detailsโ€‹

    • Technology stack will be a simple C library, mostly in C99 with a few uses of C11 _Generic. One dependency currently will be included which is an open sourced, single file, pure-header utf8 implementation useful for SCALE string encoding.
    • Makefile is included but can do simple CMakeLists.txt if preferred
    • Supported Data Types will be:
      • Fixed Width Integers
      • Compact/General Integers
      • Booleans
      • Options
      • Vectors (and Strings)
      • Enumerations
      • Tuples
      • User-Defined Data Structures
    • Some limitations and caveats:
      • C does not support uint128_t types. Possible options are to introduce a 3rd party dependency or consume u128 values encoded as char* strings. GCC does provide a uint128_t extension but I'm not sure how universal this is and C does not support sufficiently long literal int values. Currently I am able to encode from a hex-represented u128 but could consume decimal represented char* strings if required.
      • Enumerations are tricky to implement as they are user-defined. I am able to construct a struct which generates a custom enum type by consuming an array of strings of different types, e.g. [Int, Bool], but I am not sure how to make this very clean for the user.
      • A lack of templating and type inference makes encoding/decoding user-defined struct values a little difficult. I am able to achieve this by defining a custom struct which contains a serialize as well as deserialize function pointer. The user will be able to include this struct in his data structure and assign his own custom function. This works fine, but again, it is a little more in depth for the end user than ideal.
      • With each of these, I would love feedback from others on how to improve the library!

    Ecosystem Fitโ€‹

    • The target audience are Desktop C/C++ developers who would like to be able to encode and decode Substrate API data
    • Similar Projects
      • Kagome (C++ and not intended for standalone library use)
      • FinoaBanking substrate-c-tool (Has not been updated for over a year and is in unknown state of completion as far as I can tell)

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Matthew Darnell

    Contactโ€‹

    Team's experienceโ€‹

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    Currently have a basic working implementation. Generating a testing app, a basic cli app, and a statically linked library.

    Some examples:

    Fixed Intโ€‹

    scale_fixed_int fixed = { 0 };
    encode_int_to_fixed_int_scale(&fixed, (uint16_t)42);
    uint8_t serialized[64] = { 0 };
    size_t serialized_len = 0;
    serialize_fixed_int(serialized, &serialized_len, &fixed);

    uint16_t output = 0;
    decode_scale_fixed_int((void*)&output, &fixed);

    for(int i=0; i < serialized_len; i++) printf("%02X", serialized[i]);
    printf(" --- %u\n", output);

    Prints:

    2A00 --- 42

    Compact Intโ€‹

     scale_compact_int compact = { 0 };
      encode_compact(&compact, (uint32_t)69);
      uint8_t serialized[64] = { 0 };
      size_t serialized_len = 0;
      char *output = decode_compact_to_hex(&compact);
      serialize_compact_int(serialized, &serialized_len, &compact);
      uint32_t decoded = strtoul(output, NULL, 16);
      printf("SCALE=<");
      for(int i=0; i < serialized_len; i++) printf("%02X", serialized[i]);
      printf("> --- Hex=<%s> --- Decoded=<%u>\n", output, decoded);
      free(output);

    Prints:

    SCALE=<1501> --- Hex=<45> --- Decoded=<69>

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1 month
    • Full-Time Equivalent (FTE): 1 FTE
    • Total Costs: 10,000 USD, denominated in Bitcoin

    Milestone 1 - Working Productโ€‹

    • Estimated duration: 2 weeks
    • FTE: 1
    • Costs: 9,000 USD in BTC
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationI will provide a README with several examples as well as a .c file for each data type with several tests showing encoding and decoding. I will also provide a docs folder containing a markdown file giving examples for each data type as well as commenting each function in the main header file.
    1.Intermediate StructsI will provide a set of Structs which represent SCALE data internally before being processed
    2.EncodeI will provide a set of functions that encode data into intermediate structs as well as others to serialize them. Each will generate an array of uint8_t* as well as a corresponding length
    3.DecodeI will provide a set of functions that decode a valid SCALE uint8_t* array into the appropriate intermediate struct as well as functions to deserialize the struct back into raw data
    4.TestingI will provide a testing application which tests each data type and ensures correctness
    5.Basic CLII will provide a basic command line interface app which will encode/decode fixed width and compact integers

    Milestone 2 - Additional testingโ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: 1,000 USD in BTC
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationI will add several useful structs to the docs folder which represent actual Substrate data with their respective serialization functions. (AccountInfo, AccountData)
    1.TestsI will work to provide more tests, preferably utilizing Rust FFI to compare against parity-scale-code results. This may or may not require some assistance as I have never used Rust FFI.

    Future Plansโ€‹

    • I am writing this library to use in my own personal desktop wallet application
    • I see a real need for it to allow the Substrate community to grow and I hope it makes it on the official list of Scale Implementations
    • Long term I would be interested in improving this library to keep current with a possibly-evolving SCALE standard as well as getting help from other C devs making pull requests, which would be most welcome.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Shawn Tabrizi

    • This started as a personal project and I would like to assist in expanding the Substrate ecosystem by providing a critical element of its infrastructure in C
    - + \ No newline at end of file diff --git a/applications/candle_auction_ink.html b/applications/candle_auction_ink.html index d2e549867d4..a6483741630 100644 --- a/applications/candle_auction_ink.html +++ b/applications/candle_auction_ink.html @@ -4,7 +4,7 @@ Candle Auctions on Ink! | Web3 Foundation Grants - + @@ -16,7 +16,7 @@ academic course on Decentralized Applications on Ethereum platform at Innopolis University in 2017.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    โœ”๏ธ PoC is implemented (~75% completeness of the Milestone-1).
    Please see the project's Github repo ๐Ÿ‘ˆ
    which contains both sources and documentation.

    Development Roadmap ๐Ÿ”ฉโ€‹

    (This is taken as_is from the RFP, as I agree with it)

    Milestone 1 - Basic auctionโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationInline documentation (builds to cargo doc) + basic How-Tos explaining installation, deployment and usage of the contract
    0c.TestingCore functions are covered by unit tests, which serve both sustainability of code and providing another way of explaining its logic
    0d.DockerN/A for smart contracts
    1. โœ…Start & close periodCreate an auction mechanism that has a fixed start and end period
    2. โœ…Accept bidsAny user can call the contract with a bid that is higher than the last highest bid
    3. โœ…Find winnerDetermine a winner at the close period
    4.Embed reward logicThe contract creator should set logic that will be executable by the winner. Such call logic should accept optional parameters. This logic should be set at the start and be immutable henceforth
    5.PayoutA winner should be able to make a call, with an arbitrary number of parameters, to the reward/payout method. The contract would then pass the arguments to whichever logic is encoded as the reward (and e.g. send tokens)

    Milestone 2 - Random closeโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationInline documentation (builds to cargo doc) + basic How-Tos explaining installation, deployment and usage of the contract
    0c.TestingCore functions are covered by unit tests, which serve both sustainability of code and providing another way of explaining its logic
    0d.DockerN/A for smart contracts
    0e.ArticleA blogpost and\or a workshop showing the smart contract features will be published
    1.Retroactive closeAt the close block, rather than announcing the highest bidder at that point, the contract should randomly determine a block in the past (between start & end blocks) and calculate the highest bidder at that block to be the winner
    2.Randomness source (optional)Randomness source should be configurable (e.g. from hash of the block in the relay chain, from a randomness beacon parachain etc.)

    Milestone 3 - Substrate.dev Workshopโ€‹

    A comprehensive tutorial\workshop to be added to Substrate Developer Hub.

    NumberDeliverableSpecification
    0a.LicenseSame as substrate-docs or Apache 2.0. The delivery will be either merged into substrate-docs and inherit license from it, or published under Apache 2.0 as part of a separate repo
    1.ยง Candle Auction BasicsLearn the basic mechanincs of a candle auction
    2.ยง ERC721 & DNSLearn ERC721 and DNS contracts implementations in Ink!
    3.ยง Cross-Contract CallsLearn cross-contract communication patterns in Ink!
    4.ยง Auction Set UpLearn to deploy and to instantiate these contracts, to mint tokens, to register domain and to put them dowm to an auction
    5.ยง Auction RunLearn to place bids to an auction, to check its subject and status, to detect winner and to get payouts
    6.ยง Contract VerificationLearn how to verify smart contract code on Polkadot parachain
    7.ยง Add New Reward ContractLearn to add a new type of auction subject and to plug-in it into our conract logic
    8.ยง Change Randomness SourceLearn to set another on-chain randomness source for our candle

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    I came across its repository while surfing Parity's and W3F resources on Github.

    - + \ No newline at end of file diff --git a/applications/canyon_network.html b/applications/canyon_network.html index e9197f5110c..3eb0022b6bf 100644 --- a/applications/canyon_network.html +++ b/applications/canyon_network.html @@ -4,13 +4,13 @@ Canyon Network | Web3 Foundation Grants - +
    Skip to main content

    Canyon Network

    • Team Name: Canyon Labs
    • Payment Address: 0x009643f61C7cbc91404aE77Fe65542D098B822d1 (DAI)

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Canyon is designed to be a permanent storage network built on Substrate, which records the hashes of files on-chain and stores the files off-chain. By blending PoS and a probabilistic proof-of-storage scheme inspired by Arweave, Canyon greatly reduces the barriers to entry for miners, who are incentivized to store as much data as possible for the rewards. Another focus of canyon is also to build a truly useful data sharing system, providing the high availability of data access in the protocol level.

    Project Detailsโ€‹

    This grant mainly concentrates on the consensus part of canyon network, specifically the PoA consensus will be implemented. Aside from the core consensus algorithm, some indispensable basic components/tools will be built at the same time. Refer to the consensus section of white paper for more information. We'll also keep updating the technical details in the paper when necessary once more progress is made.

    Ecosystem Fitโ€‹

    There is no doubt that the infrastructure, providing a secure, highly available, low-cost, and easy-to-use decentralized data access service, will be an essential part of Web3.0 applications. Canyon network is created in such a background and tries to mitigate the known problems in the existing decentralized platforms, with a principle of lightweight storage consensus and highly usable protocol level data retrieval mechanism in mind.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Name of team leader: Liu-Cheng Xu

    Contactโ€‹

    • Registered Address: 3 FRASER STREET #05-25, DUO TOWER, SINGAPORE
    • Registered Legal Entity: Canyon Labs PTE. LTD.

    Team's experienceโ€‹

    • Liu-Cheng Xu
      • He has been working as a core developer of several projects in the blockchain field for years.
      • He is the core developer as well as the tech lead of ChainX.
      • He was the early core developer of Bytom.

    Team Code Reposโ€‹

    The GitHub accounts of all team members:

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Currently, we already have a skeleton substrate canyon and the Rust CLI canyon-cli to interact with the chain.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1.5 months
    • Full-Time Equivalent (FTE): 1
    • Total Costs: 15,000 USD

    Milestone 1 โ€” Implement the PoA consensus POCโ€‹

    • Estimated duration: 1.5 month
    • FTE: 1
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains the implementaion details of PoA consensus. We will update our paper with more SPoRA technical details and analysis.
    1.Node: cc-rpcWe will create a crate that will provides two RPCs: permastore_submit and permastore_retrieve for storing the data(<=10MiB) respectively
    2.Node: cc-databaseWe will create a crate that will provide the feature of persistent transaction data storage on the top of offchain storage.
    3.Node: cc-consensus-poaWe will create a crate that will implement the core algorithm of PoA illustrated in the white paper. This crate will also implement the function of inherent data provider to inject a DigestItem::Seal entry providing the proof of access into the block header. We will verify the DigesteItem::Seal(PoA) item in the block header by wrapping a poa import queue component into the current babe block import.
    4.Node: pallet-poaWe will create a pallet that will implement ProvideInherent to make use of the inherent data created in step 3, create an inherent extrinsic update_storage_capacity recording the storage capacity of block author on-chain.
    5.Rust CLI: submitWe will extend canyon-cli by adding two new commands: submit to store the data from CLI which calls permastore_submit internally, submit-and-store will firstly call submit and send the extrinsic permastore::store to actually store the data onto the network.

    cc-rpc RPCs:

    • permastore_submit

      • fn submit(value: Bytes) -> Result<H256>
      • user can send arbitray data bytes(<=10MiB) to the node, the chunk root will be returned once stored successfully.

    • permastore_retrieve

      • fn retrieve(key: Bytes) -> Result<Option<Bytes>>
      • user can retrieve the data(<=10MiB) directly using this PRC, the key is the chunk root of the data.

    Future Plansโ€‹

    The short term plans:

    • Implement the pricing strategy for the store transaction in the context of paying once for the perpetual storage.
    • Support uploading/retrieving data chunks for large files(>10MiB).
    • Implement transaction data sync between the multiple nodes.
    • A comprehensive design for Staking system on the top of NPOS, taking the factor of validator that also behaves a storage service provider into account.
    • Improve and audit the code to make it production-ready.
    • Build client tools for storing data onto the network easily, especially the web UI.
    • Build a network data explorer that shows the distribution of data in network nodes.

    The long term plans:

    • Do more researches and develop a more effective data sharing mechanism, rendering canyon network a highly useable data retrieval platform.
    • Foster more web3.0 applications using the decentralized storage infrastructure provided by canyon network.

    Additional Information โž•โ€‹

    The earlier successful W3F grant name is Canyon Network, which is mainly about the early research problems on the decentralized storage network and can be considered the starting point of works afterward.

    - + \ No newline at end of file diff --git a/applications/centrifuge-gsrpc-v2.html b/applications/centrifuge-gsrpc-v2.html index 0308c1dae6b..fa24b50d34d 100644 --- a/applications/centrifuge-gsrpc-v2.html +++ b/applications/centrifuge-gsrpc-v2.html @@ -4,7 +4,7 @@ Centrifuge Go-Substrate-RPC Client V2 | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Centrifuge Go-Substrate-RPC Client V2

    • Team Name: k/factory (former Centrifuge Development Team)
    • Payment Address: Ethereum(USDC) - 0x2B8A956BF807E22d858dc9AD2eFc30cccc3Ea676
    • Level: ๐Ÿ“ 3

    Project Overview ๐Ÿ“„โ€‹

    This is a follow-up grant to keep building on top of this Go Client implementation. In the past we had two grants.

    The original grant through w3f:

    And a maintenance Grant through Polkadot Treasury:

    Overviewโ€‹

    Initially Go-Substrate-RPC (GSRPC for short) was designed under the premise of being a low-level, static and strongly typed library, where all the type resolution happen at compilation time.

    This approach allowed almost full flexibility to developers to build their own types and events depending on the target chain/s they were connecting to.

    On the other hand, since the types are statically defined, this didnโ€™t leave room to, gracefully, deal with parsing errors when a type (defined on the chain runtime) is not defined in the GSRPC client.

    Project Detailsโ€‹

    The problemโ€‹

    For a hypothetical RuntimeA, give TypeA:

    type TypeA struct {
        AttrA String
        AttrB int
    }

    and EventA, that uses TypeA:

    type EventA struct {
        Data TypeA
    }

    The GSRPC instance should define TypeA to be able to decode EventA. If the client is defined as such, then there will be no problem parsing it.

    Now lets presume that a RuntimeUpgrade is executed and now the target chain is at version B -> RuntimeB. In this runtime ugprade attribute AttrB of struct TypeA has changed to String:

    type TypeA struct {
        AttrA String
        AttrB String
    }

    Then when the GSRPC client is trying to parse the event, it will fail while trying to decode the scale encoded value into the EventA struct since the type that is expecting for AttrB is an int but a string has been provided.

    This issue gets more critical when we are talking about processes, like bridges, that need to successfully parse every event in a block looking for a relevant event to their business logic. If due to the above reason, an event can't be parsed then the bridge relayer cannot ensure that a relevant event was or wasn't in that block. Therefore the only options are to skip that block (hoping that there was no relevant event within) or wait until the client is updated to continue parsing blocks, which disrupts the bridge operations.

    Solutionโ€‹

    With the inclusion of Substrate Metadata 14, we now have a definition of all the types included in a specific runtime.

    This means that at bootstrap time (and upon other certain situations) GSRPC can build a registry of types based on the data provided by the target chain metadata.

    Load types into registry from Metadataโ€‹
    Example of Metadata 14 type structure for a Balances.Transfer Eventโ€‹

    Pallet Name and associated type variants index

    Pallets.5.Name = "Balances"
    Pallets.5.Events.Type.UCompact = 28 // Events list type index

    For event Balances.Transfer with index 2 in the variants list there are 3 fields, from, to & amount.

    Lookup.Types.27.Variant.Variants.2.Name = "Transfer"
    Lookup.Types.27.Variant.Variants.2.Fields.0.Name = "from"
    Lookup.Types.27.Variant.Variants.2.Fields.0.TypeName = "T::AccountId" // Some types do not have an index reference
    Lookup.Types.27.Variant.Variants.2.Fields.1.Name = "to"
    Lookup.Types.27.Variant.Variants.2.Fields.1.TypeName = "T::AccountId"
    Lookup.Types.27.Variant.Variants.2.Fields.2.Name = "amount"
    Lookup.Types.27.Variant.Variants.2.Fields.2.TypeName = "T::Balance"
    Lookup.Types.27.Variant.Variants.2.Fields.2.Type.UCompact = 6

    from & to have type T::AccountId which is a Runtime Primitive, and potentially can have different implementations depending on the runtime connected to. In most of the cases, it would be an AccountId32, but that can be changed.

    amount has a type reference to index 6 so we can navigate to that type:

    Lookup.Types.6.Type.Def.Primitive = 7 (Si0TypeDefPrimitive)

    And that tells us that is refering to Rust Primitive number 7, so according to the primitive list (found in polkadotjs/api) for type Si0TypeDefPrimitive:

    0:  readonly isBool: boolean;
    1:  readonly isChar: boolean;
    2:  readonly isStr: boolean;
    3:  readonly isU8: boolean;
    4:  readonly isU16: boolean;
    5:  readonly isU32: boolean;
    6:  readonly isU64: boolean;
    7:  readonly isU128: boolean;
    8:  readonly isU256: boolean;
    9:  readonly isI8: boolean;
    10: readonly isI16: boolean;
    11: readonly isI32: boolean;
    12: readonly isI64: boolean;
    13: readonly isI128: boolean;
    14: readonly isI256: boolean;

    The underlying type is U128

    Challenges to solve:

    New generic type registry encoder/decoderโ€‹

    The next step is to build a generic encoder/decoder that works for all discovered types based on underlaying primitive types.

    In theory, once the types are loaded, and we built generic encoders for basic primitive types, we should be able to encode & decode all types and events.

    Challenges to solve:

    • Build generic encoder/decoder for any type loaded in the registry
    • Support custom encoder/decoder for irregular struct serialization and deserialization

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Team Lead & Protocol Developer: Miguel Hervas (mikiquantum)
    • Main Protocol Developer: Cosmin Damian

    Contactโ€‹

    • Registered Address: k-f dev AG, Grafenauweg 8, 6300 ZUG SWITZERLAND
    • Registered Legal Entity: k-f dev AG

    Team's experienceโ€‹

    The k/f team has built a decentralized platform for the financial supply chain (invoices, purchase orders, warehouse receipts) comprising of a P2P network and Ethereum smart contracts over the last 2 years.

    The platform allows tokenization of any digital assets. A strong team in the DeFi movement, they are now building a Centrifuge-specific chain with Substrate, integrated their existing Go application with the Substrate chain.

    The k/f team also developed the Go Substrate RPC client supported by a Web3 Foundation grant.

    The k/f team also developed, alongside with ChainSafe, the ChainBridge supported by Web3 Foundation grant.

    The k/f team has deep knowledge in distributed/decentralized applications, libp2p, Golang, Solidity and Ethereum overall, zkSNARKs, and tokenization of assets with NFTs and has been developing with Substrate since Summer 2019.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    V1 version implemented at https://github.com/centrifuge/go-substrate-rpc-client

    V2 will be implemented as part of this grant

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Costs: 54,000 USD

    Milestone 1 - Dynamic Type Loader from metadataโ€‹

    • Estimated duration: 5 weeks (200 hours)
    • FTE: 1
    • Costs: 30,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial on how to load any metadata into its own registry of chain types.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Metadata parsing logic into internal typesList of functions, types and structs to support parsing and internally representing any target chain Metadata

    Milestone 2 - New generic type registry encoder/decoderโ€‹

    • Estimated duration: 4 weeks (160 hours)
    • FTE: 1
    • Costs: 24,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial on how to parse any substrate event and type using the new version of the library.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.In-Memory RegistryTarget chain types are loaded and indexed properly

    Further breakdown:

    • Use the registry for parsing simple and complex structs - 80h
    • Adapt current event & storage processing to new model - 60h
    • Adapt current Types Test to decode events from the latest X blocks of popular chains - 20h

    Budget Summaryโ€‹

    This table provides a cost breakdown based on the milestones and deliverables above.

    Estimates
    MSDeliverableHoursBudget
    1Dynamic Type Loader200$30,000
    Subtotal Milestone 1200$30,000
    2Generic type registry Encoder/Decoder160$24,000
    Subtotal Milestone 2160$24,000
    Totals620$54,000

    Future Plansโ€‹

    The Centrifuge Protocol is an active user of the GSRPC library and k/f is an active member maintaining it.

    - + \ No newline at end of file diff --git a/applications/centrifuge-twamm.html b/applications/centrifuge-twamm.html index 5a373ce05d7..7fa45590419 100644 --- a/applications/centrifuge-twamm.html +++ b/applications/centrifuge-twamm.html @@ -4,13 +4,13 @@ Centrifuge On-Chain Automated Treasury Management | Web3 Foundation Grants - +
    Skip to main content

    Centrifuge On-Chain Automated Treasury Management

    • Team Name: k/factory (former Centrifuge Development Team)
    • Payment Address: Ethereum(USDC) - 0x2B8A956BF807E22d858dc9AD2eFc30cccc3Ea676
    • Level: ๐Ÿ“ 3

    Project Overview ๐Ÿ“„โ€‹

    Problem Statementโ€‹

    The ongoing discussion about automated market makers (AMMs) in the Statemint roadmap is mainly focused on improving the user and custodian experience by allowing small atomic swaps natively and making Statemint a central hub for asset deposits. This addresses important pain points by enabling transaction fees to be paid in non-native tokens and facilitating interaction with the entire asset variety of the ecosystem without requiring to run custom nodes or infrastructure.

    However, we believe that one aspect has been overlooked: the slow swaps of large volumes, which can be easily front-run or sandwiched. This is particularly relevant in the context of trades proposed through governance for use cases such as

    1. Paying out treasury grants, bounties or even salaries in less volatile currencies (ie. stablecoins).
    2. Enabling parachains to build a DOT reserve which can be used to acquire a parachain lease, pay XCM fees, or increase availability cores during times of high demand (once supported).
    3. Governance deciding to invest part of the treasury into a token to diversify their treasury

    What we need is the opposite of what a traditional AMM provides: atomic swaps with immediate execution, even in relatively illiquid assets. A governance vote is unable to time the market and is highly predictable. Therefore, executing such a transaction as a market order on an AMM is problematic, as it will be guaranteed to be front-run. A better solution is to "dollar-cost-average" over a long period of time making it harder for price manipulation to affect the purchase.

    Solutionโ€‹

    At Centrifuge, we have researched distinct approaches of how to achieve hard-to-front-run slower transactions. In our opinion, the most elegant solution is TWAMM (Time Weighted Automated Market Maker. We are of the firm conviction that the implementation of this model represents the most efficacious approach for executing token swaps in the context of slower and passive procedures, such as governance.

    Time Weighted Average Market Makerโ€‹

    The TWAMM protocol represents a sophisticated advancement of the conventional constant product (Uniswap-v2 style) automated market maker (AMM) framework. It introduces a novel feature wherein users can split their orders into infinitely small fractions and execute them at each block interval. This feature addresses a significant shortcoming of traditional AMMs that encounter severe slippage issues when processing sizable orders, leaving them vulnerable to front-running tactics.

    Furthermore, the inherent risk associated with executing transactions within a single block is nullified by the TWAMM protocol. By segmenting orders into hundreds of small units spread over a prolonged time frame, the slippage rate of the embedded AMM is markedly reduced, and the cost of price manipulation is exponentially elevated. Artificially manipulating prices over multiple blocks creates an opportunity for other traders to exploit the price-inflation tactic, which ultimately undermines the manipulative effort. This innovative solution offers an elegant means of executing large orders even in relatively illiquid markets. It is particularly well-suited for slow automated processes, such as governance-controlled treasury operations, that can effectively implement a dollar-cost averaging strategy over extended periods.

    Project Detailsโ€‹

    This proposal does not aim to build an alternative DEX. Instead, TWAMM will be a feature on top of the Statemine/t DEX, whose logic was renamed to pallet-asset-conversion (Substrate PR #12984) as a result of discussions on the Polkadot forum. While pallet-asset-conversion will remain independent of our TWAMM pallets, TWAMM expects an embedded AMM interface via the pallet's Config trait, which will be based on pallet-asset-conversion, making it easy for any chain implementing pallet-asset-conversion to add TWAMM to their runtime with minimal overhead.

    To handle the accounting, distribution and claiming of sale proceeds, pallet-twamm will use a Rewards trait implemented by pallet-rewards. The latter trait and pallet is not part of the application we have already developed that under GNU General Public License v3.0.

    Please note the following draft spec is subject to change during the implementation.

    pallet_twammโ€‹

    Structsโ€‹
    /// Exposes information about an existing longterm order.
    struct Order<AccountId, AssetId, AssetBalance, BlockNumber, OrderId> {
        id: OrderId,
        owner: AccountId,
        expiration_block: BlockNumber,
        sell_rate: AssetBalance,
        asset_in: AssetId,
        asset_out: AssetId,
    }
    Storageโ€‹
    /// Tracks next available order identifier.
    type NextOrderId = StorageValue<OrderId>;

    /// Tracks longterm order details.
    type LongtermOrders =
        StorageMap<Blake2_128Concat, OrderId, Order<AccountId, AssetId, AssetBalance, BlockNumber, OrderId>>;

    /// Tracks order ids per account.
    type OrdersOf =
        StorageMap<Blake2_128Concat, AccountId, BoundedVec<OrderId, MaxOrdersPerAccount>>;

    /// Tracks orders to be executed at a specific block.
    type OrdersAt =
        StorageMap<Blake2_128Concat, BlockNumber, BoundedVec<OrderId, MaxOrdersPerBlock>>;
    Extrinsicsโ€‹
    /// Submit a new longterm order.
    ///
    /// Noop if pool (asset_in, asset_out) does not exist in the configured [`EmbeddedAmm`].
    fn submit_order(origin: Origin, asset_in: CurrencyId, asset_out: CurrencyId, sell_rate: AssetBalance, expiration_block: BlockNumber) -> DispatchResult;

    /// Cancel an existing order.
    /// Cleans all storage associated to the order and claims proceeds.
    ///
    /// Expects origin to be owner of order.
    fn cancel_order(origin: Origin, id: OrderId) -> DispatchResult;

    /// Update the `sale_rate` of an existing order.
    ///
    /// Expects origin to be owner of order.
    fn update_order(origin: Origin, id: OrderId, new_rate: AssetBalance) -> DispatchResult;

    /// Withdraw proceeds for the specified account from an order.
    ///
    /// Can be called anytime after order submission until the order
    /// terminated and all proceeds were claimed.
    fn withdraw_proceeds_for(origin: Origin, owner: AccountId, id: OrderId) -> DispatchResult;

    AMM Traitsโ€‹

    /// Basic AMM trait which exposes buy and sell functionality
    trait BasicAmm<AccountId, AssetId, AssetBalance, Balance> {
        type MaxSwapPathLength;
        
        /// Swap the exact amount of `asset1` into `asset2`.
        /// `amount_out_min` param allows you to specify the min amount of the `asset2`
        /// you're happy to receive.
        ///
        /// [`AssetConversionApi::quote_price_exact_tokens_for_tokens`] runtime call can be called
        /// for a quote.
        ///
        /// NOTE: Implemented by `pallet_conversion_rate::Pallet::<T>`
        fn swap_exact_tokens_for_tokens(
            path: BoundedVec<AssetId, Self::MaxSwapPathLength>,
            amount_in: AssetBalance,
            amount_out_min: AssetBalance,
            send_to: AccountId,
            keep_alive: bool,
        ) -> DispatchResult;

        /// Swap any amount of `asset1` to get the exact amount of `asset2`.
        /// `amount_in_max` param allows to specify the max amount of the `asset1`
        /// you're happy to provide.
        ///
        /// [`AssetConversionApi::quote_price_tokens_for_exact_tokens`] runtime call can be called
        /// for a quote.
        ///
        /// NOTE: Implemented by `pallet_conversion_rate::Pallet::<T>`
        fn swap_tokens_for_exact_tokens(
            path: BoundedVec<AssetId, Self::MaxSwapPathLength>,
            amount_out: AssetBalance,
            amount_in_max: AssetBalance,
            send_to: AccountId,
            keep_alive: bool,
        ) -> DispatchResult;
    }
    /// Basic AMM API trait which exposes current prices.
    ///
    /// NOTE: Implemented by pallet_conversion_rate::Pallet::<T>
    trait AssetConversionApi<AssetId, AssetBalance> {
        /// Provides a quote for [`Pallet::swap_tokens_for_exact_tokens`].
        fn quote_price_tokens_for_exact_tokens(asset1: AssetId, asset2: AssetId, amount: AssetBalance, include_fee: bool) -> Option<Balance>;

        /// Provides a quote for [`Pallet::swap_exact_tokens_for_tokens`].
        fn quote_price_exact_tokens_for_tokens(asset1: AssetId, asset2: AssetId, amount: AssetBalance, include_fee: bool) -> Option<Balance>;

        /// Returns the size of the liquidity pool for the given asset pair.
        fn get_reserves(asset1: AssetId, asset2: AssetId) -> Option<(Balance, Balance)>; 
    }

    Rewards (for claiming proceeds)โ€‹

    This interface is based on paper "Scalable Reward Distribution on Ethereum Blockchain" paper which presents a pull based reward distribution in O(1) per staking group, e.g. staked asset. In the context of TWAMM, stakes correspond to the sale rates and rewards to the sale proceeds. The paper assumes static stakes but the idea can be extended for dynamic ones.

    In order to keep the efficient constant proceeds accounting, we envision to map each trading pair (asset_in, asset_out) to its unique group such that the overall complexity for accounting rewards is linearly dependent on the sum of sold and bought assets, e.g. O(#assets_in + assets_out) which is much lower than O(#orders). Within each of these groups, the accounting is still in O(1) and thus independent of the number of stakers.

    Rewards Traitโ€‹
    trait Rewards<Group, Account, Currency, Balance> {
        /// Check if the group is ready to be rewarded.
        /// Most of the cases it means that the group has stake that should be
        /// rewarded.
        fn is_ready(group: &Group) -> bool;

        /// Reward the group mutating the group entity.
        fn reward_group(
            group: &mut Group,
            amount: Balance,
        ) -> Result<Balance, DispatchError>;

        /// Add stake to the account by mutating the currency and group to achieve
        /// that.
        fn deposit_stake(
            account: &mut Account,
            currency: &mut Currency,
            group: &mut Group,
            amount: Balance,
        ) -> DispatchResult;

        /// Remove stake from the account by mutating the currency and group to achieve
        /// that.
        fn withdraw_stake(
            account: &mut Account,
            currency: &mut Currency,
            group: &mut Group,
            amount: Balance,
        ) -> DispatchResult;

        /// Compute the reward for the account.
        fn compute_reward(
            account: &Account,
            currency: &Currency,
            group: &Group,
        ) -> Result<Balance, DispatchError>;

        /// Claim the reward, mutating the account to reflect this action.
        /// Once a reward is claimed, next calls will return 0 until the group will
        /// be rewarded again.
        fn claim_reward(
            account: &mut Account,
            currency: &Currency,
            group: &Group,
        ) -> Result<Balance, DispatchError>;

        /// Return the balance of an account.
        fn account_stake(account: &Account) -> Balance;

        /// Return the balance of a group.
        fn group_stake(group: &Group) -> Balance;
    }
    Reward Structsโ€‹
    struct Group<Balance, Rate> {
        total_stake: Balance,
        rpt: Rate
    }

    struct StakeAccount<Balance, IBalance> {
        stake: Balance,
        reward_tally: IBalance,
    }
    Reward Storageโ€‹
    /// Maps a staked currency to its corresponding proceeds group id and out currency.
    type Currencies = StorageMap<Blake2_128Concat, CurrencyId, (GroupId, CurrencyId)>

    /// Maps group identifiers to their [`Group`].
    type Groups = StorageMap<Blake2_128Concat, GroupId, Group>

    /// Maps the pair of a staking account and their staked currency to their current stake and reward tally.
    type StakeAccounts = StorageDoubleMap<Blake2_128Concat, AccountId, Blake2_128Concat, CurrencyId, StakeAccount>

    Ecosystem Fitโ€‹

    Where and how does your project fit into the ecosystem?โ€‹

    We believe that a comprehensive response to this question can be found in our aforementioned sections on the Problem Statement and Solution. In essence, our solution presents a seamless opt-in extension to the pallet-asset-conversion, which can be implemented across various Substrate chains, including the relaychain, to facilitate the operation of a simplified Uniswap V2 decentralized exchange. The proposed TWAMM extension effectively addresses challenges associated with executing large orders, even within relatively illiquid markets. It particularly suits gradual automated procedures, such as treasury operations under governance control, allowing for the efficient implementation of a dollar-cost averaging strategy over extended timeframes.

    Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?โ€‹

    The target audience can be categorized into two distinct groups. Firstly, it caters to Parachain developers seeking to seamlessly integrate the extension on top of pallet-asset-conversion. Secondly, it also appeals to Governance participants of any chain that implements TWAMM.

    What need(s) does your project meet?โ€‹

    By optimizing the process of diversifying the native treasury in the context of a Multi Asset one, TWAMM empowers parachains to establish a DOT reserve. This reserve can be utilized for various purposes, such as acquiring a parachain lease, covering XCM fees, or enhancing availability cores during periods of high demand (once supported). Furthermore, it facilitates the disbursement of treasury grants, bounties, or even salaries in currencies with lower volatility, such as stablecoins.

    The presence of these features serves as the driving force behind the ongoing endeavor to develop a Multi Asset Treasury. In fact, the significance of this effort was underscored by a dedicated offsite meeting held in March 2023, which involved notable participants such as Gav, Parity developers, and @wischli. During the discussions, a key insight emerged - the inclusion of TWAMM within Multi Asset Treasuries would be a highly advantageous enhancement. This addition would streamline the execution of sizable orders while ensuring a robust level of security, effectively mitigating the risks associated with front-running vulnerabilities.

    Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? If so, how is your project different?โ€‹

    The primary contributor to HydraDX, the Galactic Council, is currently developing a tailored version of TWAMM called DCA (dollar-cost averaging) within their Omnipool protocol. However, their solution is closely intertwined with Omnipool and is only compatible with it.

    Furthermore, their existing approach involves the execution of trades at regular intervals using the on_initialize hook. However, this method faces limitations when it comes to accommodating a significant volume of orders efficiently. In contrast, the TWAMM concept is founded on the principle that long-term orders do not need to be executed periodically. This is because such orders can be calculated effortlessly based on the most recent execution and are ensured to be executed before the regular orders of the embedded AMM. By adopting this approach, the need for frequent periodic executions is eliminated, allowing for streamlined and optimized processing of orders.

    Consequently, integrating their solution into Substrate parachains would involve substantial complexities and overhead. One of our USPs is the seamless and plug-and-play integration we offer for any Substrate chain that implements the straightforward BasicAmm interface. This integration can be achieved by utilizing pallet-asset-conversion or any other customized AMM.

    Additionally, Joe Petrowski, the leader of the System Parachain team, envisions our TWAMM solution being incorporated into the Asset Hub, thereby extending the functionalities of both relay chain treasuries. Otherwise, it is highly probable that pallet-asset-conversion alone would be utilized, even for slow swaps involving substantial volumes, as a means to diversify the Multi-Asset Treasury of the Relaychain, which is currently under development. Considering that significant swaps involving non-System Parachains by the Polkadot Treasury are unlikely to occur in the foreseeable future (prior to the launch of SPREE), we strongly believe that implementing a comprehensive TWAMM solution within the Asset Hub would be a substantial improvement for the ecosystem. Parties with a keen interest in a more efficient implementation may choose to execute transactions through alternative parachains, as discussed in the various DEX deliberations. If we dare to dream, we envision our proposed pallets being integrated into the frame in the future.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • TWAMM Project Lead & Rust Developer: William Freudenberger (@wischli)
    • CTO: Jeroen Offerijns (@offerijns)
    • Technical Product Manager & Rust Developer: Frederik Gartenmeister (@mustermeiszer)

    Contactโ€‹

    • Registered Address: k-f dev AG, Grafenauweg 8, 6300 ZUG SWITZERLAND
    • Registered Legal Entity: k-f dev AG

    Team's experienceโ€‹

    This grant is proposed by k/factory, a core development contributing to the Centrifuge project. A team made of experienced Substrate builders and a well established project in the Polkadot/Kusama ecosystem.

    We have already received and successfully delivered multiple grants:

    1. We developed a Go-based RPC library for interacting with Substrate nodes (GSRPC) as a Web3 Foundation grant in Q3 2019 and maintenance coverage as one of the first Polkadot treasury proposals in Q3 2020.
    2. We also built an early bridge together with ChainSafe in Q1 2019 and Q1 2020 which was funded by a Web3 Foundation grant.
    3. Last but not least, FUDGE received a Polkadot treasury grant In Q4 2022. This tool provides a simple and generic way to interact with and manipulate the database of a Substrate-based blockchain.

    Moreover, the k/f team has contributed to the Substrate and other related repositories in numerous pull requests, new issues and discussions. We have deep knowledge in distributed/decentralized applications, libp2p, Golang, Solidity and Ethereum overall, zkSNARKs, and tokenization of assets with NFTs and has been developing with Substrate since Summer 2019.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Our recent collaboration on the development of a Multi Asset Treasury (e.g. Substrate #13602, Substrate #13608) has highlighted the necessity of having a non-attackable long-term tokenswap mechanism like TWAMM (e.g. see the draft for Multi Asset Treasury). Within this context, we have engaged in discussions with the System Parachain team, particularly Joe, who has expressed support for the inclusion of our proposed TWAMM extension onto the Asset Hub. Specifically, the extension would be built upon the existing pallet-asset-conversion implementation. These conversations have provided positive reinforcement for our vision and reinforced the potential value that our solution can bring to the Asset Hub.

    We would like to bring to your attention that we recently presented a similar, albeit more extensive and expansive, proposal to the Polkadot Treasury, which unfortunately did not succeed (Motion #408). However, we firmly believe that the broader ecosystem would greatly benefit from the availability of a simple, plug-and-play TWAMM extension integrated with the pallet-asset-conversion. This would offer an alternative to exclusively routing such trades to specialized chains like HydraDX. Interested parties seeking a more efficient implementation may choose to execute transactions through HydraDX, as extensively discussed in various DEX deliberations. Additionally, Joe Petrowski's endorsement has reaffirmed our belief in this perspective, prompting us to refine our approach. Consequently, we have focused on reducing the overall scope and placing emphasis on developing the minimum required functionality. This approach aims to create a valuable addition to the Asset Hub, as well as an extension for other parachains that adopt the pallet-asset-conversion framework or have their own version of a simple constant product formula DEX.

    About TWAMM in generalโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 7.5 weeks (286 hours)
    • Full-Time Equivalent (FTE): 1.5 FTE
    • Total Costs: 75,000 USD

    Milestone 1 - TWAMM Palletโ€‹

    • Estimated duration: 7.5 weeks (286 hours)
    • FTE: 1.5
    • Costs: 75,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial on how to load any metadata into its own registry of chain types.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.pallet_twammConfig using pallet-conversion-rate as implementor of BasicAmm trait, Structs, Storage as above.
    2.pallet_twamm ExtrinsicsExtrinsics as described above.
    3.pallet_twamm runtime APIDefine trait and expose Claimable proceeds for an order as well as aggregated order data for a given asset.
    4.Benchmark pallet_twammAdd required mocks for Rewards and BasicAmm and do runtime benchmarks.
    5.TWAMM 2.0 articleOutline spec and implementation improvements over original version.

    Future Plansโ€‹

    The Centrifuge Protocol aims to be an active user of the TWAMM protocol. If we dare to dream, we envision our proposed pallets being integrated into frame in the future.

    - + \ No newline at end of file diff --git a/applications/ces_data_store.html b/applications/ces_data_store.html index dccf01a381c..81cf1c51396 100644 --- a/applications/ces_data_store.html +++ b/applications/ces_data_store.html @@ -4,13 +4,13 @@ Data Store Pallet | Web3 Foundation Grants - +
    Skip to main content

    Data Store Pallet

    • Team Name: CESS LAB
    • Payment Address: 0x41fC582784745Ec6B4860F47808b988a473fcEFc(USDT)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Backgroundโ€‹

    As a versatile blockchain framework, Substrate has a variety of modules (a.k.a. pallets) for developers to reuse. From resource management such as accounts and assets to utilities such as random number generators and schedulers, these existing pallets could meet the need of most developers' application scenarios. However, there is still room for improvement.

    Recently we have a requirement to implement a data storage service on Substrate, and after checking through all existing pallets, we did not find one that meets our need. So we would like to develop a custom pallet to fulfill this purpose.

    We are not talking about something very niche here. On the contrary, it is a common scenario that an application would continuously consume and generate various data, whether it is system, user, or just temporary levels, during operations. Many dApps have a large number of scenarios that require off-chain data storage services, such as NFTs. The quality of the storage service chosen will directly affect the performance and reliability of the entire application.

    So we hope to offer Substrate/Polkadot community with pallets (and toolchains) dedicated for storage services that are compatible with current Substrate APIs. So developers only need to add tiny amount of code change to leverage CESS stable and secure data storage. We believe this will further enhance the development experiences when adopting Substrate and enrich the Polkadot ecosystem.

    Current Solutionโ€‹

    There is only one pallet related to data storage in the existing Substrate FRAME, aka, Transaction Storage Pallet. It supports running an IPFS node side-by-side with Substrate and allowing data to be retrieved by IPFS after putting it in Substrate storage. However, its application scope is greatly limited due to its inherent characteristics and several defects in the following aspects.

    1. Data need to be uploaded to the blockchain network. Although this data is not actually stored on the chain, they still incur additional gas costs and congestion, which is not suitable for large file storage.

    2. All validator nodes need to establish IPFS service for themselves, which subject to many restrictions.

    3. The development is difficult since the Substrate-based code needs to be greatly modified.

    4. This only supports file upload on the Substrate side. Viewers need to retrieve it via IPFS clients.

    Project Detailsโ€‹

    We design and implement a data storage service based on Substrate. On one hand, there is no need for a validator node to start additional service, and no major modifications to substrate-based code as well. Therefore, developers can easily integrate our storage service, whether it is a newly-built chain or an existing chain. On the other hand, by customizing the storage REST component, users could upload and download data conveniently without installing additional client programs.

    High level designโ€‹

    Our proposal architecture is shown in the figure below, which consists of the Data Store Pallet and custom-built Storage Sidecar (inspired by Substrate API Sidecar).

    Figure 1: Proposal architecture

    Figure 1: Proposal architecture

    • Data Store Pallet: Realize the recording and management of stored data. This pallet implements functions related to meta-data, e.g. root data management, data owner management, and data classification regarding the stored data.

    • Custom-built Storage Sidecar: Provide RESTful service to interact with Data Store Pallet. The difference from Substrate API Sidecar is that, in addition to the basic functions of interacting with the substrate-based chain, Storage Sidecar encapsulates storage-related API, including data storage and data retrieval. The data transmitted by users will eventually be stored in CESS Storage System through this interface.

    Typical exampleโ€‹

    Data storage and retrieval are the two core features for a data storage service. They are illustrated in details below.

    Figure 2: Typical example process

    Figure 2: Typical example process

    • Data Storage
    1. A user calls the data storage API of the Custom-built Storage Sidecar to upload the data file;
    2. Forward the data to CESS by calling the encapsulated CESS API;
    3. Once it is confirmed that the data has been written, Custom-built Storage Sidecar will call Extrinsic to record the relevant information of the data file on-chain;
    4. CESS Storage System maintains the integrity and privacy of data throughout its life cycle.
    • Data Retrieval
    1. A user calls the storage API of the Custom-built Storage Sidecar to retrieve the target data;
    2. Custom-built Storage Sidecar to query on-chain data routing information;
    3. Call the CESS data retrieval API with the routing info;
    4. Retrieve and return the target data from CESS Storage System;
    5. Return the target data to Custom-built Storage Sidecar;
    6. Custom-built Storage Sidecar updates on-chain information, if necessary;
    7. Return the target data to the user.

    API specifications of the core functionalityโ€‹

    • Data Store Pallet: List of the publicly exposed methods
    No. 1
    Method Namestore
    Method TypeDispatchable Function
    Parameter 1 (Type)filename:Vec\<u8>
    Parameter 2 (Type)fileid:Vec\<u8>
    Parameter 3 (Type)filesize:Vec\<u8>
    Parameter 4 (Type)keywords:Vec\<u8>
    ReturnsDispatchResult
    DescriptionUpload meta-info of stored file on chain.
    No. 2
    Method Nameretrieve
    Method TypeDispatchable Function
    Parameter 1 (Type)fileid:Vec\<u8>
    ReturnsDispatchResult
    DescriptionCheck if the caller has permission to get the specified file.
    No. 3
    Method Namereplace
    Method TypeDispatchable Function
    Parameter 1 (Type)old_fileid:Vec\<u8>
    Parameter 2 (Type)filename:Vec\<u8>
    Parameter 3 (Type)fileid:Vec\<u8>
    Parameter 4 (Type)filesize:Vec\<u8>
    Parameter 5 (Type)keywords:Vec\<u8>
    ReturnsDispatchResult
    DescriptionUpload and replace old meta-info with new's of stored file on chain.
    No. 4
    Method Namedelete
    Method TypeDispatchable Function
    Parameter 1 (Type)del_fileid:Vec\<u8>
    ReturnsDispatchResult
    DescriptionDelete the meta-info of the specified file, and the caller must be the owner of the file.
    No. 5
    Method Nameedit
    Method TypeDispatchable Function
    Parameter 1 (Type)fileid:Vec\<u8>
    Parameter 2 (Type)new_filename:Vec\<u8>
    Parameter 3 (Type)new_keywords:Vec\<u8>
    ReturnsDispatchResult
    DescriptionSupport to modify meta-info of the owner's specified file.
    No. 6
    Method Namequery
    Method TypeCustom RPC
    Parameter 1 (Type)keywords:Vec\<u8>
    Returnsqueried meta-info
    DescriptionSupport to query meta-info of the owner's specified file with some keywords.
    • Custom-built Storage Sidecar: New API interface overview
    TypeAPI PathDescription
    POST/api/storeStore files to the CESS storage system and will call store extrinsic.
    GET/api/retrieveCheck if the caller has permission with retrieve extrinsic and get the specified file.
    POST/api/replaceReplace stored file with new one and store to the CESS storage system, then call replace extrinsic.
    POST/api/deleteCall delete extrinsic and delete the file in CESS storage system.
    POST/api/editSupport to modify meta-info of the owner's specified file.
    GET/api/querySupport to query meta-info of the owner's specified file with some keywords.
    GET/api/listList all the files info of caller.
    ......

    Ecosystem Fitโ€‹

    Help us locate your project in the Polkadot/Substrate/Kusama landscape and what problems it tries to solve by answering each of these questions:

    • Where and how does your project fit into the ecosystem?

    Our project offers storage services to all Substrate-based networks in a convenient way which currently does not have a good enough solution.

    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

    The substrate developers who want to get storage services.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Teh Sunn Liu
    • Yeou Sunn Liu
    • Ted Zhang

    Contactโ€‹

    • Registered Address: 22 St Leonard's Ave, Lostock, Bolton BL6 4JE, England
    • Registered Legal Entity: Paul David Humphreys

    Team's experienceโ€‹

    We have a team of professionals in getting this done. The backgrounds of team members include but are not limited to cloud computing, consensus algorithms and distributed storage. Most of them have been working in their respective fields for many years and have rich industry experience and solutions. The team members are distributed in the UK, the US, China and India, ranging from research scholars and cryptography experts to senior technical managers and Substrate development engineers.

    So far, one of the team's project CESS is gradually integrating into the Polkadot ecosystem. Won the 1st Place in Polkadot Hackthon APAC Edition in 2021, passed all deliveries of a applied grant, and officially joined the Substrate Builder Program on February 14, 2022.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    This section should break the development roadmap down into milestones and deliverables. To assist you in defining it, we have created a document with examples for some grant categories here. Since these will be part of the agreement, it helps to describe the functionality we should expect in as much detail as possible, plus how we can verify and test that functionality. Whenever milestones are delivered, we refer to this document to ensure that everything has been delivered as expected.

    Below we provide an example roadmap. In the descriptions, it should be clear how your project is related to Substrate, Kusama or Polkadot. We recommend that teams structure their roadmap as 1 milestone โ‰ˆ 1 month.

    For each milestone,

    • make sure to include a specification of your software. Treat it as a contract; the level of detail must be enough to later verify that the software meets the specification.
    • include the amount of funding requested per milestone.
    • include documentation (tutorials, API specifications, architecture diagrams, whatever is appropriate) in each milestone. This ensures that the code can be widely used by the community.
    • provide a test suite, comprising unit and integration tests, along with a guide on how to set up and run them.
    • commit to providing Dockerfiles for the delivery of your project.
    • indicate milestone duration as well as number of full-time employees working on each milestone.
    • Deliverables 0a-0d are mandatory for all milestones, and deliverable 0e at least for the last one. If you do not intend to deliver one of these, please state a reason in its specification (e.g. Milestone X is research oriented and as such there is no code to test).

    โšก If any of your deliverables is based on somebody else's work, make sure you work and publish under the terms of the license of the respective project and that you highlight this fact in your milestone documentation and in the source code if applicable! Teams that submit others' work without attributing it will be immediately terminated.

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 2
    • Total Costs: 9,000 USD

    Milestone 1 Implement Data Store Palletโ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: 3,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1a.Substrate module: data_storeWe will create a Substrate module that will implement meta-info management of stored data, including functions such as store, retrieve, replace, delete, edit, query.
    1b.BenchmarkingThe module will be on par with other pallets in FRAME, fully equipped with benchmarking, weights, tests.

    Milestone 2 Implement Custom-built Storage Sidecar Featuring Interaction with Data Store Palletโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 3,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.CESS StorageWe will integrate CESS storage module in Custom-built Storage Sidecar to support the data storage service.
    2.Data Store APIImplement the data store API to support interaction with the data store pallet based on the stable version of the Substrate API Sidecar, which contains at least 6 new interfaces required for data storage.
    3.Endpoint DocsWe will write Endpoint Docs explaining the usage of the all implemented RESTful API.

    Milestone 3 Complete Custom-built Storage Sidecarโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 3,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains our project's features, implementation, and user guidelines.)
    1.Data Integrity VerificationWe will provide integrity verification for stored data to improve the quality of storage services.
    2.Data Store APIWe will add data storage functionality to the data store API, which adapts to existing interactions with Data Store Pallet.
    3.Endpoint DocsWe will update the Endpoint Docs to fit the upgraded Custom-built Storage Sidecar, which adds data storage features.

    Future Plansโ€‹

    In the short term, we will promote our project to get more people to use and test it. Next, we will continue to maintain component versions to accommodate Substrate updates, and as much as possible to provide more reliable storage services.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We have heard from Parity Asia.

    What work has been done already? We have already implemented a design prototype.

    Have you ever applied for other grants? We had applied a grant that had passed all the milestone deliveries on January 25, 2022.

    - + \ No newline at end of file diff --git a/applications/chainjs.html b/applications/chainjs.html index b269eb6d3ca..9b82ebfb6e4 100644 --- a/applications/chainjs.html +++ b/applications/chainjs.html @@ -4,14 +4,14 @@ Polkadot & Kusama ChainJS plugin | Web3 Foundation Grants - +
    Skip to main content

    Polkadot & Kusama ChainJS plugin

    • Team Name: API Market, Inc. dba AIKON
    • Payment Address: Ethereum Address: 0x7a6fdc8a113966d1236aB0FaB6dC5D3e5c05db88
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    AIKON is dedicated to driving mass-adoption of blockchain. We would like to bring our flagship ORE ID service to Polkadot, Kusama and to a variety of parachains. However, in order to build our API service on Polkadot & Kusama, we need an open source library called ChainJS. ChainJS is an abstraction layer that allows web applications to interact directly with Polkadot using javascript. This standard provides a handful of easy methods for common interactions on-chain, like creating wallets, transferring tokens and signing transactions.

    Once we have this ChainJS plugin, we can work with companies to launch tokens or applications on Polkadot with ORE ID. For example, with Republicโ€™s Note token, they use ORE ID to create multi-sig wallets for their investors and the investors use their ORE ID login to sign transactions, but ChainJS actually forms the transactions and sends them to the blockchain.

    Our goal is to establish ChainJS as the de facto standard for javascript developers that want to build on Polkadot & Kusama.

    • Open Source standard for Javascript
    • Easy to use abstraction layer for web developers - unlike Polkadot.js, ChainJS simplifies the interface layer making it easier for new developers
    • Makes it easy for developers to build on Polkadot, Kusama and on parachains, that can roll out their own fork of the ChainJS library
    • Allows AIKON to deploy ORE ID for companies on Polkadot & Kusama

    Once we have ChainJS, ORE ID provides four major benefits to businesses:

    • Consumer friendly user experience - including social and email login
    • API for mass migration of large existing databases of users
    • Fiat invoicing for Polkadot & Kusama transactions

    Our open source ChainJS Repo: https://github.com/TeamAikon/chain-js

    To learn more about AIKON and read our developer docs visit: https://aikon.com

    Project Detailsโ€‹

    Ecosystem Fitโ€‹

    Although there are javascript tools for Polkadot like https://polkadot.js.org/docs/, this is the first effort to create a ChianJS plugin for Polkadot. The ChainJS standard is particularly suited for helping applications form Ethereum migrate to Polkadot, and we also hope it provides a template for parachains to do the same. ChainJS is also critical for the ORE ID product to support Polkadot, allowing us to help drive business adoption of Polkadot and parachains.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Marc Blinder, CEO
    • Tray Lewin, CTO
    • Randy Torres
    • Basar Celebci
    • Mamoon Ahmed
    • Babar Bilal
    • Daniel Lin
    • Bill Rusitzky

    Contactโ€‹

    • Registered Address: 18 Bartol Street #986, San Francisco, CA 94133
    • Registered Legal Entity: API Market, Inc.

    Team's experienceโ€‹

    The AIKON team has been building blockchain technology since 2017, and the founders have decades of combined enterprise software experience before that. AIKON are major contributors to the Open Rights Exchange blockchain: https://github.com/Open-Rights-Exchange and they also launched the ORE ID product for onboarding users to a variety of public blockchains: https://github.com/TeamAikon/ore-id-docs

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    ChainJS Polkadot & Kusama Plugin Devlierables ChainJS is a low-level Javascript helper library that helps you write code that can work with multiple blockchains. ChainJS uses a plug-in model and a unified interface to do common blockchain functions like constructing, signing, and sending blockchain transactions. Unlike Polkadot.js, ChainJS simplifies the interface layer making it easier for new developers who don't need to understand how Polkadot or Kusama work in order to commit basic actions to chain.

    Publish open source Polkadot & Kusama plugins for the ChainJS standard, including the following functions:

    • Create wallet
    • Create multisig wallet
    • Construct transaction
    • Transfer tokens

    We will also deliver

    • Developer documentation

    Estimated to be ~14 months total

    Overviewโ€‹

    • Total Estimated Duration: 22 months
    • Full-time equivalent (FTE): 2 FTE
    • Total Costs: $15,000 in DAI

    Milestone 1 Example โ€” Implement ChainJS Library for Polkadot & Kusamaโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: $15,000 in DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how engineers use the ChainJS library.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.Polkadot plugin for ChainJS standardCreate wallet, Create multisig wallet, Construct transaction, Transfer tokens

    Future Plansโ€‹

    Once we have ChainJS, our intention is to deploy our flagship ORE ID product to Polkadot & Kusama. ORE ID is a service that helps enterprises migrate their user base to blockchains at scale. ORE ID provides four major benefits to businesses on Polkadot:

    • Consumer friendly user experience - including social and email login
    • API for mass migration of large existing databases of users
    • API and javascript libraries that make it easy for developers to build on Polkadot & Kusama
    • Fiat invoicing for Polkadot & Kusama transactions
    - + \ No newline at end of file diff --git a/applications/chainviz.html b/applications/chainviz.html index 169eef14f0c..6691afc3797 100644 --- a/applications/chainviz.html +++ b/applications/chainviz.html @@ -4,13 +4,13 @@ Chainviz v1 | Web3 Foundation Grants - +
    Skip to main content

    Chainviz v1

    • Team Name: Helikon Labs
    • Payment Address: bc1qxjy7sw0ffvpq86t6hj3mmqhnfz2hxt6pk7zdz0 (BTC)
    • Level: ๐Ÿค 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Chainviz web application alpha version, available at alpha.chainviz.app, is an open-source real-time 3D visualization of the Kusama relay chain block production process.


    Chainviz alpha version

    Application in its current alpha version provides the following features:

    • Real-time 3D visualization of:
      • Active validators, including paravalidation indication
      • Block production by validators
      • Block finalization
    • Navigation of the 3D scene through zooming, panning and rotation
    • Network status display
    • Active validator list and search over identity/address
    • Validator details panel upon click on a validator in the 3D model, or the validator list

    This application is to fund the building of the first major version of Chainviz, with the following features/visualizations:

    • Complete rebuild of the the existing functionality with improved UI/UX and WebGL models and animations
    • Additional support for Polkadot
    • New visualizations
      • Parachains
        • Assigned paravalidators
        • XCM messages between parachains, or from parachains to relay chains
      • Block content
        • Author
        • Extrinsics
        • Events

    With these additional features, Chainviz is going to become a complete real-time visualization of the Polkadot and Kusama relay chains and their parachains.

    Project Detailsโ€‹

    Organizationโ€‹

    Chainviz v1 upgrade is a collaboration between Helikon Labs and Klad, carried out under the management of Helikon Labs.

    System Architectureโ€‹

    Current Systemโ€‹

    Chainviz alpha version currently utilizes SubVT backend services and Polkadot JS API as follows.

    • SubVT active validator list service
      • List of all active validators
      • For each validator, a summary including:
        • Identity
        • Validator preferences
        • Self stake
        • Nomination count and total amount,
        • 1KV data if exists
        • and more
    • SubVT network status service
      • Era index
      • Era reward points
      • Total, minimum, maximum and average stake amounts
    • Polkadot JS API
      • Finalized block header subscription
        • Utilized to mark finalized blocks
      • Best block header subscription
        • Utilized to display the block production animation
        • Identify uncle blocks and visualize them

    Current Chainviz alpha version system architecture can be illustrated as follows.


    Figure 1 Chainviz alpha system architecture

    Proposed Upgradeโ€‹

    Proposed upgrade to the first major version requires the following additional data:

    • Block content
      • Extrinsic list
      • Event list
    • Parachains
    • XCM messages

    Proposed system architecture for the upgrade can be illustrated as follows.


    Figure 2 Chainviz v1 proposed system architecture

    Upgraded system utilizes:

    • Polkadot JS API to access block content and parachains, and subscriptions for new and finalized block headers
    • SubVT Polkadot and Kusama Active Validator List Services for the list and summary data for active validators
    • SubVT Polkadot and Kusama Network Status Services for live network data
    • Polkaholic XCM API for the live display of XCM messages and their summaries

    UI/UX Upgradesโ€‹

    We're going to implement a number of UI/UX upgrades, as follows:

    • Improvement of the overall aesthetics and visual coherence of the application
    • A better depiction of the block production process that is easier to comprehend for a wider range of users from the technically informed to the newly-introduced
    • Display of block contents (i.e. hash, number, author, extrinsics and events) on click
    • Responsive design for a range of screen sizes
    • A better utilization of the 3D space to allow for parachain visualization and preparation for future upgrades
    • Display of parachains, their assigned validators and the cross-chain messaging process

    UI/UX upgrade implementation consists of 3 core components:

    • Visual guidelines
    • Application UI/UX upgrades
    • WebGL graphics development and motion design upgrades

    Development of the visual guidelines aims to bring visual coherency to Chainviz. From a functional perspective, this component serves as a core visual guide and foundation for all future UI/UX components and 3D graphics development.

    UI/UX upgrades aim to elevate the project from a draft look to an efficient, performant, user-appealing, scalable web application. Visually, it will be based on the current project aesthetics while ensuring its responsiveness and accessibility. Through this work, we aim to increase usability and ensure application scalability in terms of functionality growth.

    Third component of the visual upgrades, the development of the upgraded WebGL graphics and motion, faces a set of challenges that we aim to solve, including effective visualization of the block production and cross-chain messaging process. When we use the term effective visualization, we primarily mean one that:

    • Can show the depicted processes in a simple yet systematic manner
    • Can be engaging and valuable for users with different levels of expertise

    Ecosystem Fitโ€‹

    There is currently no direct match in the Dotsama ecosystem of the features offered by Chainviz. Chainviz Alpha got shared on Twitter by Gavin Wood upon initial release, and received a lot of praise from various Dotsama ecosystem members.

    There are currently two other projects that visualize certain aspects of the Dotsama blockspace:

    1. Kusamaverse by Odyssey, which is closer to a metaverse space for Kusama, focuses more on the interaction of the actors in the ecosystem.
    2. XCM Dashboard by the Subscan team, which is a fairly static visualization of the active cross-chain messaging channels between parachains.

    Chainviz is unique in that it focuses on a very clear real-time visualization of the internals of the Dotsama machine. As we're going to explain in the Future Plans section, it also has the potential to have educational, entertainment and functional value through future development.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Team Lead & Full-Stack Developer: Kutsal Kaan Bilgin
    • Product Manager: Egor Zmaznev
    • Project Manager: Daria Kravchenko
    • Backend Developer: Ivaylo Hubanov
    • UI/UX Designer: Ksenia Leonteva
    • 3D Designer: Lena Sivakova

    Contactโ€‹

    • Registered Address: Omer Avni Mah. Balcik Sok. 4/4 34427 Beyoglu Istanbul Turkey
    • Registered Legal Entity: Helikon Teknoloji ve Medya Tic. Ltd. Sti.

    Team's experienceโ€‹

    Helikon Labsโ€‹

    A crypto-native software development company based in Istanbul. Founded by Kutsal Kaan Bilgin, Helikon Labs got introduced into the Dotsama ecosystem in January 2021. Currently focused on validator tooling, infrastructure support and creative coding projects for the Dotsama ecosystem.

    Kutsal Kaan Bilginโ€‹

    Founder of Helikon Labs. Software developer with a BS in Computer Science and 20 years of experience in software development and leadership in diverse fields such as fintech, defense industry, interactive art installations and GIS. Focusing on user-friendly, aesthetically pleasing and creative blockchain application development since late 2019. Dotsama native since early 2021. Developer of SubVT (please see above), Chainviz Alpha and ChainSynth Alpha. Presenter of a Substrate Seminar episode on blockchain UI application development.

    Egor Zmaznevโ€‹

    Egor comes from a business analytics background with an emphasis on DeFi and web3 business models. He is proficient in R and Python in applications to ML modelling, focusing primarily on textual analytics in business applications with research emphasis on DeFi and DAOs. One of the co-founders of Klad Syndicate, where he managed a set of crypto projects varying from smart contract analytics to NFT marketplaces.

    Daria Kravchenkoโ€‹

    Daria focuses on internal team management. Coming from a conflictological education background, she can effectively set up and organise all of the internal communications and carry task management. Together with the designers, Daria worked on and finalized over 35 design projects only in the past year as a Klad Syndicate co-founder. Previously, managed design processes for the SubVT implementation.

    Ivaylo Hubanovโ€‹

    Ivaylo Hubanov is coming from a strong Information Security engineering background with more than 15 years of experience in the field. He spent the last 5 years growing his passion for development and writing crypto and forex trading bots, and took part in a project for developing a 3D Fair in Unity. Also a member of Polkadot and Kusama Thousand Validators programs, he developed a complex validator orchestrator system for running validators on GCP instances while maintaining lower costs by using spot instances with low specs while inactive and high specs while active. The orchestrator required collecting live information from the chain and Ivaylo became the first developer to utilize and take part in the improvement of the SubVT websocket services. Worked together with Kutsal on improving the SubVT backend and the Telegram bots.

    Ksenia Leontevaโ€‹

    Ksenia is a co-founder and leading UI/UX designer at Klad. She has 15 years of experience in web and UI/UX design and worked on over five crypto and DeFi-related projects over the past year. Ksenia has developed UI/UX design for the SubVT application: from the user-flow map and the wireframes to the whole app UI design. Focuses on clean user-friendly solutions, and ensures that the development team always have convenient files to work with. In 2022, won over ten web-design awards.

    Lena Sivakovaโ€‹

    Lena is a co-founder and 3D & motion designer at Klad. She has over seven years of experience and has participated in various crypto projects providing supporting 3D materials, including interactive validator 3D models for SubVT. Lena brings volume and movement to brands, allowing for spectacular immersive digital experiences.

    Team Code Repositoriesโ€‹

    Team LinkedIn Profilesโ€‹

    Team Behance Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Alpha version of Chainviz has been live since February 2022 as detailed under the Project Details section. There hasn't been any development for the first major version proposed by this document.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 8 months
    • Full-Time Equivalent (FTE): 0.2
    • Total Costs: 22,000 USD

    Milestone 1 โ€” Complete Web Application Implementationโ€‹

    • Estimated duration: 8 months
    • FTE: 0.2
    • Costs: 22,000 USD
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationMilestone delivery report and inline code documentation. Separate markdown document that explains how to run an instance of the application.
    0c.Testing GuideMarkdown document in the GitHub repository that documents the complete list of test cases for application Typescript code and how to run them.
    0d.DockerNecessary Docker/compose files necessary to run the application.
    0e.Video ArticleA YouTube video accompanied by an article on Helikon website or another blog site that documents the milestone development/design process and the outcome.
    1a.Web Application Source CodeComplete source code of the application available at the Chainviz GitHub repository. Documentation delivered as part of 0b is going to have the simple instructions to run the software.
    1b.Web Application Live Deployment with New FeaturesWeb application live at chainviz.app, with additional real-time visualizations as documented above: complete block details on hover or click, parachains, parachain validators and their assignments, cross-chain messages.

    Future Plansโ€‹

    • Add educational components and user guides.
      • Replayable voice recordings attached to the various components and processes for the users who would like to learn more about the internals of the Dotsama machine.
      • Text and visual augmentation.
      • Animated explainers and hints that give better understanding of the technology and processes.
    • Validator spaces and staking through Chainviz. Support for validators to claim and update their spaces.
    • iOS and Android phone, table and watch applications.
    • Exploration of VR and AR possibilities.
    • Creating a wiki for validator operators, supporting pull requests.
    • Adding indexes to provide insights for nominators (e.g. performance, telemetry data, reliability).
    • Creating validator timeseries visualizations to provide insights on performance, reliability and stability.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    We have successfully delivered a W3F Level-1 Open Grant. Please view the application document for the details of our first introduction to the Grants Program.

    Awards Received

    Some of the recent design awards that the design team have received:

    1. CSS Design awards (link)
    2. Awwwards (link)
    3. Mindsparkle Mag (link)
    - + \ No newline at end of file diff --git a/applications/cheersland.html b/applications/cheersland.html index a1568b4a0d1..9b3f84b5e5d 100644 --- a/applications/cheersland.html +++ b/applications/cheersland.html @@ -4,7 +4,7 @@ CheersLand-Multi-game Platform for Polkadot & Kusama | Web3 Foundation Grants - + @@ -42,7 +42,7 @@ addition

    The official version of the whitepaper: https://github.com/CheersLand/cheersland-whitepaper

    The pitch deck of CheersLand: https://medium.com/cheersland/cheersland-redefine-a-cheerful-world-with-gamefi-448e1665ff76

    - + \ No newline at end of file diff --git a/applications/choko_wallet.html b/applications/choko_wallet.html index 2d326155362..bc84882b53b 100644 --- a/applications/choko_wallet.html +++ b/applications/choko_wallet.html @@ -4,7 +4,7 @@ Choko Wallet | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ jYkTaT.png jYkLRJ.png

    Ecosystem Fitโ€‹

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    None

    Team's experienceโ€‹

    We have applied and deliverd all milestones of the SkyeKiwi Protocol and built the SkyeKiwi Network based on SkyeKiwi Protocol as a privacy layer for Web3 featuring interoprabl, multi-shard, multi-vm private smart contract execution as a part of the Substrate Builder Program. We have a track record of engineering complicated system with high quality. The Choko Wallet is a critical component for the adoption of the SkyeKiwi Network (and the SkyeKiwi Protocol), from the encryption/decryption functionalities of the network. More discussed in future plan section.

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    The project is mostly front-end work, except for the mechism for cross-browser tab communication from the Dapp and wallet. Therefore, so far, we have only created a simple sandbox to demostrate the viability of such communication here.

    Moreover, the Near Wallet (an Apache2.0 or MIT licensed open source software) seem to be a good base of development for Choko Wallet. We will fork the repo and do a complete overhaul to better fit the needs of the Polkadot ecosystem.

    Update on August 2 on Near Wallet: after a month long dig into the Near Wallet codebase, we recognize the following issues that prevent us to build upon the Near Wallet but instead, start a new codebase of the Web App from scratch:

    1. Chaotic state management: the Near Wallet has very tangled state management for requests and responese. As it will be more efficient to build the underlying redux dataflow from scratch.
    2. Different account system and different cryptographics: the NEAR blockchain uses Ed25519 for pretty much everything, while on Substrate, Sr25519 is used in default but there can be all kinds of cryptographic used in the Polkadot ecosystem. (i.e. Moonbeam). Moreover, NEAR is based on a human-readable fake AccountId that links to several cryptographic "keys" for accounts. These are factors that contribute to point 1 of why the Near wallet codebase has such a complicated Redux dataflow.
    3. Loose Encoding on URL: as we stated above on "Requst Handling", we will build a byte percise(and efficient) version of the encoding to be sent between Dapp and Wallet as Substrate extrinsics can be very long on cross-chain communicattions.
    4. Decentralziation: lots of functionalities of Near wallet relies on a closed-source centralied helper service. We don't want that.
    5. Extensibility: the network RPC is hardcoded into NEAR. Choko Wallets need to support a wide range of networks, while we will allow networks to customize their own request handling mechnisim, while have a set of functionalities by default. Such design will require weeks to peel off wallet logics away from the near codebase.
    6. Security: the near wallet does not require a user input password to safeguard the seed phrase. This can be considered "kind of" secure because of the AccountId system of Near(i.e. Keys are ephermeral, while a human readable AccountId like "alex.near" is presistent). However, this is not applicable to the Polkadot ecosystem. To change so, we would also have to completely peel away the private key management logic from the near codebase.
    7. Frontend Framework: we decided to go with Next+Tailwind+Redux+TypeScript combo with good lint/test/build pipeline for better maintainablity. And avoid the messy codebase as the Near Wallet.

    LINK @choko-wallet/core for all primitives to the wallet like cross-chain DAppDescriptor, cross-chain UserAccount that can be locked and typed with different cryptographic types etc.

    LINK @choko-wallet/known-networks for a list of known-networks from @polkadot/apps;

    LINK @choko-wallet/request-handler for a extendable request handling that are byte precise and efficient on payload encoding;

    LINK @choko-wallet/sdk for Dapps to integrate for account management in browsers and handle both local and remote requests;

    @choko-wallet/sdk-react (To be made) to inject the SDK to React components for lifecycle management etc.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Mostly described above in the Overview section.

    Overviewโ€‹

    Milestone 1โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a live demo. Documentation to SDK.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerA Dockerfile won't be much useful for a static web app. Therefore, we are not going to provide one for this milestone.
    0e.ArticleWe will publish an article that explains the concept of the Choko Wallet. More general-public-oriented version of what described in this application.
    1.Reactjs WebAppimport/create account (create 12 words seed phrase, encrypt with user-input password and store in browser localStorage, encrypted with cryptographic primitives from @skyekiwi/crypto, make sure the user has writen down the seed by testing a randomly selected word i.e. ask user to input and validate word #7; import a seed phrase and encrypt with user-input password)

    sign message/transaction

    a almost blank dashboard but allow switching between networks (support all networks on @choko-wallet/known-networks) and connect to a customized network provider

    setup-on-another-device(instruction and QR code generator), import from clear seed(a route to receive a clear encoded seed pharse via URL and import into wallet), create wallet page(option to send a URL with a clear seed phrase via email & warning banner when a wallet that had exposed a clear seed phrase has more than $50 on the selected network)
    2.A Sample DAppA sample DApp created with @choko-wallet/sdk to test with common functionalities.
    3.SDKFor @choko-wallet/known-networks will include a few popular Polkadot chains, @choko-wallet/request-handler will implements handler for "request for user public identity", "request to sign transaction", "request to sign message", "request to decrypt/encrypt message" (Note: encryption/decryption won't be a solution yet, see discussion above for details).

    Future Plansโ€‹

    - + \ No newline at end of file diff --git a/applications/citadel.html b/applications/citadel.html index 4e8afdfb49a..02d67d34b70 100644 --- a/applications/citadel.html +++ b/applications/citadel.html @@ -4,7 +4,7 @@ Citadel.one integration of Polkadot | Web3 Foundation Grants - + @@ -15,7 +15,7 @@

    Below you can find the link to our API documentation. Not only we plan to integrate Polkadot into Citadel, but also upon the integration completion, we will share the open API for the development associated with DOT coins, including transfers, staking, transaction types, etc.

    https://work.3ahtim54r.ru/api/doc/

    Web:

    Mobile:

    PoC/MVP or other relevant prior work or research on the topic

    The working product is accessible via the link - citadel.one

    Ecosystem Fitโ€‹

    Are there any other projects similar to yours? If so, how is your project different?

    The most similar to what we are building at Citadel is Lunie. However, some features and platforms' details are different - it provides DOT holders with an opportunity to choose what's best for them.

    To begin with, as multi-asset platforms, Citadel and Lunie support different networks. Thus, depending on the user's portfolio,one of the platforms will be more preferable, than the other. For example, if a user holds DOT and XTZ, Citadel will become a good all-in-one solution; in the same manner, if a user possesses DOT and AKT, it may be easier for him to use Lunie. In addition, Citadel supports Bitcoin, Ethereum, and Tether for the comfort of our users.

    Furthermore, we integrated the fiat gateway and instant cryptocurrency exchange so that users can effortlessly buy tokens right in the app. Also, Citadel users have access to their transaction history details and a full analytical dashboard that allows them to track all the assets across multiple networks with a proper reward calculation. Lunie and Citadel have absolutely different interfaces, so users are free to choose the most suitable solution based on their specific needs. Below, you can find a quick comparison table.

    CitadelLunie
    Networks available for stakingCosmos, Polkadot (coming soon), Tezos, IOST, ICON, OrbsCosmos, Akash Network, e-Money, Polkadot, Kusama, KAVA, Terra
    Other supported networksBitcoin, Ethereum, Tether-
    StakingYesYes
    Proposals explorerYesYes
    Fiat gatewayYesNo
    Built-in exchangeYesNo
    Transaction historyYesComing soon
    Overall analytical dashboardYesNo
    Price feed informationYesNo
    Mobile appComing soonYes

    Team๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Dev team members

    Other team members

    Team Websiteโ€‹

    https://citadel.one/

    Citadel.One PTE LTD

    068914, SBF CENTER, SINGAPORE, 160 ROBINSON ROAD

    Team's experienceโ€‹

    Citadel.One team is extensive not only by quantity but also by quality. Our team consists of specialists that are apt to cover all the tech needs โ€“ from DevOps and node administration to backend & frontend handling. What's more, with the significant business, and finance knowledge of Alex Falko, vast project & product experience of Anton Pavlutsky, and the all-encompassing hard skills of Gregory Shabalov, the Citadel team is competent in supporting sustainable growth and development.

    As for the team's interesting cases, we shall begin with our co-founders' experience. Feel free to check out interviews with Anton and with Gregory, where they cover all of their relevant career experience. Furthermore, our dev team did hard yet interesting work with standardizing the tech stuff for all integrated networks: they coped to parse Tezos, ICON, IOST, Ethereum, Cosmos and bring them to the unified database storage standard so that the analytics can be provided in the quickest and the most convenient way.

    Our Lead Backend Developer, Pavel, was apt to unload transactions in the shortest possible time by restructuring the parsing and data saving process using the streaming method. He also found a way to optimize the logic of wallet generation for different networks in order to reduce the number of libraries used and get a much faster website experience for users. Now Pavel is working on an extremely interesting instance associated with decoding the encoded Ontology byte data into a readable form.

    Team Code Repos

    From our side, we are ready to make the part associated specifically with Polkadot fully open-source. Accesses will be given to the Polkadot team directly upon request.

    Team LinkedIn/GitHub Profilesโ€‹

    Milestone 1โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationThe described requirements fully cover the use cases and user interaction with the system. 1. Create and import an address 2. Integration of staking 3. Integration of transfers 4. Price and market performance information 5. Integration of transaction
    0c.Testing GuideEach epic describes testing opportunities. 1. Create and import an address 2. Integration of staking 3. Integration of transfers 4. Price and market performance information 5. Integration of transaction
    0d.DockerPolkadot Network is integrated into Citadel.one - https://app.citadel.one/
    0e.ArticlePress release will be prepared a few weeks before the official rollout of the network. https://medium.com/citadel-one/polkadot-overview-f7c4f06208ec
    NumberStepSpecificationDetailed descriptionTeam members involved
    1Node launch (not included in grant amount requirements)Citadel will join the Polkadot ecosystem as a validatorThe Polkadot node will be deployed with the setting of specific glitch recognition notifications (for instance, in case the validator node suspended block production, or server memory faced some issues) via Zabbix and Grafana. As a result of this stage, we expect the node to be up and running with the maintenance system and RPC interface for node access. After the successful node launch, the necessary support and updates will be provided for a longer period.Nikita (system administrator)120h per year
    2Design (not included in grant amount requirements)Interface preparation, design elements specifications, and tuningAs a result of this stage, the mockups for web and mobile UI will be ready on Figma.Margarita Omelchenko (Lead Designer)40h
    3Preparation set 1Polkadot blockchain scrutiny, data transfer to PostgreSQL (for data aggregation and statistics building)This stage mainly involves the examination of Polkadot blockchain, parser building for the data transfers to PostgreSQL database (it will allow us to aggregate data conveniently, receive transactions of a certain type on a specific address, etc.)This step will bring us some vital milestones: our database will contain all the transactions - new ones sourced directly from the blockchain will be also stored in our database that is convenient for the development needs (balance/rewards charts creation, etc.)Also, as a result we will possess the following connector methods: (isSystemAddress, validateAddress, getLastBlock, getNextBlock, getOneBlock, filterOperations, getDelegationBalanceInfo).Yeskendir (Backend Developer), Pavel (Lead Backend Developer)120h
    4Preparation set 2Examination of Polkadot transfer methods and staking systemThis step entails the connector methods: prepareTransfer, prepareDelegation, sendTransaction).Yeskendir (Backend Developer), Pavel (Lead Backend Developer)30h
    5Transfers integrationAnalysis of a network's transfer transaction; search for necessary libraries or APIs;determination of transaction preparation logic; writing logic; signing; writing the send logicUpon the successful completion of this step, we will have transactions integrated into web and mobile versions, as well as Backend API methods for the execution of transfers' transactions.Pavel (Lead Backend Developer), Petr (Lead Frontend Developer), Yeskendir (Backend Developer), Alexander (Frontend Developer), Andrey (Mobile Developer)80 h
    6Integration of stakingAnalysis of network's staking transaction, search for necessary libraries or APIs;determination of transaction preparation logic; writing logic; signing; writing the send logic. Polkadot validator list parsing.By the end of this step, we will have staking integrated into web and mobile versions, as well as Backend API methods for the execution of staking transactions via our node. Trezor and Ledger integration for Polkadot.Pavel (Lead Backend Developer), Petr (Lead Frontend Developer), Yeskendir (Backend Developer), Alexander (Frontend Developer), Andrey (Mobile Developer)80h
    7Transaction and price feed metrics addingFinding a suitable price feed solution. Information collection from node's RPC via API or source libraries.At this stage, we are preparing the relevant data for charts and the network's significant metrics.Yeskendir (Backend Developer)20h
    8Mobile integrationDevelopment of mobile app for interaction with Polkadot wallets using Web APIFor mobile app development (Android & iOS) we will use Flutter SDK. Polkadot wallets will be integrated with C++ trustwallet/wallet-core library. Furthermore, during this step we will work on screen layouts (with previously prepared design) and adaptation for different display resolutions.Andrey (Mobile Developer)120h
    9Testing and debuggingPerforming different types of testing. Verification of the main scenarios such as sending tokens, and staking in the various environments including Ledger and Trezor wallets.During this step, we proceed with testing, bug listing on Jira, test-cases writing. As a result, we will have a fully working product with all the crucial bugs fixed.Alexander (QA Engineer), Aleksey (QA Engineer)40h

    Overviewโ€‹

    The planned delivery dates are Q1โ€™2022 (approximately May). We are still sticking to the previous financial requests we mentioned in the very beginning.

    Future Plansโ€‹

    At Citadel, we focus on providing our users with seamless crypto experience. Thus, we will continue to improve our platform, add new features and promote already integrated ones. In the coming period we are planning to become a staking derivatives gateway.

    Additional Informationโž•โ€‹

    Any additional information that you think is relevant to this application that hasn't already been included.

    We have an already-working product, meaning that the platform has successful integration use-cases and is ready to provide full support for Polkadot. Additionally, we are looking forward to putting our marketing efforts in order to spread a word on Polkadot.

    No

    No

    - + \ No newline at end of file diff --git a/applications/clover_network.html b/applications/clover_network.html index 25f9d4134fa..df6b8617deb 100644 --- a/applications/clover_network.html +++ b/applications/clover_network.html @@ -4,7 +4,7 @@ Clover | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Clover

    This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

    • Team Name: Clover Team
    • Payment Address: 1HsVhJeeFx5AGGBRQzrvEqGC8FM8YfW6b6
    • Status: Terminated

    The above combination of your GitHub account submitting the application and payment address will be your unique identifier during the program. Please keep them safe.

    Project Overview ๐Ÿ“„โ€‹

    If this application in response to an RFP then please indicate this on the first line of this section.

    Overviewโ€‹

    Introductionโ€‹

    Clover is a Substrate-based Polkadot parachain which is committed to providing easy-to-use blockchain infrastructure by creating a one-stop comprehensive infrastructure that ultimately reduces the threshold and cost for the DeFi community.

    Clover provides a perfect gateway to DeFi for everyone including those who are completely new to DeFi. We bridge the gap between the crowd and the DeFi world via a user-friendly front end portal with an easy-to-navigate multi-chain wallet, block explorer/DeFi application market for regular users and a user-friendly built-in protocol library that allows developers to easily deploy their own applications. Without the need of managing multiple assets in different accounts, Clover enables users to keep track of whatโ€™s happening real-time in one place.

    Integrationโ€‹

    We decided to develop on Polkadot mainly because of its enhanced scalability and low-in-cost among other smart contract platforms in the space. As a sharded multichain network, Polkadot allows the processing of many transactions on different chains in parallel that most legacy networks do not. While providing scaling solutions through parachains, Polkadot development is steadily advanced, has gathered a large number of developers from the community, and numerous projects are emerging endlessly in the ecosystem. On the other hand, Polkadotโ€™s Substrate technology provides a relatively easy-to-use and highly customizable framework that allows us to build our platform to communicate with other ledgers, which in a sense will likely attract more users to onboard in the future.

    Clover will compete to join as parachain for Polkadot and is committed to becoming a digital finance portal and DeFi service provider on Polkadot. Focusing on both to-C and to-B users, Clover will provide a series of DeFi related products and services to meet the diverse needs of different users. At the same time, developing and providing a modular DeFi protocol, which greatly reduces the technology development threshold for upper-layer applications. Clover will put together a large user base and different projects into a one-stop open and integrated financial service platform on Polkadot, using Substrate framework, to communicate with other existing parachains such as Bitcoin and Ethereum parachains. Namely, Clover will be another parachain on Polkadot. Once the parachain gets the slot to join the Polkadot relay chain, they can communicate with each other through Cross-chain Message Passing (XCMP) protocol. That means Clover can build its DeFi with the other parachain assets, like the DeFi protocols on Ethereum.

    Team Interestโ€‹

    We are a team of like-minded people who have a dream of building a groundbreaking technology towards censorship resistance on utilizing newest additions to DLT technologies. Apart from incentivizing our core team with a structured/periodic compensation plan throughout the next 5 years with cliffs imposed in between, we give ourselves a high degree of autonomy and lots of space for creativity overall.

    Project Detailsโ€‹

    Mockups/designsโ€‹

    https://www.figma.com/file/SWg7LONt81ot05S1nlszcH/Clover-Wallet?node-id=0%3A1

    API specsโ€‹

    https://docs.google.com/spreadsheets/d/1BccgFYHS8YLEX5H9NpQf4ENE9Qwniq8YNpLEXXSAaRo/edit?usp=sharing

    An overview of the technology stackโ€‹

    The bottom layer of Clover OS is built on blockchain. Application states are built on the Polkadot network, and the storage is built on IPFS. Leveraging on Polkadotโ€™s parachain technology, Cloverโ€™s core advantage lies in its control panel. It can easily dock various user actions provided by its backend that has been integrated by a variety of tools including Wallet, Block Explorer, Polkadot-JS, and more. As a result, users can be connected, transact on various chains and integrate their corresponding functions with the support of Clover. Clover will collect incoming data and clean them, with our proprietary database and inhouse algorithm, data will undergo different sets of validation and analysis before they get applied and translated into visualizable data. Building on Substrate, Cloverโ€™s application terminal is determined to become the entrance to the global digital finance world with state-of-art simplicities. With accessible tools, better support, and lower cost, we are likely to see more applications to be developed on Polkadot in the future. Clover will foster a diversified and scalable DeFi environment that allows for more possibilities.

    Documentation of core components, protocols, architectureโ€‹

    https://docs.google.com/presentation/d/1XQTdfY8IhYGsTiiFBIeTTh25eaIEck7WJ5Tz2bBTJv4/edit?usp=sharing

    PoC/MVPโ€‹

    https://docs.google.com/document/d/1c4KecPdFp6T51YIGv45e37s7CR46MtcZEF0NSSU6Dbc/edit?usp=sharing

    Ecosystem Fitโ€‹

    As a decentralized financial service provider on Polkadot, Clover provides modular DeFi protocols and application tools, which greatly reduces the repeated efforts needed in the protocol development. Modular DeFi protocols include Staking Liquidity Protocol, Decentralized Trading Protocol, Decentralized Lending Protocol, Token Dividend Protocol, Governance Protocol, and Synthetic Asset Protocols. Clover allows its upper-layer application projects to focus on improving user experiences and accelerate innovations of diversified financial applications through its composability. Clover can potentially convert a large number of DeFi users into users of its upper-layer applications. This way, upper-layer applications will be able to bootstrap its community and inject more market values.

    Clover will also establish a developer-centric community. In addition to giving rewards to those who provide constructive contributions, Clover will encourage its third party developers to continuously build innovative dApps on top of Clover. Each project built on Clover by the third party developers will require a solid financial foundation, and generally donations from the community are insufficient to cover development expenses which results in stagnated growth. Therefore a sound funding mechanism has been established, The Developer Incentive Program, where all the projects building on Clover can benefit from a share of transaction fees. The Developer Incentive Program (DIP) is a Clover-native consensus feature that aims to direct a percentage of transaction fees to registered smart contracts to incentivize in Clover third party contract developers and commons, mainly to boost external dApp development which ultimately enlarges the Clover DeFi ecosystem overall. The program is consistent with Cloverโ€™s properties of being a decentralized operating system which does not touch the inflation schedule or alter the scarcity of CLV, but effectively increases the security of smart contracts against bugs and software vulnerabilities by enabling external development to be properly funded. Overall the benefits of the plan create the potential for a very exciting future in which Clover can grow and compete, and can reach its goal of becoming the best possible DeFi platform for all. Therefore Clover, whose key role is to be the service provider of which will allow a variety of applications to be built on top, aims to become a one-stop financial services platform that highly incentives users, developers, and upper-layer applications to innovate.

    With the rapid development of DeFi, the demand for insurance protocols is also increasing and has become an important part of the DeFi protocols. At the current stage of DeFi development, it is not yet possible to directly trade assets such as stocks, precious metals, and commodities. However, the synthetic asset protocol will allow simulations of assets price and facilitate transactions on the blockchain. In addition, the developer community we established will also become a source of innovative DeFi protocols. Clover allows modularization of the different protocols, thereby providing a resourceful module library for upper-layer applications, which will ultimately enable the creation of more diversified financial applications. With the help of Bithumb Global bootstrapping the liquidity of Clover by co-sharing its marketing and community resources, we will be advising Clover on the go-to-market strategies and PR placements as well as launching campaigns, educating Bithumb users, and distributing to our network.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Burak Keceli - Tecnical Lead
    • Chris Li - Strategy Lead
    • Norelle Ng - Operations
    • Chris Williamson - Co-strategy Lead
    • Barek Sekandari - Merketing Lead
    • Marina Danylyuk - Chief Legal Advisor

    Contactโ€‹

    Clover, Inc. (Registration Number: 2045136) Unit 8, 3/F, Qwomar Trading Complex, Blackburne Road, Port Purcell, Road Town, Tortola, British Virgin Islands, VG1110

    Team's experienceโ€‹

    As a collective, the founding team has been working together for 8 months that has been in the industry for over 2 years, of which have crossed paths multiple times in different industry conferences. Within the team Burak is mainly based in the Bay Area, Chris in Hong Kong, Norelle in Canada, and Barek is based in the UK.

    We all come from different and unique walks of life, backgrounds, and experiences which really makes us a dynamic and strong team complementing one another's skill sets. It is neat operating as a team across the globe because we can tap into different markets and bring different things to the table. Our team has been formed to optimize and complement one anotherโ€™s skill sets; from DLT engineering to economics, to operational, and marketing expertise. We have a team capable of building, executing, and scaling Clover to its fullest potential.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-time equivalent (FTE): 11.5
    • Total Costs: 0.87 BTC

    January 2021 Milestonesโ€‹

    • Estimated Duration: 1 month
    • FTE: 11.5
    • Costs: 0.29 BTC
    NumberDeliverableLanguage/FrameworkSpecification
    1.DocumentationTextStart documenting on the various aspect of the Clover product matrix.
    2.Unit TestTypeScriptThe chain specific unit tests will cover 50% at the end of Jan.
    3.LicenseTextMIT license
    4.Article/TutorialsTextWriting varios tutorials to demonstrate how to setup clover nodes
    5.Clover Rosetta ServicesNodeJSIntegrating Coinbase Rosetta services to ensure the cross-chain compatibility
    6.Clover ChainRustFully implementing distributing gas fee functionality for EVM contract deployers
    7.Clover ExplorerVue/NodeJS/SpringCloudCreating first alpha build for Clover cross-chain block explorer based on Rosetta protocol
    8.Clover StoreAndroid/iOS Native/IPFS/SolidityDelivering initial build of clover store app to be able download/execute eAPPs
    9.Clover TestnetRustWe will finalize the Clover testnet and the faucet to receive test tokens
    10.Clover Wallet AppAndroid/iOS NativeDelivering initial build of Clover official wallet on both android/iOS
    11.Clover Wallet Chrome ExtensionJavaScript/H5Delivering initial build of Chrome Extension of Clover web3 wallet
    12.Substrate module: Frontier-EVM palletRustRolling out minor EVM adjustments with Clover chain

    February 2021 Milestonesโ€‹

    • Estimated Duration: 1 month
    • FTE: 11.5
    • Costs: 0.29 BTC
    NumberDeliverableLanguage/FrameworkSpecification
    1.DocumentationTextCovering 50% of the overall features on Clover Network
    2.Unit TestTypeScriptThe chain specific unit tests will cover 90% by the end of Feb.
    3.Clover ChainRustImplementing enterprise developers' achitecture with in the low level logic
    4.Clover ExplorerVue/NodeJS/SpringCloudDelivering the beta build of Clover cross chain explorer with support of BTC/ETH/DOT/CLV
    5.Clover OS SDKNative/JSThe first version of Clover OS SDK with Android/iOS version will be released by the end of Feb.
    6.Clover Wallet AppAndroid/iOS NativeIntegrating Clover OS on Clover Wallet App
    7.Clover Wallet Chrome ExtensionJavaScript/VueFinalizing Clover chrome extension and distribute it on google store
    8.Tulip EditorVue/NodeJS/SolidityDeliverig first POC version of Tulip editor
    9.Clover Developer PortalVue/Java/NodeJS/PostgreSQLDelivering basic functionalities of developer portal with account creation/upload/upgrade eAPP
    10.IPFS IntegrationNodeJS/GoIntegrating IPFS node along with Clover node into single Docker file for distribution

    March 2021 Milestonesโ€‹

    • Estimated Duration: 1 month
    • FTE: 11.5
    • Costs: 0.29 BTC
    NumberDeliverableLanguage/FrameworkSpecification
    1.DocumentationTextDocumentation will be ready at 1.0 version to cover 100% of the current features
    2.Tulip EditorVue/NodeJS/SolidityDelivering alpha build for Tulip Editor with EVM support
    3.Clover Wallet AppAndroid/iOS NativeReleasing Clover wallet app on Google Play and Apple Store
    4.Clover OSNative/JSHaving Clover OS support for iOS/Android/Embedded by the end of Mar.
    5.Clover StoreVue/IPFS/Solidity/NodeJSDelivering the official release of Clover Store.
    6.Clover Developer PortalVue/Java/NodeJS/PostgreSQLRolling out Clover developer portal for the public with incentivize program
    7.Clover Wallet Firefox/Safari ExtensionJavascript/VueDelivering Clover Firefox/Safari extension
    8.Clover GovernanceSolidity/RustReleasing first build of Clover governance system
    9.StorageNodeJSAdding IPFS/AR/CRUST support as the Storage service

    Future Plansโ€‹

    We will start to build the developer community when TestNet is ready and SDKs are available in Q1 and Q2 2021. Detailed documentations will be provided and more contents about developing applications on Clover will be released by then. We will work with some existing developer community to hold events, as well as holding/supporting hackathons to acquire more developers once developer kits are ready in Q2/Q3 2021. Bug bounty programs will be held when Mainnet is launched. For the user community, we plan to work with some industry media to release publications. Clover maintains its social media including Twitter, Youtube, Medium, and more to provide self-generated content, and covert followers and users to our Telegram, Discord, and Kakao groups. Marketing campaigns will be held to keep user activeness while Clover will focus on incentivizing users to participate in liquidity mining and governance activities. Key metrics of campaigns include the number of new user growth, the number of token holders, the number of members in the developer and the overall community, social media followers, total value locked (on liquidity mining applications), and number of votes.

    - + \ No newline at end of file diff --git a/applications/community-health-check.html b/applications/community-health-check.html index 719886c5f73..0c8946388e3 100644 --- a/applications/community-health-check.html +++ b/applications/community-health-check.html @@ -4,7 +4,7 @@ Community Health Analytics and Benchmarking | Web3 Foundation Grants - + @@ -26,7 +26,7 @@ Previously, Head of Technical Research at Aragon. Previously, Lead Developer of the official JavaScript API for the Ethereum blockchain.

    Team Code Reposโ€‹

    All repos with the tc preface are part of the TogetherCrew project (community health check)

    Development Status ๐Ÿ“–โ€‹

    The project consists of a research part (conceptual framework) and a development part (open source data collection tool). The first phase of the research part has been completed.

    Conceptual Frameworkโ€‹

    We began to work on the community health check in Spring 2022. We have assembled a team including two PhDs in network science and an organisation designer with significant DAO and community building experience to bridge both theory and practice. Weโ€™ve reviewed over 50 papers on community, social network analysis, resilience, trust, engagement, and more. We synthesized the findings to define key indicators with high validity and predictive capacity for community health, while also taking a holistic perspective that accounts for memberโ€™s wellbeing.

    We have published our conceptual framework. This framework describes the different nested systems within a community and details a number of metrics (vital signs). It incldues insights from one of our team members on network resilience network biomimicky.

    Data collectionโ€‹

    For the data collection tool, weโ€™re going beyond traditional surveys by combining interaction data with short, targeted pulse surveys. Interaction data provides us with objective data about what is happening inside the community (social network data). While pulse survey data offers insights into members' beliefs and emotional attachment to the community (pulse surveys).

    The data is anonymised and collected in a central repository for this first phase (weโ€™re exploring decentralised hosting) and managed by a team having received ethics training and at risk of losing their credentials should it be misused.

    Currently, the data pipeline for Discord is ready and functional. We have used Discord's API to fetch the data. In February we did a soft launch of our dashboard which only visualises Discord activity. The charts for displaying our custom-build engaged and disengaged members categories are being implemented in March 2023.

    At the end of 2022, we have begun conceptual work on how to analyze Twitter and on-chain data. Efforts have remained conceptual as we were focusing on our first data pipeline (Discord).

    We have started to build the designs for the pulse survey functinality and will begin user-testing the prototype end of March 2023.

    Analyzing conversations in private channels (e.g., Discord) is within a grey zone of private and public conversations and a sensitive issue. Servers and channels that are not gated in anyway (token or role) are akin to public conversations as there are no barriers for people to enter and join the conversations. On the other hand, once users need to fulfil certain criterias or pay in order to access a server/channel, the conversation could be perceived as private. This distinction has ethical and legal consequences.

    For this reason, we have worked with a legal counsel via LexDAO. As part of this, two lawyers have reviewed the process from fetching data and presenting results to ensure we are within GDPR laws. On Wednesday 22nd February we had a GDPR session for our team and implemented the lawyers' recommendations.

    Once our process from data fetching to analysis will be fully automated, we will

    Implementationโ€‹

    To date, we have delivered six community health reports (Aragon, MetaGame, Verida, Canabis Genom DAO, LexClinic, Aave), built a prototype of our dashboard and conducted 12 user interviews.

    After our first report, we have adopted a step-wise approach to integrating the network metrics, focusing on providing a clear, concise, jargon-free explanation. In addition, we have included a simulation section in our health reports to showcase what the health metric could be if the interaction pattern changes or if there is a large change in the community size.

    While the development of the full dashboard is ongoing, we continue to deliver low fidelity dashboards to interested communities. This lets us interact closely with users, helping us learn more about their problems and shape onboarding material for users. Interested communities get direct access to our team of data scientist who happily investigate follow-up questions.

    Early development of this project has been funded by Aragon, Polygon DAO, Aave, MetaCartel and Near.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    We are following a grant-matching processes to spread the risk among different communities.

    Milestone 1 - Defining metricsโ€‹

    Research social network metrics that are viable to measure the health of a community on Twitter, and how they integrate with our existing community health framework. This will build on our existing framework, extending it to metrics that have been tested and used in Twitter communities. For example, we will look into approaches to build the network, virality and clustering/fragmentation of very large online communities.

    Note: We have done an evaluation to decide wheter Reddit or Twitter would be a better option. In the discussion we had with other communities, we were more often asked about an integration with Twitter than with Reddit. Hence, from a scaling perspective, we decided that focusing first on Twitter makes more sense with us.

    That being said, we realize that Twitter is undergoing a lot of changes, and we might have to do a last minute pivot to another platform. We are building our analytical scripts in such a way that they can easily be used for other platforms. Therefore, the only thing that has to be changed in the milestones is the name of the platform.

    Milestone 1 will be focused on research. Hence, we're not going to deliver the following usually mandatory deliverables:

    NumberDeliverableSpecification
    0a.LicenseThe results will be published open-access using an Apache 2.0, GPLv3, or MIT license. We will decide later which one is most suitable for the written document.
    0e.ArticleWe will publish an article (technical document) describing the metrics, the insights (so-what), and limitations. This article will also explain how the Twitter community is build (e.g., who are nodes, when there is an edge between two people, who is excluded/included and why). We will build a directed network, where nodes are always Twitter users. From a network assembly perspective, we will not differentiate between accounts representing people and those representing communities or organizations. The edges between an user profiles are either a reply, quote, mention, retweets, or likes. Thus, a tie from user A to user B exists if (1) user A replies to user B, user A quotes user B, user A mentions user B, user A retweets user B, or user A likes user B's tweet. At this moment, we will created weighted edges, not making a conceptual difference between the interaction type (reply, quote, mention, retweets and likes).The article will not be behind a paywall. The article will be written for an audience comfortable with data analysis.

    Milestone 2 โ€” Twitter community health dashboardโ€‹

    This milestone implements the work from the previous milestone by building the dashboard. It will be build using the Twitter API v2. This comes with the following rate limits:

    Given the rate limit, we will see how users will be able to combine different accounts (e.g., parachains, dApp developers and other teams that build on Substrate) to create a holistic picture of their community.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide a tutorial for users to understand how to run the health checks themselves. Our current version will be updated to include recent development.
    0c.Testing and Testing GuideRunning the data pipeline and analyzing the data will be covered by tests to ensure functionality. We will describe how to run the tests
    0d.DockerWe will deliver a docker file to tests the functionality.
    0e.ArticleIn addition to the dashboard, we write a handout. This is a walkthrough of the dashboard, explaining each metric, if the score is good or bad, and a list of recommendations.
    1.Twitter data pipelineWe will create a data pipeline fetching data from Twitter using their API. The user will enter one or a few twitter handles. The data pipeline is build using Python. We have already a data flow for Discord visible in the following repos: Discord bot, interactions with db, and interactions between front-end and db.
    2.Twitter dashboardWe will extend our dashboard to include a page with Twitter community health data. The dashboard is build using Typescript. Our current dashbaord, build on Discord data, is available in this github. We will add the Twitter metrics to this dashboard.
    3.Workshop/callWe will hold a workshop/ call to answer any questions about the dashboard and handout.

    Future Plans:โ€‹

    We have three workstreams for our future: New metrics, new integrations, new analytical methods.

    New Metrics and Integrationsโ€‹

    New metrics and new integrations will provide incremental improvements of the dashboard and will largely be driven by scientiic research for new metrics and user research for new integrations.

    New analytical methodsโ€‹

    We are currently developing a pulse survey functionality to measure members perception of the commnunity. This provides a subjective insight on community health currently missing in the data. We are looking at text analysis and GPT3 to help community members and moderators gain an overview of important discussions and information.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website / Medium / Twitter / Element / Announcement by another team / personal recommendation / etc.

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    - + \ No newline at end of file diff --git a/applications/contracts-tool.html b/applications/contracts-tool.html index dc2c365623f..af804901851 100644 --- a/applications/contracts-tool.html +++ b/applications/contracts-tool.html @@ -4,7 +4,7 @@ Contracts performance messurement tool | Web3 Foundation Grants - + @@ -19,7 +19,7 @@ the project does not compile the contracts by itself, contracts are delivered in binary form.

    Ecosystem Fitโ€‹

    The project is useful for ecosystem at contracts development stage to track its performance and regressions on Polkadot. It is going to be used also to measure ink! language performance by Parity core team.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    We combine development and architecting skills from embedded world, cloud systems and apply them to crypto world. Until now the team has shown his proficiency aligning smart-bench with newest libraries required by ink! contracts.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Work has been started, smart bench has been updated with new libraries and is able to build and run on test net with ink! contracts.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 Smart-bench updated โ€” Basic functionalityโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up test net and run contracts with transactions.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerCreate Docker and docker-compose related configurations to build and start smart-bench, Zombienet and parachains to generate benchmarking results.
    1.Updated evm contractsWe will update tool with support for newest Moonbeam parachain.
    2.Support for solidity-wasm contractsWe will deliver support for solidity contract compiled with solang to wasm.
    3.Launch scriptsScripts which will allow to launch the tool on Zombienet.

    Milestone Smart-bench in CI/CD flow โ€” Additional featuresโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use the performance tracking tooling to generate the graphs.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerCreate Docker and docker-compose related configurations to run Grafana and InfluxDB pre-configured with dashboards and measurements.
    0e.ArticleWe will publish article on Medium that explains what was done/achieved as part of the grant.
    1.Github Actions benchmark jobsCreate workflow and implement a job to utilize Dockerized benchmarking for generating results and uploading them to repository.
    2.Results processing toolsImplementation of tooling to translate smart-bench output format to format of InfluxDB.
    3.Github Actions workflowCreate complete workflow running parallel jobs based on matrix strategy for all missing measurements.

    ...

    Future Plansโ€‹

    We are going to promote the project writing article and involve other developers to maintain it in the future

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Parity team

    - + \ No newline at end of file diff --git a/applications/coong_wallet.html b/applications/coong_wallet.html index 65bbbb79a08..57a1bdcd349 100644 --- a/applications/coong_wallet.html +++ b/applications/coong_wallet.html @@ -4,7 +4,7 @@ Coong Wallet | Web3 Foundation Grants - + @@ -22,7 +22,7 @@ image

  • Manage Dapps Access image

  • Settings image

    • Technology Stackโ€‹

    Ecosystem Fitโ€‹

    Coong is born with the intention to help mitigate the inconsistent wallet experience on desktop & mobile and bring a seamless onboarding new users experience to the Polkadot & Kusama ecosystem.

    As discussed above, thereโ€™re a few wallet solutions out there in the ecosystem that have great UX/UI but most are extension-based wallet, Coong takes a different approach as to be a website-based wallet.

    Choko wallet is also another website-based wallet but thereโ€™re a few differences:

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    None

    Team's experienceโ€‹

    We have more than 7 years of experience in software development for startups & enterprises. Seeing the potential of blockchain technologies, we have spent more than 1 year exposing to blockchains and Polakdot & Kusama ecosystem. We closely worked with SubWallet team in helping to review the source code to improve performance & stability of the wallet. Thang is a participant of the first Polkadot DevCamp in May 2022. We as users also experience the UX problems in Polkadot & Kusama ecosystem. With that, we know where and how to solve these paint points to help bring the ecosystem closer to end-users.

    Team Code Reposโ€‹

    Projects repos will be hosted at https://github.com/CoongCrafts

    Team members

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Core features & SDKโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation of the code, a live demo of the wallet and instruction on how to integrate Coong Wallet into dapps using Coong SDK.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.Wallet App / Core featuresWe'll implement the following features for the wallet app:
    - Welcome screen: Shows a small introduction about Coong & instruct users to set up the wallet by creating a new one or import from an existing seed phrase.
    - Unlock wallet: Requires users to enter password to access the wallet
    - Set up new wallet: Guides users through a screen flow to help setting up their wallet from picking up a wallet password, to back up secret recovery phrase (12 words).
    - Create account: Creates a new account
    - List accounts: Lists all of the accounts users have created
    - Request wallet access: Allows users to approve dapps access to the wallet accounts
    - Approve transaction: Allows users to sign/approve a transaction
    2.Coong SDKWe'll implement the SDK to helps integrate Coong into Dapps & publish the package to npm registry.

    Milestone 2 โ€” Additional features & demo dappโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a live demo which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article to introduce Coong Wallet, what has been done so far and plans for future development.
    1.Wallet App / Additional featuresWe'll implement the following features for the wallet app:
    - Sign message: Allow users to sign a raw message
    - Import existing wallet: Set up wallet by using an existing recovery phrase (seed phrase) or scan QR code from the export wallet feature
    - Forget wallet password / Reset wallet: Allow users to reset the wallet if they forget the password.
    - Account Controls (Forget, Copy address, Show QR Code, Export, Rename, Dapps Access)
    - Export wallet: Allow users to easily transfer seed phrase & created accounts to other devices via QR code
    - Import account from QR Code, Private Key, JSON file
    - Manage Dapps Access: Manage & update access to wallet accounts of dapps
    - Settings: Dark/light theme mode, Language, Auto-lock timer, Reveal recovery phrase, Change wallet password
    2.Demo DappWe'll create a demo dapp that is integrated with Coong wallet to demonstrate dapp-wallet interactions, similar to connect.subwallet.app.

    Future Plansโ€‹

    As mentioned, future plans for Coong wallet are to equip with more features that help users manage assets easier:

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Web3 Foundation Website & Medium

    - + \ No newline at end of file diff --git a/applications/cross-chain-wallet.html b/applications/cross-chain-wallet.html index e22c921c511..2095d5a73b4 100644 --- a/applications/cross-chain-wallet.html +++ b/applications/cross-chain-wallet.html @@ -4,14 +4,14 @@ Cross-chain Wallet - XCW | Web3 Foundation Grants - +
    Skip to main content

    Cross-chain Wallet - XCW

    • Team Name: Blockcoders
    • Payment Address: Ethereum (USDT/USDC/DAI) 0x1Ff29471bf02399A5B6Bd096A13d43982dFac357
    • Level: 3

    Project Overview ๐Ÿ“„โ€‹

    Blockcoders is proud to propose the development of a revolutionary cross-chain wallet, capable of importing and creating both EVM and WASM accounts. This wallet will make it easy for users to manage and transfer tokens between the two chains. Built with the user experience in mind, the wallet will feature the same sleek and intuitive design as Astar UI. The term cross-chain in this case refers to the ability to transfer tokens between parachains for both EVM and WASM. We plan to give constant support to this wallet and open Telegram and Discord channels to have a better feedback from the users, solve issues and add new functionalities.

    Goalsโ€‹

    • Develop a user-friendly wallet that simplifies the management of EVM and WASM accounts in one place.
    • Enable seamless and secure asset transfer between users accounts on different chains.
    • Provide a safe and intuitive platform for users to sign messages and interact with dApps.
    • Enhance transparency and accountability by displaying transaction details and links to scanner/explorer pages.
    • Maintain the wallet's decentralization and open-source nature, ensuring its trustworthiness and security.
    • Aim to cover more than 90% of the wallet's main functionalities to provide a comprehensive user experience.

    Securityโ€‹

    The wallet will implement the Keyring concept, which is the core of the secret storing and account management system in MetaMask. This approach ensures that private keys are stored locally on users' devices using browser built-in storage capabilities such as IndexedDB or WebSQL, making them accessible only to the user. Additionally, we will use encryption techniques similar to MetaMask, such as PBKDF2 iteration and AES-GCM mode, to provide an extra layer of security for the private keys. This wallet will also implement the same feature that Polkadot's extension has, which allows users to see the availability of different parachains before they make a transfer. This feature will provide users with an added layer of security and peace of mind, as they can ensure that their transfer will go through smoothly.

    Specificationsโ€‹

    In a first approach, we will be using the following technologies: React, Typescript, Polkadot API and Ethers.js. The supported browsers will be: Chrome and Firefox. The default networks will be: Astar, Shiden, Shibuya (testnet), Moonbeam, Moonriver, Moonbase Alpha (testnet), Polkadot and Kusama. The default tokens will be: ASTR, SDN, SBY, GLMR, MOVR, DEV, DOT and KSM.

    Main functionalitiesโ€‹

    • Allow users to easily create and import EVM and WASM accounts.
    • Provide a clear and intuitive overview of users' balances for both EVM and WASM accounts.
    • Enable the transfer of assets between EVM accounts, WASM accounts, and between EVM and WASM accounts.
    • Allow users to sign messages and execute calls and transactions on custom smart contracts.
    • Provide links to explorer pages to enhance transparency and accountability.
    • Give users the flexibility to add custom networks and tokens to the wallet.
    • Implement the XCM format to enable cross-chain functionality, making it easy for users to transfer assets between parachains.
    • Design the wallet using React and follow the look and feel of Astar UI, with the option to open in full-screen mode.

    The cross-chain functionality will be implemented using the XCM format, enabling users to easily transfer assets between EVM and WASM parachains. The XCM implementation will be simplified to provide a seamless user experience. The user interface will be built using React, and the design will be inspired by the look and feel of Astar UI. The extension will have the option to open in full-screen mode for a more immersive experience.

    Ecosystem Fitโ€‹

    Help us locate your project in the Polkadot/Substrate/Kusama landscape and what problems it tries to solve by answering each of these questions:

    • Where and how does your project fit into the ecosystem?
      • This wallet is a perfect match for the ecosystem as it provides a solution to the problem of having to use multiple wallets to interact with different types of accounts such as EVM and WASM.
    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?
      • The target audience is anyone that interacts with the ecosystem using a wallet. From developers to final users.
    • What need(s) does your project meet?
      • It provides a solution that today it's resolved by using multiple wallets/applications.
    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?
      • There aren't any other wallets that support both EVM and WASM accounts and the ability to send assets between them.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Jose Ramirez
    • Fernando Sirni
    • Ruben Gutierrez

    Contactโ€‹

    • Registered Address: Bouchard 705, Buenos Aires, Argentina
    • Registered Legal Entity: Blockcoders

    Team's experienceโ€‹

    We are Blockcoders, a self-managed team building on the blockchain-based in LATAM. We enjoy working on decentralized protocols and blockchains. We put a lot of effort into developing compelling user experiences that will help your project appeal to a constantly expanding market.

    Why Blockcoders? We are a team of engineers with over ten years of experience building world-class applications. We assist engineering teams in scaling fast by focusing on developer tooling, SDKs, and libraries.

    We have experience with many different blockchains, including OL, Harmony, Aptos, Polkadot, and NEAR. With live projects focused on partnering with you to create thoughtful, innovative applications that can support its community's entire lifecycle from awareness through post-purchase behaviors.

    Team Code Reposโ€‹

    Open Source Projectsโ€‹

    Web3 Foundationโ€‹

    Nearโ€‹

    Polkadot Hackathon (Smart contracts - NFTs - Moonbeam)โ€‹

    Harmonyโ€‹

    Athena DAOโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 6 month
    • Full-Time Equivalent (FTE): 3
    • Total Costs: 64000 USD

    Milestone 1 - Wallet extensionโ€‹

    • Estimated duration: 2 month
    • FTE: 3
    • Costs: 24,000 USD

    Create a wallet extension that can be installed on browsers such as Chrome, Firefox, etc. This milestone will include the following features:

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both english and spanish versions of the documentation. This will cover step by step how to configure the environment and send xcm messages.
    0c.Testing GuideUnit test and end to end tests will cover the core functions to ensure everything works as expected. The documentation will have an example on how to run these tests.
    0d.DockerA Dockerfile will be provided that will be able to start the node and run tests for all the functionality delivered within this milestone.
    1.Chrome/Firefox ExtensionDevelop a browser extension that can be installed on Chrome, Firefox, and other popular browsers.
    2.EVM/WASM accountsImplement the ability to create and import EVM and WASM accounts.
    3.Switch between networksAllow users to switch between networks, such as Astar and Moonbeam, with ease.
    4.Display accountsDisplay EVM and WASM accounts in the same place for a clear and intuitive overview.
    5.BalancesShow users their balances for both EVM and WASM accounts.

    Milestone 2 - Support for WASM and EVM accountsโ€‹

    • Estimated duration: 1 month
    • FTE: 3
    • Costs: 12,000 USD

    The main focus on this milestone will be to allow users to transfer assets between their own accounts. This milestone will include the following features:

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both english and spanish versions of the documentation. This will cover step by step how to send all kind of xcm messages.
    0c.Testing GuideUnit test and end to end tests will cover the core functions to ensure everything works as expected. The documentation will have an example on how to run these tests.
    0d.DockerA Dockerfile will be provided that will be able to start the node and run tests for all the functionality delivered within this milestone.
    1.Custom tokensEnable users to add custom tokens and networks/chains to the wallet.
    2.Mesasges EVM - WASMProvide the ability to sign messages for EVM and WASM accounts.
    3.Transfer EVM - WASMAllow users to transfer assets between their own EVM and WASM accounts on the same chain.
    4.Transaction historyShow users their transaction history for both EVM and WASM accounts.
    5.Explorer linkProvide links to explorer pages for enhanced transparency and accountability.

    Milestone 3 - Transfer assets between chainsโ€‹

    • Estimated duration: 2 month
    • FTE: 3
    • Costs: 24,000 USD

    Milestone number 3 will focus on the transfer of assets between chains. This milestone will include the following features:

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both english and spanish versions of the documentation. This will cover step by step how to send all kind of xcm messages.
    0c.Testing GuideUnit test and end to end tests will cover the core functions to ensure everything works as expected. The documentation will have an example on how to run these tests.
    0d.DockerA Dockerfile will be provided that will be able to start the node and run tests for all the functionality delivered within this milestone.
    1.XCM/XVM standard for transfersImplement the XCM/XVM standard to enable the transfer of assets between EVM and WASM accounts on different chains.
    2.Call to custom smart contractsProvide the ability to call custom smart contracts for both EVM and WASM accounts.
    3.Transactions to custom smart contractsEnable users to execute transactions on custom smart contracts for both EVM and WASM.
    4.Open BetaCreate an open Beta of the wallet for Moonbeam and Astar users to test it (with both mainnets and testnets available). Telegram and Discord channels will be created for the beta that will be announced on Twitter.

    Milestone 4 - Improve UX/UIโ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: 4,000 USD

    The last milestone will focus on improving the UX/UI of the wallet. This milestone will include the following features:

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both english and spanish versions of the documentation. This will cover step by step how to send all kind of xcm messages.
    0c.Testing GuideUnit test and end to end tests will cover the core functions to ensure everything works as expected. The documentation will have an example on how to run these tests.
    0d.DockerA Dockerfile will be provided that will be able to start the node and run tests for all the functionality delivered within this milestone.
    0e.ArticleWe will post an article on Twitter and Reddit for both english and spanish speakers communities.
    1.Polish UX experienceEnhance wallet design and user experience. As the previous milestones will focus on resolving the features from a technical perspective, but not in the "best looking" or "easiest" way, this milestone will be focused on ensuring that the features are easy to use and the user experience is smooth. All suggestions on the Telegram and Discord channels created for the Beta will be considered here to improve UX/UI.
    2.Landing pageDevelop a landing page and documentation for the wallet.
    3.Video TutorialCreate a video tutorial to help users learn how to use the wallet.
    4.End to End TestingTest the wallet on different browsers and devices to ensure compatibility and stability.
    5.QR codeAdd a QR code feature to display the address of users accounts.

    Maintaining the walletโ€‹

    Once the wallet is released, we will continue to maintain it for at least 2 years. This will include:

    • Bug fixes
    • Improvements to the UX/UI
    • Support for new features

    User Interfaceโ€‹

    The wallet interface will be based on this mock-up:

    XCM Wallet

    Future Plansโ€‹

    • Add support for popular hardware wallets, such as Ledger and Trezor, to provide users with additional security and flexibility
    • Add support to move assets between Substrate-based blockchains and other EVM blockchains. This may be done using a bridge that can lock-mint and unlock-burn tokens.
    - + \ No newline at end of file diff --git a/applications/crossbow.html b/applications/crossbow.html index 56eda212c4d..5976111eb93 100644 --- a/applications/crossbow.html +++ b/applications/crossbow.html @@ -4,13 +4,13 @@ Crossbow (formerly Creator) | Web3 Foundation Grants - +
    Skip to main content

    Crossbow (formerly Creator)

    • Team Name: DodoRare, Inc.
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    In the previous grant, we built a tool that can automate building rust game projects for Android and iOS and tested it on applications with base elements such as 2D image / 3D model rendering, music, touch events, networking (substrate communication), etc. Also, we made it engine agnostic, and the process itself of creating similar apps pretty straightforward. But there are plenty of things left to do to provide full support of features for more advanced games: like notifications, permissions, in-app purchases, better sounds and music support, Google Play/Apple ID authentication, AdMob, iOS Bitcode, Android Application Bundles, or AAB, etc. Most of these problems are not easy to solve, and many projects facing them are moving to more popular engines because you never know how much time it will take to add IAP or authentication to your project in pure rust. So our intention on this grant is to continue fixing and adding the most crucial components of games so that the whole rust community can use them in any rust project without any problems.

    Overviewโ€‹

    Crossbow - Cross-Platform Rust Toolkit for Games.

    A goal of the crossbow project is to provide a complete infrastructure for game development in rust. In addition, the project simplifies the creation and packaging of crates for Android, iOS, and other platforms. Finally, we want to make most of our tools - engine agnostic to help rust game developers integrate them into their games, engines, and crates.

    Plenty of Polkadot / Kusama / Substrate game projects want to develop their games in pure rust game engines, but as there's no well-tested and reliable software - they choose standard game engines. It's terrible for the Substrate ecosystem in several ways: 1. they could enhance the rust ecosystem; 2. generate more rust jobs that will potentially start own Polkadot projects in the future or contribute to the ecosystem itself; 3. miss an opportunity to integrate full or light Substrate node directly in-game for peer2peer synchronization and a lot of other exciting stuff.

    Of course, there are already a bunch of promising game engine projects, but they almost all don't provide at least adequate support to simple tools like mobile permissions, game SDK, auth, achievements, etc. That's why we want to create a single game toolkit for the most popular platforms.

    Maintenance listโ€‹

    โš ๏ธ Note that we may move some libraries to separate repositories for more convenient maintenance in the future.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • David Knyshenko, Blockchain/Full stack developer and Team Leader
    • Oleksii Knyshenko, Mobile/Backend developer
    • Kulmurzin Adil, Android developer
    • Daniil Anikin, Mobile/System developer
    • Rodrigo Oliveira, Game/Mobile developer

    Contactโ€‹

    • Registered Address: 651 N Broad St Suite 206, Middletown, DE 19709.
    • Registered Legal Entity: DodoRare, Inc.

    Team's experienceโ€‹

    • Mobile Game Framework - Our first team Web3Foundation grant, mobile building tool. By our team.

    • Substrate Atom and VSCode plugins - Have contributed some code to Web3Foundation Grant for Substrate VSCode and Atom plugins while worked in outsource company. By enfipy.

    • Polkadot CosmosSDK Integration - Also, contributed to another Web3Foundation Grant while worked in another outsource company. Built some logic behind ABCI, pallet and substrate with tendermint. By enfipy.

    Team Code Reposโ€‹

    GitHub accounts of all team members:

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 5.0 months
    • Full-time equivalent (FTE): 3.5
    • Total Costs: 40,000 USD

    Milestone 1 โ€” AAB and new engine supportโ€‹

    • Estimated Duration: 1 month
    • FTE: 3.5
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can create own game project with Macroquad and our toolkit, generate and sign AAB file.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Add aapt2 tool wrapperAdd wrapper for aapt2 tool for AAB generation.
    2.Add bundletool wrapperAdd wrapper for bundletool for generation AAB file.
    3.Support AAB (needs deliverable#1 and deliverable#2)Add support of generation AAB file. Android App Bundle is a publishing format that includes all your appโ€™s compiled code and resources.
    4.Support Macroquad engineAdd support of Macroquad engine. We will change our crossbundle command-line tool to support Android building of Macroquad.
    5.Enhance documentationWrite better code and wiki documentation.

    Milestone 2 โ€” Android Plugins and Cross-platform permissionsโ€‹

    • Estimated Duration: 2.0 month
    • FTE: 4.0
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to create own Android plugins and how to use cross-platform permissions. Also, update docs on how to install and start using toolkit.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Support Android PluginsAdd support of Android plugins to help add additional functionality provided by the Android platform and ecosystem (like Ads, Auth, In-app purchases, etc.). Something similar to Godot Android plugins and Unity Plugins (or here).
    2.Support Cross-platform permissionsProvide a single cross-platform permission API that works with any iOS, Android application that can be accessed from shared code no matter how the user interface is created.
    3.Simple installation of Android SDK and NDKSimple installation with environment variables, libs, etc. Make installation of Android SDK, NDK, tools more robust.

    Milestone 3 โ€” Android Pluginsโ€‹

    • Estimated Duration: 2.0 months
    • FTE: 3.5
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to use Google Play Billing and In-App updates in your own rust game project.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Sign in with GoogleAdd support of Google Sign In inside any application.
    2.Android In-App purchases with Google Play BillingAdd support for Google Play Billing. Make it possible to buy items from your game.
    3.Support Android In-App updatesAdd support for Android In-App updates.
    4.Support Android In-App billingAdd support for Android In-App billing.
    5.ArticleWe will prepare and publish an article/tutorial that explains how to add Sign in with Google, create own Android Plugins with our toolkit (what was done/achieved as part of the grant).

    Future Plansโ€‹

    Possible additional features:

    • Firebase SDK.
    • Android Game SDK.
    • Some features that people will may be interested in.

    Also we want to make similar stuff for native iOS apps. Current nearest plans are:

    NumberTitleSpecification
    1.Support iOS PluginsAdd support of iOS plugins to help add additional functionality provided by the Apple platforms and ecosystem (like Ads, Auth, In-app purchases, etc.). Something similar to Godot iOS plugins.
    2.Sign in with AppleAdd support of Apple Sign In inside any application.
    3.Better support for Apple xcrun, xcode projAdd better support and rust wrappers for Apple xcode tools, xcrun. Make cool xcode project generation library.
    4.Apple Game CenterAdd Apple Game Center support.
    5.Support Apple In-App purchasesSupport Apple StoreKit. Make it possible to buy items from your application.

    Additional Information โž•โ€‹

    How did you hear about the Maintenance Grants Program? Personal recommendation.

    - + \ No newline at end of file diff --git a/applications/crowdloan_frontend_template.html b/applications/crowdloan_frontend_template.html index ff7d8b6f7ee..8fc037b46a6 100644 --- a/applications/crowdloan_frontend_template.html +++ b/applications/crowdloan_frontend_template.html @@ -4,7 +4,7 @@ Crowdloan Front End Template | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ (as per RFP)

    Ecosystem Fitโ€‹

    Defined by RFP

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    The team was involved in creating an internal NFT Marketplace white-label (https://marketplace.10clouds.io). As the name suggests it's a website that allows mint and trade NFTs between users. It is strongly inspired by OpenSea and follows the same lazy minting pattern. After login with Metamask user can customize the profile, create collections, and start lazy-minting NFTs. The website contains extensive search/filters for collections and NFTs. An NFT can be created as Open for offers which means another user can offer a price for which they want to buy it and the owner can accept any of them. The other way of selling is the โ€žBuy now" option which allows you to sell NFTs for a set, fixed price. In both scenarios, the NFT is minted during the sale process and transferred to the new owner.

    The app is written in Next.js on the front-end and contains our own Smart Contracts currently deployed on Goerli testnet, and the Backend is written in Python with GraphQL. We have our own subgraph created in The Graph to aggregate the information about events emitted from our contracts (to update the UI accordingly).

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We are currently in a very initial phase of gathering benchmarks for the approach and setting the general approach to deliver an experience that fits the target audience.

    From our initial research we came to the conclusion that the solution should follow these traits:

    Using a Jamstack approach & Webflow templateโ€‹

    We aim to provide front-end templates that can be used with one major static site generator (SSG). This follows similar approaches like Github Pages templates for projects that contain the most important information and link-stubs to make it easy for Github projects to present themselves.

    The Jamstack will allow us to leverage the vast community behind it for future involvement of customisations and ports to other SSGs as is evidenced by the activities of these communities who are eager to port interesting templates to their SSG of choice.

    In addition to this we plan to create a Webflow template variant for teams who are more comfortable with it. Optionally we can also publish the Figma design as a basis for custom layouts by the community.

    One Page approachโ€‹

    We will also suggest a One Page or Single Page approach that, while still having the option for a menu, presents all information in one page as the name suggests. This has the following advantages:

    SSG support (Jamstack only)โ€‹

    We aim to start with the support of Astro, a popular React-based choice for SSGs, with a vast community of its own. An initial survey of the Parity community should be done to see whether these assumptions match and should be revised.

    When it comes to other SSGs, the ports can either be motivated by further grants or left to the community of open source volunteers. As mentioned before, there is an intrinsic motivation of each SSGโ€™s community to port popular templates.

    Deployment choices (Jamstack only)

    The Jamstack approach allows the community to use virtually every popular way of hosting the project sites. We are assessing whether it is beneficial to include a โ€œDeploy to Netlifyโ€ button in the projects as well to lower the initial barrier. However, projects will be able to deploy their pages to (but not be limited):

    Easy to get startedโ€‹

    Weโ€™re assuming that the approach is also a familiar way for the Parity community to get started with their project pages. Itโ€™s as simple as fork, customize, deploy.

    For parts of the community who are less comfortable with the Jamstack approach we will provide a Webflow template as well.

    Illustrative Examplesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT or TBD
    0b.DocumentationFor both approaches (Webflow & Jamstack) we provide how-to guides. Jamstack will be documented in the Github repo.
    0c.ArticleWe will publish an article presenting the templates and how to use them.
    1a.BenchmarkingDesign research of existing Crowdloan pages and other one pages designs, like Github project pages templates.
    This will allow us to synthesize viable options of the page designs
    1b.Design Direction PrototypeAiming to create as many medium to high-fidelity dd prototypes as possible that allows the Grants team and the community to have an input on the design direction
    The aim is to have the prototypes at 25%-50% completeness, to see major components/features and the general design direction. This way we don't waste time on dismissed design directions.
    The designs should follow good practices in general without requiring additional research
    1c.Repo SetupRepo setup incl. base libraries/frameworks, initial technical documentation. Undesigned base scaffold. Allows the implementation to be simplified by forking
    2.Jamstack implementation in AstroOne (1) chosen design direction

    Minimum sections:
    - Project information
    - Rewards Schema
    - Current contributions
    - Time left in Crowdloan and competition
    - Contribute CTA
    - After the Crowdloan

    Implemented as One Page Design
    3.Webflow implementationOne (1) chosen design direction

    Minimum sections:
    - Project information
    - Rewards Schema
    - Current contributions
    - Time left in Crowdloan and competition
    - Contribute CTA
    - After the Crowdloan
    Out of the scope: integrate contribution flow and polkaskan table due to Webflow technical limitations (users of template may still try to implement that on their own way)

    Implemented as One Page Design
    4.Figma Template PublishingAllows to use it for other solutions

    Future Plansโ€‹

    When provided with the initial set of templates and their usage instructions, we envision the following:

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Multiple contact people from Parity (e.g. Alberto Navarro or Richard Casey).

    Work we have already done

    We contributed to Devnet support SLA for parachains.

    - + \ No newline at end of file diff --git a/applications/cryptex.html b/applications/cryptex.html index 18b58e8747c..40ee03c58d5 100644 --- a/applications/cryptex.html +++ b/applications/cryptex.html @@ -4,7 +4,7 @@ Cryptex: EtF Network with Aura | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ When other nodes import the block, they validate it by obtaining the ID for the slot and calculating the public key $Q_i$ and verifying the signature. We verify the signature by using the DLEQ proof to verify that the secret key used to seal the block was constructed by the proper slot winner.

    Encryption-to-Future-Slotsโ€‹

    Overviewโ€‹

    We propose an Encryption-to-Future (EtF) scheme on top of the modified Aura consensus proposed above. We enable two flavors of EtF, one which allows for encryption to specific slots in the future (but which relies on a single authority for decryption, who could release the key early or not at all), and another which allows for encryption to specific epochs and requires a threshold of authorities to seal blocks to enable decryption.

    The high level idea for encrypting to a specific slot is that given a duration of time, $t$, we can identify a 'slot seed', a role to which we can encrypt a message such that it will be decryptable after time $t$ passes, when the corresponding secret will be published. We accomplish this by:

    As can be seen, it will be paramount that all participants agree on the same 'time'.

    The second type of EtF that we enable uses the threshold scheme setup in the IBE Block seal section to decrypt data. We build this off of the previous result (encryption to a slot). Here, we aggregate the public keys $\hat{Q}$ derived from each authority's identity and use the same BF IBE scheme to encrypt a message for the aggregated public key. Subsequently, using the same decryption approach as BF IBE, once at least at threshold of validators have release their key share, any messages encrypted for $\hat{Q}$ can be decrypted.

    Implementation Detailsโ€‹

    Since all of this functionality should happen outside the context of a runtime, we implement this as a specialized light client based on smoldot.

    Slot Schedulingโ€‹

    As mentioned above, the idea is that we can take some arbitrary time in the future, $t_{fut}$, and identify a slot and epoch when that future time is expected to occur (assuming persistent liveness of the network). Very roughly, our approach will be similar to the following:

    If we assume that the current slot index is $sl{prev}$ and the epoch is $e_k$, then we allow slots to be schedule starting from the next slot in the queue, $sl{curr}$. Given that each slot lasts a static amount of time, say $t{slot} \; sec/slot$, we can calculate the slot number $t$ seconds in the future with $sl{fut} = ((t / t_{slot}) \% s) +1$ where $s$ is the number of slots per epoch. We can then identify the slot winner by calculating $A[{fut}\; \% \; |A|]$, and thus the ID. The authority slot assignments will be provided to the user from a light client, with calculations of slot seeds occuring within the SDK.

    Encryption-to-future-slots (EtF)โ€‹

    Assuming that we have found an ID for a future slot $sl_{fut}$, we now want to encrypt for that slot. We will use the Boneh-Franklin IBE scheme to encrypt the message for the slot. We have a basic implementation of the BF IBE schemehere.

    The ciphertext can be stored offchain with a reference to it published on-chain (in a pallet or contract) by calculating its sha256 hash, for example. In the future, we will replace this flavor of encryption with a more elegant solution (e.g. some type of witness encryption).

    Decryptionโ€‹

    When a slot winner's slot is active, they derive a secret key which they then use to seal the block. Additionally, the derived secret key can also be used to decrypt any messages that were encrypted for this slot. When the slot winner publishes a block, it also publishes its newly derived secret key. Offchain decryption will be possible with the BF IBE decryption mechanism.

    High Level Architectureโ€‹

    We propose the architecture of the system at a high level. It consist of three pieces:

    high-level-architecture

    Ecosystem Fitโ€‹

    Help us locate your project in the Polkadot/Substrate/Kusama landscape and what problems it tries to solve by answering each of these questions:

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Tony has worked on two, here as "iridium" and here as "Ideal Labs".

    Tony Riemerโ€‹

    I am an engineer and math-lover with a passion for exploring new ideas. I studied mathematics at the University of Wisconsin and subsequently went to work at Fannie Mae and then Capital One, where I mainly worked on fintech products, like systems for loan servicing and efficient pricing algorithms. For the previous year and a half, I've been working exclusively in the web3 space, including having worked on two web3 foundation grants here and here and as an independent consultant. Beyond the web3-sphere, I have dabbled in many open source projects as well as have built several of my own, ranging from computer vision, machine learning, to IoT and video games. Most recently, I attended the Polkadot Blockchain Academy in Buenos Aires, and this new proposal is an application of ideas I learned there applied to my previous grant.

    Carlos Montoyaโ€‹

    I have been doing software for more than 20 years, most recently in the startup world.

    Team Code Reposโ€‹

    The intended repos for this project are (but possibly subject to name change):

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Common Deliverablesโ€‹

    It should be assumed that, unless specified otherwise, each deliverable also includes proper testing (e.g. deliverable (0c)) and documentation of the item, including manual testing, unit testing, and benchmarking.

    The following items are mandatory for each milestone:

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains [...] (what was done/achieved as part of the grant). (Content, language and medium should reflect your target audience described above.)

    Additionally, outside the scope of the specified milestones, we also intend to formalize the ideas in this proposal within a whitepaper.

    Milestone 1 โ€” Block Sealsโ€‹

    Goal: Implement the IBE block seal in Aura. We do this by creating a new pallet to facilitate the identity based cryptosystem, as well as modifying the Aura pallet and client code.

    NumberDeliverableSpecification
    1.Substrate module: IBE Pallet/IBC SetupWe create a new pallet responsible for storing parameters needed for the identity based cryptosystem as detailed above. This includes param generation and distribution of the msk to authorities. The outcome of the deliverable is the pallet capable of storing system params for the IBC, including the keygen phase managed by the SessionManager.
    2.Substrate module: Aura PalletWe modify the Aura pallet to be able to calculate epk's for each known session validator. Pubkeys will be calculated on session planning and encoded in runtime storage.
    3.Substrate module: Aura ClientWe modify the Aura client to sign blocks with its secret key generated with the identity based cryptosystem as detailed above. We also modify the signature validation phase of consensus to verify the signature/DLEQ proof. For the sake of ease, the block author will publish its secret along with the block.
    4.Substrate Module: Validator IncentivesWe ensure that validators are rewarded when they participate honestly within the protocol (i.e. publish a secret). We do this by making our token inflationary, where each block author is rewarded in additional tokens when they correctly output a secret.

    Milestone 2 โ€” Encryption to Future Slotsโ€‹

    Goal: We want to enable encryption to future slots, including slot scheduling, encryption, and decryption. The following items also necesitates the development of a basic user interface, which uses the light client and SDK which we develop.

    NumberDeliverableSpecification
    1.Light ClientWe implement a light client (based on smoldot) with the added functionality that it: a. can open connections to specific nodes b. ensure clocks are properly set, otherwise return an error. This is to ensure proper synchronization, so that slot scheduling can be reliable/accurate.
    2User Interface: setupWe introduce a user interface which will act as a testbed for integrations between the light client and the SDK. The user interface will be a React project, will connect to the network via the light client, and will interface with IPFS (for storage and retrieval of ciphertexts). This intention is to integrated both light client and SDK and also to ensure that interactions with the chain function as intended.
    3.SDK: Slot SchedulingWe implement slot scheduling logic to identify a future slot based on some future 'time' and derive its inputs.
    4.SDK: EncryptionUsing the output of the slot scheduler, the user agent will be able to encrypt to a future slot or epoch. Ciphertexts will be stored offchain in IPFS, and we will refer to stored ciphertexts by their CID.
    5.SDK: DecryptionAfter a block is authored for the specified future slot, we can decrypt the secret by fetching the secret published with the block (if encrypted to a slot) or a threshold of published secrets (encrypted to epoch) and using it to decrypt the ciphertext created previously.

    Milestone 3: Putting it all together - Sealed-Bid NFT Auction PoCโ€‹

    Goal: We want to put everything developed thus far into action by developing an application that runs on the EtF network. A simple use case is to create a sealed-bid auction platform, where bids are sealed until a certain slot in the future. This work will include the development of an auction contract along with a user interface. At the end of this milestone, we will have a small testnet hosted on google cloud as well as a dapp for sealed-bid NFT auctions.

    NumberDeliverableSpecification
    1.Smart Contract: Auction ContractWe develop a smart contract (and host it on our blockchain) that enables an on-chain auction where participants can issue a sealed-bid which will unseal at some specific future slot. The sealed bid is stored in the contract.
    2.UI/SDK: Auction InterfaceWe develop an interface based on the testbed created in the previous milestone. This interface will have functionality to make calls to contracts, storage, and the blockchain. We also use this milestone to 'batrtletest' our SDK and resolve any issues that could arise in a real-world use case.
    3.UI + Testnet DeploymentWe deploy validator nodes to google cloud and build our first testnet. We will setup telemetry and monitoring in order to gauge real-time performance. We will also host our UI production build on IPFS and setup proper certs.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website / Medium / Twitter / Element / Announcement by another team / personal recommendation / etc.

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    - + \ No newline at end of file diff --git a/applications/cryptolab-staking-reward-collector-front-end.html b/applications/cryptolab-staking-reward-collector-front-end.html index 296ab83e083..0cc85d0c13d 100644 --- a/applications/cryptolab-staking-reward-collector-front-end.html +++ b/applications/cryptolab-staking-reward-collector-front-end.html @@ -4,13 +4,13 @@ CryptoLab Staking Reward Collector | Web3 Foundation Grants - +
    Skip to main content

    CryptoLab Staking Reward Collector

    • Team Name: CryptoLab
    • Payment Address: 0x064530BBA1ea3aaE6cC68207Ec75EEa6a7C0c78b (DAI)

    Project Overview ๐Ÿ“„โ€‹

    This application is in response to https://github.com/w3f/General-Grants-Program/blob/master/rfps/staking-rewards-collector-front-end.md

    Overviewโ€‹

    The Staking Rewards Collector requests us to make a front-end UI so that non-technical-background people can utilize the tool in a simple way. As the requested features are quite similar to what we have done recently, We intend to implement the requests from the rfps on https://www.cryptolab.network.

    Project Detailsโ€‹

    We plan to utilize the current Staking Reward webpage (https://www.cryptolab.network/tools/dotSR) on CryptoLab as the design base. However, we will change the data source from our DB to Staking Rewards Collector, retrieving rewards from the subscan because the subscan stores all rewards data.

    • Mockup UI
    1. Staking Reward Dashboard

    image

    See the image above, CryptoLab already have a similar page for users to query their rewards. We are going to enhance the followings

    • Filter as requested
    • Export to CSV or JSON

    image

    The table content would also be re-worked to the Staking Rewards Collector one, mockup as below.

    image

    One thing needs to discuss is that is the Tax column necessary? As it is not an input variable, users cannot enter their rates in their countries. We intend to remove the column from the webpage if you're ok.

    1. Staking Reward Filter

    Upon clicking the filter icon, a dialog would appear and provide the following options as requested. A help button would be in this dialog to give users hints of how to use it.

    image

    • Tech Stack

    Front End: Vue.js

    Back End: Rust, NodeJS

    • Architecture

    Currently, CryptoLab is served on a single VPS, thus the Staking Rewards Collector would be an application on it. When a user want to see the rewards, the website would call an API on the cryptolab-web-backend, and it then spawns a thread to call the Staking Rewards Collector and parse the responses in files. The image below show the concept of architecture of the service.

    image

    The modules in white blocks are what we have now. We plan to call Staking Rewards Collector from the cryptolab-web-backend and parse the json output to respond to the query from the website.

    Ecosystem Fitโ€‹

    The staking-rewards-collector is a tool for gathering staking rewards for given addresses and cross-referencing those with daily price data. It is a handy tool for every validator and nominator in the ecosystem. However, since it currently has a CLI and requires technical knowledge to set up (git, nodejs, yarn). A front-end hosted on a website could help many users reach this tool and enjoy the benefits.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Yu-Kai Tseng GitHub has a master's degree in Computer Science. He also had 9-year working experience in developing Industrial Network Management Softwares/Services and is now a freelancer. Yu-kai is familiar with backend service development and had experience in leading large distributed system design and development.

    • Yao-Hsin Chen GitHub has a Ph.D. in Computer Science focusing on information security. He is a big believer in blockchain and is a co-founder of a blockchain-based solar technology company in Taiwan. Currently, he is organizing a small start-up to deliver services in the Polkadot ecosystem.

    Contactโ€‹

    • Registered Address: N/A
    • Registered Legal Entity: N/A

    Team's experienceโ€‹

    We have already developed the Cryptolab.Network website and telegram bots for both Kusama and Polkadot validators, which were tipped from both chain's councils.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    N/A

    Development Status ๐Ÿ“–โ€‹

    • Original RFP (requests for proposal)

    Development Roadmap ๐Ÿ”ฉโ€‹

    Milestone 1 (Implementation)โ€‹

    • Estimated Duration: 15 days
    • FTE: 1
    • Costs: 4000 USD
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. (1 day)
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. (2 days)
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. (3 days)
    1.Integrate Staking Rewards Collector to CryptoLabDevelop CryptoLab backend so that it can call the Staking Rewards Collector and parse the output files. (2 days)
    2.Integrate Staking Rewards Collector to CryptoLab WebsiteAdd RESTful APIs to allow parameter input and retrieve the output files. (1 day)
    3.UI for filterDevelop a dialog to allow user input necessary parameters. (1 day)
    4.UI for data visualizerModify the table on our current Staking Reward Viewer to fit the requested one. (1 day)
    5.Drop-down List for download reportModify the download button to allow users select either CSV or JSON. (0.5 day)
    6.Help pageImplement help texts and descriptions for users. (0.5 day)
    7.DeploymentDeploy the code on CryptoLab. (1 day)
    8.Test live environmentTest on both Chrome and Firefox and provide a report (1 day)
    9.PolishingReach out for feedback to the Grants Team. Integrate final feedback on functional, as well as cosmetic changes like font size, colors, typos etc. (TBD days)

    Future Plansโ€‹

    Ask users to enter the Start Balance is bothersome. To further enhance the Staking Rewards Collector, it is technically possible to auto fill the Start Balance of the start date by recording the block number at 12:00 am each day and then collecting the balances during the block number from Polkascan. However, it requires specific works and would not be included in the planned 3-week duration. We may do it if feedbacks from users are positive.

    image

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    We see the RFP on the github and think it is very similar to what we have already done. We think we are suitable for working on it because CryptoLab has provided tools for both validators and nominators. Thus current CryptoLab users can enjoy the benefit from the Staking Rewards Collector. The CryptoLab can also attract more Staking Rewards Collector users to use the site.

    - + \ No newline at end of file diff --git a/applications/curve_amm.html b/applications/curve_amm.html index 6533557f5fc..abd42566173 100644 --- a/applications/curve_amm.html +++ b/applications/curve_amm.html @@ -4,7 +4,7 @@ Curve AMM | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ To demonstrate the use-case of Curve AMM we will deploy the module to Equilibrium substrate adapting it slightly to support Equilibrium's balances module.

    Polkadot Ecosystem Benefits Curveโ€™s unique stableswap invariant utilizes liquidity much more efficiently compared to all existing DEXes for stablecoins at already several hundred USD TVL (total value locked). Since initial liquidity on Polkadot is hardly going to be very large, proposed efficiency is VERY important for the ecosystem to flourish.

    Why are we creating this project We believe in mutually beneficial cooperation between Polkadot, Curve, and Equilibrium. We want to give community a useful tool for managing liquidity in assets with same primary underlying.

    Project Detailsโ€‹

    Please refer to Curve AMM google doc file for details on business logic, Curve's invariant calculations, and technical specification.

    Ecosystem Fitโ€‹

    There is a Sunrise DEX project which aims to deliver identical functionality. There are several diferences worth highligting:

    Teamโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    The team has strong experience building Decentralized Financial Protocols in Ethereum, EOS, and now Polkadot.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmapโ€‹

    Overviewโ€‹

    Milestone 1: Initial implementation, pool manipulations, invariant calculationโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how substrates may integrate our pallet
    0c.Testing GuideThe code will have unit-test coverage (min. 90%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    1.Module designAssets will be handled using a new assets trait. We will implement a pool storage structure for handling different asset pools with different parameters.
    2.Customizable Liquidity PoolsWe will implement methods to set up custom asset pools.
    3.Invariant calculationWe will implement a method to iteratively calculate Curveโ€™s invariant D and points on the bonding curve in non-overflowing integer operations.

    Milestone 2: Assets exchangeโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDocumentation We will provide both inline documentation of the code and a basic tutorial that explains how substrates may integrate our pallet
    0c.Testing GuideThe code will have proper unit-test coverage (e.g. 90%) to ensure functionality and robustness. In the guide we will describe how to run these tests. Tests will include: creation of stable coin pool, addition and removal of liquidity, swap (exchange), rewards for LPs
    1.ExchangeWe will implement methods to work with asset pools: add liquidity / remove liquidity, and exchange assets.
    2.RewardsWe will implement a mechanism to reward liquidity providers with LP tokens.
    3.Asset fluidityAssets locked inside Curve liquidity pools may be further used in various lending protocols across the Polkadot ecosystem.

    Future Plansโ€‹

    Expand research in AMMs and possibly introduce Invariants based on economic model of rational economic agents who strive to maximize their representative utility function with a choice of varieties under the budget constraint. (e.g. Dixit-Stiglitz)

    Additional Informationโ€‹

    The work under this application will be done under the supervision of the Curve team. The stable swap AMM will be delivered and launched under Curve's brand, Equilibrium will be responsible for tehcnical/dev support.

    - + \ No newline at end of file diff --git a/applications/cyclops.html b/applications/cyclops.html index fc72f1846a5..dc5992635ed 100644 --- a/applications/cyclops.html +++ b/applications/cyclops.html @@ -4,7 +4,7 @@ Cyclops Validator Dashboard | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ downtime poor performance

    Ecosystem Fitโ€‹

    Where and how does your project fit into the ecosystem?โ€‹

    Cyclops is an important addition to the Polkadot ecosystem as it addresses a key need for network validators. Validators are a critical part of any blockchain network, and they play a key role in securing the network, validating transactions. However, managing a large number of validators can be a complex and time-consuming task, and there is a need for tools that can help validators to manage their operations more efficiently.

    Cyclops fits into the Polkadot ecosystem as a validator dashboard application that provides a comprehensive and user-friendly interface for validators to manage their operations. The application also provides detailed analytics and insights to help validators make informed decisions about their operations.

    Cyclops complements other tools and services in the Polkadot ecosystem, such as Polkadot-JS, Polkadot telemetry, and Polkadot wallet applications.

    Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?โ€‹

    Validator operators

    What need(s) does your project meet?โ€‹

    We meet several critical needs for validators in the Polkadot ecosystem, including:

    Efficient Validator Management: Validator management can be a complex and time-consuming task, especially for validators who are managing a large number of validators. Cyclops provides a user-friendly dashboard that allows validators to easily monitor and manage their validators' performance and income, enabling them to optimize their operations.

    Real-Time Performance Monitoring: The Polkadot network is constantly evolving, and validators need to stay on top of performance metrics to ensure that their validators are operating effectively and efficiently. Cyclops provides real-time data on key performance indicators, enabling validators to quickly identify and address any issues.

    Historical Data Analysis: Historical data analysis is critical for validators who need to understand their validators' performance over time. Cyclops provides historical data and detailed analytics, allowing validators to make informed decisions about their operations.

    Notifications and Alerts: Validators need to stay on top of network events and changes that can impact their validators' performance and income. Cyclops provides notifications and alerts to help validators stay informed about critical events and make informed decisions about their operations.

    Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?โ€‹

    As far as I am aware, there are no similar projects on either Polkadot nor other blockchains. Grafana validator dashboards exist for Ethereum, though do not offer a similar level of insight and income management tools.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Arthur Hoekeโ€‹

    Arthur Hoeke is a seasoned full-stack software developer with over 7 years of experience in developing web and software products. He has specialized in web development and blockchain technology and has a track record of working on various projects.

    Arthur started his career in software development in 2016 and has since then been involved in developing a wide range of web applications and software applications. One of Arthur's notable projects was the development of a Zilliqa wallet app, a decentralized cryptocurrency wallet built on the Zilliqa blockchain. He played a key role in developing the app's architecture, designing the user interface, and implementing various security features to ensure the wallet's safety and security.

    Arthur has also worked as a full-stack developer for the NFT platform Mintable, where he was responsible for developing various features for the platform, including the backend APIs, and the user interface.

    Johan Hoekeโ€‹

    Johan Hoeke is an experienced Unix SysAdmin with over 16 years of experience working for Tilburg University in Holland. He is a highly skilled professional with a strong service-oriented mindset and an extensive background in problem-solving using open source solutions.

    Johan is a Red Hat Certified Engineer (RHCE) and has a deep understanding of Unix-based systems, with expertise in system administration, security, network architecture, and high availability solutions.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We currently have a fully operational proof-of-concept, and have started with the UI-UX rework. Work on front and back-end will begin after the user-interface design has been completed.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 Front-end โ€” finish UI design in Figma and convert to HTML, Angular setupโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide basic documentation about how to setup the project and generate a build. (eg. install node packages, et cetera)
    0c.Testing and Testing GuideWebsite design will corrospond to Figma design and be developed to HTML5 standards.
    0d.Dockerdoes not apply
    1.Figma designUI-UX design for Cyclops in Figma, containing screens for: login, register, dashboard, settings
    2.HTML / SCSSConvert Figma design into a website using HTML5 and CSS
    3.Angular setupCreate the Angular project for Cyclops, include pages for website

    Milestone 2 Back-end โ€” Middleware APIโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide basic documentation about how to self-host the express middle, setup database, setup e-mail smtp, subscan API key and API endpoints
    0c.Testing and Testing GuideWe will provide an API-endpoint which tests all services (smtp, substrate API, database connection) and returns status
    0d.DockerWe will provide a dockerfile to demonstrate the API running on a local machine
    1.Express API endpointsSetup express and all required end-points
    2.Database structureSetup full database structure
    3.SMTP functionalitySetup smtp functionality for e-mail alerts
    4.Subscan APIImplement subscan API

    Milestone 3 Release โ€” Implement middleware into front-endโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will update our front-end documentation to reflect how to implement the back-end API
    0c.Testing and Testing GuideWe will host Cyclops on dashboard.decentradot.com for public testing and provide a basic guide on how to get started using the application
    0d.DockerWe will provide a dockerfile to demonstrate the full project running on a local machine
    0e.ArticleWe will publish an article on Medium which explains Cyclops and a basic setup guide
    1.API ServiceCreate service in Angular to communicate with API
    2.Display dataFetch data from API and display on dashboard
    3.Elected / waitingDisplay elected / waiting status per validator
    4.Reward trackingDisplay daily income tracking
    5.Token price trackingDisplay token price data
    6.ERADisplay network ERA progress information
    7.1kv statisticsDisplay 1kv statistics if applicable to selected validator
    8.StashStash balance tracking
    9.PDF reportsMonthly PDF export functionality, overview of all reward transactions
    10.E-mail alert systemSent e-mail alert if validator is down
    11.ERA point trackingPer-session ERA point performance tracking

    Future Plansโ€‹

    We are committed to supporting and promoting the project both in the short term and in the long term. In the short term, we intend to use, enhance, promote and support the project in the following ways: Use: We will use Cyclops internally to monitor and manage our own validators, and to gain insight into the performance and income of our validators. This will allow us to optimize Cyclops accordingly.

    Enhance: We will continuously work to enhance Cyclops by adding new features and improving existing ones. We will listen to feedback from our users and incorporate their suggestions into the project, ensuring that it remains a valuable tool for network validators.

    Promote: We will promote Cyclops to the Polkadot community and beyond, through various channels including social media, forums, and other relevant communities. We will actively seek out new users and collaborators, and work to build a strong community around the project.

    Support: We will provide support to our users through various channels including email and the 1kv Element chatroom. We will ensure that our users have a smooth experience with Cyclops, and that any issues are resolved quickly and efficiently.

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    Not applicable

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/dao-entrance-phase-1.html b/applications/dao-entrance-phase-1.html index 977a9b88170..30385f99295 100644 --- a/applications/dao-entrance-phase-1.html +++ b/applications/dao-entrance-phase-1.html @@ -4,13 +4,13 @@ DAO-entrance phaseย 1 | Web3 Foundation Grants - +
    Skip to main content

    DAO-entrance phaseย 1

    • Team Name: Asyoume inc (็‚น้“ไธบๅ€็ง‘ๆŠ€ๆœ‰้™ๅ…ฌๅธ)
    • Payment Address: 1PE3N5KmEdhE561i5jRTxeQidSuQGrGtLj912GFMw4vxXMG (aUSD)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    In recent years, with the rapid development of information technology, people's work mode has gradually changed from centralized work to decentralized work. Besides, the spread and prevalence of COVID-19 in recent years get people know the importance of diverse work modes. With this trend, the concept web3 steps out from its previous version web2.

    Currently, most Web3 companies are still working with tools within Web2, such as Telegram, Discord, Google Drive, Enterprise WeChat, DingTalk, Lark, and etc, Which user's information and initiative are limited.

    DAO-entrance is trying to create a safe, efficient, powerful and Web3-based instant collaboration tool, which is a breakthrough. It establishes solid trust relationship among organization members through open and transparent smart contract; it maintain end-to-end encrypted communication, to ensure efficient and confidentiallity; it improves work efficiency with thousands of open-source collaborative tool libraries; it keeps data in safe hands through distributed and decentralized storage.

    DAO-entrance focuses on providing DAO with a comprehensive collaborative tool. The tool will help DAO to set up a core team. After the core team authorized by the community, they can make decisions on the daily affairs of DAO, in order to avoiding endless voting.

    Project Detailsโ€‹

    Our long-term goal is to provide a safe, private, efficient and automated DAO tool for enterprises, blockchains and web3 practitioners, in a multi-stage style in different period, and, in the meantime, to offer communication, consensus, production, settlement and other basic needs of members.

    Currently, we provide not only "ink!"-based DAO smart contract templates, but also substrate-based pallet templates, which support instant integration of all substrate-based blockchains. By compatible with existing DAOs through a non-instrusive way, it allows enterprises and organization to create their own DAOs in a more convenient way.

    At this stage, DAO-entrance will provide a slack-like client which is based on the matrix protocol for instant messaging. Users can log in with a blockchain account. This tool is designed for modern devices and is compatible with devices equipped with Windows/mac/Linux/android/iOS, and provides organization members with a concise and convenient collaboration platform.

    img

    Throughย DAPP rendering engine which is based on flutter, DAO-entrance is compatible with most DAPPs and run at a faster speed. The core business would be materialized by flutter native applications, and DAPPs would be rendered by the dapp engine.

    img

    DAO-entrance Client is a non-intrusive client that supports layer1 blockchain and layer2 smart contracts, and it's dedicated to adapting DAO scenarios. As an initial stage, we build the DAO-entrance chain based on the substrate, and manage the DAO-entrance chain by using DAO. After continuous improvement of the Client, we create DAO-entrance DAO, which is a fully autonomous and decentralized organization. Through our own requirements of DAO-entrance and continuous introduction of other work modes of DAO, we provide substrate pallet and "ink!" smart contracts with a fast DAO solution Polkadot Ecosystem.

    According to business needs, DAO organizations will set up skill groups, called "guilds", and each guild will automatically create public chat channels and Kanbans in DAO-entrance. Users can join a guild based on their own strengths or willings. Members can choose whether to participate in projects or events according to their own strengths and willingness.

    We provide DAO templates the substrate pallet and ink! Smart contracts:

    1. RoadMap management.
    2. Manage DAO share.
    3. Management of core team and guild.
    4. Workflow management (board/task).
    5. Financial management.
    6. Task bounty management.
    7. Hot-swap voting management.
    8. Contribution value and medal management.
    9. Level management.

    DAO-entrance focuses on providing DAO with a comprehensive collaborative tool. The tool will help DAO to set up a core team. After the core team authorized by the community, they can make decisions on the daily affairs of DAO, in order to avoiding endless voting.

    According to business needs, DAO organizations will set up skill groups, called "guilds", and each guild will automatically create public chat channels and Kanbans in DAO-entrance. Users can join a guild based on their own strengths or willings. Members can choose whether to participate in projects or events according to their own strengths and willingness.

    img

    We provide DAO templates the substrate pallet and ink! Smart contracts:

    1. RoadMap management.
    2. Manage DAO share.
    3. Management of core team and guild.
    4. Workflow management (board/task).
    5. Financial management.
    6. Task bounty management.
    7. Hot-swap voting management.
    8. Contribution value and medal management.
    9. Level management.

    Ecosystem Fitโ€‹

    Polkadot ecology currently don't have enough efficial tools specifically designed for DAO services. DAO-entrance will focus on helping DAOs to achieve synergy, and improve productivity.

    Our Client will actively adapt to the Polkadot Ecotop20 project, and offer Polkadot eco-partners a out-of-the-box online communication and collaboration tool.

    We will make substrate pallets and "ink!" Smart contracts open-sourced to provide templates๏ผŒwhich will help the partners of Polkadot ecosystem quickly integrate and publish their own DAOs.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Erica - Product Manager
    • Baiย L - Blockchain Developer
    • Vicent - Data-science Manerger
    • Wilson Lin - Market Operator

    Contactโ€‹

    • Registered Address: Building 11, No. 6055, Jinhai way, Fengxian District, Shanghai, China
    • Registered Legal Entity: Diandaoweizhi Technology Co., Ltd.

    Team's experienceโ€‹

    Erica

    • 4-years project management and investing experience in the blockchain industry. She is good at structuring and organizing the teams around the projects.
    • 5-years product Manager experience in Alibaba.

    Baiย L

    • 10-years full stack software development experience
    • Solid knowledge and experience with various programming language i.e. Go,Dart,Javascript,Rust
    • Blockchain & Substrate enthusiast

    Vicent

    • 10-years Data-science Manerger experience.
    • 7-years DAO believers

    Wilson Lin

    • 15 years management experience in big data industry includes 9 years as CEO of start up company.
    • 12 years working experience in globe IT vendor like as Oracle, Sun microsystem, EMC, NCR, etc..
    • The believer of Block Chain, DAO and cryptocurrency

    Team Code Reposโ€‹

    Team github accounts

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4ย months
    • Full-Time Equivalent (FTE): 1 FTE
    • Total Costs: 6000 USD

    Milestone 1 โ€” Implement substrate runtime and core modulesโ€‹

    • Estimated duration: 1 month
    • FTE: 1ย FTE
    • Costs: 1500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Substrate module: DAO-entrancewe create a substrate pallet specifically designed for DAO, which includes the following functions: 1. RoadMap Target Management 2. DAO Share Management 3. Core Team, Association Management 4. Workflow Management (board/task) 5. Financial Management 6. Task reward management 7. Hot-plug voting management 8. Contribution Value, Medal Management 9. Hierarchical Management

    Milestone 2 โ€” Decentralized real-time communication baseย onย matrixโ€‹

    • Estimated duration: 1 month
    • FTE: 1ย FTE
    • Costs: 1500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.DAOย desktopย andย appWe will develop a window/mac/list/ios/android client based on flutter, which includes the following functions: 1. polkadotย wallet login. 2. messaging. 3. end-to-endย encryption. 4. voice and video calls. 5. matrixย nodeย server.
    2.TestsEnd to end testing of window/mac/list/ios/android full platform to ensure application security and stability

    Milestone 3 โ€” DAO App/Desktopโ€‹

    • Estimated duration: 1 month
    • FTE: 1ย FTE
    • Costs: 1500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.DAOย UI onย nativeย flutterย ViewAย flutterย naviveย module 1. RoadMap Target Management 2. DAO Share Management 3. Core Team, Association Management 4. Workflow Management (board/task) 5. Financial Management 6. Task reward management 7. Hot-plug voting management 8. Contribution Value, Medal Management 9. Hierarchical Management
    2.TestsEnd to end testing of window/mac/list/ios/android full platform to ensure application security and stability

    Milestone 4 โ€” Dappย renderingย engineย andย ink! smart contractโ€‹

    • Estimated duration: 1 month
    • FTE: 1ย FTE
    • Costs: 1500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article and a tutorial that explains the work done as part of the grant.
    1.ink! DAO smart contractwe create a smart contract specifically designed for DAO, which includes the following functions: 1. RoadMap Target Management 2. DAO Share Management 3. Core Team, Association Management 4. Workflow Management (board/task) 5. Financial Management 6. Task reward management 7. Hot-plug voting management 8. Contribution Value, Medal Management 9. Hierarchical Management
    2.flutter DAPP rendeingwe create a engine run DAPP on Flutter natively,it is Compatible with Polkadot {. js} extension api
    3.Compatible with Polkadot ecological top20 project1. Compatibility of governance tools 2. Blockchain status monitoring 3. Smart contract deployment and operation

    Future Plansโ€‹

    In the second phase, DAO-entrance is committed to combining block chains with privacy computing, providing cloud-like mode to provide secure and efficient privacy computing services. The mode of consensus on the chain and calculation under the chain ensures security while satisfying the operation of complex programs.

    img

    At this stage, the Privacy Computing Node provides a public Privacy Computing Platform, while DAO/Enterprise can quickly build block-chain-based trust through our portal chain, and can book Privacy Computing Resources, run secure and trusted programs, and exchange data on the chain.

    - + \ No newline at end of file diff --git a/applications/daos.html b/applications/daos.html index de0913daaf3..f3dd958abcc 100644 --- a/applications/daos.html +++ b/applications/daos.html @@ -4,7 +4,7 @@ daos | Web3 Foundation Grants - + @@ -36,7 +36,7 @@ voice of the community. Using this project, the voice of every small community can be noticed. We will continue to introduce more algorithms at the governance level to meet the governance needs of different project parties. We welcome more developers to join us to improve.

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/dapp_wallet_integration_native_mobile_libraries.html b/applications/dapp_wallet_integration_native_mobile_libraries.html index 66b3041a772..2797e7c8db4 100644 --- a/applications/dapp_wallet_integration_native_mobile_libraries.html +++ b/applications/dapp_wallet_integration_native_mobile_libraries.html @@ -4,13 +4,13 @@ Tesseract dApps/Wallet integration native mobile libraries | Web3 Foundation Grants - +
    Skip to main content

    Tesseract dApps/Wallet integration native mobile libraries

    Overviewโ€‹

    This is a follow-up grant proposal aiming to reduce the integration barriers of the mobile dApp/Wallet integration protocol built during the previous grant.

    Tesseract dApp/Wallet integration protocol implemented in our previously finished grant provides excellent UX enhancement capabilities to the Polkadot Substrate ecosystem. Its current version allows native mobile applications to request public keys and transaction signatures through seamless integration with any Tesseract-compatible wallet installed on the same smartphone. You can see the Polkadoot dApp interacting with a wallet demo here: https://www.youtube.com/watch?v=0AlDYB3Qglc.

    The version released during the previous grant is an excellent achievement for Tesseract. It is the first step toward implementing Tesseractโ€™s full potential. Ultimately, we aim to make Tesseract a universal go-to dApp/Wallet integration solution capable of handling any scenario using the shortest peer-to-peer communication path. You can read more about it in detail in one of our articles: Why do we need better dApp/Wallet connectors?

    To achieve such an ambitious goal, we need to cover two main areas of improvement:

    1. Allow Tesseract to cover more use cases: add desktop dApps connectivity, ability to work with dApps running in browsers, etc.
    2. Provide the dApp and Wallet developers with a way to integrate Tesseract as easily as it can get.

    Even though covering more use cases ASAP sounds tempting, we believe that the UX improvements Tesseractโ€™s current version brings to the Substrate community already provide enough value by itself to focus on and implement an easy way for the dApps and wallets to integrate Tesseract - a set of native libraries (Swift and Kotlin), that allows using Tesseract no harder than any native library the developers are used to.

    Why are the Tesseract native libraries necessary?โ€‹

    iOS and Android provide their developers with native programming languages, which are the standard for the platforms: Swift and Kotlin, respectively.

    In contrast, Tesseract is built in Rust for its reliability, robustness, and cross-platform nature. While providing a lot of pros, Rust is quite hard and cumbersome to integrate into a mobile app (dApp or Wallet) and requires a lot of knowledge and effort, which is a significant barrier to Tesseract integration.

    To counteract this barrier, we propose to build Swift and Kotlin native libraries that wrap all the complexity of Rust integration under the hood and provide the dApp and Wallet developers with easy and familiar native APIs that require no more effort than any other mobile library.

    This way, we reduce the integration barrier to the minimum, allowing Tesseract to participate in Polkadot/Substrate community without bearing any additional complexity for the developer.

    What about cross-platform mobile apps (React Native, Flutter, etc.)?โ€‹

    Cross-platform mobile frameworks, such as React Native and Flutter, are popular among mobile developers. Providing libraries for these frameworks is definitely planned.

    However, building a library for such a cross-platform framework is done via Swift/Kotlin bridges. This means that to build the APIs for the cross-platform frameworks, we first need to implement Swift/Kotlin Tesseract libraries. Itโ€™s an unavoidable prerequisite.

    We are approaching the infrastructure around Tesseract in stages. Even though we would love to have React Native and Flutter asap, to avoid the grant bloating, we narrowed the scope down to Swift/Kotlin, which provides significant value by itself, allowing non-cross-platform developers to benefit from Tesseract while being a prerequisite step for cross-platform libraries development anyhow. React Native and Flutter are the next step.

    Native Libraries APIsโ€‹

    In total, there are four sets of APIs of Tesseract libraries to work on:

    1. Android dApp side
    2. Android Wallet side
    3. iOS dApp side
    4. iOS Wallet side

    Each of the sides requires several rust libraries to be wrapped:

    1. Tesseract itself
    2. IPC transport
    3. Test protocol
    4. Substrate protocol

    For the sake of simplicity, we will not list all the objects and methods here but rather provide examples of how native mobile developers can use Tesseract.

    We aim to make the APIs as simple as we managed to do in Rust and keep them as similar among the platforms as possible. Even though implementing the bridges is not a trivial process and is a lot of interop code, the librariesโ€™ โ€œfrontendโ€ APIs still can be very easy and intuitive. Letโ€™s jump straight to it.

    dApp Sideโ€‹

    Letโ€™s start with some code examples we have in Rust. Here is how one would initialize Tesseract and request an account from the wallet in Rust on the dApp side:

    let polkadot_wallet_service = Tesseract::new(Arc::new(delegate))
      .transport(TransportIPCAndroid::new(&env, application))
      .service(Substrate::Protocol);


    let account = Arc::clone(&polkadot_wallet_service).get_account(AccountType::Sr25519).await?;

    In iOS, it can look something like this:

    let polkadotWalletService = Tesseract(delegate: delegate)
      .transport(IPCTransportIOS())
      .service(protocol: .polkadot)


    let account = try await polkadotWalletService.getAccount()

    And here is an example for Android:

    val polkadotWalletService = Tesseract(delegate)
      .transport(TransportIPC(application))
      .service(Protocol.Polkadot)

    val account = polkadotWalletService.getAccount().await()

    Wallet Sideโ€‹

    While the dApp APIs are typical for client-side APIs, the wallet-side APIs resemble some service implementation closely (i.e., a web service or an RPC). Here is how it works in Rust (an example is taken from the Developer Wallet):

    let ipc = Transport::default(&env)?;
    let tesseract = Tesseract::new()
      .transport(ipc)
      .service(TestService::new(...))
      .service(SubstrateService:new(...));

    Also, TestService and SubstrateService are classes implementing a certain interface (separate for each) that defines how exactly the wallet should reply to the public key and transaction signature requests. Here are the Rust interface implementations:

    impl tesseract::service::Service for TestService {
      type Protocol = Test;

      fn protocol(&self) -> &Test {
        &Test::Protocol
      }


      fn to_executor(self) -> Box<dyn tesseract::service::Executor + Send + Sync> {
        Box::new(tesseract_protocol_test::service::TestExecutor::from_service(Self))
      }
    }
    #[async_trait]
    impl tesseract_protocol_test::TestService for TestService {
      async fn sign_transaction(self: Arc<Self>, req: &str) -> tesseract::Result<String> {
        //implementation code goes here
      }
    }

    The implementation of the Polkadot Service is going to be fairly similar, just different methods (Polkadot specific):

    #[async_trait]
    impl tesseract_protocol_substrate::SubstrateService for SubstrateService {
      async fn get_account(self: Arc<Self>, account_type: AccountType) -> tesseract::Result<GetAccountResponse> {
        //implementation code goes here
      }

      async fn sign_transaction(self: Arc<Self>, account_type: AccountType, account_path: &str, extrinsic_data: &[u8], extrinsic_metadata: &[u8], extrinsic_types: &[u8]) -> tesseract::Result<Vec<u8>> {
        //implementation code goes here
      }
    }

    Such an API implementation approach is pretty straightforward for both Swift and Kotlin. The initialization is a simple builder pattern, and the Rustโ€™s traits here can be replaced with the protocols and interfaces of Swift and Kotlin 1:1 in this case. We are not providing additional examples here to keep the proposal concise, as we believe they are redundant for the wallet example due to its trivial outer API.

    Feasibilityโ€‹

    All the APIs in the examples are tested to be achievable with the mock objects. The feasibility of creating such bridges was tested while creating the mobile demo applications and the Developer Wallet for the previous grant.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Daniel Leping, @dileping on GitHub, CEO
    • Yehor Popovych, @ypopovych on GitHub, CTO

    Contactโ€‹

    • Registered Address: 251 Little Falls Drive, Wilmington, New Castle County, Delaware 19808-1674, USA
    • Registered Legal Entity: Tesseract Systems, Inc.

    Team's experienceโ€‹

    Our team has been building blockchain applications since 2017 and has worked together on Tesseract since 2018. The company got funded by SOSV and Emurgo in 2019 and took training in the dLab acceleration program.

    This is our third grant application for W3F. Previously, we were awarded to build Polkadot/Substrate Swift SDK and the initial grant of Tesseract dApp/Wallet integration protocol.

    Prior to blockchain technology, we had a wealth of experience in building mobile applications and middleware, among which the most noticeable projects are: Swift Express and Reactive Swift.

    The team has a 10-year history of working together, delivering various solutions of high complexity, including the mentioned above Swift Express and Reactive Swift, Cross++ ( cross-platform framework in C++ that allowed to keep the app logic shared while providing the capability to use native UIs) and tens of the web, mobile, and server applications for customers from around the world including the US, EU, Israel, Australia, etc.

    Team Code Reposโ€‹

    Notable past open-source reposโ€‹

    Teams' github profilesโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Roadmap Overviewโ€‹

    The development is split into four equal milestones, each covering client or wallet-side APIs in Kotlin or Swift. This split allows us to focus on a particular library at a time and achieve tangible and easily verifiable goals with each milestone.

    • Total Estimated Duration: 16 weeks
    • Full-Time Equivalent (FTE): 2

    Milestone 1: Wallet-side Library in Kotlin (Android)โ€‹

    • Estimated duration: 4 weeks
    • FTE: 2

    A library in Kotlin, wrapping the wallet-side Tesseract rust implementation. Provides Android Wallet developers with native Kotlin APIs of Tesseract.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to integrate Tesseract into a Wallet.
    0c.Testing and Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerDue to the client-side nature of the deliverable, there is no need for a docker image.
    0e.ArticleWe will publish an article that explains how Tesseract makes dApps better and how to enable Tesseract protocol support in a Polkadot wallet for Android.
    1.Wallet-side Android libraryThe library provides Kotlin APIs for Tesseract's wallet-side
    2.Wallet-side IPC wrapper for AndroidKotlin wrapper for the wallet side of Android IPC transport
    3.Wallet-side of the Test protocol in KotlinKotlin API for the wallet side of Tesseract Test protocol
    4.Wallet-side of the Substrate protocol in KotlinKotlin API for the wallet side of Tesseract Substrate protocol
    5.Android demo WalletA demo wallet that demonstrates the Kotlin APIs usage

    Milestone 2: Wallet-side Library in Swift (iOS)โ€‹

    • Estimated duration: 4 weeks
    • FTE: 2

    A library in Swift, wrapping the wallet-side Tesseract rust implementation. Provides iOS Wallet developers with native Swift APIs of Tesseract.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to integrate Tesseract into a Wallet.
    0c.Testing and Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerDue to the client-side nature of the deliverable, there is no need for a docker image.
    0e.ArticleWe will publish an article that explains how Tesseract makes dApps better and how to enable Tesseract protocol support in a Polkadot wallet for iOS.
    1.Wallet-side iOS libraryThe library provides Swift APIs for Tesseract's wallet-side
    2.Wallet-side IPC wrapper for iOSSwift wrapper for the wallet side of iOS IPC transport
    3.Wallet-side of the Test protocol in SwiftSwift API for the wallet side of Tesseract Test protocol
    4.Wallet-side of the Substrate protocol in SwiftSwift API for the wallet side of Tesseract Substrate protocol
    5.iOS demo WalletA demo wallet that demonstrates the Swift APIs usage

    Milestone 3: Client-side library in Kotlin (Android)โ€‹

    • Estimated duration: 4 weeks
    • FTE: 2

    A library in Kotlin, wrapping the client-side Tesseract rust implementation. Provides Android dApp developers with native Kotlin APIs of Tesseract.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to integrate Tesseract into a dApp.
    0c.Testing and Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerDue to the client-side nature of the deliverable, there is no need for a docker image.
    0e.ArticleWe will publish an article that explains how Tesseract makes dApps better and how to integrate it into a Polkadot dApp on Android.
    1.Client-side Android libraryThe library provides Kotlin APIs for Tesseract's client-side
    2.Client-side IPC wrapper for AndroidKotlin wrapper for the dApp side of Android IPC transport
    3.Client-side of the Test protocol in KotlinKotlin API for the dApp side of Tesseract Test protocol
    4.Client-side of the Substrate protocol in KotlinKotlin API for the dApp side of Tesseract Substrate protocol
    5.Android demo dAppA demo application that demonstrates the Kotlin APIs usage

    Milestone 4: Client-side library in Swift (iOS)โ€‹

    • Estimated duration: 4 weeks
    • FTE: 2

    A library in Swift, wrapping the client-side Tesseract rust implementation. Provides iOS dApp developers with native Swift APIs of Tesseract.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to integrate Tesseract into a dApp.
    0c.Testing and Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerDue to the client-side nature of the deliverable, there is no need for a docker image.
    0e.ArticleWe will publish an article that explains how Tesseract makes dApps better and how to integrate it into a Polkadot dApp on iOS.
    1.Client-side iOS libraryThe library provides Swift APIs for Tesseract's client-side
    2.Client-side IPC wrapper for iOSSwift wrapper for the dApp side of iOS IPC transport
    3.Client-side of the Test protocol in SwiftSwift API for the dApp side of Tesseract Test protocol
    4.Client-side of the Substrate protocol in SwiftSwift API for the dApp side of Tesseract Substrate protocol
    5.iOS demo dAppA demo application that demonstrates the Swift APIs usage

    Future Plansโ€‹

    As mentioned initially, we aim to make Tesseract a universal go-to dApp/Wallet integration solution. We approach the development of Tesseract step-by-step, with each additional step bringing a significant concrete value to the ecosystem.

    The most critical areas we plan to cover are:

    1. Simplifying the integration of Tesseract for various development platforms by providing more and more libraries for various platforms (JS, Flutter, etc.)
    2. Cover more use cases. Due to its robust and flexible core, Tesseract is extremely extendible, allowing us to aim for a universal dApp/Wallet integration solution as the ultimate goal. With its first two implemented connectors (mobile IPC for iOS and Android), Tesseract proves its capabilities to provide first-class seamless integration for mobile dApps. Soon, we will release more connectors (Bluetooth, NFC, QR, etc.), allowing more dApps to benefit from our seamless wallet integration. Desktop, Web, and more kinds of dApps will be provided with a seamless wallet integration in the near future.

    Conclusion โž•โ€‹

    Thanks to the support of the Web3 Foundation, the first version of the Tesseract universal dApp/Wallet integration protocol was built and released successfully. Though, to start providing value to the Polkadot/Substrate community, we need to lower the current technical integration barriers imposed by the fact that Tesseract is built with Rust, which is hard and labor-intensive to integrate into mobile dApps and Wallets. To eliminate this, we propose to build a set of native Swift and Kotlin libraries that wrap Tesseractโ€™s Rust implementation under the hood and provide mobile developers with a straightforward way to integrate Tesseract within minutes, thus significantly improving the UX of mobile dApps within Polkadot/Substrate ecosystem.

    - + \ No newline at end of file diff --git a/applications/dart-scale-codec.html b/applications/dart-scale-codec.html index ce25b244d3b..0a336d48193 100644 --- a/applications/dart-scale-codec.html +++ b/applications/dart-scale-codec.html @@ -4,13 +4,13 @@ dart-scale-codec | Web3 Foundation Grants - +
    Skip to main content

    dart-scale-codec

    This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

    • Proposer: NBLTrust
    • Payment Address: 1LcdMwwiG1Vt8UmMqUk1RLAd2MUpbeoyba

    Project Overview ๐Ÿ“„โ€‹

    A Dart implementation of the SCALE (Simple Concatenated Aggregate Little-Endian) Codec. We are building a wallet app called Jadewallet which will support DOT/KSM, this project is a component of it.

    Jadewallet is making a new paradigm of self-custody, which uses multi-party computation (MPC) and threshold signature scheme (TSS) technology. MPC based Threshold Signatures gives clients total autonomy over whose digital assets and multisignature ability with keyless cryptographic security.

    We are building Jadewallet with Flutter, although there are Rust, C++ implementations of the SCALE Codec, we think the Dart implementation is the first choice. And we hope the project will also help the Polkadot developer community.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Alex Xu
    • Hilbert Zhou

    Team Websiteโ€‹

    Tuolian (Shanghai) Co., Ltd.

    Team's experienceโ€‹

    • Alex Xu: Co-Founder and CTO in NBLTrust for 4 years, core developer in our three custody products. IT Consultant in IBM for 9 years. Polkadot Ambassador China. Worked as TA in two training courses hold by Parity in China.
    • Hilbert Zhou: 2 years ops experience on AIX, websphere and Power. 7+ years backend service development experience including HFT, CTA and blockchain.

    Founded in 2017 and headquartered in Shanghai, China, Tuolian(Shanghai) Co., Ltd. is a high-tech company specializing in the field of digital asset custody.

    Tuolian has secure custody softwares based on self-developed high-strength classical cryptographic algorithm, hot & cold wallet and hardware wallet products that meet the bank's security level requirements, to provide overall solutions and related technical services for digital asset custody.

    Tuolian provides a full range of custody services for well-known companies or organizations such as Math Wallet and HashQuark.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 1 month
    • Full-time equivalent (FTE): 1.5
    • Total Costs: 0.85 BTC.

    Milestone 1 โ€” Dart Implementationโ€‹

    • Estimated Duration: 1 month
    • FTE: 1.5
    • Costs: 0.85 BTC
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDelivering document in dart supported format, and publish the package to pub.dev
    0c.Testing GuideDelivering Unit tests.
    Delivering an example of fetching and analyzing binary metadata from chain's runtime.
    Delivering an example of sending extrinsics to substrate based chain.
    1.Implementing the LibraryDelivering a library that support converting between object/json/binary of following types: MetadataV11 & 12, u8, u16, u32, u64, u256, bool, fixed length array, dynamic length array, bytes, address, String, Compact, Hash256, Balance, Extrinsic, Generalized structure, Generalized Enum

    Future Plansโ€‹

    We are planning to make our dart-substrate-sdk open source.

    Additional Information โž•โ€‹

    Are there are any teams who have already contributed (financially) to the project?โ€‹

    No.

    Have you applied for other grants so far?โ€‹

    Jadewallet

    - + \ No newline at end of file diff --git a/applications/data_platform_with_deep_indexed_data_and_staking_reports.html b/applications/data_platform_with_deep_indexed_data_and_staking_reports.html index fa7a58e343b..f03c19b95d9 100644 --- a/applications/data_platform_with_deep_indexed_data_and_staking_reports.html +++ b/applications/data_platform_with_deep_indexed_data_and_staking_reports.html @@ -4,13 +4,13 @@ Polkadot Data platform with deep indexed data and staking reports | Web3 Foundation Grants - +
    Skip to main content

    Polkadot Data platform with deep indexed data and staking reports

    • Team Name: P2P.ORG Validator
    • Payment Address: 0xE22211Ba98213c866CC5DC8d7D9493b1e7EFD25A (USDC)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Current proposal is the solution from P2P.org for the problem described in Analytics Website/Data Platformย RFP.

    Overview and Ecosystem Fitโ€‹

    Implementation of the data-driven culture was a huge boosting for web2 which allowed the fin-tech industry to speed up the decision-making and the development of new products, also decrease the financial fraud and provide flexible risk-management.

    Dune analytics success and arising 15+ Dune-like platforms are the evidence that data analysis tools are especially acute for web3 today and the demand for community driven data insights continue to grow.

    P2P.org is one of the biggest validators that is participate in more than 40 POS chains. That is why the need of data, monitoring, performance analysis are the core problems in decision making for us. Weโ€™ve started to develop our data function from using external platforms such as Dune but soon we found out that there is no such platform or platforms that could help with even the most common challenges according to data needs:

    • data covering: no Polkadot data and off-chain data about deFi protocols such as Chainlink;
    • absent of the streaming doesnโ€™t allow to receive the data close-to-real time which makes it unacceptable for pro-reactive tasks such as performance monitoring;
    • threshold for entering analytics: we have high skilled data analyst who can work with any data but for business people it is impossible to get answer about new metric very quick.

    Solving these problem internally we understood that our experience and data insights could be helpful for crypto community, especially in new projects such as new cosmos chains where there are not so many users and the economy has just started to evolve. We can help new project with data-driven shilling and go deeper with data-analysis in the chains that we already covered by existing data platforms.

    According the web3 fund need from RFP Polkadot ecosystem needs:

    • extract on-chain data and transform it to be available for SQL querying by data analysts
    • provide public access through query engine to build data sets on-top of indexed data
    • provide UI interface for building dashboards on-top of data sets to visualize data insights for decision makers

    We saw some teams that already building such solutions for the RFP and want to describe our key features which could provide the best user experience according to our vision:

    • modular architecture allows you
      • to use any indexer such as Subsquid, Subquery or custom indexer (Mbelt in P2P.org case)
      • to use any database as a DWH for storing public data (in current RFP we will use BigQuery as DWH)
      • to customize ETL process for any indexer/DWH solution via Airflow DAGs
      • to customize the solution for real-time data enrichment process via direct streaming to DWH
    • dashboard with sli/slo for data quality of ETL pipeline - we provide transparent and clear data quality metrics to estimate the quality of ETL
    • P2P.org infrastructure (P2P RPC for indexation)

    Potential usersโ€‹

    We define the users of the platform as data people who generates insights from the data to support data-driven base for decision makers. These people have:

    • tech skills to write SQL queries
    • basic statistics to define calculate and estimate metrics for the business
    • expertise of the particular domain (such as NFT, particular deFi)

    Current state of Dune platform (as the Leader of the market) is about 20k users. Dune is focusing on Ethereum data and DeFi in Ethereum ecosystem. Current number of active wallets in Ethereum is 400k. So, we see that current state of the crypto industry demonstrates a high proportion of data-people to all token holders with is 5%.

    We believe that in case of mass adoption we will not see this proportion but we need to involve more people still. Our global vision for this problem is to provide ability to work with the data without SQL knowledge. That is why we develop Kolmo - AI assistant.

    Our concern is that we can first attract users from the Polkadot ecosystem, which hasnโ€™t been covered by the current data-platforms. After that we are going to provide an innovative opportunity to enter in data-driven decisions without SQL skills.

    Free usage

    The only limitation for all users is number of TB for free executing of SQL query. We would be able to charge users for executing more data.

    Project Detailsโ€‹

    We already mentioned modular architecture as key feature of the solution. The next chapter will describe it deeply.

    Modular architecture

    Indexing & ETL module consist of:

    • indexer which is Software to extract the data
    • orchestration service: you can use any source to receive the data from RPC and write it to any DWH

    DWH module is analytical data base which stores all the data and provides public access. It consist of:

    • raw layer which is simply the response from indexer - structured/decoded data from RPC nodes
    • domain layer which is the reports and data-marts that were written by the users. By default we would provide the โ€œstaking domain dataโ€ with the data marts about staking

    UI module consist of forking existing BI tool with the ability:

    • get access to DWH data (both layers)
    • interface to write the query
    • execute the SQL statement
    • save and store SQL statements (provided by users manually) to use it for visualizing
    • BI interface to build charts and dashboards on-top of DWH data

    Tech stack

    modulecomponentsolutiontech stackcomment
    Indexing & ETLindexerMbeltjsWe already develop the indexer for web3 RFP. It can extract all data like Subquery but more over it can extract data about staking process.
    We also share sli/slo for indexer and our experience showed that currently it is the best solution according to data quality and flexible enough to support custom needs like staking.
    orchestrationAirflowpythonflexible, popular ETL orchestration
    DWHraw layer + domain layerbigQuerycloud sqlcurrent solution is DWH agnostic but we are using bigQuery
    UIforked BI toolforking Superset- backend: python
    - frontend: rest- auth in the box
    • already has all functions to write, save, execute query and build dashboards
    • open-source
    • flexible role-model
    • audit of logs for security
    • ability to make dashboards public |

    Data schema

    Raw layer (indexerโ€™s data) which is MBELT data scheme described here:ย https://github.com/p2p-org/polkadot-profit-transformer/blob/main/db/000001_init.sql

    The solution comes with the second layer of data which is data marts layer.

    There are two ways to create report based on raw layer:

    • via BI where the query will be store as request to DWH
    • PR with data mart that should be re-calculated every time

    Second option is for popular/the most important reports which are accepted by admin users (p2p.org DWH team).

    Initially the solution will contain reports about staking in Polkadot/Kusama/Evm parachains:

    • active set of validators per epoch
    • stake amount between nominator and validator for every epoch
    • total validator stake per epoch
    • the validator commission for all active validators
    • the public identity of validator
    • the rewards (tokens, rewards points) earned by nominator with particular validator per epoch
    • total rewards (tokens, rewards points) earned by nominator per epoch
    • total rewards (tokens, rewards points) earned by validator per epoch
    • ability to calculate APR/APY on top of this reports

    Data quality

    Polkadot SLI (based on history for internal consumption):

    • Block processing mean time: 1073 msec (min - 238 msec, max- 35 sec)
    • Mean latency between block in RPC node to block in database: ~ 18 ัะตะบ (min - 13 sec, max 99 sec)
    • Blocks processed correctly in first attempt (others are fixed automatically): ~ 99%
    • Staking SLI: 100% (no problems detected)

    Parachains sli:

    • Block processing mean time: 914 msec (min - 81 msec, max- 98 sec)
    • Mean latency between block in RPC node to block in database: ~ 95 ัะตะบ (min - 12 sec, max 240 sec)
    • Blocks processed correctly in first attempt (others are fixed automatically) ~ 96%
    • Staking SLI: 95%

    We also have an SLIย dashboard here, but thresholds used in this dashboard were set by internal team and could be different for final public solution.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Developers:
      • Ivan Safronov (developer of Mbelt)
      • Artem Kiselev (team lead of indexation team in P2P.org)
    • DWH engineers:
      • Kovalev German - (data engineer)
      • Kamalov Sergey (team lead of DWH team in P2P.org)
    • Product owner: Kotenko Nick

    Team Code Reposโ€‹

    Indexer: Mbelt

    Public DWH: โ€œp2p-data-platformโ€ in bigQuery you can find in public access though bigQ console

    Team's experienceโ€‹

    We believe that proposed product can bring not only a new user experience for validators and NO managers but also provide true decentralization with the performance improvement. P2P.org has long-term experience in more then 25 blockchains since 2018. We can bring the high level expertise to help new participants perform better by providing recommendations on-top of the core solution.

    Our data chapter is successfully implementing data-driven culture in P2P.org during 2 years.

    1. Our developers have vast experience in data-indexation (Mbelt, Cosmos chains indexer for Agoric);
    2. Data engineers support external and internal solutions for Data warehouse with more than 200 TB of on-chain data;
    3. Data analyst with developers are finishing new stacking flow solution with Delegatorsโ€™s custom dashboards which are build on-top of DWH.

    Contactโ€‹

    Development Status ๐Ÿ“–โ€‹

    Current solution from P2P.org has already implemented:

    • mbelt indexer as open-source solution
    • private Polkadot datasets
    • private Superset without public userโ€™s access and public auth
    • dashboard with sli/slo for ETL of the platform

    We suggest proposal with 1 milestone to:

    1. copy Mbelt data (raw indexed data) to public
    2. provide public dataset about staking (example userโ€™s domain data/reports)
    3. fork Superset for public usage
    4. provide staking dashboards (example userโ€™s domain data/reports)
    5. wrapping to end-2-end open-source solution: indexer deploy + orchestration + DWH connector + BI tool

    Overviewโ€‹

    • Total Estimated Duration: 1.5 month
    • Full-Time Equivalent (FTE): 200 FTE hours [100 USD/hr]
    • Total Costs: $20,000

    Milestone 1 โ€” Forked Superset with indexed dataโ€‹

    • Estimated duration: 1.5 month
    • FTE: 3.5
    • Costs: 20,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide a documentation page about how to launch dockerโ€™s files for ETL (indexer + orchestration), DWH connection, launching UI (BI tool).
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to run indexer locally, set up data base (DWH), and run BI.
    1.Develop the ETL componentThe result of developing ETL component contains the docker with Mbelt (indexer) and Airflow with DAGs to write indexerโ€™s output into DWH (data base).
    2.Publish DWH dataOur goal for publishing data is: providing raw (indexerโ€™s data) data into public bigQ project with the ability to query and use this data for public users. The chains are Polkadot, Kusama, EVM parachains. We would also provide reports about staking on top of raw data in chains above. The additional result is SLI/SLO dashboard of ETL process to provide more transparency for users.
    3.Forking SupersetForking Superset will allow us to modify sign-in page to provide new users to join. We will make some changes on UI side to improve userโ€™s experience such as: Main page modifications to make it dash-oriented, Dashboard tab & Chart tab modification to provide user-friendly filters, SQL lab tab modification to make it more useful to search for sources, Userโ€™s settings modification to exclude useless bottoms

    Future plansโ€‹

    The functionality that we want to test and implement out of scope the RFP development:

    • materialized views for user
    • upload userโ€™s off-chain data
    • anchor modeling as data layer for analysts
    • AI assistant implementation (closed-source)
    • community driven fine-tuning of the AI assistant

    Referral Program (optional)ย ๐Ÿ’ฐโ€‹

    Not applicable****

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Web3 Foundation Website and previous grants: Multiblockchain ETL

    How did you hear about the Grants Program?

    Web3 Foundation Website and previous grants: Multiblockchain ETL

    - + \ No newline at end of file diff --git a/applications/dauth_network.html b/applications/dauth_network.html index 2a64a131a36..4340e92f1df 100644 --- a/applications/dauth_network.html +++ b/applications/dauth_network.html @@ -4,14 +4,14 @@ DAuth Network | Web3 Foundation Grants - +
    Skip to main content

    DAuth Network

    • Team Name: DAuth
    • Payment Address: 0x09C08f46d523822cC9D18A077e2e3BDE5BC07a0b (Ethereum (USDC))
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    This grant is for the RFP Social Recovery Wallet

    Overviewโ€‹

    Backgroundโ€‹

    As the RFP mentioned: "managing private keys is a difficult task." The next billion users who will enter Web3 will have a hard time entering without the empowerment of social accounts. The Web3 ecosystem needs Web2 functionality that keeps the underlying system decentralized.

    Most of the current authentication is based on the centralized OAuth and SMTP protocol framework. These protocol frameworks will make the authentication service providers becoming centralized collectors of user Web2-Web3 information (although this is not their intention). This massive collection of user data poses a significant risk of exposing the user's identity and assets, ultimately compromising the security and privacy of Web3.

    Descriptionโ€‹

    DAuth is an improved and adapted version of OAuth for the Web3 ecosystem, providing native privacy and trustless social account access for Wallets, Decentralized Identifiers (DIDs), and Decentralized Applications (DApps).

    Our solutionsโ€‹

    In contrast to OAuth, SMS, and SMTP protocols, which rely on centralized servers and third-party services to verify user identities and send messages, DAuth uses blockchain and ZK technologies to provide a trustless authentication and verifiable profile aggregation that enhances trust, privacy, and security on the Web3. This means that users can authenticate their social accounts without revealing their identities. Moreover, DApps can send Emails and SMS messages to their subscribed users while keeping the user's email addresses and phone numbers private at the same time, giving the users greater control over their personal data and enhancing their privacy.

    Decentralized OAuthโ€‹

    The DAuth adapts the mainstream OAuth service providers such as Google, Github, and Twitter for users to be able to pass the authentication of their social accounts without disclosing any information about it. This is because the whole authentication information is managed by the TEE and then a ZK proof is generated and passed onto the DApp proving that the user has authenticated.

    doauth

    Decentralized Emailโ€‹

    This anonymous mechanism is based on the reconstruction of the SMTP protocol. SMTP allows proxy servers to send emails to a given email address. When the DAuth node gets an email request, the enclave will translate the web3 address to the user's email accordingly, and the enclave will establish an SMTP channel with the email service provider. The key point is that the channel will be encrypted with a TLS handshake between the DAuth Enclave and the email service provider, which will keep the user's email address invisible to the DAuth node.

    dmail

    Project Detailsโ€‹

    Documentationsโ€‹

    • Project overview PPT here
    • Project Docs here

    POCโ€‹

    We have completed a proof-of-concept to verify the feasibility of our solutions here.

    Technology Stackโ€‹

    • DAuth Node: A DAuth Node is the basic unit of DAuth Network. DAuth Network will consist of nodes from several institutions in its early stage. In the future, the number of nodes will gradually expand with the increase in the security and stability of the DAuth Network.
    • Secure Enclave: DAuth Enclave uses Trusted Execution Environment (TEE) technology to handle social account authentication in a anonymous way. That is also the part the ZK technology can't do for now. TEE is hardware technology that is leveraged on each DAuth node. The TEE protects the core data of the users from being tampered with by the DAuth nodes.
    • Zero Knowledge Authentication: Zero-Knowledge Proofs are the best way to handle authentication problems since it keeps information private. DAuth uses zero-knowledge as an identity credential generation for users. However, the current ZK technology can not make social account authentication anonymous so we use TEE technology as an add-on module for anonymity protection and use ZK for credential generation.

    Scopeโ€‹

    There are a lot of tasks involved to get all of these into a product-ready state which is what we are always aiming for, but it'd be too extensive to fit all of the tasks into this one single open grant. Therefore, we have carved out a scope specifically for this grant, followed by the details of the future tasks.

    Grant scope

    • Develop TEE module(written in Rust) that supports basic Google OAuth.
    • Develop TEE module(written in Rust) that supports basic Email auth flow.
    • Develop TEE module that generates proofs for user authentication.
    • Develop off-chain node program(written in Rust) that coordinating with TEE module.
    • Develop on-chain protocol (written in ink! smart contract) that organizes all TEE nodes into a functioning network.
    • Contribute SDKs for dApps and wallets in Polkadot ecosystem, such as Clover and zCloak, so that users in Polkaodt ecosystem can have a trustless and private social login to their Web3 accounts.

    Future development

    • Implement more functions in TEE, such as ZK proof.
    • Accept nodes endorsed by more organizations.
    • Support more authentication methods such as Twitter and Discord.

    Ecosystem Fitโ€‹

    • Generally, their are many wallets in Polkadot ecosystem that planning to provide social login functions in the trend of Account Abstraction and MPC wallet. DAuth will make all the wallets trustless, verifiable, private, and fully decentralized.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Name of team leader: Dean Yan
    • Names of team members: Michael A. Hanono, Scott Zhang

    Contactโ€‹

    • No legal entity yet

    Team's experienceโ€‹

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We completed a prototype system to verify technical feasibility. The relevant RFP is here

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 8 months
    • Full-Time Equivalent (FTE): 3
    • Total Costs: $27,000 (payable in Ethereum-USDC)

    Milestone 1 โ€” Implement On-chain Modulesโ€‹

    • Estimated duration: 6 month
    • FTE: 3
    • Costs: 15,000USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use DAuth.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Core ProtocolImplements the nodeRegister userRegister userAuthentication and keyRecovery functions for Node program written in Rust.
    2.TEE ImplementationImplements the nodeRegister userRegister userAuthentication and keyRecovery functions for TEE part written in C++.
    3.Smart ContractImplements and test for the !ink smart contracts used for nodeRegister and userRegister.
    4.Web ServerProvide meta-data management service for DAuth users written in Rust, users can manage keys and authentication methods
    5.Polkadot.jsAdd in encryption/decryption functionality to @polkadot/keyring and @polkadot/extension so that the protocol can run without the needs to read the private key of users.
    • Estimated duration: 2 month
    • FTE: 3
    • Costs: 12,000USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a project can integrate the DAuth Protocol into their project.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.SDKCooperation with multiple wallet providers, they will integrate DAuth in their authentication flow
    3.Support mainstream authentication methodsProvide multiple authentication methods such as Google, Email, Github and other authentication methods.

    Future Plansโ€‹

    • Accept nodes endorsed by more organizations.
    • Support more authentication methods such as Twitter and Discord sign-in.
    • Open DAuth network to public, espacially to Authentication solution providers.

    As a long-term business model, we have following plans to make DAuth powerful and secure:

    • Implement more functions in TEE, such as ZK proof on the authentication result.
    • We will support more TEE implementations, such as Trusted Zone of ARM, SEV of AMD;

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Announcement by another team

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    Dean's Crust Network and Mingshi's Astart Network are both projects of Web3 Grants.

    - + \ No newline at end of file diff --git a/applications/decentral_ml.html b/applications/decentral_ml.html index cd0fb1b6506..90fc1925bbe 100644 --- a/applications/decentral_ml.html +++ b/applications/decentral_ml.html @@ -4,7 +4,7 @@ Decentral ML | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ DecentralML is built upon the Substrate framework, and leverages the Tensorflow's Federated Machine Learning library enabling seamless integration into the Polkadot ecosystem. By leveraging Substrate's flexible and modular pallet architecture, we can shortcut a lot of the overhead needed to create a chain that has a dynamic collective consensus governance approach for things like AI model weights and other safety measures along with higher level controls for licensing of the entire models, jurisdiction training rules and other multi-territorial controls.

    The project aims to be as open and flexible as possible to integrate with other project with an innovative "bring your own" (BYO) token staking economy (faciliated by Pallets such as Balances, Grandpa, Ink! etc).

    We hope for active engagement from the wider Polkadot developer network once the project is complete or even during its development. We strongly believe that this project holds the potential to transform and advance the entire AI industry.

    Team Motivation: Our team is driven by the urgent need to challenge the dominance of centralised corporates like Facebook, OpenAI, Microsoft, etc, in the field of AI model development. These companies have built powerful models that require significant computing power and data, are not environmentally efficient, limit access to AI capabilities and, potentially, create a safety threat to humankind. We believe that these models could not only be statistically improved if they were decentralised, but also may improve power usage efficiency and reduce safety concerns by being transparently controlled by humankind on-chain, rather than a select number of corporations.

    Our second motivation as Livetree involves a solution for our AI tasks, such as video processing, speech-to-text, facial recognition, scene detection, and content recommendations. We currently solve these challenges using centralised model solutions and would like to transition to a decentralised model. For further demonstrations or information on Livetree, feel free to download the free Livetree app and try speech-to-text or contact us. We will gladly provide instructions on how you can try the AI models within our app and provide the raw AI JSON processing results for object detection, landmark recognition, speech-to-text, and other AI processor outputs.

    We are passionate about decentralisation and see the limitations of centralisation in terms of quality of the models, data ownership, privacy, and safety control. This has fueled our motivation to decentralise these models and create a decentralised federated machine learning module.

    Project Detailsโ€‹

    We have made significant progress in integrating TensorFlow's Federated Machine Learning (FML) library within a decentralized Polkadot Substrate environment. This innovative approach combines the power of decentralized machine learning with the robustness of Polkadot's governance and consensus mechanism. The key objectives of our project can be summarised as follows:

    1. Personal data privacy: Our approach ensures that the model is trained on the local node or device, with only the model inferences synchronised through consensus. This preserves privacy as private data never leaves the device/node, protecting user data and maintaining confidentiality.

    2. Improved model quality: By enabling a diverse set of nodes to contribute to the training process, our decentralized approach allows for a wider range of data inputs. This results in better model insights and intelligence that may surpass current centralised models, leading to more accurate, comprehensive and widely available models.

    3. Safety and governance: The governance of consensus built within the Polkadot Substrate framework enables open collective voting on crucial aspects such as model weights, jurisdictional usage, costs, and model selection. This provides a transparent and secure environment for the future AI collective society to make informed decisions and ensures the safety and reliability of the models.

    Architecture Overviewโ€‹

    Logical Componentsโ€‹

    Logical architectural components

    Data Management: Blockchain-based encrypted data storage system that ensures immutable data storage and securely provides data access via protocols and apis.

    Federated Learning Consensus:Implements federated learning algorithms like Federated Averaging or Secure Aggregation for collaborative model training across distributed nodes.

    Collective Economy: Implements decentralized governance using a collective model, to enable decision-making amongst participants to vote on model updates, protocol changes, network parameters, reputation systems, model licensing, nodes lists and incentive mechanisms to encourage active node participation, discourage malicious behavior, and reward contributors.

    Model Deployment: Model serving frameworks (e.g., TensorFlow Serving, PyTorch Lightning) for deploying trained models for production usage, including monitoring tools and frameworks for tracking model performance, latency, and resource utilisation.

    Client Interface: This component acts as a facade providing a universal interface to the deployed models and other aspects of the system for a range of DevTools, SDKs, and user interfaces.

    Implementationโ€‹

    Data Management: Current implementation uses IPFS, however, as part of the grant we plan to make this modular so other dentralised and, potentially, distributed storage systems (such as HDFS) might be dynamically utilised.

    Federated Learning Consensus: Implements the federated learning process which involves multiple stages:

    1. Client Selection: Selecting a subset of clients or nodes themselves to participate in each round of model training.
    2. Model Distribution: Distributing the initial model or updated model parameters to the selected clients.
    3. Local Model Training: Clients perform model training on their local data using the received model parameters.
    4. Model Aggregation: Aggregating the updated model parameters from the clients to generate a node model update.
    5. Model Update Application: Applying the node model update via consensus to the global model.

    Nodes are rewarded for successfully improving the model. This happens at "Model Update Application" stage whereabouts the global model is segregated into training, testing and results data partitions. The application of the node gradient update should result in the testing partition. If the results when compared to the testing partition prove successful then the node is awarded tokens in order to pay for the required resourcesโ€”processors, memory, storage, and network bandwidth used to perform the federated learning. As part of this grant we will introduce token staking so any Polkadot compatible token can be used enabling the framework to support external token ecomonies.

    Collective Economy: By submitting and voting on proposalsโ€”referendaโ€”the DecentralML community can determine what models should be trained, the thresholds for node rewards per model, clients eligible for training, and other ownership and training specifics. These include but are not limited to jurisdicational licensing fees for model deployment and other safety measures such as weights or algorithms related to the model.

    Model Deployment and Client Interface: The ability to interact with the models and chain will be limited to a simple Javascript/Typescript set of interfaces primarily for model submission, and parameterisation through governance.

    Technology stackโ€‹

    Ecosystem Fitโ€‹

    The team has engaged with core members of the Polkadot team who have shown keen interest in the convergence of federated ML and decentralization. Through active discussions with key technical leads, we have identified immense potential to revolutionise the field of artificial intelligence using the Substrate framework and the Polkadot's developer network. Our goal is to democratise and decentralise AI models development by introducing decentralised federated machine learning, surpassing the capabilities of centralised entities. With privacy protection at the core, industries ranging from healthcare to creator and social networks can benefit from our solution.

    To our knowledge, there are currently two AI-related projects in the Substrate/Polkadot/Kusama ecosystem: DeepBrainChain and BitTensor. DeepBrainChain focuses on decentralised GPU server compute, while BitTensor offers a marketplace for ranked models. DecentralML brings decentralised federated machine learning to the ecosystem, making it an exciting addition to the Polkadot ecosystem.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    The team consists of computer science academics and software engineers, including Dr. Jamie Ward, a senior lecturer in machine learning at Goldsmith's University, Isak Grimson, a computer science graduate specialising in machine learning research, and Ashley Turing, an experienced computer software engineer with expertise in blockchain technologies.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    The current whitepapers for BitSensor and DeepBrainChain

    Here are key publications in the field of decentralised federated machine learning:

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Federated Learning Consensus & Data Management Implementationโ€‹

    NumberDeliverableSpecification
    0a.LicenseAPACHE 2
    0b.DocumentationWe will provide both a Gitbook with basic tutorial and inline documentation of the code that explains how a user can (for example) upload and train a model, this will show how the federated machine learning functionality works.
    0c.Testing and Testing GuideUnit test will comprehensively cover core functions ensuring both functionality and robustness. In the Gitbook, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Data Management ImplementationDecentralML, aims to establish a system of on-chain incentives and charges for the four key parties involved in the model's training and utilization. These parties are defined as:

    i) Model Engineers: These are the data scientists, mathematicians, and computer scientists who develop and refine the models.
    ii) Data Annotators: These users enrich the model by providing labels and annotations.
    iii) Data Contributors: These users enhance the model by adding gradients.
    iv) Clients: These are the licensors of the model who may wish to use the model for commercial, contribution or educational purposes.

    Our initial step in this process involves storing the "Master" model in a decentralized storage system. This DecentralML "PUT" method will be parameterized, allowing for the selection of different storage types (e.g., 1=IPFS, 2=Another storage type). We will abstract the data management to support pluggable data storage implementations and will implement IPFS initially. Note: In the future, we would like to support different decentralised storage types to test for update speed, retrieval and caching (see Decentralised data options for polkadot)

    The "Model Creator" initiates the upload by calling DecentralML methods using the Substrate Python Client library. Initially, uploading the "Master Model" and defining the "Training" parameters. These parameters include but are not limited to the following:
    1. The staked pool payable amount is sent by the "Model Creator" and stored on-chain as either DOT (or relevant compatible coin). These assets will ultimately be used to incentivize Data Contributors, Model Engineers, and Data Annotators.
    2. The percentage of the pool allocated to the Data Contributors, Model Engineers, and Data Annotators.
    3. The charges for Model Engineers to download the model.
    4. The charges for Licensors of the model to download it.

    These DecentralML parameters will be set using the Python client library by the "Model Creator". The method will return a global unique identifier for the model.
    2.Federated Learning ConsensusWe will write the core of rewarding "Data Contributors". Our focus will be on supporting Google's TensorFlow's Federated Learning implementation, given its widespread client support and the substantial commercial funding it has received for development. However, we acknowledge the limitations of this approach, particularly in relation to the ProxyModel approach, and we may consider modifying TensorFlow's core FL libraries in future releases to incorporate the ProxyModel approach. In terms of specific deliverables we plan on developing two DecentralML methods:

    1. defineDataContributors([clientId], [walletaddress]): This method, called by the Model Creator (MC), identifies the "Data Contributors" who are eligible to train the model. The clientId is generated by the TensorFlow FL library. It is the MC's responsibility to manage and develop the relevant Client specific applications using TensorFL client libraries. This method is expected to be called before the "Client Selection" step outlined in the "Implementation > Federated Learning Consensus" section of this application. In this context, DecentralML serves as an auditing and reward mechanism for the Data Contributors.
    2. rewardDataContributors([clientIdArray],[0-1]): This method, also called by the MC, rewards the Client for their data contribution. We anticipate this function being called after step 4, Model Aggregation, once the MC has determined a score (defined as the second parameter, ranging from 0-1). This score represents a percentage of the remaining "Data Contributors Pool" defined during the initial upload of the "Master Model". The method then allocates the assets to the Data Contributors' wallet. The advantage of this approach is that it requires minimal modifications to the TensorFlow FL library. Instead, we focus on rewarding and providing transparency for each set of gradients passed by the client, thereby incentivizing the client to contribute data to the model.

    We will also add additional administrative methods as needed, such as the ability to upload the associated Client gradients and query the allocation on-chain.

    Milestone 2 โ€” Collective Economy and Client Interfaceโ€‹

    NumberDeliverableSpecification
    0a.LicenseAPACHE 2
    0b.DocumentationWe will provide both a Gitbook with basic tutorial and inline documentation of the code that explains how a user can (for example) work with governance and stake against a model and how the client interface works.
    0c.Testing and End-to-end (e2e) Testing GuideComprehensive unit tests to ensure core functionality and robustness of code. Instructions on how to run the tests will be included. End-to-end federated learning test using the MNIST dataset for classification
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.Robust Incentivisation SchemeIn response to the feedback received, we will implement a random role assignment mechanism as part of our example game logic. We also see the value in having some flexibility in role assignments, similar to the VBFL paper. This will be configurable using the strategy pattern, thereby addressing the "game theory" concerns. As in the VBFL paper, at every communication round, each device will be randomly appointed as one of the three roles defined as follows: (1) "Data Contributors" can occasionally take on the role of "machine learning worker," as described in the VBFL paper. (2) The role of "model validator" will be an extension of our existing validation processes. This role will employ advanced validation techniques like k-fold and stratified sampling to ensure the integrity and accuracy of model training. This role can be dynamically assigned as with the "machine leanring worker" and "blockchain miner" roles, adding an extra layer of robustness. (3) The "blockchain miner" role will be responsible for incorporating validated models into the blockchain.
    1.Collective EconomyWe plan to establish governance mechanisms related to the selection and training of models, specifically for Data Annotators and Model Engineers.

    For Model Engineers, we will implement the following logical methods:

    1. listMasterModels: This method returns a report listing the modelGUID, modelName, usageType, usageTypeCost, and costTokenAccept.
    2. getMasterModels(licenseUsage, quantityOfPaymentCoins): This method takes the type of usage and the payable amount for that usage, returning the master model. It operates on an element of trust, with users expected to pay the appropriate amount based on the associated licensing (MIT, Apache, etc. defined on-chain for the model). While we don't anticipate this being a problem for this grant, future releases may include more sophisticated whitelists or permissions.
    3. listModelEngineers(modelGUID): This method returns a list of Model Engineer (ME) wallet addresses approved to call the collectiveApprovesModel method.
    4. modelEngineerUpdate(modelGUID, model, senderWalletAddress): Anyone can send their version of the model, which will be stored on-chain for review and approval. We may add more permissions to this method but the idea is to keep it as open as possible.
    5. listModelEngineerUpdates(modelGUID): This method returns a report listing the senderWalletAddress, model version, block number, and updateID.
    6. collectiveApprovesModel(updateID, collective member or MC sender address, reward percentage:0-1): This method approves the model to replace the "Master" model and awards the Model Engineer a percentage (defined in the parameter 0-1) from the Model Engineer pool.
    7. addCollectiveMember(modelGUID, walletAddress): This method adds collective members to the approval list so updates to the model by MEs can be approved. Future expansions may support issues like jurisdiction, licensing, usage, as well as parameter settings for algorithm selection and more.

    For Data Annotators, we will implement similar logical methods:

    1. uploadDataForAnnotation(image, text, sound, testQuestionnaire:questionText, answerType, questionId, answerPoints:numberPointsRewarded, batchParameters): This method allows collective members to provide data that requires annotation. The solution design records the answer types as columns and the questions as rows, enabling a wide variety of annotation questions to be modelled depending on the model requirement.
    2. getDataAnnotationQuestionnaire(modelGUID): This method returns a list of required data annotations and associated questionnaire information with data types as columns, offering flexibility to build a wide variety of dApps that could harness and offer various rewards to DAs.
    3. submitDataAnnotationForReward(modelGUID, questionId, answer): This method implements a simple validation test for the submitted annotated data, with the potential for more sophisticated game theory algorithms to validate DA submissions in the future.
    4. reportDataAnnotationAwards(modelGUID): This method returns a report of pending and allocated rewards.
    2.Client InterfaceWe will focus on utilising Substrate api-client libraries, particularly the Python library. We won't be developing a user interface for Data Annotators or any other specific targetted party. Instead, our attention will be on integrating a Python library, which could potentially be used with applications like Jupyter Notebooks and other machine learning tools in the future. It's important to note that we anticipate commerical "Clients" will use the 'getMasterModel' method, as outlined in the Collective Economy section above.
    - + \ No newline at end of file diff --git a/applications/decentralized_invoice.html b/applications/decentralized_invoice.html index fbe4860bbf8..2b817f9fc8a 100644 --- a/applications/decentralized_invoice.html +++ b/applications/decentralized_invoice.html @@ -4,7 +4,7 @@ Decentralized Invoice | Web3 Foundation Grants - + @@ -16,7 +16,7 @@ -> send the amount to the receiver and change the status of invoice from Awaiting Payment to Payed

    A similar product has been made by Request Network. They do have some products and one of them is similar to the one I would like to build: https://create.request.network/ They have used ethereum and solidity and we are gonna use substrate and rust.

    Ecosystem Fitโ€‹

    Teamโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Hello, my name is Elio. I have a master's degree in computer science and I have more than 6 years of experience as a professional software developer in the Android/Java developer in the market. I have been deeply fascinated by blockchain and discovered Substrate. I have spent 1+ year learning/contributing to Rust/Substrate.I am a contributor to the Substrate recipes repo,ย  taking it upon myself to upgrade Substrate โ€œKitchen Nodeโ€ Recipes from v1 to v2, which took 5-6 months working in my spare time.

    Hello, my name is Gerti. Over the last 5 years, I've been continuously working towards achieving clients' business goals through the application of IT technology. The collaborations I've had working in a few industries brought to life numerous products with an audience of thousands and even millions of users. The secret behind this success was creating an intuitive, visually attractive application customized to the needs of the target clientele.In addition to the substantial experience working as a Java Enterprise, I've also gained a Master's Degree in Computer Science that has equipped me with a strong knowledge of the newest tools and technologies to create flawless products your clients will enjoy.For the last few years, I have been curious about Substrate/Rust, and I am learning it in my spare time.

    Team Code Reposโ€‹

    Winner of a small grant to build an Escrow system on top of substrateโ€‹

    Deliver everything on time and meet all the requirements

    Team Githubโ€‹

    Team LinkedIn Profilesโ€‹

    Development Statusโ€‹

    We would like to use the Substrate template node

    Development Roadmapโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement create_invoice functionalityโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how create_invoice works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains how the decentralized invoice system works.
    0e.BenchmarkingBenchmarking will be provided for create_invoice.
    0f.Substrate module: create_invoiceWe will create a Substrate module that will create an invoice.

    Milestone 2 โ€” Implement show_all_invoices functionalityโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how show_all_invoices works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains how the decentralized invoice system works.
    0e.BenchmarkingBenchmarking will be provided for show_all_invoices.
    0f.Substrate module: show_all_invoicesWe will create a Substrate module that will show all the invoices.

    Milestone 3 โ€” Implement pay_invoice functionalityโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how pay_invoice works
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains how the decentralized invoice system works.
    0e.BenchmarkingBenchmarking will be provided for pay_invoice.
    0f.Substrate module: pay_invoiceWe will create a Substrate module that will pay an invoice.

    Future Plansโ€‹

    - + \ No newline at end of file diff --git a/applications/decentralized_well-being_game_api.html b/applications/decentralized_well-being_game_api.html index 574b212fa2a..cdd14545c1c 100644 --- a/applications/decentralized_well-being_game_api.html +++ b/applications/decentralized_well-being_game_api.html @@ -4,13 +4,13 @@ Decentralized Well-being Game API | Web3 Foundation Grants - +
    Skip to main content

    Decentralized Well-being Game API

    Team Nameโ€‹

    Health Hero

    Payment Addressโ€‹

    0xc7ad868f9b421dabf7cdaa0e6c508ff74e2f1cfd (USDT)

    Status: Terminated

    Overviewโ€‹

    Introductionโ€‹

    Well-being engagement is up and rising. With a more health-conscious generation of users, they are wanting to experience health engagement in different areas of their lives. Health Hero, as a digital health engagement company, seeks to grow a well-being focused game API that engages developers with health-related development tools. With more people now working remotely, health engagement has never been more important. Healthcare is a multi-billion dollar industry that still struggles with delivering tools to consumers to engage with their health in their own way. IoT, omnichannel, chatbots, and other interactive interfaces are just a few to mention for the opportunities surrounding the use of Health Hero's Game API.

    Project Detailsโ€‹

    The Health Hero Game API provides the opportunity for developers to build games, apps, and features using well-being data endpoints that are centered around steps and fitness data. The play-to-earn approach of the API endpoints, allows the users to earn points in different areas such as XP (Experience Points), HP (Hero Points), Levels, Life, Star Power, badges, and parcels of land that ultimately rewards the user with digital assets (collectibles/NFTs) that are valued in Polkadot currency and Using State Channels to send out the payouts to users from the treasury based on their authentic health data.

    API specifications of the core functionality

    1. Endpoints will provide the following data:
    2. IoT data: step trackers, to include Google Fit, Apple Health, Garmin, Fitbit, Peloton, Headspace, Calm, and more.
    3. Activity data
    4. Gamification data points such as XP, HP, levels, life, star power
    5. Smart contracts customization based on health data engagement

    Ecosystem Fitโ€‹

    Where and how does your project fit into the ecosystem? / What need(s) does your project meet?

    With the growing need of well-being engagement tools, a major pain point is the lack of shareability, access, and implementation of wellness-related features into games, apps, and other online applications. From the users' perspective, the delivery of gamification and rewards is also poorly present in today's games and apps ecosystems. Not only would the developers be able to create and build apps off of our API, but they will have the tools necessary to create customized smart contracts that will deliver a unique and evolving experience to the users based on their own health engagement within the app or game the developers created. These smart contracts will be used against the minting of personalized collectibles that will evolve with a series of attributes (XP, HP, levels, etc.) which are then translated into earnings (play-to-earn) for the users.

    Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

    • Game developers

    • Blockchain engineers

    • Cryptocurrency developers

    • In-house

    • Game artists

    Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

    • At the moment, there are no other projects similar to ours in any ecosystem.

    Teamโ€‹

    Team Membersโ€‹

    Team Leaders:

    • Umair Azhar (CTO)

    • Anthony Diaz (CEO)

    Team Members:

    • Angel Leon (Product and UX)

    • Jon Izquierdo (Senior Full Stack Engineer)

    Contactโ€‹

    Contact Name:

    • Anthony Diaz (CEO)

    Contact Email:

    Website:

    • gohealthhero.com

    Registered Address

    • Health Hero, Inc, 548 Market St, Suite 15351, San Francisco, CA 94104

    Registered Legal Entity

    • Health Hero, Inc

    Team's experienceโ€‹

    • Mr. Diaz has over a decade of experience in leadership in healthcare, global product and platform development, and digital consumer engagement. Repeat founder. People leader that commands an uncanny sense of global business and brings global products to life that generate profit.

    • Mr. Azhar is a software engineer with over 7 years of experience. Mr. Azhar has a passion for back-end development with great instinct for reflecting code on user interfaces and user experience, Artificial Intelligence, machine learning, innovative technologies, and development operations. Strong leader with a tactical vision on integrating latest technologies into highly complex products. Mr. Azhar has driven development efforts for large teams of engineers and has an acute eye for security, product, and technology architecture

    • Mr. Leon is a U.S. Navy veteran, product, operations, and innovation leader overseeing teams that manage revenue, strategy, business, partnerships, information technology, product management, policy, security, workplace resources, and other cross-functional operations. Angel's passion is on how to operationalize and productize integration technologies, patterns, best practices, and user interfaces. His experience includes a decade+ years in health IT, working with a wide spectrum of customers, including IDNs, payers, life sciences companies, and software vendors, with the goal of improving outcomes and reducing costs by aggregating and analyzing clinical, claims, and cost data.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Statusโ€‹

    Development Road Mapโ€‹

    Milestone 1 - Exposing Game API endpointsโ€‹

    Estimated Duration

    • 4 weeks

    FTE

    • 2

    Costs

    • $25,000 USD

    Purposed Diagramโ€‹

    Architecture Diagram

    State Channels Implementationโ€‹

    State Channels (2)

    NumberDeliverableSpecification
    0aLicenseApache License 2.0
    0bDocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can run a local instance and / or fetch metrics using the application.
    0cTesting GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0dDockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0ePress ReleaseWe will create a press release to inform the audience.
    1aInk Contract DevelopmentA contract with all required functions for service written in ink! In our ecosystem, smart contracts will be utilized in a variety of ways within the platform such as: To store user data smart contracts will need to be used via state channels for all aspects of the relationship between the data store and the user. Fitness games within the Ecosystem will utilize smart contracts to pay out and reward winners or games and challenges. A multi-signature smart contract will hold all DAO funds and payout based on milestones reached. Users will be rewarded for logging and tracking well-being through simple actions such as taking a picture of food, logging breakfast via smartwatches, or through slack.
    1bServices ImplementationAPI for developers to: 1. store user data to Postgres Database 2. serve API to users to collect the Health Data 3. interact with the Smart Contract 4. Written in Rust/TypeScript5. Rust/TypeScript unit tests
    1cState ChannelsWe will be implementing Perun Polkadot Pallet as a part of our Ink Smart Contract and will use RUST language for the backend implementing these state channels.These channels will allow us to make transactions to the users for their payouts from the treasury based on their authentic health data. As state channels will be established between treasury and users to handle frequently occurring transactions for their payouts
    - + \ No newline at end of file diff --git a/applications/deeper_network.html b/applications/deeper_network.html index 9b01fd7092a..fdf7539aba1 100644 --- a/applications/deeper_network.html +++ b/applications/deeper_network.html @@ -4,7 +4,7 @@ Deeper Chain | Web3 Foundation Grants - + @@ -20,7 +20,7 @@ Zhuang has a masterโ€™s degree in Electrical Engineering. He has working experience in network security, distributed system, and embedded system development.

    Yang Liu
    Yang worked at Bytedance, Alibaba, Windriver, and has working experience in cloud infrastructure, operating system and embedded system.

    Fei Yang
    Fei has been active in blockchain space since early 2017. He has worked as software engineer in blockchain startups, crypto exchanges and other blockchain project grants. He has led teams organised on the Internet to win a couple of blockchain hackathons.

    Team Code Reposโ€‹

    deeper-chain

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    In this application, the deliverables are the micropayment pallet, the client codes and tutorial document. The micropayment pallet contains all the necessary functions for a user to interact with the blockchain including open channel, close channel, claim micropayments etc. The client codes contains two parts: one is for a user to interact with blockchain, the other is for a user to interact with another user. The micropayment design, use cases as well as detailed examples will be given in the totorial document. In the next phases/applications, we will add Proof of Credit and light node discovery pallets as well as their corresponding client codes.

    M1: Micropayments โ€“ 4 weeksโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DescriptionFor our testnet, we use one-way micropayment protocol. There are 2 parties: Sender (Client) and Receiver (Server). There are 3 steps: Sender opens a channel; sender sends accumulated micropayments to receiver; Receiver closes a channel or the channel closed after expiration. When sending the accumulated micropayments, the sender will sign the following data: (receiver, address, nonce, sessionId, accumulateAmount). Each time a new (sender, receiver) channel is opened, nonce is increased by 1 to avoid replay attack. sessionId represents one unique session inside one channel. When a channel is open/active, it can contain multiple sessions. The receiver can only claim once for each unique (nonce,sessionId) pair.
    0c.Testing GuideThe tests will verify the basic functionalities like opening channels, sending micropayments, claiming payments, and closing channels. 1. Opening channels: verify that sender has enough balance to reserve and the channels are unique; 2. Sending micropayments: verify that receiver info and payment amount is correct, the payment is indeed signed by sender, and sender has enough reserved balance. Verify that micropayments are received in each service period; 3. Claiming payments: Verify that balance transfer is submitted on chain; 4. Closing channels: only receiver can close the channel. Clear any outstanding micropayment balances and free reserved balance of sender.
    0d.Language/FrameworkRust/Substrate
    0e.TutorialAdd tutorial documentation including blockchain setup, client setup. Add code examples to demonstrate the interaction between clients to blockchain, as well as clients to clients.
    1.Channel opensender who opens the channel should reserve enough funds for accumulated micropayments. Channel data structure contains sender, receiver, nonce (to avoid replay attack), expiration time.
    2.Channel closechannel will be closed after expiration time passed. Only the receiver can close the channel before the expiration time. The remaining amount which is not claimed by the receiver will be refunded to sender during close.
    3.Claim paymentsDuring the lifetime of the channel, the receiver can claim accumulated micropayments. The sessionId becomes invalid after claim, and the sender should start using a different sessionId for a different micropayment session.
    4.Client to BlockchainThe client inside a deeper device (light node) can automatically interact with blockchain: open channel (client only), close channel (server only), claim payment (server only), add balance (client only), and close expired channels (client only)
    5.Client to ClientThe client inside a deeper device (light node) can automatically interact with each other: start services, send micropayments, stop services.

    Future Plansโ€‹

    1. Light node discovery. Each deeper device is acting as a light node in deeper layer. There are potential millions of light nodes in p2p network. We need pairing light nodes with unbiased randomness and design discovery mechanism in a decentralized way.
    2. Proof of Credit is a core component in deeper network. We already have built MVP functions for PoC. But there are more work to be done.
    3. Testnet: Build an end to end blockchain system that running deeper devices smoothly.

    Additional Information โž•โ€‹

    What work has been done so far?โ€‹

    1. Code is open source at https://github.com/deeper-chain/deeper-chain
    2. MVP is developed for core features: micropayments(master branch), light node(master branch), delegated proof of credit(master branch).

    Have you applied for other grants so far?โ€‹

    We have applied for Substrate Builder's program and got accepted.

    - + \ No newline at end of file diff --git a/applications/deip.html b/applications/deip.html index 7915edd67fd..95010dfb2b3 100644 --- a/applications/deip.html +++ b/applications/deip.html @@ -4,7 +4,7 @@ DEIP IP Management/Governance Module | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    DEIP IP Management/Governance Module

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    DEIP builds an IP assets management platform which allows discovering, evaluation, and exchange of IP assets on the blockchain. It can be applied to any type of IP assets. The platform implements registration of IP assets on the blockchain, tokenization of IP assets, and governance of IP assets. With such infrastructure, DEIP becomes a foundation for DeFI and DAO around IP assets. In the future, DEIP will also provide a no-code/low code SDK to build custom Dapps for specific IP assets management cases (patents, art, movies, technologies, etc.).

    Integrationโ€‹

    DEIP is a Polkadot Parachain built on Substrate 2.0 Framework and designed specifically for IP governance, tokenization, and exchange. We see integration with Polkadot ecosystem as an important step towards a truly decentralized way to govern and exhange tokenized IP assets.

    Motivationโ€‹

    DEIP team has been building a solutions for tokenization and exhange of IP assets since 2017. We have a vision of a more innovative world where individuals and companies are able to push their innovations to market faster and with less expenses.

    We see Polkadot as a the best ecosystem for us to join. We believe that our protocol will be useful for other companies in the Polkadot ecosystem and even could drive adoption of both Polkadot and DEIP solutions.

    Project Detailsโ€‹

    DEIP IP Management/Governance (IPMG) Moduleโ€‹

    IPMG is a core module for managing technology assets, and assessment and evaluation of IP assets. It enables a collaborative approach in the creation and governance of IP assets via working groups as DAOs, advanced access control & sharing capabilities with Proof of Share. Furthermore, the IPMG module enables a collaborative assessment and evaluation of IP assets via a Decentralized Assessment System that allows to crowdsource expertise from the network. Working groups are managed as DAOs via specific smart-contracts that create delayed transactions with multi-sig to be executed.

    Within the scope of this grant we will implement a parachain and web-based UI with basic functionality for the management of working groups via DAOs, and governance and registration of IP on the blockchain. Core features to be implemented during this phase:

    • Management of working groups (creation, membership management, decision-making mechanisms (voting));
    • Creation of project(s);
    • Creation of IP asset(s) within a project;
    • Registration of IP asset(s) ownership on the blockchain with certification (a digital certificate that embeds a signature of IP asset creator, creation timestamp and hash of the certified IP asset);
    • Access control (with Proof of Share);
    • Ownership validation tool (a web-based tool used to verify the owner/creator of IP asset and creation timestamp using the provided certification data such as hash of IP asset or certified IP asset file);

    Technology stackโ€‹

    • Blockchain: Substrate + C++/Rust
    • Backend: Node.js + MongoDb
    • Frontend: Vue.js

    PoC/MVPโ€‹

    Live demo of the platform is available at https://demo.deip.world

    Ecosystem Fitโ€‹

    As far as our team knows there are no other projects working on IP governance, tokenization or exhange solitions within the Polkadot ecosystem.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Yahor Tsaryk - CTO, Project Lead, Blockchain Developer
    • Alex Shkor - Product director, Blockchain Architect
    • Alexey Kulik - System Architect
    • Euheny Bondarovich - Full-stack Developer

    Contactโ€‹

    • Registered Legal Entity: DEIPWORLD INC.

    Team's experienceโ€‹

    Yahor Tsaryk

    More than 7 years of experience Professional in front-end and backend development, Big Data and distributed systems.

    Alex Shkor

    An expert in blockchain architectures, crypto economies modeling and has more than 10 years of experience in designing distributed systems. He held executive positions in Paralect.com. Alex is thinktank member and expert at Blockchain for Science, and public speaker at various events (presentations in Vienna (Scientific Publishing on the Blockchain), Zurich (CRYPTSCIENCE2018), ETH Zurich). Author of articles about the distributed system, especially CQRS and Event Sourcing.

    Alexey Kulik

    Expert in software architectures and blockchain with 10 years of hands-on experience. Speaker on blockchain/DLT topics and lecturer at Belarusian National Technical University.

    Euheny Bondarovich

    Full-stack developer since 2004.

    Team Code Reposโ€‹

    The existing code is not fully open-sourced at the moment. DEIP team is fully commited to open-source the code and protocol in early 2021. We will provide access to our current GitLab repositories upon request from Polkadot team. All developments within the Polkadot Open Grants Program will be open-sourced from day one on GitHub.

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-time equivalent (FTE): 4.5
    • Total Costs: 1.21 BTC

    Milestone 1 Implement IP Management/Governance Moduleโ€‹

    • Estimated Duration: 2 months
    • FTE: 3.5
    • Costs: 0.94 BTC
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDocumentation describing the DEIP protocol and basic workflows implemented in the IPMG module.
    0c.Testing GuideComplete test-suite with acceptable unit-test coverage, and instructions how to run these tests.
    0d.DockerDEIP will provide a Docker file to start up a node for testing the functionality.
    1.Basic working group management (DAO)We need some way to minimally manage organizations because assets are owned by organization initially. We will implement a minimal needed governance operations for IP assets, but will also implement an adapter which will allow to connect DAO pallets in the future. ะก++/Rust
    2.Project and IP managementCreate project, edit project, create IP asset within project. C++/Rust
    3.IP registrationRegister (timestamp) a fact of creation and/or ownership of specific IP asset on the blockchain. C++/Rust
    4.Access controlManage access permissions to specific IP asset with unique Proof of Share entries that confirm a specific user was granted access to an asset. C++/Rust

    Milestone 2 Implement Web-base UI (Human Capital Tokeization Use-Case (Vedai))โ€‹

    • Estimated Duration: 2 months
    • Estimated Completion: End of January 2022
    • FTE: 1
    • Costs: 11000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationUser stories describing the use-case features and documentation with details on application stucture and DEIP modules used to built it.
    0c.Testing guideTesting guide on how to test functionality (described in user stories provided in 0b) of the web application delivered.
    0d.DockerDocker file to run both test node and Web-base UI for testing the functionality delivered within milestone #2.
    0e.ArticleDEIP will publish an article to explain the purpose, applications and functionality of the application implemented in the scope of this milestone. Article will be published on DEIP blog (Medium) as well as it will be shared in DEIP media channels (e.g. official Telegram channel with 20k members, Twitter, Facebook)
    1.Web-based UIManage working groups (DAOs), project management, IP asset creation and registration (tokenized Income Share Agreements). Vue.js & Node.js + MongoDb for web-based app backend

    Use-case descriptionโ€‹

    Vedai is an investment platform that enables companies and individuals to invest into coding bootcamp Income Share Agreement (ISA) programs and receive a share of the bootcamp profits in ISA returns. This novel investment mechanism allows to align incentives for all participants of the educational market and advance the development of global human capital.

    Future Plansโ€‹

    We are planning to continuusly evolve the project adding new modules and make a first decentralized exchnage for IP assets.

    IP Tokenization (IPT) moduleโ€‹

    IPT module enables securitization and tokenization of IP assets. It introduces advanced mechanics for the management of IP ownership, such as the distribution of shares of IP, co-ownership, and royalties distribution via smart-contracts.

    IP Financing (IPF) moduleโ€‹

    IPF module provides various models of funding and financing for projects that produce IP assets. Funding models include (but not limited to): crowd investing, private investing, grants, open innovation (OI) challenges.

    IP Licensing (IPL) moduleโ€‹

    IPL module enables the licensing of IP assets. Allows tracking of all licensing transactions and provides evidence of licensing. Various licensing agreements, instant licensing, proof of licensing, licensing transactions overview.

    IP Exchange (IPE) moduleโ€‹

    IPE module enables the exchange of IP assets. Any IP asset can be exchanged for any other IP asset on the platform, as well as it can be exchanged for various crypto assets (e.g. DOT, ETH, or BTC).

    Additional Information โž•โ€‹

    • What work has been done so far?

    We already have a working prototype and pilots.

    • Are there are any teams who have already contributed (financially) to the project?

    No

    • Have you applied for other grants so far?

    We have not applied for any other grants with this exact project. But we have applied for multiple grants related to the application of our Decentralized Assessment System (a system we designed for crowdsourcing of domain expertise to assess various IP assets). We are currently implementing pilots as part of Blockchers program, as well as part of EOSC Digital Innovation Hub.

    - + \ No newline at end of file diff --git a/applications/delightfuldot.html b/applications/delightfuldot.html index bbf269020ce..841a482c722 100644 --- a/applications/delightfuldot.html +++ b/applications/delightfuldot.html @@ -4,13 +4,13 @@ DelightfulDOT | Web3 Foundation Grants - +
    Skip to main content

    DelightfulDOT

    • Team Name: Coong Crafts (formerly Coong Team)
    • Payment Address: 15GJvMYDXXU5Xr795kP5VdsfccWS7Hcug5smWjN6gEELvWaT (AssetHub - USDT)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    1. Overviewโ€‹

    Dapps have always been a very important part of any blockchain ecosystem, it is where users can connect and interact with blockchain nodes. Given the complex nature of interacting with Substrate-based blockchains, in order for developers to focus on the business logic, a middle layer between dapps and blockchain nodes to facilitate the connections & interactions is always an essential part of the ecosystem and this is where @polkadot/api comes in.

    @polkadot/api has done a great job in helping applications connect to networks in an easy and effortless way by abstracting away all the complexities of connecting with a Substrate-based blockchain and scale-codec serialization process under the hood. But through development experience, benchmarking and profiling, we found out that @polkadot/api has a relatively high memory consumption, which might not be problematic for dapps that only connect to one or a few networks, but for dapps that need to connect to dozens or even hundreds of networks at the same time, itโ€™s a problem which might create a great impact on the overall user experience (e.g: a wallet app or portfolio app needs to connect to a large number of networks to fetch usersโ€™ balances & assets or to listen to on-chain events).

    • If we enable all 100+ Substrate networks on SubWallet, it could increase the memory consumption to over a GB of RAM.

      subwallet-high-memory-consumption

    • Talisman is having their own solution for connecting to networks and fetching balances effectively without relying on @polkadot/api (@talismn/balances, @talismn/api).

    • We ran a NodeJS script that connects to 100 substrate-based network endpoints to fetch balances for an account using @polkadot/api, and the average memory consumption is over 800MB. More details about the benchmark results could be found here.

    As weโ€™re heading toward a multi-chain future, there will absolutely be more parachains, parathreads or solochains built on Substrate to come, and users might have assets spreading over dozens or hundreds of networks. With that, we do see the need of connecting to a large number of networks at the same time effectively and efficiently, Coong Crafts propose to build delightfuldot, an alternative solution to @polkadot/api to address this issue in contributing to the whole effort of paving the way to a multi-chain future of the Polkadot & Kusama ecosystem.

    2. Project Detailsโ€‹

    2.1. Why does @polkadot/api has a high memory consumption?

    We ran memory profiling for a NodeJS script to connect to Polkadot network to see how much memory @polkadot/api consume during the bootstrapping process (initialization). Below are captures of the results:

    • Result of Allocation sampling profiling via Google Dev Tools

      image

    • Result of Allocation instrumentation on timeline profiling via Google Dev Tools

      image

    From the results, we can see that the memory consumption from Metadata and its type system is relatively high. As we looked into the source code itself, we found out that @polkadot/api has its own types and structure for every piece in the metadata, during the decoding process it will create types for all of the pieces in the metadata hierarchy/structure which result in the lot of Type objects and a big Metadata object (PortableRegistry is a part of the Metadata)

    We tried to build a small proof of concept alternative solution using scale-ts (now subShape) for scale-codec encoding/decoding to do the same functionality and the memory consumption has improved noticeably.

    image

    Going further, instead of connecting to 1 network, this time we tried to connect to 20, 50, and 100 network endpoints to fetch balances for an account using @polkadot/api and our PoC solution for comparison, and as we can see from the benchmark result, the memory consumption of our PoC solution is significantly smaller. More details about the benchmarking could be found in our PoC repository.

    2.2. Design Goals & Approach

    2.2.a. API style similar to @polkadot/api

    @polkadot/api is currently using an easy-to-use and intuitive API style (e.g: api.query.system.account(address) to query account balance, or api.consts.[pallet_name].[constant_name] to access constants of a pallet ...).

    So we decided to use the same API style so that users donโ€™t have to learn new syntax when switching to using delightfuldot and making the migration progress easier.

    2.2.b. Less overhead evaluation

    During the bootstrapping process, @polkadot/api will try to register all possible type definitions (ref1, ref2) and expose all available methods/props after decoding the metadata retrieved from a network (ref). This would help make the API execution faster but at the same time make the bootstrapping process longer and increase the overall memory consumption. Secondly, most of the dapps only use a few APIs and types (e.g: fetching balances, transfer balances or assets ...), so the registration of all of APIs and types would be unnecessary in most cases.

    delightfuldot's approach is to perform API evaluation and execution on the fly, which is at the time an API is called, delightfuldot will check if the API is existed or not, register all necessary types (and cache those types if possible for later usage), execute the API and then handle the response.

    For example, upon calling api.query.system.account('5xxxxx...') to fetching balances for an account, delightfuldot will do the following steps:

    • Check if the pallet named System is existed in the metadata, else throw an error.
    • Check if the storage entry named Account is existed in the pallet System in the metadata, else throw an error.
    • Gather all the necessary information to perform a storage query through an RPC state_getStorage like input types, output type, calculate storage entry hash โ€ฆ
    • Execute RPC state_getStorage with the calculated storage entry hash
    • Decode the response with the output type and return the decoded data.

    Unlike @polkadot/api where the first 2 steps are already done in the bootstrapping process. We believe that our approach would help speed up the bootstrapping process and reduce the overhead memory consumption. We archived this by using a proxy technique, you could find more in detail about it in the PoC repository.

    2.2.c. Caching

    Metadata has always been an important part of any Substrate-based blockchain, itโ€™s where we can find all information about on-chain functionalities (pallets, storage, extrinsics, constants, โ€ฆ), but it takes time to encode the metadata retrieved from networks and take space in the memory to store all of the information after decoding the metadata.

    Since Metadata is only updated through runtime upgrades, so delightfuldot will cache the decoded metadata information in the deviceโ€™s storage (localStorage, IndexedDB, โ€ฆ) and only check to update it on runtime upgrade. This would also help speed up the bootstrapping process and reduce memory consumption since the metadata is now stored on the deviceโ€™s storage.

    One drawback of this approach is that access speed to storage would be a bit slower than to memory, but given the benefits of the approach, we believe the tradeoffs are acceptable.

    2.3. Vision

    We set a vision for delightfuldot to become an essential part of Polkadot & Kusama ecosystem, so dapps can leverage its utilities to connect to and interact with hundreds of networks quickly and smoothly without having to think about memory consumption.

    This proposal is asking for a grant to support the first development phase of delightfuldot for the foundational modules with core functionalities. More details are in the upcoming section.

    2.4. Foundational modules with core functionalities

    This step, we aim to lay out all the necessary foundational pieces of the library and put all of them together to form the core functionalities, including:

    • New type system built on top of scale-ts (now subShape) with less memory consumption while at the same time can easily switch to use @polkadot/api's type system for easy migration from existing dapps.
    • A metadata parser with abilities to decode & encode Metadata using scale-codec. In the scope of this grant, we plan to support the latest version of metadata which is v14.
    • Ability to execute RPCs to a Substrate-based node
      • Each blockchain has its own custom list of supported RPCs, in the scope of this grant we plan to implement the supported RPCs of Polkadot & Kusama networks.
      • Support registering custom RPCs, so developers can easily add custom RPCs for their custom substrate node.
    • Ability to execute Runtime APIs
      • Similar to RPCs, each substrate-based blockchain has its own list of supported Runtime APIs, so in the scope of this grant, we plan to implement the supported Runtime APIs of Polkadot and Kusama networks.
      • Support registering custom Runtime APIs
    • With the format of Metadata V14, on-chain functionalities are exposed through palletโ€™s definitions including palletโ€™s constants, storage entries, extrinsic calls, events & errors. We plan to support abilities to:
      • Inspect palletโ€™s constants (similar to @polkadot/api APIs to inspect constants)
      • Inspect palletโ€™s events & errors (similar to @polkadot/api APIs to inspect events & errors)
      • Execute palletโ€™s storage queries (similar to @polkadot/api APIs to execute storage queries)
      • Sign and submit extrinsics (similar to @polkadot/api APIs to sign & submit extrinsics)

    The work will be focused on building APIs to facilitate interactions with Substrate-based blockchain nodes, therefore we'll leverage existing solutions for creating, managing & signing keys in @polkadot/keyring package as well as other cryptography & utility functions in @polkadot/util-crypto, @polkadot/util.

    2.5. Tech Stacks

    • TypeScript
    • scale-ts (now subShape), rxjs
    • Helpful packages from @polkadot/api, @polkadot/common

    Ecosystem Fitโ€‹

    delightfuldot fits perfectly in the Polkadot & Kusama ecosystems as it provides a solution to a critical issue faced by dApps that need to connect to and interact with hundreds of networks efficiently & effectively. Any dApps (e.g wallet apps, portfolio apps, ...) that need to connect to a large number of networks can benefit from delightfuldot's utilities.

    We as the maintainer of Coong Wallet see that delightfuldot is a stepping stone to the next development phase of Coong Wallet with more & more useful features in which Coong Wallet would need to connect to a large number of Substrate-based networks to fetching & syncing information.

    Aside from @polkadot/api, capi is another project to help craft interactions with Substrate-based blockchain, but at the time of writing this proposal, itโ€™s going through a big restructuring, weโ€™re not sure what would it look like until its shape be more concrete. Overall we donโ€™t see any noticeable projects that are trying to solve the same problems as us.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Thang X. Vu (Team Leader)
    • Tung Vu

    Contactโ€‹

    N/A yet

    Team's experienceโ€‹

    Coong Crafts is a small team set out with a mission to bring Web3 closer to the world. We previously completed a grant to build Coong Wallet (PR), a website-based wallet solution to address the inconsistent wallet experience on mobile & desktop and bring a new approach to onboard new users to Polkadot & Kusama ecosystem.

    Team Code Reposโ€‹

    Project repositories will be hosted at https://github.com/CoongCrafts

    Team members

    Development Status ๐Ÿ“–โ€‹

    • We have been in research the @polkadot/api project to learn how it works under the hood as well as doing benchmarking & profiling to figure out why it has a high memory consumption.
    • We have been building a proof-of-concept solution in an attempt to address the memory issue and saw a clear/good improvement.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3.5 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 30,000 USD

    Milestone 1 โ€” Foundational modules with core functionalitiesโ€‹

    • Estimated duration: 2 months
    • FTE: 2
    • Costs: 17,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to install delightfuldot and interact with Substrate-based networks.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.Core functionalitiesWe'll build the following features for the library:
    - New type system built on top of scale-ts
    - A Metadata parser for the Substrate Metadata V14
    - RPC APIs: Support default RPC APIs for Polkadot and Kusama networks & ability to add custom RPC APIs
    - APIs to inspect pallets' constants
    - APIs to execute pallets' storage queries
    - APIs to inspect pallets' events & errors
    2.Publish to npmWe'll package and publish the library to npm, so developers can install and start using it.

    Milestone 2 - More core functionalitiesโ€‹

    • Estimated Duration: 1.5 months
    • FTE: 2
    • Costs: 13,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to sign & submit extrinsics via delightfuldot and the migration process from @polkadot/api to delightfuldot
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.More core functionalitiesWe'll continue to build core functionalities for the library:
    - APIs to create Extrinsics payload, sign and submit Extrinsics as well as the ability to keep watching for Extrinsic status after submission.
    - Runtime APIs: Support default runtime APIs for Polkadot and Kusama networks & ability to add custom Runtime APIs

    Future Plansโ€‹

    Next steps for delightfuldot are:

    • Support APIs to interact with Smart Contract
    • Support older/newer versions of Metadata
    • Support more RPC and Runtime APIs
    • XCM utilities
    - + \ No newline at end of file diff --git a/applications/delmonicos.html b/applications/delmonicos.html index ca5a81886db..271cbaab06c 100644 --- a/applications/delmonicos.html +++ b/applications/delmonicos.html @@ -4,7 +4,7 @@ Delmonicos | Web3 Foundation Grants - + @@ -90,7 +90,7 @@ technology by allowing the secure digitalisation of assets (charging power, money and identity) and the secure conversion of value between these assets. Our potential partnerships with actors mentioned above will give us direct access to the market.

    - + \ No newline at end of file diff --git a/applications/distributed_cryptography_for_polkadot_wallets.html b/applications/distributed_cryptography_for_polkadot_wallets.html index a0a2061705c..93e81de98ba 100644 --- a/applications/distributed_cryptography_for_polkadot_wallets.html +++ b/applications/distributed_cryptography_for_polkadot_wallets.html @@ -4,13 +4,13 @@ Distributed Cryptography for Polkadot Wallets | Web3 Foundation Grants - +
    Skip to main content

    Distributed Cryptography for Polkadot Wallets

    • Team Name: PolyCrypt GmbH
    • Payment Address: 0x308Ca526B009e10Ef0482C38A3370BFb44A32908 (DAI)
    • Level: 3

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Cryptocurrency wallets are a highly attractive target for cyberattacks. An attacker that breaks into a wallet gets access to secret keys, thereby gaining full control over the user's funds. Many examples illustrate that hacks of cryptocurrency wallets are one of the major security threats for blockchain users. For example, in the recent security breach of the popular atomic wallet, hackers allegedly stole over $100 M worth of cryptocurrency from users of the atomic wallet.

    The overall goal of this project is to develop a cryptographic library to protect Polkadot wallets against cyberattacks. This will be done via threshold cryptography. Threshold cryptography is an emerging technology that can significantly strengthen the security of cryptocurrency wallets. The main idea is to share the secret key over multiple entities/devices, thereby making it much harder for an attacker to gain control over the userโ€™s funds. There has recently been a lot of interest in academia and industry in designing new threshold cryptographic schemes that come with additional security features and offer better efficiency [1,2,3]. Some of these schemes (or variants thereof) are currently deployed in both custodial and shared custodial wallets (e.g., Fireblocks or ZenGo). Most research and implementation of threshold signatures focus on the ECDSA signature scheme. This is because ECDSA is widely used by the two largest cryptocurrencies Bitcoin and Ethereum. In our project, we will focus on the Schnorr signature scheme, which is the main signature scheme used by the Polkadot ecosystem.

    Concretely, we will develop a library that allows to thresholdize BIP32 wallets. BIP32 is a wallet standard that is widely deployed in practice and offers deterministic and hierarchical key derivation. Members of our team have previously designed a threshold BIP32 protocol for the ECDSA signature scheme [4]. In the first phase of this multi-phase grant, we will adapt our threshold BIP32 scheme for Schnorr signatures that are used by Polkadot (i.e., the Schnorrkel/Ristretto). We will summarize our results as white paper that will include a full technical description of our scheme and a rigorous security analysis. We will also give advice on implementing our scheme to avoid common security incidents (e.g., missing range checks or zero knowledge proofs). Finally, we will disseminate our results via a medium article and if suitable through a publication at an academic conference (e.g., Financial Crypto, ACM CCS,...).

    Over the past years, our group has carried out intensive research on threshold cryptography and cryptographic wallets [4,5,6]. With this project, we hope to see some of our research deployed and integrated in practice. Threshold cryptography has many fascinating applications for blockchain systems, and we hope that with this project we can contribute to this emerging field. We choose to focus on thresholdizing cryptographic wallets for two reasons. First, most of our prior research has been on this topic. Second, cryptographic wallets are a fundamental building block that is crucial for any blockchain application (DeFi, staking, gaming,...). Moreover, we have previously talked to researchers at web3/Polkadot, who encouraged us to apply for a grant on this topic.

    Project Detailsโ€‹

    As mentioned above, in this grant we will research threshold cryptographic wallets. We will not develop code at this stage of the project (see the section on Future plans for more details on this), but instead deliver a white paper describing our new cryptographic scheme (including its formal security analysis). Moreover, this white paper will contain a specification that will be a solid basis to enable developers implementing our wallet scheme. Our research in this proposal is mainly based on our prior work on the ECDSA BIP32 wallets [4,5,6]. Let us briefly describe our prior work relevant to this project below.

    In [5,6], we provide the first rigorous security analysis of the BIP32 standard. BIP32 has two main features. First, it offers a deterministic key derivation, where session secret keys are derived via an additive key derivation function from a master secret key. Second, BIP32 offers support for key hierarchies, which are particularly important for larger organizations managing cryptocurrency funds. Hierarchical key derivation also offers two types of wallets: hardened and non-hardened nodes. Hardened nodes offer better security as corrupting the secret keys assigned to such nodes does not affect the security of other nodes in this key hierarchy. The figure below gives a graphical representation of a BIP32 hierarchical wallet.

    bip32-hierarchical-wallets

    In our research work published at the academic conference ACM CCS 2021, we propose a formal security model for hierarchical deterministic wallets. We define two security properties called wallet unforgeability and wallet unlinkability. The first says that funds cannot be stolen as long as the secret keys remain secure. We also integrate hardened node corruption, where the attacker is allowed to learn the secret keys assigned to a hardened node of its choice. The unlinkability property is a privacy feature and guarantees that individual wallets derived from the same master key are unlinkable. Finally, we show that the BIP32 standard satisfies wallet unforgeability and unlinkability. The analysis in our prior work [4] only shows these security features for the ECDSA signature scheme. For further details on BIP32, we refer to the description in our paper [6].

    The second work that is relevant for this grant application is our work on thresholdizing BIP32 [4]. We propose a cryptographic protocol for thresholidzing the ECDSA BIP32 wallet. We also give a security model and formally analyze the security of our cryptographic scheme within this model. A key insight of our work is that by slightly adjusting the BIP32 standard, we can offer significantly better efficiency. To this end, we rely on a threshold verifiable random function (TVRF) and show that for an appropriately chosen TVRF, we can seamlessly integrate it with an ECDSA threshold signature scheme.

    At a high level, this project will combine the results from [4] and extend them to work with the Schnorr signature scheme used within the Polkadot ecosystem. Our work consists of a theoretical and more applied component. On the more conceptual/theoretical side, we will select an appropriate threshold scheme for Schnorr that is compatible with the Schnorrkel/Ristretto environment and offers overall good efficiency. We will design the protocols for threshold Schnorr BIP32. Moreover, we will investigate if our threshold TVRF idea from [4] can also be applied for Schnorr signatures. If this is not the case, we will seek alternatives (e.g., using efficient multiparty computation to evaluate the hash function of BIP32). Finally, we will deliver a security argument for our scheme following the approach from our prior research. On the more applied side, our white paper will contain a specification for developers (with background in cryptography) to implement the key components of our proposal. We provide more details on the tasks carried out in this project as part of the development roadmap.

    Ecosystem Fitโ€‹

    There is a large number of wallets supporting the Polkadot/Kusama ecosystem. While there exist general purpose wallets such as ZenGo that use threshold cryptography to secure funds, there is a large number of Polkadot/Kusama specific wallets that currently do not offer their users support for threshold cryptography (e.g., PolkaWallet). With threshold cryptography, our project meets the urgent need to offer better security to every user in the Polkadot/Kusama ecosystem. This is achieved without inducing additional blockchain fees as unlike multisignatures, threshold signatures produce standard Schnorr/ECDSA signatures that can be verified against a single public key. The results of the first phase of this project can be used by developers to integrate threshold cryptography in their products/wallets. Moreover, it forms the basis for our own software library that we could implement in a follow-up grant.

    As mentioned above, there are multiple projects that build general purpose wallets leveraging threshold cryptography (e.g. ZenGo or Coinbase as a distributed custodial wallet). We are not aware of any Substrate / Polkadot / Kusama dedicated project that works on threshold wallets. Moreover, even existing solutions in the wider blockchain ecosystem will not offer the features that we aim to achieve in this project since our work is based on recent research from members of our team. In particular, except for our own prior work [4], we are not aware of any threshold BIP32 scheme โ€“ in particular, there currently does not exist any variant that is compatible with the Schnorr signature scheme.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Team members are listed in alphabetical order:

    • Hendrik Amler: Hendrik is a co-founder and CEO of PolyCrypt. He holds a Master degree in IT Security from the Hochschule Darmstadt.
    • Jan Bormet: Jan is a Master student of Computer Science at the Technical University of Darmstadt. He is currently finishing his Master thesis on threshold cryptography and is a core developer at PolyCrypt.
    • Andreas Erwig: Andreas finished his PhD degree in Applied Cryptography at the Technical University of Darmstadt in July 2023. His research focuses on the security of cryptographic wallets. He is co-author of most prior work mentioned in this proposal.
    • Sebastian Faust: Sebastian is a professor of Computer Science at the Technical University of Darmstadt. He leads the Applied Cryptography Group which focuses on cryptography for blockchain applications. He is a co-inventor of the Perun protocols and has published more than 70 academic papers at leading venues for research in cryptography and IT Security. He is co-founder and research lead at PolyCrypt.

    Contactโ€‹

    • Registered Address: HilpertstraรŸe 31, 64295 Darmstadt, Trakt C, Germany
    • Registered Legal Entity: PolyCrypt GmbH, Handelsregister Darmstadt HRB 101219, VAT DE339864467

    Team's experienceโ€‹

    The team has extensive experience in the design and analysis of cryptographic protocols and blockchain technology. Members of the team have co-invented the Perun state channel protocols [7,8,9], which have been published at the leading venues for research in IT Security and cryptography (ACM CCS, IEEE S&P and Eurocrypt). The Perun state channels are implemented for several major blockchain ecosystems including Ethereum, Polkadot and Cardano. Most important for this project is the teamโ€™s prior work on analyzing and designing cryptographic wallets [4,5,6,10]. Members of the team designed the first formal model for deterministic wallets [5], devised wallets with post-quantum security [10] and provided the first security analysis of the BIP32 standard [6]. The team also has extensive experience in threshold cryptography [4,11,12].

    PolyCrypt is a spin-off of the Technical University of Darmstadt that is a specialized technology provider for research in blockchains and cryptography. The current product portfolio of PolyCrypt includes the blockchain agnostic state channel framework Perun (https://perun.network) and a TEE-based second-layer solution called Erdstall (https://erdstall.dev). PolyCrypt also offers consulting services in topics such as anonymous credentials, threshold cryptography and privacy preserving technologies. Customers include major European technology companies and leading blockchain ecosystems.

    PolyCrypt has strong prior expertise in the Polkadot ecosystem and was already funded by the web3 foundation in the past. It has developed a Polkadot backend for Perun state channels and various extensions for it (https://grants.web3.foundation/applications/perun_channels, https://grants.web3.foundation/applications/perun_channels-integration, https://grants.web3.foundation/applications/perun_app_channels). Moreover, we are currently collaborating with Ajuna (https://ajuna.io/) to build a second-layer solution on Polkadot for the gaming industry.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Google Scholar Profiles (Or other research indexer profile, ex. Researchgate)โ€‹

    Development Status ๐Ÿ“–โ€‹

    As discussed above, the team has extensive research experience in cryptographic research and engineering cryptographic/blockchain protocols. Relevant for this project is our own prior research on cryptographic wallets and threshold cryptography:

    Moreover, Andreas Erwig and Sebastian Faust were in contact with cryptographic researchers at web3. In particular, we had several calls with Handan Kilinc Alper and Jeff Burdges on topics related to this proposal. Andreas Erwig also gave a talk on cryptographic wallets in the research seminar of the web3 crypto team.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 7.25 months
    • Full-Time Equivalent (FTE): 1.25 FTE
    • Total Costs: 87,000 USD

    This is mostly a basic research project and hence a detailed development plan is difficult to give. We will make all results publicly available through a whitepaper that we plan to publish on an archive (e.g., the cryptology eprint archive or arxiv.org). Moreover, if suitable, we will publish the results of our research (or parts of it) via a publication at an academic conference (e.g., Financial Crypto or ACM AFT). We will further disseminate the results of our project via a medium article on our webpage (https://medium.com/perunnetwork). This article will be less technical and highlight our main findings for a broader audience.

    Based on our previous experience with publicly funded research projects, we plan the following main tasks and milestones. Notice that the description slightly deviates from the application template as it is not planned to deliver code in this project.

    Milestone 1 โ€“ Research on cryptographic algorithmsโ€‹

    • Estimated duration: 1.5 months
    • FTE: 1.25 FTE
    • Costs: 18,000 USD
    NumberDeliverableSpecification
    1.0a.Copyright and LicensesCC BY 4.0
    1.0b.Documentation/TutorialAs we do not plan on delivering code we will not provide documentation in that sense. The delivered report at the end of this milestone will serve as documentation.
    1.0c.MethodologyThis milestone will be achieved mainly by compiling and reading relevant literature as well as internal talks and discussions. We may involve interviews with external parties such as web3 researchers and/or wallet developers, specifally for Task 1.2. Our results can be verified through the report delivered in this milestone.
    1.0d.InfrastructureWe expect that all our work and deliverables for this milestone can be reviewed and understood without need for specific infrastructure or software except from a web browser.
    1.0e.ArticleWe will deliver a short report that contains a list of academic papers that we studied and a discussion on which cryptographic schemes are most suitable for our goal of building Threshold BIP32 wallets for Schnorr. The report will contain the results from Tasks 1.1 to 1.3. The report is mainly for internal use and hence will be approx. 2 pages. We will make sure that the report is easiliy accessible to the reviewers and the community.
    1.1.Investigation into threshold Schnorr protocolsWe will investigate the current state of the art in threshold Schnorr protocols that are suitable to work with the Schnorrkel/Ristretto environment. We will evaluate them according to efficiency (round complexity, communication complexity) and security. For the latter, important criteria are: (1) static vs. adaptive corruption, (2) corruption threshold, (3) robustness, (4) cryptographic assumptions and models (e.g., only RO vs. AGM).
    1.2.Identification and prioritization of desirable featuresWe will research and discuss the priority and importance of specific efficiency and security features for our application (wallets). If necessary, we may involve interviews with external parties such as web3 researchers and/or wallet developers.
    1.3.TVRFs for threshold Schnorr walletsWe will investigate if existing protocols for TVRFs are compatible with the threshold Schnorr protocols from Task 1.1. We will classify them according to the criteria mentioned for Task 1.1.

    Milestone 2 โ€“ Design of the basic Threshold BIP32 wallet for Schnorrโ€‹

    • Estimated Duration: 1.5 months
    • FTE: 1.25 FTE
    • Costs: 18,000 USD
    NumberDeliverableSpecification
    2.0a.Copyright and LicensesCC BY 4.0
    2.0b.Documentation/TutorialAs we do not plan on delivering code we will not provide documentation in that sense. The delivered report at the end of this milestone will serve as documentation.
    2.0c.MethodologyThis milestone will be achieved mainly by reading relevant literature as well as internal research discussions. We will make use of our experience and prior work regarding Threshold BIP32 wallets.
    2.0d.InfrastructureWe expect that all our work and deliverables for this milestone can be reviewed and understood without need for specific infrastructure or software. Access is possible via a web browser.
    2.0e.ArticleWe will deliver a report that contains: (1) a description of the security model and definitions, (2) the pseudocode of the cryptographic scheme from Task 2.2 and (3) a brief discussion on the security of our protocol. The article is still mainly for internal use and will be extended during the next tasks. We will make sure that the report is easiliy accessible to the reviewers and the community.
    2.1.Security ModelWe will develop a security model to rigorously analyze Threshold BIP32 wallets for Schnorr. Most likely, this task will be rather easy as the model will be similar to what we have done in our prior works. We will start to sketch the model and security definitions in our report. These definitions may later be adjusted depending on the final scheme.
    2.2.Protocol DesignWe will design the basic protocol for Threshold BIP32 wallets for Schnorr. We will either base our novel protocol on an existing Schnorr threshold scheme or design a threshold Schnorr scheme that is particularly tailored for our use case. We will give a pseudocode description of the protocol as common in cryptographic research.
    2.3.Protocol EvaluationWe will evaluate our basic protocol with respect to security and efficiency. We will not deliver a full security analysis here as the final protocol may still change during later phases of the project.

    Milestone 3 โ€“ Extensions for efficiency and securityโ€‹

    • Estimated Duration: 2 months
    • FTE: 1.25 FTE
    • Costs: 24,000 USD
    NumberDeliverableSpecification
    3.0a.Copyright and LicensesCC BY 4.0
    3.0b.Documentation/TutorialAs we do not plan on delivering code we will not provide documentation in that sense. The delivered report at the end of this milestone will serve as documentation.
    3.0c.MethodologyThis milestone will be achieved mainly by reading relevant literature as well as internal discussions. We will make use of our experience and prior work regarding Threshold BIP32 wallets. We will involve external experts and potential users of our wallet scheme, especially for Task 3.2.
    3.0d.InfrastructureWe expect that all our work and deliverables for this milestone can be reviewed and understood without need for specific infrastructure or software. Access is possible via a web browser.
    3.0e.ArticleWe will extend our report with: (1) the full specification of the Threshold BIP32 protocol for Schnorr signatures and (2) a discussion on why we decided on a particular threat model (see Task 3.2). The report is still mainly for internal use and will be extended during the next tasks.
    3.1.Efficiency ImprovementsIn this task, we will focus on efficiency improvements. Most importantly, we will explore the combination with a TVRF as done in our work on ECDSA. If feasible, this will significantly reduce communication and computation complexity. We will also investigate if techniques for de-randomizations can be integrated into our wallet scheme.
    3.2.Stronger Security ModelIn this task, we will investigate stronger security models. In particular, our current construction for ECDSA only supports static corruption. We will explore if this can be strengthened to resist active corruptions. We will also explore various choices for the corruption threshold and what impact it has on efficiency. Finally, we want to investigate the pro-active setting as it can be used for key updates (e.g., in case of key loss or when the threshold is adjusted). We will decide which of these extensions will be integrated into the final specification. Our decision is based mainly on efficiency/practicality concerns as well as input from external experts and potential users.

    Milestone 4 โ€“ Security analysisโ€‹

    • Estimated duration: 1.5 months
    • FTE: 1.25 FTE
    • Total Costs: 18,000 USD
    NumberDeliverableSpecification
    4.0a.Copyright and LicensesCC BY 4.0
    4.0b.Documentation/TutorialAs we do not plan on delivering code we will not provide documentation in that sense. The delivered report at the end of this milestone will serve as documentation. While there is no code or code documentation, we will deliver implementation considerations for developers as part of this milestone.
    4.0c.MethodologyThis milestone will be achieved mainly by compiling and reading relevant literature as well as internal discussions. We will make use of our experience and prior work regarding Threshold BIP32 wallets.
    4.0d.InfrastructureWe expect that all our work and deliverables for this milestone can be reviewed and understood without need for specific infrastructure or software. Access is possible from a web browser.
    4.0e.ArticleWe will extend our report with the security analysis. We will also add an overview of common challenges when implementing threshold cryptography and how to mitigate these attacks.
    4.1.Security AnalysisWe will do a security analysis and a security proof of our construction. The exact threat model and assumptions are based on our work from Milestone 3. We will update the report with a security analysis/proof of our scheme.
    4.2.Implementation ConsiderationsWe will do research on secure implementations of threshold signature schemes and discuss common pitfalls. There have been multiple incidents in implementations of threshold ECDSA (e.g., missing range checks and validity checks), and we will investigate if similar problems may arise in implementations of our selected threshold Schnorr scheme and our wallet scheme.

    Milestone 5 โ€“ Finalizing and publication of white paperโ€‹

    • Estimated duration: 0.75 months
    • FTE: 1.25 FTE
    • Costs: 9,000 USD
    NumberDeliverableSpecification
    5.0a.Copyright and LicensesCC BY 4.0
    5.0b.Documentation/TutorialAs we do not plan on delivering code we will not provide documentation in that sense.
    5.0c.MethodologyWe will achieve this milestone by compiling and polishing the results from all previous milestones.
    5.0d.InfrastructureWe expect that all our work and deliverables for this milestone can be reviewed and understood without need for specific infrastructure or software. Access is possible from a web browser.
    5.0e.ArticleWe will complete the final report and publish it on an archive server. We will prepare a summary article and publish it on our medium blog. If suitable, we will also prepare an academic publication. All articles will contain the following statement in an acknowledgments section: This work was supported by a research grant from the Web3 Foundation.
    5.1.Whitepaper & Academic PublicationWe will polish the report and release it as a white paper on a suitable archive (e.g., the eprint archive or arxiv.org). If suitable, we will also prepare an academic publication.
    5.2.Medium ArticleWe will write a medium article that summarize our findings for a broader audience and release it on https://medium.com/perunnetwork

    Future Plansโ€‹

    We will promote our research results with companies building and running wallets within the Polkadot ecosystem. Moreover, we plan to continue our work in the following directions:

    • Once the research is completed, we plan to work on the implementation of our cryptographic protocol and offer it as an open source SDK. We hope to fund this via a follow-up grant from the web3 foundation.
    • Based on our SDK, we plan integration projects with wallet providers in the Polkadot / Kusama ecosystem.
    • We also plan to run multiple threshold servers, where users may outsource parts of their key shares to. This will be offered as part of a freemium service, where the basic functionality is provided for free but extensions (e.g., better usability, key recovery features, support of key hierarchies etc.) may be purchased by the user.

    Finally, we believe that our research on threshold Schnorr signatures may have applications outside of wallets, e.g., to secure the consensus protocol of modern blockchains.

    Additional information โž•โ€‹

    We were referred to the web3 grant program by web3 cryptographic researchers (Handan Kilinc Alper and Jeff Burdges). We have already successfully completed multiple web3 grants on the Perun state channel framework and are currently collaborating with Ajuna to build a second-layer solution for the Polkadot gaming industry.

    - + \ No newline at end of file diff --git a/applications/dora-factory-molochdao-v1-v2.html b/applications/dora-factory-molochdao-v1-v2.html index bf4fa9bca5c..17970fdb987 100644 --- a/applications/dora-factory-molochdao-v1-v2.html +++ b/applications/dora-factory-molochdao-v1-v2.html @@ -4,13 +4,13 @@ Quadratic Funding Pallet | Web3 Foundation Grants - +
    Skip to main content

    Quadratic Funding Pallet

    • Project Name: Build MolochDAO v1 and v2 on Substrate
    • Team Name: Dora Factory
    • Payment Address: 0xadcba9C5C8c33F7F71600c436F2F2B00bAbc9997

    Project Overviewโ€‹

    MolochDAO is the mostly used venture DAO template so far, hosting major venture & grant DAOs such as MolochDAO, The LAO, and MetaCartel Ventures. This project implements MolochDAO v1 on a Substrate pallet. The goal of this project is to eventually launch a MolochDAO for Polkadot ecosystem grants.

    Overviewโ€‹

    MolochDAO was conceived after the fail of The DAO -- the first pioneering effort to support Ethereum ecosystem projects. After The DAO failed, MolochDAO revived the idea of The DAO but with simplicity and security. The MolochDAO itself is a minimum viable DAO, which implemented a concise set of mechanisms including proposal submission, voting, and ragequit. It has been operating safely for some time, and currently hosting more than $6 Million to support Ethereum ecosystem projects with grants.

    The open-source approach of MolochDAO has encouraged many other efforts. For example, The LAO (https://www.thelao.io/) and MetaCartel Ventures are using Moloch as an infrastructure to build DAO venture funds. Together, they are managing more than $50 Million worth of assets at this moment of writing. DAOhaus, on the other hand, creates a platform to create DAOs based on Moloch. It allows different types of organizations to create Moloch-like DAOs on Ethereum to manage its funds. The Open Law team is also developing a MolochV3 codebase (https://github.com/openlawteam/molochv3-contracts), which aims to break Moloch main contract into smaller smart contracts, and bring modularity to Moloch.

    Currently, there are two mature versions of MolochDAO that are widely accepted -- the MolochDAO v1 and the MolochDAO v2. MolochV2 has some major features on top of MolochV1, including 1) multiple tokens in guild bank; 2) loot and shares; 3) guildkick.

    This project develops a substrate pallet that implmenets MolochDAO v1 and v2, in two separate milestones. The goal of this project is to bring MolochDAO to Substrate and make it available for future DAOs on Polkadot, Kusama, and other parachain ecosystems.

    Dora Factory and DoraHacks team is building tools and infrastructures to incentivize / fund open source blockchain innovation. Therefore, one of the first use cases of a Substrate MolochDAO can be a grant DAO to support open source developer projects that build on Substrate. It is yet another alternative to the current funding schemes.

    Project Detailsโ€‹

    The MolochDAO is an open source project.

    MolochDAO v1 codebase can be found here: https://github.com/MolochVentures/moloch/tree/master/v1_contracts

    The current MolochDAO (V2) codebase can be found here: https://github.com/MolochVentures/moloch

    This project will implement MolochDAO v1 and v2 in two milestones. The first milestone is to create a Substrate pallet that implements MolochV1, and the second milestone is to create a Substrate pallet that implements MolochV2.

    The MolochV1 Substrate pallet will implement features including the following:

    • Guild bank
    • Guild shares
    • Submit a proposal
    • Vote for a proposal
    • Process a proposal
    • Ragequit

    The MolochV2 Substrate pallet will be built on top of MolochV1 and further implement features including the following:

    • Support multiple tokens in guild bank
    • Implement loot
    • Guild kick
    • Ragekick

    In this grant, we will not change the mechanism or logic of the original design of Moloch v1 and v2, because of its simplicity and security. However, we recognize the importance of building Moloch in the Polkadot ecosystem as an incentive mechanism and open source DAO infrastructure that can be used in many use cases.

    With an implementation of Moloch v1 and v2 on Substrate, developers from the whole Polkadot ecosystem can build DAOs or other applications based on the code, such as DAO venture funds, parachain grant programs, clubs, project governance bodies, etc.

    A Substrate implementation of Moloch can allow us to make Moloch more useful. For example, managing cross-chain assets or adding application-level features can be made easier on a Substrate-based Moloch implementation. Therefore, after completion of this grant, we can start to build a more general DAO infrastructure based on the codebase, which could evolve into an open platform for DAOs, and every blockchain based organization can use it to support on-chain governance and open source ventures. However, it will depend on a successful delivery of the current grant.

    Ecosystem Fitโ€‹

    Since quadratic funding is a community driven funding mechanism for early-stage grants, it will introduce a more community-driven method to fund developer community projects in the Polkadot and Kusama ecosystem.

    It's also exciting to implement quadratic funding as an on-chain governance module and add it to Polkadot governance stack.

    MolochDAO is the most important open source DAO template in Ethereum ecosystem at this moment. It supports grant DAOs like MolochDAO and venture DAOs like The LAO and MetaCartel. Because of the simplicity of the Moloch mechanism, it can be extended to more use cases in the future.

    Supporting on-chain governance and open source ventures is an important task in the Polkadot ecosystem. Therefore, an open source MolochDAO will be a useful building block is important.

    Team membersโ€‹

    • Dora Factory & DoraHacks Dev Team -- a team of developers who has built HackerLink.io/en, now hosting quadratic funding grants, bounties, and hackathons for BSC, Filecoin, HECO, Solana, etc. The team also implemented a quadratic funding Substrate pallet (https://github.com/w3f/Grant-Milestone-Delivery/pull/104).

    Contactโ€‹

    • Matsushiba Foundation LTD.

    Team Code Reposโ€‹

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2.5 months
    • Full-time equivalent (FTE): 2
    • Total Costs: 2000 DAI

    Milestone 1 -- Implement MolochDAO v1 Palletโ€‹

    • Estimated Duration: 6 weeks
    • FTE: 2
    • Costs: 1000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT
    0b.Testing GuideThe code will have unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests
    1.MolochDAO v1 Substrate PalletAn open-source prototype of a MolochDAO v1 substrate pallet. The pallet will implement Moloch v1. Key features include 1) guild bank, 2) guild shares, 3) submit a proposal, 4) vote for a proposal, 5) process a proposal, 6) ragequit
    2.TestDeploy the runtime module to a Substrate node and test MolochDAO v1 functions described above๏ฝœ

    Milestone 2 -- Implement MolochDAO v2 Palletโ€‹

    • Estimated Duration: 4 weeks
    • FTE: 2
    • Costs: 1000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT
    0b.Testing GuideThe code will have unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests
    1.MolochDAO v2 Substrate PalletAn open-source prototype of a MolochDAO v2 substrate pallet. The pallet will implement Moloch v2 based on the delivery of Milestone 1 (Moloch v1). Key features include 1) support multiple tokens in guild bank, 2) implement loot, 3) guild kick 4) ragekick
    2.TestDeploy the runtime module to a Substrate node and test MolochDAO v2 functions described above๏ฝœ

    Future Plansโ€‹

    The next step after completion of the milestone, we will consider to run a MolochDAO grant to support important projects from Polkadot and Kusama developer communities.

    We will develop frontend solutions in parallel with the pallet. Eventually, we are providing an open source Moloch infrastructure to facilitate on-chain governance and support open source ventures in the Polkadot and Kusama ecosystem.

    - + \ No newline at end of file diff --git a/applications/dora-factory-multisig.html b/applications/dora-factory-multisig.html index 9a0cfdb4b67..cdbbc5a5c83 100644 --- a/applications/dora-factory-multisig.html +++ b/applications/dora-factory-multisig.html @@ -4,14 +4,14 @@ Multisig Product on Substrate | Web3 Foundation Grants - +
    Skip to main content

    Multisig Product on Substrate

    • Project Name: Build A Minimum Viable Functioning Multisig Product on Substrate
    • Team Name: Dora Factory
    • Payment Address: 0xadcba9C5C8c33F7F71600c436F2F2B00bAbc9997

    Project Overviewโ€‹

    Multisig is the mostly used DAO infrastructure so far. In the Ethereum ecosystem, multisig wallets are hosting major DAOs (such as venture DAOs & grant DAOs). This project implements a multisig pallet and a minimum viable functioning multisig product on a Substrate. The goal of this project is to eventually launch a multisig product that is integrated with Dora Factory's testnets and parachain.

    Project Detailsโ€‹

    The MultiSig Substrate product functions include the following:

    • Create wallet by organization
    • Multi-asset management
    • Initiate a transaction in a wallet, sign a transaction, confirm a transaction
    • Switch wallet, manage multiple multisig account at the same time

    There've been a multisig pallet developed by parity. The pallet (https://github.com/paritytech/substrate/tree/master/frame/multisig) is a basic building block for us to build a more complete multisig MVP to meet actual demands of DAOs. We have finished the desgin based on the functions of current pallet, you view it here.We'll implement a frontend MVP which interacts with the pallet to make the multisig work for end users.

    Ecosystem Fitโ€‹

    The Dora Factory team has built the first functioning quadratic funding pallet, a MolochDAO pallet (for both MolochDAO v1 & v2), and a POA local testnet that runs an actual quadratic funding round for Dora Factory ecosystem projects (https://hackerlink.io/grant/dora-factory/).

    In addition to the pallets, the Dora Factory team has also built up the parachain infrastructure with a core pallet that helps organizations register and use future pallets that are available on the Dora Factory parachain.

    Although structures vary in different organizations, funding management is a general demand of all decentralized organizations. Multisig has been proven to be the most general and flexible way of managing funds within a DAO (or any other forms of decentralized organizations / communities), because it introduces minimum procedure requirements of funding management except multi-signature itself. Therefore it is also the best entry point to a wider range of dGov applications.

    Team membersโ€‹

    • Dora Factory & DoraHacks Dev Community -- a community of developers who has built HackerLink.io/en, now hosting quadratic funding grants, bounties, and hackathons for EVM ecosystems, Polygon, BSC, Filecoin, Solana, and Dora Factory itself (https://hackerlink.io/grant/dora-factory/). The team also implemented a quadratic funding Substrate pallet (https://github.com/w3f/Grant-Milestone-Delivery/pull/104), a Moloch pallet, and a DAO-as-a-Service Substrate chain to host dGov applications within the Polkadot / Substrate ecosystem.

    Contactโ€‹

    • Matsushiba Foundation LTD.

    Team Code Reposโ€‹

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1 months
    • Full-time equivalent (FTE): 2
    • Total Costs: 10000 DAI

    Milestone 1 --The code implementation Multisig Frontend MVPโ€‹

    • Estimated Duration: 4 weeks
    • FTE: 1
    • Costs: 10000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT
    0b.DocumentationWe'll provide a simple documentation for current pallet that we'll support and a basic guide for our design principle
    0c.Testing GuideThe code will have unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.DockerFor easy deployment, we'll provide a Dockerfile coming with our code, so that it can be published easier and faster
    1.Multisig frontend MVPA functioning open-source frontend project. The frontend MVP will enable the whole flow of the pallet key features including 1) Create wallet by organization 2) Initiate, sign, and confirm transactions 3) Add signer and update multi-sig rule 4) Show transaction history of a wallet
    2.TestDeploy the runtime module to a Substrate node and test Multisig functions described above

    Future Plansโ€‹

    Integrate the multisig MVP with the Dora Factory core pallet and allow any organization on the Dora Factory Substrate chain to create a multisig wallet and use it to manage funds and access the other dGov applications (e.g. Quadratic Funding, MolochDAO, etc.) in the ecosystem.

    - + \ No newline at end of file diff --git a/applications/dorahacks-quadratic-funding.html b/applications/dorahacks-quadratic-funding.html index 910edd89039..c263c4da031 100644 --- a/applications/dorahacks-quadratic-funding.html +++ b/applications/dorahacks-quadratic-funding.html @@ -4,13 +4,13 @@ Quadratic Funding Pallet | Web3 Foundation Grants - +
    Skip to main content

    Quadratic Funding Pallet

    • Team Name: DoraHacks
    • Payment Address: 0xadcba9C5C8c33F7F71600c436F2F2B00bAbc9997

    Project Overviewโ€‹

    We would like to bring quadratic funding grants to Polkadot and Kusama ecosystem so that there is a way for the community to support early-stage developer projects on Polkadot and Kusama.

    Overviewโ€‹

    Quadratic Funding was proposed in Vitalik Buterin's paper Quadratic Payments https://vitalik.ca/general/2019/12/07/quadratic.html. It's now been proven as an effective way to encourage grass-root innovation from the developer community and a unique mechanism to allow community contributors to directly support early-stage projects. Currently, GitCoin's ETH Grant and HackerLink's BSC Grant are already practicing this idea.

    This project develops a substrate pallet that implements the quadratic funding process. The pallet will be tested on a local substrate node, and a simple frontend interface will be created based on Substrate Frontend Template.

    We are building tools to incentivize open source blockchain development on HackerLink.io/en, and we have already implemented quadratic funding grant. Binance Smart Chain community is running its first quadratic funding grant on HackerLink, and we have seen amazing projects being uploaded since its launch. GitCoin is also doing a good job working with the Ehtereum Foundation to host Ethereum quadratic funding grants.

    This is the first step we want to take to eventually bring quadratic funding grants to Polkadot, Kusama, and all parachains that need it.

    Project Detailsโ€‹

    Any quadratic funding grant will consist of two funding pools -- a community contributors' donation pool and a matching pool donated by ecosystem partners. Community contributors will be able to directly donate to projects they like and complete voting in the same time. The distribution of the matching pool will be determined by quadratic voting results from community contributors. Therefore, all community contributors will have a direct impact on the allocation of the matching pool.

    Here is a detailed explanation of HackerLink quadratic funding (use DOT as example):

    Polkadot Quadratic Funding Grant.jpeg

    The on-going BSC quadratic funding grant can be accessed here: https://hackerlink.io/en/grant

    A Chinese version to explain Quadratic Funding can be found here: https://matataki.io/p/6113

    Ecosystem Fitโ€‹

    Since quadratic funding is a community driven funding mechanism for early-stage grants, it will introduce a more community-driven method to fund developer community projects in the Polkadot and Kusama ecosystem.

    It's also exciting to implement quadratic funding as an on-chain governance module and add it to Polkadot governance stack.

    Team membersโ€‹

    • DoraHacks Dev Team -- a team of developers who has built HackerLink.io/en and implemented the first quadratic funding smart contract on BSC.

    Contactโ€‹

    • Twenty-Second Century Dora Technology Holdings Inc.

    Team Code Reposโ€‹

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-time equivalent (FTE): 3
    • Total Costs: 1000 DAI

    Milestone 1 -- Implement Quadratic Funding Palletโ€‹

    • Estimated Duration: 5 weeks
    • FTE: 2
    • Costs: 500 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT
    0b.Testing GuideThe code will have unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests
    1.Quadratic Funding Substrate PalletAn open-source prototype of a quadratic funding substrate pallet. The pallet will implement quadratic voting algorithm and the quadratic funding process: project registration, direct donation, voting, fund distribution.
    2.TestDeploy the runtime module to Substrate testnet and test quadratic funding functions: project registration, direct donation, voting, fund distribution. (No security audit here)๏ฝœ

    Milestone 2 -- Frontend Integrationโ€‹

    • Estimated Duration: 3 weeks
    • FTE: 3
    • Costs: 0 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT
    0b.Testing GuideA testing guide to list blackbox test cases demonstrate the frontend integration functionalities on HackerLink.
    1.Connecting to PolkadotJS extensionIf not installed, direct users to install. If installed, ask users to select an account. Popup window for interactions: project registration, voting, donating, fund redemption.
    2.HackerLink IntegrationDeploy a substrate node and connect it to the HackerLink test line. Similar user experience to BSC Grant Round-1.
    4.TestWe will test the frontend before milestone delivery.

    Future Plansโ€‹

    After implementation of quadratic funding pallet on Substrate, we will plan a quadratic funding grant as soon as the Kusama Network is available. This effort will be in coordination with the Kusama Council. We will audit the pallet code and the frontend code before launching.

    Eventually, we hope to run KSM and DOT quadratic funding grants on a regular basis, and make it a continuous effort to support and incubate developer projects from the community, by the community. Meanwhile, we want to make the pallet availale as a module for every other parachain to run their own quadratic funding grant.

    Additional Informationโ€‹

    DoraHacks' blockchain developer platform HackerLink is currently hosting the Binance Smart Chain Quadratic Funding Grant Round-1. The BSC foundation donated $50,000 to this round to support BSC-based developer projects. This grant can be accessed at https://hackerlink.io/en/grant.

    There is a smart contract deployed on the BSC mainnet to process all quadratic voting and funding activities, and the smart contract has been audited by Certik. https://github.com/dorahacksglobal/BSCQuadraticFundingGrant

    DoraHacks is an active hackathon organizer and developer community in the blockchain space. DoraHacks has been organizing blcokchain hackathons and developer communities in 8 countries and ~20 cities around the world (Boston, SF, San Jose, Beijing, Hangzhou, Bangalore, Berlin, Oxford, Tokyo, Seoul... etc.)

    - + \ No newline at end of file diff --git a/applications/dot_etl.html b/applications/dot_etl.html index f38da000559..7afc11ecb39 100644 --- a/applications/dot_etl.html +++ b/applications/dot_etl.html @@ -4,13 +4,13 @@ DOT-ETL | Web3 Foundation Grants - +
    Skip to main content

    DOT-ETL

    • Team Name: Davanti
    • Payment Address: 16m9eMpB3BuPSXwjvdCY6z63pTuvdnv8FjmmH33ZkYPCr9XC
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    This proposal is in response to the following RFP: Analysis Website and Data Platform

    The goal of the Dot-ETL project is to lower the friction required to conduct fine-grained and aggregated analysis of transactions on Polkadot network, via a framework to extract Polkadot transaction-level data to various offline formats: e.g. CSV / delimited, relational, columnar. Furthermore, we intend to develop a framework to ETL Substrate to Google BigQuery, orchestrated via Google Cloud Composer.

    The Polkadot and Kusama ecosystems have nurtured a significant developer community, and hosts a number of well-known parachains spanning a diverse series of domains, including Defi lending / liquidity, DEXs, NFTs, RWAs and securitization, as well as identity and privacy applications. While there has been a great deal of interest in developing on polkadot, there hasn't thus far been a simple means to query and visualize transaction-level data and aggregates.

    Dot-ETL will be similar in functionality to the Ethereum ETL project. In the same way that the ETH-ETL offering Ethereum transaction data as a Public Dataset from Google has helped to establish higher TVL and adoption of the Ethereum network, the goal is that by making PolkaDot transactional data easily accessible without the majority of data engineering tasks that exist in extracting data in usable form from the blockchain will lead to greater development and interest for the protocol by mainstream users of platforms such as Google Cloud. Once data is supported and provided in this format, there are also other potential use cases that can expand adoption of PolkaDot data by the blockchain industry such as easily being able to host Chainlink oracles for this data and provide it in readily available form for a number of different cross-chain applications. The open nature of the google bigquery dataset would allow anyone to query and extract insights from on-chain activity via SQL, or even build visualizations on thedata.

    Upon successful completion of the primary data structures (blocks, extrinsics, events), we plan to provide a framework / pattern to extract extrinsics tailored to specific parachains. We may explore Defi and RWAs in more depth: we believe that providing focus on DeFi activity related to Real World Assets on Google Cloud is the most promising use of public data to attract attention to the ecosystem.

    We also intend to publish guides on how to query and use the dataset (i.e. medium articles, github wikis, gitbook document site). The source code for Dot-ETL will be made public through the Web3 foundation.

    The team has extensive technical background in backend software engineering and machine learning / data science, and domain knowledge in machine learning, financial services (both retail as well as institutional), lending, and quantitative risk management. Our expertise and extensive domain experience, particularly in real world usage of data in Fintech and DeFi, will allow for us to build with adoption and practical use in mind.

    Project Detailsโ€‹

    (Technical Details)

    The Dot-ETL project will utilize prior work on the SubQuery project to index and source block/event/call data on the Polkadot blockchain. The SubQuery project is already able to index and parse block / extrinsic(transaction) / event data on Substrate, persist into a postgres data schema, and serve queries on the data via GraphQL.

    Our ETL framework will consume the indexed data on a managed SubQuery node via GraphQL, and save to Google BigQuery in a format similar to existing blockchain-etl projects. We plan to orchestrate this ETL to BigQuery via the Google Composer offering on GCP as Airflow DAGs, written in Python.

    The design of the ETL will allow for a varied series of output formats. Users of the framework can choose to download the code and run their own copy of the ETL locally against the SubQuery node, or they can utilize the GCP BigQuery offering. We expect most users of the ETL data to utilize the public offering.

    The architecture and process of executing airflow pipelines within GCP composer are fairly well-documented. We expect that the infrastructure / architectural components for Dot-ETL will be similar to standard deployments within GCP composer - we are unlikely to require anything truly bespoke.

    The first milestone of the project will focus around blocks, extrinsics and events in Substrate, and will produce the same base-level tables (blocks, extrinsics, events). Subsequent milestones will propose a means to extract specific extrinsics / events from particular pallets and parachains, with a possible focus on Defi / RWAs. We believe that providing focus on DeFi activity related to Real World Assets on Google Cloud is the most promising use of public data to attract attention to the Polkadot ecosystem.

    We're still investigating the appropriate schema details that will capture data in the most useful /optimal way, but believe that the core tables / schema will be very similar to that of the Ethereum ETL project.

    There are two main components of the project. The first is the configuration of the SubQuery managed node that will index the components of Substrate that we are interested in. The second component is the Airflow DAG that will communicate with the SubQuery node via a GraphQL API. The DAG will write updates to underlying formats. The initial focus will be on writing to BigQuery tables, but the framework should be written such that other providers / database formats can be accommodated. While we may not write drivers / handlers for each provider or database type, the framework will be written in such a way that will allow the community to write specific handlers that can be easily plugged into the existing framework.

    Ecosystem Fitโ€‹

    Questions / Answers on Ecosystem Fit:

    Q: Where and how does your project fit into the ecosystem?

    A: Our aim is to provide a foundational framework and approach to ETLing Substrate data into the GCP BigQuery cloud storage medium (+ other mediums as needed). A robust illustrative example will allow others to build upon / extend the framework, and run and maintain the ETL process for general community use. By transforming into GCP BigQuery, we hope to drastically lower the friction required for anyone to analyze and produce insights on the data (developers, analysts, investors, enthusiasts).

    Q: Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

    A: Everyone. By building a framework that will make data available in a way that can be queried via SQL, and in conjunction with a repository of query recipes and articles / guides / docs, we allow anyone with some base-level analysis interest to get up and running quickly. Because transaction-level data will also be available in a standard data query format on Google cloud, it will be possible to create any number of dashboards and visualizations on third-party / cloud-based analytic tools.

    Q: What need(s) does your project meet?

    A: Analysis / Insights - ability for people (all audience types) to query transaction data at any granularity. Putting this data into an approachable format opens the ability for users to create reports, visualizations, monitors and notifications. Better visibility => more engagement / better understanding => stronger community. Most users of data don't have the data engineering skills or capacity to extract data of this form onto a platform like Google Cloud platform, while remaining highly adept at querying, analyzing and modeling this type of data on such a platform. The DOT-ETl project is meant to remove the major data engineering barrier that exists for these individuals to take advantage of the technological offerings Google Cloud platform in working with PolkaDot data.

    Q: Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? If so, how is your project different? If not, are there similar projects in related ecosystems?

    A: There is already a team that has created substrate-etl on Google BigQuery. However, we believe there is value to creating redundancy by providing a competing approach to the problem. Our approach differs in two ways (technically): (a) use of the SubQuery indexer, whereas the competing team utilized their own indexer (polkaholic), (b) use of google composer / airflow.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Jonathan
    • John

    Contactโ€‹

    • Registered Address: N/A
    • Registered Legal Entity: N/A

    Team's experienceโ€‹

    The team has extensive technical background backend software engineering and machine learning / data science, and domain knowledge in machine learning, financial services (both retail as well as institutional), lending, and quantitative risk management (market trading risk as well as bank capital).

    Jonathan has worked in both fintech in backend software engineering, as well as institutional financial firms (investment banks / hedge funds) in quantitative risk roles. Please see Jonathan's Github (liangjh) for some public examples of projects he has built in his free time (private repos also available, pls contact to discuss). Jonathan is currently working on Cascadius Finance, a full-stack securitization protocol.

    John served as Head of Data Science & Modeling in FinTech startups, where he led and built teams for over nine years. He also has led adoption and integration of blockchain technology for FinTech clients, namely the partnership between Visa, Circle and Tala. In addition he has notably worked with companies like JD.com, Baidu, Ford Motor Credit, Discover, and Synchrony in the development of machine learning models for financial application. He has regularly served as a thought leader and public figure for credit executives on the subject of machine learning, having spoken on multiple industry panels and at notable conferences such as Lendit Fintech, American Bankerโ€™s BankAI and the Marketplace Lending Summit. John has also achieved the level of Competitions Master from the Google owned company Kaggle, for his stellar and consistent performance in real world machine learning competitions. He has formerly reached the rank of one of the top 100 data scientists in the world for his performances with Kaggle.

    Team Code Reposโ€‹

    No team code repos at the moment. Please see individual Github repos (below)

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We are currently in research phase; Development / coding has not started on this project yet.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 8 months
    • Full-Time Equivalent (FTE): 0.25
    • Total Costs: 26,000 USD

    Milestone 1 โ€” ETL of Relay Chain + Google BigQuery Integrationโ€‹

    • Estimated duration: 3-4 months
    • FTE: 1
    • Costs: 8,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide code document as well as a basic tutorial / instructions in the form of a README that will explain how a user can set up and run the components of the ETL to extract data to queryable formats
    0c.Testing and Testing GuideWe will have unit tests to ensure functionality. There will be concise instructions on how to run the tests in the guide / readme
    0d.DockerThe main infrastructural components, including subquery and airflow, will each be shipped with their own Dockerfile
    0e.ArticleWe will publish an article and how-to guide on Medium that will introduce our work and how to set up the basic Dot-ETL (audience: developers). We will also reference prior work done in the space.
    1.Create SubQuery Managed NodeUtilize SubQuery framework to create a running indexer node on SubQuery's managed services, reading and indexing blocks on the Polkadot network (may involve a few iterations for testing)
    2.Define schema to store underlying base data structures (blocks, extrinsics, events)Finalize stored format
    3.Define framework interfaces to allow for extensibilityMultiple underlying storage formats can be extended by community (not just limited to BigQuery)
    4.Airflow workflows to read SubQuery updatesRead updates from SubQuery node via GraphQL queries and write to BigQuery on a periodic timeframe
    5.Deploy Airflow to Google Composerdeploy to google composer as a test / note: we won't be maintaining this going forward
    6.Detailed developer guidesDeveloper-centric guides on how to extend the framework to interoperate with additional database frameworks and cloud platforms.

    Milestone 2 โ€” ETLs for Selected Parachains, Extensionsโ€‹

    • Estimated Duration: 3-4 months
    • FTE: 1
    • Costs: 18,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide detailed documentation for work done on this portion of the grant.
    0c.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0d.ArticleWe will publish a follow-up (part 2) article on Medium describing the extensions to the original work
    1.From base tables, extend to parsing 1-2 palletsWith milestone 1 completed and tables create for the core data structures (blocks, extrinsics, events), we can further process those base tables to produce more detailed tables for particular pallets
    2.Framework / methodology to extend to additional palletsCreate a configurable framework that will allow a more imperative approach to defining more detailed ETLs that can be extended to parsing and creating tables on specific pallets
    3.Detailed developer guideDetailed developer guide on using and extending the framework above - goal is to allow developers to utilize the framework to define more sophisticated ETL steps on top of the base tables, all in python (+ orchestrated by airflow).

    Future Plansโ€‹

    Our vision is to provide the framework which will power the go-to queryable data source for Substrate (polkadot / kusama) transactions - both for the main relay chain as well as for the respective parachains. Users of Dot-ETL can either query the public Google BigQuery database directly or create their own index node for any purpose. We expect the community to devise new use cases and applications for the underlying data.

    We intend to partner with / reach out to the following entities on the sponsorship / maintainance of the cloud-based query and storage formats (i.e. Google BigQuery):

    • Polkadot and Web3 Foundation -
    • Google Cloud Team -
    • Blockchain-ETL (related to Google Cloud Team)

    We also intend to seek integration for this data within the blockchain industry through potential oracle partnerships with protocols like Chainlink.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website / Medium / Twitter / Element / Announcement by another team / personal recommendation / etc.

    By recommendation from someone who was already familiar with the Polkadot / Substrate / Kusama projects, as well as the Web3 Foundation's grants program.

    - + \ No newline at end of file diff --git a/applications/dot_marketplace-Phase3.html b/applications/dot_marketplace-Phase3.html index 3d4c3776222..c196461d439 100644 --- a/applications/dot_marketplace-Phase3.html +++ b/applications/dot_marketplace-Phase3.html @@ -4,13 +4,13 @@ Dot Marketplace v3 | Web3 Foundation Grants - +
    Skip to main content

    Dot Marketplace v3

    • Status: Open
    • Project Name: Dot Marketplace
    • Team Name: Wow Labz
    • Payment Address: bc1qv954czydwz72egdzhkkuw85jegwrsmlt8a5xs8 (BTC - Bitcoin)
    • Level: 2

    Overviewโ€‹

    Links To Previous Approved Grants:

    This is phase 3 of Dot Marketplace, which is a general-purpose decentralized marketplace created as a Substrate pallet.

    • Dot Marketplace can be used by any decentralized project to float tasks and invite their community members to execute them for a reward. Its POC was developed during the Polkadot India Buildathon (2021).
    • In the previous phases we have built a decentralised bounty platform and a decentralised court for dispute resolution. More details can be found on the respective grant proposals shared above.

    Project Detailsโ€‹

    The current scope of work involves milestone-based submissions in which a project is divided into multiple configurable milestones(min 1 and max 5) to allow parallel or sequential execution.

    • Each project must have at least one milestone and can have a maximum of five milestones (configurable)
    • Each milestone has its independent bidding system where multiple workers can place their bids
    • The publisher can select a bid as per the requirement and ratings of the worker and other criteria that can be added to a user account.
    • A worker can bid for multiple milestones of a single project based on their expertise.
    • A project reaches completion only if all milestones in the project are completed and approved by the publisher.
    • In our current implementation all milestones are independent, hence they can be completed and approved by the publisher irrespective of the overall project status.
    • Based on the requirements, a publisher can add more milestones to a project even after it is pushed to the market, provided the total number of milestones does not exceed 5 (configurable)
    • Decentralized IPFS Storage for project materials using NFTStorage Provider. Each material will have a unique CID that can be accessed by both Publisher and Worker.
    • Advance Search by task tags, ids & title.
    • The decentralized court implemented in phase 2 is functional for each milestone of a project
    • All of the above features will be updated as a new feature for the existing marketplace pallet. Similarly, the selekatal UI will be updated to showcase the same.
    • A new file server written using the rocket framework will be provided for the integration with IPFS (using NftStorage).

    The flow of tasking pallet with milestone based submission

    Tasking-Court-Flow4 drawio

    Repository Hierarchyโ€‹

    node
    โ”œโ”€โ”€ build.rs
    โ”œโ”€โ”€ Cargo.toml
    โ””โ”€โ”€ src
        โ”œโ”€โ”€ chain_spec.rs
        โ”œโ”€โ”€ cli.rs
        โ”œโ”€โ”€ command.rs
        โ”œโ”€โ”€ lib.rs
        โ”œโ”€โ”€ main.rs
        โ”œโ”€โ”€ rpc.rs
        โ””โ”€โ”€ service.rs
    pallets
    โ”œโ”€โ”€ pallet-chat
    โ”‚   โ”œโ”€โ”€ Cargo.toml
    โ”‚   โ”œโ”€โ”€ README.md
    โ”‚   โ””โ”€โ”€ src
    โ”‚       โ”œโ”€โ”€ benchmarking.rs
    โ”‚       โ”œโ”€โ”€ lib.rs
    โ”‚       โ”œโ”€โ”€ mock.rs
    โ”‚       โ””โ”€โ”€ tests.rs
    โ””โ”€โ”€ pallet-tasking
        โ”œโ”€โ”€ Cargo.toml
        โ”œโ”€โ”€ README.md
        โ””โ”€โ”€ src
            โ”œโ”€โ”€ benchmarking.rs
            โ”œโ”€โ”€ lib.rs
            โ”œโ”€โ”€ mock.rs
            โ”œโ”€โ”€ utils.rs
            โ””โ”€โ”€ tests.rs
    runtime
    โ”œโ”€โ”€ build.rs
    โ”œโ”€โ”€ Cargo.toml
    โ””โ”€โ”€ src
        โ””โ”€โ”€ lib.rs

    The current focus is to enhance the existing Substrate pallet and allied code base to get a basic yet functional marketplace up and running.

    Ecosystem Fitโ€‹

    We believe this work could be helpful for any Polkadot parachains/parathreads interested in including a marketplace with on-chain dispute resolution.

    • Almost all parachains/parathreads would find motivation in encouraging their community members to contribute meaningfully to their roadmap. This can be achieved by utilizing a marketplace like Dot Marketplace, where technical, marketing, or governance-centric projects can be published as bounties. And community members are invited to bid for and execute them.
    • A milestone-based submission will enhance the functionality of the marketplace and provide a more comprehensive user experience for both the worker and the publisher.
    • The on-chain court will act as a dispute resolution mechanism between users involved in a project. A set of community members meeting specific criteria get to be a part of the jury for the dispute and cast votes, based on which a decision is reached.
    • To facilitate easier communication between a customer and a worker, a one-to-one chat feature is also created.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    • Registered Address: Wow Labz, 2Gethr Cowork, Tower B, Mantri Commercio, Outer Ring Rd, Bellandur, Bengaluru, Karnataka, India 560103
    • Registered Legal Entity: Wow Internet Labz Private Limited

    Team's experienceโ€‹

    Dot Marketplace is being built by the team at Wow Labz. Wow Labz is one of India's leading turnkey product development companies. The team is also building Socialli - an interoperable metaverse protocol on Polkadot. Additionally the team at Wow Labz has built Polkadot India - a 15,000+ community of polkadot enthusiasts predominantly from the Indian region. The team has previously built a decentralized storage protocol called Lake Network - https://lakenetwork.io/ in addition to multiple dApps on Ethereum, Stellar, EOS, and Hyperledger.

    A list of centralized and decentralised apps published can be found here.

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    • Here's a link to the approved grant proposal for the first phase and second phase
    • We are in touch with @takahser and @Rouven from the Web 3 Grants and Treasuries team, respectively.

    Development Roadmap ๐Ÿ”ฉโ€‹

    **Overview**

    • Total Estimated Duration: 2.0 Months
    • Full-Time Equivalent (FTE): 2.39
    • Total Costs: 29,925 USD

    Milestone 1โ€‹

    • Estimated duration: 3.0 weeks
    • FTE: 1
    • PTE: 2
    • Costs: 12,725 USD

    The main deliverable for this milestone is to facilitate the creation of a project that can accommodate multiple milestones that may or may not depend on each other. These functionalities will be implemented as an upgrade to the existing marketplace pallet.

    Sr no.DeliverableDescription
    0aLicenseApache 2.0
    0bDocumentationWe will provide both inline documentation of the code and a tutorial that explains how a user can use DOT Marketplace and understand the flow of tasking pallet.
    0cTesting GuideFunctions will be covered by unit tests, the documentation will describe how to run these tests. We will also provide scripts to help deploy, run and test the build.
    0dDocker ImageDocker image of the build
    1Project StructureThe existing application only allows one milestone per project. Phase 3 modifies it to allow a publisher to add multiple milestones under the same project.
    2Multiple BiddersMultiple bidders can now bid for the same milestone, and the publisher can choose one worker based on the bidder ratings
    3EscrowMultiple subaccounts are created for a project to account for each milestone and make it easier to store all funds for transfer/exchange.

    Milestone 2โ€‹

    • Estimated duration: 2.0 weeks
    • FTE: 1
    • PTE: 2
    • Costs: 9,225 USD

    In continuation to previous work, this milestone involves the creation of an on-chain decentralized court to handle dispute resolution. Each milestone can go into a dispute on the same scope as mentioned in the second phase of dot marketplace. The other milestones in a project are not affected by the dispute of one of the milestones. The court pallet will be upgraded to support these new features.

    Sr no.DeliverableDescription
    0aLicenseApache 2.0
    0bDocumentationWe will provide both inline documentation of the code and a tutorial that explains how a user can use DOT Marketplace and understand the flow of tasking pallet.
    0cTesting GuideFunctions will be covered by unit tests, the documentation will describe how to run these tests. We will also provide scripts to help deploy, run and test the build.
    0dDocker ImageDocker image of the build
    1Decentralized Court ModuleAn on-chain decentralized court for dispute resolution within the ecosystem.
    1aDisapprove MilestoneIn the case of a customer not being satisfied with the work submitted by the service provider (worker). A set of jurors is shortlisted (court summon) to resolve the dispute and pass a verdict.
    1bDisapprove RatingThe customer or the service provider, once they have received their rating for a particular milestone and are not satisfied with it.
    1cGeneral DisputeA general dispute function for cases that do not fall under the categories mentioned in 1a and 1b.
    2Voting moduleEach juror can review the dispute and cast their vote, which also includes their rating for both the customer and the worker. After two days, all the juror votes are counted, and a winner is identified.
    3Frontend AppSupporting frontend UI to test the aforementioned functionality.

    Milestone 3โ€‹

    • Estimated duration: 3.0 weeks
    • FTE: 1
    • PTE: 2
    • Costs: 7975 USD

    The main deliverables in this milestone are to use decentralized IPFS based storages to store all the files realated to tasks & advanced search. A file server integrated to nft storage will provided, using rocket framework & the search feature will be an update to the makerplace pallet. The skeletal UI will also be updated to showcase all the new features in Phase3.

    Sr no.DeliverableDescription
    0aLicenseApache 2.0
    0bDocumentationWe will provide both inline documentation of the code and a tutorial that explains how a user can use DOT Marketplace and understand the flow of tasking pallet.
    0cTesting GuideFunctions will be covered by unit tests, the documentation will describe how to run these tests. We will also provide scripts to help deploy, run and test the build.
    0dDocker ImageDocker image of the build
    1Decentralized StorageAll tasks related docs will be stored on a decentralized IPFS platform.
    2Advanced SearchSearch based on task progress, tags, tasks or milestone id's.
    3Frontend AppSupporting frontend UI to test the aforementioned functionality.
    4WebsiteDedicated one-page website for Dot Marketplace.
    5ArticleWebsite article showing motivation behind phase 3 of dot marketplace and how to make the best use of it.

    Additional Project Detailsโ€‹

    • Technology stack being used
      • Rust, Substrate, React, Python, centralized cloud storage

    Future Plansโ€‹

    This is the last phase in our current roadmap. Post this we would focus on partnerships with chains on the dotsama ecosystem for integrating DotMarketplace as their native bounty management tool (this work has already started). If future, if the traction is great, we could create a fresh proposal for an excellent UI or integrate DotMarketplace within PolkaJS Apps itself with native support for multiple tokens besides DOT.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website, Polkadot India Buildathon

    • We have been working on this roadmap since we applied for the Web3 grant
    - + \ No newline at end of file diff --git a/applications/dot_marketplace-phase2.html b/applications/dot_marketplace-phase2.html index dd26bbc8b9c..9366623388a 100644 --- a/applications/dot_marketplace-phase2.html +++ b/applications/dot_marketplace-phase2.html @@ -4,13 +4,13 @@ Dot Marketplace v2 | Web3 Foundation Grants - +
    Skip to main content

    Dot Marketplace v2

    • Status:ย Open
    • Team Name:ย Wow Labz
    • Payment Address:ย 0xF13001401396AA866E8012f31fD939C7E83B8601 (USDT - ERC20)
    • Level:ย 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    This is phase 2 of Dot Marketplace, which is a general-purpose decentralized marketplace created as a Substrate pallet.

    • Here's a link to the approved grant proposal for the first phase.

    • Dot Marketplace can be used by any decentralized project to float tasks and invite their community members to execute them for a reward. Its POC was developed during the Polkadot India Buildathon (2021).

    • It would be directly integrated into Polkadot JS Apps, where such marketplaces could create bounties and tasks that community members could fulfill.

    • The inspiration for Dot Marketplace emerged from our own needs while building Yoda - a protocol that facilitates decentralized app development leveraging open data. Dot Marketplace would be used to create data, services, and app marketplaces on Yoda, which would motivate us to maintain this project in the long run.

    Project Detailsโ€‹

    The current scope of work involves implementing a decentralized court system to resolve disputes in the marketplace and a chat feature between two users.

    • The court is a functionality that delivers unbiased decisions and is driven by a jury.
    • The jury is the participants already present on the chain
    • The jury is selected based on some criteria
    • The potential jurors are collected from the chain based on their past ratings and whether they have the expertise of the task in question
    • Then the final jurors can nominate themselves to be part of the jury for a specific job after accepting the proposal
    • All court cases are time-bound and are given 3 days (43,000 slots) in total
    • The 3 days are divided into 2 parts:
      • Jury acceptance period (14,400 slots/1 day) - This is the period for the potential jurors to accept the jury duty
      • Voting period (28,800 slots/2 days) - This is the time for the jurors to cast their vote. One juror gets only one vote which can be in favor of the customer or service provider (worker)
    • After concluding, all the jurors who participated in the case get a commission, which is based on the total cost of the entire task.
    • In case of a tie or if no juror votes, the voting is carried out by the super juror, who will cast a vote based on the work submitted.
    • A user can call the court on the unsatisfactory rating provided by either the customer or the worker.

    The flow of the tasking pallet with decentralized court implementation

    Tasking-Court-Flow4 drawio

    Dot Marketplace is being built as a Substrate pallet. It would include boilerplate code that para-chain teams can customize as per their requirements. We believe this project has the potential to transform community participation, engagement, and governance in decentralized projects.

    Repository Hierarchyโ€‹

    node
    โ”œโ”€โ”€ build.rs
    โ”œโ”€โ”€ Cargo.toml
    โ””โ”€โ”€ src
        โ”œโ”€โ”€ chain_spec.rs
        โ”œโ”€โ”€ cli.rs
        โ”œโ”€โ”€ command.rs
        โ”œโ”€โ”€ lib.rs
        โ”œโ”€โ”€ main.rs
        โ”œโ”€โ”€ rpc.rs
        โ””โ”€โ”€ service.rs
    scripts
    โ”œโ”€โ”€ docker_run.sh
    โ””โ”€โ”€ init.sh
    pallets
    โ”œโ”€โ”€ pallet-chat
    โ”‚ย ย  โ”œโ”€โ”€ Cargo.toml
    โ”‚ย ย  โ”œโ”€โ”€ README.md
    โ”‚ย ย  โ””โ”€โ”€ src
    โ”‚ย ย      โ”œโ”€โ”€ benchmarking.rs
    โ”‚ย ย      โ”œโ”€โ”€ lib.rs
    โ”‚ย ย      โ”œโ”€โ”€ mock.rs
    โ”‚ย ย      โ””โ”€โ”€ tests.rs
    โ”œโ”€โ”€ pallet-court
    โ”‚ย ย  โ”œโ”€โ”€ Cargo.toml
    โ”‚ย ย  โ”œโ”€โ”€ README.md
    โ”‚ย ย  โ””โ”€โ”€ src
    โ”‚ย ย      โ””โ”€โ”€ lib.rs
    โ””โ”€โ”€ pallet-tasking
        โ”œโ”€โ”€ Cargo.toml
        โ”œโ”€โ”€ README.md
        โ””โ”€โ”€ src
            โ”œโ”€โ”€ benchmarking.rs
            โ”œโ”€โ”€ lib.rs
            โ”œโ”€โ”€ mock.rs
            โ””โ”€โ”€ tests.rs
    runtime
    โ”œโ”€โ”€ build.rs
    โ”œโ”€โ”€ Cargo.toml
    โ””โ”€โ”€ src
        โ””โ”€โ”€ lib.rs

    The current focus is to enhance the existing Substrate pallet and allied code base to get a basic yet functional marketplace up and running.

    Ecosystem Fitโ€‹

    We believe this work could be helpful for any Polkadot para-chains/ para-threads interested in including a marketplace with an on-chain dispute resolution mechanism.

    • Almost all para-chains/ para-threads would find motivation in encouraging their community members to contribute meaningfully to their roadmap. This can be achieved by utilizing a marketplace like Dot Marketplace where technical, marketing or governance-centric tasks can be published as bounties. And community members are invited to bid for and execute them.
    • The on chain court will act as an dispute resolution mechanism between users involved in a task. A set of community members meeting a certain criteria get to be a part of the jury for the dispute and cast votes, based on which a decision is reached.
    • To facilitate easier communication between a customer and a worker, a one-to-one chat feature is created as well.

    Teamย ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    • Contact Name:ย Amit Singh
    • Contact Email:ย amit (dot) singh (@) wowlabz.com
    • Website:ย http://www.wowlabz.com
    • Project Website:ย Dot marketplace website is under construction
    • Registered Address:ย Wow Labz, 2Gethr Cowork, Tower B, Mantri Commercio, Outer Ring Rd, Bellandur, Bengaluru, Karnataka, India 560103
    • Registered Legal Entity:ย Wow Internet Labz Private Limited

    Team's experienceโ€‹

    Dot Marketplace is being built by the team at Wow Labz. Wow Labz is one of India's leading turnkey product development companies. Socialli Protocol has been conceptualized and is being produced by the team at Wow Labz. The team has previously built a decentralized storage protocol called Lake Network -ย https://lakenetwork.io/ย in addition to multiple dApps on Ethereum, Stellar, EOS, and Hyperledger.

    A list of centralized apps published can be foundย here.

    Team Code Reposโ€‹

    Development Statusย ๐Ÿ“–โ€‹

    Dot Marketplace POC was conceptualized and developed during the Polkadot India hackathon. The roadmap listed below comprises new features that would help take the POC to a minimum viable product (MVP). The first stage of the project involved creating user registration and marketplace based on a bidding system.

    Development Roadmap ๐Ÿ”ฉโ€‹

    **Overview**

    • Total Estimated Duration: 3 Weeks
    • Full-Time Equivalent (FTE): 3.36
    • Total Costs: 24,305 USD

    Milestone 1โ€‹

    • Estimated duration: 1 week
    • FTE: 2
    • PTE: 2
    • Costs: 8,325 USD

    The main deliverable for this milestone will be to migrate the existing application to substrate frame v2 and include the chat feature as a pallet for communication between a customer and a service provider to have a one-on-one conversation over the deliverables and timelines. The entire milestone covers the Rust/Substrate code implementation.

    Sr no.DeliverableDescription
    0aLicenseApache 2.0
    0bDocumentationWe will provide both inline documentation of the code and a tutorial that explains how a user can use DOT Marketplace and understand the flow of the tasking pallet.
    0cTesting GuideFunctions will be covered by unit tests, the documentation will describe how to run these tests. We will also provide scripts to help deploy, run and test the build.
    0dDocker ImageThe docker image will contain the entire tasking pallet Frame V2 version for anybody to just deploy it on their terminal without cloning the repo explicitly, it will be explained along with the commands for testing and running the image.
    1Migrate Tasking Pallet from FRAME v1 to FRAME v2The existing Tasking Pallet will be migrated to FRAME v2 to account for the new features provided by the framework
    2Chat PalletChat functionality is to be exposed and consumed between the customer and the service provider to ease communication and this will be integrated with the tasking pallet's frame v2 version

    Milestone 2โ€‹

    • Estimated duration: 2 weeks
    • FTE: 2
    • PTE: 2
    • Costs: 15,900 USD

    In continuation to previous work, this milestone involves the creation of an on-chain decentralized court to handle dispute resolution. Being a juror is one of the user incentives that can be achieved thanks to the rating module mentioned in the first phase of dot marketplace. The entire milestone covers the Rust/Substrate code implementation. The court process can be called at any one of the instances mentioned from points 1a to 1c below. The dispute logic is a function which will be called from two extrinsic. The additional dispute function for 1c will cover one case (at the moment- for example, the customer is not closing the task due to some reason. The worker gets the functionality to raise a dispute for this particular case). There can be more cases as such, which can be consumed and utilized for any use case. The functions for jury, which are court summon, dispute resolution time and other helpers, can be configured and managed for each use case.

    Sr no.DeliverableDescription
    0aLicenseApache 2.0
    0bDocumentationWe will provide both inline documentation of the code and a tutorial that explains how a user can use DOT Marketplace and understand the flow of the tasking pallet.
    0cTesting GuideFunctions will be covered by unit tests, the documentation will describe how to run these tests. We will also provide scripts to help deploy, run and test the build.
    0dDocker ImageDocker image of the build will contain the entire code for court and tasking pallet, with all the dependencies to directly run the code
    1Decentralized Court ModuleAn on-chain decentralized court for dispute resolution within the ecosystem.
    1aDisapprove TaskIn the case of a customer not being satisfied by the work submitted by the service provider (worker). A set of jurors is formed (court-summon) to resolve the dispute and pass a verdict.
    1bDisapprove RatingThe customer or the service provider, once they have received their rating for a particular task and are not satisfied by it.
    1cGeneral DisputeA general dispute function for cases that do not fall under the categories mentioned in 1a and 1b.
    2JuryThe chain specification of the testnet is modified to include more users with necessary specifications to be a part of the jury. The specifications include having average user rating above a certain threshold and being an expert in the field of the task. A list of potential jurors are notified and they have a period of one day to accept jury duty, with the maximum number of juors capped to 5 per dispute.
    3Voting moduleEach juror can review the dispute and cast their vote which also includes their rating for both the customer and the worker. After a period of two days all the juror votes are counted and a winner is identified.
    4EscrowSingle account for storing all the funds for transfer/exchange. Account for creating task, bidding for the task, transferring juror fees (if the court is summoned), transferring winner fees.
    5SchedulerCustom event scheduler built based on block number to facilitate the waiting periods for jury acceptance and juror voting.

    Additional Project Detailsโ€‹

    • Technology stack being used
      • Rust, Substrate, React, Python, centralised cloud storage

    Future Plansโ€‹

    Future releases of the Dot Marketplace include:

    PhaseFeatureDescription
    3Milestone based submissionsMaking provisions to breakdown a project into multiple configurable milestones to allow parallel or sequential execution
    4Decentralized StorageIntegration with IPFS or another decentralized storage platform

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website, Polkadot India Buildathon

    • We have been working on this roadmap since we applied for the Web3 grant
    - + \ No newline at end of file diff --git a/applications/dot_marketplace.html b/applications/dot_marketplace.html index 68c84ec8512..85cab0a5473 100644 --- a/applications/dot_marketplace.html +++ b/applications/dot_marketplace.html @@ -4,7 +4,7 @@ Dot Marketplace | Web3 Foundation Grants - + @@ -15,7 +15,7 @@ Wow Labz is one of India's leading turnkey product development companies. Yoda Protocol has been conceptualised and is being built by the team at Wow Labz. The team has previously built a decentralised storage protocol called Lake Network - https://lakenetwork.io/ in addition to multiple dApps on Ethereum, Stellar, EOS and Hyperledger.

    A list of centralised apps published can be found here.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Profiles of the people working actively on Dot Marketplace

    Development Status ๐Ÿ“–โ€‹

    Dot Marketplace POC was conceptualised and developed during the Polkadot India hackathon. The roadmap listed below comprises of new features that would help take the POC to a minimum viable product (MVP).

    Development Roadmap๐Ÿ”ฉโ€‹

    The development of Dot Marketplace is already underway. For the custom pallet (tasking) we are:

    1. Using various Substrate provided traits like - Currency, ExistenceRequirement, LockIdentifier, LockableCurrency, ReservableCurrency and few more;
    2. Using the pre-existing pallets like assets, balances and staking;
    3. Implementing custom structs like TaskDetails and TransferDetails. These in turn are used for various functionalities like create_task, bid_task, complete_task and approve_task. A special transfer money function is only initiated once the task cycle gets completed and the escrow funds are released to the worker.

    All the below mentioned milestones are going to be implemented and this application is going to be fully public.

    NOTE: A barebones UI would also be provided as a part of this submission to help the developer experience the functionality

    DotMarketplaceU

    Overviewโ€‹

    Milestone 1โ€‹

    The main deliverable for this milestone will be to allow a user to register via a registration form and link her wallet account along with role based switching from Service Provider view to Customer view and visa versa.

    NumberDeliverableSpecification
    0aLicenseApache 2.0
    0bDocumentationWe will provide both inline documentation of the code and a tutorial that explains how a user can use DOT Marketplace and understand the flow of tasking pallet.
    0cTesting GuideFunctions will be covered by unit tests, the documentation will describe how to run these tests. We will also provide scripts to help deploy, run and test the build.
    0dDocker ImageDocker image of the build
    1Registration ModuleForm based user registration
    2Wallet LinkingSupport for user to link their Math wallet, Guarda wallet or Polkadot Js apps with the account.
    3Profile ModuleSupport for role based screens to ease the usability for users
    4Frontend AppSupporting frontend UI to test the aforementioned functionality

    Milestone 2โ€‹

    In continuation to the previous work, we will be working on a rating system for both Customer and Service Provider. This rating will eventually be the motivating factor for performance in the network. It would also help in designing incentives in future.

    NumberDeliverableSpecification
    0aLicenseApache 2.0
    0bDocumentationWe will provide both inline documentation of the code and a tutorial that explains how a user can use DOT Marketplace and understand the flow of tasking pallet.
    0cTesting GuideFunctions will be covered by unit tests, the documentation will describe how to run these tests. We will also provide scripts to help deploy, run and test the build.
    0dDocker ImageDocker image of the build
    1Rating ModuleSupport for profile based rating using substrate balances, treasury and staking pallets to be integrated with our custom tasking pallet to weigh the user's performance and rewards based rating system.
    2Programmatic Wallet TransferSubstrate based Smart Contract transfer function for programmatic/automated transfer of tokens from one application/user to the other.
    3Asset RestrictionsSupport for the locking of assets by time
    4Frontend AppSupporting frontend UI to test the aforementioned functionality

    Milestone 3โ€‹

    The deliverable for this milestone is that we will be providing a multi user scenario to test the functionality and integrate with storage and backend APIs for multipart data to be uploaded and downloaded.

    NumberDeliverableSpecification
    0aLicenseApache 2.0
    0bDocumentationDocumentation of the entire pallet, a guide for developers forking the project including FAQ
    0cTesting GuideFunctions will be covered by unit tests, the documentation will describe how to run these tests. We will also provide scripts to help deploy, run and test the build.
    0dDocker ImageDocker image of the build
    1Multiuser ModuleSupport for multiple Substrate seed users to test the functionality and make the task based transactions as per the Status mentioned. Substrate based Lockable currency for reserving user funds and allowing the escrow unlock after the approved status.
    2Tagging ModuleSupport for smart tags with the user profiles for programmatic track/domain alignment in the future
    3File Transfer ModuleAPI connections to cloud storage async upload/download of small files via Rocket
    4Frontend AppSupporting frontend UI to test the aforementioned functionality
    5WebsiteDedicated one page website for Dot Marketplace
    6ArticleWebsite article sharing the motivation behind Dot Marketplace and how to make best use of it

    Additional Project Detailsโ€‹

    Future Plansโ€‹

    Future releases of the Dot Marketplace include:

    PhaseDeliverableSpecification
    2Decentralised CourtA fully decentralised dispute resolution mechanism along with configurable rules for slashing and reputation.
    3Milestone based submissionsMaking provisions to breakdown a project into multiple configurable milestones to allow parallel or sequential execution
    4Decentralised StorageIntegration with IPFS or another decentralised storage platform

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website, Polkadot India Buildathon

    - + \ No newline at end of file diff --git a/applications/dotly.html b/applications/dotly.html index 02efe12fe06..cfd9f107e8b 100644 --- a/applications/dotly.html +++ b/applications/dotly.html @@ -4,13 +4,13 @@ DOTLY: Revolutionizing Polkadot Account Statistics | Web3 Foundation Grants - +
    Skip to main content

    DOTLY: Revolutionizing Polkadot Account Statistics

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    The growth of Polkadot, leading blockchain platform, presents a challenge for users in understanding and tracking their account activities. Existing solutions lack intuitive and engaging tools to present comprehensive statistics, leaving users with limited insights into their impact within the ecosystem.

    DOTLY is an innovative application that addresses this problem head-on. By providing a user-friendly platform with visually captivating and interactive displays, DOTLY transforms Polkadot account statistics into an informative and ingsightful experience. Users gain access to a wide range of statistics, including account overviews, balance and extrinsic histories, badges, and action insights. DOTLY goes beyond numbers by incorporating visually appealing charts.

    With DOTLY's intuitive interface, users can understand their account activities at a glance. DOTLY aims to bridge the gap between account statistics and user accessibility, empowering Polkadot account holders to maximize their potential and contribute to the growth and success of the network.

    Project Detailsโ€‹

    Mockups

    Overview PageStats Page
    OverviewStats
    Extrinsics PageBadges Page
    ExtrinsicsBadges

    Technical Scheme

    technical_scheme


    API Scheme

    fast_api


    Technical Stack

    • Frontend: NextJS, Tailwind CSS, Apache ECharts
    • Backend: Python, Fast API
    • Integrations: Google Analytics

    Ecosystem Fitโ€‹

    Target audience

    DOTLY targets a diverse range of individuals within the Polkadot ecosystem, including existing Polkadot account owners seeking a comprehensive solution to track and understand their on-chain account activities, new users looking for an intuitive onboarding experience, and ecosystem enthusiasts interested in monitoring their involvement with pursuing badges.

    Impact

    • Comprehensive Account Insights: DOTLY offers users comprehensive statistics and insights about their Polkadot accounts, including total transfers, transaction rates, balance summaries, and more. By providing this deep level of visibility, DOTLY enables users to make informed decisions, optimize their engagement, and monitor their progress within the ecosystem.

    • Uniqueness: While there may be block explorers offering Polkadot ecosystem account statistics, such as balance history (and not much else), DOTLY differentiates itself through its focus on user experience, and rich charts/insights.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Mert Kรถklรผ - Project Owner

    Contactโ€‹

    • Registered Address: N/A
    • Registered Legal Entity: Individual

    Team's experienceโ€‹

    Mert Kรถklรผ

    Acted as an ambassador of many organizations including ACM, Microsoft and NVIDIA as Certified Instructor. In the Web3 space, he co-manage the AAVE Turkey Community and advocate for The Graph. Was working with AI video pipelines at an NVIDIA distributor company in Turkey before getting involved with blockchain.

    Develops ecosystem tools and applications with various tech stacks. AAVE, W3F, Flow and Filecoin grantee with an accepted multiple projects and now developing open-source, user-friendly applications that add value to the DOT ecosystem.

    Team Code Reposโ€‹

    Github Account

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    API scheme, technical stack and mockups are ready for development.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-Time Equivalent (FTE): 1 FTE
    • Total Costs: 10,000 USD

    Milestone 1 - Frontend and Backendโ€‹

    • Estimated duration: 2 months
    • FTE: 1 FTE
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationI will provide both inline documentation of the code and a basic set-up page that explains how a user can run frontend/backend repositories of the project in their local environment.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleI will publish an article that explains the charts/widgets in DOTLY and publish it with ecosystem.
    1.Search PageImplement search page that allows users to search for an account by address in Polkadot ecosystem.
    2.Overview PageImplement overview page that displays brief stats, parachain balance pie, parachain balance list, weekly transaction rate widgets.
    3.Overview Page - Brief StatsImplement an endpoint for brief stats widget that displays summaries like, total transfers sent\received, time with Polkadot, extrinsic count, nonce, role, tags, display name, twitter, web, Judgements, email (if these are exists) etc.
    4.Overview Page - Parachain Balance PieImplement an endpoint for balance pie widget that displays three pie charts. The first pie chart will show parachain that account address has balance. The second pie displays distribution of balance like Transferrable balance, Locked balance etc. and the third pie chart will show sub-distribution balance of the first pie chart selection like Election Lock, Democracy Lock, etc.
    5.Overview Page - Parachain Balance ListImplement an endpoint for balance list widget that displays list of parachains with respective balance summary of account address.
    6.Overview Page - Weekly Transaction RateImplement an endpoint for weekly transaction rate widget that is the number of transactions account have sent over the past 7 days.
    7.Stats PageImplement stats page that displays balance history, transaction history, top 5 senders/receivers, incoming/outgoing transfer, staking/pool reward history widgets.
    8.Stats Page - Balance HistoryImplement an endpoint for balance history widget that shows DOT balance change over time on account using chart.
    9.Stats Page - Transaction HistoryImplement an endpoint for relationship chart widget that shows relationship with different accounts. It can show most frequent accounts that user has interacts with.
    10.Stats Page - Top Senders/ReceiversImplement an endpoint for top senders/receivers widget that lists top senders and receivers (transfer) of the account.
    11.Stats Page - Incoming/Outgoing Transfer WidgetImplement an endpoint for top incoming/outgoing transfer widget that displays count of incoming/outgoing transfers over time with two line charts.
    12.Stats Page - Staking/Pool Reward HistoryImplement an endpoint for staking/pool reward widget that displays count of staking/pool reward over time with a line chart.
    13.Extrinsics PageImplement an extrinsics page that displays extrinsics count history, extrinsics success rate, top interacted modules/calls, action insight widgets.
    14.Extrinsics Page - Extrinsics Count HistoryImplement an endpoint for extrinsics count history widget that displays count of extrinsics over time with a line chart.
    15.Extrinsics Page - Extrinsics Success RateImplement an endpoint for extrinsics success rate widget that displays success rate of extrinsics on pie chart.
    16.Extrinsics Page - Top Interacted Modules/CallsImplement an endpoint for top interacted modules/pallets and calls widget. Top interacted calls will be listed based on selection of module.
    17.Extrinsics Page - Action InsightImplement an endpoint for action insight widget that displays two pie charts and one line chart. The first pie chart will show count distribution of modules user interacte with (such as balances), and the second pie chart will show count distribution of calls (such as transfer, transfer_keep_alive etc.) based on selected module. The line chart will show that call's count over time.
    18.Badges PageImplement badges page that displays badges widget.
    19.Badges Page - BadgesImplement an endpoint for badges widget. It will return all badges that user has achieved and yet to achieve. For example a badge will look like this: "Join the party! - Perform a token transfer".
    20.Google Analytics IntegrationIntegrate Google Analytics to track user interactions.
    21.Share FeatureMake every widget on the pages shareable.

    Future Plansโ€‹

    Altough DOTLY is initially focused on Polkadot, it offers detailed balance overview on parachains that user has balances. I plan to expand its capabilities to include other networks within the Polkadot ecosystem, such as Kusama and other parachains. Users can change parachain to see their stats in other parachains as well just like parachain explorers. This will allow users to track and analyze their activities across multiple interconnected networks, providing a comprehensive view of their participation in the wider Web3 ecosystem.

    Also I am planning to add quests that incentivize users to perform certain actions. Altough this is done by badges (for now) that are awarded to users, quests are a bit different. For example I can incentivize users to swap in X protocol, or stake in Y protocol, or provide liquidity in Z protocol. This will be a great way to increase user engagement and participation in the Polkadot ecosystem. The rewards for quests can be DOT, KSM, NFTs, etc. and can be provided from respective X, Y, Z protocol/tools. This feature is not included in the proposal since it adds complexity to the project and it will take more time to implement.

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    • Referrer: -
    • Payment Address: -

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    I am grantee of Web3 Foundation Grants Program.

    - + \ No newline at end of file diff --git a/applications/dotmog.html b/applications/dotmog.html index 748851e7b48..a4d28ff7053 100644 --- a/applications/dotmog.html +++ b/applications/dotmog.html @@ -4,7 +4,7 @@ DOTMog | Web3 Foundation Grants - + @@ -16,7 +16,7 @@ One of our big goals is to create further creatures in addition to the Mogwai, which have different characteristics depending on the universe on which they are located. So in a future step not only mogwais, but also kusamais or polkadais will populate the universe of the game and create a big community of gamers that loves to dive into this immersive experience.

    Motivation (An indication of why your team is interested in creating this project.)โ€‹

    We love the way we can materialize our ideas. Our small team consists of game and technology enthusiasts, who work in their leisure time with great dedication, passion and great intrinsic motivation on the project. Everyone inevitably has several hats on, we are developer, graphic designer, project manager, web designer and so on. We try to make up for this deficiency with our great enthusiasm and conviction in our almost daily work for the project.

    Project Detailsโ€‹

    Mockups/designs of any UI componentsโ€‹

    https://dotmog.com/gallery/

    Mogwai Life-Cylce

    API specifications of the core functionalityโ€‹

    https://github.com/dotmog/SubstrateNetApi

    An overview of the technology stack to be usedโ€‹

    Application Architecture

    Documentation of core components, protocols, architecture etc. to be deployedโ€‹

    We have been working on the World of Mogwais for a long time gaining experience in technology and game design, we were stopped by the limitations of the technology we were using, problems like freezing chains due to hash power spikes or no available storage made our lives hard. Just when we were giving up, we learned about substrate, so we dug into it and started to work on migrating and transforming our project into this new world of 3 sec block times and responsive storage access.

    We differentiate the gamelogic into two parts, base logic which is not heavy computing intense which will run inside the node and intense computing gamelogic for example for a dungeon event, which we plan to outsource with an Off-Chain worker to a trusted computing environment.

    PoC/MVP or other relevant prior work or research on the topicโ€‹

    Our alpha MVP is already running, check out our webpage (https://dotmog.com/).

    A lot of our previous work on the World of Mogwais is being used as PoC for the current project, the game logic we created WoMNetCore is reused where it makes sense or refactored to match better, here an old PoC. We used the CryptoKitties on Substrate as our first crash course into Rust and luckily it had a theme in common with our vision from 2017 old whitepaper.

    Ecosystem Fitโ€‹

    I think currently there are no such projects in the substrate ecosystem, at least we don't know of any. The full game logic is written down in our confluence, but for the sake of this file, we don't copy & paste it into here, but we can add it if necessary.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Artists:

    Contactโ€‹

    Team's experienceโ€‹

    The team consists of two experienced developers, one project manager / designer and additionally two supplying artists working on illustrations and 3D models. In past projects the team has already worked together on different projects one of them is mogwaicoin which has been live since 2018 and on the game on top The World of Mogwais. Besides that both devs have a background in reverse engineering of games and creating automations or simulators, like sabberstone. Our project manager is working in the financial sector in the same role for years as he is supporting the team. Based on the work of darkfriend77 Sabberstone simulator a lot of research and publications have been done in the AI domain (google: sabberstone research ai) or even ai competitions. Our passion is about creating games and/or enhancing the gaming experience for us.

    Team Code Reposโ€‹

    Other projects lead and maintained by the teammembers

    Adding a polkadot related commit here .. https://github.com/usetech-llc/polkadot_api_dotnet/pull/10

    Active organisations of the teammebers

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1: SubstrateNetApi โ€” Implement Basic Substrate .NET Standard 2.0 APIโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.Basic APICreate a solid base for the API, to be reusable, easy to use and simple to maintain
    1a.MetaData Modelread & parse metadata v11, v12 to json
    1b.ConnectionConnect & disconnect to node, with StreamJsonRpc, avoid reinventing the wheel where possible
    1c.Class ModelCreate basic class model, for the API
    1d.LoggingBasic NLog implementation, make sure it's usable with Unity3D
    1e.ErrorhandlingImplement specific errorhandling
    1f.Unit TestsCreate unit test cases
    2.Storage CallImplement basic storage call
    2a.Generic CallImplement generic type read from metadata
    2b.Type ConverterAdd type converter logic for basic types
    2c.Unit TestsCreate unit test cases
    3.RefactoringFirst Round of refactoring and restructure the API
    4.Submit ExtrinsicImplement basic extrinsic submits
    4a.Generic CallImplement typed extrinsic submits, to make access easier
    4b.EncodingAdd type encoding to the type converter class
    4c.Unit TestsCreate unit test cases, with payload testing signed and unsigned
    5.TestingAdd overall tests including connection to a node

    Milestone 2: SubstrateNetApi & Pallet DotMog โ€” Implement Advanced Substrate .NET Standard 2.0 API & Basic Pallet DotMogโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.Second Round of refactoring and restructure the API
    2.SubscriptionsImplement basic subscriptions
    2a.SubscriptionsImplement generic Callback for handling multiple subscriptions with subscriptionId
    2b.SubscriptionsAdded storage subscriptions, with paging
    2c.Unit TestsCreate unit test for subscriptions
    3.RefactoringRefactor type converters to be generic and reusable inheriting from IType, BaseType & Struct Type
    4.PalletDotMogPallet add base functionality, MogwaiStruct, AccountConfig & BreedType
    5.PalletDotMogPallet add pairing algorithm and MogwaiBios
    6.UpdateUpdate to Substrate v3.0/0.9 โ€“ Apollo 14, adjust types

    Milestone 3: SubstrateNetWallet โ€” Implement basic wallet & example Unity3D applicationsโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.WalletAdd basic wallet functions to be used in the game
    1a.WalletAES wallet file encryption, make sure that it is usable on Unity3D Mobile deployments, Android & iOs.
    1b.WalletWallet unlock and create, subscription to account and updates
    1c.WalletAdd events so game can register to changes, like mogwai creation, or extrinsic finalization
    2.ExamplesProvide basic examples of Unity3D application using the SubstrateNetApi
    2a.ExamplesSimple connection example
    2b.ExamplesSmall wallet example
    3.DocumentationAdd documentation to the usage of the SubstrateNetApi

    Milestone 4a: DOTMog โ€” Features Login / Create / Remove / Breeding / Paring / Morphโ€‹

    Milestone 4b: DOTMog โ€” Features Explorer / Auction / Trade / Sacrifice / Phases / GameEventsโ€‹

    Milestone 5: Enhancement of 3D Models / Enhancement of old Logo / Website and moreโ€‹

    Milestone 6: MVP 2 โ€” Features Stash/Item/Skillsโ€‹

    Milestone 7: MVP 2 โ€” Features Combatsystem, Duells, Leagueโ€‹

    Milestone 8: DOTMog Game โ€” Extensions Proving grounds & Interstellar Travel (Interchain operability)โ€‹

    Future Plansโ€‹

    We believe that there is a lot of potential in our project and we have a lot of ideas to provide additional content that can fit on the technology that we are using.

    Future Plans for MVP 2โ€‹

    Game Extensionโ€‹

    Additional Information โž•โ€‹

    The Milestones that have been marked as self funded include intellectual property of our brand and the core game, which includes game algorithm that shouldn't be public, which will run offchain worker on a trusted computing environment, it makes no sense in having this part open source as it would remove the games mysteries that are part of the DOTMog experience.

    ETA of the PROJECTโ€‹

    Currently we already have implemented the following Milestonesโ€‹

    On going workโ€‹

    - + \ No newline at end of file diff --git a/applications/eightfish.html b/applications/eightfish.html index 79679cfcd24..2be51b07bba 100644 --- a/applications/eightfish.html +++ b/applications/eightfish.html @@ -4,7 +4,7 @@ EightFish | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ consensus and code upgrade
  • Pursuing for the high performance tps, lower to 2~4 nodes, to run a blockchain application, to get the highest performance
  • Put major computing off-chain
  • Easy and quick query and indexing
  • No assets on it, but credits (asset is transferable, credit is non-transferable)
  • No need for collateral

    • By this way, this solution can be adopted and deployed by EVERY person/organization, and doesn't rely on any public service, we call it self-sovereign like what Web1.0 provides (http protocol, nginx servers, etc).

    There is no need to force users to use a web browser wallet plugin to kick off the beginning of the application. No new concepts need to be mastered, so it's relatively easy to import the internet users into the open web application.

    EightFish is a programming framework whose SDK interface is as simple as a traditional MVC web development framework. A good profit we can get is that this solution keeps programming models as the same as Web2.0 (MVC, CRUD, RESTFUL, GRAPHQL), and easily imports traditional web programmers into Open Web.

    This solution leverages all existing outstanding achievements in the database and distributed computing/storage industry from the internet time begins. We can build our next generation of applications based on these shoulders of giants.

    Data Availabilityโ€‹

    Since the application powered by EightFish has a blockchain network underlying, so the availability problem is the same as a general blockchain.

    First of all, all raw request data from user would be recored in the blocks, one by one. For a newly node joined, it could restore the latest global status of the Substrate on-chain node and the SQL db by rows. If there are too many blocks need to sync, another scheme is to get a snapshot from a trustful node, and catch up the latest blocks from that snapshot point.

    The second, we recommend that store the structured data (model object) into SQL database, and put other data (e.g. blob, picture, file) into a decentralized storage network, like IPFS. User upload the blob to IPFS, get the CID, insert it into the content of the structured data, and upload the structured data to the EightFish powered application to store the content into the SQL database, the id-hash pair index into the Substrate on-chain storage.

    This data separation model seems like the model a Web2 application uses. Model data is stored in the database, and pictures are stored in a public image bed service, the url of the picture will be inserted into the content of the model object. But here, it is for Web3.

    Ecosystem Fitโ€‹

    EightFish itself is a development framework, its users are developers.

    The experience of Web2 MVC framework alike will help import amounts of Web2 developers into Web3 and Substrate dev communities, meanwhile help Web3 developers implement their applications for broader internet users easily and quickly. Indirectly, we hope to attract more end users into Web3, by providing better UX and performance, which rely on the underlying framework. Thus we believe in the more adoption of EightFish, the more adoption of Substrate.

    Right now we don't find similar projects on this direction in the Substrate / Polkadot / Kusama ecosystem, and even in other ecosystems. Because most of other ecosystems are in fact ecosystems of smart contract public blockchains, the projects among them are unlikely going to adopt the appchain approach that Polkadot uses.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Daogang Tang (Mike Tang), a Rust enthusiast in China, the co-founder of Rust Chinese Community (RustCC), the advocator of the Substrate framework in China, has more than 15-years experiences on coding and architecture. He is also the ex-cofounder of Octopus Network, in charge of developer community building. He has done many research on Substrate and Web3, and published some articles on public media. He has been striving to promote the mass adoption of Rust, Substrate and Web3.

    Keqin Tao (Hacken), a Rust language lover, active in Rust Chinese Community. He is a certified AWS solution architect. He endeavours to introduce Rust into the projects of his company. He has much experience on Rust and Substrate developing.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Development Status ๐Ÿ“–โ€‹

    In Dec, 2022, Daogang Tang published his research on the theory of Open Web, a subset of Web3, the link is The Road to Open Web. This work has been lasting for about 2 years.

    And roughly from the June, 2022, Daogang Tang started to construct the EightFish framework, the framework to implement the theory of Open Web. Till now the five core components have been developed, and need another estimated one or two months to make them work together. So it is the right time to apply for the grant of W3f, and introduce the work we did to the whole substrate community.

    A full version deck of EightFish can be found here: EightFish Deck

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Accomplishing All Basic Components of EightFishโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains [...] (what was done/achieved as part of the grant).
    1.Substrate module: eightfishWe will create a Substrate module that will:
    1. record the coming requests;
    2. record the coming model indexes;
    3. update the on-chain wasm code for the off-chain worker
    2.Subxt proxyUse subxt to build a client proxy for the Substrate node and the spin worker node
    3.Off-chain wasm workerWe use spin as the wasm engine and to execute the code retrieved from the Substrate on-chain storage, interact with redis and postgresql
    4.Upgrade utilitiesSome tools or scripts to help on code upgrade:
    1. the tool for uploading new wasm file to the substrate node;
    2. the timer daemon for checking the new version of on-chain wasm code by interval;
    3. a monitor for wasm worker that while new version of wasm code loaded, reboot the wasm worker to execute new wasm code
    5.A set of rust derive procedural macroHelp write SQL literals and the type convertions between Rust types and SQL results easierly
    6.Framework SDK interface1. A router in the wasm worker to help write dispatching code;
    2. the handler definition;
    3. middlewares;
    4. a mechanism of shared varialbes;

    Milestone 2 โ€” Integrationโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains [...] (what was done/achieved as part of the grant).
    1.Writing processIntegrate all components built in milestone 1 and do testings on writing process
    2.Query processIntegrate all components built in milestone 1 and do testings on query process
    3.Code upgrading processIntegrate all components built in milestone 1 and do testings on code upgrading process
    4.A simple demoPrepare a demo for all processes with a simple web page UI, user can click on the web page to experience the capabilities of EightFish
    5.A 4 nodes networkBuild a 4 nodes network to test and run smoothly

    Future Plansโ€‹

    There are several points need to be optimized, including the performance of the finalization of the model index on-chain data submitted from the off-chain wasm worker, maybe we will dive into the Substrate transaction pool to do some work. So the perfection of EightFish is the next stop.

    And on the user level, next step we will port the RustCC forum onto EightFish, compile it into wasm code, and run it on the EightFish/Substrate network, that would be a 4 nodes network. And then we will use EightFish to build its own official website.

    We will spend about 12 months to verify the performance and UE of this forum, find defects of it, and improve the underlying EightFish framework.

    Meanwhile, we will start to promote the adoption of EightFish in our dev community, encourage them to test the EightFish framework, use it to develop some applications.

    After enough verifications, we will promote EightFish to all developers around the world.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    Daogang Tang developed a Rust MVC web framework sapper years ago, and the RustCC forum is running on it, so he will design the EightFish SDK interface by refering this work.

    - + \ No newline at end of file diff --git a/applications/epirus_substrate_explorer.html b/applications/epirus_substrate_explorer.html index 2e50524e948..0bf0013d8b4 100644 --- a/applications/epirus_substrate_explorer.html +++ b/applications/epirus_substrate_explorer.html @@ -4,13 +4,13 @@ Epirus Substrate Explorer | Web3 Foundation Grants - +
    Skip to main content

    Epirus Substrate Explorer

    • Team Name: Web3 Labs Ltd
    • Payment Address: 0xc905c448db9942c662fcb1680f3ecfcd0592409c
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Epirus Substrate Explorer will be a modular explorer for Substrate-based blockchains centred on supporting the Substrate contracts pallet and ink! smart contracts.

    Web3 Labs has developed a closed source commercial blockchain explorer for EVM blockchains named Epirus. It is already in production for some private chains of financial institutions, Chainstack, the Palm Network and Iconโ€™s upcoming ICE network. The acquired knowledge and the existing source code, if applicable, will speed up the delivery of the product.

    Our aspirational vision is to deliver a fully modular system providing a runtime for end-to-end extension bundles to compose your bespoke blockchain explorer instance. Each bundle should include the data model, the API and the UIย  to serve a specific set of functionality available in a Substrate node (e.g. contracts, identity, treasury, etc.) and be installable from a repository. In addition to supporting pre-built pallets, it would serve as a powerful complement for custom pallets. This design could stimulate the evolution of the ecosystem through the open-source community.

    Project Detailsโ€‹

    Architectureโ€‹

    The following diagram shows a high-level overview of the system logical components.

    Epirus Substrate Architecture

    The UI client application (C1) runs in a web browser and connects to a stateless web-accessible remote API through HTTP (C2).

    The API exposes the database entities in an easy to query way using GraphQL (C2).

    The database serves as a data enrichment layer and indexing of Substrate related data entities (i.e. metadata, blocks, extrinsics and events).

    The blockchain data services is a modular event-driven data extraction and transformation pipeline. This design will allow us to scale out the processors and extension modules that compose a data pipeline.

    The Substrate Indexer (C3) loads blocks from genesis to the present block height through a Substrate node RPC API. These blocks are stored in the database, emitted to an event hub, and consumed by the base processors (C4) responsible for extracting additional core entities.

    There is a processor per core data type, e.g. events from chain storage, to extract, transform and load it into the database. Each base processor emits events for its extracted entities.

    The extension modules are data processors with a function-specific processing scope, existing one per supported pallet. The Accounts module (C5) is an extension module to index data related to accounts and balances, while the Contracts module (C6) does the same for contract pallet related data.

    System Componentsโ€‹
    IDNameDescription
    C1Explorer UIThe Substrate Explorer client facing application that uses the Explorer API.
    The Explorer UI client application runs in the end-user web browser and uses the Explorer API (C2) for the rendition of user views.
    A registry of composable display blocks, for the navigation and the views itself will be implemented in order to make it easy to adapt the UI to the different pallets available in the Substrate node.
    C2*Explorer APIStateless GraphQL API to access the underlying database. Supports searching by indexed properties, pagination and sorting of results. We plan to serve it using PostGraphile or Husura.
    The API services can scale out by the usual HTTP load balancing.
    C3*Substrate IndexerLoad blocks from a Substrate node. It is responsible for reaching the most recently finalised block in the chain andย emittingย events on the ingestion of blocks.
    This component is the entry point for the transformation pipeline (C4, C5 and C6).
    C4*Base ProcessorsComponents for indexing and decoding the fundamental Substrate data types, i.e. blocks, extrinsics, events and logs.
    C5Accounts ModuleModule to index accounts and balances information.
    This is a prerequisite for the Contracts module (C6).
    C6Contracts ModuleModule to support the contracts pallet and ink! smart contracts.
    Features:
    • Support of two step contract deployment
    • Detection of contract code uploads and indexing of WASM hashes
    • Detection of contract instantiations and indexing of contract accounts
    • Basic decoding of contract calls, i.e. 4 bytes selector and unnamed parametersIndexing of contract related calls and events

    Notes

    * Depending on the readiness of the existing ecosystem projects for indexing and GraphQL API building, e.g. Substrate Archive, Subsquid or Subquery, could be used to provide the functionality of the API (C2), Substrate Indexer (C3) and Base Processors (C4).

    In any case, we will align the project with existing ecosystem solutions as much as possible.

    User Interfaceโ€‹

    The user interface will be based on the existing Epirus look & feel:

    Epirus Look and Feel

    Technology Stackโ€‹

    Web UI

    • Typescript โ€“ Strongly typed programming language that builds on JavaScript.
    • React / Preact โ€“ JavaScript library for building user interfaces. We will consider using Preact, the fast 3kB alternative to React with the same modern API, to reduce the package size if the bundler tree shaking is not enough.
    • Tailwind CSS โ€“ A utility-first CSS framework packed with classes that can be composed to build any design, directly in your markup.

    Data Processing*

    • Kotlin โ€“ Modern, concise and safe programming language.
    • Quarkus โ€“ Kubernetes native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards.
    • GraalVM โ€“ High-performance JDK distribution. It is designed to accelerate the execution of applications written in Java and other JVM languages while also providing runtimes for JavaScript, Ruby, Python, and a number of other popular languages. GraalVMโ€™s polyglot capabilities make it possible to mix multiple programming languages in a single application while eliminating any foreign language call costs.
    • PolkaJ โ€“ Java client library to use and access API of Polkadot based networks.

    * Depending on the maturity of the Substrate JVM ecosystem, we can switch to languages with more mature support for Substrate.

    Web API

    • GraphQL โ€“ Query language for APIs and a runtime for fulfilling those queries with your existing data.
    • PostGraphile โ€“ Builds a powerful, extensible and performant GraphQL API from a PostgreSQL schema.

    Database

    • PostgreSQL โ€“ Powerful open source object-relational database. Provides first-class support for JSON data types.
    • Citus โ€“ PostgreSQL extension that transforms Postgres into a distributed databaseโ€”so you can achieve high performance at any scale.

    Synergies to Explore

    • Substrate Archive โ€“ As a possibility to be evaluated, the Substrate Indexer and Base Processors could be provided by this Substrate blockchain indexing engine.
    • Subsquid โ€“ A query node framework for Substrate-based blockchains. In very simple terms, Subsquid can be thought of as an ETL tool, with a GraphQL server included. It is alpha stage software.
    • Subquery - A framework to define your own APIs to expose blockchain indexed data. It is similar to the Graph Network.

    Ecosystem Fitโ€‹

    Substrate Epirus Explorer, in general, aims to deliver a great user experience while browsing blockchain information. In particular, it will provide extensive support for accessing all the information related to deployed WASM bytecode and its account instances.

    The scope of this grant includes a baseline implementation of the core mechanisms and an elementary information display for contracts and accounts. The user interface will fulfil the minimum requirements for the prospective customers of the system to deliver a meaningful and fully functional baseline.

    Audienceโ€‹

    NameUsages
    Developers
    1. Developing backend extension modules
    2. Developing UI modules
    Service Providers
    1. Running an Explorer instance
    2. Customising the Explorer look and feel
    End Users
    1. Accessing precise and user-friendly blockchain information
    2. Verifying ink! smart contracts

    Existing Projectsโ€‹

    There are other Substrate based blockchain explorers, notably Subscan and Polkascan. Both are general Web3 explorers, whilst Subscan provides a better user experience, supports some pre-build pallets (i.e. staking, EVM and parachain) and exposes a REST API.

    We believe that a single provider cannot absorb all the UI experiences tailored to the growing number of pallets in the Substrate ecosystem. An open community package registry for this UI experience that exposes the functionality and data related to the pallets would benefit the evolution of the ecosystem. Regarding the API, the REST model imposes a rigid model to access information compared to GraphQL.

    Epirus Substrate Explorer differentiates itself from the present offering in the following key points:

    • Initial focus on smart contracts and ink! with unique and novel features like verification and standards contract identification.
    • Ease of customisation and branding without tech provider lock-in.
    • Aim for end-to-end modularity and extensibility.
    • Aim to avoid duplication and foster synergies leveraging existing projects in the ecosystem, like Subquery or Subsquid.

    Potential Synergiesโ€‹

    These are some projects that could ease the implementation of the proposed system:

    a) Substrate Archive is a project that decouples the indexing engine from the blockchain explorer, making it convenient to index historical blockchain data.

    b) Subsquid is a project targeted at developers aiming to reduce the complexity of fetching and transforming blockchain data and exposing it through a GraphQL API.

    c) Subquery is a project with similar functionality to Subsquid.

    Subquery and Subsquid projects are potential candidates to serve as the indexing backend of Epirus Explorer. However, the indexed data needs to turn into the human-friendly information displayed in the explorer UI, requiring further transformations and data enrichment (e.g. metadata from ABI descriptors, RPC calls for standard contract interfaces, etc.) This data transformation and the user-friendly display are what Epirus Explorer provides.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 50,000 EUR

    Milestone 1 - Devnet MVPโ€‹

    • Estimated duration: 2 months
    • FTE: 2
    • Costs: 50,000 EUR
    NยบDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up an Explorer instance and connect it to a Substrate node.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile and Docker Compose file(s) to ease the deployment and execution of the system.
    1.Baseline implementation of the system componentsThe implementation of the system components described in the โ€œSystem Componentsโ€ section:ย 
    • C1. Explorer UI
    • C2. Explorer API
    • C3. Substrate Indexer
    • C4. Base Processors
    • C5. Accounts Module
    • C6. Contracts Module
    The source code will be stored in a public git repository.
    2.Public explorer instanceA publically accessible instance of the Explorer connected to a development network with ink! smart contracts support.

    For this minimum viable product delivery the following features are out of scope:

    • Detection of standard contracts, e.g. Open Brush PSP22, PSP34, etc.
    • Uploading verified ABI metadata
    • Decoding of the contract calls based on ABI metadata
    • Decoding of events based on ABI metadata
    • Processing of "intrinsics", i.e. cross-contract interactions equivalent to Ethereum "internal transactions"

    Team ๐Ÿ‘ฅโ€‹

    Team Membersโ€‹

    • Marc Fornรณs
    • Xueying Wang

    Contactโ€‹

    • Registered Address: 7 Bell Yard, London, England, WC2A 2JR
    • Registered Legal Entity: Web3 Labs Ltd, CRN 10783824

    Team's Experienceโ€‹

    Marc Fornรณs has been designing and implementing software systems for 20 years. He is an expert in the area of distributed systems and data-intensive applications. His experience ranges from warehouse automation with radio-frequency terminals using the Adaptive Communication Environment C++ framework, to airline post-sale revenue optimization software-as-a-service platform, generating millions in incremental revenue for low-cost and full-service carriers during eight years of operation. Currently in charge of evolving the Web3 Labs Epirus Block Explorer product offering.

    Xueying Wang pivoted to software development after completing an MSc. in Aerospace Engineering and has been in the industry for the past six years. During this time, she pioneered conversational AI assistants for airlines, counting more than 20 assistants in production covering ten languages for customer service, FAQ and in-chat purchases. Also built a scalable publish-subscribe system to trigger actions on flight feed events for the automated agents. She participated in implementing a crypto trading bot as a side project and a composable Solid POD/RDF data browser. She has a great deal of experience developing React applications and is currently learning Rust and Substrate technologies.

    Team Code Repositoriesโ€‹

    Future Plansโ€‹

    The present proposal exists to deliver a minimum viable product implementation of the Substrate Epirus Explorer and a public instance connected to a development network.

    After this delivery, we expect to continue evolving the project and use each increment as feedback to the next phase to adapt the course of action as the problem space unfolds.

    Down below is an illustrative sketch of the phases that could follow.

    Phase 2 - Marketable Systemโ€‹

    • Estimated duration: 2 months
    • FTE: 2
    • Costs: 75,000 EUR

    Tentative scope:

    • Refinement of core abstractions and modules
    • Next increment of the Contract module
    • Ability to display different contract widgets based on contract metadata or standard implementations; e.g. PSP22 and PSP34
    • Support for branded themes

    Phase 3 - Web-Scale Systemโ€‹

    • Estimated duration: 2 months
    • FTE: 2
    • Costs: 75,000 EUR

    Tentative scope:

    • Ready to support a large number of users and transaction volumes
    • Performance analysis and tuning to cope with high volumes
    • Potentially includes horizontal scalability capabilities, e.g. sharding, batch splitting, distributed processing, etc.
    • Monitoring and scalable deployment infrastructure

    On-Going Supportโ€‹

    Post delivery it is anticipated that an ongoing maintenance and support grant will be required from the Polkadot Treasury in DOT to keep Epirus up to date with the ink! smart contract language and Substrate evolution in general.

    Business and Communityโ€‹

    Web3 Labs is passionate about supporting the wider Web3 community.

    Web3j has been going since 2016, and we have offered a free version of our Epirus Explorer for EVM-based chains since 2019.

    Our commercial model of the Epirus Explorer is a paid per volume and support software as a service. We plan to incorporate the Substrate Epirus Explorer into the offering.

    Based on our experience with Web3j over the years, pure open-source is hard to sustain. We want to ensure that our Epirus service on Substrate chains will serve the community while being a self-sustained revenue-generating product.

    The open-core of the Substrate Epirus Explorer, i.e. any grant funded development, will be available to the community without any financial constraints. Anyone will be able to run and extend its instances of the Explorer for its Substrate-based solutions.

    Additional Informationโ€‹

    In order to support ink! and Substrate, parts of Epirus Explorer could be open-sourced under an Apache 2.0 license following an โ€œopen coreโ€ model. Proprietary components, like EVM modules and chain intelligence, would be available exclusively via Web3 Labs Epirus offerings.

    Details about the existing Epirus offering for EVM chains:

    Additionally, it is worth mentioning that the team already built a composable data browser prototype for Solid PODs and RDF sources in general.

    - + \ No newline at end of file diff --git a/applications/epirus_substrate_phase_2.html b/applications/epirus_substrate_phase_2.html index 587fd86614a..ee31714fad4 100644 --- a/applications/epirus_substrate_phase_2.html +++ b/applications/epirus_substrate_phase_2.html @@ -4,7 +4,7 @@ Epirus Substrate Explorer - Phase II | Web3 Foundation Grants - + @@ -15,7 +15,7 @@ Verified Contract View

    More details of verified contract source codes: Verified Contract details

    Metadata Decodingโ€‹

    Currently, Epirus Explorer displays the encoded information for contract interaction messages and events, as shown in the image below.

    Contract Encoded Data Display

    We need to decode these entities to make them informative for a user. We will use the metadata in the .contract file generated during source code verification to decode these messages and events.

    As shown in the sequence diagram below, the decoding process will work as follows:

    Contrat Decode Sequence

    With the decoded data available, the Explorer UI can display contract messages and events with meaningful names and decoded parameters.

    Mock-ups

    This is how we envision the decoded contract data will look like: Contract Decoded Data

    Technology Stackโ€‹

    For the Metadata Registry, we will evaluate srtool for the part of deterministic builds, and we will leverage it if it meets our needs. Source code and metadata files will be stored on the file system and served using NGINX with an optimised configuration. In the future, we can also support decentralised storage layers.

    We plan to use Fastify, a project under OpenJS Foundation, for the web API because of its good performance, default security and smooth developer experience.

    We will continue using the Subsquid framework, Typescript and React.js for the Squid Ink processor and Explorer UI.

    Out of Scopeโ€‹

    In the case of contract metadata being uploaded sometime after instantiation, there will be un-decoded messages and events. A re-indexing process needs to be triggered to decode these entities. Currently, the indexing engine does not support any easy way for re-indexation. We will need to analyse the current system and derive the best solution for this situation. Considering the time and effort required, we have decided to leave this feature for the future.

    Ecosystem Fitโ€‹

    Currently, there is a lack of a Wasm contracts-oriented explorer in the Substrate ecosystem. While general explorers such as Subscan and Polkascan are available, the support for Wasm contracts on these explorers is either limited or non-existent. There is no explorer which verifies Wasm contracts or displays decoded contract messages, two valuable features for users. Epirus Substrate Explorer aims to fill the gap and provide a better user experience when interacting with Wasm contracts on Substrate chains.

    Additionally, the Metadata Registry will also be an independent service providing its capabilities to any explorer, or application, that wishes to access contract metadata and verified source codes. It will be comparable to Sourcify in the Ethereum ecosystem. Such a service does not yet exist in Substrate.

    On top of that, Epirus Substrate Explorer leverages existing solutions, such as SubSquid and srtools, which fosters synergy across the Substrate ecosystem.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 - Source Code Verificationโ€‹

    NยบDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation of the code and a basic tutorial to explain how to upload contract source code and metadata to the Metadata Registry.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. We will describe how to run these tests in the guide.
    0d.DockerWe will provide a Dockerfile and Docker Compose file(s) to ease the deployment and execution of the system.
    1.Metadata RegistryThe delivery of the baseline Metadata Registry will include
    • 1. Metadata Registry Core
    • 2. Metadata Registry API
    The source code will be in a public git repository.
    2.Developer ToolsWe will provide example scripts to help ease the process of bundling and compressing the required source code files.
    3.Updated Explorer UIThe Explorer UI will support the display of verification status and source code, in addition to the UI for contract source upload.
    4.Public explorer instanceA publicly accessible instance of the Explorer connected to a development network displaying verified source code and verification status.

    Milestone 2 - Decoding of Contract Messages and Events based on ABI Metadataโ€‹

    NยบDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation of the code and update the tutorial.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. We will describe how to run these tests in the guide.
    0d.DockerWe will provide a Dockerfile and Docker Compose file(s) to ease the deployment and execution of the system.
    1.Updated Squid Ink processorThe processor will connect to the Metadata Registry to retrieve contract metadata by chain ID and code hash, followed by decoding messages and events based on retrieved metadata.
    2.Updated Explorer UIThe Explorer UI will support the display of decoded contract messages and events.
    3.Public explorer instanceA publicly accessible instance of the Explorer connected to a development network displaying decoded contract messages and events.

    Team ๐Ÿ‘ฅโ€‹

    Team Membersโ€‹

    Contactโ€‹

    Team's Experienceโ€‹

    The same team has worked on the delivery of the first grant.

    Team Code Reposโ€‹

    Future Plansโ€‹

    With the baseline implementation of the Metadata Registry complete, there are many enhancements that can be built upon it. One such enhancement is to have different confidence indicators for verified contracts. Using the verification process outlined in the Source Code Verification section, we are only able to verify that the function of the code is the same as the uploaded source code. There is still the possibility for malicious actors to upload a "vandalised" source code with misleading function names and comments. We plan to circumvent this issue by allowing the user to sign the upload with his private key; source code uploaded and signed by the code owner will take prevalence over other uploaded sources. The contract code will also have the "signed by owner" badge, thus adding an additional layer of trust.

    With the verified metadata available, we are able to recognise when a contract is implementing a well-known interface. This will allow Epirus Substrate Explorer, or any other application using the Metadata Registry, to display and group contracts based on the interface that they are implementing. It will be similar to how ERC-20, ERC-721 and ERC-1155 tokens are distinguished in EVM contracts. We plan to support PSP-22 and 34 as standard contract-based token interfaces.

    We also plan to support EVM-compatible contracts in Substrate chains. This phase involves adding capabilities to index and decode messages and events from the EVM pallet.

    Lastly, we aim to improve scalability to handle large volumes of users and contracts. We will potentially switch from the current PostgreSQL to a distributed database such as CockroachDB. We also intend to add monitoring and scalable deployment infrastructure.

    - + \ No newline at end of file diff --git a/applications/escrow_pallet.html b/applications/escrow_pallet.html index 714c684d617..dd1b032c8fc 100644 --- a/applications/escrow_pallet.html +++ b/applications/escrow_pallet.html @@ -4,7 +4,7 @@ Escrow Pallet | Web3 Foundation Grants - + @@ -23,7 +23,7 @@ I am a contributor to the Substrate recipes repo, taking it upon myself to upgrading Substrate โ€œKitchen Nodeโ€ Recipes from v1 to v2, which took 5-6 months working in my spare time.

    Hello, my name is Gerti. Over the last 5 years, I've been continuously working towards achieving clients' business goals through the application of IT technology. The collaborations I've had working in a few industries brought to life numerous products with an audience of thousands and even millions of users. The secret behind this success was creating an intuitive, visually attractive application customized to the needs of the target clientele. In addition to the substantial experience working as a Java Enterprise, I've also gained a Master's Degree in Computer Science that has equipped me with a strong knowledge of the newest tools and technologies to create flawless products your clients will enjoy. The last months I have been curious about Substrate/Rust, and I am learning it on my spare time.

    Team Code Reposโ€‹

    Team Githubโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Statusโ€‹

    We would like to add this pallet to the Subtrate recipes repo.

    Development Roadmapโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement sign functionalityโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can sign an Escrow contract with another user.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains how an Escrow contract can be created and how can it be used.
    0f.BenchmarkingBenchmarking will be provided for sign_contract.
    1.Substrate module: sign_contractWe will create a Substrate module that will sign an Escrow contract between two users.

    Milestone 2 โ€” Implement send funds functionalityโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can send funds to the contributor/receiver.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains how an Escrow contract can be created and how can it be used.
    0e.BenchmarkingBenchmarking will be provided for send_funds.
    0f.Substrate module: send_fundsWe will create a Substrate module that will send funds to to the contributor/receiver

    Milestone 3 โ€” Implement Withdraw funds functionalityโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how the funds holders withdraw.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains how an Escrow contract can be created and how can it be used.
    0e.BenchmarkingBenchmarking will be provided for withdraw_funds.
    0f.Substrate module: withdraw_fundsWe will create a Substrate module that will withdraw the funds if nothing was delivered.

    Future Plansโ€‹

    - + \ No newline at end of file diff --git a/applications/evanesco_networks.html b/applications/evanesco_networks.html index 8a84c768086..2175aca2bb6 100644 --- a/applications/evanesco_networks.html +++ b/applications/evanesco_networks.html @@ -4,14 +4,14 @@ Evanesco Network | Web3 Foundation Grants - +
    Skip to main content

    Evanesco Network

    • Team Name: Evanesco Labs
    • Payment Address: 15wQ831BoNnEMEVsfvF4mS5e94QL4RYGTc

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    • Evanesco is based on Polkadot ecology, committed to building the next generation of decentralized new privacy financial ecology protocol family in a fair and reliable way. Relying on the underlying secure privacy network, mainstream cross chain adaptation mechanism, powerful privacy transaction engine, it can build a more equitable ecology network of privacy finance.
    • The open, transparent and difficult-to-tamper characteristics of the block chain have accelerated the emergence of modern decentralized finance, but in some fields these characteristics are not suitable for the development of financial activities, such as transaction information of large encrypted currency. Whether it is in the cryptocurrency or the traditional financial field, it is very sensitive to the transfer of large-value assets. The transfer information of top Exchange`s address can even affect the market direction. For both parties, it is more hoped that the key transaction amount can be concealed. The privacy transaction process reduces the impact on the market. We belive that a complete decentralized financial network must has a privacy layer. Users are concerned about income risks and account transaction privacy the most in using any finance-related application. Especially when DeFi leads modern finance, the privacy layer, will be an item of standard configuration.
    • Evanesco's vision is to build the next generation of financial ecology in a fair and reliable way. Based on privacy network and privacy transaction technology, it will be committed to breaking through the protocol stacks of public chains, private transaction and DeFi, breaking the liquidity boundary of encrypted assets, and building a robust DeFi operation platform. With the private P2P network, friendly and standardized trading interfaces will be provided for various encryption ecological access, and the privacy transaction liquidity be shared with Polkadot ecosystem, other public chains, exchanges, wallets, OTC, DAO and other encryption ecology.

    Project Detailsโ€‹

    The three main features:

    • Privacy Cascade Network The bottom layer of EVA runs on the privacy layered network, providing development and privacy communication services for the entire network routing layer. Through the construction of a hierarchical decentralized P2P network, EVA combines the open PoW mining network with the privacy trading network, fairly balancing fairness and privacy security.

    • GPoW

      In order to provide a decentralized, more efficient and consistent consensus system for the entire financial ecology, EVA uses GPoW consensus algorithm to perform token mint and final consistency identification. GPoW consensus includes two layers of consensus mechanisms, which are nested, influence each other and play different roles. GPoW algorithm not only provides almost real-time, asynchronous and safe finality similar to GRANDPA algorithm, but also can fairly distribute new tokens according to PoW, enabling a wider range of communities to go in for the construction of the whole ecology.

    • Privacy Transaction

      Evanesco has implemented the balance hiding technology based on Balance account by constructing scope proof, and introduced zero knowledge proof technology into the intelligent contract system, which allows transactions between open accounts and private accounts, and transfer and audit between different accounts. Even if the network miners decrypt the encrypted network layer and view the transaction data Payload, the specific transaction information cannot be decrypted due to the private transaction agreement.

    All the documents are opened in https://github.com/Evanesco-Labs/docs, the docs explain the Evanesco Protocol and associated subsystem, and they will be updated continually.

    Developer can try examples from https://github.com/Evanesco-Labs/xv-crypto/, more demos will be listed soon.

    Ecosystem Fitโ€‹

    Problems such as insufficient liquidity, traceability of transactions and visibility of account book owners during decentralized transactions exist in most standard and non- fungible assets in the current encryption ecology.

    A complete decentralized financial network must has a privacy layer. Users are concerned about income risks and account transaction privacy the most in using any finance-related application. Especially when DeFi leads modern finance, the privacy layer, will be an item of standard configuration.

    Phala Network is privacy preserving data protocol in web3, and it implement Intel-TEE to handle privacy compute. EVA is totally different, it implement the privacy network protocol to protect the user end and a zkp/bulletproof like algorithm to hide the private asset information.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Name of team leader: Kim Pfeiffer
    • Names of team members David Pen, Lily Lin,Willam Wang

    Contactโ€‹

    • EVANESCO FOUNDATION LTD, 3 Fraser Street #05-25 Duo Tower Singapore 189352.

    Team's experienceโ€‹

    • Kim Pfeiffer: Systems and Development for Yale University;Financial Software for Multiple Entrepreneurs; PCI Financials and Banking for York & Chapel

    • Willam Wang: Dev for combchain; Served as R&D director and CTO of listed companies such as LeEco and CreditEase; More than ten years of experience in technology research and development and management in large-scale Internet industries;Has rich experience in blockchain and Internet finance business.

    • Lily Lin: Senior Visiting Scholar, St. John's University; Doctor of Technical Economic Management;

      Manager of WPP Group; Technology and finance expert; Investment and financing management expert

    • David Pen: Early Bitcoin mining evangelist; Co-founder of a large mining pool; Operating multiple mines in Sichuan and other places with hundreds of thousands of mining machines; Founder of a large community

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months

    • Full-time equivalent (FTE): 3

    • Total Costs: 1 BTC

    • In the first milestone, the features for the private network protocol will be implemented as a library named P2Private and integrated the API with substrate. After that the substrate node could be deployed like a Tor-network to surpport private communication.

      The private network protocol establishment steps are as follows:

      1. The nodes will establish DHT databases of their adjacent points at the network layer according to the K-bucket algorithm, and set up internal data tunnel routes, which default to 3 hops, in which each node will form routes with other nodes;
      2. After the client or node packages the message, it locates the access point of data tunnel routing through DHT table and sends the transaction to the access point node;
      3. Each data tunnel is established as per TOR protocol.
      4. The tunnel has a re-planning time. If the planning time arrives and data is being transmitted, the tunnel will be re-planned after a period of delay.

    • In the second milestone, we will create a client to communicate with each other based on the testnet setup in the first milestone.

    The following components will be included:

    • Sbstrate Node with P2Private API
    • A Message Client
    • The P2Private library and SDK
    • Tutorial documentation
    • All code written in Rust

    Milestone 1 โ€” private network node based on substrateโ€‹

    • Estimated Duration: 3 months
    • Full-time Equivalent (FTE): 2
    • Costs: 0.7 BTC
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can running substrate to support private netowork service
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.P2Private-rust RepoWe will create a new lib named P2Private written in rust which can implement the private protocol
    2.private service nodethe substrate node integrate with P2Private-rust module and perform as a Tor-like network
    3.Test-NetA Test-net could be tested by limited users would deployed.

    Milestone 2 โ€” private client based on the P2Privateโ€‹

    • Estimated Duration: 3 months
    • Full-time Equivalent (FTE): 1
    • Costs: 0.3 BTC
    NumberDeliverableSpecification
    0a.LicenseUnlicense
    0b.DocumentationThe documentation will be provided to show how to integrate the P2Private function in client
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.P2Private-cliIt would implemented in rust. We will create a client to communicate with each other based on the private substrate network

    Future Plansโ€‹

    After complete the network protocol and privacy transaction, EVA will

    • start POW miner design and deployment
    • Cross-chain cooperation with other project
    • start nft privacy and MPC framework development

    Additional Information โž•โ€‹

    • Now we haven`t apply for other grants except for an ongoing general grant which contain the privacy algorithm protocol prototype and miner development .
    - + \ No newline at end of file diff --git a/applications/faceless.html b/applications/faceless.html index 94902ec6337..bee8755c571 100644 --- a/applications/faceless.html +++ b/applications/faceless.html @@ -4,7 +4,7 @@ Faceless Protocol | Web3 Foundation Grants - + @@ -28,7 +28,7 @@ 2020.

    [SuterusuWP][Huang Lin. Suterusu white paper, 2019](https://github.com/suterusuteam/suterusu-documents)

    [SuterusuWebsite] https://suterusu.io/.

    [tornado] https://docs.tornado.cash/tornado-cash-nova/logging-in-tornado-cash-nova.

    [AztecWP] Zachary J. Williamson, The aztec protocol, 2018

    [BonehF03] Dan Boneh and Matthew K. Franklin. Identity-based encryption from the weil pairing. SIAM J. Comput., 32(3):586-615, 2003.

    [LinSZF13] Huang Lin, Jun Shao, Chi Zhang, and Yuguang Fang. CAM: cloud-assisted privacy preserving mobile health monitoring. IEEE Trans. Inf. Forensics Secur., 8(6):985-997, 2013.

    - + \ No newline at end of file diff --git a/applications/fair_squares.html b/applications/fair_squares.html index dc9d7187022..ef8b44fac5f 100644 --- a/applications/fair_squares.html +++ b/applications/fair_squares.html @@ -4,7 +4,7 @@ Fair Squares (FS) | Web3 Foundation Grants - + @@ -567,7 +567,7 @@ RE .-> | represents| IS end

    Milestone 5 โ€” Matching, reccuring payments and UI developmentโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how the user can navigate through the interface.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article and video that explains what actions you can take on the front-end does and the build up of the several pages.
    1.Pallet: tenancyWe will expand on the tenants registration, we will be keeping when a tenant is registered, what region they are applying for and how big their household is. We will also expand on this structs on the asset side. The representative can ask for more information in which the user can share it with the representative. The representative will propose a tenant to the letter.
    2.Pallet: paymentsThe renter will have to place a deposit and the monthly rent in. The rent can be credited per x-block basis. The recurring payment can also go in the negative if the renter cannot pay the rent on time, let's say per rule-of-law 14 days and it signals the representative after this time to get in touch.
    2.UI & frond-endDuring the time of development also in previous milestone we will have produced several wire-frames and a front-end frame we will work with. We want to have for each main section page, which are: Funding, Onboarding, Voting, Finalizing and Renting. These will be the most used functionalities. If time allows also a front-end a dashboard that shows the total homes that are on the platformm, the value locked etc. This will be the biggest effort of this milestone.
    2.Total product FSThe combination of the previous milestones and this one, with UI gives us the us the automation the first iteration of the Fair Squares platform that will allow us a crowdfunded fair housing protocol, with an simplified legal acceptance framework.

    Future Plansโ€‹

    Short to medium termโ€‹

    Long Termโ€‹

    In 2-4 years from now we aim to co-founded, co-researched a legal framework with other institutions where the outlook for deployment is more clear than now. We are laying strong ties with municipalities or state-level governmental instituions that will allow us the sand-box enviroment to implement this. We aim to organize from the bottom-up with other parties that find this relevant and iterate together with them. But we like to take it step for step and this grant will give us the fundamental code that will showcase it's techincally safe and possible, while recorded right.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We have been around in the ecosystem for some time and we knew from the W3F grants program since it's inception.

    Work you have already done?

    - + \ No newline at end of file diff --git a/applications/faterium.html b/applications/faterium.html index 8e9f68177c5..c4a2a787f95 100644 --- a/applications/faterium.html +++ b/applications/faterium.html @@ -4,13 +4,13 @@ Faterium | Web3 Foundation Grants - +
    Skip to main content

    Faterium

    • Team Name: DodoRare, Inc.
    • Payment Address: 0x6f083B9888D65A7CA7b8936982BE8Be328eF6d56 (ERC20 USDT)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Faterium is a decentralized voting platform that provides business tools for content creators to monetize their projects and directly engage the community on important decisions. It helps game developers, creators and artists to easily create own assets, distribute them and earn by providing crowdfunding polls on various topics that are important to their community.

    Problem Summaryโ€‹

    Services like Patreon help content creators get support from their community, and Kickstarter helps raise money for a new creative projects. These are very good services and everyone is used to them, but we see opportunity here: the community canโ€™t directly influence the creation process and be truly involved into it.

    Solution Summaryโ€‹

    We have found a solution that can give creators new opportunities to monetize their project and directly involve their community in the creation process through regular voting and events with valuable rewards.

    We will provide a simple interface where creators can create special polls in a few clicks, set which currency will be used for voting, and then invite the community to participate in it.

    Also, we will make convenient tools for creating, distributing and integrating of own assets and NFTs, thanks to which people who are not familiar with Web3 will be able to use the power of decentralization in their projects such as games, online books, movies and comics.

    We integrate social elements into the platform, such as rating, discussion forums or community-created proposals. And it will give creators even more ways to interact with the community.

    In addition, we will make SDKs and APIs to help integrate our platform into existing services and projects, such as games, websites for reading books or comics, or websites for watching movies, which will open up endless possibilities for adopting the technology.

    Glossaryโ€‹

    • User Profile - a collection of settings and information associated with a user.
    • Community - a customizable space where polls, discussions, and events of a specific community will be located, it can be either a personal space or a project space.
    • Crowdfunding Polls - a way for creators to decide what community wants and raise money for a project or idea. Authors themselves determine which currency they want to use for voting and what percentage they will receive after the end of the poll.
    • Poll Rewards - any kind of reward that users can receive after winning the poll. It can be either a unique NFTs or any gifts personally from the author of the poll.

    Infrastructure Schemeโ€‹

    Faterium - Faterium Platform

    Wireframesโ€‹

    1. Main Page2. Categories3. Community
    4. Poll5. User Profile6. Create Community
    7. Create Asset8. Create Poll9. Profile Settings

    Substrate and Backend APIโ€‹

    image

    Usecasesโ€‹

    The Faterium platform can be useful for a large pool of content creators and projects. Such as game developers, comic and manga artists, book writers, movie and anime creators, bloggers and streamers, journalists and politicians, etc. Faterium can be used in all areas where the creators would like to give the community the tools to vote and influence. Now, we would like to show a couple of interesting use cases of the platform.

    Simplified user flow diagramโ€‹

    image

    Comics Creatorโ€‹

    Imagine talented comics creator - Bob Johnson, that has several popular multi-series comics and thousands of fans waiting for new chapters. Bob is looking for a new way to get funding for his projects, and at the same time get feedback from his community.

    He comes to the Faterium platform, configures user profile and creates his first crowdfunding poll, in less than 30 minutes. Bob sets the duration of the poll to 3 days, selects DOT as the voting currency and also sets what will happen after the poll ends - 50% of winners assets go to the poll creator, and winners will receive remaining 50% of assets alongside unique NFTs as reward.

    In the poll, he asks his community a question: "Which comic should I develop this month?". Also, Bob describes options in the poll and give detailed information about what he will do after the end of the poll. Then he posts the poll with unique link in his social media. Fans are happy that the author is preparing new series of comics and they decide to help him by voting. They log in via the polkadot{.js} extension, choose one of the options in the poll and send assets.

    After the end of the poll, the Bob receives finances that will help him to create new series. At the same time, fans took part in an important decision and supported their favorite author, and of course were rewarded with rare NFTs! Looks nice!

    Game Developerโ€‹

    Let's look at another example - a famous game developer. The developer wants to launch the game on as many platforms as possible, so he needs to integrate cryptocurrency into the game in a soft way. Also, he wants to do something unique and increase the involvement of his community.

    He chooses to use the Faterium platform, configures user profile and creates a community on the platform. Since his game has a very interesting plot and characters, he decides to create an asset for each key character in the game. Thanks to a user-friendly interface, he mints new assets in a short time. Then, with the help of the Faterium SDK, he adds these assets to the game as special rewards for players and announce the new feature on his social media.

    Then, he releases new story missions in the game, and players who have assets of their favorite characters, now can directly influence on how the game's story develops by spending assets and voting on various plot twists and character decisions. Players who love the story of the game now have cool tools to interact and influence the game, and last but not least, they can freely sell and buy these assets on decentralized marketplaces.

    It is important to note that game developers who already have own tokens or assets may not create a new one, but use an existing one by bridging it to the Faterium platform.

    Ecosystem Fitโ€‹

    The main goal of Polkadot is to create a decentralized network where users are in control. Faterium empowers as many people as possible to create safe, fair, universal voting polls on any topic possible. In addition, the Faterium platform will not focus only on its own Substrate Network - our main development goal is to cover as many Web3 networks as possible along with Web2. All this will help attract a lot of people who are not familiar with the crypto, influencers, other projects and games. That's why Polkadot and Faterium are compatible and can help each other make Web3 even more popular.

    Team ๐Ÿ‘ฅโ€‹

    • Registered Legal Entity: DodoRare, Inc.
    • Registered Address: 651 N Broad St Suite 206, Middletown, DE 19709.

    Contactโ€‹

    Team membersโ€‹

    Team's experienceโ€‹

    • Crossbow - Our second W3F grant to enhance and improve Mobile Game Framework: Cross-Platform build tools and toolkit for Rust and Substrate community. By our team.
    • Narnao Labyrinth - Our team has been working on this game project for more than a year. Some unique features originally from Narnao - now evolved into something bigger inside Faterium. The launch of the Narnao Labyrinth is tightly connected to the launch of Faterium, it will be a flagman project that will show most of the features and will initially bring the gamer community to Faterium. By our team.
    • Mobile Game Framework - Our first team Web3Foundation grant, mobile building tool. By our team.
    • Substrate Atom and VSCode plugins - Have contributed some code to Web3Foundation Grant for Substrate VSCode and Atom plugins while worked in outsource company. By enfipy.
    • Polkadot CosmosSDK Integration - Also, contributed to another Web3Foundation Grant while worked in another outsource company. Built logic behind ABCI pallet and Substrate with Tendermint. By enfipy.

    Team Code Reposโ€‹

    Website Links:

    Github Organizations:

    Repositories:

    GitHub accounts of developer team:

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 7 weeks
    • Full-time equivalent (FTE): 5
    • Total Costs: 30,000 USD

    Milestone 1 โ€” Crowdfunding Pollsโ€‹

    • Estimated Duration: 4 weeks
    • FTE: 5
    • Costs: 17,000 USD

    The main goal of the Milestone 1 is to create base functionality for Crowdfunding Polls. To make it possible - we will create Substrate Node that will contain basic template pallets, alongside with Pallet Assets (for creating assets), and Pallet Scheduler (for scheduling polls endings). Also, we will create a new Pallet called Crowdfunding Polls Pallet.

    To minimize storage on chain (as polkassembly and Polkadot do) - we will create a Golang server that will embed IPFS node and PocketBase (or launch nearby in separate docker containers), to create the best User Experience and make it possible to store big media files as IPFS CID in database. To make it simple and straightforward in usage - we will launch test Substrate Network with our pallet on our servers, and create pages for creating Polls, and voting (with help of polkadot{.js} extension).

    Please, see the Substrate API design of the Faterium Platform above.

    NumberDeliverableSpecification
    0a.LicenseWe will add Apache 2.0 Licenses to all repositories.
    0b.DocumentationWe will provide both inline documentation of the code and a live demo.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Crowdfunding Polls PalletAs described above - we will create a Substrate Pallet for creating Crowdfunding Polls.
    2.Configure Substrate NodeAs described above - we will create a Substrate Node from template and integrate Pallet Assets, Pallet Scheduler and our Pallet Crowdfunding Polls.
    3.Faterium Server with PocketBase and IPFSAs described above - we will create a Golang Server with API through PocketBase for uploading polls details in IPFS Node.
    4.Launch testnet Substrate network on the serverAs described above - we will setup and run Faterium test network on our servers to make sure that everything works as designed.
    5.Pages for creating Polls and voting on itAs described above - we will create pages for creating and using Crowdfunding Polls to make sure that all functionality is working well.

    Milestone 2 โ€” Profiles, Communities, and Pagesโ€‹

    • Estimated Duration: 3 weeks
    • FTE: 5
    • Costs: 13,000 USD

    The main goal of the Milestone 2 is to create UI design (see wireframes for the reference) and all main functionality of Faterium Platform: Communities, User Profiles, Categories, Assets, Crowdfunding Polls. After completion of Milestone 1 - we will have Golang Server that we will extend with new functionality: wallet connect, user profile configuration, community creation, asset creation, voting.

    Please, see the Backend API design of the Faterium Platform above.

    Also, we will prepare and publish and Article, that will explain a new concept of Crowdfunding Polls.

    NumberDeliverableSpecification
    0a.LicenseWe will add Apache 2.0 Licenses to all repositories.
    0b.DocumentationWe will provide both inline documentation of the code and a live demo.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains the concept of the Faterium Network, it's features, and usecases. More general-public-oriented version of what described in this application.
    1.Create design for Faterium dAppAs described above - we will create a UI design for Faterium Platform.
    2.Extend Faterium serverAs described above - we will update and extend Faterium Server to make it work as designed.
    3.All web pages for dAppAs described above - we will create all website pages from design and connect them to Faterium Server / Faterium Network node.

    Future Plansโ€‹

    1. IPFS Cluster Integration.
    2. DEX + Subsidizing System / Fuel-Gas Tanks.
    3. Anti-spam System + Account Verification.
    4. Author & Project Verification.
    5. Faterium API & SDK.
    6. Faterium Android and iOS Apps.
    7. Faterium Discord and Telegram Bots.
    - + \ No newline at end of file diff --git a/applications/faucet-bot.html b/applications/faucet-bot.html index 62051a85bc4..fa241f6fac6 100644 --- a/applications/faucet-bot.html +++ b/applications/faucet-bot.html @@ -4,13 +4,13 @@ Generic sybil-resistant chat based faucet bot | Web3 Foundation Grants - +
    Skip to main content

    Generic sybil-resistant chat based faucet bot

    • Team Name: Nikita Orlov PR
    • Payment Address: 0x49F19FA78C4E766b8C5592e53CC35b1411a5E11f (USDC/DAI)
    • Level: 1

    Project Overviewโ€‹

    Overviewโ€‹

    Sybil-resistant faucet is a generic chat bot based faucet solution that can be used on any existing parachain (substrate-based chain, either pallets or ink! smart contracts).

    Project Detailsโ€‹

    Mockupโ€‹

    bot that handle all messages like /request {wallet_public_address}, and trying to send tokens if it eligible

    Technology stackโ€‹

    • Golang
    • Redis
    • Discord sdk (go)
    • Matrix sdk (go)

    Architectureโ€‹

    architecture

    Configurationโ€‹

    To make the faucet generic, it will store its configuration settings in .env file which will include the following settings:

    • DRIP_CAP - how many tokens to send per request
    • DRIP_DELAY - how often user's can request to drip tokens (in ms)
    • REDIS_ENDPOINT - Redis instance endpoint
    • RPC_ENDPOINT - Substrate node endpoint
    • FAUCET_ACCOUNT_MNEMONIC - mnemonic of faucet's wallet

    Based on addons, it can be credentials for any platform, what will be used, in based version discord/matrix.

    Ecosystem Fitโ€‹

    Many dApps are facing an issue where itโ€™s difficult to onboard new users. Thus, the goal is to simplify the process by making it easier for parachain and dApp developers to spin up their own faucets, and give users free tokens without people exploiting the system. In order to make the system sybil-resistant, centralised solutions like Discord, Matrix and any other chat based platforms, that will uniquely identify users, and enable requesting tokens to the account only once per given time period.

    Some similar projects include:

    The advantages of this project are that similar projects are implemented specifically for one platform, this project will be implemented on the interface, and the platforms (Discord, matrix and etc) will be like addons (classes) that correspond to the interface, which will allow you to easily connect new platforms, do not depend on the implementation of platforms, will allow you to run unlimited number of platforms at the same time.

    That is, to integrate a new platform, you will need to implement an interface, and cybil resist, message processing and other functionality will already work out of the box. Also, the implementation of new functionality requires only a change in one point of code, if this does not affect the interface.

    Teamโ€‹

    Team membersโ€‹

    • Nikita Orlov

    Contactโ€‹

    • Registered Address: Jurija Gagarina 231, Beograd
    • Registered Legal Entity: Nikita Orlov PR

    Team's experienceโ€‹

    ETH Waterloo 2019 hackathon prize-winner, is a engineer with over 8 years of experience in development and integration of fault-tolerant high-loaded SaaS IT solutions including relevant experience in blockchain solutions.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1.5 month
    • Full-Time Equivalent (FTE): 1.5 FTE
    • Total Costs: 7,500 USD

    Milestone 1 โ€” Implement the Faucetโ€‹

    • Estimated duration: 1.5 month
    • FTE: 1.5
    • Costs: 7,500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationI will provide both inline documentation of the code and a tutorial that explains how a developer can spin up his/her own faucet.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.ArticleI will publish an article that explains how the faucet works, why it was created, and how it can be used by developers.
    1.Universal message interface (UMI)Implement golang interface (contract) to unify all chat providers to one standart, so we can easily use abstraction
    2.DiscordGolang implementation of discord integration using open-source SDK, that support interface of UMI module
    3.Matrix.orgSo same as discord, golang module
    4.Wallet statusGolang module that control user/wallet faucet drip, so user will be able to receive only once in a certain period of time
    5.Faucet dripGolang module that can send token to user wallet address on substrate based chain, RPC library to substrate chain through open-source library https://github.com/centrifuge/go-substrate-rpc-client
    6.Substrate demoImplement demo example on substrate template node

    Future Plansโ€‹

    • Keep adding another chat providers.
    • Keep maintaining the project in case of potential issues.
    • Analytics for owner with dashboard UI.
    - + \ No newline at end of file diff --git a/applications/fidi-dotsight-analytics.html b/applications/fidi-dotsight-analytics.html index 7c8e7968192..8b816f7a1c6 100644 --- a/applications/fidi-dotsight-analytics.html +++ b/applications/fidi-dotsight-analytics.html @@ -4,7 +4,7 @@ FiDi DotSight: Analytics Data Platform for DotSama | Web3 Foundation Grants - + @@ -23,7 +23,7 @@ | dApp names | Historical balance per dApp |

    Language Agnostic Analytics Since DotSight aims to be a combination of presentation and querying layer on top of the higher-level metrics above, it will abstract away the smart contracts implementation details and functionality, i.e., EVM, non-EVM, Vyper, WASM, or others will be supported.

    Ecosystem Fitโ€‹

    As on-chain analysis becomes an increasingly important field, there is a growing need for a platform that enables users to access and query high-quality data easily. Our proposed project is an optimal fit for the Polkadot and Kusama ecosystems. The current options for querying data via GraphQL are limited to backend services such as Subquery and Subsquid; however, our proposed data interface will provide a user- and developer-friendly way to surface customized analytics, similar to Dune Analytics in the Ethereum community; however, with more flexibility, customization, and at a higher level of abstraction.

    Our decentralized platform will enable analysts and power users to interactively query and visualize high-quality data, creating custom charts and visualizations to share metrics with others. By easing the process of building dashboards, sharing data visualizations, and integrating data providers, we will encourage projects to create custom dashboards to share data with the Polkadot & Kusama community.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Registered Address: Unit 2A, 17/F, Glenealy Tower, No.1 Glenealy, Central, Hong Kong SAR

    Registered Legal Entity: FiDi Tech Ltd

    Team's experienceโ€‹

    FiDi brings together a team of builders and venture-backed operators with expertise in distributed systems, web3, data analytics, science, and infrastructure engineering at the internet scale.

    Anton leads FiDiโ€™s engineering, particularly the data and backend infrastructure. Most recently, he has been an Engineering Manager supporting marketplace teams at Yandex. Antonโ€™s key expertise is in data and distributed systems at scale.

    Kirill leads FiDiโ€™s mobile and NFT data development. Most recently, he has been a Senior SWE at Yandex, focusing on the front end. Kirillโ€™s key expertise is in cross-platform mobile and web development at scale.

    Roman is a venture-backed founder and engineering leader passionate about building great products. He previously led the data organization at Twitter, particularly Data Engineering, Science, ML, and Analytics โ€“ scaling the core of their ad tech and analytics at scale.

    Shaun is a seasoned operator and engineering leadership recruiter. He previously supported product teams at Google, Twitter, and Meta, among others. Both Shaun and Roman are founders in the past.

    Finn leads the design at FiDi and brings in his experience supporting creative work at Riot Games and Porsche Design. He also runs his own design agency, 0xsphere, where he challenges the boundaries of visual user experience in web3.

    We all came together to found FiDi in 2022 with a mission to democratize access to data in web3, initially as a portfolio tracker and, more recently, as a fully-fledged high-precision analytics platform. Our strengths lie in the ability to tackle complex technical challenges and deliver high-quality products for our users

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    The basis for the project has been established. FiDi today offers four default dashboards available for the community (one metric, three metrics, a pie chart, and an asset list) and a fully customizable advanced analytics dashboard currently under development and in open beta with ambassadors and core teams of several parachains. Subquidโ€™s recent release of GiantSquid API makes surfacing metrics and deploying new squids intuitive for developers and L1 operators.

    This proposal aims at delivering (a) a data interface connecting the squidsโ€™ query code and customized dashboards and (b) both streamlining and decentralizing the productionization of new analytics queries for the community by community.

    All infrastructure deliverables belong to the teamsโ€™ domains of expertise and serve as a continuation of our previous track record.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Data Interfaceโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide documentation on every supported metrics class and an educational tutorial explaining the typical way to interpret the data, deploy a data interface configuration, and select the desired dashboard.
    0c.TestingCore functions will be fully covered by a unit and integration tests suite to ensure robustness, deployment, and serving times.
    1a.GiantSquid data funnelingWe will extend the existing data streaming infrastructure to support an arbitrary query to GS and user-built squids.
    1b.Data Aggregation moduleWe will provide support for user-specified (GraphQL or SQL) aggregation logic that would be inputed via the data interface and invoked at the streaming stage.
    1c.Off-chain sourced addresses supportWe will provide rudimentary support for additional data materialization parameters, e.g., pricing via liquidity pool addresses. This will be extended to any off-chain data in an oracle-like fashion in future milestones.
    2a.Data Interface for developersWe will provide a configuration-based interface (initially via git pull requests, then automated in Milestone 2) with key specifications for the new views. We will leverage React and Typescript on the frontend and Typescript with Nest and PGSQL on the backend.
    2b.Schema mapping and morphingWe will provide a configuration-based paradigm for specifying: the desired metrics mapping, aggregation logic, upstream GiantSquid URI, and desired materialized view.
    3a.Dashboards: Default Analytical ViewsWe will integrate the default views, i.e., pie chat, 1/3-metrics view, and list of assets, with the data interface and make it available for the ad-hoc developer deployment. For 3a-c UI components, we will similarly rely on React + Typescript.
    3b.Dashboards: Advanced Staking ViewWe will integrate the advanced staking view, e.g., the dApps names, nominator TVLs, balances, rewards, and ranks, with the data interface and make it available for ad-hoc developer deployment.
    4a.Lighthouse use cases: Squids for Wallet-specific metricsWe will implement new squids in GraphQL surfacing wallet-specific metrics for two parachains with the following metrics that need to be surfaced via GiantSquid: Free tokens, Vesting, EVM Deposits, and dApp names.
    4b.Lighthouse use cases: Squids for dApp-specific metricsWe will implement new squids in GraphQL surfacing wallet-specific metrics for two parachains with wallet-specific metrics for dApps: TVL change per dApp, Active (UAW) and net new wallets per dApp (x2), historical Transactions / Volume / Balance per dApp (x3).
    4c.Lighthouse use cases: customized dApp viewsAs the first two use-cases, a feasibility proof and an accelerator, we will provide the community with a fully integrated customized dApp analytics dashboard leveraging the data interface (2a-2c), the advanced staking view (3b), and the data aggregation module (1a-1c).

    Milestone 2 โ€” POC Dashboards with Network-, dApp-level and custom Metricsโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide documentation on every supported metrics class and an educational tutorial explaining the typical way to interpret the data, navigate the developer UI, specify the required metadata, deploy a data interface configuration, and select the desired dashboard.
    0c.TestingCore functions will be fully covered by a unit and integration tests suite to ensure robustness, deployment, and serving times.
    1a.dApp-level signals: collator metricsWe will generalize prior work from Milestone 1 to span collator/nominator activity and make metrics such as uptime, block production rate, block processing time, rank/nominator rank, name, and value locked available in the views. For 1a-2a, the respective GraphQL squid query and GiantSquid's code are also in scope; the UI components will be written in React + Typescript, and the backend code in Typescript + Nest + PGSQL.
    1b.dApp-level signals: user activityAdditionally, the dApp-specific user activity metrics will be surfaced, e.g., UAW, net new wallets, historical transactions, volume, and balance per dApp. Respective squid query and GS code are also in scope.
    2a.Network-level signalsWe will generalize prior work from Milestone 1 to span L1-level metrics and activity made available in the developer UI, e.g., UAW per network, number of new wallets, adoption rates, unstaked tokens currently in wallets, tokens in circulation, and tokens staked or locked. Respective squid query and GS code are also in scope.

    Milestone 3 โ€” Developer UI & Automated View Deploymentโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide documentation on every supported metrics class and an educational tutorial explaining the typical way to interpret the data, navigate the developer UI, specify the required metadata, deploy a data interface configuration, and select the desired dashboard.
    0c.TestingCore functions will be fully covered by a unit and integration tests suite to ensure robustness, deployment, and serving times.
    1a.dApp-level signals: collator metricsWe will provide an intuitive web interface for specifying the desired metrics mapping, aggregation logic, upstream data provider, and desired materialized view (dashboard). The UI willleverage Typescript + React; and Nest + CloudSQL (PGSQL) + Typescript on the backend.
    1b.Online testing & deploymentWe will provide an intuitive web interface for querying the new view for deployment and validating its configuration. The UI's part technology choices is the same as 1a.
    2a.Deployment validation & View statusWe will implement testing and validation layers to ensure the user-inputted configurations for newly spun-up views and queries are performant. We will surface the view โ€œstatus,โ€ e.g., up, down, missing data, and similar.
    2b.Automated and ad-hoc deploymentWe will decouple the existing infrastructure to support ad-hoc and scheduled deployments for newly created views. The CI/CD and automation for 2a-b will rely on scheduled App Engine workers.
    2c.Data interface: view constructionWe will provide developers with the ability to select a desired analytical dashboard from the pre-selected collection (see five views explained in the architecture section; fully customizable views will make it to future milestones). These UI components will also be implemented via React and Typescript.
    2d.Data interface: DeploymentWe will provide developers with the ability to schedule their customer viewโ€™s deployment (automatically at recurring times in the future milestones). The deployment action will be a UI module, and the propagation/consensus will occur via GitHub at first and via a PGSQL query in future milestones.

    Milestone 4 โ€” Interactive SQL Query Engine for Viewsโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide documentation on querying methodology, e.g., functions, operators, data types, and statement reference; as well as an educational tutorial explaining the typical way to run the queries, associate them with the views, interpret the data, navigate the developer UI, and share the views.
    0c.TestingCore functions will be fully covered by a unit and integration tests suite to ensure robustness, deployment, and serving times.
    0e.ArticleWe will publish an announcement article capturing the work completed in the grant along with the educational guides and success stories, enabling users to further leverage and expand DotSightโ€™s functionality.
    1.FiDi SQL implementationWe will provide a query engine for blockchain data. Initially forked from TrinoSQL and/or harmonizer, we will extend the functionality to support variable views and embed GraphQL upstream queries. We'll simialrly rely on Typescript + Nest + CloudSQL (PGSQL) for the query engine's implementation. FiDi SQL Engine UI Example
    2.SQL Editor View UIWe will augment the no-code view developed in Milestone 2 with SQL functionality allowing users to rehash the existing views as well as create new ones. The Editor UI will include the runner log, a tree of dependencies and suggested resources, and the editor interface itself. See the UI direction in the following wireframe:
    3.Advanced Querying DocumentationWe will provide a comprehensive guide for optimizing the queries, both language- and database-specific, along with real-world examples

    Future Plansโ€‹

    DotSight will provide a scalable, incentivized platform for developers to contribute to the Polkadot ecosystem's growth by integrating new protocols and on-chain metrics. We aim to continue extending the number of parachains with advanced analytics supported on FiDi, the breadth and depth of analytical dashboards, and the pre-developed squids available.

    For further development, we will also streamline the user/developer funnel to the point where simple SQL/GraphQL or no-code user flows suffice to seamlessly productionize and share new dashboards matching user needs. For the further go-to-market, we plan to attract content creators and crypto influencers by offering customizable portfolio views, analytical dashboards, and reward-based contributions to extend coverage and analytics on the platform.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Via Subsquid founders - Marcel & Dmitry and the W3F staff - Sebastian & David.

    Follow Our Socials

    - + \ No newline at end of file diff --git a/applications/fractapp.html b/applications/fractapp.html index ca43e971e3d..af06beebe6a 100644 --- a/applications/fractapp.html +++ b/applications/fractapp.html @@ -4,14 +4,14 @@ Fractapp | Web3 Foundation Grants - +
    Skip to main content

    Fractapp

    • Proposer: CryptoBadBoy
    • Payment Address: 3HrP78rbmafpfBsU49LCpywYrNcscnKd76

    The above combination of your GitHub account and payment address will be your unique identifier during the program. Please keep them safe.

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Please provide the following:

    • A brief description of the project.

    Fractapp is a messenger with a cryptocurrency wallet. Cryptocurrency address is hard to remember so users have a problem send cryptocurrency to another user. Fractapp creating a simple ecosystem for users. Users can send crypto in chats and use DApp chat-bots. Fractapp will be available on Android and later IOS.

    And we have old DEMO for the hackathon.

    • An indication of how you will integrate this project into Substrate / Polkadot / Kusama.

      The integration will involve creating a mobile app on Expo (React Native) and backend services.

    • Mobile App:

      • Non custodial wallet for Polkadot and Kusama (creating, backup, wallet details, transaction info)
      • Payment chat is a chat for only send cryptocurrency. These milestones haven't support messages in chats. But we will add messages later.
      • Chat-bots for DApp

    • Backend services:

      • Push-Notification service is a service which will notify a user about received transactions
      • Profile service is a service that stores not public information about the user (Nickname, Twitter, Email, Phone Number).

    • CBI (Chat-Bot interface):

    CBI is the interface between Fractapp and your chat-bots. It can be summarized in the following algorithm:

    1. To call the bot, the user must send a request to start.
    2. Bot service must return the user interface (button name, image, and trigger name)
    3. The user clicks a button and sends the request with the trigger name to the chat-bot service.
    4. Chat-bot processes the user's request by the trigger name.. If the user doesn't need to make a choice then the service returns the transaction which the user will sign.
    5. User signs or cancels transactions.

    Example, Decentralized Exchange Bot (exchange DOT <-> KSM):

    1. User sends a request to start.
    2. Chat-Bot returns response with 2 buttons: DOT, KSM
    3. User chooses DOT
    4. Chat-Bot returns the text-editor element to the user
    5. User sends a request with text (amount)
    6. Chat-Bot returns transaction (transaction calling Exchange DApp)
    7. User signs and sends transaction
    • An indication of why your team is interested in creating this project.

    Polkadot is one of the most interesting blockchain platforms. We want to help users to just join in polkadot and wallet is the most important module in the platform.

    Project Detailsโ€‹

    We expect the teams to already have a solid idea about the project's expected final state.

    Therefore, we ask the teams to submit (where relevant):

    • Mockups/designs of any UI components

    https://elshandzhafarov326555.invisionapp.com/overview/Fractapp---cryptocurrency-wallet-with-messenger-ckeyvvuh70t3j01bx5mg6e7b0

    • An overview of the technology stack to be used

    Golang, React Native, Polkadot, Kusama

    Ecosystem Fitโ€‹

    Similar projects: Luno/Polkawallet

    We are creating a messenger with a cryptocurrency wallet. This will help the user to interact with each other without a complicated address. Users can exchange currency, use p2p smart-contracts, vote in the DAOs and etc via chat-bots.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Elshan Dzhafarov
    • Anastasiya Strashnikova

    Team Websiteโ€‹

    personal address will be provided via the invoice form

    Team's experienceโ€‹

    Elshan Dzhafarov:

    Anastasiya Strashnikova:

    • Awesome designer at Fractapp

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-time equivalent (FTE): 3.5
    • Total Costs: 1.2 BTC

    Milestone 1 โ€” Walletโ€‹

    • Estimated Duration: 1 month
    • FTE: 1.5
    • Costs: 0.44 BTC
    NumberDeliverableSpecification
    1.Creating walletProcedure for creating/importing a wallet
    2.Backup walletUser can backup wallet one of method: google drive/encrypted file to phone/ display of seed phrase on the screen
    3.Wallet detailsUser can see balance, transactions, transaction info
    4.DocumentationA standalone document, describing usage
    5.Unit-testingUnit tests covering at least 75% of the code
    6.DistributingWe will provide .apk files for Android

    Milestone 2 โ€” Profileโ€‹

    • Estimated Duration: 1 month
    • FTE: 1
    • Costs: 0.38 BTC
    NumberDeliverableSpecification
    1.ProfileFractapp user profile
    2.Connect phone number/twitter/emailUser can connect social for an account. Any users can search to find user by social.
    3.Push-Notification service for transactionPush-Notification service notifies users about transactions.
    4.Backend for profile storageGolang backend for storing fractapp profiles.
    5.DockerDocker image for backend and push-notification service
    6.DocumentationA standalone document, describing usage
    7.Unit-testingUnit tests covering at least 75% of the code
    8.DistributingWe will provide .apk files for Android

    Milestone 3 โ€” Chatโ€‹

    • Estimated Duration: 1 month
    • FTE: 1
    • Costs: 0.38 BTC
    NumberDeliverableSpecification
    1.ChatOnly payment chat (not have messages). Users will be able to send crypto by email/phone/twitter/nickname.
    2.Staking botFirst built in a chat-bot for staking.
    3.DocumentationA standalone document, describing usage
    4.Unit-testingUnit tests covering at least 75% of the code
    5.DistributingWe will publish on Google Play and F-Droid

    Future Plansโ€‹

    • Apply to App Store
    • Integration Bitcoin and Ethereum
    • Messaging protocol on a substrate
    • Creating popular DApp in chat-bots
    • Group chats for DAO (If user have token then he can join the group)
    • Decentralized voting in a groups
    - + \ No newline at end of file diff --git a/applications/galaxy.html b/applications/galaxy.html index 8150f055ee8..74971468865 100644 --- a/applications/galaxy.html +++ b/applications/galaxy.html @@ -4,7 +4,7 @@ Galaxy: Three-dimensional Web for Polkadot Users | Web3 Foundation Grants - + @@ -25,7 +25,7 @@ Also notice, how curators managing the gallery are being rewarded along with actual painting authors. The same mechanics can be applied to any other type of information: news, expert opinions, financial forecasts, etc. Content Explorers, who rearrange and recommend the most relevant pieces of information in the Web, will be financially incentivized along with actual content creators.

    Future Plansโ€‹

    I believe in opensource community to drive the long term development of the project, and of course can see myself leading it as long as needed.

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? personal recommendation

    - + \ No newline at end of file diff --git a/applications/grantmaster.html b/applications/grantmaster.html index 7bc7c134057..488dfd6bc01 100644 --- a/applications/grantmaster.html +++ b/applications/grantmaster.html @@ -4,7 +4,7 @@ GrantMaster: Web3 Grants Management Application | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ Grants Stats Teams

    To get a feeling how the page will look like, I prepared this Hi Fi wireframe. Keep in mind that some details are missing, due to limitations in the wireframing framework:

    image

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Development of API and Grant Frontendโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationI will provide both inline documentation of the code and a basic tutorial that explains how a user can use the application and its various features.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. I will provide a guide describing how to run these tests.
    0d.DockerI will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleI will publish an article that explains the development process, the challenges faced and how I overcame them, and the functionalities of the GrantMaster application.
    1.Crawler & REST APII will develop a configurable crawler and a REST API that facilitates interaction with the Grants-Program GitHub repository. The crawler will update specific applications or deliveries on demand through the web UI (see Data Synchronization Approach chapter).
    2.GitHub ActionsGitHub Actions will be used to trigger updates in the application whenever new comments, pull requests, or PR reviews are added on GitHub (see Data Synchronization Approach chapter).
    3.Frontend Module: Grants PageI will develop a Grants Page that will display all the grants in a tabular format. Grants will be searchable by team name, application name as well as full text search. They will be filterable and sortable by pull request status, github label, last updated timestamp, number of approvals & rejections of committee members and all this data will also be displayed in the table. The table will be customizable and attributes will be hidable by the user. It will include all grants - both active and inactive.
    4.Frontend Module: Grant DetailsI will create a Grant Details module that displays detailed information about a specific grant when clicked on in the Grants Page. This will include any parsable data, such as team name, level, payment address, team members, legal entity, milestones and their related info (duration, FTE, costs), etc. in a structural manner. In case an application is not fully parsable, the affected attributes will hold an indication. Finally, the application document will be displayed and the links for any related PRs will be displayed.
    5.Frontend Module: TeamsThis module will present all teams involved in the grants in a concise and searchable manner.
    6.Frontend Feature: Grants Committee LenseThis feature will allow a user experience that is optimised to a specific grants committee member. The committee member will be able to provide his username (using simple textbox without authentication) and they'll be able to see in which pull requests for grants applications and amendments they've participated and how long it's been since they last commented on it. I think this will be useful for priorizing grant application reviews.

    Future Plansโ€‹

    I'm planning to implement the following milestone as part of a possible follow-up grant.

    Additional Milestone โ€” Development of API and Grant Frontendโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationI will provide both inline documentation of the code and a basic tutorial that explains how a user can use the application and its various features.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. I will provide a guide describing how to run these tests.
    0d.DockerI will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleI will publish an article that explains the development process, the challenges faced and how I overcame them, and the functionalities of the GrantMaster application.
    1.Crawler & REST APII will extend the previously developed configurable (see Data Synchronization Approach chapter) crawler and REST API to facilitate interaction with the Grant-Milestone-Delivery GitHub repository.
    2.GitHub Actions IntegrationI will integrate GitHub Actions to trigger updates in the application for new comments, pull requests, or PR reviews in the Grant-Milestone-Delivery repository (see Data Synchronization Approach chapter).
    3.Frontend Module: Deliveries PageI will develop a Grant Deliveries Page that will display all the deliveries in a tabular format. They will be searchable by team name, application name as well as full text search. They will be filterable and sortable by pull request status, github label, last updated timestamp. It will include all deliveries - both active and inactive. Also, the deliveries will be included in the team and grant pages that were delivered in M1.
    4.Frontend Module: StatsA Stats module will be developed to provide statistics about the grant applications and deliveries.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? personal recommendation

    - + \ No newline at end of file diff --git a/applications/halva_bootstrapping.html b/applications/halva_bootstrapping.html index e29877d3fbd..6579455158c 100644 --- a/applications/halva_bootstrapping.html +++ b/applications/halva_bootstrapping.html @@ -4,13 +4,13 @@ Halva [Bootstrapping and Scaffolding] | Web3 Foundation Grants - +
    Skip to main content

    Halva [Bootstrapping and Scaffolding]

    This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

    • Proposer: Halva
    • Payment Address: 1837ca1w8WK9yfaVo5Lhgg4sENK2Tq3FgW

    Project Description ๐Ÿ“„โ€‹

    We want to automate the process of bootstrapping a new project using the Halva framework. To do this, we add the cli commands halva-cli init andhalva-cli create. In the basic case, halva-cli init adds the file halva.js and adds the directory with sample tests/tests for standard pallets to the substrate project's directory. The command halva-cli create deploys new code from template e.ghalva-cli create test Token creates a new test case /tests/Token.ts

    Team ๐Ÿ‘ฅโ€‹

    • Members: Wintex
    • LinkedIn Profiles: -
    • Code Repos: https://github.com/orgs/halva-suite
    • Website: https://wintex.pro/en/
    • Legal Structure: individual
    • Team's Experience: Our team develops software about 10+ years and decentralized applications since 2017. We have a great experience with typescript, node.js, and testing frameworks.

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 2 weeks
    • Full-time equivalent (FTE): 1.5
    • Total Costs: 0.728 BTC

    Milestone 1โ€‹

    • Estimated Duration: 2 weeks
    • FTE: 1.5
    • Costs: 0.728 BTC
    NumberDeliverableSpecification
    1.Command initCreate a new Halva project within the existing substrate project directory or creating new substrate project with initialed halva within
    2.Command createHelper to create new test-cases
    3.TestingWrite unit-tests for implemented functions
    4.ExamplesUpdate halva-test-example
    5.TutorialWrite step by step tutorial and publish it
    6.DocumentationsWrite documentations for both commands
    - + \ No newline at end of file diff --git a/applications/halva_framework.html b/applications/halva_framework.html index 81069a95e1b..fafd490e5b7 100644 --- a/applications/halva_framework.html +++ b/applications/halva_framework.html @@ -4,13 +4,13 @@ Halva | Web3 Foundation Grants - +
    Skip to main content

    Halva

    This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

    • Proposer: Halva
    • Payment Address: 1837ca1w8WK9yfaVo5Lhgg4sENK2Tq3FgW

    Project Description ๐Ÿ“„โ€‹

    Halva is a toolchain for improving the experience of developing Decentralized Applications based on Substrate. It provides a high-level way to configure a development environment, interact with Substrate through external API and writing your test cases.

    Halva inspired by Truffle but implements Substrate specific API. It targets testing extrinsics via RPC calls this allows test Substrate (or clients compatible with Substrate RPC) as a black-box. Halva uses Polkadot.js to interact with RPC.

    Right now you must do much boilerplate code around your testing framework (mocha, chai, ava, etc) so that beginning testing your Substrate based app. Halva addressing these challenges.

    Team ๐Ÿ‘ฅโ€‹

    Our team develops software about 10+ years and decentralized applications since 2017. We have a great experience with typescript, node.js, and testing frameworks.

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 5 weeks
    • Full-time equivalent (FTE): 1.5
    • Total Costs: 1.82 BTC

    Milestone 1โ€‹

    Core functional for automated testing with Mocha and Chai. This stage involves the creation of basic functionality for running tests. It will include the TestRunner package, and assertions to simplify checking external calls.

    Assertions:

    • .passes Asserts that the passed async extrinsic does not fail.

    • .eventEmitted The eventEmitted assertion checks that an event has been emitted by the transaction with result

    • .eventNotEmitted The eventNotEmitted assertion checks that an event has not been emitted by the transaction with result

    • .reverts Asserts that the passed async extrinsic fails with a certain reason.

    • Estimated Duration: 5 weeks

    • FTE: 1.5

    • Costs: 1.82 BTC

    NumberDeliverableSpecification
    1.ConfigurationNetwork config for interacting with many public & private networks, keyring config for initializing test accounts and chain spec parser
    2.CoreImplement primitives, assertions, a high-order function for a test-cases
    3.TestingImplement scripts for command halva test. It run JavaScript tests with pre-initialized accounts.
    4.DocumentationsWrite documentations
    - + \ No newline at end of file diff --git a/applications/hamster.html b/applications/hamster.html index 04ba67f1486..d4c8c89f6fa 100644 --- a/applications/hamster.html +++ b/applications/hamster.html @@ -4,13 +4,13 @@ Hamster | Web3 Foundation Grants - +
    Skip to main content

    Hamster

    • Team Name: Hamster
    • Payment Address: 0xa5dEFB39eDF3B678D3C4F264EAA909E3f490d2D0(USDT)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Hamster is a decentralized computing network based on the underlying chain. It aims to provide users with cost-effective computing servers. It is a decentralized platform for leasing computing resources that can be performed to rent idle computing resources

    Currently there are many cloud computing service vendors providing cloud computing services, but currently with the expansion of services, the price of cloud computing services is gradually stabilized and high, and most of the cloud computing services are purchased on an annual basis, which causes great waste for current users who may use them for a short period of time, while the world's hardware capacity is gradually increasing today, and people have more and more idle computer products on hand. The goal of our product is to utilize the current idle computing resources in people's hands in a decentralized way, so that users who need it can use computing services in a cost-effective way.

    Our team aims to build a complete platform for leasing idle computing resources. The decentralized computing resource leasing function is realized by using substrate framework pallet, which can be leased and traded on the chain, and the link and use of computing resources can be done through the p2p network protocol under the chain after signing the lease agreement on the chain.

    Project Detailsโ€‹

    Hamster is composed of Hamster nodes, Hamster resource providers, Hamster clients, Hamster gateways, and Hamster front-end pages.

    • Hamster Node: is a custom node built on Substrate 3.0.

      • pallet_provider: performs resource provider registration and provider resource information storage, and provides a computational marketplace
      • pallet_resource-order: performs resource lease order functions and lease agreement execution
      • pallet_gateway: The gateway mainly has the following functions: gateway registration, gateway heartbeat detection, gateway status reset, gateway drop penalty, and receive rewards. The main role is to add the gateway as an important player in the shared computing platform

    • Hamster Gateway: p2p gateway with public IP, used to link information between resource provider and resource user, built with libp2p component, is the cornerstone of the leased resource availability, can register itself to Hamster Node. That includes the Register, Receive rewards and Configuration modules.

      • Register: Register Gateway information to Hamster Node.
      • Receive rewards: Revenue for those who provide gateway resources.
      • Configuration: Basic configuration of p2p gateway information.

    • Hamster Provider: can provide compute resources and register them with Hamster Node. Compute resources are provided using both vm virtual machine technology and docker technology. Currently vm virtual machine technology is used to better protect user privacy. That includes the Initialize configuration, Resource details, Account information and Configuration information modules.

      • Initialize configuration: Initialize configuration, including p2p seed node configuration, p2p port configuration.
      • Resource details: Available spare resource specifications (cpu, memory, etc.), and price.
      • Account information: Provide the import of the substrate account, provide the pledge of the deposit before the service, etc.
      • Configuration information: resources that have not reached a transaction are offline at any time, resource specifications, price configuration, etc.

    • Hamster Client: After purchasing compute resources in the front-end marketplace, users can view them through the client and link to them. That includes the Market, My order and My resource modules.

      • Market: A trading market where computing power providers submit idle computing power to the market and configure prices. The client can choose the configuration and price resources to be purchased to form a transaction contract.
      • My Orders: List and details of all resource orders I have purchased.
      • My resources: The list of resources corresponding to the current valid order, the client app can establish a connection with the remote resources through the list of resources.

    • Hamster Front End: Hamster Dapp, which allows users to purchase compute resources that have already been provided, and pay a certain Token to purchase a certain amount of time to use the compute resources. We can pay by the hour for more flexible use.

    Project Flowโ€‹

    Anti-malicious attacksโ€‹

    • How do you ensure the system isnโ€™t exploited and users actually fulfill the agreement?

      When the agreement is reached, the provider is required to complete the creation of the virtual machine, notify the blockchain of the completion of the order agreement, and request a heartbeat per epoch, which includes the number of cpu cores and memory size, for the blockchain to verify that it is working and providing valid resources. The potential threat is a nefarious provider forging heartbeats to trick the network into providing a valid service that actually provides less than the promised resources or even none at all. Since we have thought long and hard about this, and we do not currently have a cryptographic or better design to accomplish such a solution, we have adopted the idea of an arbitration model to prevent malicious attacks.

      1. when the user finds a problem with the resource and the information configured at the time of purchase does not match, submits a validation request and requests arbitration. in order to ensure that there is no malicious validation, the submission of the request will have a certain cost pledge.
      2. the arbitration group is subject to the validation request, currently designed to arbitrate the group for the current chain of validators. because he is the block validator, will promote the role of the current ecology. It is a trusted team
      3. the arbitration group to link the computing resources, after entering the link for linux least privilege account, to query the virtual machine specifications
      4. arbitration break to verify and report the vote
      5. according to the voting results for incentives and penalties, to achieve the purpose of malicious evil.

      We will follow up with cryptography or a better algorithmic model to replace the arbitration model. This will be a major topic of our subsequent research.

    • What are other potential attack vectors and how are you going to address them?

      • Virtual machine p2p connection security:

        The connection port of the virtual machine is exposed to the p2p network and is vulnerable to security attacks from the p2p network. When provier creates a virtual machine, it will use the public key of the purchasing user and inject it into the virtual machine. The password will be changed to a random password to ensure that no one can access it, and disable remote login by password. This protects the login security of the virtual machine.

      • Host network security:

        Mainly facing Escape Exploit . The 'Escape Exploit' problem is a persistent network security attack and needs to be solved by updating the corresponding software in time. We will iterate on the provider virtualization technology in the future.

    Project Technology Stacks

    • Rust
    • Substrate
    • Node.js
    • Golang
    • Wails
    • Libp2p
    • Kvm
    • Docker
    • Vue.js
    • Polkadot.js
    Proof of Conceptโ€‹

    The current project is in the primary stage of validation of the entire business process, the Gateway module has not yet been completed, this is the goal of our subsequent planning.

    Project pageโ€‹

    • Resource Registration

    • Resource Purchase

    • Resource Usage

    Ecosystem Fitโ€‹

    Our project is a distributed shared computing platform. Through the shared computing platform, our target customers are user groups with idle resource machines and some users who want to use cost-effective resources, they can be developers, designers, etc., and can deploy their inspirations that they want to share to our shared computing network to share out. The follow-up vision is to build an ecosystem of shared services on the shared platform network

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Teng Liang
    • Haijiang Mo
    • Jianguo Sun
    • Zhiwei Li

    Contactโ€‹

    • Contact Name: Teng Liang
    • Contact Email: ltyuanmu@gmail.com
    • Website: Hamster is currently maintained on Github, no website has been created yet

    Team's experienceโ€‹

    Teng Liang: Currently a team project leader with 8 years of software development experience, designed in the areas of Cloud Computing, Cloud Native, DevOps. and familiar with Java/Go/Rust languages and Solidity smart contract development.

    Haijiang Mo: CTO of the team, with 10 years of software development experience. He is familiar with Go/Rust/Java/Python/Javascript/Typescript and has worked in cloud computing, cloud native, DevOps.

    Jianguo Sun : Full-stack engineer with three years of development experience. And familiar with Go/Rust/Java/Python/Javascript/Typescript, front-end and client-side development.

    Zhiwei Li: Graduate student in Computer Science, Substrate pallet developer.

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    We have completed a simple version of the project for minimal process execution, and will subsequently update the usage documentation so you can install and experience using it.

    The following is a list of the features that have been implemented:

    • Hamster Node

      Computer resource register

      Update computer resource unit-price

      Create resource order

      Provider finish order

      Provider heartbeat

      Provider staking amount

      Provider withdraw amount

      Withdraw rental amount

      Withdraw fault execution

      Client cancel order

    • Hamster Provider

      Computer create

      Computer destruction

      P2p link listen

    • Hamster Client

      List of paid computers

      Computer link usage

    • Hamster Front End

      Computing market

      Provider shared computing

      Provider lease agreement list

      List of computers purchased by the customer

      Customer order list

    • Hamster Gateway

      Private IPFs network

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-Time Equivalent (FTE): 4 FTE
    • Total Costs: $25,600

    Milestone 1 Example โ€” Implement Hamster Client and Provider Modulesโ€‹

    • Estimated duration: 1 month
    • FTE: 4
    • Costs: $12,800
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide online documentation of the code and a basic tutorial that includes
    1. Hamster Client installation tutorial
    2. Hamster Client usage tutorial
    3. Hamster Provider installation tutorial
    4. Hamster Provider usage tutorial
    5. Hamster Chain installation tutorial
    6. Hamster Chain usage tutorial
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.Hamster ClientWe will create a desktop client that will have Market,My order and My resource module.
    We will provide a desktop (windows, macos,linux) app based on wails to achieve
    1: Market inquiry and management of purchased resources,
    2: The point-to-point communication between the client and the computing resource provider.
    3: Query historical orders
    4: Partial fee refund for defaulted orders
    Tech stack: go+wails+go-libp2p+vue.js+polkadot.js
    2.Hamster ProviderWe will create a a resource provider server that will have Initialize configuration,Resource details,Account information and Configuration information module.
    The resource provider will use the idle resources of the machine, register in the market, and declare that it can provide rental. When the provided virtual machine reaches a transaction in the market, the resource provider provides the virtual machine with the corresponding quota for the remote purchaser to use according to the agreement. The resource provider will establish a p2p connection with the used client for remote management, such as ssh, rdesktop, etc.
    Our initial idea is to use the libvirt scheme to implement the management of virtual machines. (Windows uses Hyper-V)
    We will support these operating systems: Windows 10, Ubuntu 18+, CentOS 7+
    Tech stack: go+go-libp2p+libvirt+go-substrate-rpc-client+gin
    3.Hamster Provider: web appWeb app is a set of web management tools of Provider. Through this set of management tools, users can share or stop sharing idle resources for their own use, set prices for their own idle resources, adjust the specifications of idle resources provided, and modify the provisioning services of idle resources. period, etc. And when a transaction is terminated normally, the desired compensation can be obtained through the contract. (Providing idle resource services requires a certain pledge. After the transaction is breached, part of the pledge deposit will be deducted. If the pledge deposit is too low, other people will not be able to see this idle shared resource in the market)
    Tech stack: vue.js+polkadot.js+Node.js
    4.Hamster chainpallet_provider, pallet_resource-order modifications and optimizations due to the need to optimize and adapt already developed pallets when adding features for customers. As code delivery of the underlying framework, there are two integrated pallets
    5.WhitepaperPreparation of project white papers

    Milestone 2 Example โ€” Implement Hamster Gateway Modulesโ€‹

    • Estimated duration: 1 month
    • FTE: 4
    • Costs: $12,800
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide online documentation of the code and a basic tutorial that includes
    1. Hamster Gateway installation tutorial
    2. Hamster Gateway usage tutorial
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will write an article or tutorial that explains the work done as part of the grant.
    1.Hamster GatewayWe will create a desktop client that will have Register, Receive rewards and Configuration module.
    Tech stack: go+go-libp2p+libvirt+go-substrate-rpc-client+gin
    2.Hamster Node: pallet_gatewayWe will create a Substrate module that will have Register gateway,Receive rewards etc function.
    3.Hamster Gateway: web appWe will create a web app integrated in the Hamster Gateway, to let users easily interact with our Hamster Gateway function module.
    Tech stack: vue.js+polkadot.js+Node.js
    4.Hamster chainAdd a gateway module in the Hamster chain, to enable users to share gateway resources with public IP , receive rewards, etc.

    Future Plansโ€‹

    Our current goal is to provide distributed shared computing power. After this milestone is completed, we will be able to build our own ecosystem based on resources. That is, when everyone is willing to add their free resources to the hamster network, it can be assumed that there are near-infinite computing resources in the network, and more quality services can be built and constructed in the hamster network. For example, service providers no longer need to rely on the support of a single cloud vendor, but only need to use the computing resources in the hamster network, and the system automatically schedules the resource arithmetic needed for the services to build their own services in the form of edge computing. In addition to this, we can also provide some toolkits so that these computing resources can participate in other services with one click, such as becoming a chain node of Thegraph, so that they can participate in other networks, and later on, we can also use incentives to encourage people to develop toolkits for different blockchain ecosystems. When more and more people and more service providers participate in the hamster network, maybe it can become a truly decentralized metaverse service cornerstone.

    Additional Information โž•โ€‹

    So far, we are self-funded development. However, for our long-term vision, we will try to get support from investment institutions.

    - + \ No newline at end of file diff --git a/applications/helixstreet.html b/applications/helixstreet.html index d512f9fee82..d6437c245df 100644 --- a/applications/helixstreet.html +++ b/applications/helixstreet.html @@ -4,13 +4,13 @@ helixstreet Module | Web3 Foundation Grants - +
    Skip to main content

    helixstreet Module

    • Team Name: helixstreet
    • Payment Address: bc1qvu2mjjm602rqshwkspy2v7a6wke529uzkucnej
    • Level: 2
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    helixstreet is a project to extend the use of Blockchain technology to genomics. helixstreet chose substrate as technology to implement a pallet to store a Merkle tree hash of genomic raw sequencing data. Relationsships ( ancestry ) can be documented in the blockchain based on relationships between genomic data. Currently we are planning to implement helixstreet as parathread.

    Ancestry data and personal genomic relationships are today stored centralized. helixstreet's approach allows the representation of ancestry data in a decentralized manner.

    Project Detailsโ€‹

    The project is in this stage just a pallet.

    Ecosystem Fitโ€‹

    The project extends the use of Polkadot ( or Kusama ) to a whole new use case. helixstreet would be an application specific parathread. It solves the problem of ownership of genomic data and the the human desire to conduct genealogical research without a central authority.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Thomas Deisen

    Contactโ€‹

    • Registered Address: None
    • Registered Legal Entity: None

    Team's experienceโ€‹

    Master in Computer Science / Founder of several companies / self education in Genomic Sequencing Technology and Variant Calling

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We started the project: https://github.com/helixstreet

    Development Roadmap ๐Ÿ”ฉโ€‹

    N/A

    Overviewโ€‹

    • Total Estimated Duration: 1
    • Full-Time Equivalent (FTE): 1
    • Total Costs: 1000 USD

    Milestone 1 Example โ€” Implement Substrate Modulesโ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: 1000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. The docker image will not include sequencing data.
    0e.ArticleWe will publish an article/workshop that explains what was achieved as part of the grant.
    1.Substrate module: genomicsWe will create a Substrate module that will store the merkle hash of genomic sequencing raw data.
    2.Program to generate HashtreeWe will creates a hash tree for all reads of the DNA probe. The script should calculate for every Read of every Chromosome a hash and create a Merkle tree to reduce storage. Furthermore the script should store a vector ( or the main root ) of the root hashes automatically in the Blockchain assigned to the private key. A flag is needed to distinguish between entries made by a machine ( e.g. Sequel II ) or by the identified owner of the DNA raw data ( the private key of the human being represented by the sequencing data ). The program will be realized in rust.

    Future Plansโ€‹

    The pallet is gradually expanded to document the relationship to other public keys. There is also the possibility of working together with HiFi sequencing manufacturers ( e.g. PACB ) who could store genomic footprints directly from the machines in the blockchain. Longterm we plan to develop a healthcare ecosystem in the blockchain based on genomic data.

    Selling any private data is completely out of scope of this project. The focus is to keep private DNA data private. The purpose of the project is to enable all the possibilities of owning his own DNA ( firstly ancestry research ) without revealing the whole data ( zero knowledge processing). When the raw data goes through the process of variant calling ( DeepVariant / open source variant caller / https://github.com/google/deepvariant ) groups of variants will additionally be stored in the blockchain. Scope of the grant is a genomics pallet with the described basic functionality, which should be adaptable and extensible.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    The project is a very long term project. Parallel to the Blockchain and decentralized governance development there is actually a game changing shift in the sequencing technology (SMRT Long Read Sequencing ) based on the availability of HiFi sequencing which allows the sequencing of human DNA ( and other species ) in a reference grade level quality.

    - + \ No newline at end of file diff --git a/applications/hex.html b/applications/hex.html index e3a7dd512ae..52fdda7af90 100644 --- a/applications/hex.html +++ b/applications/hex.html @@ -4,7 +4,7 @@ Five Degrees on Substrate | Web3 Foundation Grants - + @@ -22,7 +22,7 @@ No.

    Individual

    Team's experienceโ€‹

    Lester has 20+ years of software development experience and 4 years working in Blockchain developer.now working as a freelancer.He is proficient in C++. He has 2 years Rust development experience and 3 years Solidity development experience.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    No.

    Development Status ๐Ÿ“–โ€‹

    5degrees-protocol-substrate ink! contract implement finished. 5degrees-protocol-front-end implement finished.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement Five Degrees ink! Contract & Front-end Modulesโ€‹

    NumberDeliverableSpecification
    0a.Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can deploy our smart contract, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Docker file(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article on medium detailing our social protocol construction .
    1.ink! Contract: FiveDegreesThis contract is the overall contract of the FiveDegrees protocol.Set Entity's Info, Get Entity's Info,Build the relationship,Destroy the relationship and so on.
    2.protocol front-endWe will deliver the react-based front-end base on substrate-front-end-template with the contract,which demonstrates core methods of the contract.

    Future Plansโ€‹

    No.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    - + \ No newline at end of file diff --git a/applications/hs-web3.html b/applications/hs-web3.html index 9eb07f13b8b..27775073206 100644 --- a/applications/hs-web3.html +++ b/applications/hs-web3.html @@ -4,13 +4,13 @@ Haskell Web3 library | Web3 Foundation Grants - +
    Skip to main content

    Haskell Web3 library

    This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

    • Proposer: akru
    • Payment Address: 18QrEJq9f1EL4f3DVsbxYnkJXgbhSF9XJ4

    Project Description ๐Ÿ“„โ€‹

    It's my personal project. It was started as Ethereum client library but recently I guess it could evolve into multi-platform client library including Polkadot / Substrate chains. Haskell is a powerful hight order functional programming language that provide industrial grade code safety because of very strict control of function side effects. For Polkadot ecosystem Haskell developers is couple of high skilled professionals that could make effective services and applications. This project reduce entry threshold and could be a good quick start for haskellers.

    Team ๐Ÿ‘ฅโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 16 weeks
    • Full-time equivalent (FTE): 0.4
    • Total Costs: 2 BTC

    Milestone 1โ€‹

    • Estimated Duration: 3 weeks
    • FTE: 0.4
    • Costs: 0.4 BTC
    NumberDeliverableSpecification
    1.Substrate WebSocket RPCImplement Substrate JSON-RPC methods described here: author, chain, state, system.
    2.Substrate RPC documentationsExtend Haskell Web3 documentation by implemented functions adding Substrate RPC section.
    3.Substrate RPC examplesWrite simple examples into repository.
    4.Docker imagePack milestone results into docker image to make it's evaluation easy.

    Milestone 2โ€‹

    • Estimated Duration: 6 weeks
    • FTE: 0.4
    • Costs: 0.8 BTC
    NumberDeliverableSpecification
    1.Haskell SCALE codecImplement SCALE codecs for Haskell that required for correct Polkadot / Substrate client implementation. Codec should reference to official documentation and Rust implementation. Codec should pass Rust test cases.
    2.SCALE codec documentationDocument implemented functionality and extend hs-web3 documentation by adding SCALE codec section.
    3.Codec examplesAdd examples of using codec into hs-web3 repository.
    4.Docker imagePack milestone results (unit tests) into docker image to make it's evaluation easy.

    Milestone 3โ€‹

    • Estimated Duration: 3 weeks
    • FTE: 0.4
    • Costs: 0.4 BTC
    NumberDeliverableSpecification
    1.Runtime Metadata parsersImplement structures and abstractions that helps to parse runtime metadata and make API decoration easy.
    2.Runtime query requestsImplement read type requests for the runtime. This methods should help developer to read data from Substrate-based blockchains.
    3.Runtime query documentationDocument implemented functionality and extend hs-web3 documentation by adding Substrate query section.
    4.Runtime interaction examplesAdd examples of using API queries into hs-web3 repository.
    5.Docker imagePack milestone results (unit tests) into docker image to make it's evaluation easy.

    Milestone 4โ€‹

    • Estimated Duration: 3 weeks
    • FTE: 0.4
    • Costs: 0.4 BTC
    NumberDeliverableSpecification
    1.Extrinsic abstractionsImplement structures and abstractions that makes extrinsics operations (serialize/deserialize, sign, send).
    2.Extrinsic signersUse ECDSA and Ed25519 cryptography libraries for signing extrinsics. (Unfortunately Sr25519 unavaliable for Haskell, it could be an idea for another grant.)
    3.TransactionsUsing Metadata and Extrinsics to make transactions into Substrate-based blockchains.
    4.API tx documentationDocument implemented functionality and extend hs-web3 documentation by adding Transactions section.
    5.Runtime transaction examplesAdd examples of using tx module into hs-web3 repository.
    6.Docker imagePack milestone results (unit tests) into docker image to make it's evaluation easy.
    - + \ No newline at end of file diff --git a/applications/hybrid.html b/applications/hybrid.html index a4f7ffc3638..7d31e21971a 100644 --- a/applications/hybrid.html +++ b/applications/hybrid.html @@ -4,7 +4,7 @@ Hybrid Block Explorer | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Hybrid Block Explorer

    • Team Name: Jonathan Brown
    • Payment Address: 0x36a7401F269555916a0243E586234D3Bbf5A0c36 (DAI)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    This application is in response to two RFPs:

    Overviewโ€‹

    Hybrid takes a unique, partially decentralized approach that improves two major problems with current open source Substrate block explorers: centralization and huge hosting requirements.

    A fully centralized block explorer typically populates an SQL database with the entirety of an archive node and stores additional data to index everything. Operating such a database reliably requires huge system resources and expense.

    When querying block information, or the chain state at any block height, the Hybrid dapp will use the Substrate Connect light client from within the browser. Alternatively, these queries can be made directly to an archive node via WSS.

    For event search functionality, the Hybrid indexer efficiently indexes events in all blocks so they can be found with a simple WSS query. For example, to find all events connected with a specific AccountId.

    This architecture has three main advantages:

    • state queries are fully decentralized - you don't have to trust an RPC provider not to lie to you
    • 100% availability - the light client doesn't depend on any centralized service that may not always be available
    • the Hybrid indexer has significantly lower system requirements - it doesn't need to store all chain history

    Eventually, Hybrid will use this centralized / decentralized approach as the basis for an ink! contract explorer.

    Because Substrate is a federated platform, it will be possible browse multiple chains from the Hybrid dapp.

    Project Detailsโ€‹

    Hybrid will be a Substrate block explorer dapp. By default it will connect to major Substrate blockchains. Additionally it can be configured to connect to any Substrate chain.

    There are two types of queries that the explorer can perform:

    • Decentralized - ideally using the Substrate Connect light client, or alternatively connecting to an archival node via WSS. For example, querying blocks or state storage.
    • Centralized - the Hybrid indexer for the chain will be queried via WSS. This is for event searching and watching, such as finding all events across all chains that relate to a specific AccountId.

    Hybrid Architecture

    Indexerโ€‹

    The Hybrid indexer will be written in Rust. It can be configured to connect to any Substrate chain.

    It will read events in all blocks using subxt and index these events in a Key-value database using the sled library. This is considerably more efficient than storing the index in an SQL database.

    subxt currently has an issue where it is not possible to query blocks prior to V14 metadata (block #7,229,126 on Polkadot). Resolving this issue is not within the scope of the grant. Once this grant is completed a further grant application will be made that includes resolving this issue.

    When decoding events, subxt needs to have the correct metadata. The metadata changes whenever a chain performs a runtime upgrade. Hybrid Indexer handles this in a very elegant way. When indexing begins it downloads the metadata for the starting block. When it encounters a decoding error it downloads the metadata for the current block and retries decoding. This means that the indexer does not have to be built with the metadata and block number of every runtime upgrade.

    To index an event, it needs to be converted into a Rust type that matches the metadata. Sometimes the metadata for an event will change during a runtime upgrade. To handle this the indexer will have Rust types for current and historic versions of all events. When an event fails to be converted into a Rust type the previous type will be tried.

    All events in all pallets that have identifying parameters will be indexed. For example the Transfer event in the Balances pallet is identifiable by the AccountId of both from and to.

    Other examples of identifying event parameters are assetId in the Assets pallet, code_hash in the contracts pallet, CollectionId and ItemId in the NFTs pallet, and MultiLocation in the XCM pallet.

    Additionally, all events are indexed by event variant.

    To download a block, a query first has to be made to determine the hash for a given block number. In order to ensure throughput is as high as possible, multiple queries to the full node will be active at the same time to avoid round-trip delay. Block processing will be in a separate thread.

    In the same manner that each Substrate chain is a separate Rust build that uses Substrate crates, each chain will need a separate Hybrid Indexer build that is configured to index the correct pallets.

    When a chain is going to potentially perform a runtime upgrade, the Hybrid Indexer for the chain will need a new release with any updated events. If an instance of the indexer is not updated before the runtime upgrade occurs, it can be restarted with the new version at the correct block number.

    WSS queries will be handled via the highly scalable tokio_tungstenite Rust library.

    In addition to the identifier being searched for, queries will be able to include start block, offset, and limit to control which events are returned.

    Consumers will be able to subscribe for new events that match a query.

    The database keys will be constructed in such a way so that events can be found using iterators starting at a specific block number. For example, for for the AccountId keyspace:

    AccountId/BlockNumber/EventIndex

    Database entries will be key-only. No value will be stored. The blocknumber and event index are all that need to be returned for each event found. This reduces the size of the index database and increases decentralization. The frontend can query the chain in a decentralized manner to retrieve the event.

    Dappโ€‹

    The Hybrid dapp will be a Vue dapp, using the Vuetify framework for the user interface. pnpm and Vite will be used for the build.

    It will use @polkadot/api to retrieve data from the chain, either via the Substrate Connect light client, or via an RPC connection to a full archival node. The Hybrid indexer will be queried via WSS.

    This grant will only include a basic dapp including:

    • block browsing, showing transactions and events
    • event searching, e.g. searching for all events connected to a specific AccountId.

    A subsequent grant application will be made to develop a richer dapp experience.

    Ecosystem Fitโ€‹

    A major issue holding back the Substrate and Polkadot ecosystem is a high quality block explorer comparable to Etherscan. We need such a block explorer to be:

    • non-proprietary
    • as decentralized as possible
    • not requiring massive system resources
    • feature-rich

    The target audience is blockchain enthusiasts and developers. Eventually end-users should not need to know about block explorers, but this depends on dapps improving their user experience.

    The indexing component has value far beyond the Hybrid block explorer. Many Substrate applications will find a centralized event indexer extremely useful.

    Comparison to other Substrate explorers / indexersโ€‹

    There are no known block explorers in other ecosystems that are indexing, and either fully decentralized or have a hybrid design like this one.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Jonathan Brown

    Contactโ€‹

    • Registered Address: n/a
    • Registered Legal Entity: n/a

    Team's experienceโ€‹

    Jonathan Brown has extensive relevant experience to build this software.

    He built a proof-of-concept centralized indexer for a cross-chain DEX that has a very similar architecture to the Hybrid indexer. It is written in Rust, indexes data from Substrate and Ethereum blockchains, writes it to RocksDB, and enables WSS queries via tokio_tungstenite.

    https://github.com/acuity-social/acuity-atomic-swap-offchain

    He is also very experienced building dapps with polakdot.js such as the Acuity DEX.

    Jonathan has also made some videos about Substrate development: https://www.youtube.com/watch?v=FMr2bNSmnfY

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    • n/a

    Development Status ๐Ÿ“–โ€‹

    Development has not started on the project, however the codebase will largely follow that of the Acuity DEX offchain indexer.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 12 weeks
    • Full-Time Equivalent (FTE): 1
    • Total Costs: 10,000 USD

    Milestone 1 โ€” Event Indexing componentโ€‹

    • Estimated duration: 6 weeks
    • FTE: 1
    • Costs: 5,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can index a Polkadot node and query events.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Connect to Substrate chainsThe indexer will be written in Rust and configurable to connect to the Polkadot chain using the subxt library.
    2.Block syncingAs new blocks are produced, the indexer reads all events. Additionally, it will read events from archived blocks. Indexing will be quite slow because communication with the full node will not be asynchronous. Only the Polkadot chain will be supported.
    3.Index writingThe following identifying parameters in events will be indexed in the database using the sled library: AccountId, AccountIndex, AuctionIndex, BountyIndex, CandidateHash, MessageId, ParaId, PoolId, ProposalHash, ProposalIndex, RefIndex, RegistrarIndex, TipHash. Not all events will be indexed.
    4.Status queryingIt will be possible to query the current status of the indexer via WSS. This will include information about which chain is being indexed, indexing progress and last know block. Queries will be handled via tokio_tungstenite.
    5.Index queryingIt will be possible to search via WSS for events with an identifier. Basic event parameters details will be provided for most events.
    6.DappA rudimentary web interface will be developed to expose this functionality. This will be built using pnpm, vite, vue, vuetify & polkdadot.js .

    Milestone 2 โ€” Event Subscribingโ€‹

    • Estimated duration: 3 weeks
    • FTE: 1
    • Costs: 2,500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can witness live updates to event search results.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Event subscription APIThe indexer will be updated to service subscription requests via WSS.
    2.Live dappThe dapp will be updated so that pages displaying results from event queries will be updated as soon as a new event appears on the chain.
    3.Full Polkadot event indexingThe indexer will be updated to index all Polkadot pallets and the following keys will be indexed in addition to those in Milestone 1: preimage_hash, era_index, session_index.
    4.Variant indexAdditional event index by pallet, variant
    5.Increased decentralizationDon't store event in db - load events in front end from chain
    6.Asynchrous block downloadingBlocks will be downloaded as fast as possible for improved indexing speed.

    Milestone 3 โ€” Decentralized Componentโ€‹

    • Estimated Duration: 3 weeks
    • FTE: 1
    • Costs: 2,500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can build a chain-specific Hybrid Indexer and use the rudimentary explorer dapp.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.Blog postWe will publish a blog post that explains and demonstrates all aspects of the explorer.
    1.Hybrid Indexer LibraryConvert hybrid-indexer into a library that can be used by a Substrate chain indexer. Write macros for indexing all standard Substrate pallets.
    2.Polkadot IndexerNew rust project using hybrid-indexer library to index polkadot, kusama, rococo & westend.
    3.Chain selectThe Hybrid dapp will have a dropdown to switch between the 4 polkadot chains.

    Future Plansโ€‹

    • indexing block prior to V14 metadata (block #7,229,126 on Polkadot). See issue.

    • hosting - The project needs to host indexes for all major Substrate chains. The frontend can be hosted as a traditional website and on IPFS.

    • improve dapp - explore how the event index can be used to better display the richness of the Polkadot ecosystem.

    • support for tokens and nfts

    • add support for ink! smart contracts with decentralized source code publishing

    • maintain Hybrid as the most decentralized Substrate block explorer

    • marketing

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Twitter

    • What work has been done so far? Development has not started yet.

    • Are there are any teams who have already contributed (financially) to the project? No

    • Have you applied for other grants so far? No

    - + \ No newline at end of file diff --git a/applications/hybrid2.html b/applications/hybrid2.html index 58c073c9574..e20aa58b803 100644 --- a/applications/hybrid2.html +++ b/applications/hybrid2.html @@ -4,13 +4,13 @@ Hybrid Indexer Follow-up | Web3 Foundation Grants - +
    Skip to main content

    Hybrid Indexer Follow-up

    • Team Name: Jonathan Brown
    • Payment Address: 0x36a7401F269555916a0243E586234D3Bbf5A0c36 (DAI)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    This application is for a follow-up grant to the original Hybrid Block Explorer grant: https://github.com/w3f/Grants-Program/pull/1582

    Overviewโ€‹

    Hybrid Architecture

    The original grant for the Hybrid Block Explorer involved creating a Rust library that can be utilized to create an event indexer for any Substrate chain. A Rust project to index all Polkadot-based chains was delivered. Additionally, a rudimentary browser dapp was produced to provide a user interface to query the index and load event details from the chain.

    This follow-up grant application is specifically to improve the indexer component of the project.

    Project Detailsโ€‹

    Before the indexer can be used effectively by the Polkadot community, there are various improvements that need to be made:

    Indexer Improvementsโ€‹

    • Currently there are two indexer threads, one for indexing new finalized blocks, and one to index old blocks. This is unnecessarily complex. Combining these threads will make the codebase much simpler.

    • The indexer needs to verify that it is indexing the correct chain. If it connects to the wrong endpoint or opens the wrong database, incorrect data would be present in the index.

    • Terminal output needs to be improved with configurable levels of verbosity. Statistics need to be output in a regular time interval, not block interval.

    • Error handling needs to be improved. Currently many error conditions are silently ignored. Exiting needs to be handled gracefully.

    Reverse Batch Indexingโ€‹

    Currently when the indexer is indexing old blocks it starts at a specified block and works forward, eventually catching up with head. When the indexer is restarted it will resume where it left off.

    Typically users are more interested in recent blocks. If a user is indexing on their own device it can take many hours or days for the batch indexer to catch up with head.

    If the user wants to index from an earlier block, they have to re-index all the already indexed blocks.

    The solution is for the batch indexer to always start indexing backwards from head and store in the database which spans of blocks have been indexed with which version of the indexer.

    The indexer currently trusts that new finalized blocks are delivered sequentially. The indexer needs to verify that no blocks have been ommitted. If a block has been omitted or the WSS connection is broken and reestablished then the batch indexing will need to restart from head.

    Database Improvementsโ€‹

    • Currently, the event parameter types that are available to be indexed are hardcoded in the indexer library. The API needs to be extended so that chain indexers can specify custom parameter types, beyond those in Substrate.

    • In addition to indexing event parameters, the indexer can also index which variants of events have occurred. This is very useful. For example, the indexer can return all balance transfers that have occurred. This index is the largest because every event that occurs is a separate database entry. Making this index optional will greatly reduce the storage space for those users who do not need it.

    • Hybrid uses the Sled database library. Tunables cache_capacity and mode should be exposed in the indexer.

    WS API Improvementsโ€‹

    • Currently, to receive status updates it is necessary to continually query the indexer. It should be possible to subscribe to status updates.

    • It should be possible to query how much disk space is used for each index. This can be implemented using the following method: size_on_disk.

    • It is currently possible to subscribe to event searches. It needs to be possible to unsubscribe.

    • A Rust library needs to be written to make it easier to query Hybrid indexes from Rust programs.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Jonathan Brown

    Contactโ€‹

    • Registered Address: (shared privately)
    • Registered Legal Entity: n/a

    Team's experienceโ€‹

    Jonathan Brown is the sole developer of Hybrid Indexer and dapp.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    • n/a

    Development Status ๐Ÿ“–โ€‹

    Work on the deliverables defined in this application has not started yet.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 12 weeks
    • Full-Time Equivalent (FTE): 1
    • Total Costs: 10,000 USD

    Milestone 1 โ€” Indexer Improvementsโ€‹

    • Estimated duration: 3 weeks
    • FTE: 1
    • Costs: 2,500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can specify chain identifying information and control logging verbosity.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Combine head and batch indexer threadsThe codebase will be simplified by combining head and batch indexing into a single thread.
    2.Check correct chainThe indexer will ensure that both the chain being indexed and the existing index database have the correct chain information.
    3.Improved loggingVerbosity level will be controlled by command line parameter. Statistics will be output with a regular time interval, not block interval.
    4.Improved error checkingAll error conditions in the codebase will be handled correctly. Exiting will be handled gracefully.

    Milestone 2 โ€” Reverse Batch Indexingโ€‹

    • Estimated duration: 3 weeks
    • FTE: 1
    • Costs: 2,500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can declare starting blocks for updated indexers.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Index backwardsWhen the indexer starts it should always start indexing backwards from head.
    2.Store indexed spansThe indexer should store in the database a record of which spans of blocks have been indexed with which version of the indexer and utilize this information to avoid redundantly indexing blocks multiple times.
    3.Declare indexer start blocksEach chain indexer can declare which block each version of the indexer should start from. Automatically re-index blocks after upgrading the indexer.

    Milestone 3 โ€” Database Improvementsโ€‹

    • Estimated duration: 3 weeks
    • FTE: 1
    • Costs: 2,500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can implement new indexes, omit the variant index and adjust database tunables.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Support additional indexesChain indexers will be able to define additional index parameter types that can be indexed.
    2.Variant index optionalVariant indexing will be made optional.
    3.Expose cache_capacity() and mode()These Sled database parameters will be exposed on the command line.

    Milestone 4 โ€” WebSocket API Improvementsโ€‹

    • Estimated duration: 3 weeks
    • FTE: 1
    • Costs: 2,500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can subscribe to status updates, unsubscribe, query index storage space, and use the Hybrid Rust API.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article describing the improvements to the indexer.
    1.Status subscriptionIt will be possible to subscribe to status updates.
    2.UnsubscribingIt will be possible to unsubscribe from status updates and event parameter watching.
    3.Report each index sizeIt will be possible to get a report of how much storage space is used by each index.
    4.Rust APIA Rust library will be developed to make it easier for Rust applications to query Hybrid indexes.

    Future Plansโ€‹

    • indexing block prior to V14 metadata (block #7,229,126 on Polkadot). See issue.

    • desktop dapp - build a block explorer dapp in Rust

    • support for tokens and nfts

    • add support for ink! smart contracts with decentralized source code publishing

    • maintain Hybrid as the most decentralized Substrate block explorer

    • marketing

    - + \ No newline at end of file diff --git a/applications/hybrid_node_research.html b/applications/hybrid_node_research.html index 4cba3c05d3e..6fa243919ad 100644 --- a/applications/hybrid_node_research.html +++ b/applications/hybrid_node_research.html @@ -4,7 +4,7 @@ hybrid_node_research | Web3 Foundation Grants - + @@ -21,7 +21,7 @@ We will pay particular attention to the following areas:

  • Analysis, initial rework (as a proof of concept) and reimplementation of a module: Based on the findings from the previous stage, we will select and replace a module (such as Keystore and remote signing APIs) while keeping everything else in the node functional.

    • Overviewโ€‹

    Milestone 1 - Preengineering of hybrid node and research analysisโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT
    0b.DocumentationWe will provide a inline documentation of the code and inline documentation of the code and a basic tutorial
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. We plan to write integration tests at the boundary level
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article explaining the research analysis done
    1.Research ReportWe will provide a detailed report covering the review of specifications and conformance tests, the review of Polkadot Host (Parity)and the findings from the re-work of the module and primitives including recommendation practices based on this proof of concept.
    2.PoC codeWe will provide the code from the re-worked primitives.We plan to promote modularity and replace parts of the reference node by rewriting them in C/C++.
    Note: This will not be production-ready code. It is just meant to be used as a proof of concept and to inform future development plans.

    Future Plansโ€‹

    After this first research analysis we plan to apply for additional grant to cover a long-term commitment and full rework implementation of this alternative hybrid Polakdot host.

    Additional Information โž•โ€‹

    Zondax has been contributing to the Polkadot ecosystem for several years, and has succesfully completed several grants.

    - + \ No newline at end of file diff --git a/applications/imbue_network.html b/applications/imbue_network.html index c0bd1871050..cffff6c8de7 100644 --- a/applications/imbue_network.html +++ b/applications/imbue_network.html @@ -4,7 +4,7 @@ Imbue Network | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Imbue Network

    This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a > (such as this one) can be removed.

    See the Grants Program Process on how to submit a proposal.

    • Team Name: Elamin LTD
    • Payment Address: 0xcF27835b42Da4C1E44f94b671cBC544de828144d (USDT)
    • Level: 2

    โš ๏ธ The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.

    Project Overview ๐Ÿ“„โ€‹

    Imbue Network was born out of the growing problem of funding projects. There is a real problem in the polkadot ecosystem with funding, projects tend to launch on ETH as an easy way out due to lack of options. The problem is then compounded because of seed/private investors so by the time the token launches, their community can only get a chance to invest through severly limited whitelists

    Imbue Network wants an end to Eth raises and whitelists. We aim to solve this problem by building a parachain that allows its token holders to propose and then fund a proposal.

    Project Detailsโ€‹

    Imbue network aims to become a DAO and a parachain, so we will be heavily dependant on both Substrate/Polkadot/Cumulus

    We aim to build on top of the great work the OAK network has done around quadratic funding and build a custom pallet that holders of the Imbue network token ($IMBU) will be able to propose a new project and idea, detail how much they need and milestones. The proposal can also detail stages in their milestones and split the required amount. I.e Claire is a founder of a project and needs $100k and detailed 5 milestones. Claire needs $10k upfront to start off with then once milestone 1 is complete Claire requires a further $40k for milestone 2 and 50k for milestone 3.

    We also will build a UI that allow users to connect their polkadotJs wallet to allow other holders to vote on the projects they want to see implemented.

    Once voting completes, DAO council members will then approve the winning proposals and allocate a portion of the funds - % that was defined in milestones - immeditely.

    Once the founder believes they completed their first milestone they can use the pallet to initialise a vote, only the original funders can then vote to validate whether the milestone was completed successfully or not. If the vote passes the next stage of funds are unlocked.

    • For MVP we hope to achieve:
      • Grants pallet - where holders can propose projects/ideas and receive funding
      • Democracy pallet - where funders can vote on proposals and milestones
      • DAPP integrated with polkadotjs for a more seemless user experience.
    • What wont be ready but we hope to add
      • Funding will initially only be done via the $IMBU token, but we hope to add other currencies as we grow. We will also explore working with statemint to manage this funds

    An overview of the flow is detailed here, please bear in mind this is just showing the happy path

    We will be adding signitures for each pallet call over the next few weeks.

    Ecosystem Fitโ€‹

    We believe we are solving a real problem in the polkadot ecosystem, and cannot think of any other project that aims to do what we are trying to do.

    We do not consider IDO platforms as a solution to this problem. There is also the governance aspect which is also missing from the space but is also needed

    However, https://aragon.org/ is something similar that is built on top of Etherum. We believe our USP is the funds being unlocked in stages and allowing funders to vote on those milestones

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Sam Elamin
    • Aala Sharfi
    • Kanthan Segeran

    Contactโ€‹

    • Registered Address: 56 Balder Rise, London. United Kingdom SE12 9PF
    • Registered Legal Entity: Elamin LTD

    Team's experienceโ€‹

    Sam has over 15 years experience as a developer and has worked in some of the world's largest companies such as Sony Playstation,Discovery Communications and JustEat. He has extensive experience in Big Data and for the past year has been leading the tech team @ Kylin Network

    Kanthan has 10 years of experience in IT specializing in integration, cloud & security architecture He has also worked with Sam @ Kylin Network

    Aala is a multidisciplinary designer specializing in branding and publication design. Aala's strengths lie in identity design, digital and print design, with technical skills in Adobe CC, (AfterEffects, Photoshop, InDesign and illustrator) Microsoft Office, Figma as well as AutoCAD and Sketchu

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Development Status ๐Ÿ“–โ€‹

    We are still at the early stage of development, getting our website out in the next week or two. We do have some wireframes around how people will be able to propose/vote for project which can be found below

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: Duration of the whole project (e.g. 6-9 months)
    • Full-Time Equivalent (FTE): 3 FTE, 2 PTE
    • Total Costs: 30k.

    Milestone 1 โ€” MVP startโ€‹

    • Estimated duration: 3 month
    • FTE: 2 FTE, 2 PTEs
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DappUI to add proposals onchain. This can be either stored onchain completely or a combination of IPFS and onchain. The UI will be written in Typescript/NodeJS and interact with PolkadotJS wallets to deduct costs for voting/adding proposals
    0c.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Substrate module: Grants palletAdd grants pallet to add proposals onchain, each proposal has a unique ID which votes will be counted against. This pallet will be called by project proposers to submit new projects/milestones.

    The grants pallet is essentially a data store of grants, it will also need to track progress on each grant application

    I.e one unique grant ID has a one-to-many milestones relationship and the council will determine when to mark a milestone as complete

    Milestone 2 โ€” Adding new features and refining existing onesโ€‹

    • Estimated Duration: 3 month
    • FTE: 2 FTE, 2 PTE
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.DevOpsBuilding out CI/CD pipeline using github actions
    0b.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0c.Voting PalletAdd voting module to add governance and votes on grants
    0d.Public boardWork in an agile manner and maintain a public board so the community could keep an eye on progress
    0e.DappAllow voting on proposals via a linked PolkadotJS wallet. Votes on new projects/milestones for existing ones. To be built in react
    0f.ArticleWe will publish a medium article and workshop that explains how the grant funds were spent as well as detailed guides on how to spin up the collators and submit a proposal then vote on it
    1.Substrate module: Democracy palletVotes pallet to allow voting on proposals (working alongside the grants pallet). Votes meant to be stored via IPFS. Voting will be done with 1 $IMBU = 1 vote.
    2.Substrate module: Funding palletWorks alongside the democracy pallet to unlock funding in the stages defined by the project orignally. This will be called after council votes on approval of funding/milestones. This will also be called by the proposer to withdraw the approved funds. Can potentially be merged with the grants pallet

    The proposed flow for milestone 2 is:

    • Given Alice is proposing an idea/project, alice submits this proposal via the UI. The proposal details can be stored on/offchain but the ID needs to be stored onchain.

    • The council approves it which then goes to voting via the democracy pallet.

    • $IMBU holders vote on the project they want to see implemented by partially funding a locked account.

    • The council then approves the initial amount (defined by Alice in her milestones ) via the treasurey pallet(if required) and unlocking a % of funds that the $IMBU holders locked

    • For each and every milestone Alice completes, she submits it and the whole process restarts again culminating with the treasury unlocking the % of funds required for that milestone. The only difference here is that only IMBU holders that funded the project (and council if treasury was involved) can vote on milestones. For simplicity's sake 1 $IMBU = 1 Vote

    The Funding pallet needs to be built in such a way where it can either fund the project proposals in the native IMBU token or in any other token. We can reuse the treasury pallet but change it in such a way to allow this iterative milestone unlocking behaviour.

    ...

    Future Plansโ€‹

    We want to build out Imbue network as a DAO, We also want to build out the ability to allocate funds on the different polkadot currencies so a proposer can choose which currency they want to be funded in

    Ideally, for future milestones, we would like to remove the need for the council completely and have this fully determined by the IMBU holders. Also a vote can be a fraction of an IMBU so your vote weight is equal to the % of the amount funded

    Work with Parity on how we can utilise Statemint with fund storage/allocation

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    • Sam has already worked on building the kylin parachain almost single handedly, grew the team to 4 before starting Imbue Network. He is more than capable of making the Imbue network vision a reality
    - + \ No newline at end of file diff --git a/applications/infimum.html b/applications/infimum.html index aee4d8fabb1..aaabf570a36 100644 --- a/applications/infimum.html +++ b/applications/infimum.html @@ -4,13 +4,13 @@ Infimum | Web3 Foundation Grants - +
    Skip to main content

    Infimum

    • Team Name: Apollos Collective
    • Payment Address: 0x9c10EbAEB989CFd239679d47B9100dc4ad57A536 (ERC20 USDC)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    This application is in response to the anti-collusion infrastructure RFP.

    Overviewโ€‹

    Helping to empower the realization of trust in, and verification of, voting systems within Substrate parachains.

    The goal of this proposal is to provide a minimum viable implementation of Vitalik Buterinโ€™s โ€œMinimal Anti-Collusion Infrastructureโ€ as a substrate pallet and CLI (for performing off-chain work, i.e. encrypting votes, processing messages, and generating proofs).

    The scope of this proposal is intended to be a proof of concept, of which contributes to the development of a genuine minimal anti-collusion infrastructure within the Substrate ecosystem.

    Governance, and by extension voting systems, are critical facets of society at large and have become a crucial value proposition of many blockchain applications. It is therefore imperative to develop systems which not only promote a sense of underlying trust, but also can intrinsically verify their own integrity.

    The team is interested in cryptographic voting as a research domain. They would like to further explore this area in order to provide a meaningful contribution to the community. Refer to โ€œFuture Plansโ€ section to preview how weโ€™d like to see this project evolve.

    Project Detailsโ€‹

    There are two primary deliverables outlined in this proposal:

    1. A Substrate pallet which facilitates the voting apparatus and on-chain verification of poll results, and;

    2. A CLI tool to facilitate the generation of arguments passed to the methods exposed by the pallet.

    The goal of this system is to deincentivize collusion between participants given that any participant can secretly change or nullify their vote.

    Use case diagram

    Deliverables:
    1. Substrate pallet
      1. Description
        1. Facilitates transparency and provenance of poll interactions and outcome. Users can register as either coordinators or participants, create polls, and interact with polls. On-chain verification of zero-knowledge proofs (which have been generated off-chain) that establish the correctness of the poll tallying computations (which have been performed off-chain) must occur prior to the acceptance of, and publishing of poll outcome.
      2. Public methods
        1. registerAsCoordinator Permits the caller to create polls, and stores their (public) keys.
        2. rotatePublicKey Permits a coordinator to rotate their public,private keypair. Rejected if called during an ongoing poll.
        3. rotateVerifyKey Permits a coordinator to rotate their verification key. Rejected if called during an ongoing poll.
        4. registerAsParticipant Permits a user to participate in a poll. Rejected if called after voting period.
        5. createPoll Instantiates a new poll object with the caller as the designated coordinator. Emits an event with the poll data.
        6. interactWithPoll Inserts a message into the message tree for future processing by the coordinator. Valid messages include: a vote, and a key rotation. Rejected if sent outside of the timeline specified by the poll config. Participants may secretly call this method (i.e. from a different address) to override their vote, thereby deincentivizing bribery.
        7. mergePollState Used by the coordinator to compute roots of message state tree, which is used as a commitment value by the proof verification logic. Rejected if called prior to poll end.
        8. commitProcessedMessages Verifies the proof that the current batch of messages have been correctly processed and, if successful, updates the current verification state. Rejected if called prior to the merge of poll state.
        9. commitTallyResult Verifies the proof that the current batch of votes has been correctly tallied and, if successful, updates the current verification state. On verification of the final batch the poll result is recorded in storage and an event is emitted containing the result. Rejected if called before messages have been processed.
      3. Runtime storage
        1. Public key store: mapping between coordinators and their public keys (which are used by participants to encrypt their votes)
        2. Verifying key store: mapping between coordinators and their verifying keys used in the on-chain verification of proofs
        3. Poll store: mapping between poll id and the current state of the poll
        4. Poll message state: mapping between poll id and a merkle tree of secret participant messages (i.e. votes and/or nullifiers)
        5. Poll Result: mapping between poll id and outcome
      4. Dependencies
        1. We will rely on the Groth16 verifier provided by bellman under the MIT license.
    2. CLI tool
      1. Description
        1. Facilitates off-chain computations performed by participants and trusted operators. In particular, generating the values (e.g. encryption keys, proofs) required by the function signatures specified in the first deliverable (1.Susbtrate Pallet). This will be provided as a TypeScript library (in order to serve as a starting point for future integration into dApps) with a simple CLI wrapper.
      2. Technologies used
        1. Circom
        2. Typescript
        3. Node.js
        4. snarkjs
      3. Commands available to users
        1. generateKeypair Used by both participants and coordinator. Outputs a keypair used for encrypting and decrypting the messages which represent poll interactions.
        2. generateProof Used by the coordinator. Generates a proof of correctness for the current batch of message processing computations (including final vote tally).
        3. encodeMessage Used by participants. Accepts their vote as input, and outputs an encoded message which may only be decrypted and read by the coordinator.
    Poll lifecycle:
    1. Poll is created (by a coordinator). Prior to the start time of the poll:
      1. The coordinator may perform any permitted alterations to the poll configuration, or close the poll
      2. Individuals can begin to register as participants in the poll
    2. Poll starts:
      1. Coordinator may no longer preform any alterations to the poll (e.g. update signing key)
      2. Participants may interact with the poll (vote, revote, nullify vote, switch keys)
    3. Poll ends:
      1. Participants may no longer sign up or interact with the poll
      2. Coordinator may start to compute the outcome of the poll
    4. Poll result becomes โ€œfinalizedโ€ once:
      1. The coordinator publishes the result of the poll alongside proofs of the computations
      2. The result of the poll is committed to storage if and only if every proof passes verification
      3. At this point it is sensible for external actions to be taken in response to the outcome of the poll
    Constraints and limitations of the deliverables to be aware of:
    • A coordinator may only manage a single poll at a time (there may be multiple coordinators each with their own poll at any given time)
    • Users can only cast a vote of weight 1
    • Votes must be processed, and tallied, in batches
    • Non-transparent proof system (Groth16); requires a trusted setup

    We intend to improve upon these limitations in future work (see the section below).

    Ecosystem Fitโ€‹

    • Useful in governance schemes, e.g. crowd funding applications.
    • The target audience is parachain developers, e.g. a candidate integration could be the imbue network.
    • The overall intended trajectory is to help establish a sense of integrity within democratized systems. Participants in these systems are empowered to verify by default.
    • The team is not aware of any projects in the Substrate/Polkadot/Kusama which are currently attempting to achieve feature parity (or beyond) with MACI in the Ethereum ecosystem.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Rhys Balevicius

    Contactโ€‹

    • Registered Address: 173 Presidial Avenue, Oshawa, ON Canada
    • Registered Legal Entity: Apollos Web3 Collective Inc.

    Team's experienceโ€‹

    Rhys Balevicius is a software developer with over half a decade of professional experience in full-stack development, software design, and software architecture in various industries, of which include blockchain technologies and fintech. He is also currently studying Mathematics and Computer Science at University of Toronto.

    He is a founding software engineer at Dropverse, which is a gamified blockchain-based app where users can collect tokens, participate in drops, etc. in the real world. It is primarily integrated with the Ethereum ecosystem (in particular, there is currently support for any EVM compatible chain). Major achievements in this role include building a microservice that relay meta-transactions originating from user custodial wallets.

    Rhys also has previous experience in research and development, and some of this work has been patented. In particular, he designed and implemented a novel algorithm which utilized sequential image recognition in order to synchronize secondary content with the current timestamp of a video. The patent can be found here: https://patents.google.com/patent/US11082679B1/en?oq=US11082679B1

    Team Code Reposโ€‹

    The majority of Rhysโ€™ work has been client-based work and is closed-source. His interest in other projects has led him to also contribute to various open-source projects, some of which can be found here:

    GitHub profile: https://github.com/rhysbalevicius

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    This application is in response to the anti-collusion infrastructure RFP.

    Development status will be found over at https://github.com/rhysbalevicius/infimum. This is empty at the time of submission.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 6 months
    • Full-Time Equivalent (FTE): 0,5 FTE
    • Total Costs: $27,000

    Milestone 1 โ€” Voting apparatus without verificationโ€‹

    • Estimated duration: 2 months
    • FTE: 0,5
    • Costs: 9,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationInline documentation. Basic guide explaining how to interact with the pallet will be provided in the README.
    0c.TestingUnit tests, GitHub actions CI workflow, and brief guide for running tests locally
    0d.DockerDockerfiles and docker-compose.yml for running a development environment which locally spins up a node and frontend template for observing events, calling pallet extrinsics, and performing state queries.
    1.Substrate palletMethods 1.ii.a to 1.ii.i (listed under deliverables in the project overview) without verification functionality provided by Groth16 proving system.

    Milestone 2 โ€” On-chain verification logic and circuitsโ€‹

    • Estimated Duration: 2 months
    • FTE: 0,5
    • Costs: 9,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationInline documentation. Amendment to the original guide explaining the requirements for satisfying the verification logic.
    0c.TestingUnit tests for methods added. Updated unit tests for amended methods.
    1a.Pallet: verification methodsPrivate methods for verifying proofs which have been generated off-chain by the CLI delivered in Milestone 3. Relies on the verification logic provided by bellman (https://github.com/zkcrypto/bellman).
    1b.Pallet: method modificationsModifications to methods 1.ii.h and 1.ii.i (listed under deliverables in the project overview) to call the private verification methods defined in Milestone 2.1.a โ€” these modifications will guard against storage updates in the case that verification fails, and publish the final poll outcome in the case of success.
    2.Circom circuitsFork of MACI circuits defined here (https://github.com/privacy-scaling-explorations/maci/tree/master/circuits/circom) and licensed under MIT, amended as necessary for consumption within our off-chain proof generation pipeline.

    Milestone 3 โ€” CLI tool and docsiteโ€‹

    • Estimated Duration: 2 months
    • FTE: 0,5
    • Costs: 9,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationInline documentation. Instructions for setting up and interacting with the CLI will be provided in the README.
    0c.TestingIntegration test scripts will be provided.
    0e.ArticleWe will provide an article directed towards parachain developers detailing: the motivation and general use case, an overview of the individual components of the system, the poll lifecycle, limitations and trust assumptions of the system, as well as an open invitation to contribute to the project.
    1a.TypeScript libraryA library which exposes the functionality described in 2.iii.a to 2.iii.c (listed under deliverables in the project overview), as well as all related helper functions.
    1b.CLI for operatorsCLI wrapper around 1a. Provides command line accessibility to the functionality required by operators to successfully interact with the pallet.
    1c.CLI for participantsCLI wrapper around 1a. Provides command line accessibility to the functionality required by participants to successfully interact with the pallet.
    2a.DocsiteWe will package the article in 0e., all documentation, and all necessary setup and usage instructions into a readable and user friendly docsite. This will be hosted and associated with the project under the URL section of the repository as well as linked to in the README.
    2b.Voting ExampleThe docker-compose.yml will be updated to (optionally) provision a simple coordinator script (using Node.js and TypeScript) which manages an example poll.
    2c.Voting TutorialWe will provide a tutorial which provides explicit step-by-step instructions on how to setup and interact with the voting example.

    Future Plansโ€‹

    1. Experimentation with alternative architectures
      1. In particular, we are interested in architectures which support on-chain tallying utilizing partial or fully homomorphic encryption, and verifiable computation schemes such as Rinnochio.
      2. Secure multi-party computation architecture which relies on multiple coordinators; this would enable complete secrecy of individual voter preferences. Ideally this would be combined with (1.i).
    2. Features and enhancements to deliverables
      1. Integration of transparent zk-SNARKS
      2. Reduce number of extrinsic calls required in the tallying phase, e.g. with Nova
      3. Support for different voting schemes, e.g. quadratic, ranked choice
    3. Additional systems and example integrations
      1. Off-chain worker (and potentially a backend service) to automatically perform the message processing, tallying, and proof generation computations
      2. dApp which provides a rich user interface for creating and participating in polls
      3. Example ink! smart contract demonstrating how to interface with the pallet, e.g. a fungible-token contract wherein the voting power of a single participant corresponds to the number of tokens they own
    4. Outreach
      1. Obtain a security audit of infrastructure
      2. Network with faculty and peers with the aim of collaborating on research goals
      3. Seek out possible integrations with a parachain, e.g. imbue

    Where appropriate, we would like to deliver some subset of these in follow up proposals.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Personal recommendation from a colleague.

    - + \ No newline at end of file diff --git a/applications/ink-analyzer-phase-2.html b/applications/ink-analyzer-phase-2.html index 0dc0fbb1a3c..da08f3ae917 100644 --- a/applications/ink-analyzer-phase-2.html +++ b/applications/ink-analyzer-phase-2.html @@ -4,7 +4,7 @@ ink! Analyzer (Phase 2) | Web3 Foundation Grants - + @@ -26,7 +26,7 @@ I've worked as a technical lead on projects for HubSpot, Permobil, Pressboard, Grindery, InboundLabs, Tunga, ButterflyWorks, Telegraaf Media Groep (TMG) and many more companies. I hold a Bachelor of Science in Computer Science degree from Makerere University, Kampala, Uganda. You can find my full profile at https://davidsemakula.com.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    I've delivered implementations of the semantic analyzer, language server and VS Code extension in the first W3F grant application for this project:

    The VS Code extension is published in the VS Code Marketplace at https://marketplace.visualstudio.com/items?itemName=ink-analyzer.ink-analyzer.

    ink! analyzer has also been added to the official ink! documentation portal at https://use.ink/getting-started/ink-analyzer (under "Third Party Tools and Libraries").

    You can find a full list of available resources in the introductory blog post for ink! analyzer.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Semantic analyzer: Quick fixes, ink_e2e macro support, project creation command and code/intent actions for inserting code stubs/snippets for relevant ink! entitiesโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT or Apache 2.0
    0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on Github, crates.io and docs.rs) providing general information about the library, instructions for installing and using the library and links to other documentation and resources related to the library.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Rust crate update: Quick fixes for all existing diagnostic errors and warningsI will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return quick fixes (suggested edits/code actions) for all existing diagnostics. I will leverage the existing methodology for extracting ink! semantic rules that was used to extract the existing (more than 74) diagnostics errors and warnings to determine the relevant quick fix(es) for each diagnostic based on the related semantic rules and context. The high-level methodology can be summarized as: 1) remove and/or replace ink! attribute for ink! attributes applied to the wrong Rust item (e.g. for #[ink(storage)] attribute applied to anything other than a struct, a quick fix to remove the ink! attribute and another to add a relevant ink! attribute, e.g #[ink::contract] if the original attribute was applied to a mod and no other ink! contracts are defined in the current file e.t.c) 2) remove and/or add/replace Rust invariants for ink! entities that don't satisfy ink! semantic rules based on expected Rust item invariants (e.g. add a self reference - i.e. &self or &mut self - to an #[ink(message)] whose fn item's parameters don't include a self reference, or remove a self reference from an #[ink(constructor) whose fn item's parameters include a self reference, or rename the associated type for a chain extension to ErrorCode if no other associated type named ErrorCode exists e.t.c) 3) move ink! entities to the appropriate "scope" (e.g. move ink! constructors and ink! messages implemented in the root of the ink! contract module to either the first non-trait impl block or create a new impl block to for them e.t.c). 4) update order of ink! attributes so that the "primary" attribute comes first (e.g. refactor #[ink(payable)]\n#[ink(message)] to #[ink(message)]\n#[ink(message)] or #[ink(anonymous, event)] to #[ink(event, anonymous)] e.t.c). This methodology should not be considered exhaustive at this point as more patterns may be found during actual implementation, in which case, they will be documented.
    2.Rust crate update: ink_e2e macro supportI will update the semantic analyzer crate to return diagnostics, quickfixes, completions, code/intent actions and hover content for the ink_e2e macro via the existing interfaces for all the aforementioned features. Diagnostics and quick fixes will be extracted using the existing methodology for extracting ink! semantic rules with the difference being the use of the ink_e2e_macro crate (instead of the ink_macro crate) as the entry point. Completions, code/intent actions (for adding the attribute macro and/or attribute arguments) and hover content will be added for the #[ink_e2e::test] macro as well as its associated attribute arguments (i.e. additional_contracts, environment and keep_attr).
    3.Rust crate update: Command for creating a new ink! project with a contract stubI will update the semantic analyzer crate to provide an interface that accepts a name as input and returns an ink! smart contract code stub/snippet similar to those created by cargo contract new.
    4.Rust crate update: Code/intent actions for inserting code stubs/snippets for relevant ink! entitiesI will update the semantic analyzer crate to provide an interface that accepts ink! smart contract code and a cursor position as input and returns code/intent actions for inserting code stubs/snippets for relevant ink! entities for the current context (e.g. in the context of the root of an ink! contract mod, code actions for inserting ink! storage - if an ink! storage struct isn't already defined - and/or ink! event code stubs/snippets which would wrap an edit that adds a struct annotated with the relevant ink! attribute e.g #[ink(event)] e.t.c). This applies to all ink! entities (i.e. contract, storage, constructor, message, event, trait definition, chain extension, storage item e.t.c.) that would be relevant for any given context - context being determined by the parent/ancestor ink! attribute annotations for the current cursor position.

    Milestone 2 โ€” Semantic Analyzer: Inlay hints, signature help/parameter hints and attribute "flattening"โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT or Apache 2.0
    0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on Github, crates.io and docs.rs) providing general information about the library, instructions for installing and using the library and links to other documentation and resources related to the library.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Rust crate update: Inlay hints for ink! attribute argument valuesI will update the semantic analyzer crate to provide an interface that accepts ink! smart contract code as input and returns inlay hints for ink! attribute argument values (e.g. u32 \| _ for selector values, u32 for extension values, &str (a valid Rust identifier for) for namespace values, &str (a comma separated list) for keep_attr values, Path for env and environment values e.t.c). Inlay hints will be provided for all ink! attribute arguments that require values (i.e env, keep_attr, namespace, selector, extension, handle_status, derive, additional_contracts, environment e.t.c).
    2.Rust crate update: Signature help/parameter hints for ink! attribute argumentsI will update the semantic analyzer crate to provide an interface that accepts ink! smart contract code and a cursor position as input and returns signature help/ parameter hints for relevant ink! attribute arguments. Signature help/parameter hints will be provided for all ink! attribute macros with associated ink! attribute arguments (e.g. env and keep_attr for #[ink::contract()], namespace and keep_attr for #[ink::trait_definition()], derive for #[ink::storage_item()] e.t.c) and "primary" ink! attribute arguments that can be combined with other ink! attribute arguments (e.g. anonymous for #[ink(event)], payable, selector and default for #[ink(message)], selector and default for #[ink(constructor)], handle_status for #[ink(extension)] e.t.c).
    3.Rust crate update: Code/intent actions for "flattening" ink! attributesI will update the semantic analyzer crate to provide an interface that accepts ink! smart contract code and a cursor position as input and returns code/intent actions for "flattening" relevant ink! attributes and arguments (e.g. converting #[ink(event)]\n#[ink(anonymous)] to #[ink(event, anonymous)], or #[ink(message)]\n#[ink(payable)]\n#[ink(selector = 1)] to #[ink(message, payable, selector = 1)] e.t.c). "Flattening" will be supported for all ink! attribute arguments that can be combined to form "compound" ink! attributes (e.g. event and anonymous for ink! events, message, payable, default and selector for ink! messages, impl and namespace for ink! impl, extension and handle_status for ink! extensions e.t.c) and for erroneously split ink! attribute macros and there associated arguments (e.g. converting #[ink::contract]\n#[ink(env=crate::Environment)]\n#[ink(keep_attr="foo, bar")] to #[ink::contract(env=crate::Environment, keep_attr="foo, bar")] e.t.c).

    Milestone 3 โ€” Semantic Analyzer: Go to definition, find references and rename/refactor support for path-based ink! attribute argument values and diagnostics, quick fixes and code/intent actions ink! attribute argument values that should impl Environmentโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT or Apache 2.0
    0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on Github, crates.io and docs.rs) providing general information about the library, instructions for installing and using the library and links to other documentation and resources related to the library.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Rust crate update: Diagnostics that verify resolution of path expressions for env for #[ink::contract] and environment for #[ink_e2e::test] argument values as well as quick fixes that either fix paths (e.g. by fixing or adding a qualifier) or suggest paths to valid item definitions (where possible)I will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for resolution of path expressions for env for #[ink::contract] and environment for #[ink_e2e::test] argument values whose value doesn't resolve to any item as well as quick fixes in the form of code/intent actions that either fix paths (e.g. by fixing or adding a qualifier) or suggest paths to valid item definitions (where possible).
    2.Rust crate update: Diagnostics that verify that env values for #[ink::contract] and environment values for #[ink_e2e::test] are impl Environment as well as quick fixes to impl Environment for the target item where necessaryI will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for env values for #[ink::contract] and environment values for #[ink_e2e::test] whose target item doesn't impl Environment as well as quick fixes in the form of code/intent actions that insert code stubs/snippets that impl Environment for the target item where necessary.
    3.Rust crate update: Diagnostics that verify that ink! trait definition impl blocks implement all associated methods as well as quick fixes for implementing missing methods where necessaryI will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for ink! trait definition impl blocks that don't implement all associated methods as well as quick fixes in the form of code/intent actions that add code stubs/snippets for implementing missing methods where necessary.

    Milestone 4 โ€” Semantic Analyzer: Diagnostics, quick fixes and code/intent actions for chain extension ErrorCode type is impl FromStatusCode , and is not referred to using Self::ErrorCode anywhere in the chain extension or its defined methodsโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT or Apache 2.0
    0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on Github, crates.io and docs.rs) providing general information about the library, instructions for installing and using the library and links to other documentation and resources related to the library.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Rust crate update: Diagnostics that verify that the chain extension ErrorCode type is impl FromStatusCode as well as quick fixes and code/intent actions to impl FromStatusCode for the target item where necessaryI will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for chain extension ErrorCode types whose target item doesn't impl FromStatusCode as well as quick fixes in the form of code/intent actions that insert code stubs/snippets that impl FromStatusCode for the target item where necessary.
    2.Rust crate update: Diagnostics for references to the chain extension's ErrorCode type using Self::ErrorCode in the chain extension (i.e. the #[ink::chain_extension] annotated trait) or it's defined methods (i.e. impl blocks for the chain extension trait in a #[ink::contract] annotated mod) as well as quick fixes to replace Self::ErrorCode usages with the ErrorCode type directlyI will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for references to the chain extension's ErrorCode type using Self::ErrorCode in the chain extension (i.e. the #[ink::chain_extension] annotated trait) or it's defined methods (i.e. impl blocks for the chain extension trait in a #[ink::contract] annotated mod) as well as quick fixes in the form of code/intent actions that replace Self::ErrorCode usages with the ErrorCode type directly.
    3.Rust crate update: Diagnostics that verify that the chain extension ErrorCode type implements SCALE codec traits (i.e. scale's Encode and Decode and scale-info's TypeInfo) as well as quick fixes and code/intent actions to implement the SCALE codec traits for the target item where necessaryI will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for chain extension ErrorCode types whose target item doesn't implement SCALE codec traits (i.e. scale's Encode and Decode and scale-info's TypeInfo) as well as quick fixes in the form of code/intent actions that insert code stubs/snippets that implement SCALE codec traits for the target item where necessary.
    4.Rust crate update: Diagnostics that verify that input and output types of chain extension methods implement SCALE codec traits (i.e. scale's Encode and Decode and scale-info's TypeInfo) as well as quick fixes and code/intent actions to implement the SCALE codec traits for the target item where necessaryI will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for input and output types of chain extension methods whose target items don't implement SCALE codec traits (i.e. scale's Encode and Decode and scale-info's TypeInfo) as well as quick fixes in the form of code/intent actions that insert code stubs/snippets that implement SCALE codec traits for the target items where necessary.

    Milestone 5 โ€” Language Server: Updates #1โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT or Apache 2.0
    0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on Github, crates.io and docs.rs) providing general information about the crate, instructions for installing and using the crate and links to other documentation and resources related to the crate.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Rust binary crate update: ink! Language Server updatesI will update Rust binary crate that implements the Language Server Protocol to support features added to the semantic analyzer in milestones 1 and 2 above.

    Milestone 6 โ€” Language Server: Updates #2โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT or Apache 2.0
    0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on Github, crates.io and docs.rs) providing general information about the crate, instructions for installing and using the crate and links to other documentation and resources related to the crate.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Rust binary crate update: ink! Language Server updatesI will update Rust binary crate that implements the Language Server Protocol to support features added to the semantic analyzer in milestones 3 and 4 above.

    Milestone 7 โ€” Visual Studio Code Extension: Updatesโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPL-3.0
    0b.DocumentationI will provide inline source documentation and a README file (published on Github and the VS Code marketplace) providing general information about the extension, instructions for installing and using the extension and links to other documentation and resources related to the extension.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive integration tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleI will publish an article that introduces the new features of ink! analyzer, including updates to the VS Code extension, the language server and the semantic analyzer.
    1.Visual Studio Code Extension: UpdatesI will update the Visual Studio Code Extension to support the ink! language support features added to the language server and semantic analyzer in milestones 1, 2, 3, 4, 5 and 6 above. Visual interface demos of all the IDE/editor features can be found in VS Code extension documentation for diagnostics, completions, hover content, code actions, quick fixes, signature help/parameter hints (demo uses functions but should still be helpful for interface visualization for ink! attribute arguments), inlay hints, go to definition, find references, rename/refactor, snippets/code stubs and commands.

    Future Plansโ€‹

    I will publish updates to the VS Code extension to the VS Code marketplace.

    In the short-term, I will likely apply for follow-up funding for:

    As the project is a public good, the long-term goal is to create a community of users, contributors and ecosystem partners who are invested in the project's long-term success because of its utility.

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    N/A

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Web3 Foundation Website.

    - + \ No newline at end of file diff --git a/applications/ink-analyzer.html b/applications/ink-analyzer.html index f202dce687d..29f391cc816 100644 --- a/applications/ink-analyzer.html +++ b/applications/ink-analyzer.html @@ -4,7 +4,7 @@ ink! Analyzer | Web3 Foundation Grants - + @@ -32,7 +32,7 @@ I hold a Bachelor of Science in Computer Science degree from Makerere University, Kampala, Uganda. You can find my full profile at https://davidsemakula.com.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    I've developed a proof of concept (POC) for the semantic analyzer that can be accessed on Github at https://github.com/ink-analyzer/ink-analyzer. The POC implements a diagnostic that detects when the #[ink::contract] attribute is applied to anything other than a mod item and returns a diagnostic model that includes an error message and the text range to which the diagnostic applies.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Semantic Analyzer: Setup and Diagnosticsโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 and MIT
    0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on on Github, crates.io and docs.rs) providing general information about the library, instructions for installing and using the library and links to other documentation and resources related to the library.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Rust library crate: Diagnostic errorsI will create a Rust library crate with an interface that accepts ink! smart contract code as input and returns diagnostic errors based on ink!'s semantic rules. Diagnostic errors will include: conflicting ink! attributes and/or arguments based on the item being annotated and list of ink! attribute arguments (e.g #[ink(storage)] applied to anything other than a struct), missing required ink! attributes (e.g no #[ink(constructor)], #[ink(storage)] or #[ink(message)] in a contract mod), multiple annotations of attributes and/or arguments that can only be applied to one item in a contract (e.g multiple #[ink(storage)] structs or more than one wildcard selector among #[ink(message)], as well as #[ink(constructor)] methods), duplicate ink! attributes on an item (e.g multiple #[ink(message)] annotations on one method), overlapping #[ink(constructor)]and #[ink(message)] selectors.

    Milestone 2 โ€” Semantic Analyzer: Code completion suggestions, code/intent actions and hover contentโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 and MIT
    0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on on Github, crates.io and docs.rs) providing general information about the library, instructions for installing and using the library and links to other documentation and resources related to the library.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Rust crate update: Code completion suggestionsI will update the semantic analyzer crate to provide an interface that accepts ink! smart contract code and a cursor position as input and returns code completion suggestions for relevant ink! attributes and arguments.
    2.Rust crate update: Code/intent actionsI will update the semantic analyzer crate to provide an interface that accepts ink! smart contract code and a cursor position as input and returns code/intent actions for adding relevant ink! attributes and arguments.
    3.Rust crate update: Hover contentI will update the semantic analyzer crate to provide an interface that accepts ink! smart contract code and a text range as input and returns documentation for relevant ink! attributes and arguments.

    Milestone 3 โ€” Language Serverโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 and MIT
    0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on on Github, crates.io and docs.rs) providing general information about the crate, instructions for installing and using the crate and links to other documentation and resources related to the crate.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Rust binary crate: ink! Language Server Protocol implementationI will create Rust binary crate that implements the Language Server Protocol for the ink! language support features provided by the semantic analyzer as outlined in milestones 1 and 2 above (i.e diagnostic errors, code completion suggestions, code/intent actions and hover content as defined in the respective milestones above).

    Milestone 4 โ€” Visual Studio Code Extensionโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPL-3.0
    0b.DocumentationI will provide inline source documentation and a README file (published on on Github and the VS Code marketplace) providing general information about the extension, instructions for installing and using the extension and links to other documentation and resources related to the extension.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive integration tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
    0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleI will publish an article that explains how to use all the components of ink! analyzer, including the VS Code extension, the language server and the semantic analyzer.
    1.Visual Studio Code ExtensionI will create a Visual Studio Code Extension that supports the ink! language support features provided by the language server and semantic analyzer as outlined in milestones 1, 2 and 3 above (i.e diagnostic errors, code completion suggestions, code/intent actions and hover content as defined in the respective milestones above).

    Future Plansโ€‹

    I will publish the VS Code extension to the VS Code marketplace and share it along with the code and documentation for all ink! analyzer components in Substrate / Polkadot / Kusama ecosystem developer communities.

    In the short-term, I will likely apply for follow-up funding for:

    As the project is a public good, the long-term goal is to create a community of users, contributors and ecosystem partners who are invested in the project's long-term success because of its utility.

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    N/A

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Web3 Foundation Website.

    - + \ No newline at end of file diff --git a/applications/ink-boxes.html b/applications/ink-boxes.html index 0a36cb59780..024e450f30a 100644 --- a/applications/ink-boxes.html +++ b/applications/ink-boxes.html @@ -4,7 +4,7 @@ Ink Boxes | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Ink Boxes

    • Team Name: Ink Boxes Team

    • Payment Address: Bitcoin Address: bc1qtr9993ch6zlr29j5c22zzax57h62x5gj24wtxk

    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Ink boxes are a collection of helpful Ink smart contract boilerplates along with it's frontend. It will already have polkadot.js library using which frontend can talk with the smart contract deployed. Got inspired by truffle boxes on how easily one can spin up the boilerplate code in no time.

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem? Anyone who wants to quickly spin up boilerplate can use our platform.
    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)? Anyone who wants to create Smart Contracts on top of Ink are our target users.

    User Journeyโ€‹

    • User visits Ink boxes website.
    • User selects the dApp they want to download.
    • User will be able to download the entire dApp code in zip format.
    • Contributors can also submit a new dApp if it is fit for the substrate ecosystem. They need to provide the GitHub repo link for the ink box.

    Simillar platformsโ€‹

    • Truffle Boxes

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • @nerdsince98
    • Registered Legal Entity: Not yet registered

    Team's experienceโ€‹

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overview

    Grant levelโ€‹

    Level 1: Up to $10,000, 2 approvals

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 4 weeks

    • Total Costs: 5,000 USD

    Milestone 1โ€‹

    • Estimated Duration: 2 weeks

    • Costs: 3,500 USD

    NumberDeliverableSpecification
    0a.Apache License 2.0All code will be published under Apache 2.0
    0b.DocumentationWe will provide both inline documentation of the code.
    0c.Testing and it's GuideCore functions will be fully covered by comprehensive unit tests written in Jest and UI tests in Cypress to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticlesWe will publish a series of articles on how to contribute and create new boxes.
    0.Creation of BoxesWe will create boxes in a GitHub repo like NFT-Marketplace, Decentralized Ecommerce platform, ERC-721 with UI functionalities, ERC-20 with UI functionalities. Complete list will be provided in the GitHub repo README and coming soon section of the website.

    Milestone 2โ€‹

    • Estimated Duration: 2 weeks

    • Costs: 1,500 USD

    NumberDeliverableSpecification
    0a.Apache License 2.0All code will be published under Apache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to develop a new box.
    0c.Testing and it's GuideCore functions will be fully covered by comprehensive unit tests written in Rust to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticlesWe will publish a series of tutorials on how to contribute to website.
    0.Creation of website.We will create a website where anyone can download the box in zip format and can upload the same. Website will accept the GitHub link of the box. If anyone tries to download the box, GitHub release of the box will be downloaded.

    Additional Information โž•โ€‹

    • We're currently implementing it in substrate ecosystem.
    - + \ No newline at end of file diff --git a/applications/ink-explorer.html b/applications/ink-explorer.html index ac3caa5baa9..54fc7e4f0a4 100644 --- a/applications/ink-explorer.html +++ b/applications/ink-explorer.html @@ -4,14 +4,14 @@ Ink Explorer | Web3 Foundation Grants - +
    Skip to main content

    Ink Explorer

    • Team Name: Blockcoders
    • Payment Address: Ethereum (USDT/USDC/DAI) 0x0B7144E7960Ac666A6AD6B38Fe65C2fe96E65994
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Ink Explorer is an application that provides Ink contracts related information on Substrate based blockchains. It subscribes to blockchain and Ink modules events and store the information on its own PostgreSQL database. The backend exposes an API that can interact with the DB and run fast queries to get specific information in a short time.

    The idea of this project is to have fast way to start a node that can be used as an explorer getting live and old data for specific contracts or addresses.

    This project serves useful information that is not available anywhere else. Since the back end is in charge of obtaining information related to the balances, transactions and more, of the contracts that use Ink modules. Ink Explorer uses polkadot.js to communicate with the Substrate / Polkadot networks. It is safe to say that this project is a must.

    Blockcoders is a team that is always contributing to blockchain projects to help the growth of the ecosystem.

    Ecosystem Fitโ€‹

    Help us locate your project in the Polkadot/Substrate/Kusama landscape and what problems it tries to solve by answering each of these questions:

    • Where and how does your project fit into the ecosystem?
      • It gives a solution for all the ones that are interested in analyzing Ink contracts information.
    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?
      • Anyone who is interested in working with contracts that use the Ink protocol and has an interest in accessing as much information as possible about what is happening with said contracts.
    • What need(s) does your project meet?
      • Obtain the greatest amount of information about what is happening with contracts that use the Ink protocol in a fast and easy way.
    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?
      • There are block explorers, but these are limited to saving and accessing information related to blocks and transactions, but are not intended to provide contract-oriented information.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Jose Ramirez
    • Damiรกn Fixel
    • Fernando Sirni

    Contactโ€‹

    • Registered Address: Bouchard 705, Buenos Aires Argentina
    • Registered Legal Entity: Blockcoders

    Team's experienceโ€‹

    Our team has been contributing with different projects in blockchain for a few years, building APIs, SDKs and developer tools. Our goal is to continue to drive the crypto space forward by investing intellectual capital into projects, participating actively to help shape the ecosystems we believe in.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4 month
    • Full-Time Equivalent (FTE): 2
    • Total Costs: 30000 USD

    Milestone 1 - Backendโ€‹

    • Estimated duration: 2.5 month
    • FTE: 2
    • Costs: 20,000 USD

    In this milestone the focus is on creating a new service that can be consider a full node of the aplication that will create a new DB and will start syncing all the data from the blockchain (can be synced from genesis or a specific block). This node will also have the frontend covered in Milestone 2. The service will expose an API that will provide all the required information that the frontend may need.

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both english and spanish versions of the documentation. This will cover step by step how to set up and start the project using both docker and running the node locally.
    0c.Testing GuideUnit test and end to end tests will cover the core functions to ensure everything works as expected. The documentation will have an example on how to run these tests.
    0d.DockerA Dockerfile will be provided that will be able to start the node and run tests for all the functionality delivered within this milestone.
    0e.ArticleWe will post an article on Twitter and Reddit for both english and spanish speakers communities.
    1.Create databaseCreate a docker container to start a PostgreSQL database to store all the information, define the models to store and create tables and indexes.
    2.Backend serviceCreate a docker container to start a typescript service that subscribes to blockchain events and Ink modules events. This service will store and index the information in the database to be accessed quickly and easily. Add all subscriptions needed to retrieve the information of the emited events from both the blockchain (using polkadot.js) and Ink modules. Store and index the events data on the database. (If needed sync all data from blockHash - can be from genesis but it will take longer)
    3.APIExtend the service functionality to expose an API that gets the contracts data
    4.TestingAchieve a testing coverage of the functionalities above 90%

    Deliverables in this milestone will be dockerized. We will provide a README with examples showing how to start the service, and query the API.

    Milestone 2 - Frontendโ€‹

    • Estimated Duration: 1.5 month
    • FTE: 2
    • Costs: 10,000 USD

    This milestone is entirely about creating a frontend app and making it work along with the back end service. The app will be mounted on the same docker as the backend service so it can be started with a single docker command.

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both english and spanish versions of the documentation. This will cover step by step how to set up and start the project using both docker and running the node locally.
    0c.Testing GuideUnit test and end to end tests will cover the core functions to ensure everything works as expected. The documentation will have an example on how to run these tests.
    0d.DockerA Dockerfile will be provided that will be able to start the node and run tests for all the functionality delivered within this milestone.
    0e.ArticleWe will post an article on Twitter and Reddit for both english and spanish speakers communities.
    1.Create AppCreate a frontend application that follows the proposed design. Cover the following functionalities: Blocks explorer, Transactions explorer and Contracts explorer (this section will provide to the user information related to the contract, such as transactions, the contract data and events). Dockerize the app to start in a container.
    2.Support for Spanish speakers communityTranslate the app to spanish and add support to switch languages.
    3.TestingAdd tests to the components. Achieve a testing coverage of the functionalities above 90%
    4.Final setupsDeal with all production issues/configuration requirements such as creating the final docker image, reviewing the documentation and verifying everything works fine.
    5.Deploy the appDefine the final domain and deploy the app.

    User Interfaceโ€‹

    The user interface will be based on this mock-up:

    Blockcoders Ink Explorer

    Future Plansโ€‹

    We plan to expose all the data throughout a Graphql application and add support for more languages.

    Licenseโ€‹

    Apache license version 2.0

    - + \ No newline at end of file diff --git a/applications/ink-pallet-benchmarking-phase-2.html b/applications/ink-pallet-benchmarking-phase-2.html index 39194a1d75f..39f7e7250c9 100644 --- a/applications/ink-pallet-benchmarking-phase-2.html +++ b/applications/ink-pallet-benchmarking-phase-2.html @@ -4,14 +4,14 @@ ink!/pallet/solidity performance benchmarking phase 2 | Web3 Foundation Grants - +
    Skip to main content

    ink!/pallet/solidity performance benchmarking phase 2

    • Team Name: Talentica Software
    • Payment Address: 0x8bd54ec34A35f3A2f668A33d9578b5C3A6b730dE
    • Level: 1

    Project Overview :โ€‹

    Proposal for Milestone 2 in the RFP titled implementation-benchmarking.

    Overviewโ€‹

    There are multiple ways to implement the logic in substrate i.e using pallets or ink smart contracts, or even writing solidity code and compiling it to WASM with the help of a solang compiler. We have to benchmark the performance metrics of the logic implemented using each of the above methods. We have already benchmarked the storage performance(basic data types) of each of the implementations as part of Milestone 1 and 2. Now, we will benchmark CPU-intensive logic, events emission and cross-contract calls across all the four implementations. We hope this will help new developers in deciding the best approach to implement the logic.

    Project Detailsโ€‹

    We will employ the approach already taken to deliver Milestones 1 and 2 to benchmark CPU intensive task on all the four implementation strategies and also cross-contract calls within an implementation, wherever possible. We will use following tools to do so:

    Ecosystem Fitโ€‹

    This will help new developers to decide the best tool to implement the logic.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    • Registered Address: Talentica Software Inc., 6200, Stoneridge Mall Road, Pleasanton, California 94588, USA.
    • Registered Legal Entity: Talentica Software Inc.

    Team's experienceโ€‹

    We have already worked on implementation-benchmarking and delivered Milestones 1 and 2.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status :โ€‹

    We have come up with a high-level implementation plan and will start implementing it soon.

    Development Roadmap ๐Ÿ”ฉโ€‹

    NumberObjectiveDeliverableTime Estimate
    1.Milestone 3, Deliverable 12 days
    2.Milestone 3, Deliverable 22 days
    3.Milestone 3, Deliverable 31 day
    4.Milestone 3, Deliverable 42 days
    5.Milestone 3, Deliverable 53 days
    6.Milestone 3, Deliverable 63 day
    7.Milestone 3, Deliverable 73 days
    8.Milestone 3, Deliverable 83 days
    9.Milestone 3, Deliverable 91 days
    10.Milestone 3, Deliverable 101 days
    11.Milestone 3, Deliverable 111 days
    12.Milestone 3, Deliverable 121 days
    13.Milestone 3, Deliverable 0b, 0e1 day

    Overviewโ€‹

    • Total Estimated Duration: 5 Weeks
    • Full-Time Equivalent (FTE): 1
    • Total Costs: 6,000 DAI

    Milestone 3 - Compute intensive function and cross-contract call benchmarkingโ€‹

    • Estimated duration: 5 Weeks
    • FTE: 1
    • Costs: 6,000 DAI

    โ— The default deliverables 0a-0d below are mandatory for all milestones, and deliverable 0e at least for the last one.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and and an article explaining how to use the tool to benchmark custom compute intensive functions and cross-contract calls along with a live demo if possible.
    0c.Testing and Testing GuideWe are building atop of the benchmarking framework that's part of the substrate-core. Some tests may be included when it comes to the functions being tested.
    0d.DockerNot Applicable.
    0e.ArticleWe will publish an article that explains how each implementation technique performs, and when to choose which.
    1.Pallet CPU-intensive extrinsicExtend a sample pallet to include a CPU-intensive extrinsic.
    2.Ink! CPU-intensive functionExtend a sample Ink! contract to include a CPU-intensive function.
    3.Solidity-WASM and Solidity-Native CPU-intensive functionExtend a sample Solidity contract to include a CPU-intensive function
    4.CPU-intensive benchmarksRun the benchmarks on all these implementations and compare.
    5.Pallet cross-contract callAdd another pallet and invoke it from the sample pallet.
    6.Ink! cross-contract callAdd another Ink! contract and invoke it from the sample Ink! contract.
    7.cross-contract benchmarksrun cross-contract calls across different implementations and collect benchmarks.
    8.Solidity-WASM and Solidity-Native cross-contract callAdd another Solidity contract and invoke it from the sample Solidity contract. (Note: There are unresolved issues questioning the feasibility of cross-contract calls in Solidity-WASM and Solidity-Native. Nevertheless, an attempt will be made to see if it's possible.
    9.Pallet eventsbenchmark events emitted from the sample pallet.
    10.Ink! eventsbenchmark events emitted from the sample Ink! contract.
    11.Solidity-WASM and Solidity-Native eventsbenchmark events emitted from the Solidity-WASM and Solidity-Native contracts.
    12.Benchmark events across implementationsbenchmark and record events emission across implementations.

    We are planning to submit another grant application towards Milestone 4 where we discuss our approach to maintaining this work, using some software tools to automate the process wherever possible.

    Additional Information โž•โ€‹

    Gautam Dhameja told us about the Grants program and encouraged us to apply to the same. We have already applied for and delivered Milestones 1 and 2 against implementation-benchmarking

    - + \ No newline at end of file diff --git a/applications/ink-pallet-benchmarking.html b/applications/ink-pallet-benchmarking.html index 2e33f9df9f9..108f7bf0dab 100644 --- a/applications/ink-pallet-benchmarking.html +++ b/applications/ink-pallet-benchmarking.html @@ -4,13 +4,13 @@ ink!/pallet/solidity performance benchmarking | Web3 Foundation Grants - +
    Skip to main content

    ink!/pallet/solidity performance benchmarking

    • Team Name: Talentica Software
    • Payment Address: 0x8bd54ec34A35f3A2f668A33d9578b5C3A6b730dE
    • Level: 1

    Project Overview :โ€‹

    Proposal for the RFP titled ink!/pallet/solidity performance benchmarking.

    Overviewโ€‹

    There are multiple ways to implement the logic in substrate i.e using pallets or ink smart contracts, or even writing solidity code and compiling it to WASM with the help of a solang compiler. We have to benchmark the performance metrics of the logic implemented using each of the above methods. This will help new developers to decide the best tool to implement the logic.

    Project Detailsโ€‹

    We will use following tools to benchmark the ink smart contract/pallet:

    Team Membersโ€‹

    Contactโ€‹

    • Registered Address: B-7/8, Anmol Pride, Baner Road, Baner, Pune, Maharashtra 411045, India
    • Registered Legal Entity: Talentica Software India Pvt. Ltd.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status :โ€‹

    We have explored the tools specified in the RFP. We have also come up with a high-level implementation plan and will start implementing it soon.

    Development Roadmap :โ€‹

    NumberObjectiveDeliverableTime Estimate
    1.Create a unified framework to work with both, Substrate Runtime Benchmarking Framework and Smart-benchMilestone 1, Deliverable 43 days
    2.Test it with existing palletsMilestone 1, Deliverable 42 days
    3.Create new pallets for benchmarkingMilestone 1, Deliverable 23 days
    4.Test it with the new palletsMilestone 1, Deliverable 22 days
    5.Create new Ink smart contracts for benchmarkingMilestone 1, Deliverable 33 days
    6.Test it with the new Ink smart contractsMilestone 1, Deliverable 32 days
    7.Adapt Smart Bench to work with arbitrary Solidity smart contractsMilestone 1, Deliverable 41 week
    8.Create new Solidity smart contracts for benchmarkingMilestone 2, Deliverable 13 days
    9.Test it with the new Solidity smart contractsMilestone 2, Deliverable 12 days
    10.Adapt the framework to work with the above smart contractsMilestone 2, Deliverable 21 Week

    Overviewโ€‹

    • Total Estimated Duration: 6 weeks
    • Full-Time Equivalent (FTE): 1
    • Total Costs: 10,000 DAI

    Languagesโ€‹

    • Rust
    • Solidity

    Milestonesโ€‹

    Milestone 1 โ€” Basic benchmarkingโ€‹

    • Estimated duration: 3 weeks
    • FTE: 1
    • Costs: 5000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a live demo.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0e.ArticleWe will publish an article that explains how each implementation technique performs, and when to choose which.
    1.Performance metricsAfter examining the existing benchmarking tools and discussing with their developers, we believe weight alone serves as a good metric to analyse performance.
    2.Pallet: Basic Read & WriteWe will create some pallets which expose simple methods for writing to storage and reading from on-chain storage.
    3.Ink Smart Contract: Basic Read & WriteWe will create some ink smart contracts which expose simple methods for writing to storage and reading from on-chain storage.
    4.Library: BenchmarkingWe will deliver a Rust library that allows calling both the pallet's extrinsics and contract's public methods multiple times and return the benchmarks.

    Milestone 2 โ€” Integrate native solidity & solang-compiled solidityโ€‹

    • Estimated duration: 3 weeks
    • FTE: 1
    • Costs: 5000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a live demo.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0e.ArticleWe will publish an article that explains how each implementation technique performs, and when to choose which.
    1.Solidity(native and WASM) Smart Contract: Basic Read & WriteWe will create some solidity smart contracts which expose simple methods for writing to storage and reading from on-chain storage.
    2.Adapt the benchmarking frameworkWe will adapt the benchmarking framework so it can handle WASM and native solidity code benchmarking.

    Additional Information:โ€‹

    Gautam Dhameja told us about the Grants program and encouraged us to apply to the same.

    - + \ No newline at end of file diff --git a/applications/ink-playground-ide-improvements.html b/applications/ink-playground-ide-improvements.html index 44d2b68dfd9..818a777cc86 100644 --- a/applications/ink-playground-ide-improvements.html +++ b/applications/ink-playground-ide-improvements.html @@ -4,7 +4,7 @@ Ink Playground IDE Improvements Grant | Web3 Foundation Grants - + @@ -33,7 +33,7 @@ Round from Leo Capital and Blu Ventures. It plans to deploy the funds towards product development, augmenting the technology team and enhancing its reach among DApp developers and global corporations, please consider visiting our prior work.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Before applying for the Web3 Foundation Grant, the Zeeve team has built a DevOps automation for Polkadot and other substrate chains, also created substrates based relay chains:

    Development Road-map ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement Ink's Dependency versioningโ€‹

    NumberDeliverableSpecification
    0.a.LicenseApache-2.0
    0.b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can open and save a file
    1.On demand version specific compilationWe will add the ability to build the compiler environment if a compiler environment is not present with a specific version of Ink!
    2.Dependency Version supportWe will upgrade and maintain Ink! and cargo-contract dependencies versions up to date and have provision to have older version support
    3.Ink! UpgradesWe will add the ability to add Playground's Ink! version support to latest version as soon as new version of Ink! is released without manual intervention
    4.Select Ink! version from UIWe will add ability to select Ink!'s version from the IDE to compile

    Milestone 2 - Ink! crate docs code executionโ€‹

    NumberDeliverableSpecification
    0.a.LicenseApache-2.0
    0.b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can open and save a file
    1.Ink! Create docsWe will provide the API and update create docs to run the code examples

    Technology Stackโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website / Parity team / a conversation with Richard Casey.

    References:โ€‹

    [1]: What is Parity's ink!? | Parity Technologies

    [2]: ink/ARCHITECTURE.md at master ยท paritytech/ink ยท GitHub

    - + \ No newline at end of file diff --git a/applications/ink-smart-contract-wizard.html b/applications/ink-smart-contract-wizard.html index 3113cf94245..d3d3e271dd3 100644 --- a/applications/ink-smart-contract-wizard.html +++ b/applications/ink-smart-contract-wizard.html @@ -4,7 +4,7 @@ Ink Contracts Wizard | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Ink Contracts Wizard

    • Team Name: Ink Contracts Wizard Team

    • Payment Address: Bitcoin Address: bc1qtr9993ch6zlr29j5c22zzax57h62x5gj24wtxk

    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Ink Contracts Wizard is an CLI based smart contract generation tool. It will scaffold Smart Contracts based on the options selected by the user. Once all the options are selected, user will have smart contract scaffolded in the machine.

    CLI commandsโ€‹

    CLI will have following commands.

    ink-wiazrd --help

    Print outs all the available commands.

    ink-wizard new flipper

    Create boilerplate code for Flipper Smart Contract.

    ink-wizard new psp-22

    Create boilerplate code for PSP-22 standard smart contracts, it is as same as ERC-20 standard.

    ink-wizard new psp-34

    Create boilerplate code for PSP-34 standard smart contracts, it is as same as ERC-1155 standard.

    ink-wizard new psp-37

    Create boilerplate code for PSP-37 standard smart contracts, it is as same as ERC-721 standard.

    In an interactive way, CLI will ask user if they want to have mint, burn, Pausable, Capped, Ownable, etc. functionality.

    Motivationโ€‹

    A lot of people use OpenZepplin's Smart Contract Wizard tool on daily basis since they are industry standard. We will be using OpenBrush smart contracts: https://github.com/Supercolony-net/openbrush-contracts. The reason to use OpenBrush Library is to abstract away a lot of details like OpenZepplin Smart Contracts does otherwise Smart Contracts code will end up being too bloaty.

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem? Anyone who wants to quickly scaffold smart contract from the UI are our users.
    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)? Anyone who wants to create Smart Contracts on top of Ink are our target users.

    User Journeyโ€‹

    • User installs the CLI.
    • User selects option in which she wants there smart contracts to have functionality.
    • User will be able to generate the Smart Contract.
    • Smart contracts will be scaffolded in the user's machine.

    Simillar platforms for solidityโ€‹

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Aviraj Khare

    Contactโ€‹

    • Contact Name: Aviraj Khare
    • Registered Legal Entity: Not yet registered

    Team's experienceโ€‹

    • Aviraj Khare: Worked in Gojek, Dukaan in the past. Into Web3 space since 2016. Successfully completed Ink Boxes grant.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overview

    Grant levelโ€‹

    Level 1: Up to $10,000, 2 approvals

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 4 weeks

    • Total Costs: 5,000 USD

    Milestone 1โ€‹

    • Estimated Duration: 2 weeks

    • Costs: 3,000 USD

    NumberDeliverableSpecification
    0a.Apache License 2.0All code will be published under Apache 2.0
    0b.DocumentationWe will provide both inline documentation of the code.
    0c.Testing and it's GuideCore functions will be fully covered by comprehensive unit tests written in unittest in python which is a great test runner to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0.Conversion of OpenBrush smart contracts written in Ink to it's templates and sub-templates.We will be using this code repo: https://github.com/Supercolony-net/openbrush-contracts and will convert them into basic templates and it's sub templates. We will be converting PSP-22, PSP-34, PSP-37 contracts.
    1.Creation of code generation logic for Ink smart contracts.We will be building our own code generator in Python. We will have templatized code and code convertor will output the rendered code with user's selected options.

    Milestone 2โ€‹

    • Estimated Duration: 2 weeks

    • Costs: 2,000 USD

    NumberDeliverableSpecification
    0a.Apache License 2.0All code will be published under Apache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can run the CLI to generate the smart contracts.
    0c.Testing and it's GuideCore functions will be fully covered by comprehensive unit tests written using unittest package to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticlesWe will publish an article on Medium on how to use this CLI tool.
    0.Smart Contract Generator CLIWe will be building this CLI using Typer package using which we can create interactive CLI.
    1.Push the Python package to PyPiWe will push this python package to PyPi so that users can install the package using pip3.
    2.Creation of formula for CLIWe will be creating homebrew formula so that users can easily install this CLI tool. Since most of the substrate ecosystem users use Rust, having formula will remove dependency to install python.

    Additional Information โž•โ€‹

    Future plansโ€‹

    Once we are done with grants, we will be adding ink-boxes so that anyone can scaffold any ink-box using the same CLI.

    - + \ No newline at end of file diff --git a/applications/ipfs_utilities.html b/applications/ipfs_utilities.html index dfcb0b85f28..b0345301cc5 100644 --- a/applications/ipfs_utilities.html +++ b/applications/ipfs_utilities.html @@ -4,7 +4,7 @@ Substrate IPFS Utilities | Web3 Foundation Grants - + @@ -15,7 +15,7 @@ Especially for NFT products this solution is helpful to avoid external middleware implemetations taking action. Having the whole logic for minting NFTs with related content inside Substrate makes it easier to maintain and more secure.

    Technology Stackโ€‹

    Blockchain

    Team ๐Ÿ‘ฅโ€‹

    Team Membersโ€‹

    The team setup might change depending on the availability at TDSoftware. With 40+ employees, TDSoftware has various developers that might contribute to the project. In all probability the members listed above will attend.

    Contactโ€‹

    Team's experienceโ€‹

    We have years of experience bringing ideas to life with a user-centered focus using blockchain and mobile technology. We have worked closely with many customers to implement their solutions and have already gained experience with blockchain technologies. Our most relevant projects are, among others:

    We look forward to contributing to the web3 ecosystem with an open-source project next.

    Team Code Reposโ€‹

    Source code will be in:

    Team profiles:

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    A concept and solution draft was created as part of this application and can be found in the Project Details chapter.

    As described above, we will reuse the existing IPFS node implementation developed by: offchain::ipfs. This solution is not handling the CID in a proper way. E.g. instead of returning the CID, it's just logging it out. It also provides the reading of the file thru an extrinsic. As the file is public on IPFS, that is not necessary.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 - Research and implementation of file upload featureโ€‹

    After the first research, the pallet implementation will be developed. The goal of milestone 1, is a fully working round trip (except the redirect feature). A web3 client, reading a file, calling an extrinsic and uploading the content of a file, will be developed. The CID information from IPFS will be stored in the pallet. Please see the chapter above ("Project Details > Upload utilities") for details.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a developer can re-use the implementation.
    0c.TestingCore functions will be covered by unit tests as far as reasonably applicable to ensure functionality and robustness. In the documentation, we will describe how to run these tests.
    0d.CodeWe will provide the whole code in a public GitHub repository.
    1.Implementation of the IPFS upload extrinsicThe pallet implementation will be added, that takes bytes of a file as input parameters. Adjust the extrinsic method ipfs_add_bytes to trigger an event IpfsAdd(CID).
    2.Implementation to retrieve CID and store it on chainThe off-chain worker needs to be extended. Data (bytes) received will be added to the local IPFS node via the IPFS offchain worker. Once added, it stores the CID on chain.
    3.Implementation of a web3 clientFor testing and the use case of a tutorial, a web3 client with dedicated UI will be implemented. The client app can read the data from a file, call the implemented extrinsic and uploads the content in bytes to the Substrate node.
    4.Benchmark and adjustmentsTo check the maximum accepted file size, a benchmarking is performed. The result should give some concrete limits that will be added to the implemetation.

    Milestone 2 - Implementation of the redirect/fetch file featureโ€‹

    The goal of the second milestone is to implement the redirect/fetch utilities. A RPC request, based on a PRG mechanism, can be used to redirect to any file server, which is not limited to IPFS. If the file is not available thru a public IPFS gateway, the local node can be used to retrieve the file.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a developer can re-use the implementation.
    0c.TestingCore functions will be covered by unit tests as far as reasonably applicable to ensure functionality and robustness. In the documentation, we will describe how to run these tests.
    0d.CodeWe will provide the whole code in a public GitHub repository.
    0e.ArticleWe will write and publish a Medium article to spread the word and give developers an introduction to the project and how to use it.
    1.Fetch File ImplementationImplement the logic that allows clients to fetch a file from IPFS with the Substrate node. E.g. #[prg(name = "nft_getFileById")] will be designed and developed that allows users to redirect a request, which returns Result<String>, to a file server. The PRG mechanism is used to provide a RPC API that can redirect to a file server. The existing IPFS "get file" extrinsic will be obsolet as we provide this new RPC API.
    2.Web3 Client ExtensionThe web3 client will be extend to show the (PRG) redirect feature and retrieve corresponding files via a public IPFS gateway.
    3.Local Node Fetch ImplementationImplement a file fetch RPC API, that returns the file from the local embedded IPFS node instead of the public IPFS gateway. This is helpful when waiting for the file to be available on the public IPFS gateway.

    Additional Information โž•โ€‹

    This is our second application for an open-source project to innovate the web3 Ecosystem.

    - + \ No newline at end of file diff --git a/applications/iris.html b/applications/iris.html index 8e5339c5f47..820c3a3c7d0 100644 --- a/applications/iris.html +++ b/applications/iris.html @@ -4,7 +4,7 @@ Iris | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ The audience is very wide ranging.

  • What need(s) does your project meet?

    • There are several viable decentralized storage networks that already exist, with some being substrate-based chains. However, these all succumb to some of the issues outline in the introduction with DSNs (indexability, availability, security, governance), and they all have varying degrees of decentralization, from totally decentralized to barely.

    Within the substrate ecosystem, notable DSNs are:

    There are several decentralized storage options already available outside of the substrate world, all with varying degrees of decentralization. Some of these include:

    How IRIS differs from existing solutions:

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Tony Tony is a full-stack engineer with over 5 years of experience building enterprise applications for both FNMA and Capital One. Notably, he was the lead engineer of Capital One's "Bank Case Management" system, which is responsible for creating, managing, and automating customer needs initiated from Capital One cafes (such as modifying their name or changing their SSN/TIN). In addition, he holds a breadth of knowledge in many languages and has built several open-source projects, including a blockchain built from scrach in Go, an OpenCV-based augmented reality application for Android, as well as experiments in home automation.

    Team Code Reposโ€‹

    (Tony) Personal Links

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Guidelines/Assumptions:

    Milestone 1 โ€” The Iris Runtime (Foundations of the DSN)โ€‹

    Goal: The first milestone delivers a minimally functional, isolated version of Iris. Some of the functionality delivered as part of this milestone will be shortlived within Iris, as it will be moved into parachains in subsequent milestones. We deliver the functionality to add and retrieve data as part of this milestone. We intend to be able to provide end to end testing scenarios in which a node adds owned data, purchases access to owned data, and retrieves it. We also introduce the idea of the "ticket" to control access to data as well as functionality to verify tickets when processing requests to deliver data.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can setup an Iris node, join the private network, and provide storage capacity.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. We intend to deliver fully functional tests along with each deliverable (which warrants testing). We intend to achieve a minimum of 85% coverage on new code.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a weekly log explaining what was achieved as part of the grant, as well as any additional learnings that we deem important throughout development. https://medium.com/iris-blockchain
    0f.Update offchain::ipfs to latest substrate masterSync the iris fork of the offchain::ipfs runtime to the latest substrate master branch. (work is completed but needs review)
    1.Genesis State and the Private IPFS NetworkCreate a private IPFS network and encode initial bootstrap nodes in the iris genesis block. (estimated duration: 0.5 weeks)
    2.Substrate module: iris Runtime ModuleWe build the module used by nodes in Iris to ingest and eject data from the private IPFS network. The pallet's functionality includes: creating requests to add and retreive data, to create, purchase, and validate tickets, and to allow OCWs to process requests initiated by nodes (i.e. call IPFS and publish results on chain). The outcome is for nodes to be able to create owned data and to monetize access to that data via the ticket asset. (estimated duration: 2 weeks)
    3.Custom RPC EndpointWe implement the custom RPC endpoint to retreive data from OCWs as defined here. (estimated duration: 0.5 weeks)
    4.User InterfaceWe build a UI using react, polkadot.js, and js-ipfs to provide an easy way to test data ingestion and retrieval from the network and to form the basis for a potential use case and integration guide/example. This minimally functional UI will let users add data to the network, view and purchase tickets, as well as download data retrieved from the network. (estimated duration: 1.5 weeks)

    Milestone 2 - Iris as a Decentralized Pinning Serviceโ€‹

    Goal: The second milestone enables a decentralized and incentivized IPFS pinning service in Iris.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can setup an Iris node, join the private network, and provide storage capacity.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. We intend to deliver fully functional tests along with each deliverable (which warrants testing). We intend to achieve a minimum of 85% coverage on new code.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a medium article explaining what was achieved as part of the grant, as well as any additional learnings that we deem important throughout development. https://medium.com/iris-blockchain
    1.Substrate module: iris-session Runtime ModuleWe build a module to enable validators to approve new network validators and for network validators to process requests to the embedded IPFS swarm. We introduce a simple reward scheme to incentivize validators to store data. The outcome of this deliverable is a fully decentralized storage network achieved by through a decentralized IPFS pinning service (estimated duration: 3 weeks)
    2.User InterfaceWe will iterate on the previous user interface to create two separate functionalities in the UI. Firstly, a "data-owner/consumer" facing page which let nodes view the availability of specific assets (number of online nodes pinning some CID), to request storage of data and to pay nodes for storage. The "data-owner/consumer" view swallows the of the functionality built in milestone 1 as well. Secondly, we build a "storage-provider" facing user interface, which displays to nodes running the embedded ipfs node their DHT stats and their rewards for pinning CIDS. (estimated duration: 1.5 weeks)

    Milestone 3 - Creating an smart contract that uses Irisโ€‹

    Goal: The third milestone delivers a decentralized application that uses Iris as a storage layer. We will deliver a smart contract (on Iris) that acts as a simple data marketplace where owners can buy and sell access to data. We also build a user interface to accompany the smart contract.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can create and run the iris-compatible smart contract as well as document the process through which interactions with Iris are made and verified.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. We intend to deliver fully functional tests along with each deliverable (which warrants testing). We intend to achieve a minimum of 85% coverage on new code.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a medium article explaining what was achieved as part of the grant, as well as any additional learnings that we deem important throughout development. https://medium.com/iris-blockchain
    1.Substrate module: iris Runtime ModuleWe add the ability to burn tokens and destroy asset classes. We also test and document edge cases and known issues. (estimated duration: 1.5 weeks)
    2.Custom RPC endpointWe enhance security to make this only callable by authorized nodes. (estimated duration: 0.5 weeks)
    3.Iris Runtime: Contracts PalletWe add the contracts pallet to the iris runtime and develop a simple smart contract to allow data owners to sell access to data consumers. (estimated duration: 2 weeks)
    5.User InterfaceWe build a user interface for use by the smart contract

    Future Plansโ€‹

    In the short term:

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? I learned about the grants program through the substrate website, as well as was encouraged to submit a proposal during discussions with Parity on the Substrate Builder's Program.

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    - + \ No newline at end of file diff --git a/applications/iris_followup.html b/applications/iris_followup.html index d36cf91750c..d8b0b6003b1 100644 --- a/applications/iris_followup.html +++ b/applications/iris_followup.html @@ -4,14 +4,14 @@ Iris | Web3 Foundation Grants - +
    Skip to main content

    Iris

    • Team Name: Ideal Labs
    • Payment Address: 0xB7E92CCDE85B8Cee89a8bEA2Fd5e5EE417d985Ad (DAI)
    • Level: 3
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    This is a follow-up grant to Iris:

    Overviewโ€‹

    Iris is a decentralized data exchange protocol that enables a secure data ownership, access management, and delivery layer for Web 3.0 applications. It is infrastructure for the decentralized web. By building a cryptographically verifiable relationship between storage and ownership, Iris provides a data exchange which enables the transfer and monetization of access to and ownership of data across chains, smart contracts and participants in the network or connected through a relay chain. Iris provides security, reputation, and governance on top of storage, enabling data ownership, monetization, access management, capabilities to define unqiue business logic for data access and authorization, as well as smart contract support for content delivery. It applies defi concepts to data to represent off-chain assets in an on-chain context by representing data as a unique asset class with access to the underlying data controlled by ownership of assets minted from the asset class.

    Project Detailsโ€‹

    The intention of this follow-up grant is to implement several features that enable Iris to be a secure data exchange protocol with support for multiple storage backends, capabilties for the development of unique data access and authorization models, and that lays the foundation for future governance and moderation capabilities. In our system, data owners associate their data with any number of 'data spaces' that each have specific rule sets and inclusion policies. We also lay the foundations for our encryption scheme (we will use a threshold encryption mechanism, though the implementation of this is out of scope for this proposal) by introducing the concept of the proxy node that are the linchpin for threshold encryption, as well as allows data owners and data consumers to run light clients (as they no longer are required to run the full node and add data to the embedded IPFS node). Additionally we introduce "composable access rules" and an associated "rule executor", allowing data owners to define unique business logic that enables custom access and authorization models to their data. Further, we build a generic storage connector module which allows Iris the abilitiy to support multiple downstream 'cold' storage systems (such as using XCM to communicate with the Crust network) as well as 'hot' storage via IPFS, supported by proxy nodes, that facilitates the transfer of data between them in an offchain context. Lastly, we will build a javascript SDK to allow user interfaces for dapps built on Iris to easily build applications and interface with Iris.

    This proposal makes several improvements on top of the existing Iris blockchain, specifically in terms of security, extensibility, data organiziation, and data ingestion/ejection workflows.

    To summarize, in the following we propose:

    • the introduction of "data spaces"
    • the implementation of "composable access rules" to apply custom business logic to data
    • the introduction of "proxy nodes" that enable threshold encryption within the network
    • implementation of an offchain client to send/receive data to/from proxy nodes
    • introduce a configurable storage layer to support storage in multiple backends as well as usage of go-ipfs for hot storage
    • a javascript SDK to allow dapp developers to easily build front ends for smart contracts on Iris

    For further details, we direct the reader to view our whitepaper draft here: https://www.idealabs.network/docs

    Note: The whitepaper is outdated, specifically in sections where references to the storage system are made.

    Tech Stackโ€‹

    Frameworks/Libraries:

    • go-ipfs
    • Substrate
    • Crust Network

    Languages:

    • Rust
    • Go
    • Javascript/Typescript

    Terminologyโ€‹

    • Data Asset Class and Data Asset: A data asset class is an asset class which is associated with some owned data which has been ingested into the Iris storage system at some point in the past. A data asset is an asset minted from the data asset class.

    • Data Owner: A data owner is any node that has initiated the ingestion of some data and owns a data asset class. In the following, we may refer to data owners as "Alice".

    • Data Consumer: A data consumer is any node that owns a data asset minted from a data asset class. In the following, we may refer to data consumers as "Bob".

    • Proxy Node: A proxy node is any node that has the minimum required hardware requirements and has staked the minimum required amount IRIS tokens to become a proxy node.

    Data Spacesโ€‹

    A data space is a user-defined configuration and rule set that allows users to group data together into curated collections. More explicitly, the data space lays the foundation to enable user-defined moderation rules within the network and provides a means to securely associate disparate data sets with one another (i.e. under an โ€˜organizationโ€™). All data in Iris exists within the context of a space, however, there is no limit to the number of spaces a data owner may associate their data with.

    Under the hood, the 'data space' is an asset class which is mapped to a set of configuration items that determine the inclusion and moderation policies of the space. These asset classes exist much the same as the concept of 'data assets' from the original Iris proposal. In a data space with a private inclusion policy, only nodes holding tokens minted from the data space asset class are authorized to associate data with the data space. We see this as an additional market opportunity for the data economy, as ownership of a space may become important based on the sum of data stored within. Data spaces may also be subject to composable access rules at some point in the future.

    Further, data spaces form the basis for moderation, or curation, within the network. Each data space may have a set of rules associated with it which limits not only the type of data that can be associated with the space, but also with the contents of the data. We intend to accomplish this through the execution of machine learning models, bayesian filters, and more, within a trusted execution environment. However, that work is outside the scope of this proposal.

    data spaces diagram

    Composable Access Rules and Data Access Authentication via a Rule Executorโ€‹

    Iris enables data owners to determine rules that consumers must follow when requesting their data from the network which, when met, should authorize the caller to access the data associated with the asset class. These rules could include: limited use access tokens, minimum token requirements, time sensitive tokens, and many other use cases.

    We accomplish this through a set of smart contracts called composable access rules (CARs) and an associated 'rule executor' contract. The rule contracts are composable in the sense that the data owner may specify any number of rules, each of which must be validated when a consumer requests data. In general, each rule stipulates a condition which, when met, results in the consumer being blocked from accessing data. For example, a "limited use token contract" would track the number of times a token is used to fetch data, and forces that token to be burned once the threshold is reached. If at end of execution of each CAR no false result has been returned, then the consumer can proceed to fetch the data. In general, the greater the number of CARs, the more costly it will be for consumers to access the data, since they must pay for each one to be executed.

    In order to associate CARs with an asset class, each CAR must be executed as part of a 'rule executor' contract which makes cross-contract calls to each rule specified. After execution of each rule, the executor submits the results on chain. In general, we assume that the result submission is a boolean value, where true implies each rule evaluated to true and data access is authorized, and false implies some rule failed and data is not accessible. When an executor contract's address is associated with the on-chain asset class, Iris uses a mechanism to 'unlock' the data for the authorized address for a limited period of time (until it is fetched for the first time). To this end, we introduce a new pallet, iris-ejection, which handles the management of this locking mechanism, submission of rule executor results, and association of rule executor contract addresses to asset classes.

    A composable access rule must implement the following functions, which is enforced via a trait:

    • an execute(asset_id, consumer_address) function that produces a boolean output. This function accepts the asset id of an asset class in Iris and a consumer address. It encapsulates the โ€˜access ruleโ€™ logic.

    Proxy Nodes and offchain clients for data ingestion/ejectionโ€‹

    Proxy nodes form the basis of secure data ingestion and ejection from the network. Ultimately, these nodes will be responsible for powering Iris's threshold encryption mechanism. This mechanism is out of the scope of the current proposal, however, we will create this node role to provide the foundation for subsequent work in which the threshold encryption scheme will be implemented, as well as make data ingestion/ejection workflows easier for data owners and consumers. In the implementation proposed here, these nodes simply act as ingress and egress points to/from the IPFS network. Though proxy nodes do not increase the security of the network at this point, they do remove the dependency on data consumers and data owner to run a full Iris node to enable data ingestion and ejection.

    Putting data spaces and proxy nodes together, we arrive at the following design:

    proxy nodes

    Offchain Clientโ€‹

    The inclusion of proxy nodes impacts data ingestion and ejection workflows. We will build a secure offchain client using Go in order to serve files for ingestion by proxy nodes and to listen for data sent by proxy nodes when requested from the network.

    In the initial design of Iris, data ingestion functioned by allowing a data owner, who is running a full iris node, to add some data to their embedded IPFS node to gossip with a validator node, who would then add the data to their own embedded IPFSS node, which is connected with other validator nodes. This poses several issues. Not only is it insecure, but also it forces data owners to always run a full node which limits the ease of use of the system. Similarly, data ejection functioned by allowing a data consumer to directly connect their embedded IPFS node to a validator node to retrieve data from the 'validator network', which introduced a similar set of issues that data owners would face. Proxy nodes allow us to circumvent both of these issues by acting as a gateway to the IPFS network. To accomplish data ingestion, nodes will run an offchain client, which acts as a file server that only authorized proxy nodes can call into.

    data ingestion

    For data ejection, data consumers run the offchain client which will listen for connections from proxy nodes, accept authorized connections, and provide data consumers the ability to fetch data without running a full node.

    data ejection

    Encryption/Decryptionโ€‹

    As part of this proposal, we will implement a semi-centralized approach to securing data. There are significant security issues with the design we are proposing that we are aware, specifically when any authority node chooses to act maliciously. As we are remaining a proof of authority network for the time being, we are choosing to forgo threshold encryption while we continue to build the infrastructure needed to support it.

    Our approach to encryption relies on a semi-static set of authority nodes. We propose a system where a data owner's offchain client encrypyts their data so it may be decrypted by some specific proxy node who has been selected to handle the ingestion of their data into the network. Once this is done, the chosen proxy node decrypts and re-encrypts the data so it can be decrypted by any current proxy node in the network. When data is requested from the network, a proxy node then fetches the data from the 'hot' storage system (discussed here), decrypts it, re-encrypts it for the caller, and delivers it to the offchain client. This encryption and decryption happens offchain, but not in a TEE, which we are aware poses increased security risks which we will remediate once we implement threshold encryption.

    Proxy Node Reward Structureโ€‹

    Each data ingestion and ejection transaction has an additional transaction fee which is then pooled together and distributed to proxy nodes at the end of a session based on their participation during the session. This will function similarly to how proof of stake consensus algorithms reward validator nodes when new blocks are accepted into the chain.

    Storage System Integrationโ€‹

    There are two storage layers in Iris, a 'hot' storage layer which is supported by the proxy nodes, and a 'cold' storage layer which exists offchain.

    hot-cold-storage

    We will build a generic pallet that allows for any given storage backend to be configured for use with Iris. The intention behind this is that it may allow the network to function agnostically of any one given storage solution. The pallet will expose two main extrinsics, a 'read' extrinsic and a 'write' extrinsic, which send commands to proxy nodes to either ingest data from a configured storage system into hot storage, or to store data available in hot storage into cold storage. This approach allows us to support multiple storage backends, as well as provides us the freedom to implement our own storage system in the future without impacting the user experience.

    Initally, we will demonstrate how this can be used to allow connections to an external storage backend by adapting the connector to an external, centralized data store (e.g. either a locally running file server or AWS S3), which may be useful in B2B/C solutions who want to maintain ownership of their own storage system.

    To realize a decentralized solution to storage, we will use the same approach to implement a pallet which acts as a connector to the Crust network via XCMP. Explicitly, we intend to use the xStorage pallet provided by the crust project, which allows for us to place storage orders on the Crust network. Crust IPFS nodes will then fetch data, as based on the given CID and Multiaddress, from an Iris proxy node. Further, we will integrate with the xTokens pallet to enable the usage of our native token (IRIS) to pay for storage fees. The interactions with Crust (and this would be the same for any given storage system) will be abstracted away from the user through the generic storage connector pallet, which exposes read/write functionality. We intend to follow the approach described here as well as open a dialogue with the Crust team in order to ensure all testing is sufficient and successful. We enable proxy nodes to ingest data from cold storage by reading from the IPFS gateway in which Crust has stored the data.

    In order to properly test and verify this, we will also setup our own relay chain with both Iris and Crust deployed as parachains.

    IRIS SDKโ€‹

    We intend to adapt the user interface developed as part of the initial Iris grant proposal for usage as an SDK for dapp developers on Iris. The SDK will facilitate development of user interfaces for contracts running on the Iris blockchain. As an example, the Iris Asset Exchange UI from the initial grant proposal is one such application. We will adapt the current Iris UI to use this new SDK as well as demonstrate how to develop a simple data marketplace.

    Specifically, we intend to adapt the SDK from the functions available in these files: https://github.com/ideal-lab5/ui/tree/master/src/services.

    Prior Workโ€‹

    This proposal is a followup to a completed web3 foundation grant which laid the foundation for these enhancements. With our initial proposal, we delivered:

    • a layer on substrate that builds a cryptographic relationship between on-chain asset ownership and actual off-chain data storage
    • a naรฏve validator-based storage system that encourages storage of 'valuable' data
    • support for contracts and a rudimentary decentralized exchange to purchase and sell data access rights

    In addition to these items, the Iris fork of substrate has been upgraded to by in sync with the latest substrate master branch and we have also upgraded the runtime to use the latest version of rust-ipfs (see here: d9e14294c89abd2c085e91d8312041245b5d3b35).

    Limitations and Expectationsโ€‹

    Iris is not intended to act as a decentralized replacement for traditional cloud storage or to be a competitor to existing data storage solutions. In fact, Iris is not really a storage layer at all. Further, this proposal does not address security (i.e. threshold encryption) in the network, nor does it appproach moderation capabilities, though it does lay the foundation for those items to be implemented in the next phase of development.

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem?

      • Iris intends to be infrastructure for dapps that leverage decentralized storage and ownership capabilities. Further, our long term intention is to participate in a parachain auction once Iris is feature complete, after which we will be able to provide cross-chain data ownership that is cryptographically linked with their stored data.

    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

      • The target audience is very wide ranging as we aim to provide infrastructure for dapps and potentially other parachains to allow them to easily take advantage of decentralized storage capabilities. We also aim to provide tools for data owners and content creators to share or sell their data without a middleman, determining their own prices and business models. Additionally, data spaces allow organizations to control which data can be associated with them, which may allow Iris to be a used in B2B or middleware within existing centralized applications.

    • What need(s) does your project meet?

      • The basis of Iris is the creation of a cryptographically verifiable relationship between data ownership, accessibility, and storage. We aim to treat data as an on-chain asset as well as provide a robust governance and moderation framework, which can assist in IP protections and safeguarding the network from being used for abusive or malicious purposes (such as hosting malware, illicit or illegal materials, plagiarized materials, etc.).

    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Tony Riemer: co-founder/engineer
    • Tom Richard: engineer
    • Sebastian Spitzer: co-founder
    • Brian Thamm: co-founder

    Contactโ€‹

    • Registered Address: TBD, in progress
    • Registered Legal Entity: Ideal Labs (TBD)

    Team's experienceโ€‹

    Ideal Labs is composed of a group of individuals coming from diverse backgrounds across tech, business, and marketing, who all share a collective goal of realizing a decentralized storage layer that can facilitate the emergence of dapps that take advantage of decentralized storage.

    Tony Riemer

    Tony is a full-stack engineer with over 6 years of experience building enterprise applications for fortune 500 companies, including both Fannie Mae and Capital One. Notably, he was the lead engineer of Capital One's "Bank Case Management" system, has lead several development teams to quickly and successfully bring products to market while adhering to the strictest code quality and testing practices, and has acted as a mentor to other developers. Additionally, he holds a breadth of knowledge in many languages and programming paradigms and has built several open-source projects, including a proof of work blockchain written in Go, an OpenCV-based augmented reality application for Android, as well as experiments in home automation and machine learning. More recently, he is the founder and lead engineer at Ideal Labs, where he single-handedly designed the Iris blockchain and implemented the prototype, which was funded via a web3 foundation grant. He is passionate about decentralized technology and strives to make the promises of decentralization a reality.

    Tom Richard

    A programming fanatic with six years of professional experience who always thrives to work on emerging technologies, especially in substrate and cosmos to create an impact in the web 3.0 revolution. I believe WASM is the future and has great leverage over EVM, and that is the reason why I started building the Polkadot ecosystem, currently developing smart contract applications and tools with Rust.

    Sebastian Spitzer

    Sebastian started his career in marketing, from where he ventured into innovation management and built up innovation units and startup ecosystems in 3 verticals.

    Essentially working as an intrapreneur in the automotive sector for the last 6 years, he managed the entire funnel from ideation to piloting and ultimately scaling digital solutions. In the last 3 years he scaled up 2 projects, adding 2m+ of annual turnover within the first 2 years to market.

    In 2016 he first came into contact with the Blockchain space when scouting new tech and got deeply immersed when he saw the disruptive potentials. Since then he has become an advisor for two projects, supporting them in their growth to 200m+ market caps, worked as a dealflow manager/analyst for a crypto VC and helped founders on their early stage journey in the space.

    In 2019 he authored a research paper on why the data economy in the automotive industry fails. Since then he was looking for an adequate solution and co-founded Ideal Labs 2 years later after discovering Tony's initial work.

    Brian Thamm

    Brian Thamm has over a decade of experience leading large data initiatives in both the Commercial and U.S. Federal Sectors.

    After several years working with companies ranging from the Fortune 500 to startups, Brian decided to focus on his passion for enabling individuals to use data to improve their decision-making by starting Sophinea. Since its founding in late 2018, Sophinea has lead multi-national Data Analytics Modernization efforts in support of the United Stateโ€™s Department of State and the National Institutes of Health.

    Brian believes that data-driven success is something that often requires top level support, but is only achieved when users of the information are significantly engaged and are able to seamlessly translate data into decision-making. This requires expertise, but often also novel datasets. Brian believes that blockchain ecosystems represent a generational opportunity to develop these novel data sets by providing a fairer incentive structure to reward data providers for their efforts and willingness to share.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    As stated earlier in the prior work section, we have delivered the three milestones detailed as part of the intiial Iris grant proposal. Additionally, we have also synced the Iris repository with the latest substrate master branch as well as have upgraded to use the latest rust-ipfs version (see here: d9e14294c89abd2c085e91d8312041245b5d3b35).

    Development Roadmap ๐Ÿ”ฉโ€‹

    Note: There are several items we aim to accomplish during the lifetime of this proposal that are not explicitly mentioned as part of the below milestones, including:

    • properly weighting and benchmarking extrinsics
    • developing automated gates for test coverage and code quality
    • developing a simple testnet and CICD pipeline to automatically update the node runtimes
    • updating our whitepaper with most recent results and findings
    • continuing research on threshold encryption and how we can most efficiently implement it, which will also allow Iris to transition from PoA consensus to PoS consensus.

    Overviewโ€‹

    • Total Estimated Duration: 9 months
    • Full-Time Equivalent (FTE): 2.5 FTE
    • Total Costs: 47,000

    Milestone 1 โ€” Implement Data Spaces and Composable Access Rulesโ€‹

    • Estimated duration: 1 month
    • FTE: 1.5
    • Costs: 10,000 USD

    This milestone delivers two distinct deliverables.

    1. We abandon the integration with rust-ipfs which was used as part of the original iris proposal. There are several reasons to do this, but the main reason is that rust-ipfs is still under development and is not yet feature complete, which severely limits its capabilities and security. Additionally, integration with rust-ipfs by embedding it within the substrate runtime significantly increases development and maintenance overhead while the benefits do not outweight usage of an external ipfs instance with go-ipfs and http bindings/communication via offchain workers. As such, this milestone will introduce breaking changes to the data ejection and ingestion workflows which are addressed in milestone 2. The results of this change implies that data ingestion and ejection are temporarily non-functional, though the underlying mechanisms are untouched. That is, this milestone introduces mechanisms to organize asset classes using dataspaces and authorization mechanisms for accessing offchain data associated with asset classes, without actually delivering the offchain data.

    2. We introduce data spaces, the ability to manage data spaces associated with data, and lay the groundwork for future moderation capabilities.

    3. We deliver composable access rules, the rule executor, and the iris-ejection pallet to the Iris network, allowing data owners to specify unique business models that consumers must adhere to across any number of data spaces. Specifically, we will implement a composable access rule and associated rule executor contract which allows a token to be 'redeemed' only a limited number of times (e.g. ownership of a token implies you can fetch associated data only N times from the network).

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. We will provide a demo video and a manual testing guide, including environment setup instructions.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a medium article explaining what was achieved as part of the grant, as well as any additional learnings that we deem important throughout development. https://medium.com/ideal-labs
    1.Separate Iris node from substrate runtime forkWe migrate the existing pallets used in iris to a new repository based on the substrate node template
    2.Substrate module: DataSpacesCreate a pallet, similar to iris-assets pallet, that acts as a wrapper around the assets pallet and allows nodes to construct new data spaces and mint data space access tokens.
    3.Substrate module: Iris-AssetsModify the iris-assets pallet to allow nodes to specify data spaces with which to associate their data. Additionally, we implement the logic required to verify that the data owner holds tokens to access the space.
    4.ContractsCreate the trait definition for a Composable Access Rule and develop a limited use rule, allowing a token associated with an asset id to be used only 'n' times. Additionally, we develop the RuleExecutor contract which aggregates rules and submits the results on chain.
    5.Substrate Module: Iris-EjectionWe develop a module to handle the association of rule exectors with asset classes, the submission of results from rule executors, and management of the data access locking mechanism.
    6.Substrate Module: Iris-SessionWe modify the data ejection workflow to verify data authorisation via the iris ejection pallet's "lock".
    7.User InterfaceWe update the iris-ui repository so as to keep calls to extrinsics in sync with changes to parameters.

    Milestone 2 - Proxy/Gateway Nodesโ€‹

    • Estimated Duration: 5.5 months
    • FTE: 2.5
    • Costs: 22,000 USD

    This milestone delivers the infrastructure to ingest data into the network and delegate decryption rights to authorized nodes.

    1. To securely ingest data, we implement two new RPC endpoints, 'iris_encrypt' that allows a node to encrypt data using proxy reencryption, and 'iris_decrypt' .
    2. We create two new node types, a 'proxy' node which enables the proxy reencryption mechanism and a 'gateway' node, which enables data ingestion and asset class creation.
    3. We reintegrate with IPFS by making http calls using the offchain client. We also build a module to bridge between IPFS and Iris.
    4. We modify the user interface to provide a simple way to start the ingestion process, view data about asset classes, and ultimately to decrypt and download data.
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. We will provide a demo video and a manual testing guide, including environment setup instructions.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a medium article explaining what was achieved as part of the grant, as well as any additional learnings that we deem important throughout development. https://medium.com/ideal-labs
    1.Substrate Module: Iris-ProxyImplement mechanism to allow nodes to act as a proxy and reencrypt data when requested.
    2.Substrate Pallet: IPFSBuild a pallet that enables mechanisms to issue commands to specific nodes so that their offchain worker can interact with IPFS. We do this by associating IPFS id and Iris id.
    3.Substrate Module: GatewayImplement mechanism to allow nodes to act as a proxy and reencrypt data when requested.
    4.Encryption MechanismWe implement a proxy reencryption mechanism as described above.
    5.RPC: Encryption RPCThe encryption RPC endpoint allows a node to send a signed message and plaintext. After verification of the signature, the plaintext is encrypted and ciphertext is returned.
    6.RPC: Decryption RPCThe decryption RPC allows a node to send a signed message and ciphertext. After verification of the signature, if the node has been delegated decryption rights (through the 'Rule Executor' from the previous milestone), then the plaintext is returned.
    7.Testnet SetupWe deploy a functional testnet to AWS that can be connected to from an iris node by specifying a custom chain specification.
    8.User InterfaceWe update the iris-ui repository so as to keep calls to extrinsics in sync with changes to parameters.

    Milestone 3 - Storage Systemโ€‹

    • Estimated Duration: 2 months
    • FTE: 1.5
    • Costs: 12,000 USD

    1. In this milestone we implement rewards and slashes for Gateway and Proxy nodes

    2. This milestone delivers a generic storage pallet that can be adapted/instantiated to communicate with any given storage system. Specifically, we will demonstrate by building two distinct implementations of this adapter, one which is capable of interacting with a centralized datastore and one which uses the Crust Network. These storage systems represent the 'cold' storage capabilities of Iris. We will also invesetigate several other 'cold' storage options, such as Arweave, Filecoin, and potentially CESS (which is currently under development and funded via the w3f grants program).

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. We will provide a demo video and a manual testing guide, including environment setup instructions.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a medium article explaining what was achieved as part of the grant, as well as any additional learnings that we deem important throughout development. https://medium.com/ideal-labs
    1.Substrate Module: GatewayWe build a mechanism for gateway nodes to require payments for processing ingestion requests based on the amount of data ingested.
    2.Substrate Module: IrisProxyWe build a mechanism for proxy nodes to require payments for
    3.Substrate Module: Generic Storage Service palletWe build a generic pallet with read and write capabilities which can be modified to support multiple storage systems.
    4.Substrate Module: Centralized Storage SystemWe build a storage system connector based on (2) which can read and write data to a centralized storage system (i.e. an AWS S3 or equivalent local file server).
    5.Substrate Module: Integration with Crust via the xStorage and xTokens palletsWe use the pallet developed during part 2 to use XCMP to store data in the Crust network, based on the approach outlined here.
    6.Relay Chain and Light ClientWe deploy a relay chain with Iris and Crust as parachains and ensure that XCM messages are properly relayed between chains. We also build a chain specification that can be used via substrate connect to use a light client in the browser.
    7.Benchmarking, Devops and CICDWe develop pipelines needed in order to continuously update the testnet runtime when pull requests are deployed to the main branch of the github repository. We also add additional gates to this process, such as be

    Milestone 4 - iris.js Javascript SDKโ€‹

    • Estimated Duration: 1 month
    • FTE: 1.5
    • Costs: 3,000 USD

    1. This milestone delivers iris.js, a javascript SDK designed to facilitate interactions with iris and smart contracts deployed to the iris chain (i.e. with rule executor contracts). This SDK is built with the polkadot.js library and will be adapted from the functionality of the iris-ui developed in the previous grant proposal and modified as part of this current proposal.

    2. We catalog and demonstrate several novel use cases that Iris enables and host the dapps developed at https://apps.idealabs.network

    3. We intend to consult with UX professionals to ensure that work developed as part of this is consistent, aesthetically pleasing, and approachable to users.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. We will provide a demo video and a manual testing guide, including environment setup instructions.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a medium article explaining what was achieved as part of the grant, as well as any additional learnings that we deem important throughout development. https://medium.com/ideal-labs
    1.Javascript SDKWe will develop the javascript SDK to provide easy accessbility for front end developers to hook into dapps built on top of Iris as well as easily accomplish data ingestion, ejection, allocation/inclusion to data spaces, and more. We will document the full functionalities and specification of the SDK as part of this milestone.
    2.ExamplesWe develop several small applications using Iris to showcase potential capabilities, such as an NFT marketplace, online bookstore, or spotify-like application. If possible, we will also explore integration into an existing open source application.
    3.Hosting and connection the testnetWe host demo applications and capabilties using the idealabs.network domain by building a hub to access them. Further, we run these applications on our testnet which is deployed as part of milestone 3.

    Future Plansโ€‹

    There are several key features of Iris that are out of scope of this proposal that the team will implement after these milestones. These items are specifically:

    • The implementation of an anonymous repuation and feedback system
    • The implementation of moderation protocols within dataspaces
    • The implementation of machine learning algorithms, bayseian filters, and other checks to verify data integrity and compliance, both globally and within the context of data spaces.
    • The implementation of governance protocols, including governance as a result of moderator node actions (with the implication being that Iris becomes an opinionated network where data may be rejected and specific addresses blocked from participation in the network).

    Other non-development activities that we will pursue also include:

    • We will finalize the Iris whitepaper.
    • We will work with dapp developers to assist in develop of applications on Iris. We are already in communication with several projects that are interested in leveraging Iris as their storage system.
    • We will strive to become a parachain on Kusama and Polkadot
    • We will continue to expand the features available in Iris, such as partial ownership of assets, selling ownership of asset classes, and more

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We first heard about the grants program from the Web3 Foundation Website.

    Previous work on Iris is known the W3F grants team.

    - + \ No newline at end of file diff --git a/applications/ismp.html b/applications/ismp.html index 87723340b5b..512253512ee 100644 --- a/applications/ismp.html +++ b/applications/ismp.html @@ -4,13 +4,13 @@ Interoperable State Machine Protocol | Web3 Foundation Grants - +
    Skip to main content

    Interoperable State Machine Protocol

    • Team Name: Polytope Labs
    • Payment Address: 0x486cbad2d704bc76f8d0cdda6aa93c94d53297b9 (Ethereum DAI)
    • Level: 3

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    The Interoperable State Machine Protocol, or ISMP for short, is the product of our research into state proofs. We show that state-proof based interoperability is possible and more efficient as the messages no longer need to be routed through the relay chain and can be exchanged independent of it, while still maintaining the same level of trustlessness and security. This protocol allows not just for messaging but also state reads of other parachains in a trustless and secure manner.

    Unfortunately, Parachain-to-Parachain communication today relies on the relay chain for message routing. This is highly inefficient and relieving the relay chain of this burden will allow for better Parachain throughput and scalability. We believe ISMP is the end-game for parachain interoperability, with the relevant ISMP modules, each parachain can send and receive messages and assets to and from other parachains which also have the ISMP modules. Seconded by Rob Habermeier on twitter.

    Project Detailsโ€‹

    ISMP is a simple protocol for state machines to send requests that can be handled by a counterparty chain. Akin to the HTTP paradigm in web2, parachains can issue GET-like requests for storage reads as well as POST-like requests for sending data.

    Requests are stored in a merkle mountain range tree on the sending chain as this data structure provides some benefits, binary merkle trees have more compact proof sizes than patricia merkle tries, and in particular, merkle mountain range trees have much smaller proof sizes for recently inserted items in the tree. We believe this choice will enable higher bandwidth parachain <> parachain messaging with smaller proof sizes.

    ISMP will also support request timeouts, allowing for more safer parachain <> parachain messaging.

    Architecture

    Use casesโ€‹

    For instance a user wanting to transfer their funds from parachain A to parachain B will initiate a post request on parachain A. This post request is stored in an mmr maintained in the state trie on parachain A. Parachain A's headers also contain the root for this mmr structure.

    The user('s wallet) after observing that parachain A's headers have been finalized and made it's way into the relay chain state trie, can present a merkle proof of parachain A's header in the relay chain state trie which parachain B can verify using it's access to the latest relay chain state root. Next they present the mmr proof for the request which they had previously initiated on parachain A. After verifying this mmr proof, parachain B can "execute" the request. In this case minting the equivalent asset that was burnt on parachain A.

    There are of course other use cases that can be built on POST requests, but this is the simplest case.

    For GET requests, a different mechanism is at play. Perhaps a user wants to settle a bet they had made in a prediction market in parachain A. The data that is needed to settle this bet is on parachain B where we regard parachain B as the oracle parachain. The user initiates a GET request, with it's content the keys of the storage items they need to settle their bet. After initiating the request, the request is stored in the parachain A's mmr trie, but it is never relayed anywhere. Instead, the user('s wallet) then reads the state trie of parachain B and provides the state proof for the appropriate data that was requested.

    pallet-ismpโ€‹

    This serves as the foundational element for state-proof based messaging between parachains, enabling state reads of the relay chain directly from any given parachain, granting the ability to verify incoming messages and data from other parachains under the shared security umbrella of the relay chain.

    Custom crates

    • ismp-rs - A set of primitives necessary for pallet-ismp
      • ISMPHost: Represents a state machine's core functionality
      • ISMPRouter: Embodies the request and response routing logic for parachain interactions
      • ConsensusClient: Logic for consensus proof verification

    This module can also serve as an alternative transport layer for XCM programs.

    Ecosystem Fitโ€‹

    Currently messages are sent over the Relay Chain through opening HRMP channels but through ISMP we can increase the bandwidth of messaging between parachains without burdening the relay chain with these messages. This allows the relay chain to focus on its main task: enforcing the validity of parachain state transitions.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Leads: Seun Lanlege, David Salami
    • Members: Damilare Akinlose, Femi Bankole, Jesse Chejieh

    Contactโ€‹

    • Registered Address: Harneys Fiduciary (Cayman) Limited, 4th Floor, Harbour Place, 103 South Church Street, Cayman Islands
    • Registered Legal Entity: Polytope Labs Ltd.

    Team's experienceโ€‹

    Polytope Labs is a collective of core blockchain engineers, researchers & scientists from varying blockchain protocol backgrounds passionate about the proliferation of networks over platforms and enabling this future through blockchain research, education, tooling and core infrastructure development.

    1. Seun Lanlege - Founder, Mad Scientist at Polytope Labs and Polkadot Fellowship Member. Previously core developer at Parity Tech, Worked on Ethereum and Polkadot with over 4 years of industry experience.

    2. David Salami - Scientist at Polytope Labs and Polkadot Fellowship Member. Previously Senior Blockchain Engineer at Composable Finance and Webb.

    3. Damilare Akinlose - Lab Intern at Polytope Labs and Polkadot Fellowship Member. Previously Blockchain Engineer at Webb

    4. Femi Bankole - Blockchain engineer at Matchx_iot + MXC Foundation and Lab Intern at Polytope Labs.

    5. Jesse Chejieh - Polkadot Fellowship Member.

    Research Publicationsโ€‹

    Team Code Reposโ€‹

    Team GitHub Profilesโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    State-proof based parachain messaging has been discussed on the Polkadot Forum.

    And some Updates to cumulus, required for parachains to read the relay chain state has been approved

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4.5 Months
    • Full-Time Equivalent (FTE): 3
    • Total Costs: 75,000 USD

    Milestone 1 โ€” ismp-rsโ€‹

    • Estimated duration: 1.5 months
    • FTE: 3
    • Costs: 30,000 USD

    In this milestone we develop the core primitives needed for pallet-ismp

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a README stating objectives of this ISMP primitive on the project repository.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test functionalities delivered with this milestone.
    0e.ArticleWe will publish an article that explains what was achieved as part of the grant.
    0f.ISMP SpecificationWe will put together a technical specification detailing the ISMP protocol.
    1.ismp-rsRust implementation of ISMP primitives for handling incoming messages to and from connected parachains.
    1a.ISMPHostState machine host functionality required to support ISMP.
    1b.ISMPRouterSub-component for routing incoming requests & response to the destination ISMP modules.
    1c.ISMPModuleInterface modules/pallets must conform to in order to receive incoming ISMP requests/responses.
    1d.ConsensusClientLogic for consensus proof verification, In the case of parachains, we will leverage the relay chain as a ConsensusClient through the new host functions in cumulus.
    Request/Response proof verificationSub-component for verifying membership of proofs of a request/response in a merkle mountain range tree.
    Request Timeout verificationVerifying non-membership of a request in the state trie of a parachain.
    1e.HandlersLogic for handling varying types of incoming messages.
    CreateConsensusClientFunctionality for creating a consensus client on the receiving state machine.
    ConsensusMessageFunctionality for handling consensus update messages from other state machines.
    RequestMessageFunctionality for handling request messages from other state machines.
    ResponseMessageFunctionality for handling response messages from other state machines.
    TimeoutMessageFunctionality for handling request timeout messages from other state machines.

    Milestone 2 โ€” pallet-ismpโ€‹

    • Estimated duration: 3 months
    • FTE: 3
    • Costs: 45,000 USD

    In this milestone we develop pallet-ismp

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a README stating objectives of this ISMP primitive on the project repository.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test functionalities delivered with this milestone.
    1.pallet-ismpBuilding the substrate pallet with above stated dependencies.
    1b.HostISMPHost implementation for the pallet.
    1c.RouterISMPRouter implementation for the pallet.
    1c.ParachainConsensusClientConsensusClient implementation for the pallet-ismp, utilizing the relay chain as consensus client for parachains.
    1d.RPCThis sub-crate will allow for users to query relevant ISMP data over RPC.
    1e.Runtime-APIsThis sub-crate will expose relevant ISMP data from the runtime through runtime APIS.
    1f.BenchmarksWe will benchmark pallet-ismp, providing a benchmark crate for parachain teams to run so as to generate the proper weights for their runtime.

    Future Plansโ€‹

    We recognize the significant benefits that pallet-ismp offers to the ecosystem, and therefore, after the grant completion we plan to continue providing maintenance with support from the Polkadot/Kusama treasury.

    Additional Information โž•โ€‹

    Solidity Trie Verifier

    - + \ No newline at end of file diff --git a/applications/java-client.html b/applications/java-client.html index c6bf61aaa64..125c6fa486a 100644 --- a/applications/java-client.html +++ b/applications/java-client.html @@ -4,7 +4,7 @@ polkadot-java-client | Web3 Foundation Grants - + @@ -20,7 +20,7 @@ But in addition, we want to leave a possibility to support older versions and/or Android.

    The library is going to be released under the Apache 2 license. Build artifacts are going to be published to a publicly accessible Maven repository, with Javadoc and documentation in the Github repo and/or on the company website.

    Team ๐Ÿ‘ฅโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Milestone 1โ€‹

    Initial domain specific model, types and encoding.

    NumberDeliverableSpecification
    1.SS58 encodingJava class to encode/decode with SS58
    2.SCALE codedJava class to encode/decode with SCALE
    3.Base typesJava classes to hold and operate Address, Hash, and DOT
    4.Unit TestsUnit tests covering at least 75% of the code
    5.DocumentationA standalone document, describing usage

    Milestone 2โ€‹

    Client for HTTP JSON RPC. With the focus on the following APIs: chain, contracts, and state.

    NumberDeliverableSpecification
    1.HTTP ClientA Java wrapper around standard HTTP JSON RPC, to read current state needed by a typical service
    2.Example AppAn example app that accesses a node and prints the current status of the blockchain to the console
    3.Unit TestsUnit tests covering at least 75% of the code
    4.DocumentationA standalone document, describing usage

    Milestone 3โ€‹

    Modules to read, create and broadcast extrinsic. Plus the API module which should provide access to the following APIs: account, author, and payment.

    NumberDeliverableSpecification
    1.schnorrkel/sr25519 moduleWrapper around Rust crypto library
    2.Signing and signature validation moduleJava classes to sign data or verify an existing signature
    3.Example AppAn example app to create and broadcast an extrinsic
    4.Unit TestsUnit tests covering at least 75% of the code
    5.DocumentationA standalone document, describing usage
    - + \ No newline at end of file diff --git a/applications/keysafe_network.html b/applications/keysafe_network.html index c9f1ea99572..3c3bb7d6caa 100644 --- a/applications/keysafe_network.html +++ b/applications/keysafe_network.html @@ -4,14 +4,14 @@ Keysafe Network | Web3 Foundation Grants - +
    Skip to main content

    Keysafe Network

    • Team Name: Keysafe
    • Payment Address: 0x09C08f46d523822cC9D18A077e2e3BDE5BC07a0b (Ethereum (USDC))
    • Level: 2
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    This grant is for the RFP Social Recovery Wallet

    Overviewโ€‹

    Backgroundโ€‹

    As the RFP mentioned: "managing private keys is a difficult task." A secure, simple and user-friendly private key management solution has not yet appeared in the Web3 world. Most typical Web3 users do not have the ability to properly safeguard and manage private keys to their crypto assets and Web3 identities. Based on a latest research by ChainAnalysis, the number of lost bitcoins due to account loss has reached 3.79 million($150 billion).

    We are thus inspired and encouraged by this initiatives and create Keysafe, a decentralized key custody network together with its underlying protocols, to offer a solution that aims to keep private keys safe and 'alive' in a user-friendly way for all Web3 users.

    Descriptionโ€‹

    Keysafe is a decentralized protocol for private key backup, retrieval, and access management. Keysafe allows users to register their keys with multiple authentications (SMS, email, etc.) and access their keys from anywhere in the world securely without carrying specific devices that store them.

    Our solutionโ€‹

    architecture

    Keysafe Protocol uses Secure Multi-party Computation (MPC), Threshold BLS Signatures, and Trusted Execution Environment (TEE) technology to manage private keys and allows owners to access with a customized combination of Web2 third-party authentication services including SMS, email, Google Auth, and even another Web3 address.

    When a private key is registered in Keysafe Network, the key will be divided into multiple fragments by a threshold secret sharing scheme on user's local device and then sent to randomly appointed TEE nodes in encrypted forms. Each fragment is bound to an authentication condition set by the user, i.e. SMS, email, Google authentication, etc. The private key fragments and the corresponding authentication info will be safely stored in Keysafe's decentralized network of TEE nodes - even the TEE enclave are not allowed to read the data.

    When a user wants to access his or her registered private keys from Keysafe Network, the TEE nodes who are in charge of each fragment will initiate an authentication task, i.e. sending a verification SMS or email, according to the authentication info bound to the fragment. After passing the authentication process, the user is allowed to access his or her private keys, which can be a key retrieval, a remote Sig generation, a remote Tx generation, or a modification on the registered data.

    Project Detailsโ€‹

    Documentationsโ€‹

    • Project overview PPT here
    • Technical whitepaper here
    • API specifications here

    POCโ€‹

    We have completed a proof-of-concept to verify the feasibility of our solutions here.

    Technology Stackโ€‹

    • The TEE (Trusted Execution Environment) technology: TEE guarantees secrets to be protected with respect to confidentiality and integrity from a hardware level.
    • Secret Sharing algorithm: Based on the M-of-N Threshold Secret Sharing algorithm, privates key can be divided into N shares, and can be later restored as long as M shares are obtained.
    • BLS-MPC: Based on MPC and BLS algorithms, users can manage nodes to complete threshold signatures with their stored private key fragments.
    • The Node: Keysafe Network is made up of many distributed Nodes with TEE inside. Private key fragments are stored safely in the node's TEE enclave.
    • Web2 + Web3 authentications: The user can authenticate through Web2 or/and Web3 methods (including SMS, emails, social media accounts and Web3 accounts) to access his or her registered private keys.

    Scopeโ€‹

    There are a lot of tasks involved to get all of these into a product-ready state which is what we are always aiming for, but it'd be too extensive to fit all of the tasks into this one single open grant. Therefore, we have carved out a scope specifically for this grant, followed by the details of the future tasks.

    Grant scope

    • Develop TEE module(written in C++) that supports basic private key transfer and management functions.
    • Develop off-chain node program(written in Rust) that coordinating with TEE module.
    • Develop on-chain protocol (written in ink! smart contract) that organizes all TEE nodes into a functioning network.
    • Develop a key management tool with Web-UI (written in JS) that supports Ethereum and Polkadot accounts.
    • Implement a hybrid authentication mode that includes mailbox, password, Google 2FA, and Polkadot account.
    • Contribute SDKs for polkadot-js or polkadot-apps, so that polkadot users can use Keysafe Network to backup, recover and manage their substrate-based keys.

    Future development

    • Implement more functions in TEE, such as MPC signature and access delegation.
    • Accept nodes endorsed by more organizations.
    • Support more authentication methods such as google sign-in
    • Develop more Adapter SDKs, compatible with all users of the Substrate ecosystem.

    Ecosystem Fitโ€‹

    • Generally, Keysafe Network provides decentralized and distributed private key custody with recovery and remote access compatibility with multi-factor auth for all potential web3 users.
    • By integrating Polkadot-JS and other libraries if needed, Keysafe Network provides key management for all kinds of accounts/address in the Substrate/Polkadot ecosystem.
    • Dapps and their users will greatly benefit from the decentralized key custody service from Keysafe Network:
      • No more worrying about losing private keys and corresponding crypto assets for their accounts;
      • They can now easily migrate their private keys to new devices without copying private keys or seedphrases in plaintext and risking themselves of accidentally exposing them to attackers.
      • They can remotely access their accounts and generate signatures/transactions with multi-factor social auths, from devices that don't have private keys stored locally.
    • Futhermore, as long as Keysafe Network integrates libraries/SDKs from other ecosystem/blockchains, our users enjoy one-stop cross-platform management for their keys, accounts as well as assets held by the accounts.
    • Keysafe Network can be easily integrated into all kinds of Dapps (i.e. wallets, De-Fi protocols, GameFi projects) so that they can offer their users with a 'Log in with Keysafe' option inside their user interface. Since Keysafe's login style is significantly more friendly to new web3 users who are expectedly much familier with social auth, both Dapps and Keysafe Network realize a win-win situation from these integrations.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Name of team leader: Dean Yan
    • Names of team members: Mingshi Song, Yan Jiang

    Contactโ€‹

    • No legal entity yet

    Team's experienceโ€‹

    • Dean is the author of technical whitepaper of Crust Network
    • Mingshi is the incubation program leader of Astar Network
    • We once won the third prize at Web3-hackathon with the idea of โ€‹โ€‹Keysafe

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We completed a prototype system to verify technical feasibility. The relevant RFP is here

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 8 months
    • Full-Time Equivalent (FTE): 3
    • Total Costs: $27,000 (payable in Ethereum-USDC)

    Milestone 1 โ€” Implement On-chain Modulesโ€‹

    • Estimated duration: 6 month
    • FTE: 3
    • Costs: 15,000USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can use Keysafe.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Core ProtocolImplements the nodeRegister userRegister userAuthentication and keyRecovery functions for Node program written in Rust.
    2.TEE ImplementationImplements the nodeRegister userRegister userAuthentication and keyRecovery functions for TEE part written in C++.
    3.Smart ContractImplements and test for the !ink smart contracts used for nodeRegister and userRegister.
    4.Web ServerProvide meta-data management service for Keysafe users written in Rust, users can manage keys and authentication methods
    5.Polkadot.jsAdd in encryption/decryption functionality to @polkadot/keyring and @polkadot/extension so that the protocol can run without the needs to read the private key of users.
    • Estimated duration: 2 month
    • FTE: 3
    • Costs: 12,000USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a project can integrate the Keysafe Protocol into their project.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.MPMC(Multi-Party-Multi-Cloud)Cooperation with multiple institutions, different institutions run Keysafe nodes on different cloud vendors. Decentralizing the Keysafe Network.
    2.Keysafe SDKDevelop the Keysafe SDK and the corresponding Adapters written in JS, so that the projects in Polkadot ecosystem can integrate Keysafe to provide users with a secured private key backup and recovery function.
    3.Support mainstream authentication methodsProvide multiple authentication methods for user key recovery, such as Ethereum wallet, Polkadot wallet, email and other authentication methods.

    Future Plansโ€‹

    • Implement more functions in TEE, such as MPC signature and access delegation
    • Accept nodes endorsed by more organizations
    • Support more authentication methods such as google sign-in
    • Develop more Adapter SDKs, compatible with all users of the Substrate ecosystem

    As a long-term business model, we have following plans to make Keysafe powerful and secure:

    • We will support more TEE implementations, such as Trusted Zone of ARM, SEV of AMD;
    • We will explore more possibilities as Keysafe Lego, including AML integrations, Web3 social graph, and decentralized access management;

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Announcement by another team

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    Dean's Crust Network and Mingshi's Astart Network are both projects of Web3 Grants.

    - + \ No newline at end of file diff --git a/applications/klevoya_fuzzer.html b/applications/klevoya_fuzzer.html index a5055f552fc..4c2a83415a4 100644 --- a/applications/klevoya_fuzzer.html +++ b/applications/klevoya_fuzzer.html @@ -4,13 +4,13 @@ Klevoya - Substrate WASM Smart Contract Fuzzer | Web3 Foundation Grants - +
    Skip to main content

    Klevoya - Substrate WASM Smart Contract Fuzzer

    • Team Name: Klevoya
    • Payment Address: DAI 0x31840be5bf48811ffa35512735de0a53b4ba230d
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Backgroundโ€‹

    The novelty and complexity of smart contracts, in addition to their role in managing potentially high-value digital assets, requires a high degree of attention to be paid to their security. Yet to date it is estimated that hundreds of millions of dollars have been lost to hackers who have exploited vulnerabilities in smart contracts.

    Currently blockchain developers mainly check their smart contracts using manually written tests and source inspection by internal and external audit teams. However security auditing is a highly specialised skill (and may even be more so for Substrate chains which are based on relatively new software technologies such as Rust and WebAssembly). Further, the growing complexity of smart contracts and their composable nature makes it difficult to scale manual methods.

    Klevoyaโ€™s mission is to build automated solutions that help blockchain developers find and eliminate bugs and zero-day vulnerabilities in their code before hackers can get to them.

    Our solution: The Substrate Contracts pallet will be used to execute smart contracts written by 3rd party developers, and these smart contracts may contain a variety of bugs. In this grant we will develop a WebAssembly smart contract byte-code fuzzer (i.e. dynamic execution of the smart contract in response to random inputs) for smart contracts that are to be deployed/executed in Substrateโ€™s Contracts pallet. We will not be fuzzing the Contracts pallet itself, only the smart contacts that are to be deployed on it.

    From experience with other blockchain ecosystems we have observed that the majority (if not all) of smart contract hacks that take place are a result of logic bugs. Therefore the main objective of this smart contract fuzzer will be to identify smart contract logic bugs. An ancilliary benefit will be to identify memory corruption errors in cases where developers use non-Rust programming languages (e.g. Ask! which is based on AssemblyScript) to write their smart contracts.

    This project builds on Klevoyaโ€™s previous work developing byte-code fuzzers for other WASM based smart contract chains.

    Benefits of fuzzers:

    1. In comparison to static analysis, fuzzers dynamically execute the code and therefore tend to give results that have fewer false positives/negatives than comparable static analysis techniques,
    2. Bugs found by a fuzzer are easily reproducible as the inputs needed to recreate a bug are a by-product of the fuzzing process,
    3. Fuzzing at the byte-code level means that we are agnostic to the smart contract programming language, whether that is ink! or some other future smart contract language, and,
    4. In comparison to formal verification techniques, it is relatively easier to set up a fuzzing campaign as it does not require training and expertise in formal methods.

    Project Detailsโ€‹

    Prior workโ€‹

    We have already developed a generic, coverage guided WASM binary smart contract fuzzer. The diagram below shows the general architecture of the smart contract fuzzer (the section in the red dotted line denotes the scope of work for this grant application):

    fuzzer_arch2

    The faster one can fuzz, then the more program paths that can be explored; therefore a key design feature of the fuzzer is its ability to execute many fuzz cases per seconds (we have benchmarked it executing several million fuzz cases/sec on a 16-core CPU with WASM binaries of a moderate size).

    There are two main ways we achieve this high fuzz case throughput:

    1. Efficient compilation of WASM bytecode to optimised machine code: WASM bytecode naturally doesnโ€™t run on the processor. Modern compilers can generate high quality optimised code, but can take a long time to compile. However the compilation result can be cached, and reused between execution instances which leads to an ideal position of โ€œcompile once - run manyโ€. To get optimised machine code we leverage existing tooling, namely Cranelift JIT to lift WASM bytecode to Cranelift IR, then transpile to C++ whilst adding instrumentation that allows gathering of coverage statistics. (This multi-stage process is necessary as existing WASM JIT compilers are fast to generate machine code, but the code they do generate is of poor quality - performance wise.) The transpiled C++ is then compiled to machine code with the Clang compiler.

    transpiler

    1. Parallel execution: the fuzzer runs several (typically one per CPU core) independent WASM Virtual Machine instances (the output of the compilation step detailed above) in parallel. Each VM instance has a local seed corpus, mutator and input generator (these parts are specific to a fuzz target and we will be developing a Polkadot specific one as part of this grant). The individual VMs then periodically sync their corpora to a corpus aggregator that allows the VMs to share corpus mutations.

    Scopeโ€‹

    In this grant we will only focus on fuzzing of WASM smart contracts.

    In the future we plan to expand the fuzzer to include fuzzing of custom (i.e. developed by third-party developers) Substrate Runtimes; we plan to seek a separate grant for that activity.

    In scope:

    • Implementation of a Substrate Smart contract model for integration with our generic WASM bytecode fuzzer. The model will be API compatible with the Contracts pallet with the underlying logic being mocked as much as possible (in order to reduce the maintenance of the model in response to future changes to the Contracts pallet)
    • Development of scheme to detect simple logic bugs
    • Finetune performance of fuzzing engine

    Out of scope:

    • No fuzzing of the Substrate Contracts pallet
    • No Substrate Runtime fuzzing
    • No fuzzing of non-WASM smart contracts (e.g. smart contracts that target the Substrate EVM Pallet)

    Ecosystem Fitโ€‹

    Making DApps built on Polkadot/Kusama robust to hacking is critical to ensuring the health of, and confidence in, the Polkadot/Kusama ecosystem. To date we have not seen any tools that have been specifically developed to assess the security of Substrate smart contracts.

    The results of this project will be used by smart contract developers to verify that their smart contracts are free of bugs and vulnerabilities prior to public deployment.

    Similar work in this or other ecosystems

    • A previous Web3 grant was awarded to a team to perform WASM Runtime Fuzzing. However in that grant they specifically sought to fuzz the wasmi/wasmtime to identify errors in those components, whereas in this grant we seek to fuzz smart contracts not the runtime.
    • The greatest amount of similar work has been done in the Ethereum ecosystem where several blockchain security related organisations have developed fuzzers for Ethereum smart contracts. For example the Echidna fuzzer (by TrailOfBits) and MythX (by Consensys) which is a security suite that includes a smart contract fuzzer. Those works are not applicable here as they fuzz smart contracts that run on the Ethereum Virtual Machine (EVM) whereas we specifically target fuzzing of WASM smart contracts running on Substrate's Contract pallet.

    In conclusion: we are not aware of any teams in the Polkadot/Kusama ecosystem that are currently pursuing a similar project.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Team Lead: Moti Tabulo
    • Fuzzer Developer: David Morgan
    • Blockchain Engineer: Christoph Michel

    Contactโ€‹

    • Registered Address: ideaspace City, 3 Laundress Lane, Cambridge CB2 1SD, UK
    • Registered Legal Entity: Barracuda Systems Ltd

    Team's experienceโ€‹

    The team is composed of members with many years of experience in general + blockchain software development, cybersecurity and blockchain security.

    • Moti Tabulo, PhD: Moti is the architect of Inspect, Klevoya's static vulnerability analysis engine. He has over 20 years' experience in technology R&D. Klevoya is his third startup after two previous startups in embedded software and robotics.
    • David Morgan: David is a performance and security conscious engineer with a keen eye for identifying vulnerabilities, and reverse engineering binaries. 4+ years experience finding hard to reach bugs. 10+ years finding, and exploiting vulnerabilities in gaming consoles.
    • Christoph Michel: Christoph has over a decade of experience in full-stack development. For the past several years he has been working on smart contract development for blockchain platforms like EOS and Ethereum. He has performed security audits on over a dozen smart contracts and regularly participates in CTF tournaments.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    As described in the project prior work section above, we are currently developing a generic WebAssembly bytecode fuzzer. The code is currently closed source (let us know in case you would like to arrange a private session to review it).

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 2 FTE, the listed members would contribute to different deliverables based on their skill-set.
    • Total Costs: 29,000 USD

    Milestone 1: Implementation of Substrate smart contract modelโ€‹

    • Estimated Duration: 2 months
    • FTE: 2
    • Costs: 19,000 USD
    • Goal: Implement model of Substrate Smart Contract pallet within fuzzer.
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a tutorial that explains how a user can use the fuzzer, and test their own smart contracts
    0c.Testing GuideThe code produced under this grant will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests.
    0d.Article/WorkshopWe will publish an article describing the work that was done during the grant and conduct a workshop describing how to fuzz a smart contract.
    1.Fuzzer VM: Model Substrate WASM Smart contract palletImplement model of blockchain logic: Substrate smart contract pallet calls, intrinsics, memory model etc within the fuzzer
    2.Fuzzer: Input generationGenerate smart contract calls with appropriate inputs
    3.Fuzzer: Seed mutationMutate seed corpus to allow efficient exploration of the smart contract with the aim of increasing code coverage

    Milestone 2: Substrate logic bugsโ€‹

    • Estimated Duration: 1.5 months
    • FTE: 1.5
    • Costs: 10,000 USD
    • Goal: Implement logic bug checks within the fuzzer, tune fuzzer performance. Integrate and test fuzzer with several Substrate projects.
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a tutorial that explains how a user can use the fuzzer, and test their own smart contracts
    0c.Testing GuideThe code produced under this grant will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests.
    0d.ArticleWe will publish an article describing the work that was done during this phase of the grant and describing how to find common smart contract logic bugs
    1.Prototype generic logic bugsPrototype and document logic bugs that are generic across Substrate WASM smart contracts
    2.Fuzzer: implement logic bugImplement logic bug checks within fuzzer
    3.Testing against ecosystem smart contractsConduct testing of the developed fuzzer against several in-development (and live where possible) Substrate WASM smart contracts from the Polkadot ecosystem to verify the performance of the fuzzer and its efficacy in identifying bugs. We will summarise the results

    Future Plansโ€‹

    Our vision is to provide a fuzzer that can identify security issues across the range of Substrate pallet functionality.

    Future development:

    • Extend the fuzzer to allow fuzzing of Substrate runtimes.
    • Implement fuzzer for EVM pallets
    • Integrate and fuzz Substrate runtimes that include either WASM or EVM smart contract pallets
    • Investigate feasibility of adding compiler engine as a backend to sp_sandbox to reduce maintenance overhead of fuzzer model

    Additional Information โž•โ€‹

    • Work you have already done:
      • Implemented generic WASM fuzzer and version targeting EOSIO smart contracts
    • Whether there are any other teams who have already contributed (financially) to the project.
      • No
    • Previous grants you may have applied for.
      • None in the Polkadot/Web3 ecosystem. We have previously received a grant from EOS.VC for the development of the Inspect static analyser
    - + \ No newline at end of file diff --git a/applications/kodadot_assethub_nft_indexer_statemine_statemint.html b/applications/kodadot_assethub_nft_indexer_statemine_statemint.html index 358cf85e5f1..8e151140bac 100644 --- a/applications/kodadot_assethub_nft_indexer_statemine_statemint.html +++ b/applications/kodadot_assethub_nft_indexer_statemine_statemint.html @@ -4,7 +4,7 @@ AssetHub NFT Indexer | Web3 Foundation Grants - + @@ -15,7 +15,7 @@ its commitment to bringing Statemine utilization & documentation closer to developers. Furthermore, the AssetHub Indexer is a completely decentralized, open-source solution that respects user privacy by not collecting user data.

    By reducing the time required to query assets and providing a more user-friendly interface, the AssetHub Indexer aims to foster the growth and development of the Web 3.0 ecosystem in Polkadot.

    Project Detailsโ€‹

    The AssetHub Indexer is a state-of-the-art infrastructure tool designed to address developers' challenges when querying NFTs from the chain. Currently, developers are limited to querying NFTs in batches from RPC nodes, which can be time-consuming and inefficient for customer-facing products. This limitation often results in long waiting times and heavy device data loads.

    To overcome these challenges, we have developed the AssetHub Indexer. This tool leverages the power of GraphQL to provide a more efficient and user-friendly interface for developers. With the AssetHub Indexer, developers can easily query NFTs and build on top of the new NFTs pallet by Parity, opening up a wide range of potential use cases, such as creating fandom shops for art.

    Recognizing that many web developers may not have extensive experience with GraphQL, we have also built a TypeScript-based SDK that can be easily imported into any existing project. This SDK simplifies interacting with Uniques and Assets on Statemine, making it more accessible for developers of all skill levels.

    The AssetHub Indexer uses TypeScript and leverages the Squid framework (ArrowSquid) for data processing. It interacts with a Postgres database and provides a GraphQL interface for querying data. The project structure includes directories for generated model/server definitions, server extensions, data type definitions, and mapping modules. It also uses environment variables defined in a .env file or supplied by a shell for configuration.

    Currently, the AssetHub Indexer allows developers to interact with Uniques and Assets on Statemine using GraphQL. The project is designed to be as simple as possible, ensuring all tasks can be done quickly and without extended searching. We aim to reduce the time necessary to query fungible and non-fungible assets on AssetHub, making it easier for developers to build innovative and user-friendly decentralized apps.

    Architecture ๐Ÿ—โ€‹

    The architecture of the AssetHub Indexer is designed with simplicity and efficiency in mind, ensuring a seamless interaction with Uniques and Assets on Statemine.

    At the core of our architecture is TypeScript, a statically typed superset of JavaScript that adds optional types to the language. TypeScript ensures robustness and reliability in our codebase, allowing us to catch errors early in the development process and write more maintainable code.

    To handle data processing, we leverage the ArrowSquid framework. ArrowSquid is a powerful tool allowing us to process and index blockchain data efficiently. It provides a set of utilities for defining and running data processing tasks, making handling complex data processing requirements easier.

    Our project interacts with a Postgres database, a powerful, open-source object-relational database system that uses and extends the SQL language. Postgres provides us with the robustness, scalability, and performance we need to handle large amounts of data.

    On the architectural level, we have a few layers, as described in the picture above. We need to obtain the data for the correct function of our indexer. AssetHub indexer combines the SubSquid archive (the pre-indexed storage) and RPC node for the new data. When the indexer obtains a new event, it is automatically processed by the defined handler. As previously mentioned, we processed data stored in the Postgres DB.

    To expose the data to clients, we provide a GraphQL interface. GraphQL is a query language for APIs and a runtime for executing those queries with our existing data. It allows clients to ask for exactly what they need and nothing more, making it easier to evolve and enabling powerful developer tools.

    The project structure is organized into several key directories. The 'src/generated' directory contains model/server definitions created by codegen. The 'src/server-extension' directory contains a module with custom type-graphql-based resolvers. The 'src/types' directory contains data type definitions for chain events and extrinsics created by typegen. The 'src/mappings' directory contains the mapping module. The 'lib' directory contains compiled js files, reflecting the structure of the 'src' directory.

    Finally, the project configures environment variables, defined in a .env file or supplied by a shell. This approach allows us to easily manage and change the configuration without altering the codebase.

    The second state-of-the-art is our Client-first SDK called Uniquery. As we can see in the picture below, the only thing that client applications need to do is import the Uniquery package via ESM/CJS (Javascript targets). Once we have the Uniquery package, we can access query builder implementation (such as client.getCollectionById(id)). Additionally, because many developers are familiar with REST API, we build a similar fetch strategy without needing a third party (every client fetches data directly from SubSquid). The REST looks like this: $fetch(/collectionById/${id}).

    Technology Stack ๐Ÿ’ปโ€‹

    Ecosystem Fitโ€‹

    The AssetHub Indexer is a crucial addition to the Polkadot and Substrate SDK ecosystem. It addresses the challenges developers often encounter when building on top of runtime pallets, particularly when interacting with Uniques, NFTs, and Assets on Statemine. The AssetHub Indexer provides a comprehensive NFT-oriented data solution, simplifying the development process and enhancing the efficiency of dApps within the ecosystem.

    Our solution stands out within the Polkadot and Substrate SDK ecosystem due to its user-friendly GraphQL interface and TypeScript-based SDK. These features streamline interaction with Uniques and Assets on Statemine, reducing the complexity of querying these assets.

    Moreover, the AssetHub Indexer is designed to be versatile, supporting a broad range of use cases. Developers can also leverage our sub-scaffold UI template to bootstrap their projects quickly. This template, a forkable Substrate dev stack focused on rapid product iterations, accelerates the development process and allows developers to focus on creating innovative and user-friendly dApps, rather than getting bogged down in the initial setup.

    Our target audience for this proposal includes Web3 projects and blockchain developers, whether they are just starting out or already established within the Polkadot and Substrate SDK ecosystem. We believe the AssetHub Indexer can provide significant value to these developers, enabling them to build more efficient and user-friendly dApps like KodaDot.

    AssetHub also plays significant for the KodaDot NFT marketplace, which is one of the main consumers for this indexer. Thanks to that, developers can find real-world examples of how to effectively make GraphQL queries and learn more about using Uniquery.

    Regarding competition within the Polkadot and Substrate SDK ecosystem, the AssetHub Indexer differentiates itself through its focus on NFT-oriented data solutions, user-friendly interface, and commitment to simplifying the development process. Including the sub-scaffold UI template further sets it apart, providing developers with a ready-to-use foundation for their projects. Moreover, the AssetHub Indexer is already being utilized by Subsocial and KodaDot, demonstrating its practical application and effectiveness. We plan to further promote the indexer within the ecosystem to onboard new developers and explore new solutions. These factors position the AssetHub Indexer as a unique and valuable tool within the Polkadot and Substrate SDK ecosystem, ultimately serving as a Common Good solution.

    Team ๐Ÿ‘ฅโ€‹

    Team members (In order of joining time)โ€‹

    Contact ๐Ÿ“žโ€‹

    Team's experienceโ€‹

    Matej Nemฤek is the Founder and CEO of KodaDot. He has been instrumental in the growth and development of KodaDot, leading the team to create the best end-user experience on the Asset hub. Matej's leadership and vision have been pivotal in transforming KodaDot into a collaborative hub where creators, developers, and community members work collectively for decision-making.

    Viktor Valaลกtรญn, also known as Viki Val, is the Co-founder of KodaDot. He is responsible for the technical aspects of the project. Viktor has been working on implementing MoonBeam and MoonRiver NFT EVM smart contracts and enabling read-only access to existing components for seamless end-user interaction. His technical expertise has been crucial in successfully launching the Basilisk NFT Marketplace pallet in the Fall of 2022.

    Matej and Viktor are strongly committed to the Polkadot ecosystem and have demonstrated their ability to deliver high-quality, impactful projects. They bring a wealth of knowledge and experience to the AssetHub Indexer project. Their work has earned KodaDot the number one rank as a decentralized dapp in the Polkadot ecosystem on Github. You can read more about their work and KodaDot's contributions to the Polkadot ecosystem on the Polkadot Wiki.

    Team Code Reposโ€‹

    Team GitHub accounts ๐Ÿง‘โ€๐Ÿ’ปโ€‹

    Team LinkedIn Profiles ๐Ÿง‘โ€๐ŸŽ“โ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 - AssetHub Indexer Implementation first partโ€‹

    SequenceDeliverableDescription
    0a.LicensingMIT License will be applicable.
    0b.DocumentationComprehensive inline code documentation and an explicit README file to guide the project setup and execution.
    0c.Test GuidelinesTesting will cover major functionality with unit tests and provide a guide for executing these tests.
    0d.Docker IntegrationA Dockerfile will enable the project to run within a Docker container.
    1a.Backward Compatibility MaintenanceEnsuring backward compatibility with current Uniques v1.
    1b.Collection Schema DevelopmentDevelopment of a GraphQL schema entity that represents the collection.
    1c.NFT Schema DevelopmentFormulation and creation of a GraphQL schema entity representing Non-fungible tokens.
    2.Unique v1.1 HandlersImplement a handlers to index buy, set_price events from the chain.
    3.NFT Pallet HandlersHandler created for indexing create, mint, buy, set_price, transfer, burn events from the chain.
    4a.On-chain Attributes Schema DesignDevelopment and design of a GraphQL schema entity representing on-chain attributes.
    4b.On-chain Attributes HandlersImplementing a four handlers to index the creation and deletion of metadata set for collection and NFT from the chain.
    5a.Metadata Schema DevelopmentCreating and designing a GraphQL schema entity representing metadata.
    5b.Metadata HandlersImplementing a four handlers to index the creation and deletion of an attribute for collection and NFT from the chain.
    5c.Metadata IPFS Integration HandlerDesign a handler to retrieve IPFS Metadata from the IPFS network.
    5d.Metadata IPFS Unification HandlerDesign and integrate the library to uniform IPFS metadata into one format (OpenSea,TZIP-16,ERC-5773, FXhash)
    6a.NFT Royalties Schema IntegrationDesign and include royalty support within the GraphQL schema.
    6b.NFT Royalties Addition HandlerImplement a handler to add royalty into NFT.
    6c.NFT Royalties PAYOUT HandlerCreation of handler to index royalty payout events from the chain.
    7a.Fungible Assets Schema CreationDesign and formulation of a GraphQL schema entity representing fungible assets.
    7b.Fungible Assets Force CreationHandlers will be developed to add system tokens like KSM/DOT into fungible assets.
    7c.Fungible Assets CREATE EventAn event handler for indexing the creation of a fungible event from a chain, such as (RMRK/USDT) will be developed.
    7d.Metadata Support for Fungible AssetsImplement a handler to add metadata to a fungible asset event from the chain.
    7e.Fungible Asset Allowlist SetupSetting up allows list-based indexing of fungible assets.
    8a.Data Views DevelopmentConstruction of data views for efficient access to indexed data.
    8b.Implementing Metadata Caching LayerDevelop and retry IPFS metadata if un-indexed by Metadata IPFS Integration Handler.
    9.Transfer of Collection OwnershipIncorporate functionality to transfer collection ownership.
    10a.Collection settings Schema DesignDevelopment and design of a GraphQL schema entity representing Collection settings
    10b.Collection settings handlerImplement a handler to add collection settings into data

    Future Plans ๐Ÿ”ญโ€‹

    Upon the successful deployment of the AssetHub Indexer, our team plans to continue refining and expanding its capabilities in response to user feedback and technological advancements. We have outlined several key enhancements and upgrades that we aim to implement:

    1. Development of an explorer to facilitate navigation within the NFT ecosystem.
    2. Introduction of collections functionality for systematic organization of NFTs.
    3. Creation of view modules to visually present NFT details.
    4. Establishment of user profiles to enable personalized user interfaces.
    5. Incorporation of constituent elements for individual NFT representation.
    6. Implement action components for functionalities like LIST, SEND, BUY, MINT, BURN, and Atomic Swap.
    7. Development of comprehensive statistical representations and analytics mechanisms.
    8. Introduction of rankings to highlight top-performing users, collections, or items.
    9. Personalization of the user interface to enhance the user experience.
    10. Maintenance of compatibility with runtime upgrades and changes in the Kusama/Statemine ecosystem.
    11. Regular updates to keep up with Substrate for continuous system enhancement.
    12. Management of upgrades to parachain runtime versions, including indexer enhancements and related costs.

    Additional Information โž•โ€‹

    The AssetHub Indexer project continues our team's various projects and implementations in the Polkadot ecosystem. We have already attracted interest from developers within the Polkadot and Kusama ecosystems. Notably, we have in 2019 previously received a grant from the W3F for creating Vue.js UI utilities, components, and libraries, details of which can be found here.

    This previous grant allowed us to reimplement keyring into Vue.js & TypeScript, demonstrating our hands-on experience with the polkadot.js.org/common utilities. The result of this work can be seen in the web-based Subkey tool.

    We learned about the Grants Program through a personal recommendation. We believe that our project aligns well with the program's goals, and we are excited about the potential to further contribute to the Polkadot ecosystem.

    - + \ No newline at end of file diff --git a/applications/konomi.html b/applications/konomi.html index a8d9668aa7c..cc624644de9 100644 --- a/applications/konomi.html +++ b/applications/konomi.html @@ -4,7 +4,7 @@ Konomi | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ It is currently a private repo, please contact us for access.

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 Pool Lending Moduleโ€‹

    NumberDeliverableSpecification
    0LicenseApache 2.0 / MIT / Unlicense
    1DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. There will also be a more detailed design documentation of the module reflects the delivered status
    2Substrate Module: Pool lending modulelending/borrowing pool of multi-assets with user deposit/debut tracking and interest calculation; liquidation functionality with sudo price oracle
    3Front EndComplete our own web page and provide front end UI for users to test the lending module. Using React and Javascript. Front end modules include: user account management (position tracking, interest, liquidation); lending/borrowing pools display; asset deposit and withdraw;
    4TestsUnit tests and also a public accessible testnet of the PoC
    5DockerA docker image of Substrate node with the lending module for anyone to easily run the node

    Community engagementโ€‹

    https://konomi-network.medium.com/ We have been documenting the project progress and also our understanding of the DOT ecosystem in our blog.

    Future Plansโ€‹

    After delivery, we will start to explore cross-chain lending senario and will first try to enable cross-chain asset to be lended and borrowed. Konomi aims to bridge the gap between crypto and fiat world by offering an easy to use, high performance product for users to trade and manage their crypto assets. In the mid term, we plan to implement cross-chain lending aggregation protocols since the current products could not execute orders across parachains simultaneously. We plan to deploy lending modules to partnered parachains in order to support cross-chain lending. In the long term, acquiring fiat-based customers and improve Polkadot cross-chain protocol to more compatible with cross-chain lending are the two strategic focus. In terms of fiat to crypto gateways, there have been many licensed service providers but it is yet to achieve mainstream adoption. With regulated players eying in this space, there will be more users and more demand for DeFi products. Furthermore, we believe that cross-chain infrastructure is going to be an important building block for crypto industry going forward since current solutions for BTC and other assets supported on Ethereum are either centralised or slow in speed.

    Additional Information โž•โ€‹

    Possible additional information to include: https://medium.com/konomi

    - + \ No newline at end of file diff --git a/applications/kylin_network.html b/applications/kylin_network.html index 609fbf71861..a466b09c85d 100644 --- a/applications/kylin_network.html +++ b/applications/kylin_network.html @@ -4,7 +4,7 @@ Kylin Network | Web3 Foundation Grants - + @@ -37,7 +37,7 @@ โ€ƒ- Seasoned development experience in Hyperledger, Ethereum and EOS.
    โ€ƒ- Expert in the architecture design of DeFi and token economics.
    โ€ƒ- Senior Software Developer and Data Scientist in Baidu.

    Team Code Reposโ€‹

    Team Linkedin Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Verify Production of Concepts (POC) and Implement Substrate Modulesโ€‹

    In this milestone, we will verify features with limited users and launch the testnet for the production of concepts. The implementation of off-chain workers of Substrate Framework will be built and validated.

    NumberDeliverableSpecification
    0a.LicenseApache License 2.0
    0b.DocumentationDocuments containing the description of whole architecture design for Kylin Network.
    0c.Testing GuideWe will provide a full test suite and guide for the POC.
    1.Kylin Network Oracle Node Module RepoOracle Node for data feeding built on top of Substrate 2.0 as a customized module written in Rust will store and process the data query request from data consumers, also it will handle the data feeding from miners. The very consensus protocol and the simplest schema of oracle market are implemented inside.
    2.Kylin Network Data Feeding/Miner RepoIt handles the query requests from oracle nodes, and feeds the data after processing as requested. It will be implemented with Substrate 2.0, and the major data feeding part will be built with off-chain workers. We will perform configuration and optimization work to make this easier for typical use cases of the Kylin Network.
    3.Kylin Network Datasource Sample RepoThe sample datasource provider provides the data (e.g. the data provider fetches the spot and contract data from derivative exchanges) to be used by miners. It will contain two parts, the Java data retriever to access APIs from exchanges and the NodeJS datasource to handle data feeding.
    4.Docker ImageThe Kylin Network docker image contains the POC version which can be running anywhere to verify the idea of Kylin Network.
    5.Kylin Contracts RepoThe smart contracts with Ink! to access oracle data and provide API for external calls.
    6.Kylin Market Front-end RepoThe Oracle Data Market front-end based on polkadot js to listing all available Oracle Data Services provided by providers through the Kylin Oracle Market.

    Community Engagementโ€‹

    Kylin's current community engagement strategies include:

    Kylin's future community engagement strategies include:

    Future Plansโ€‹

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/leetcoin.html b/applications/leetcoin.html index 7d351129e31..2beb99da32e 100644 --- a/applications/leetcoin.html +++ b/applications/leetcoin.html @@ -4,7 +4,7 @@ LeetCoin | Web3 Foundation Grants - + @@ -85,7 +85,7 @@ structure https://github.com/greenoakxyz/leetcoin-app. There is no prototype yet and we are currently developing it.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement Ink! Problem Builder, Solution and Compilerโ€‹

    This milestone will allow for the creation and use of Ink! coding problems.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide the documentation for the repository code as well as a tutorial for publishing/designing a user-generated coding problem and test suites.
    0c.Testing GuideBest practices for developing test suites to run code against and a FAQ.
    0d.ArticleAnnouncement blog post explaining how LeetCoin can be used for upgrading web3 developer skills, improve security and help with properly vetting dev core-team candidates to minimize technical risks.
    1.Design DocumentDescription of architecture and interface
    2.User AuthenticationCreate a wallet based authentication system for problem builders as well as users with Web3 Onboard
    3.Online JudgeOnline judge that compiles Ink! contract code and runs it against test suites comparing the actual output with the expected ones based on the different test cases
    4.Frontend problems listA simple table that displays all available problems on the platform
    5.Frontend code editorCode editor for the problems
    6.First Ink! Problem SetDevelop first 5 Ink! problems working with core teams of popular DeFi protocols
    7.DatabaseDatabase to store all problem datasets (Postgres)
    8.APICreate an API with express, express router, Postgres and CORS
    9.Frontend user profileUser profile page where they can edit their information and see their progress
    10.LoggingServer logging with morgan and winston

    Milestone 2 โ€” Educational Modules and Extensionโ€‹

    This milestone will extend the problem compiler and problem sets as well as introduce new functionality related to different learning paths and in-depth analysis of hugely popular smart contracts.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide the documentation for the repository code as well as a tutorial for publishing/designing a user-generated coding problem and test suites.
    0c.Testing GuideBest practices for developing problem sets, how to test them and a FAQ.
    0d.ArticleAnnouncement blog post explaining the new educational modules on the platform.
    1.Set CreatorImplement problem set curation and creation
    2.Problem FavouritingAllow users to favourite specific problems to easily reference later
    3.Expand Online JudgeAllow for problems written in Ink!, Rust and Go by extending compiler
    4.Diversify SetsDefine and add more problems.
    5.BadgesAward badges to specific users and educators that have hit specific achievements
    6.Page with educational resourcesList of awesome educational Ink! resources

    Milestone 3 โ€” Hiring Moduleโ€‹

    This milestone will introduce functionality to allow hiring core teams to generate links of predefined problems to share with prospective applicants as well as receive feedback on the applicantโ€™s performance.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide the documentation for the repository code as well as a tutorial for publishing/designing a user-generated coding problem and test suites.
    0c.Testing GuideBest practices for developing test suites to run code against and a FAQ.
    0d.ArticleAnnouncement blog post explaining LeetCoin's hiring tools to help vet the candidates.
    1.Employer Problem Sets
    • Allow employers to search through database of existing problems and add them to problem set
    • Implement problem set timer
    • Implement employer problem set one-time-use link generator
    • Allow employers to optionally specify ethereum address to solve problem
    • Allow employers to create custom problems to mix and match
    2.Applicant AuthenticationApplicants must connect with their Polkadot wallet in order to start and view timed employer problem set
    3.Mailing NotifierMailing system that notifies specified email upon completion of problem set with applicantโ€™s answers

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/liberland.html b/applications/liberland.html index 74e4943ba9c..903a9f1fb33 100644 --- a/applications/liberland.html +++ b/applications/liberland.html @@ -4,7 +4,7 @@ Liberland | Web3 Foundation Grants - + @@ -61,7 +61,7 @@ We will build tools to establish API connections with popular online marketplaces as an integral part of our project. We will ensure that users can apply objects to other objects and that, combining those objects, effects that somewhat resemble what one might expect in real life.

    A marketplace for virtualized real assetsโ€‹

    Answering the call of a widespread demand and seeing that there is no comparable solution currently available and functional/user friendly to the extent which we would find desirable, VR Liberland will feature a marketplace of real-world goods. We will represent real-world goods:

    Additional Informationโ€‹

    How did you hear about the Grants Program?โ€‹

    Our team is familiar with the Web3 Foundation and the works of Parity due to previous experience in substrates.

    Any other grants?โ€‹

    Liberland's blockchain project has not asked for any previous grants before. We plan to launch another grant application by Parity for the decentralized justice system of Liberland soon.

    - + \ No newline at end of file diff --git a/applications/lip_payments.html b/applications/lip_payments.html index dc9fe7ed2bd..575e309cc7b 100644 --- a/applications/lip_payments.html +++ b/applications/lip_payments.html @@ -4,7 +4,7 @@ Payments Pallet | Web3 Foundation Grants - + @@ -86,7 +86,7 @@ in Latin America, as an effort to create a decentralized on & off ramps platform but later developed independently with a brother scope and self-funded for the most part of 2021.

    - + \ No newline at end of file diff --git a/applications/logion_wallet.html b/applications/logion_wallet.html index 5941284f318..3d7b02098c5 100644 --- a/applications/logion_wallet.html +++ b/applications/logion_wallet.html @@ -4,7 +4,7 @@ logion wallet - a wallet you can trust | Web3 Foundation Grants - + @@ -62,7 +62,7 @@ implemented (off-chain and on-chain) and ready to be used.

    All relevant source code has been published in logion's GitHub organization.

    Logion's mission statement has been published in the form of a Medium article the 8th of July 2021.

    logion's Web site will be reviewed before the end of October 2021.

    We also communicate via twitter and LinkedIn. However, we are still quite discreet because our team is small and has limited financial resources.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Introductory noteโ€‹

    We chose to start the development from our own resources in order to properly set our strategy and to show concretely what we are doing and what our future contribution could be.

    Milestone 1 โ€” Implement account protection and recoveryโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDocumentation on how to run the wallet is available in the README of published repositories (see below) and formalized in this docker compose file: it describes a simple single-node local setup for testing purpose.
    0c.Testing GuideEach component comes with a set of unit and integration tests. However, this milestone is more about delivering a user experience. It is therefore advised to instantiate logion locally and use the Web application to execute the protection and recovery processes. This can be easily done using Docker Compose and logion test, a project enabling the easy deployment of logion for testing. The processes to execute are described in the README here and here. Logion test version 0.1 must be used. The Docker images to use have tag grant1-milestone1 (see here).
    0d.DockerWe provide Dockerfiles that can be used to test all the functionality delivered with this milestone.
    1.Logion nodeWe deliver logion's Substrate node version 0.1.0 including the recovery pallet in its runtime. The node is based on Substrate Node Template v3.0. The code (Rust) is hosted here. This file describes logion's runtime configuration.
    2.Off-chain serviceWe deliver the version 0.1.0 of companion off-chain service handling protection requests (the first step for a wallet user before being able to actually get the protection of legal officers) through a REST API implemented in Node.JS/TypeScript. The code of the off-chain service is available here. The controller implementing the REST resources for protection request handling is defined in this file. Unit tests are located in this file. Note that most resources require the caller to be authenticated. The authentication "protocol" is described here and implemented using resources defined in this file. Tests are here.
    3.Web applicationWe deliver logion's Web application (React/TypeScript) version 0.1.0 which enables the execution of the process described at point 0c. The code is available here.

    Milestone 2 โ€” Implement node directoryโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDocumentation will be included in the README of the published repository.
    0c.Testing GuideThe node directory service will come with a set of unit and integration tests. It will also be included in our logion test project (see Milestone 1). As a result, it will be possible to test the integration of the new component in a locally running logion infrastructure. From a user experience perspective, there should be no difference. However, when inspecting the requests issued by the app, it will be clear that the list of available legal officers is loaded from the node directory. The Docker images to use for testing will have tag grant1-milestone2.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a Medium article to communicate to the Polkadot/blockchain community that logion is developing its decentralized wallet secured by legal officers, having an insititutional social recovery functionality already implemented.
    1.Node directoryThe source code of the node directory, a Node.JS service written in TypeScript, will be published in a yet-to-create repository of Logion's GitHub organization. The goal is to have a service matching the specifications given in the Components section.
    2.Web applicationLogion's Web application (React/TypeScript) will use the list coming from the node directory instead of a hardcoded list currently.

    Milestone 3 โ€” Implement distributed backupโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDocumentation will be included in the README of off-chain service's repository.
    0c.Testing Guidelogion test project (see previous milestones) will include the deployment of IPFS services. It will also include a couple of scripts enabling the simulation of a node's failure and recovery. The Docker images to use for testing will have tag grant1-milestone3.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Distributed backupEncrypted backups of the database will be stored in the IPFS cluster as described above in the paragraph about fault tolerance in the Architecture section. Configuration (for PostgreSQL) and/or scripts (Bash) needed to actually enable this will be published in the off-chain service's repository. logion test will expose IPFS configuration (additional services in the Docker Compose file).

    Milestone 4 โ€” Multisig serviceโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDocumentation will be included in the README of the wallet repository and a use-case will be added to the README of logion test.
    0c.Testing Guidelogion test should be used to instantiate locally a logion infrastructure. The procedure to follow in order to test multisig is described in logion test's README. The Docker images to use for testing will have tag grant1-milestone4.
    0d.DockerWe will provide a Dockerfiles that can be used to test all the functionality delivered with this milestone.
    1.Web applicationThe multisig feature as part of our Web application (React/TypeScript). It will essentially consist in the possibility for a wallet user to request the creation of a multisig address with a legal officer. The signatures of the regular user and the legal officer will then be required to transfer tokens out of this account. Such transfers will always be created by the regular user and counter-signed by the legal officer.
    2.Off-chain serviceThe multisig feature in the form of REST resources and a model in logion's off-chain service (TypeScript).

    Future Plansโ€‹

    Beyond the improvements that could be brought to the service, the most important challenge could be to find a solution to provide our wallet to the whole DotSama ecosystem. For this, we need an access to the relay chain, at least, in the Kusama environment first.

    The wallet logion could then be used to secure all the digital assets of DotSama.

    It should also be available for nominators with the stacking function enabled.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Web3 Foundation Website / Medium / Announcement by another team / personal recommendation (all of these)

    - + \ No newline at end of file diff --git a/applications/lunie.html b/applications/lunie.html index 69fbef391b0..b38bb72151f 100644 --- a/applications/lunie.html +++ b/applications/lunie.html @@ -4,7 +4,7 @@ Lunie | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ We'd also like to include two guides for how governance in Kusama and Polkadot works.

  • An indication of why this project is good for the ecosystem.

    Participating in the staking economy can be complex and overwhelming. Governance engagement tends to be lower than the broader community would like. Lunie can help by providing a modern user experience and easy-to-use products that Kusama / Polkadot users will love. Our mobile apps, web wallet, and browser extension make it extremely simple to create and read proposals, deposit on proposals, vote on proposals, and understand the origin of the submissions. Having support for Kusama and Polkadot governance in Lunie will make them more accessible, understandable, and more delightful to engage with. Cosmos token holders and validators love Lunie โ€” and we think Polka-folks will too. ๐Ÿ˜‡

  • An indication of how you will integrate this project into Substrate / Polkadot.

    Lunie is an extensible staking and governance platform. The integration will involve working with our node partners, writing governance API mappers for the Lunie API, integrating Polkadot in our test suites, and building UI for governance related activities.

  • An indication of why your team is interested in creating this project.

    Polkadot is one of the most promising new blockchain platforms. We are passionate about providing world class experiences for staking communities around the world and are confident that a Lunie x Polkadot integation would be extremely well-received and impactful. We're excited to dive deep into Polkadot governance to help drive engagement and ease the overall experience.

    • Team ๐Ÿ‘ฅโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Milestone 1โ€‹

    Proposals in Lunieโ€‹

    NumberDeliverableSpecification
    1.Proposals are readable in Lunie see list of active proposals see when proposals are active and for how long see how the proposals are performing in terms of votes see potential proposals (in the queue

    Milestone 2โ€‹

    Governance Transactionsโ€‹

    NumberDeliverableSpecification
    2.Voting, Deposits, Time Locking provide ability to vote and deposit on proposals vote โ€œyesโ€ or โ€œnoโ€ on given proposals select how many DOTs a user wants to vote with provide ability to time-lock DOTs to increase the weight of the vote *

    Milestone 3โ€‹

    Notifications, Council, Treasuryโ€‹

    NumberDeliverableSpecification
    3.Notifications, Council, Treasury ability to recieve notifications for on-chain governance topics see active council members see treasury proposals

    Additional Information โž•โ€‹

    Any additional information that you think is relevant to this application that hasn't already been included.

    We have been working closely with Dieter and David on our previous milestones and have been asked to submit this application for governance to complete our Kusama / Polkadot integration.

    Possible additional information to include:

    We have completed account management and staking for Kusama. We have a rudimentary on-chain governance experience in place for Cosmos and Terra.

    - + \ No newline at end of file diff --git a/applications/maintenance/Substratesnap_Maintenance.html b/applications/maintenance/Substratesnap_Maintenance.html index 38168de2a0c..c8786bb47b1 100644 --- a/applications/maintenance/Substratesnap_Maintenance.html +++ b/applications/maintenance/Substratesnap_Maintenance.html @@ -4,7 +4,7 @@ SubstrateSnap Maintainance Grant Proposal | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ Registered Legal Entity: ChainSafe Systems Inc.

    Team's experienceโ€‹

    ChainSafe is a global leader in blockchain research and development and specializes in the designing and building of web3-related infrastructure. We believe that empowering developers with blockchain-agnostic tools is essential for the future of decentralized systems.

    The firm encompasses top engineering talent from around the globe and also enjoys a strong reputation within the blockchain community.

    In addition to protocol-level client implementations (such as โ€œGossamerโ€ on Polkadot), ChainSafe also has demonstrated experience of developing a Metamask Snap for the Filecoin Foundation "Filsnap" as well as engineering the SubstrateSnap (formerly Polkadot-Metamask Snap) itself. Further, ChainSafe is currently in active discussions with a number of blockchain foundations that are exploring Metamask Snaps. We believe that this experience uniquely positions us as an ideal choice to maintain the SubstrateSnap.

    In addition to the above, ChainSafe also rounds out its deep Web 3.0 portfolio with undertakings into product development such as the privacy-first decentralized storage solution ChainSafe Files, among others such as the ChainSafe Gaming SDK and ChainBridge.

    Team Code Reposโ€‹

    Team Github Handlesโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Approximately 2 years ago, Node Factory (recently acquired by ChainSafe) submitted a grant proposal for the maintenance of the SubstrateSnap (formerly Polkadot-Metamask Snap). As the market was not quite ready for Snaps at the time, it was decided that Snaps would be put on hold until further notice.

    https://github.com/w3f/General-Grants-Program/pull/244

    ChainSafe would like to formally re-apply for this grant as we feel that there is now a real need for Snaps in the market.

    After recent discussions between Bryant Soorkia (ChainSafe - Business Development) and David Hawig (W3F - Head of Grants), it was established that a crucial factor in determining the necessity of Snap maintenance would be confirmation of Metamask's intentions to implement the snap into the full version of the Metamask and not just Metamask Flask.

    Following this, ChainSafe and Metamask had a discussion on Wednesday the 9th of March 2022, and confirmed that Metamask will shortly be announcing a Snaps rollout timeline for several different chains. It is expected this announcement will be made in the next few weeks. One such chain will be Filecoin (Filsnap), a project that ChainSafe also engineered. Although we do not yet know the exact date, Metamask has indicated that the SubstrateSnap will be included in the roll-out of all Snaps.

    Evidence of the above has been shared with David Hawig via email.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Why the Specific Project Should Continue Being Supported:

    Given that Metamask has recently shifted its focus towards interoperability and as such, Snaps, we believe that this presents an ideal opportunity for The Web3 Foundation to leverage first-mover advantage. By maintaining the SubstrateSnap, it will allow W3F to take advantage of this by being one of the first Snaps that are ready for deployment prior to launch.

    Overview of the Features/Bugs That Need Development Contributions:

    1. Complete a rewrite of the SubstrateSnap to conform to the new Metamask Snaps API.
    2. Update the @polkadot/api library to the latest version and ensure that it works with Lavamoat.
    3. Update the Demo and Wiki page.
    4. Open a Github Pull Request on https://polkadot.js.org/apps/#/explorer to enable the usage of Metamask Flask via Snap.

    Assurance That the Current Project Owners Are Willing to Review/Accept Your Contributions: We are owners of the SubstrateSnap repository. Further, the maintainers of Polkadot applications are open to accepting a pull request that adds Snap functionality as described here: https://github.com/polkadot-js/apps/pull/2865

    Overview / Budgetโ€‹

    Current and Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? ChainSafe is a long-standing friend of The Web3 Foundation and has collaborated on several projects over the past few years. It was through this relationship that ChainSafe was made aware of the Maintenance Grant program. It is also worth noting that ChainSafe has been awarded W3F grant funding for other projects in the past, one such being Gossamer.

    - + \ No newline at end of file diff --git a/applications/maintenance/Zondax-Support.html b/applications/maintenance/Zondax-Support.html index 8740e26bad0..50839828a42 100644 --- a/applications/maintenance/Zondax-Support.html +++ b/applications/maintenance/Zondax-Support.html @@ -4,13 +4,13 @@ Zondax Support & Maintenance | Web3 Foundation Grants - +
    Skip to main content

    Zondax Support & Maintenance

    • Team Name: Zondax
    • Payment Address: DAI (ERC20) 0x64c37c278f4c975e44ffd99b6e5f0832a3e9e981

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    The aim of this proposal is to contribute and support the community in the face of multiple challenges connected to the use of Ledger applications in the Polkadot/Kusama/Substrate ecosystem.

    Our previous maintenance contract expired several months ago. Because of our commitment to the community (without funding or a contract), we have still been keeping track of support requests and upgrading applications as new runtimes were being released. In this respect, we are already discussing proposals to the respective treasuries but this process requires a deeper legal assessment on our side that may take several more weeks to get resolved.

    Because of the incredible success of substrate based projects, a sizeable amount of new users have recently joined the community. It is important to state that Zondax did not design or operate any web, desktop, mobile or browser extension in the Substrate ecosystem.

    Unfortunately, in recent days, changes to the user interface of Polkadot.js have resulted in some users incorrectly sending funds to destination addresses (actually public keys) derived for other networks. Although these funds are not irrecoverable, at the moment, these users cannot recover funds without a deep technical understanding of the problem. Actually, we do not recommend any of these stopgap solutions, and employing them may compromise the secrecy of Ledgerโ€™s mnemonics.

    For this reason, we would like to propose a series of steps to address and mitigate future similar issues. As previously mentioned, we consider part of this grant as an intermediate step towards a fully treasury based approach. Unfortunately, given the urgency, we believe that in order to respond adequately, an open grant is more appropriate until we analyse in depth some legal uncertainties in the treasury model.

    Project Detailsโ€‹

    Team ๐Ÿ‘ฅโ€‹

    • Registered Legal Entity: Zondax AG
    • Registered Address: 6300 Zug. Switzerland

    Contactโ€‹

    Team's experienceโ€‹

    Our team has very specific experience in this subject matter. Zondax developed both Polkadot and Kusama apps. We have also maintained both applications along all runtime upgrades (more than 50 upgrades) and provided technical support on engineering aspects. Actually, Zondax has developed tens of different Ledger apps for a wide range of blockchain projects. Zondax is also Substrate delivery partner and we have experience in embedded systems, blockchain core and protocol development and applied cryptography.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Introductionโ€‹

    Ledger App Standard Runtime Upgrades: Along the period of time covered by this grant (16 weeks), we will keep upgrading both the Polkadot and Ledger apps to align with important runtime upgrades, in particular, those that are not backwards compatible because of tx_version changes. We are already aware of some important changes happening in a few weeks.

    Ledger App (Polkadot & Kusama) Recovery Extensions: We propose creating a special configuration setting that users can enable to allow for cross-chain derivation (multiple BIP44 derivation) on both Kusama and Polkadot apps. This would allow users to retrieve funds that have been sent by mistake to keypairs in other BIP44 paths and that are currently not easy to recover.

    JS key derivation library: We strongly recommend not using mnemonics anywhere but on the HW wallets themselves. However, we understand the need for a simple tool to independently verify key derivation. For this reason, we propose creating an npm JavaScript and/or Typescript package that can derive keys in the exact same way that Ledger devices do.

    Support: In Polkadot / Kusama, we do not develop or operate web/desktop/mobile wallets, servers, user interfaces, etc.. However, given our involvement in the community (and the fact that we have developed both Ledger apps in addition to other related grants), we are currently receiving a sizeable amount of requests and support questions.

    A large quantity of questions refers to the aforementioned problem (locked funds). In other cases, they are mostly about misusage or lack of training on polkadot.js user interface, connection issues or questions about polkadot and kusama network operations. We believe that newcomers to the ecosystem would definitely profit from a much better support experience and we can contribute to this. We also think that a closer collaboration and joining forces with https://support.polkadot.network would be a major improvement.

    Last but not least, in the following weeks after the release of the "recovery extensions", we understand that adequate and specific guidance and support will be necessary.

    In this respect, we propose:

    • To reactivate and improve our processes, response times and broadening the range of questions that the team at support@zondax.ch are able to answer.

    • To improve coordination with https://support.polkadot.network.

    • To develop and expand a Polkadot/Kusama support website with documentation and articles that address a large quantity of the typical support questions that Zondax receives every day.

    Overviewโ€‹

    • Total Estimated Duration: 16 weeks
    • Total Costs: 49000 DAI (+VAT when applicable)

    Milestone 1 โ€” Supportโ€‹

    • Estimated Duration: 8 weeks
    • FTE: variable due to different skillset but approximately equivalent to 2.5-3.0 FTEs
    • Costs: 25000 DAI (+VAT when applicable)
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will extend our documentation to include this additional features. We will also add more documentation about Ledger key derivation internals
    0c.Testing GuideThe code will have both unit and integration (zemu based) tests as our previous deliverables.
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.Polkadot App Recovery ExtensionWe will add a special recovery mode in the Polkadot app. To minimize mistakes, activating this option will require several steps and explicit confirmation.
    This option will allow deriving Kusama key pairs. We will also adjust JS libraries and coordinate upgrades and Ledger review and publication process
    2.Kusama App Recovery ExtensionWe will add a special recovery mode in the Polkadot app. To minimize mistakes, activating this option will require several steps and explicit confirmation.
    This option will allow deriving Kusama key pairs. We will also adjust JS libraries and coordinate upgrades and Ledger review and publication process
    3.Ledger-Substrate-js DerivationWe will extend the ledger-substrate-js package to include host-side for Ledger's ed25519+BIP32 derivation. A minimal react site and examples will be provided
    4.Polkadot App - Runtime Support UpdatesDue to substrate/scale design requirements, we will make periodic updates to align with changes in the node metadata. In particular, backward incompatible changes (indicated by tx_version increases) require adjusting the code base, review and publication of a new Polkadot app.
    5.Kusama App - Runtime Support UpdatesDue to substrate/scale design requirements, we will make periodic updates to align with changes in the node metadata. In particular, backward incompatible changes (indicated by tx_version increases) require adjusting the code base, review and publication of a new Polkadot app.
    6.Community SupportWe will reactivate and improve of our support processes, response times and broaden the range of questions the support team are able to answer even when they are beyond of our original scope. We will initiate a support subdomain with relevant content, material and tutorials to support both the recovery extension as well as to mitigate future community issues. Moreover, we will improve coordination with support@polkadot.network.

    Notes:

    • We will strongly prioritize the release of recovery extensions to both Kusama / Polkadot Ledger apps.

    Milestone 2 โ€” Supportโ€‹

    • Estimated Duration: 8 weeks
    • FTE: variable due to different skillset but approximately equivalent to 2.5-3.0 FTEs
    • Costs: 24000 DAI (+VAT when applicable)
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will document any protocol level changes made as part of the runtime support upgrades
    0c.Testing GuideThe code will have both unit and integration (zemu based) tests as our previous deliverables.
    0d.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.Polkadot App - Runtime Support UpdatesSimilar objective as the previous milestone
    2.Kusama App - Runtime Support UpdatesSimilar objective as the previous milestone
    3.Community Support
    - + \ No newline at end of file diff --git a/applications/maintenance/wasm-opt-for-rust.html b/applications/maintenance/wasm-opt-for-rust.html index bc098f556e7..cd21876765e 100644 --- a/applications/maintenance/wasm-opt-for-rust.html +++ b/applications/maintenance/wasm-opt-for-rust.html @@ -4,7 +4,7 @@ wasm-opt for Rust Maintenance | Web3 Foundation Grants - + @@ -47,7 +47,7 @@ or introduce major new features.

    We expect to continue to be involved in the Substrate / Ink! ecosystems, and to make additional grant proposals related to WebAssembly, Ink!, and Substrate in the future.

    Additional Information โž•โ€‹

    How did you hear about the Maintenance Grants Program? personal recommendation

    - + \ No newline at end of file diff --git a/applications/manta_network.html b/applications/manta_network.html index 0cdc970dc0a..54d6bbec2b5 100644 --- a/applications/manta_network.html +++ b/applications/manta_network.html @@ -4,7 +4,7 @@ Manta Network | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ tx_mint with the deposit of base coin, more specically:

    1. u samples a random number, which is a secret value that determines the private coins serial number (Note: tx_mint didn't include this number).
    2. u commits her public key a_pk, the value of the coin v, and the random secret s that she sampled in the last step in a two stage commitments.
    3. u thus mint a private coin and only put the value, the first stage commitment, the random secret for the second stage commitment, and the final commitment.
    4. The ledger verifies that the u indeed deposits base coin of value v and add the final commitment to the merkle tree that represent ledger state.
    Transfer private coinsโ€‹

    Private coins can be spent and transferred by tx_transfer, which takes a set of input private coins to be consumed, and transfers their total value to a set of output coins: which could be either private or public.

    To transfer a private coin, a user need to provide a zero knowledge proof of she knows the old coins, new coins, and the secret key of old coin such that:

    1. both the new coins and old coins are well formed
    2. the address secret key matches the public key
    3. the old coin's commitment appears as a leaf of the merkle tree representing ledger state
    4. The set of old coins and the set of new coins have the same total value (minus transaction fee).

    The new coin will be posted on chain using public key encryption.

    Manta DAXโ€‹

    Manta Decentralized Anonymous eXchange scheme is based on zkSNARK and AMM. The overall design intuition is that the ledger maintains x*y = k (or using some more sophiscated curve) invariant for an exchange pair. The validation logic requires that trader provide an zero-knowledge proof of the fulfillment of this invariant after trading. Below is a simplified architecture of Manta DAX:

    (Please see section 4 of the white paper for more details.)

    Implementationโ€‹

    Manta DAP will be a substrate module. The ledger state will be a list of Merkle roots, i.e. (L_A, L_B, ..., L_N), where each merkle root represents the commitment list of a base coin. Manta DAP also support registering new coins that is compatiable with Manta DAP interface.

    We will implement Manta as two parts:

    We will only build Decentralized Anonymous Payment (DAP) in this grant since the whole project (DAP+ DAX) is too large to be implemented in only one grant.

    Ecosystem Fitโ€‹

    The current ecentralized exchanges scheme lack privacy, anti surveillance interoperability, and anonymous cryptocurrenciesโ€™ lack of price stability. As the first decentralized anonymous payment that could support existing assets, Manta DAP will be a great addition to Polkadot eco-system since Polkadot and Parachain assets such as aUSDT and wrapped BTC can be transferred and spent privately. We already talked to Polkadot eco-system members such as Acala and Equilibrium. They showed strong interests of integrating with Manta. Also, Manta DAP will be the an important building block for Manta DAX (Decentralized Anonymous eXchange) scheme that enables privacy preserving AMM style decentralized exchange using zkSNARK.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Detailed experience see Team's experience section.

    Team Websiteโ€‹

    Manta Network Ltd., a British Virgin Islands corporation

    Team's experienceโ€‹

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Manta DAP Protocol Prototypeโ€‹

    The major deliverable of this milestone is Manta substrate pallet that support the basic DAP scheme:

    1. Mint private coin, a user could mint a DOT/KUSAMA coin to a private coin in Manta
    2. Transfer private coin, a Manta user could transfer a private coin to another user Manta user by providing an address and a zero-knowledge proof of the private coin that she owns

    The Manta substrate pallets includes the ledger state implementation, the transaction validation logic which involves the validation of zero-knowledge proofs. Note that this milestone will only support converting DOT/KUSAMA to private coins.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    1.Manta Substrate Pallet ProtoypeAn open-sourced Manta DAP propotype substrate pallet. It will contains several sub-pallets, such as zkSNARK verifier runtime, ledger state and its validation logic, etc. This prototype supports basic functionalities such as mint private coins, transferring private coins. This first version of Manta DAP will only support DOT/KUSAMA.
    2.Benchmarkbenchmark on Manta DAP transaction latency and throughput.
    3.DockerWe will provide a dockerfile to demonstrate the end-to-end use case of Manta DAP.

    Milestone 2 โ€” Manta DAP Wallet Protocol and XCM Integrationโ€‹

    There are two major new deliverable in Milestone 2:

    1. Support minting Parachain asset via XCM. This requires the following:
    2. MantaPay wallet protocol and wallet implementation:
    NumberDeliverableSpecification
    0a.LicenseGPL V3
    1.Manta Parachain Runtime with MantaPayCompared with the prototype in Milestone I, we will add support for minting parachain assets to private coins in this prototype.
    2.MantaPay Pallet ImplementationThis is the pallet that implements the updated MantaPay Protocol with signficant speed improvement.
    3.Manta DAppA web based DApp that manages and transacts Manta supported private assets
    4.Manta SignerManta's Mac/Win/Ubuntu client that turbo-charges ZKP generation. Signer will communicate with Manta DApp

    Note: 1 and 2 will be delivered together as a docker container.

    Community engagementโ€‹

    As part of the Program, we plan to publish several medium articles/tutorials, including:

    Future Plansโ€‹

    Community Planโ€‹

    Our co-founder Victor is the chair of Harvard Kennedy School Blockchain and Cryptocurrency PIC, which is one of the largest blockchain community in eastern America. He can reach the local tech communities since he organized many Hackathons for the ETH foundation and Dorahacks in Boston.

    Meanwhile, as a famous investor and columnist at top-tier Chinese blockchain media, Victor can engage with China investors and communities based on his connection. So we can build our communities in both US and China for Polkadot and Manta based on our previous experiences and resources.

    We already created the Twitter, WeChat, telegram and medium channels for the Manta Network. In next step, we will work with our investors and partners to widespread it. Moreover, we will select investors to choose those with strong media and community resources.

    Besides, we are actively engaging with Polkadot ecosystem projects like Acala, Equilibrium, Moonbeam, Stafi, Sora and Reef to find opportunities to work together in research, development and community building.

    Development Planโ€‹

    Manta DAP is the foundational part of Manta project. The future plan of Manta includes:

    Additional Information โž•โ€‹

    We finished the cryptographic scheme design of Manta, see Manta White Paper. We are still quickly iterating and refining the engineering details of Manta.

    Email: contact@manta.network

    Website: https://manta.network/

    Whitepaper: https://github.com/Manta-Network/Manta-Whitepaper

    Github: https://github.com/Manta-Network

    Twitter: https://twitter.com/mantanetwork?s=21

    Medium: https://medium.com/@mantanetwork

    Telegram: https://t.me/mantanetwork

    WeChat Public Account: MantaNetwork

    - + \ No newline at end of file diff --git a/applications/massbit_route.html b/applications/massbit_route.html index 421387012d6..ebc0340a6b9 100644 --- a/applications/massbit_route.html +++ b/applications/massbit_route.html @@ -4,14 +4,14 @@ Massbit Route | Web3 Foundation Grants - +
    Skip to main content

    Massbit Route

    • Team Name: Codelight
    • Payment Address: 0xD068C7E05CF20fcEE618C8F9207e019020c62F35
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    • Codelight team's vision is to build a decentralized, user-operated, and governed Blockchain Distribution Network. To achieve the goal, we build Massbit blockchain on Substrate framework, with MBT token to create an economy, where Node Providers stake and earn Massbit token for servicing the BDN and Consumers pay in token for global access to decentralized blockchain APIs.

    • The majority of existing dApps are utilizing blockchain Infrastructure-as-a-Service (IaaS) such as Infura or GetBlock to shorten the time to bring their products into production. Those blockchain IaaS services have gained traction quickly and contributed to the growth of many layer-1 and layer-2 blockchain networks. But that added value comes with downsizing that many "dApps" rely on a centralized blockchain IaaS service and are prone to outages caused by IaaS providers. Massbit Route eliminates blockchain API single-point of failure by forming a global network of Independent node providers to allow dApps access to the nearest blockchain data source with optimal response time.

    Project Detailsโ€‹

    Architechture Overviewโ€‹

    • Massbit Route is a blockchain distribution network (BDN) operated and governed by users all over the globe. It provides decentralized applications access to different blockchain APIs by routing request network traffic to a blockchain node with optimized response time. In addition, Massbit Route is built to provide performance-optimized access to blockchains and aims at eliminating blockchain API single-point of failure by forming a global network of independent Node Providers. We build a network operated and serviced by users that provide fast and redundant access to blockchain sources. Massbit Route facilitates a network of Gateways and Nodes infrastructure in 6 different zones around the world:

      • Asia
      • North America
      • Africa
      • Europe
      • South America
      • Oceana

    • Users can join the Massbit network as Providers from any of those regions by running Massbit Nodes and Gateways connected to blockchain data sources such as Ethereum or Polkadot. As the Massbit network grows in the number of Nodes and Gateways as well as independent node providers, the network becomes highly available and redundant. When a Provider experience an issue with their nodes, blockchain API requests will be served by other Providers, which eliminates single-point-of-failure in Web2 CDN architecture.

    Componentsโ€‹

    | 1. Massbit Core

    • Massbit Core (MC) is the orchestrator of the entire Massbit network. New Nodes and Gateways that need to join Massbit network can obtain installation script and network configuration generated by MC.

    • MC works along with other components to onboard new Gateways and Nodes onto the Massbit network, and make sure traffic is routed by Gateways and Nodes effectively. When Providers need to operate Nodes or Gateways in the Massbit network, they need to obtain a set of instructions created by the MC from the Portal for their servers. By executing the instructions in the form of a bash shell script, the server will negotiate with MC and Verification Service if it is qualified to participate in the MassBit routing network. Once a Gateway is successfully verified in the Massbit network, MC provides a list of dAPI entry-points and Nodes in the same zone the Gateway needs to server request and forward traffic respectively.

    • As the Massbit Route network grow globally and blockchain traffic needs to be directed optimally, MC constantly updates Gateways with a set of traffic routing and handling instruction to adopt a change within the Massbit network. For example, when some nodes in a zone go offline, new nodes are added or Consumers adjust the request rate for dAPI entry-point, MC generates a new set of configurations for all of the Gateway in the zone.

    | 2. Gateway Manager

    • Gateway Manager the DNS component of Massbit network based on the opensource project gdnsd. It runs as an authoritative DNS system of the Massbit network, and can be seen as a directory for all Community Gateways and Nodes around the world.

    • When a dApp queries blockchain API through a Massbit dAPI entry-point, it needs to lookup the IP address for the dAPI entry-point through their configured recursive DNS servers. If the recursive DNS servers do not have the entry for the dAPI entry-point, they will perform an authoritative lookup to Gateway Manager. With geographic IP capability, Gateway Manager resolves the DNS lookup with the IP of the Gateway closest to the requesting dApp based on the source IP in the request Header.

    • A dAPI entry-point URL has the following format:

    https://[API ID].eth-mainnet.massbitroute.net/[API key]
    wss://[API ID].eth-mainnet.massbitroute.net/[API key]
    • The host portion in the dAPI URL is a dynamic DNS entry in Gateway Manager. The resolved IP in the authoritative response by Gateway Manager will vary depending on the source IP in the request Header.

    | 3. Session Manager

    • When a dAPI entry-point is created by Consumer, a dynamic DNS entry is created by Gateway Manager and resolved to the nearest Gateway IP based on the source IP in the request header. Once traffic reaches a Gateway, in order to accept the API request from Consumers, it needs to obtain a dAPI session key from Session Manager. The session key is only valid for a certain amount of time and will be renewed for the dAPI entry-point if needed.

    • In addition, Session Manager also controls the usage of the dAPI entry-point. Consumers need to deposit MBR tokens for the dAPI entry-point in advance to pay for the cost of dAPI usage. Depending on the amount of MBR deposit, Consumers will receive a corresponding quota for dAPI usage. Session Manager will inform if a dAPI entry-point is out of quota and Gateways will block incoming request until more MBR token is funded for the dAPI.

    • Session Manager also prevents malicious actors from bypassing dAPI payments and sending blockchain requests directly to Gateway public IP. Without a valid session key and a dAPI entry-point, Gateways will reject the requests destined to their public IP. This will maintain the security of the network and form a building block for Massbit Route token comic.

    | 4. Stats

    • Stats collects telemetry from all verified Gateways and Nodes in the Massbit network. The service provides different metric data to allow the Portal to visualize Nodes and Gateway performance with charts. In addition, it calculates and keeps track of the available quota for each dAPI based on the amount of MBT token deposit.

    | 5. Fisherman Pallet - Decentralized Node Verification Service

    • Massbit Route becomes a faster and more reliable BDN when the number of Community Nodes and Gateway increases. For that reason, Nodes and gateways need to meet certain bandwidth and latency requirements checks by Fishermans in order to be part of Massbit global network. Fisherman Pallet is an Off-Chain Woker that is included with the Massbit Gateway installation script. The more Massbit Gateways are deployed, the more decentralized this service become, which make the process of node/gateway onboarding un-biased.

    • When a Node requests to join the Massbit network, nearest Fishermans checks if the Node is able to forward requests to its blockchain data source and return results matching with the blockchain data source such as block data, block hash, and runtime version. If all checks passed the validation process, the node becomes a part of the Massbit network and gets ready to receive traffic from Gateways in the same zone.

    • In each zone, a minimum of 1 Node is required in order for a Gateway to be verified. Without any Node or blockchain data source, it is unnecessary to run a Gateway in that zone because it introduces some routing overhead, and traffic will eventually be routed to the nearest zone.

    • When a Gateway needs to join the Massbit network, Fisherman will validate if the Gateway has obtained a list of Node in its zone from Massbit Core and whether it can proxy traffic to the Nodes properly. If blockchain data returned by Gateway is correct and match with data from the Node and blockchain data source in that zone, the Gateway is verified and its public IP is updated in the Gateway Manager directory.

    | 6. Massbit Route blockchain

    • Building on the Substrate framework, the Massbit chain is a source of truth for token-related activities in the Massbit network. Massbit Consumers need to pay fees in MBT tokens in exchange for global dAPI service. In return, Providers earns rewards from Consumers' fee for handling blockchain API requests and maintaining the stability of the network. Through the Massbit chain, anyone can verify Providers' and Consumers' activities with the following pallets:

    • Provider/Delegator activities Pallet

      • Staking/Un-staking amount on each Node/Gateway
      • Reward calculated after each Era from Consumer fees โ€‹
      • Reward claim history โ€‹
      • Node/Gateway State reported by Fisherman โ€‹
      • Node verified duration eligible for staking rewardโ€‹
      • Provider Wallet and transactions
      • Staking/Un-staking amount on delegated Node/Gateway

    • Consumer activities Pallet

      • dAPI deposit fee
      • dAPI remaining quota based on past usage on the deposit fee
      • Consumer wallet and transactions

    | 7. Portal

    • Portal is the user interface of Massbit Route that allows user to user to perform the following activities:

      • Create/stake/unregister Nodes and Gateways
      • Obtain the installation script for Nodes and Gateways
      • Claim reward for Nodes and Gateways
      • Visualize traffic of Nodes, Gateway, and dAPI entry-point
      • Create dAPI entry-point and view the quota
      • Deposit fee for dAPI

    • Below is the first version UI of the Massbit Web Portal

    Home PageMassbit Route Home Page

    Gateway ListMassbit Gateway List

    Gateway DetailMassbit Gateway Detail

    Node ListMassbit Node List

    Node DetailMassbit Node Detail

    dAPI DetaildAPI detail

    | 8. Community Gateway

    • Gateways are entry-points to the Massbit network, which receive blockchain API requests from dApps. It keeps a list of verified Nodes in the same zone, and forward requests to those nodes. It also stores static content of blockchain requests to reduce the response time for identical requests that come in later
    • Utilizing Open Resty framwork, Gateways are repsonsible for blockchain traffic within each zone. The robust functionalities of Open Resty framework allows advanced and efficient routing capabilities for Massbit dAPI entrypoints including:
      • Load Balancing for multiple Node-as-a-Service enpoints like Infura or Getblock
      • accepting blockchain requests from dAPI entrypoints
      • Rate limiting
      • Geo IP detection and routing for optimal response time
      • Edge caching
      • Routing to only functional Upstream servers (Massbit Node)

    | 9. Community Node

    • Community Nodes receive requests from upstream Community Gateway and forward them to the attached blockchain data source. In addition, it works with Massbit Fisherman to make sure the data source is available and synchronized with peers before it can receive new blockchain API requests from Gateways.
    • Also utilizing Open Resty framework, it acts as one of the Upstream Servers for all of the Massbit Gateways in the same zone, and forwards traffics to its own blockchain data source.
    • Node Providers can make their own decision whether to run Massbit Node and blockchain RPC node on the same host/server or different ones.

    Traffic Routing Mechanismโ€‹

    • In the Massbit network, Gateway Manager, Community Nodes and Community Gateways form a global blockchain CDN network in order to optimize blockchain API request and response time.

    • Based on the public IP of each community-run Node and Gateway, a global geographic map of verified and staked Gateways is continuously updated. When a dApp sends a blockchain API request through Massbit Route API Entrypoint created by a Consumer, based on the global network IP map, the request is forwarded to a Gateway in which its zone is the same or closed to the request source IP.

    • Each Gateway constantly updates Massbit Core to maintain a list of verified Node in its zone. From the gateway, the request is then forwarded to one of the nodes in the same zone in a round robit fashion. A node will will then relays the request to the blockchain data-source associated with the node.

    Massbit routing mechanism

    • When a node or gateway experiences issues such as poor CPU, memory, and network performance which result in high latency and response time, it will be deregistered from the Massbit network by Fisherman. Only nodes with "staked" status in the Massbit network can serve API requests and earn token rewards to guarantee the stability of the entire network.

    • Because Massbit Gateways, Nodes, and blockchain source nodes are operated by independent providers, single-point of failure is eliminated. Fisherman ensures DNS entries of offline or malfunctioned Nodes and Gateways are removed from the network and make sure blockchain requests are forwarded through active nodes, which maintains redundancy for the Massbit network.

    Node Approval processโ€‹

    Node Aprroval process

    When a Node or Gateway joins Massbit, it needs to go through different states before it can serve dAPI traffics.

    • Created: Node/Gateway information (name, zone, blockchain type that is served by this node, blockchain node IP) is registered with Massbit network. Based on the registered information, an installation shell script is generated for the new node.

    • Installing: When the installation script is executed on a new server that needs to join the Massbit network, the status changes to Installing, and the public IP of Node/Gateway is recorded to the Massbit chain

    • Verifying: When the installation completes on the new server, it will proceed with the verification process for eligibility to join the Massbit network. Fisherman will be mainly responsible for this stage by checking the following criteria:

    CriteriaDetail
    Data integrityThe node/gateway must return data identical to the blockchain data-source from which the response was retrieved. This will prevent man-in-the-middle attacks
    The blockchain data-source must be fully synchronized.
    PerformanceNode/gateway needs to satisfy 3000 requests/sec with a 500 MB/sec transfer rate for 95% of test requests

    • Verified / Failed: If a node/gateway passes Verifying stage, it becomes "Verified" and is ready to be approved by Fisherman for staking and serving dAPI

    • Approved: In each zone, based on the dAPI demand, Fisherman automatically will approve the node/gateway to join Massbit.

    • Staked: After the node/gateway gets approved, the Node Provider needs to stake a minimum of 100 MBT tokens. Once the node/gateway is staked, it is ready to service the dAPI and earn token rewards.

    • Reported: While nodes/gateways are servicing the network, Fisherman continuously checks for the network stability of each node/gateway. In case a node/gateway does not pass the check, it will be reported and eliminated from the Massbit network.

    How does Massbit make sure that the nodes actually fulfil the Performance requirements?โ€‹

    • In Milestone 1, we place Fisherman in each regions to check the network performance of new Nodes/Gateways before joining Massbit network. By measuring Rount Trip Time and network bandwidth from it self to the new Node/Gateway, it makes decisions whether the new node is eligible for joining the network.

    • We are aware that this approach has many drawbacks and the evaluation proccess is not fair for all new nodes. The first version of Fisherman is a prototype for us to test the functionality of all Massbit components together.

    • In Milestone 2, Fisherman is modified to be more decentralized and more efficient. All Massbit Gateways have Fisherman component included, which is responsible for ensuring the neighbor Nodes and Gateways are functional. Each Fisherman talks to a Scheduler in its region and perform assgined tasks.

    1. When a Node/Gateway needs to join Massbit network, the Schedulers requires all active Gateways in the network to measure Round Trip Time (RTT) and network bandwidth to the new Node/Gateway.
    2. Based on the result of RTT and network bandwidth from active Gateways to the new Node/Gateway, if they satisfy the RTT and network bandwidth baseline, the new Node/Gateway is verified. The Node Provider can stake the new node with MBT tokens and serve traffic. In case of a new Node, it also needs to be able to forward test RPC requests to its attached blockchain datasource and returns back valid RPC response.
    3. Once the new Node/Gateway is staked and actively serving traffic, the Scheduler will inform the Massbit Core to update the network configuration for the whole network with the new node. Based on measured RTTs and network bandwidth measure from each active Gateway to the new Node/Gateway:
      • The new Gateway will receive a new network configuration to pair and forward traffic to low latency/nearby existing Nodes
      • The new Node will receive a new network configuration to receive traffic from nearby Gateways
    4. The previous process will repeat periodically to update Gateway and Node pairings with the most optimized paths and make sure the new Node/Gateway remain functional in the Massbit network.
    • The specific values for ideal RTT and network bandwidth are to be determined as Massbit team needs to perform more benchmark and testing for further evaluation.
    • The Scheduler is designed to assign multiple checks/tasks to Fishermans on active Gateways. Depend on our findings, more tasks may be added after our internal testing and during testnet phase.

    How does Massbit system deal with denial-of-service (DDoS) attacks?โ€‹

    • Malicious actors will find a way to disrupt Massbit network in order to cause outage and interuption for Web3/DApp. For Massbit Gateways and Nodes, the only required open port is 443 to minimize the attack surface to Massbit network. What counter-measurements does Massbit implement to prevent this problem?

    • Massbit Route is designed as distributed network of Nodes and Gateways. As Massbit network grows in the number of Nodes/Gateways in 6 different regions, high network load is scattered across different paths to reach a specific blockchain RPC node, which will reduce the network congestion and mitigate the effect of DDOS attacks.

    • Protection at Node level:

      • Massbit nodes only need to receive traffic from nearby Gateways with low RTT and high network bandwidth. For that reason, HTTPS connections are only whitelisted for those nearby Gateways.

    • Protection at dAPI level:

      • Attacker can obtain Massbit dAPI URL from Web3/DApps source code and perform volume-based DDoS at Layer 7 on the URL with the desire of saturating the bandwidth of the whole network. Each Massbit dAPI created has a default rate limiting configuration of 100 requests/sec which is applied on all Gateways that will be serving traffic for the specific dAPI URL. The consumers can adjust this number from the Web Portal based on their usage.

      • When the dAPI URL is called, the traffic is handled by a Gateway which is in the same zone as the requester's source IP. If the DDoS attack is lauched from many different botnets in a single or multiple Geo resgions to the dAPI endpoint, their traffic is served by multiple Massbit Gateways, which mitigate the impact of high-volume traffic. Once the request/sec threshold reaches on a Gateway, it start to refuses subsequent incoming requests. As a result, Massbit Gateways prevents volume-based DDoS traffic from entering Massbit network, and reaching underlying Massbit Nodes/RPC nodes. The more Gateways are deployed across regions, the better Massbit network sustain volume-based DDoS attack

      • The Fisherman component of the nearby Gateways periodically check its neighbor for liveness, and inform Massbit Core to update the routing/DNS configuration for the entire network to instruct healthy Gateways to serve incoming RPC requests within a zone. If a Gateway's resources are overwhelmed and can no longer serve request due to DDoS protocol attacks such as SYN flood, or IP spoofing, Massbit Core updates with Gateway Manager to stop resolving the host portion in the dAPI URL to the unhealthy Gateway. This will add redundacy and ensure Massbit network remain functional in the event of some Gatways are taken down due to DDoS attack.

      • The attacker can also create multiple Massbit dAPI entries to increase the attack surface, and amplify the magnitude of the attack. In order for the attacker's volume-based network traffic to penerate into Massbit network and reached Massbit Nodes and RPC nodes, they will need to deposit MBT token to their Massbit dAPI and receive a specific quota according to the deposit amount. If the dAPI quota reaches 0, Gateways stop serving traffic for the dAPI URL. This also discourage the attacker as there is cost involved in launching the attack, and the Node Providers earns reward for maintain the network.

    • Protection at Gateway level:

      • The attacker can focus on a specific Gateway IP and perform a direct DDoS attack without using the dAPI URL.

      • At Layer 3 and 4, monitoring network health and anomaly detection is one of our team's primary focus for DDoS mitigation strategy. Each Gateway and Node will be installed with a monitoring client which will report network statistics, network flow and top talkers. Known DDoS attack patterns are rejected and alerted to our internal team's monitoring service with pre-configured patterns/rules such as certains IPs causing peaks in network, open connections and resource depletion.

      • Additionally, based on our observation, we can also implement a new traffic configuration policy, and allow Massbit Core to update the entire network of Massbit Gateways/Nodes to defend against malicious DDoS traffic. DDoS protection at Layer 3/4 for Massbit network is a challenging task with unexpected and sophisticated threats, so we will have to take both pro-active and re-active approach to keep the network healthy.

    • Other counter-measurements:

      • Gateway Manager is also a crucial part of Massbit network as it the authoritative DNS component of the network. DNS components are prone to reflection and amplification attack, which accelerate the rate of malformed traffic to deplete the server resources. We will utilize existing third-party service with Deep Packet Inspection capability, DNS query whitelisting and rate-limiting to add a layer of defense and DDoS mitigation to this component.

      • Massbit Core and Massbit web portal are also placed behind a Web Application Firewall and Layer 3 Network Firewall to protect against DDOS and common web application attacks.

    Tokenomic of MBTโ€‹

    • MBT tokens will be used within the Massbit network by Node Providers, dAPI Consumers, and Delegators. In order to join the Massbit network, Node Providers need to stake their Massbit Nodes and Gateways to become actively serving blockchain requests in Massbit. In return, Node Providers will receive MBT token rewards from serving requests from dAPI Consumers.

    • The Consumers need to deposit MBT tokens to exchange for dAPI usage quota. The deposit amount is distributed to the Nodes Providers based on the amount of dAPI requests they served after each Era.

    • In addition, anyone can delegate MBT token to actively running Massbit Nodes/Gateways to earn a small portion of the reward without the technical knowledge and effort to maintain Nodes/Gateways and RPC nodes.

    • Our team is still expanding more detail for the Massbit token economy, which can be found in the this documentation

    Project Technology Stacksโ€‹

    • Rust
    • Substrate
    • Node.js
    • NGINX (Open Resty)
    • Lua
    • Docker
    • Vue.js
    • Polkadot.js

    Ecosystem Fitโ€‹

    • Massbit Route is a decentralized network of Nodes and Gateways that route dApps requests to low latency blockchain nodes. Built on Substrate framework, we would like to create a diversified network of independent blockchain RPC nodes and Web3 applications that are servicing each other.

    • Within the ecosystem, by using Massbit tokens, independent individuals, groups, communities, or organizations can freely join and get reward for servicing the BDN network by running Node/Gateways. With Massbit Route dAPI, Web3/DApps will have reliable and cost-efficient access to a independent blockchain RPC nodes through Massbit routing and caching mechanism. There is no middle-man or single entity that controls the entire blockchain distribution network which will eliminate the majority of undesired service interuption or censorship that may happen.

    • With a foundational software design and network routing structure of Massbit Nodes and Gateways, the upcoming integration with more layer-1 protocols, ETH layer 2 solutions, and other parachains become less of a burden in the near future. Once our team sees a demand for a new type of blockchain in the Massbit Route network, the implementation for the new blockchain integration can be done in a short duration. Our team commits to listen and support our community's needs to enrich the ecosystem and maintain the stability of the Massbit network.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Name of team leader: Minh Doan
    • Names of team members:
      • Tran Thanh Vu
      • Vu Viet Tai
      • Nguyen Anh Huy
      • Nguyen Manh Dat
      • Thien Tuong
      • Bui Tran Huy Hoang

    Contactโ€‹

    • Registered Address: Craigmuir Chambers, Road Town, Tortola, VG 1110, British Virgin Islands
    • Registered Legal Entity: MassBit Solutions Ltd

    Team's experienceโ€‹

    • Tran Thanh Vu: Massbit Technical Product Manager - 9+ years experience working with high load systems, designing architecture systems, resolving problems in high performance, high availability, scalability, distributed system, and big data.
    • Vu Viet Tai: Massbit Product Owner - Co-Founder of Appbike, experience in product management and Scrum development
    • Nguyen Anh Huy: Software Engineer (Rust) - Doctor of Computer Science and Intelligent Systems - Osaka Prefecture University
    • Nguyen Manh Dat: Software Engineer (Rust - Blockchain) - Software Engineer with past experience building large E-commerce platforms and Fintech product
    • Nguyen Thien Tuong: Full-stack Software Engineer - Software Engineer with past experience building large E-commerce and logistics platform
    • Bui Tran Huy Hoang: DevOps Engineers - Experience with deploying/scaling/automating Enterprise network infrastructure and application on Public Cloud

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    • Massbit Route team has completed the code base for the Massbit Route blockchain distribution network including:

      • Core API
      • Stats
      • Session manager
      • Fisherman and Verification service
      • Gateway Manager
      • Massbit Node
      • Massbit Gateway

    • Through a network of Massbit nodes and gateways, Massbit Route is now supporting traffic routing to ETH and DOT blockchain nodes. We have tested the network internally with 150 Massbit nodes and gateways deployed in 5 zones. We came to the conclusion that, in each zone, each working Massbit node requires 4 Massbit Gateway to achieve a reponse time under 500 ms for a blockchain API request through dAPI entry-point.

    • Currently, we are in Testnet with a target of 100 independent user-operated Massbit nodes (each node attach to an ETH/DOT full node) and Gateways that span across 5 different zones. Through this testnet phase, we would like to introduce Massbit Route core functionality to professional and individual node providers as well as dApps partners that need cost-efficient and fast access to ETH/DOT blockchain nodes. Additionally, we take this opportunity to object real-world network traffic/usage to evaluate the following key points for further improvement in preparation for main-net launch:

      • The effectiveness of the blockchain traffic routing mechanism
      • Find out key metrics to adjust the fairness for the node approval process
      • Adjust the fee for dAPI usage and fair reward distribution to node providers who served the API request

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months (only applied for the delivery scope of this project)

    • Full-Time Equivalent (FTE): 6 FTE

    • Total Costs: $50,000 USD

    • We do not have an estimate for the actual cost and duration of this project, as we continue to integrate more blockchain projects, improve the performance/efficiency of the network, and building tools to support dAPI users.

    Milestone 1 - Global Blockchain Distribution Networkโ€‹

    • Estimated duration: 1 month
    • FTE: 6
    • Costs: $35,000
    NumberDeliverableSpecification
    0.aLicenseApache 2.0
    0.bDocumentationWe will release a detailed official guides for node operation, routing mechanism, and Node/Gateway performance metric requirements on Massbit mainnet
    0.cTesting GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0.dDocker releaseWe will provide docker files to simulate Massbit network that can be used to test all of the functionality delivered with this milestone
    0.eArticleWe will publish an article that explains the technical details of Massbit Routing mechanism, Node/Gateway verification process and how individuals/communities around the world can run Nodes and Gateways and participate in service Massbit network
    1.Massbit Core Implementation (Lua)We will implement Massbit Core which is responsible for ochestrating, generating installation scripts and routing configuration for all Nodes and Gateways within Massbit network
    2.Gateway Manager Implementation (C)We will implement Gateway Manager as an Authoritative DNS server for Massbit network
    3.Fisherman - Node Verification Service (Rust)We will implement the first version of Fishserman. This allows the Node/Gateway to be verified with Fisherman in each before join Massbit network
    4.Massbit Nodes and Gateway (Lua)We will implement Massbit Node and Gateway with Open Resty framework. These components are responsible for routing API requests to RPC blockchain nodes nodes within each zone
    5.Web Portal implementation (Vue.js)We will implement the front-end web portal to allow user interaction with Massbit such as creating new node/gateway and generate installation scripts, or staking and claiming token rewards
    6.Pallet Implementation for Consumer dAPI fee and reward distribution for providersWe will implement reward distribution from Consumer fee to Node providers based on the number of API requests served by each Provider.
    7.Pallet Implementation for Node Provider/Delegator staking and reward distributionWe will implement the Node/Gateway Staking feature for Providers and Delegators. In addition, the reward for each Node staking can be also claimed and sent to stakers' wallets

    Milestone 2 - Implementation for substrate-based Massbit chainโ€‹

    • Estimated Duration: 1 month
    • FTE: 6
    • Costs: $15,000
    NumberDeliverableSpecification
    0.aLicenseApache 2.0
    0.bDocumentationWe will release a detailed official guides for node operation, routing mechanism, and Node/Gateway performance metric requirements on Massbit mainnet
    0.cTesting GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0.dDocker releaseWe will provide docker files to simulate Massbit network that can be used to test all of the functionality delivered with this milestone
    0.eArticleWe will publish an article that explains the usage of MBT token for dAPI and Node/Gateway staking, the reward distribution mechanism, and the Node Provider incentives to increase the number of Nodes and Gateway for high-traffic zones in Massbit Route network
    1.Fisherman Pallet - Collect Provider Performance OracleWith performance metrics observed from testnet, we will use Subtrate Offchain Worker to allow the community to operate this component under the Proof of Authority concept. This will provide an unbiased, fair and decentralized Node Approval Process as Fisherman is no longer a single component in each zone controlled by the Massbit team. Active Gateways are also automatically update to include this component
    2.Session Manager (Rust)We will implement Session Manager to control and grant session keys to Massbit Community Gateways
    3.Node Provider staking Pallet - Provider incentive potAt the early stage of the Massbit network, the number of Consumers will be low, which leads a small reward for Node Providers. The Provider Incentive Pot is a module with 10% of the total token supply locked and will be allocated 0.01% of the remaining balance for each Era to incentivize Node Providers to maintain network service.
    4.Stats and monitoring system implementationWe will implement a metric collection module to observe traffic and network performance to make improvement/adjustment to routing mechanism, Consumer dAPI as needed

    Future Plansโ€‹

    • Our testnet phase is currently open to let our community experiment with Massbit Route core routing functionality with ETH and DOT blockchain nodes. Within the scope of Milestone 1, we want to take this opportunity to observe the following to release the stable version of the Massbit Route blockchain distribution network:

      • User experience with Node/Gateway installation process
      • Node approval process with a fair evaluation of RTT and network bandwidth by distributed Fisherman component at different locations within a zone
      • Accuracy in IP Geolocation for Nodes/Gateways
        • This ensures Nodes/Gateways are approved and benchmarked by Fisherman in the right zone
        • Detect inaccuracy in IP Geolocation database by surrounding gateways

    • In the short term, we put our effort into optimizing and improving the efficiency of core functionalities of Massbit Route. We will open testnet with unofficial Massbit token to allow active community members to experiment with the Massbit Route network. This also helps our team to patch any bugs or issues from the design and implementation from the Node Provider standpoint.

    • Once Massbit Route achieves the stability and efficiency at the early stage, it will have a solid foundation to attract DApps to migrate to Massbit Route API and more Node Providers around the world to come and service the network. DApps and strategic partners are onboard and offered to use dAPI from Massbit Route launched testnet. We will collect feedback/performance metrics and improve the product from End-user/Consumer standpoint.

    • In the long run, once we reach the stability of global Massbit routing performance and fair token distribution from Consumers deposit fees to Node Providers, we will focus on expanding the Massbit Route ecosystem by integrating the network with parachains and major L1/L2 that have a large number of transactions and data usage. In addition, when we reach a large network of node providers that span many different parts of the world and have quick access to mempool, it is a good opportunity for Massbit to expand the feature scope to Defi Trading such as determining the gas price to win a gas auction or future block mining.

    - + \ No newline at end of file diff --git a/applications/mobile-game-framework.html b/applications/mobile-game-framework.html index fe56deb3507..0d54fe6b56d 100644 --- a/applications/mobile-game-framework.html +++ b/applications/mobile-game-framework.html @@ -4,13 +4,13 @@ Mobile Game Framework for Substrate | Web3 Foundation Grants - +
    Skip to main content

    Mobile Game Framework for Substrate

    • Proposer: enfipy
    • Payment Address: 1Gkvai1HtZmtQ5DWDGrCwarKHh4SErAufe

    Project Description ๐Ÿ“„โ€‹

    We want to make it simple to create and build Android and iOS game projects and connect them with Substrate blockchain. Currently, setup build of rust game project with basic requirements (like 2D/3D rendering, sounds, touch events, textures, etc) for iOS and Android is a pretty hard task. So a lot of developers don't start projects on top of rust-lang game engines because of uncertainty that they will be able to publish them to Google Play and App Store. We want to change this situation and make sure that anybody will be able to create, build and publish their mobile games to the marketplaces. Make this process simple yet reliable.

    Also, we are extremely excited about decentralized games and what kind of games can be created with this idea in mind! Substrate blockchain framework is ideal for this as it can provide forkless updates, smart contracts, light client and so much on. We plan to create a setup for mobile development first, build a Substrate light client in mobile app and connect it to Substrate full node (or make a connection via JSON-RPC). Make sure that we can subscribe to data and send extrinsics to any Substrate based network. So that anybody from community of Polkadot will able to create own game projects, build for mobile platforms and publish them.

    There are already plenty of interesting game engines made with rust-lang (e.g. Piston, Amethyst, BevyEngine. But we don't want to make it possible to build only with one specific rust game engine so we will do this framework game engine agnostic as much as possible.

    Pros for Polkadot Ecosystem:

    1. We will setup mobile development environment - community of Polkadot will be able to create own mobile game projects on top of it. This is also very useful for rust game development community.
    2. We will create integration and communication with substrate node and make sure that it runs on mobile platforms flawlessly.
    3. The community of Polkadot will be able to set up their own substrate-based game projects in a matter of minutes.
    4. The first decentralized mobile game on top of the Substrate.

    After the finish of this project, our team wants to create a mobile strategy game with all backend logic in Substrate. So this project important step forward decentralized mobile game on top of the Substrate.

    Team ๐Ÿ‘ฅโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 12 weeks
    • Full-time equivalent (FTE): 2.0
    • Total Costs: 2.5 BTC

    Milestone 1 - Create setup for Android (parallel milestone 3)โ€‹

    • Estimated Duration: 4 weeks
    • FTE: 2.0
    • Costs: 1.0 BTC
    NumberDeliverableSpecification
    1.Project on AndroidSetup basic project and Android Application build and run it on Android device and emulator.
    2.Working app with Rust code insideLink rust code to Android application.
    3.Basic app UI, working touch events and storage accessAdd touch events, storage access for game assets (textures, images, sounds, etc) and simple UI for Android Application.
    4.Substrate inside Android appBuild Substrate light client (or JSON-RPC API client) for Android Application.
    5.Connection to Substrate network from appAdd connection from rust code in app to the Substrate network.
    6.Blockchain explorerAdd simple blockchain explorer to Application for showcase of working Substrate connection side.
    7.CI and testsAdd Github CI for automatically build and test Android application.
    8.DocumentationWrite documentation to create and build similar applications for Android.

    Milestone 2 - Create setup for iOS (parallel milestone 3)โ€‹

    • Estimated Duration: 4 weeks
    • FTE: 2.0
    • Costs: 1.0 BTC
    NumberDeliverableSpecification
    1.Project on iOSSetup iOS Application build and run it on iOS Simulator.
    2.Working app with Rust code insideLink rust code to iOS application. Make it work with Xcode-compatible iOS bitcode.
    3.Basic app UI, working touch events and storage accessAdd touch events, storage access for game assets (textures, images, sounds, etc) and simple UI for iOS Application.
    4.Substrate inside iOS appBuild Substrate light client (or JSON-RPC API client) for iOS Application.
    5.Connection to Substrate network from appAdd connection from rust code in app to the Substrate network.
    6.Blockchain explorerAdd simple blockchain explorer to Application for showcase of working Substrate connection side.
    7.CI and testsAdd Github CI for automatically build and test iOS application.
    8.DocumentationWrite documentation to create and build similar applications for iOS.

    Milestone 3 - Create generic framework, documentation, tutorials and examplesโ€‹

    • Estimated Duration: 4 weeks
    • FTE: 2.0
    • Costs: 0.5 BTC
    NumberDeliverableSpecification
    1.Simple interface of creation of Android and iOS projectsEncapsulate logic and pipeline of building for Android and iOS as much as possible.
    2.Templates for Android and iOS projects to make it possible to create projects from it in one callCreate template Android and iOS platform projects to create new applications from them.
    3.CLI and build utilitiesMake utilities to make it possible setup build in matter of minutes.
    4.Support of CD with FastlaneAdd support of continuous delivery with Fastlane.
    5.Test Substrate network with test dataRun Substrate testnet with pallets and data that can be used in Applications.
    6.Documentation, tutorials and example projectCreate detailed documentation, tutorials and example projects (with connection to substrate node) for the project.

    Future Plansโ€‹

    • We want to create a mobile game in a military-economic strategy genre with Substrate blockchain. Then publish our game to Google Play and App Store. Continue to develop and polish it.
    • Integrate non-fungible tokens (NFT) in our game world in the form of game items. Also, add ability to create and deploy smart contracts by players to enhance their base or automate things. Run mainnet and connect to Polkadot as a parachain.
    - + \ No newline at end of file diff --git a/applications/mobile_dapp_connection.html b/applications/mobile_dapp_connection.html index 29f5026dbfa..b31b76e2b64 100644 --- a/applications/mobile_dapp_connection.html +++ b/applications/mobile_dapp_connection.html @@ -4,13 +4,13 @@ Polkadot/Substrate dApps/Wallet Connection using Tesseract | Web3 Foundation Grants - +
    Skip to main content

    Polkadot/Substrate dApps/Wallet Connection using Tesseract

    Project Descriptionโ€‹

    The goal of this proposal is to enhance the usability and security of Polkadot/Substrate native mobile applications (the ones in AppStore and Play Market). By enabling the apps to connect to the wallets when a signature for a transaction is needed, we propose to get rid of a cumbersome and potentially insecure private key handling burden.

    To achieve this goal, we propose to implement Tesseract (dApps/wallets connection) protocol for Polkadot/Substrate.

    Why Tesseract is good for the ecosystemโ€‹

    iOS and Android are (arguably) the most popular app platforms today. With smooth experience and high security provided by Tesseractโ€™s capability to eliminate private key handling, the dApps could more easily match the expectations of an application from AppStore or PlayMarket, thus leading to lesser friction in dApps adoption.

    How Tesseract integrates into Substrate/Polkadotโ€‹

    Once implemented, any Polkadot/Substrate native mobile dApp developer will be able to add Tesseract support with just several lines of code.

    As an example, this is how our integration currently works in Swift for the Ethereum network:

    import Tesseract

    // Check that we have a wallet installed. You should handle this situation in your app.
    guard Tesseract.Ethereum.isKeychainInstalled else {
        fatalError("Wallet is not installed!")
    }

    // Our HTTP RPC URL. Can be Infura
    let rpcUrl = "https://mainnet.infura.io/v3/{API-KEY}"

    // Creating Web3 instance. Try to reuse the existing instance of Web3 in your app.
    let web3 = Tesseract.Ethereum.Web3(rpcUrl: rpcUrl)

    For more information, please check: https://github.com/tesseract-one/Tesseract.swift

    Our current implementation of the reference wallet for iOS, supporting Ethereum can be found here: https://apps.apple.com/us/app/tesseract-wallet/id1459505103. We plan to approach Tesseract supporting Polkadot wallet with a consequent separate proposal. Itโ€™s either going to be a reference wallet implementation or integration with some existing Polkadot wallets.

    How is Tesseract different?โ€‹

    Since the deliverables of this proposal are mobile-specific, but Tesseract is so much more than just a solution for mobile dApps and weโ€™d like to share this aspect as well. We've split this section into two parts: the first answering the question specifically about mobile and the second covering a more general comparison of Tesseract's approach.

    How is Tesseract different on mobile?โ€‹

    The short answer to this question is that Tesseract can provide a potentially more familiar mobile UX due to deeper integration with the underlying OS, by utilizing OS native IPC (Inter-Process Communication) protocol.

    To demonstrate the advantages of our approach, letโ€™s first briefly cover the other options available:

    • Key inside the dApp - not really an external signature provider, as the app manages the private key inside. Worth mentioning, as quite a number of native mobile dApps use this approach. The user just has to copy the private key into the dApp. Simplest, but raises security concerns and the usability is questionable.
    • Centralized proxies - centralized custodial wallet solution for decentralized applications. Example: Fortmatic
    • URLs (aka deep-linking) - allows jumping between applications on smartphones using special URLs. This way a dApp can switch to the wallet by forming a request in a URL form and receive a response from the wallet switching back the same way. This approach works to a limited extent, suffering from routing problems (especially on iOS) and canโ€™t support multiple wallets without a 3rd party router (or a maintained list of supported wallets matched to their unique URLs). On iOS, if more than one application can open a URL, the app is chosen randomly which rises a security concern. From the UX standpoint, it looks like the apps are switching back and forth. Deep-linking is sometimes used together with relays (see below).
    • Centralized signing relays - allows a mobile wallet to sign transactions using centralized servers as connection relays. Usually works together with a deep-linking handshake, inheriting its issues and behavior (iOS routing issues, app switching UX). Also, such a solution canโ€™t be considered optimal, due to the fact that two apps running on the same device have to communicate through a server somewhere on the internet. Examples: WalletConnect, WalletLink
    • Decentralized signing relays - this approach works similarly to Centralized signing relays, except that p2p mesh is used instead of a centralized relay server. Examples: Beacon

    In contrast, Tesseractโ€™s transport on smartphones is based on another technology, deeply integrated into the underlying OS - inter-process communication (IPC). This way we have managed to achieve a convenient UX. The behavior is centered around modal screens, which are quite widely used in various applications (please, check our demo: https://drive.google.com/file/d/17YMdJS9CH6SXqP-YPUMKbm0BWdAE2Rx3/view). There is no central authority and the data goes through the shortest route - communication is done point to point between two processes running on the same device. It works equally well on both iOS and Android without any dApp/Wallet routing issues (the user can pick the wallet to use for a signature). As for security - after extensive testing, we have not found any ways to hijack a transaction so far.

    The table below summarises our comparison considerations, demonstrating why we have decided to utilize the IPC protocol instead of something else:

    Transport\CriteriaUniversal (iOS and Android)SecureConvenient (from a usability standpoint)DecentralizedOptimal (shortest data path)
    Key inside the dAppโœ…โŒ because of giving away the private key to a 3rd party dAppโŒ the user has to copy/paste private keysโœ…โœ…
    Centralized proxiesโœ…โš ๏ธ controversial, due to the inherent custodial mechanismโœ…โŒ custodial walletโŒ data has to go through the internet to facilitate a local transfer
    URLsโš ๏ธ has routing issues on iOS. Can be solved either by maintaining compatible wallets list (in code? On a server?) or through a 3rd routing applicationโš ๏ธ Due to random selection of the app matching the URL on iOS has a potential spoofing vulnerabilityโœ… explicit app switching behaviorโœ…โœ…
    Centralized signing relaysโš ๏ธ inherits deep-linking issues as itโ€™s used for handshakeโš ๏ธ inherits deep-linking issues as itโ€™s used for handshakeโœ… same as deep-linking (if the deep linking handshake is used) or manual (if not)โŒ uses central servers as relaysโŒ data has to go through the internet to facilitate a local transfer
    Decentralized signing relaysโš ๏ธ inherits deep-linking issues as itโ€™s used for handshakeโš ๏ธ inherits deep-linking issues as itโ€™s used for handshakeโœ… same as deep-linking (if the deep linking handshake is used) or manual (if not)โœ…โŒ data has to go through the internet to facilitate a local transfer
    IPC (Tesseract)โœ…โœ…โœ… modal screens, OS integrated wallet selectionโœ…โœ…

    How is Tesseract different beyond mobile?โ€‹

    Tesseract protocol was designed adaptable to existing and new potential use cases through flexibility provided by multi-transport (IPC, socket, QR-code, etc.) architecture, in contrast to its single-transport protocol counterparts. While some transport protocols can shine in one scenario, a totally different approach may be needed for another. There are a number of known (and probably quite some yet-to-be-discovered) use cases of how dApps and wallets may need to interact. Some common examples are:

    • A dApp and a wallet run on the same smartphone
    • A dApp and a wallet run on the same desktop
    • A dApp runs on the desktop and a wallet runs on a smartphone
    • etc.

    Here is a short table, that summarises the comparison of some common transport protocols versus the use cases. While there are way more use cases than the table covers, the ones included are sufficient to showcase that neither transport is capable of covering all the use cases by itself. Also, here we show only transports that are not compromising decentralization.

    dAppMobileDesktopDesktopMobile
    WalletMobileMobileDesktopDesktop
    DescriptionA very common scenario, when both the dApp and the Wallet run on the same smartphone.Another common scenario, when a dApp runs on a desktop computer and the wallet is on the smartphone.A scenario when a user needs to run a dApp and the wallet on the same desktop computer.This case covers a dApp running on the phone and the wallet on a desktop.
    IPCโœ… Direct dApp/Wallet interaction. Native platformโ€™s look and feel.โŒ By definition works only on the same device.โœ… Direct dApp/Wallet interaction.โŒ By definition works only on the same device.
    Deep-linkโš ๏ธ Direct dApp/Wallet interaction. Apps switching behavior. Has routing issues on iOS.โŒ By definition works only on the same device.โš ๏ธ Can work to an extent how well the OS supports deep linking.โŒ By definition works only on the same device.
    Network (direct socket connection)โŒ Potentially can work on Android, especially with a deep-linking handshake. Problematic on iOS: background sockets are against Apple guidelines.โœ… Works best when both devices are on the same WiFi. Needs a QR-code or NFC handshake.โœ… Works well as the desktops donโ€™t set any limitations on sockets in the background. To avoid routing problems can be used together with a separate handshake (i.e. deep-linking).โœ… Works best when both devices are on the same WiFi. Needs a QR-code or NFC handshake.
    Network (p2p)โš ๏ธ Can work, though requires an internet connection for communication that is actually between apps on the same device, which is not ideal. Requires a deep-linking handshake.โœ… Works best for situations when devices are not in close proximity and donโ€™t share the same WiFi. Needs a QR-code or NFC handshake.โš ๏ธ Can work, though requires an internet connection for local communication, which is not ideal.โœ… Works best for situations when devices are not in close proximity and donโ€™t share the same WiFi. Needs a QR-code or NFC handshake.
    QR-codeโš ๏ธ Can potentially be made to work, though would require image copy-pasting, which is not an ideal UX.โœ… Best use - a handshake mechanism for another transport. Even though technically it can work by itself if both devices have cameras, itโ€™s not an ideal UX.โš ๏ธ Can potentially be made to work, though would require image copy-pasting, which is not an ideal UX.โš ๏ธ While it technically can work, might provide an awkward experience to the user turning screens of large devices into the cameras of each other.
    Bluetooth/NFCโŒ By definition works only with separate physical devices.โœ… Works best for devices in close proximity, especially if a shared WiFi is not an option.โŒ By definition works only with separate physical devices.โœ… Works best for devices in close proximity, especially if a shared WiFi is not an option.

    Since none of the transport protocols are universal enough to be an optimal choice for every use case, weโ€™ve designed Tesseract to be non-constrained by this factor. Instead, Tesseract can use any implemented transport protocol, based on the scenario and/or the userโ€™s choice, due to its layered architecture. The following diagram demonstrates a simplified architecture of the Tesseract protocol:

    Architecture of Tesseract

    This way, Tesseract can potentially handle any known or future use case to the extent the most matching transport can, which is not an available option for the single-transport bound solutions.

    Why our Team is interestedโ€‹

    As we indicated in our first proposal, which was awarded and currently coming to the end (Swift API), that our long term goal was to bring Tesseract support to the Polkadot community.

    The Swift API library from our first proposal was an essential step for us, as Swift is the programming language of iOS and we need this to implement Tesseract support for Polkadot/Substrate on iOS. Since we are finishing with the first grant application, we have prepared the current proposal to continue the integration process of Tesseract into Polkadot/Substrate ecosystem.

    Team membersโ€‹

    • Daniel Leping, @dileping on GitHub, CEO
    • Yehor Popovych, @ypopovych on GitHub, CTO

    Team Websiteโ€‹

    https://tesseract.one

    Team's experienceโ€‹

    Our team has been building blockchain applications since 2017 and has worked together on Tesseract since 2018. The company got funded by SOSV and Emurgo in 2019 and took training in the dlab acceleration program.

    This is our second grant application for Polkadot. Previously, we were awarded to build Polkadot/Substrate Swift SDK.

    Prior to blockchain technology, we had a wealth of experience in Swift, building applications, and middleware. The most noticeable projects are Swift Express, Reactive Swift.

    The team has a 10-year history of working together, delivering various solutions of high complexity, including the mentioned above Swift Express and Reactive Swift, Cross++ ( cross-platform framework in C++ that allowed to keep the app logic shared while providing the capability to use native UIs) and tens of the web, mobile, and server applications for customers from around the world including the US, EU, Israel, Australia, etc.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Tesseract Overviewโ€‹

    The main goal of the Tesseract protocol is to enable dApp developers to provide a smooth and easy-to-understand user experience without compromising privacy and decentralization. Being a protocol that allows dApps to run without having access to the user's private key, Tesseract facilitates communication with the Wallets to request transaction and data signatures, thus providing a possibility to get rid of private key handling and having a look and feel of a โ€œnormalโ€ application.

    Before digging into the technical details, we want to share the โ€œfeelโ€ of how the Tesseract-based dApps work: https://drive.google.com/file/d/17YMdJS9CH6SXqP-YPUMKbm0BWdAE2Rx3/view.

    Such a user experience is achieved by having a seamless connection between the dApp and the wallet via Tesseract protocol.

    Even though mobile is the first focus, Tesseract is not limited to being the mobile-only solution. It can maintain the connection between dApps and wallets working in various environments: smartphone, desktop, or even crossing the border of a single device (i.e. a dApp runs on the computer and the wallet is on the smartphone). This is achieved by having a layered architecture, that depending on the current environment, allows using a suitable transport protocol.

    Tesseract protocol does not require a server to keep the keys. All the requests are done directly to the wallet application through IPC (if the device is the same) or other p2p communication protocol (if cross-device).

    Tesseract Architectureโ€‹

    Tesseract protocol is designed from the perspective of flexibility to make it adaptable for various scenarios. To achieve this goal, Tesseract uses a layered structure in its core and messages, that are enveloped according to the protocol layer.

    The layers-based implementation is largely inspired by the OSI model (the model of network protocols).

    Layered structureโ€‹

    As mentioned above, Tesseract has a layered structure. The basic three layers are:

    • Application Layer - responsible for communication via specific protocol (i.e. Polkadot): transaction signing request, messages signing, public key requests - all here.
    • Presentation Layer - provides enveloping of application-specific data into transportable packages. Defines text/binary packet structures transferrable via any underlying transport.
    • Transport Layer - implementation of various transport types. IPC, p2p NFC, URLs, QR-codes, Bluetooth, etc.
    Application Layerโ€‹

    The application layer can be anything, depending on the specific network plus Tesseractโ€™s application-layer protocol for controlling connection establishment, checking the presence of other application-layer protocols, etc.

    Tesseract application-layer protocolโ€‹

    Tesseractsโ€™ application layer API is responsible for the following:

    • Checking the presence of specific application-level protocol extensions
    • Event subscription
    • Inter-device connection initialization
    Polkadot application-layer protocolโ€‹

    This is the part where Polkadot gets integrated:

    • Signing data
    • Signing transactions
    • Public key querying

    From the perspective of the dApp developer - nothing changes. The developer still uses the same familiar Polkadot APIs. The only difference is that when Tesseract is integrated as a signature provider, the transactions are rerouted to an external wallet for signing, and then sent back to the dApp.

    Presentation Layerโ€‹

    The presentation layer defines how the data is enveloped to be properly delivered to the destination. The current implementation uses JSON text messages (the easiest to debug and has great support in various platforms). Binary is a future consideration.

    Transport Layerโ€‹

    This layer is what makes Tesseract so flexible and allows it to work in various environments. It determines how exactly the dAppโ€™s requests packets are transferred to the wallets and how the wallets reply. By having multiple options of the transports, the dApps can communicate to the wallets located anywhere: on the same device or not. Communication between devices can be pretty much anything that can transfer data (TCP/IP, Bluetooth, NFC, etc.). For the current proposal though, we want to limit the number of transport layers implementations to the following:

    • iOS IPC
    • Android IPC

    By implementing the above transfer protocols, we already allow developers to create native mobile dApps that donโ€™t have to carry a private key. While more protocols bring more value, this way we can release the first version sooner and go to market sooner with a concrete value proposition.

    In the future, we plan to implement protocols that allow inter-device communication. Possible options for the near future include:

    • QR codes/(NFC) - mainly for a persistent connection initialization, especially in trustless environments
    • WebRTC - potentially the best option for browsers
    • TCP/IP - easier to implement for desktop apps then WebRTC
    • Bluetooth - browsers/between devices

    Tesseract Implementationโ€‹

    The implementation of Tesseract, pretty much like any other protocol, is a set of libraries that allow applications to communicate through it. In the case of Tesseract, there are two sets of libraries: one for the dApps (allows querying the wallets) and one for the Wallet (allows replying to the signing requests).

    Currently, Tesseract has a partial implementation in Swift and works on iOS: https://github.com/tesseract-one/Tesseract.swift.

    For the sake of having a single cross-platform implementation (fewer bugs, single codebase), we propose to implement it in Rust and add language-specific wrappers in the future (i.e. Swift, Java, ReactNative, etc.).

    For the details on the proposed implementation, please refer to the Development Roadmap section.

    Development Roadmapโ€‹

    Milestone 1: Cross-platform Tesseract Core in Rustโ€‹

    Duration: 8 weeks

    This is the very foundation of the Tesseract protocol.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDocumentation for Tesseract Core:
    1) overview with usage examples
    2) messages and envelopes structures
    3) APIs for application and transport level with examples
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerDue to the client-side nature of the deliverable, there is no need for a docker image.
    0e.ArticleWe will publish an article that explains the value Tesseract brings to the dApp developers and how Tesseract Core serves as a foundation for all future work.
    1.ArchitectureRepository with overall code structure. Serves as a framework for all the further development. Defines the layered structure and contains all the code that makes the layers (details below) to work together
    2.Application-level frameworkDefines how application level calls are formed as data structures and passed down to the next layer
    3.Messages and envelopesImplements serialization and envelopes for the app level structures + parsing and identification on the other side
    4.Transport-level frameworkTransport level abstractions, interfaces, data flow + transport initialization and selection logic
    5.Transport-layer development APIsAPIs for transport protocol (IPC, socket, etc.) development. Will have two transport types: persistent, single-shot
    6.Application-layer development APIsAPIs for application level stuff development (i.e. Tesseract handshaking and transport selection, Polkadot APIs)

    Milestone 2: Platforms and Polkadot/Substrate Supportโ€‹

    Duration: 6 weeks

    This milestone is based on the foundation built in Milestone 1 and focuses on platform-specific transport extensions (iOS, Android) and Substrate integration.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide:
    1) README-type documentation for substrate-specific application-level APIs with examples
    2) Rust API docs for substrate-specific application-level APIs
    3) instructions on how to build and run the test apps for both iOS and Android
    0c.Testing GuideSubstrate application layer will be fully covered by unit tests for both dApp and Wallet sides with a mock transport. For the IPC transport, we will provide test apps for both iOS and Android.
    0d.DockerDue to the client-side nature of the deliverable, there is no need for a docker image.
    0e.ArticleWe will publish an article that describes how to start using Tesseract in Substrate applications. It's a continuation of the article from Milestone 1 and will tease part3, promising more examples and details.
    1.iOS IPC transport protocol implementationImplementation of IPC transport for iOS. Code is tested with small test app on an iOS device.
    2.Android IPC transport protocol implementationImplementation of IPC transport for Android. Code is tested with small test app on an Android device.
    3.Substrate protocol specificationMarkdown-based documentation that provides details of workflows and messages required for proper substrate-based calls handling and transaction signing. This is separate from the main documentation and is a detailed description of the protocol to be implemented in the following step.
    4.Substrate protocol implementation1) implementation of Substrate application layer
    2) substrate-specific application-level APIs

    Milestone 3: Demo applicationsโ€‹

    Duration: 6 weeks

    To demonstrate the capabilities of Tesseract, we would like to provide easy-to-understand examples. These examples should be fully working (even though very basic and not intended for production use) and capable to showcase the capabilities to an unfamiliar audience.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide:
    1) README-type documentation describing the key aspects of how the test applications work
    2) instructions on how to build and run the test apps for both iOS and Android
    0c.Testing GuideWe will provide a guide how to build and run the apps.
    0d.DockerDue to the client-side nature of the deliverable, there is no need for a docker image.
    0e.ArticleWe will publish an article (part3) that covers more details about the integration of Tesseract into Substrate dApps and wallets. The article will also cover some of our plans, specifically - java and swift libraries integration.
    1.Android Demo WalletAndroid Wallet test application with logic implemented in Rust, which demonstrates how a wallet can sign substrate transactions using the Rust APIs.
    2.Android Demo dAppAndroid test dApp with logic implemented in Rust, that demonstrates transaction creation and signing through Tesseract via test wallet. The transaction is submitted to test-net after being signed.
    3.iOS Demo WalletiOS Wallet test application with logic implemented in Rust, which demonstrates how a wallet can sign substrate transactions using the Rust APIs.
    4.iOS Demo dAppiOS test dApp with logic implemented in Rust, that demonstrates transaction creation and signing through Tesseract via test wallet. The transaction is submitted to test-net after being signed.

    Future Plansโ€‹

    The long-term vision for Tesseract is to be a safe, secure, and user-friendly way for any application to access a userโ€™s wallet and private keys, on as many blockchains as possible.

    At the moment, though, we want to bring the details about the next short-term steps, that we believe are essential for the project to start bringing traction.

    The next immediate step is making the use of Tesseract protocol easy for the Polkadot developers, which requires integration with the ecosystem. Specifically integration with:

    This will enable Mobile developers to start using Tesseract without any additional tools switching. Just adding a couple of lines of code for initialization.

    Simultaneously, we are going to deal with the wallet side by either providing a reference wallet implementation or by integrating with the existing Polkadot wallets (TBD).

    Conclusionโ€‹

    The quest for a better dApp signature provider is not new and there are quite some approaches. All the solutions have their pros and cons, but none are universal, secure, and decentralized at the same time.

    Tesseract was designed with the idea that itโ€™s not enough to solve one of the problems or to provide a limited number of use cases. We believe that to break the dApps adoption barrier, there must be a solution that is universal, secure, usable, and decentralized at the same time.

    Tesseractโ€™s Github: https://github.com/tesseract-one/

    Tesseractโ€™s implementation in Swift: https://github.com/tesseract-one/Tesseract.swift

    Tesseractโ€™s reference wallet: https://apps.apple.com/us/app/tesseract-wallet/id1459505103

    Demo video: https://drive.google.com/file/d/17YMdJS9CH6SXqP-YPUMKbm0BWdAE2Rx3/view

    Our previous proposal (Substrate/Polkadot Swift API): https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/swift_api.md

    Our previous proposal codebase: https://github.com/tesseract-one/Substrate.swift

    - + \ No newline at end of file diff --git a/applications/multisignature_management_tool.html b/applications/multisignature_management_tool.html index 3dab1aaa803..2b246639f1a 100644 --- a/applications/multisignature_management_tool.html +++ b/applications/multisignature_management_tool.html @@ -4,13 +4,13 @@ multisignature_management_tool | Web3 Foundation Grants - +
    Skip to main content

    multisignature_management_tool

    Multi-signature_Management_Toolโ€‹

    • Proposer: Hong Tao
    • Payment Address: 3P1DGw78xgkQ2pTPT1hcwmzozY1T93gmTB

    Project Descriptionโ€‹

    When we developed and used the multi-signature feature, we found that there is no multisignature wallet tool that can be used conveniently. The current wallet project is mainly designed for different usage environments, such as mobile wallet app, web wallet, chrome extension, etc. The development of these wallets (except the polkadot.js app) is at an early stage, and lack of multi-signature module . Polkadot.js apps is a very powerful tool, however the user experience and interface of substrate's native multi-signature module integrated in polkadot js is not friendly enough.

    Therefore, we want to develop a Web Multisignature Management Tool (like gnosis based on Ethereum), implement a Substrate multisignature Portal and Web Tool integration, and bring users a better experience. Besides, subscan will support multisig Extrinsic details display. At current stage, our goal is offering users have a convenient multisignature tool and helping developers reduce the development cost of similar functions.

    • Network scalability

    All chains built on substrate as_multi module can use our tools to complete related operations directly. The chain that changes the as_multi module can use our UX design partly or completely according to their needs to reduce the development cost.

    • Platform scalability

    The web Multi-signature Management Tool can only run on PC and use it with extension programs.

    Objectivesโ€‹

    • Create multi-signature account and send extrinsic
    • Manage multi-signature wallets and extrinsic
    • as_multi Module subscan browser adaptation
    • Support multiple networks that are based on Substrate development
    • UX optimization

    Team membersโ€‹

    Wan Bei, Hong Tao

    Shanghai Yitaiyuan Tech

    Team Websiteโ€‹

    https://www.subscan.io/

    Team's experienceโ€‹

    Our team is based in Shanghai and Nanjing. We are very interested in substrate and we have done a lot of related development work, such as helping Darwinia build web wallet.

    But our focus has always been Subscan blockchain explorer, which keeps it updated quickly.

    Team Code Reposโ€‹

    https://github.com/itering/subscan

    https://github.com/itering/subscan_ui

    Development Roadmapโ€‹

    Basic function: generate Multisig account and send Extrinsicโ€‹

    • General UI design (in Figma)
    • backend design doc(in Notion, in Google Docs)
    • Integrate with polkadot js extension
    • Multisig wallet creation and management
    • Basic Multisig Extrinsic(transfer) create and process in Multisig wallet
    • Multisig wallet support polkadot mainnet
    • Build user-friendly UI to list decoded call data with its hash for users who participated in the multi-signatures, data will be verified by hash on frontend
    • Use database or other backend service to store the index data.
    • Docker Files and Images
    • Unit tests and integration test
    • Tutorials

    Total for worker implementation: 25 days

    Budget: 1 BTC

    Advanced function: more features for multisig wallet and support more networkโ€‹

    • Multisig wallet support more kinds of Extrinsic such as staking, Democracy
    • Support kusama ,Darwinia and other network which base on Substrate 2.0
    • Docker Files and Images
    • Unit tests and integration test
    • Tutorials

    Total for worker implementation: 30 days

    Budget: 1 BTC

    Total Budget: 2 BTC.

    - + \ No newline at end of file diff --git a/applications/mybank.html b/applications/mybank.html index 6ea7c1cb3bb..5b0db7f9e9d 100644 --- a/applications/mybank.html +++ b/applications/mybank.html @@ -4,13 +4,13 @@ MyBank Network | Web3 Foundation Grants - +
    Skip to main content

    MyBank Network

    • Team Name: MyBank Labs

    • Payment Address(DAI): 0xd2884f29b1aE21Cd88c51068f2C81060B58ddC1e

    • Status: Terminated

    Project Overviewโ€‹

    Overviewโ€‹

    MyBank is a decentralized financial platform based on Polkadot, aiming to establish a blockchain network that realizes asset appreciation and promotes asset flow. MyBank is divided into four parts: Platform Bank, Social Network Bank, MyDeX and Credit Scoring System.

    • In Platform Bank, users can participate as depositors, borrowers, and guarantors. Depositors can obtain deterministic returns by injecting liquidity into the corresponding asset pool. Borrowers can borrow by mortgaging collateral or invite guarantors to guarantee them to make zero-mortgage loans. After the implementation of the credit scoring system, credit loans without collateral or guarantee will be supported based on the user profile.

    • In Social Network Bank, MyBank as an infrastructure platform provides corresponding tools so that any individual and organization can build a collective bank that belongs to all members of a social network.

    • MyDeX aims to provide users with the service of AMM, and support users to participate in the liquidation of Platform Bank.

    • We will develop a credit scoring system based on users' deposit records, loan records, guarantee records, transaction records, social networks and third-party data to generate user profile.

    Project Detailsโ€‹

    Platform Bankโ€‹

    Most DeFi lending products are based on the mortgage system. Users lend assets from the asset pool by mortgaging collateral. We try to go further on this pattern. While providing mortgage lending services, we will release the liquidity of the depositor's assets and provide zero mortgage services. Depositors can use their deposit certificates to guarantee loans for friends, and friends can make zero mortgage loans on the platform based on the guarantee certificates. During the guarantee process, the guarantor's deposits will continue to generate income and will not be affected.

    Each user will maintain a social network circle of their own, and the friend relationship needs to be confirmed by both parties. When a user has a loan demand and wants to choose a zero-mortgage loan, he can send the loan event to his friend's inbox, and the friend can choose to respond to the event to guarantee him. After the guarantee is successful, the system will issue a loan to his friend, and the deposit certificate will be locked by the system. Before the borrower repays, unless the guarantor chooses to pay a certain amount of funds to redeem the deposit certificate, his deposit will not be withdrawn.

    image-20210429161048216Platform Bank supports multi-currency digital assets as collateral for loans or guarantees. Each type of asset corresponds to different risk parameters according to its risk coefficient. In the future, MB Token holders can vote on the adjustment of the parameters, and the proposal passed by the referendum will be automatically executed by substrate runtime.

    • Liquidation Ratio Each loan that occurs in the PB will correspond to a collateral-to-debit ratio. Each type of asset will have a corresponding liquidation ratio according to its market value and volatility, and the system will monitor the collaterals-to-debit ratio of each loan. Once the collaterals-to-debit ratio is lower than the liquidation ratio, it will trigger liquidation behaviour. Assets with a higher risk coefficient usually correspond to a larger liquidation ratio and vice versa.

    • Interest Rates Determine the annualized rate of return of depositors, the borrowing cost of borrowers, and the size of the asset pool, and at the same time affect the risk of the system. The interest rate is determined by supply and demand. When the utilization rate of the asset pool is low, users will be encouraged to borrow through low-interest rates. When the utilization rate of the fund pool is high, the interest rate will increase to encourage users to repay the loan and attract depositors to provide liquidity to the asset pool through higher yields. Each asset pool will set a critical point, and the loan interest rate will increase faster after the utilization rate of the asset pool exceeds the critical point.

    • Insurance Fund MyBank has set aside a part of MB Token as insurance funds. When the Black Swan incident causes unexpected situations, MyBank will take part of the assets from the insurance fund to compensate users for losses. MyBank will charge depositors a certain percentage of handling fees and this part of funds will be combined with insurance funds.

    We will expand Platform Bank to support credit loans. The user's social networks, deposit records, loan records, guarantee records, and transaction records will all be stored on the chain to form an anonymous credit scoring system. The credit data accumulated by users combined with off-ch governance has brought the possibility of developing credit loan business. Credit loans need a strong governance organization, relying on the relevant identity authentication system and legal system. In the first stage, the credit loan business will be launched through the Private Pool and will only be open to financial institutions and enterprises that have passed the off-chain review.

    Institutions can also pay a certain fee to create an independent Private Pool to develop loan business based on the infrastructure provided by MyBank. For example, the identity on the chain is an anonymous hash address. With the user's permission, the institution can verify the user's identity under the chain, and combine the credit score record to decide whether to issue a credit loan or mortgage loan to the user. The loan contract will be written to MyBank's distributed ledger. Loan records incurred by Private Pool can also be synchronized to the credit scoring system.

    img

    Social Network Bankโ€‹

    We try to integrate the advantages of blockchain, social network and collective governance to establish a brand-new collective bank to improve the utilization rate of funds and realize inclusive finance. Anyone can build a digital bank of their own through the blockchain infrastructure provided by MyBank. The bank will be governed by the users and MyBank will not intervene. The governance of each bank will be the responsibility of all users of the bank. As a bank based on social networks, members have real social relationships under the chain.

    Members can contribute deposits to the bank. The more deposits, the greater the contribution to the bank. Deposit contributions will be recorded on the chain, and depositors will not only gain wealth but also reputation. The deposit records contributed by members are visible to other members. In the future, when they need loans, loan applications will be easier to pass. The more people they helped in the past, the greater the probability of getting help from others in the future.

    Repayment of a loan will leave a record on the chain. Borrowers will have a greater chance to obtain larger loans in the future, indirectly encouraging users to gradually accumulate their credit history. All behaviours will be recorded on the chain. Based on the external constraints of social networks, the default will affect the reputation of individuals in the real life. And borrowers will not be able to obtain loans from the bank in the future or it will become more difficult to borrow. Loans can be based on joint and several liabilities. If a person fails to repay the loan, the credit history of the members who guarantee or vote for it will also be affected. It may be regarded as a default, so the borrower's friends have an additional incentive to help the borrower.

    image-20210430143053169

    MyBank abstracts the user's demands into corresponding events, and the event is decided by the collective or the committee. Users can set the governance of the bank by themselves.

    Users can select a committee to govern. The committee members are elected by all members, and all members also have the right to initiate a referendum to remove a committee member. The management of the bank will be fully represented by the committee, and each event requires the consent of a certain proportion of the committee members before it can be executed. The event approved by the committee can be an automatic event, or it needs to be executed after a while. If all members reject the event by referendum, the event will be automatically removed. The committee member can choose to pledge a certain amount of assets to obtain more nomination votes. If the committee member acts against the interests of other members of the bank, other members can initiate a referendum to confiscate the pledged assets of the committee member.

    Users can also choose collective governance. Each event requires the consent of a certain proportion of all members before it can be executed. Or users can combine the advantages of committee governance and collective governance to conduct mixed governance, and choose a balance between efficiency and democracy. For example, a loan event requires a collective decision, and a deposit event can be decided by the committee.

    MyDeXโ€‹

    Any user can inject funds into the asset pool to obtain the transaction fee income. The equation for working out the price of each token is x*y=k, where the amount of XToken is x and the amount of YToken is y. K is a constant value.

    At the same time, users can pledge the LP Token to become a liquidator in Platform Bank, and can easily capture the income brought by liquidation while obtaining the transaction fee income. When the liquidation is triggered, the borrower needs to pay a certain percentage of the penalty fee, and the liquidator will receive this penalty fee.

    img

    MyDeX will integrate with Platform Bank to make it easier to short or long.

    • If a user is not optimistic that XToken will continue to rise in the future, he can choose to lend XToken at Platform Bank, then sell XToken in MyDeX to obtain stable coins, and redeem XToken to repay the loan when the price falls.

    • If a user is optimistic that XToken will continue to rise in the future, want to leverage. He can lends stable currency in Platform Bank, and then use the stable currency to obtain XToken in MyDeX, and sell XToken to redeem stable currency to repay the loan when the price rises.

    On the current Ethereum platform, if the above two operations are to be carried out, users need to jump and click multiple times between multiple DeFi products. On the front-end interactive page of MyBank, the above-mentioned operation users only need to click once, and the whole operation will be completed in one block, which is more convenient and has a faster execution speed.

    Credit Scoring System Explanationโ€‹

    Human beings are the total of social relations, and we should create a credit score system that does not need a third party or a central institution but is based on individual social relations.

    The structure and location of human networks determine everyone's choices in making friends, choosing schools, employment, financial management, raising children, leisure and entertainment. They also determine people's social circles and beliefs, as well as who is more powerful and influential and more likely to be successful. We quantified a personโ€™s 'position' in social networks, combined with a continuous "Proof Of Vote" to establish a completely digital blockchain credit system.

    Unlike trust models such as EigenTrust, the trust system is based on the fact that we can use homomorphic encryption to achieve anonymous scoring of any individual in social networks; and a person's centrality, eigenvector centrality, propagation centrality, intermediary centrality, etc. are used as weight factors; Burn mechanism of Coindays is used as another set of main credit evaluation factors.

    Anonymous Voteโ€‹

    In an interpersonal network, we should directly express our likes and dislikes, and should not be affected by identity, status, skin color, wealth, etc. In addition, we should digitize it and show it to the newly joined individuals in an intuitive way.

    Homomorphic encryption provides the technical foundation. Each vote will consume a certain amount of MB, and the cost of the vote will be directly related to Token, which will affect the opportunity to obtain Token in the future. We use the Burn mechanism of Coindays as a credit evaluation factor. In a vote, the value of destruction is positively related to the weight of the credit evaluation. When two accounts are trying to repeatedly trade to obtain the score of this weight, the first evaluation is valid, and at this time the accumulated Coindays have been destroyed. When the second vote is conducted, the accumulation of Coindays will be very small because it occurs shortly after the first transaction. Correspondingly, the contribution to the credit evaluation is very small, but a certain amount of MB tokens will be consumed as a handling fee. Similarly, when there are possible malicious bad reviews, because the credit evaluation is proportional to the destruction of Coindays, the amount of the transaction is too small, and it can hardly affect the user's credit.

    Social Locationโ€‹

    Social networks are different from other networks. We measure a person's position in society. At present, it mainly includes the following five aspects:

    1. The number of friends. We have created a new relationship network on the chain. To establish such a relationship, we need the consent of the other party and pay a certain fee. The existence of a hash algorithm naturally helps us avoid network storms. For possible abuse, we combine social science research similar to "Dunbar number". After the number of friends reaches a certain threshold, the cost will be greatly increased. Centricity is used to measure this indicator.
    2. The number of friends with high scores. Real-life experience tells us that it is necessary for a person to have many friends, and it is more important to have higher-quality friends. Although a person may not have many friends, it is usually more useful to have some "powerful" friends. We use the term eigenvector centrality to measure this indicator.
    3. The trust score on the chain should be closely related to the activities on the chain. As an extension of the AMM function, we hope to spread the demand in social networks, and the spreading individuals can charge a certain handling fee and earn a certain interest rate spread.
    4. There is a cost to forwarding requirements. When there are more friends to forward your requirements to help you achieve your requirements, we believe that your role in your network cannot be ignored. We use the degree of communication centrality to measure this indicator.
    5. The role of mediation cannot be ignored. In fact, with smart contract, combined with the trust subsystem, anyone can act as an intermediary. When a demand can only be propagated and matched through this individual, this role is crucial to both supply and demand.
    Directionality Of Transactionsโ€‹

    Another use of Coindays is to establish the weight of trust scores assessed by transfers. Usually, we will deal with transactions as equivalent transactions. In a transaction, one party's expenditure is equal to the other party's income. This is no problem in itself, but in the world of digital, it is necessary to convert scalars into vectors. In the process of trading, the system's Coindays are always destroyed, and the original ordinary transaction.

    UIโ€‹

    Homepage

    img

    Social Networks

    image

    Different colors represent different relationships, friends or not, vouch or not, one-way vote, obligatory relationships, etc.

    img

    Ecosystem Fitโ€‹

    Similar lending products on Ethereum include Compound & Aave, and AMM products include Uniswap & Sushiswap.

    • In Platform Bank, we will release the liquidity of depositors' assets to maximize their social guarantee value and provide borrowers with zero mortgage loans service. After perfecting the credit scoring system, we will support users to make credit loans.

    • Platform Bank and MyDex are developed based on Polkadot and Substrate, and users will pay fewer transaction fees and get higher TPS.

    • Based on Polkadot's cross-chain bridge, MyBank can provide users with more diversified choices.

    • MyBank integrates lending and trading, abstracting it into an interface at the front end. Users can conduct leveraged trading with one click, making it more convenient to long and short without switching between multiple products to obtain lower transaction delay.

    At present, there is no similar product to Social Network Bank(SNB) in the market. SNB is not only aimed at the existing DeFi user group. SNB is an inclusive finance platform, allowing most people, including poor groups, to enjoy the convenience brought by finance and blockchain.

    • Most of the existing lending product is based on asset collateral, but many poor people in the world do not have enough assets to mortgage, so they cannot obtain loans from financial institutions. MyBank will provide relevant digital tools based on the blockchain, so that poor groups can help each other and supervise each other based on their social networks.

    • At the same time, we will cooperate with charities to provide start-up funds for the user's bank. When charities choose to donate to a poor village, after the initial distribution, some funds can be reserved for the user's SNB. Members in the same social network know each other better than third-party financial institutions. SNB can invest this sum of money in the village's most capable people through collective governance. All members share the income as angel investors.

    Teamโ€‹

    Team Membersโ€‹

    • Amos - Full-stack Developer

    • Dean - Full-stack Developer

    Contactโ€‹

    Email: official@mybank.network

    Team's Experienceโ€‹

    Amos

    • Machine Learning Engineer(Big Data & Computer Version)

    • Rust And Substrate Developer

    Dean

    • Distributed Storage Engineer(FileCoin)

    • Rust And Substrate Developer

    Team Code Reposโ€‹

    https://github.com/mybank-network/mybank-network

    Team LinkedIn Profilesโ€‹

    1. Amos
    2. Dean

    Development Statusโ€‹

    Currently, we have finished the basic lending pallets and deployed a test network in polkadot.js.

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months

    • Full-time equivalent (FTE): 4

    • Total Costs: 8000 DAI

    Milestone 1 โ€” Implement Platform Bankโ€‹

    • Total Estimated Duration: 2 months

    • Full-time equivalent (FTE): 4

    • Total Costs: 8000 DAI

    NumberDeliverableSpecification
    0.LicenseApache 2.0
    1.aDocumentationThe documentation will be given to show the whole architecture of the Platform Network.
    1.bTesting GuideThe testing guide will be provided to test pallets and the front-end.
    2.aSubstrate Module: Asset PoolRealize the interface of deposit and debit. Support multi-currency lending. Automatically adjusts interest rates based on demand and supply. Support mortgage lending and guraantee lending. Implement Liqudation Module(off-chain worker).
    2.bSubstrate Module: User Profile & Credit ScoreGenerate user profiles based on the user's past deposit records, loan records, transaction records, and social networks.
    2.cSubstrate Module: Private PoolUsers can apply to create an private pool and inject liquidity to develop loan business.
    2.dSubstrate Module: Social NetworkUsers can friend someone on PB and send a guarantee request to a friend.
    3.Front End Of Platform BankComplete the development of the platform bank interactive page in react. The interface will be available in Chinese as well as English.
    4.Docker ImageWe will provide a dockerfile to demonstrate the full functionality of our chain.

    Future Plansโ€‹

    1. Build MyBank Community.
    2. Publish articles on media channels to expose the MyBank Network.
    3. Cooperate with ETH-bridge and BTC-bridge project.
    4. Support Kusama Node. The MyBank Network will run as a parachain of the Kusama.
    5. Implement WASM Smart Contract by using !ink.
    6. Develop credit loan module.
    7. Cooperate with third-party institutions to introduce users' off-chain assets into MyBank.
    8. Develop Social Network Bank after we implement Platform Bank and MyDeX.

    Additional Informationโ€‹

    We have just developed the first version of the MyBank Network and have not yet accepted external donations and financing.

    - + \ No newline at end of file diff --git a/applications/myriad_social.html b/applications/myriad_social.html index 19200074e5b..35bb175d3f1 100644 --- a/applications/myriad_social.html +++ b/applications/myriad_social.html @@ -4,7 +4,7 @@ Myriad Social - Uncensorable, Decentralized Social Network | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Myriad Social - Uncensorable, Decentralized Social Network

    This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines (except for the title)! Lines starting with a > (such as this one) should be removed. Please use markdown instead of HTML (e.g. ![](image.png) instead of <img>).

    See the Grants Program Process on how to submit a proposal.

    • Team Name: Myriad Systems LTD.
    • Payment Address: 0x89f547Ed40B8e921C566505Ccb71C69F398adbFF (USDT ERC-20)
    • Level: 2

    โ— The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Myriad Social is a social network that allows users to have their own platform without being controlled by a central authority. It is decentralized and censorship-resistant.

    Our app is developed using the Myriad blockchain, specifically as an appchain that runs on the Octopus Network. This provides several benefits. Firstly, it's censorship-resistant since there's no central control point. Secondly, it offers sovereign control as all data is kept in user-hosted instances with the freedom to host.

    The product proposition of myriad is as follows:

    • Myriad, a Federated Free Speech platform, empowers users to host their own social network and be a part of the Federation. By self-hosting, users can create their own server and invite others to join, enabling anyone to establish their own social network without depending on a central service.

    • Myriad Social offers a decentralized alternative to current social media platforms. With their crowdsourced method of importing social media posts, users can follow individuals on centralized networks without needing an account on those networks. This allows for greater accessibility and diversity of content.

    • With Myriad's Crypto Value Layer, users can gather posts from various social networks such as Twitter or Reddit and transfer them onto the blockchain. This transforms each post into a tipping wallet, enabling regular social media users to receive cryptocurrency for their content.

    • Myriad Social is a social media platform that is run by both $MYRIA token holders and users, making it self-governing. Unlike traditional platforms, it operates in a decentralized manner, which means that the governance system is more democratic and fair, without being controlled centrally.

    • At Myriad Social, our goal is to support the wider community by offering a range of pallets, services, and seamless integration options for federated social technologies. We strive to enhance the overall ecosystem and provide users with a more comprehensive experience.

    At Myriad, we prioritize interoperability. Our blockchain is powered by Substrate, a framework developed by Parity Technologies for Polkadot. This choice allows for greater flexibility, as our blockchain can easily connect with other popular blockchains like Octopus, Kusama, and Polkadot.

    In addition, Myriad has a federated architecture designed for modularity. This means that its components are extensible and can be treated like building blocks that can be assembled in any desired way.

    Our ultimate objective at Myriad Social is to become the primary decentralized social media platform of the future. After launching in early 2022, we have completed the first and second phases of our product's development, and it is now available on Octopus Network as an appchain. The Octopus project offers great flexibility as appchains can be deployed into a different ecosystem or live as their own blockchain. Additionally, Octopus Network supports protocols that "graduate" from its network. As the second appchain to go live on Octopus Network's ecosystem, Myriad has decided to level up and get embedded into the Kusama ecosystem to reach a wider audience.

    As a parachain that lives in Kusama/Polkadot/Web3 Ecosystem, Myriad provides:

    • A new decentralized social network with self-governance capability
    • A complete documentation on how to upgrade an existing Octopus appchain or similar substrate-based chains to any Polkadot Ecosystem
    • Multi wallet login using various providers

    Project Detailsโ€‹

    Architectureโ€‹

    The following is the architecture that has been deployed on Octopus Network as an appchain and will be deployed fully to Kusama as a parachain.

    User Interface Designโ€‹

    Technologiesโ€‹
    • GCP
    • Kubernetes (GKE Cluster)
    • NodeJS
    • MongoDB
    • Redis
    • Bastion VM
    Componentsโ€‹

    Myriadโ€™s decentralization is organized into two layers โ€” the Myriad blockchain and the Myriad federation. While each of these two layers is a network of cooperating computers that collectively constitute the Myriad platform, each individual layer provides something to the platform that the other cannot.

    Myriadโ€™s blockchain layer (composed of Myriad Nodes) is developed with the open-source Substrate blockchain platform and secures data that must be held strictly in global consensus, such as ownership, asset transfer, and global reputation. This includes things like Myria token balances, Userโ€™s global reputation scores, and NFT ownership.

    Myriadโ€™s federation layer (composed of Myriad Servers) allows for both scalability and data sovereignty which would not be possible in a pure-blockchain architecture. The federation servers store things like communities, posts, and experiences. This type of data is distinct from the hard-consensus data stored in the blockchain in a few significant ways โ€” It can be high-volume, curated per server, and itโ€™s not used in hard-consensus decisions (such as ownership transfer validation.)

    Itโ€™s important to note that the same physical computer can be both a Myriad Node and a Myriad Server (although it need not be both.) These two protocols work together to provide the features of the Myriad platform as a whole. As a consequence of this dual-network architecture, the following things are made possible:

    • Myriad Server Operators maintain complete data sovereignty โ€” The network does not force Server Operators to host content they disagree with. This is not possible, for example, in a pure-blockchain architecture where a node operator only has the binary choice to either host ALL data, or not run a node at all.
    • Myriad Servers can scale to millions of Users by leveraging traditional horizontal scaling techniques (which is impossible with conventional blockchains by virtue of the scaling problem) while remaining fully decentralized and censorship-resistant by virtue of any personโ€™s ability to operate a server that maintains their own communityโ€™s data.
    • The social media experience can be seamlessly augmented by the ability to send and receive tokens, convert any post into an NFT (*future roadmap), or even automate the democratic governance of communities โ€” all with the security properties of hard-consensus blockchains (such as ledger immutability and the unforgeability of digital signatures.)

    Ecosystem Fitโ€‹

    Myriad solves the problem where social media has become too controlled by big corporations. By providing a decentralized social media, Myriad allows users on Polkadot/Substrate/Kusama ecosystem to interact and host their own node instances.

    • The target audience of this project is the general audience who are looking for an uncensorable and free social media with web3 capabilities
    • The project allows builders on Substrate ecosystem to extend and build on top of the Myriad API
    • Similar project: Subsocial. Key difference: Myriad Social is combining decentralization and federation, allowing the off-chain data of the social media to be fully owned by the community.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Lead: Jean Daniel Gauthier (CEO)
    • Pandu Sastrowardoyo (Cofounder)
    • Gilang Bhagaskara (CTO)
    • Serafica Alamanda (Product Manager)
    • Irman NM (Lead Engineer & DevOps)
    • Abdul Hakim (Blockchain Developer)
    • Neka Arta Jaya (Full Stack Developer)
    • Ruben Kristian (Full Stack Developer)
    • Alvin Dimas (Full Stack Developer)
    • Alexander (Full Stack Developer)
    • Hildegard Lydia (QA Engineer)

    Contactโ€‹

    • Registered Address: House of Francis, Room 303, lle Du Port, Mahe, Seychelles
    • Registered Legal Entity: Myriad Systems LTD.

    Team's experienceโ€‹

    The core team members of Myriad Systems consists of professional blockchain consultants with 6 years of experience building and designing blockchain solutions at Blocksphere Indonesia and BlockchainZoo. Some of the team members (Gilang, Serafica, Irman, Abdul Hakim, and Lydia) hold the Certified Blockchain Professional certification from EC-Council. Irman, Lydia, Neka, Alvin, and Ruben have over 8 years of programming experience, and Abdul Hakim have 3 years of RUST experience. Gilang is an entrepreneur, blockchain developer, researcher, teacher, mentor, with over 12 years of experience, and has a reputable influence in blockchain development communities in Indonesia.

    Some interesting projects the team has been involved includes:

    • Debio Network: anonymous-first blockchain for medical and bioinformatics services and data
    • Realitychain: a multichain metaverse-as-a-service
    • Nester City: an arcitect-led NFT/metaverse project solving intellectual property and royalty issues of architecture designs

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 3
    • Total Costs: 30,000 USD

    Milestone 1 โ€” Parachain setupโ€‹

    • Estimated duration: 1 month
    • FTE: 3
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseAGPL-3.0 license
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up the parachain and copy an Octopus appchain into the Rococo ecosystem.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Infrastructure SetupWe will fully replicate the current appchain of the Myriad Social web application running on Octopus Network to Polkadot ecosystem as a parachain in Rococo
    2.Code RefactoringThe modules we implement during this milestone will interact in such a way that the Myriad Social website works with the same functionality as the current one that lives as an appchain on Octopus Network
    3.Data UpgradeWe will fully upgrade the existing data from the Myriad Social web application running on Octopus Network to Polkadot ecosystem

    Myriad Social will create a parachain on Polkadot while maintaining a foothold in the NEAR ecosystem.

    By maintaining the wallet selector for seamless switching between NEAR and Polkadot, we can expose our current community of NEAR users to Polkadot applications and their communities.

    Milestone 2 โ€” Native Polkadot Currency and Wallet Integrationโ€‹

    • Estimated duration: 1 month
    • FTE: 3
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseAGPL-3.0 license
    0b.DocumentationWe will provide documentation of the app changes and video guidance of how to utilize native DOT currency inside the Myriad Social application environment.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Native Currency IntegrationWe will enable tokens native to the Polkadot ecosystem as a way of interacting inside our app for tipping and other upcoming features.
    2.Wallet IntegrationWe will update the current wallet requirement to allow polkadot based wallet login into Myriad app.

    Myriad Social will utilize native tokens within Polkadot ecosystem within its app environment and incorporate their tokenomics, adding to the utility of the native tokens.

    *Please note that Myriad Social has already enabled DOT as a tipping option within the Myriad application.

    Our additional work product with the granting of this grant would allow us to develop and offer more features for the token ecosystem community, such as:

    • The ability for Myriad Users to unlock a Premium Post within Myriad using tokens native to the Polkadot ecosystem.
    • The ability to utilize other standard tokens within the Polkadot ecosystem within the Myriad app.

    Milestone 3 โ€” UI Revamp and Enhancementโ€‹

    • Estimated duration: 1 month
    • FTE: 3
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseAGPL-3.0 license
    0b.DocumentationWe will provide documentation of the app changes and video guidance of how to use the new Myriad Social user interface
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Front end: New UIWe will update the UI that has the functionality: Polkadot setup, connection, and use user guide (Step by step tooltips), simplified transaction flow for tipping, and creating/revealing exclusive content), token on-ramp, simplified timeline discovery (Timeline search function, revamped layout, revamped flow), and first step guide for new users (Step by step tooltips)
    2.B2B FeaturesWe will implement multiuser timelines, multiuser accounts, and multiuser content metrics
    3.Performance improvemmentWe will do code refactoring and optimization in order to enhance app performance, ensuring a faster and smoother user experience.
    4.Authentication improvementWe will implement Personal Access Token and Single Sign On using Myriad API
    5.Additional Utility-driven FeaturesWe will implement token-gated timelines, as well as token-gated access to content metrics
    6.Backend: Mobile WalletWe will implement Myriad connection to polkadot wallet on mobile (currently can only connect to Near wallet)
    7.Backend: Improved algorithmWe will improve algorithm such as: Native import of embedding of additional platforms (Youtube, Twitch, web content), and refactoring of popularity ranking for timelines, posts and hashtags
    8.Backend: Improved federated instance (Self-hosted Myriad Server) deploymentWe will create additional, simplified documentation for instance deployment, as well as automated/semi-automated Linode instance deployment
    9.Additional ClientsWe will implement Polkadot integration within the Myriad Telegram bot as well as the Myriad Chrome Extension

    Future Plansโ€‹

    • Myriad social intends to promote the upgrade process to our community in Telegram, Discord, and other social platforms, as well as working with Octopus to publish the activity in their official channels
    • The team will continue working on the Phase 3 (NFT, Social Token, Chat, etc) in the newly deployed ecosystem

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    • Referrer: Husni Rizal (Polkadot Ambassador)
    • Payment Address: 14tcZ9ibPGdMwb7XXE4QChgVuJU1xXTvDFpV3E1HpMajbBsH

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We received an email invitation from a Parity representative to submit a grant proposal.

    Myriad Social has performed fund raising activities, including a token sale on Skyward Finance in the NEAR Ecosystem, and has received financial backing from a couple private investors.

    - + \ No newline at end of file diff --git a/applications/native-bitcoin-vaults.html b/applications/native-bitcoin-vaults.html index c92c165762e..1aa6a0fc98c 100644 --- a/applications/native-bitcoin-vaults.html +++ b/applications/native-bitcoin-vaults.html @@ -4,7 +4,7 @@ Native Bitcoin Vaults (NBV) | Web3 Foundation Grants - + @@ -15,7 +15,7 @@ (project will have 4 developers contributing, blended rate of $50/hour)
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code, an mdBook with an explanation of the mechanics of NBV, detailed explainers for all user-facing features.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.VideoWe will record and publish a video explainer and demonstration of all features in English and Spanish.
    1.BDK IntegrationPreferably, we will build a no_std version of BDK, and if not, we will create an off-chain worker for all pertinent functions
    2.Account xpubUser can set an xpub on their account in the NBV pallet
    3.Output DescriptorsGenerate output descriptor (vault/wallet) based on the selected Vault Signers
    4.Generate Receiving AddressesNBV will be able to generate receiving addresses for a vault
    5.List and View vaultsNBV client will show a list of treasuries/vault, their labels, and the eligible signers
    6.Pass to SignerScan a treasury/vault from NBV into BlueWallet

    The following Extrinsics or RPC calls, with relevant UI functions, will be included in milestone #1.

    Milestone 2 โ€” Signing, Broadcasting and a Hosted Releaseโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code, an mdBook with an explanation of the mechanics of NBV, detailed explainers for all user-facing features.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.Video & ArticleWe will author an article, as well as record and publish an updated video explainer and demonstration of all features in English and Spanish.
    1.PSBT SigningUsers will be able to sign transactions using our customized signer (Spectre Desktop) and save the output to the Substrate node.
    2.Transaction BroadcastWhen the threshold of signatures has been reached, the node will broadcast the transaction to the Bitcoin network (via integrated Bitcoin core node)
    4.Hosted InstancesWe will host a testnet and mainnet instance of the full solution (as a standalone Substrate chain) for no less than 2 years
    5.EZ-TryThe hosted instances will have EZ-Try, which is our method of ensuring any level user can easily go to the app with no prerequisites and try it. (e.g. auto-faucet, auto-generate xpubs)
    6.Support & MaintenanceWe will provide user support and maintain compatibility with Substrate releases for no less than 2 years

    The following Extrinsics or RPC calls, with relevant UI functions, will be included in milestone #2.

    Future Plansโ€‹

    Immediate Useโ€‹

    We will immediately use the functionality for a number of DAOs, communities, and businesses that we work with and participate in. This is a critical feature that these teams desire before they are ready to migrate to the Polkadot ecosystem.

    Greater Contextโ€‹

    In the greater context, we are working towards a Substrate standalone chain and/or parachain/parathread to be used by small and medium-sized businesses.

    Over the last several years, we have established a leading presence in this area of blockchain. For example, last year, we were the first organization to ever tokenize real estate directly on chain in a manner where the token represents FINAL and INSTANT settlement of ownership. This was only possible in Wyoming after the DAO LLC legislation became effective in July 2021. In other words, a token holder can show their asset(s) to the Wyoming Supreme Court and they will protect their property rights. The LLC veil also sheilds DAO members from any personal liability. We attend the legislative sessions in person of the Select Committee for Blockchain and Financial Innovation in Wyoming.

    For a detailed legal explanation and step-by-step review of how we achieved this, please see our Digitalness Primer article and how Kitchen Lands DAO LLC Buys 35 Acres in Wyoming. In fact, the Chairperson of the Committee, Senator Chris Rothfuss, tweeted in support of our efforts and legal interpretation.

    This project has received much positive feedback and press, including this article from The Information.

    Other Small Business/Non-profits Toolsโ€‹

    Along these lines, we have and are building several other critical modules for small businesses, including:

    Feature Roadmapโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    Other relevant info:

    Q&Aโ€‹

    Do you know of any similar projects on other blockchains?โ€‹

    There are tons and tons of examples of wrapped Bitcoin of course, with various forms of trust, custody, and/or light clients. As referenced above, there is also interlay/interbtc in the Dotsama ecosystem which seems to be trustless and supports insurance for lost Bitcoin.

    In a few DAOs we built and participate in on Telos, there's an onchain badge for treasurers as they are elected/assigned, which helps, but certainly falls well short of delivering what NBV does.

    Besides that, I have not come across any tools or products that offer this capability, and certainly not with the strength of user experience that non-technical users expect and we intend to build.

    Comparison to Remark palletโ€‹

    What for example is the advantage of your solution compared to having a bitcoin multisig wallet which is controlled by a DAO and signing a remark on substrate that says this multisig account is controlled by the DAO? I guess you could do the same on bitcoin using OP_RETURN.

    This would be possible. At a high level, any state trie and state transition function can be summarized to a hash to sign in a remark. As seen with the RMRK NFT project ๐Ÿ‘, a lot of functionality can be driven through that capability. The benefit of using remark is that it is compatible with the relay chains.

    The trade-offs, IMHO, are mostly around usability, composability, and designing idiomatically, which I find incredibly useful for re-usability by other developers (particularly in initial releases). As an example, the Identity pallet developer chose to store fields, including the registrars' judgments ๐Ÿง‘โ€โš–๏ธ , within the pallet rather than hashing them into a remark field. I tend to think of these as "first class" attributes because the architect decided they were worth the space and mind-share of being stored directly on chain. In a similar pattern, I think the xpubs ๐Ÿ”‘ are important enough to persist this way also.

    In the future, I expect there to be a quite complex many:many relationship between users, DAOs, and vaults. For example, within the Hypha DAO, there are team "circles" or quests (projects) that are allocated a budget to a vault. There may be many circles/quests per DAO. There may also be many DAOs and circles/quests for each user, and they will likely desire different xpubs in their profiles for these scenarios.

    We can use the remark pallet, and it would be valuable 'back-end' for NBV that works on the relay chains. I think there are likely privacy preserving benefits to this as well. But the functionality and logic of generating the output descriptors dynamically along with receiving addresses, the user experience, vault handling, managing the user flow, etc, still needs to be developed.

    My suggestion would be that we implement the most vanilla, idiomatic way first, and then add compatibility to relay chain/remark as a future step. OP_RETURN compatibility is interesting too. A caution with that is, in my experience, the more complex/obfuscated the persisted state, the harder it is (more tooling/logic) for more casual users to verify and adopt. But there is absolutely value in pursuing these. Let me know what you think, and we would be happy to pivot or add this to the proposal.

    - + \ No newline at end of file diff --git a/applications/new-order.html b/applications/new-order.html index 92900abd96f..2cabacebcda 100644 --- a/applications/new-order.html +++ b/applications/new-order.html @@ -4,7 +4,7 @@ New Order - a full onchain orderbook dex with indexers | Web3 Foundation Grants - + @@ -31,7 +31,7 @@ CanceledOrder: an event when an order is canceled PairWhitelisted: an event when an asset pair is whitelisted

    I will build this.

    Documentationโ€‹

    Gitbook documentation is not enough to describe interacting with the software in current market. Guides are getting more important as more general people have been exposed to crypto. Polkadot has many tech to build something but coordination of them is poorly done. This section specifies which document to write for sufficient approach for newcomers and new devs. The documentation will add 2 categories, 3 subcategories, and at least 6 pages built with docusaurus framework.

    Why Docusauraus?โ€‹

    Docusauraus supports algolia search with customizable UI components with React. Some of the components include codehike.

    (Home)
      - What is New Order?
      - Learn More
      - Community
      Security
      FAQ


    <Protocol>
      (Overview)
        Protocol Participants
        Tokens

      (Governance)
        Proposal Types
        Whitelist procedure

    <Runtime>
    new-order: new-order pallet description 
      - Primitives
      - Storages
      - Calls
      - Events
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationI will write this in official documentation
    0c.Testing GuideTest code will be provided in the pallet.
    0d.DockerDocker can be provided for running this in substrate.
    1.Pallet codethe code repo will be open source with name new-order

    Documentationโ€‹

    Gitbook documentation is not enough to describe interacting with the software in current market. Guides are getting more important as more general people have been exposed to crypto. Polkadot has many tech to build something but coordination of them is poorly done. This section specifies which document to write for sufficient approach for newcomers and new devs. The documentation will add 1 category, at least 2 pages.

    <Developers>
    newordercli: A CLI to execute orders with new order
    neworder.js: Usage guides with query, execution
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationI will write this in official documentation
    0c.Testing GuideTest code will be written in neworder.js
    0d.DockerDockerfile is not needed
    1.Library RepoThe code for the library will be open source for PoC.
    2.CLI RepoThe code for CLI interacting with new order will be open source for PoC.
    2.Article & VideoWe will write an article that explains the work done as part of the grant, as well as release a video demo of executing newordercli

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? I applied before.

    - + \ No newline at end of file diff --git a/applications/new_bls12_hash_function.html b/applications/new_bls12_hash_function.html index c1e2dd12695..4493531feca 100644 --- a/applications/new_bls12_hash_function.html +++ b/applications/new_bls12_hash_function.html @@ -4,14 +4,14 @@ Implementation of the new hash function to BLS12 curves | Web3 Foundation Grants - +
    Skip to main content

    Implementation of the new hash function to BLS12 curves

    • Team Name: Dmitrii Koshelev
    • Payment Address: 0x050240CB2f5F7f7aA8AA10a5A9AE36c784AEdE49 (ERC20 USDC)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Please provide the following:

    • If the name of your project is not descriptive, a tag line (one sentence summary).

    Implementation of my hash function in Sage in the general case and in Rust specifically for the curve BLS12-381.

    • A brief description of your project.

    Recently, my article https://link.springer.com/article/10.1007/s10623-022-01012-8 was published in the quite prestigious cryptographic journal "Designs, Codes and Cryptography". This article provides a new hash function (indifferentiable from a random oracle) to the subgroup G1 of many elliptic curves of j-invariant 0, including most pairing-friendly curves of the family BLS12 (Barreto-Lynn-Scott) of embedding degree 12. Such curves and hash functions are actively used in blockchains, namely in the BLS (Boneh-Lynn-Shacham) aggregate signature. According to the web page https://wiki.polkadot.network/docs/learn-keys, the BLS signature will be in particular used in Polkadot.

    My hash function is much faster than previous state-of-the-art ones, including the Wahby-Boneh indirect map to the curve BLS12-381. This curve is a de facto standard in today's real-world pairing-based cryptography. The indifferentiable Wahby-Boneh hash function requires to extract two square roots (i.e., to compute two exponentiations) in the basic field Fp. In comparison, the new hash function extracts only one cubic root, which can be also expressed via one exponentiation in Fp. And according to Section 1.1 of my other article https://eprint.iacr.org/2021/1082 the exponentiations for square and cubic roots in Fp have short addition chains of about the same length.

    I have already checked the correctness of my results in the computer algebra system Magma. The new project is dedicated to an implementation of the new hash function to BLS12-381 in Rust. This project is a follow-up of the previous one concerning a proof-of-concept implementation in Sage (see #825). I wrote such an implementation, but I didn't finish the project, because my code does not meet high standards of Web3 Foundation. However, I found a professional developer in Rust who is ready to provide a Rust implementation (based on my Sage one), including tests. Consequently, besides my initial $10,000 reward (level 1), an additional reward for my colleague's work is required.

    • An indication of how your project relates to / integrates into Substrate / Polkadot / Kusama.

    According to the web page https://wiki.polkadot.network/docs/learn-keys, the BLS signature will be in particular used in Polkadot.

    • An indication of why your team is interested in creating this project.

    Because I want to demonstrate to the blockchain society that my research has an immediate practical value.

    Project Detailsโ€‹

    • PoC/MVP or other relevant prior work or research on the topic

    My article https://link.springer.com/article/10.1007/s10623-022-01012-8 under the name "Indifferentiable hashing to ordinary elliptic Fq-curves of j=0 with the cost of one exponentiation in Fq".

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem?

    Hashing to elliptic curves in the BLS (Boneh-Lynn-Shacham) aggregate signature.

    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

    Developers who will use the new hash function in their implementations of cryptographic protocols.

    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?
      • If so, how is your project different?
      • If not, are there similar projects in related ecosystems?

    I don't know, because my project is quite extraordinary, in my opinion. Maybe, similar projects (based on recent results of mathematical cryptography) periodically arise in the Ethereum Foundation grants program.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Name of team leader

    Dmitrii Koshelev

    • Names of team members

    My colleague who is a professional Rust programmer. He prefers to be anonymous.

    Contactโ€‹

    • Registered Address: 27B boulevard Jourdan, app. 317, Paris, France
    • Registered Legal Entity: In this project I am an individual, but I work as a postdoctoral researcher in Telecom Paris (Polytechnic Institute of Paris).

    Team's experienceโ€‹

    There is the regularly updated CFRG draft on hashing to elliptic curves: https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/. As for me, at the beginning of the last year, as said in https://blog.ethereum.org/2021/11/04/esp-allocation-update-q2-2021/, I won an Ethereum Foundation grant to derive a fast hash function to the subgroup G2 of the pairing-friendly curve BLS12-381. As an outcome of this grant, in Section 1.2 of https://eprint.iacr.org/2021/1082 I prove that for hashing to G2 the Wahby-Boneh map applied only once (not twice) is sufficient to act as a random oracle. Thus we get rid of one exponentiation in the quadratic extension Fp2 or, equivalently, of two exponentiations in the prime field Fp. Besides, I constructed a series of hash functions to other elliptic curves in the articles https://eprint.iacr.org/2021/1034 (accepted in SIAM Journal on Applied Algebra and Geometry), https://link.springer.com/article/10.1007/s12095-021-00478-y (published in Cryptography and Communications), https://eprint.iacr.org/2021/1604 (submitted to Journal of Mathematical Cryptology).

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    • links to your research diary, blog posts, articles, forum discussions or open GitHub issues,

    https://ethresear.ch/t/indifferentiable-hashing-to-ordinary-elliptic-fq-curves-of-j-0-with-the-cost-of-one-exponentiation-in-fq/8867

    https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/issues/316

    https://github.com/dishport/Indifferentiable-hashing-to-ordinary-elliptic-curves-of-j-0-with-the-cost-of-one-exponentiation

    https://link.springer.com/article/10.1007/s10623-022-01012-8

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 6 months
    • Full-Time Equivalent (FTE): 1 FTE
    • Total Costs: 15,000 USD

    Milestone 1 โ€” An implementation in Sageโ€‹

    • Estimated duration: 3 months
    • FTE: 1
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseGNU GPL
    0b.DocumentationI will provide inline documentation of the code.
    0c.Testing Guide
    0d.DockerI do not intend to deliver this, because the project is research oriented.
    0e.ArticleI will cite the implementation and I will thank Web3 Foundation for its financial support in my new article https://eprint.iacr.org/2021/1082. I submitted this article to Journal of Cryptology. At the moment, it is under review.
    1.ImplementationSage (non-constant-time) implementation of the hash function described below.

    To be definite, let me use the notation of my article https://link.springer.com/article/10.1007/s10623-022-01012-8. The new hash function consists of three components: a classical one \eta: {0,1}^ -> Fp^2, a rational map \varphi: Fp^2 -> T(Fp), and an additional map h^\prime: T(Fp) -> E(Fp), where E is a given elliptic Fp-curve of j-invariant 0 and T is a suplementary algebraic threefold. A construction of \eta is represented in Section 5 of the draft https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/. This is the composition of a hash function {0,1}^ -> {0,1}^n for some n \in N and the subsequent restriction modulo p, hence we can use a standard hash function from one of cryptographic libraries. It remains to implement \varphi and h^\prime just as described in my article.

    It is also worth noting that the new hash function is relevant for any ordinary (i.e., non-supersingular) elliptic Fq-curve y^2 = x^3 + b (of j-invariant 0) such that the square root of b lies in Fq. Here Fq is an arbitrary finite field (of characteristic p > 3) for which 3 divides q-1, but 27 does not. Therefore, our Sage implementation is in fact relevant for all such curves and fields. The BLS12-381 curve corresponds to the case when q = 10 (mod 27) and b is not a cubic residue in Fq.

    Milestone 2 โ€” A non-constant-time implementation in Rust in the case of the BLS12-381 curveโ€‹

    • Estimated duration: 3 months
    • FTE: 1
    • Costs: 5,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache License, Version 2.0 and MIT license
    0b.DocumentationI will provide inline documentation of the code.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. I will describe how to run these tests.
    0d.DockerI do not intend to deliver this, because the project is research oriented.
    0e.ArticleI will cite the implementation and I will thank Web3 Foundation for its financial support in my new article https://eprint.iacr.org/2021/1082. I submitted this article to Journal of Cryptology. At the moment, it is under review.
    1.ImplementationRust non-constant-time implementation of the new hash function for BLS12-381. It is suggested to use the library arkworks (https://github.com/arkworks-rs/curves) as a base. In particular, to perform the (unique) exponentiation in Fp an addition chain of quite small length has already been derived in https://github.com/dishport/Some-remarks-on-how-to-hash-faster-onto-elliptic-curves (cf. Section 1.1 of https://eprint.iacr.org/2021/1082).

    Future Plansโ€‹

    The new hash function appears to be optimal, because it performs only one exponentiation in the basic field Fq. In other words, since it is highly unlikely that there is a hash function to an elliptic curve without exponentiations at all (even if it is supersingular), the result of my article seems to be unimprovable. Thus I hope that the implementation of my hash function will be interesting not only to you, but also to all blockchain projects that involve the BLS signature.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    • If there are any other teams who have already contributed (financially) to the project.

    No

    • Previous grants you may have applied for.

    An Ethereum Foundation grant called "fast hash-to-curve research" and represented on the web page https://blog.ethereum.org/2021/11/04/esp-allocation-update-q2-2021/

    - + \ No newline at end of file diff --git a/applications/newomega-m3m4.html b/applications/newomega-m3m4.html index 83b84eef4e0..bd58531e5ee 100644 --- a/applications/newomega-m3m4.html +++ b/applications/newomega-m3m4.html @@ -4,7 +4,7 @@ NewOmega (Milestone 3 and 4) | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ https://wiktorstarczewski.medium.com/newomega-3504ce08120 https://wiktorstarczewski.medium.com/newomega-now-and-future-a87589d01722

    Homepage: https://www.newomega.online/

    The goal is to have a deployed, playable, and marketable test version on a public network at the end of Milestone 4. The combination of space exploration, leaving a permanent mark on an inifinite universe, combined with a tactical combat element, all delivered in a modern 3d web (hybrid) app, will provide a broader "reason" to enjoy the game, and the ranked combat (leaderboards + staking own ingame money on fights) will provide a competitive element to compliment.

    In time (after M4), the Universe will become more diverse; producing different minerals which will be used to craft Modules of certain parameters. The minerals/production system should offer the player an option creation of an "industry" used to produce Modules, and the mineral types should be randomly generated when discovering Systems, making control of some Systems more attractive than others and giving more reason to territory control.

    Once released to test users, additional features will be driven by test user feedback, at which stage we will also trigger development on onboarding features (in game tutorials, starting resources, but also gas (weight => transaction cost) sponsoring model to remove the requirement of owning tokens for new players (to pay registration contract's gas fees, for example). And as the DOT ecosystem matures, new opportunities for technical improvements will present themselves.

    - + \ No newline at end of file diff --git a/applications/newomega.html b/applications/newomega.html index 0dee227b219..1fd7a1cebf6 100644 --- a/applications/newomega.html +++ b/applications/newomega.html @@ -4,7 +4,7 @@ NewOmega | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ A way to provide additional strategic options to the game, without increasing the smart contract load too much (one can design a ship and easily pass it into the fight contract as parameter, so its next to free).
  • Territory Control Will put more load on the contract side, but for broader gameplay will be unavoidable. Contracts for map control can be kept lean, so they would be cheap.
  • Cooperative Play Combining fleets together for attacks, etc.
  • Alliances

    • Additional Informationโ€‹

    A working frontend prototype and smart contracts on Ethereum Ropsten are available. No teams have already contributed (financially) to the project. No other grant applications have been made.

    - + \ No newline at end of file diff --git a/applications/nft_collectibles_wallet.html b/applications/nft_collectibles_wallet.html index 21e3b3f6d6d..058456c45c8 100644 --- a/applications/nft_collectibles_wallet.html +++ b/applications/nft_collectibles_wallet.html @@ -4,7 +4,7 @@ NFT Collectibles Wallet | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    NFT Collectibles Wallet

    • Payment Address (DAI): 0x16D7A415040D52F2427C2b921dfC31829C0d17fc
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    The NFT Collectibles Wallet is a multi-chain non-custodial mobile wallet which will allow users to claim, store and manage an unlimited number of NFTs from any Substrate based blockchain. This project will consist of 2 major parts: the mobile wallet for users and the javascript sdk for front-end developers to create NFT management UI.

    **Users:** By scanning QR codes, users will be able to claim NFTs into their wallet. These NFTs can be consumed (burned), listed for sale or sent to others. Users will also have the ability to mint NFTs from within the mobile app. The mobile app will be downloadable from Apple's App Store and Google's Play Store.**Front-end developers:** By using the `nft-wallet-javascript-sdk`, javascript developers can create a UI for creating new NFTs. This javascript sdk will be able to connect to any substrate node via Polkadot.js.

    Overviewโ€‹

    The reason we are creating the NFT Collectibles Wallet is to allow users of GamePower Network (https://www.gamepower.network) to claim NFTs from games published on the platform. We could have made the wallet closed sourced such as other projects (Enjin Wallet), but we decided since we are the new kids on the block, it is better for us to contribute to the Substrate/Polkadot/Kusama community. That is what excites us so much about this project.

    Our team is very passionate about gaming and NFTs. We believe the use case for NFTs in gaming is one of the most valuable in crypto right now. The problem we see with NFTs is that explaining NFTs to the general consumer and giving them a streamlined and friendly place to use those NFTs is lacking. We want to solve this with the NFT Collectibles Wallet.

    Project Detailsโ€‹

    • Mobile Wallet Details:

    The mobile wallet will be built using React Native. We feel this will allow us to use a coding language (javascript) we've used for years and build performant mobile applications. Using React Native also allows us to code once and deploy on multiple mobile platforms.

    Mobile Stack:

    • React Native
    • Polkadot.js
    • react-qr-scanner

    A mockup of our mobile wallet UI. This mockup outlines the wallet creation, QR scanning and collectibles viewer. img

    • Substrate Pallet Details:

    The nft-wallet-pallet will use ORML (open runtime modules library: https://github.com/open-web3-stack/open-runtime-module-library) which will provide us with some underlying NFT code. The pallet will also talk to the balances pallet to handle any minting and consuming which is needed since each NFT is minted with a type of currency native to the blockchain it is on.

    Substrate Stack:

    • Substrate
    • ORML

    These methods will serve as an interface for the NFT Wallet to communicate with any substrate runtime. nft-wallet-pallet expects ORML's nft pallet to be a part of the runtime since it will be used to handle all NFT related functions.

    We will expose a SEND and BURN callback so that the runtime can do any domain specific logic when sending or burning an NFT.

    fn send(origin, asset_id: u64, recipient: AccountId) -> Result;
    // burn the NFT with a short reason used by dapps
    fn burn(origin, asset_id: u64, reason: Vec<u8>) -> Result;
    // list an NFT for sale
    fn list(origin, asset_id: u64, price: T::Balance) -> Result;
    // buy a listed NFT
    fn buy(origin, asset_id: u64, list_price: T::Balance) -> Result;
    // add an emote to the NFT (for social)
    fn emote(origin, asset_id: u64, emote: Vec<u8>) -> Result;
    // allows a user to claim a minted NFT
    fn claim(origin, asset_id: u64) -> Result;
    • Javascript SDK Details:

    The front-end UI will be built using React + Polkadot.js. This will be a straight-forward and clean UI to allow the creation and management of NFTs. This UI is not a front-end for consumers but for developers to create NFTs. The underlying SDK for the front-end can be used to create any type of custom NFT management UI.

    Web Stack:

    • React
    • Polkadot.js

    Mockup of the admin frontend. img

    Ecosystem Fitโ€‹

    The NFT Collectibles Wallet provides the ecosystem with a streamlined and standard way to create, manage and exchange NFTs. By allowing the wallet to connect to any substrate based chain, users can freely move around the ecosystem without downloading multiple wallets for each chain, while still having a wallet that focuses specifically on collectibles.

    The NFT Wallet uses the RMRK NFT standard (https://rmrk.app/#standards). However the NFT Wallet project can potentially support other standards such as the new Enjin initiative on the Polkadot ecosystem.

    Our target audience is 3-fold: The everyday consumer that wants to manage their NFTs, The Substrate blockchain developer that wants to connect to the NFT Collectibles Wallet to offer NFTs on their blockchain and finally Dapp developers who want to offer their users NFTs through QR codes.

    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

    The most similar project to the NFT Collectibles Wallet is the Enjin Wallet. However, the Enjin wallet is closed sourced and multiple blockchains cannot directly integrate into it in a decentralized way. This project solves that issue by being open sourced and allowing anyone that is a part of the ecosystem to contribute and enhance the project. Also by removing the wallet's centralization, any Substrate blockchain can make use of it.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Michael Huntington: Senior Software Engineer.
    • Michael Rochester: Project Manager and Software Project Implementation

    Contactโ€‹

    • Registered Address: None
    • Registered Legal Entity: None

    Team's experienceโ€‹

    Michael Huntington has worked on various projects through enterprise and personal software creations. Mike has published games for IOS and Android launched on the Apple AppStore and Google Play Store. He has worked as a Software Engineer for multiple fortune 500 companies such as AT&T, Turner Broadcasting, and ADP. Mike brings a wealth of knowledge to our team and is a driving force behind our concepts.

    Michael Rochester has worked with various software companies as a project manager and has implemented a wide range of clients within the municipal software niche and utility billing genre. His experience includes consumer account management applications launched on Google Play and Apple app stores. He brings 7 years of project management experience and is a guiding force for this project.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Currently, work for the NFT Collectibles Wallet has not started, but the team has started initial work on GamePower Network (https://www.gamepower.network) which will be the first project to implement the NFT Collectibles Wallet. The wallet was actually conceived because of the GamePower project. The need for the NFT wallet was very important and we decided to open the project up to anyone in the ecosystem that has the same need.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 7 weeks
    • Full-Time Equivalent (FTE): 2.1 FTE
    • Total Costs: 15,000 USD

    Milestone 1 โ€” Implement NFT Wallet Palletโ€‹

    • Estimated Duration: 4 weeks
    • FTE: 1
    • Costs: 0 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.nft-wallet-palletWe will create a Substrate module that will allow an NFT to be (consumed, listed on market, traded, purchased on market). pallet methods are listed in the diagram above.
    2.Substrate Test Chainusers can interact with the nft-wallet-pallet module through a simple substrate barebones setup.

    Milestone 2 โ€” Build NFT Collectibles Wallet Mobile Appโ€‹

    • Estimated Duration: 4 weeks
    • FTE: 1
    • Costs: 10,000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.build app structureWe will have the core structure of the application in place.
    2.implement wallet creation viewThis will be the landing screen of the app where users can create or restore their NFT Collectibles Wallet.
    3.implement the collectibles viewThis view is where users can see a list of all their collectibles.
    4.implement QR scanner viewThis view is where users can scan a QR code a see information about the NFT such as (the chain it belongs to and other metadata attached to the NFT).
    5.implement QR scanner logicWhen a QR code is scanned we will connect to the blockchain it belongs to and fetch the NFTs metadata.
    6.implement NFT claim screenAfter scanning a QR code the user will be taken to a screen to confirm if they want to claim the NFT. From here a transaction is made for the claim.
    7.write testsTests will need to be written for each view.

    Milestone 3 โ€” Build Javascript SDK and Admin Frontendโ€‹

    • Estimated Duration: 3 weeks
    • FTE: 0.5
    • Costs: 5,000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.Article/TutorialWe will publish an article/tutorial for non-technical users that explains what the NFT Collectibles wallet is and how to use it.
    1.react frontendThis frontend will provide a UI for all the CRUD methods needed for managing NFTs. Users should be able to mint collections, mint NFTs and change issuers.
    2.Connect to IPFSAll metadata entered for minting collections and NFTs should be stored on IPFS.
    3.Connect to substrate with Polkadot.jsUsers should easily be able to connect the Admin frontend using polkadot.js.
    4.write testsTests will need to be written for each view.

    Future Plansโ€‹

    This NFT Collectibles Wallet will be used as part of the GamePower Network. GamePower will operate on the Kusama and Polkadot platform and will be the first application of it's kind that delivers decentralized game publishing. GamePower will use the NFT Collectibles Wallet to allow users of GamePower to store NFTs purchased or earned through GamePower either in a game or through the GamePower NFT marketplace.

    However, Development of the NFT Collectibles Wallet won't end after all milestones are met. We plan to add features such as Minting NFTs from within the application by users, A way for the app to automatically discover blockchains using NFTs on its own (maybe through some type of registry). There are endless possibilities where this wallet can go and we are very excited to get started on it!

    Additional Information โž•โ€‹

    Currently we have no funding for this project or GamePower Network, we feel getting the NFT Collectibles Wallet off the ground will kick-start our GamePower Network development in a big way. We are excited to be part of the Substrate and Polkadot community and we will continue to contribute as much as we can. Thank you for your time and thank you for considering us for the Web3 Open Grant.

    - + \ No newline at end of file diff --git a/applications/nft_explorer.html b/applications/nft_explorer.html index 546d8835fda..6aab7b6f0ec 100644 --- a/applications/nft_explorer.html +++ b/applications/nft_explorer.html @@ -4,13 +4,13 @@ Uniscan NFT Explorer | Web3 Foundation Grants - +
    Skip to main content

    Uniscan NFT Explorer

    • Team Name: Uniscan
    • Payment Address: 0x480821a0700b0d5fBC722a5339ED2d49979Eaa42 (DAI)

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Uniscan NFT Explorer wants to be the best place to analyze, track and discover NFTs.

    Uniscan NFT Explorer hopes to create a unified NFT dedicated explorer for the Polkadot / Kusama ecology. It can be used to discover and view the NFTs in important parachains in the Polkadot / Kusama ecology.

    The vision of this explorer is to become a better platform for discovering and analyzing NFTs. In the future, we can provide more tools for discovering and analyzing NFTs, such as combining on-chain data and off-chain data to provide users with some statistical views.

    We hope that through this grant, we can better understand NFT and lay a foundation for the realization of this vision. This grant is the first step of this vision, that is to achieve a basic browser structure and functions, and only focus on evm. Through this grant, we hope to

    1. establish a reliable technology architecture.
    2. choose the best technology stacks.
    3. better understand nft, and improve the data model,
    4. implement a better style suitable for NFT display.

    Project Detailsโ€‹

    Architectureโ€‹

    This is a standard web program, the main structure includes three layers.

    The first layer is the Web server, which is responsible for rendering browser pages, showing NFTs to users, and providing some interactive functions.

    The second layer is the database layer. A data model is used in the database to store all NFTs data, and the Web server will query the data from the database.

    The third layer is the data query layer connected to blockchains. In this layer, there will be a number of long-running workers. These workers will monitor or poll blockchains to discover NFTs, and then combine these NFTs with their related data into the database, and the push service will also be notified to push the latest data to the browser. In addition to obtaining data through blockchains, this layer may also grab data from some centralized or decentralized services, such as grabbing transaction data from Markets, etc. This part is not in the scope of this grant.

    This grant application only focuses on the NFTs on the evm-compatible virtual machine in the Polkadot ecosystem, and only monitors and saves the ERC721 and ERC1155 compatible NFTs. And only considers connecting two substrate based blockchains.

    In the future, we will apply for other grants based on the completion of this grant, including more chains, support for wasm based NFTs, and support for more types of NFTs, such as RMRK.

    Mockupsโ€‹

    nftexplorer

    Data modelsโ€‹

    collectionsโ€‹
    • id: The collection's unique identifier
    • name: The collection's name
    • symbol: An abbreviated name of this NFT. null if it is an erc1155 collection.
    • blockchain_id: Blockchain id
    • contract_platform: Only support EVM compatible now, wasm will be supported
    • contract_address: Contract address
    • type: erc721 compatible | erc1155 compatible
    • total_supply: A count of tokens tracked by this NFT
    • explorer_url: A subscan(or other explorers) url to show its the normal info
    • holders: Number of holders
    • transfers: Number of transfers
    • creator: The creator's address id
    tokensโ€‹
    • id: The token unique identifier in the system
    • id_in_contract: Token id or token type id(erc1155) in its nft contracts
    • collection_id: the NFT id to which this token belongs
    • unique: true | false, true if it is an erc721 compatible token, false if it is an erc1155 compatible token
    • supply: 1 if erc721
    • creator: The creator's address id
    • owner: The current ownerโ€˜s address id
    • title: Short title of this token
    • name: The name of this token
    • description: Describe the token
    • image: A URI pointing to a resource with mime-type image/*
    • metadata_uri: A distinct Uniform Resource Identifier (URI) for a given token
    • is_permanent: bool, a flag to show is this token has a permanent resource
    • explorer_url: A subscan(or other explorers) url to show its the normal info
    • transfers: Number of transfers
    addressesโ€‹
    • id: The address unique identifier
    • blockchain_id: Blockchain id
    • important_level:
    blockchainsโ€‹
    • id: The blockchain unique identifier
    • title: Short title of this blockchain
    • description: Describe the blockchain
    transfersโ€‹

    if it is an erc1155 batch transfer, it will be split into many rows here.

    • collection_id: the collection id
    • token_id: the token id
    • value: used if it is an erc1155 transfer
    • from: from address
    • to: to address
    • created_at: Time when the transfer occurred
    • txhash: txhash

    Apisโ€‹

    Web APIsโ€‹

    Because we don't want to make this application separate from the frontend and backend, there may be no well-defined APIs. Here are some APIs:

    • GET /tokens/latest

      Get the latest created NFT list

    • GET /transfers/latest

      Get the latest transfers

    • GET /tokens/highest_transfered/1

    • GET /tokens/highest_transfered/7

    • GET /tokens

      List all NFT tokens by condition

      params:

      • sort by:
      • type:
      • chain:
      • page

    • GET /tokens/:id

      Get token detail by id

    • GET /collections

      List all NFT collections by condition

      params:

      • sort by:
      • type:
      • chain:
      • page

    • GET /collections/:id/tokens

      Get the tokens of a collection

    • GET /addresses/:address

      Get the collections with tokens that belong to the address

      [
       {
        "collection_id": 1,
          "collection_name": "...",
        "tokens": [
         {
          "token_id": 2,
          "token_title": "...",
          ...
         },
         ...
        ]
       },
       ...
      ]

    Technology stackโ€‹

    frontendโ€‹
    backendโ€‹

    Ecosystem Fitโ€‹

    We believe that there will be various NFTs in the Polkadot / Kusama ecosystem in the future, so a unified nft explorer must be very important. Now many parachains will support the creation of NFTs. Users interested in NFTs will want to have a unified entry to view these NFTs.

    We found that there is no unified and easy-to-use NFT browser in the current Polkadot ecosystem.

    Potential users of the NFT browser include NFT collectors, NFT creators, NFT speculators and other applications.

    Similar projectsโ€‹

    https://nft.kodadot.xyz/rmrk/gallery

    Kodadot gallery is a rmrk nfts gallery.

    The difference between us is that the purpose and direction. Kodadot gallery is a part of the RMRK. Uniscan's current goal is to support NFTs of evm pallet. The Uniscan's final goal is to build an all-in-one NFT explorer for Polkadot & Kusama ecosystem with some data statistics for users to easily discover NFTs.

    Why evm?โ€‹

    1. Evm is the most widely adopted virtual machine platform in the Polkadot/Kusama ecosystem, so there will be a lot of NFTs to be issued based on evm pallet.
    2. There is not an NFT explorer support evm in the Polkadot/Kusama ecosystem.
    3. It is difficult for the NFT explorers of the Ethereum ecosystem to cover the chains in the Polkadot ecosystem. And they are not permissionless.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Kyle Gu: product manager
    • Tuminfei: architecture and blockchain consultant
    • Aki Wu: full-stack developer

    Contactโ€‹

    • Registered Address: 3 FRASER STREET #05-25 DUO TOWER SINGAPORE (189352)
    • Registered Legal Entity: UNI-ARTS FOUNDATION LTD.

    Team's experienceโ€‹

    Uniscan is a team dedicated to create an unified NFT explorer. We have the ability to develop web, mobile, and blockchain applications. The team is familiar with Ethereum and Substrate development.

    Aki Wu has many years of web and blockchain development experience, and is proficient in web development, and is familiar with ruby and rust languages. When working at Itering, he developed scale.rb, a Scale Codec library and Substrate Client implemented in Ruby language. scale.rb is a grant of the Web3 Foundation.

    Kyle Gu is the product manager of Uniscan team. He has worked in the blockchain industry for many years and is familiar with the operation and development of blockchain projects.

    Tuminfei is the architecture and blockchain consultant of Uniscan team. He has rich experience in the field of software development, especially in blockchain. He has implemented many projects as a leader. He is familiar with the development of Ethereum and Substrate. He is also a major maintainer of the UniArts chain.

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2.5 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 16,000 USD

    Milestone 1 โ€” common componentsโ€‹

    • Estimated duration: 1 month
    • FTE: 2
    • Costs: 8,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that run the code, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.Article
    1.A evm log tracking lib using ethereum filterIt is a lib used to track event logs of certain addresses and topics.
    It use ethereum compatible json-rpc apis(eth_newfilter, eth_getlogs) to track the logs.
    It will be used to track the substrate ERC721 and ERC1155 NFTs.
    It will be implemented in rust programming language.
    2.A evm log tracking lib using substrate eventIt is a lib used to track event logs of certain addresses and topics.
    It use substrate events(getStorage) to track the logs.
    It will be used to track substrate ERC721 and ERC1155 NFTs.
    It will be implemented in ruby programming language.
    3.A lib to identify the NFTsThis lib is used by the above tracking lib to identify which contracts are NFT contracts(ERC721, ERC1155). ERC-165 Standard Interface Detection is used.
    It will be implemented in ruby programming language.

    Milestone 2 โ€” Web serverโ€‹

    • Estimated Duration: 1.5 month
    • FTE: 2
    • Costs: 8,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.Documentation1. We will provide both inline documentation of the code.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    And, It will be used to run the server.
    0e.ArticleWe will publish an medium english article that explains what was done as part of the grant and how to use it( How to use the three libraries in Milestone1, the description of the models in Milestone2).
    1.ModelsImplement the models described in models.
    It will be implemented in ruby programming language.
    2.Views and ControllersImplement the views and the related controllers described in mockups and apis.
    It will be implemented in ruby programming language.

    Future Plansโ€‹

    • Strengthen the display effect on the small screen
    • Support the NFTs of Statemine
    • Support more evm based chain
    • Support wasm based NFTs
    • Support more NFT types or specifications, such as RMRK
    • Market data & view
    • Record important addresses and level them
    • Statistic chart, such as transfer frequency statistic
    • Signup & Signin. The use can add nfts to the favorites.
    - + \ No newline at end of file diff --git a/applications/nft_product_analytics_suite.html b/applications/nft_product_analytics_suite.html index 53d1a4bee21..4ed7a169469 100644 --- a/applications/nft_product_analytics_suite.html +++ b/applications/nft_product_analytics_suite.html @@ -4,13 +4,13 @@ NFT Product Analytics Suite | Web3 Foundation Grants - +
    Skip to main content

    NFT Product Analytics Suite

    Status: Terminated

    Team Nameโ€‹

    Health Hero

    Payment Addressโ€‹

    0x9CcB0Fb827Aa2418121b6D20FD23c8e2c341b081

    Overviewโ€‹

    Introductionโ€‹

    Over billions of dollars of digital collectibles (NFTs) have been minted and traded. The people minting these tokens need to know who's interacting, buying, selling, and how they should best create them. They also need to know what different variations of digital collectibles have gamification or point elements that are attached to these assets and how users are receptive to this. With this information at hand, they can get faster and more effective feedback so they can make artful or functional digital collectibles that drive the right behaviors for that model. In the traditional space, companies have access to tools such as Segment and Google Analytics, that have become commonplace due to opportunity cost and user retention. We plan on bringing that functionality into the blockchain space.

    Project Detailsโ€‹

    The NFT Product Analytics Suite will aggregate various data points both off and on chain to provide NFT minters the metrics they need to use to decide how to best serve their target audience. This will include tracking the transfers of the user's minted NFTs, when and how much they are being sold for, and price trends. We will also aggregate the meta data associated with a given NFT to see the effectiveness of various gamification methods. With this data being tracked, you will be able to compare your NFTs to other leading projects and artists to see what the difference is and how to better target end users.

    • Data Gathering
      • Chain Indexer (find the indexer they've funded)
      • Marketplaces
    • Insights
      • Chain of custody
      • Price Trends
      • Revenue Tracking
      • Insights about projects

    Ecosystem Fitโ€‹

    Where and how does your project fit into the ecosystem? / What need(s) does your project meet?

    • With the largely growing adoption of NFTs, whether you are a game company or an NFT artist, a major pain point is the lack of easy access to metrics that are standard in other non-blockchain-based ecosystems. Those metrics have proved detrimental in how people decide to best present their offering to their target audience, but have remained largely out of reach for a large portion of the early adopters in the NFT space either due to time or technical experience. NFT artists and content creators will be able to track their progress, spot trends, and better tell what their customers want without getting lost in technical documentation or spending time manually collecting data. Companies won't have to devote time or development resources to come up with an in-house monitoring solution to track revenue, user adoption, and easily compare new ideas.

    Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

    • In-house
    • Blockchain companies and NFT-based Solutions
    • NFT artists and content creators

    Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

    • There are projects that index the chain, but none that are specifically tracking metrics that are related to NFTs both on and off chain

    Teamโ€‹

    Team Membersโ€‹

    Team Leader:

    • Monty Lennie (CTO)
    • Anthony Diaz (CEO)

    Team Members:

    • Umair Azhar (Senior Full Stack Engineer)
    • Hamza Liaqet (Senior Data Scientist)
    • Angel Leon (Product and UX)
    • Nicholas Vincent (Senior Full Stack Engineer)

    Contactโ€‹

    Contact Name:

    • Anthony Diaz (CEO)

    Contact Email:

    Website:

    • gohealthhero.com

    Registered Address

    • Health Hero, Inc, 548 Market St, Suite 15351, San Francisco, CA 94104

    Registered Legal Entity

    • Health Hero, Inc

    Team's experienceโ€‹

    • Mr. Diaz has over a decade of experience in leadership in healthcare, global product and platform development, and digital consumer engagement. Repeat founder. People leader that commands an uncanny sense of global business and brings global products to life that generate profit.
    • Mr. Lennie is a polyglot technology leader. Repeat founder. Grew numerous tech companies across enterprise SaaS. Motivated to lead engineering organizations to accomplish extraordinary things in the field of health. Medical school student turned CTO.
    • Mr. Azhar is a software engineer with over 7 years of experience. Mr. Azhar has a passion for back-end development with great instinct for reflecting code on user interfaces and user experience, Artificial Intelligence, machine learning, innovative technologies, and development operations. Strong leader with a tactical vision on integrating latest technologies into highly complex products. Mr. Azhar has driven development efforts for large teams of engineers and has an acute eye for security, product, and technology architecture
    • Mr. Liaqet is a passionate full stack machine learning engineer. Author of โ€œPractical Machine Learningโ€. Author of โ€œPractical Machine Learningโ€. Belief that if one has the right programming and problem-solving ability, then no problem is unsolvable. Loves solving challenging problems. Deploying strong algorithmic, AI, quantum computing, and mathematics to well-being is in his calling.
    • Mr. Leon is a U.S. Navy veteran, product, operations, and innovation leader overseeing teams that manage revenue, strategy, business, partnerships, information technology, product management, policy, security, workplace resources, and other cross-functional operations. Angelโ€™s passion is on how to operationalize and productize integration technologies, patterns, best practices, and user interfaces. His experience includes a decade+ years in health IT, working with a wide spectrum of customers, including IDNs, payers, life sciences companies, and software vendors, with the goal of improving outcomes and reducing costs by aggregating and analyzing clinical, claims, and cost data.
    • Mr. Vincent is a software engineer with over 6 years of experience. Mr. Vincent has a passion for new technologies that was what originally drew him into the blockchain space back when he was first starting and has continued to drive his career goals. He has worked with and led multiple teams on blockchain implementation, cryptographic protocols, data analytics platforms staying in line with his passion by using new high throughput languages such as GoLang and Rust.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Statusโ€‹

    Development Road Mapโ€‹

    Overviewโ€‹

    Total Estimated Duration

    • 8 weeks

    FTE

    • 2

    Total Costs

    • 0 USD (Terminated)

    Tech Stack

    • We will be using rust as the primary language Rust
    • For the database we will be using PostgreSQL
    • The database will be exposed via a GraphQL node

    Milestone 1 - On Chain Data Sourcesโ€‹

    Estimated Duration

    • 4 weeks

    FTE

    • 2

    Costs

    • 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache License 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can run a local instance and / or fetch metrics using the application.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.Press ReleaseWe will publish a press release that explains the use and benefits of having an NFT analytics suite to provide NFT artists and content creators a way to better tell what their customers want without getting lost in technical documentation or spending time manually collecting data. Additionally, this release will expose Health Hero's work with Parity and how we are enhancing their ecosystem.
    1.Base Data Adapter / Data Adapter TemplateThis will include aggregating the various structs that are going to be used across the various data adapters(e.g. ink contract based NFT transactions, commodities frame pallet based NFTs, EVM contract based NFT transaction, etc.), and creating the abstracted structs with unified traits to allow them to be easily plugged into the routers. This could also be viewed as a data adapter template.
    2.Base RoutersThis will include the basic functionality that will handle the parsing of the predefined structs supplied by the various data adapters.
    3.Substrate Based Chain Indexer AdapterThis milestone will include building out a data adapter specific to Substrate Archive as well as enhancing support for various common NFT specific events
    4.EVM Compatibility Layer AdapterImplementation of a data adapter for the EVM compatibility layer to allow us to process data from EVM based para-chains.

    Milestone 2 - Off Chain Data Sourcesโ€‹

    Estimated Duration

    • 4 weeks

    FTE

    • 2

    Cost

    • 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache License 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can run a local instance and / or fetch metrics using the application.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Base Marketplace AdapterThis will include the marketplace_adapter module & will allow users to plug in the API of the marketplace of their choosing. The module will contain a struct with generic traits related to the various events the can get emitted from various marketplaces (e.g. Auctions, bids, sales, etc.)
    2.OpenSea Marketplace AdapterImplementation of the data adapter for the OpenSea marketplace (e.g. transfer settings, supply models, transfer settings, etc.) as well as the standard marketplace adapter metrics (e.g. bid activity, frequency of listings & marketplace supply, etc.)
    3.Front-EndBase implementation of the front-end of the application
    4.AnalyticsThis milestone will include API endpoints & the front-end representation of the data to allows users to view key metrics (e.g. price trends, number of transfers, unique wallets, returning wallets) over edfined time periods.
    5.KPI ReportsLogic to allow users to receive KPI reports detailing their progress in emails

    Future Plansโ€‹

    Here at Health Hero we have been focusing on providing an instant health engagement platform for employees, patients, and community members, but have always been at the convergence of health engagement and gamification. We saw an opportunity in applying gamification to well-being and released a well-being driven digital collectible game. With the analytics suite we will be able to better determine what we can do to drive user retention and engagement within our platform while at the same time providing incentives for our user's well being.

    Additional Informationโ€‹

    We became aware of the Web-3 grants after our partnership with the Enjin team, which suggested that we should get in touch with the Web-3 Foundation. After discussing our main project with the team, they put us in touch with David Hawig given his previous experience in the healthcare space who then specifically went into the details regarding the grants and other types of support they can offer.

    - + \ No newline at end of file diff --git a/applications/ocelloids_monitoring_sdk.html b/applications/ocelloids_monitoring_sdk.html index 91c70c4a194..c396c6cc9cb 100644 --- a/applications/ocelloids_monitoring_sdk.html +++ b/applications/ocelloids_monitoring_sdk.html @@ -4,7 +4,7 @@ Ocelloids: Monitoring SDK | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ We will also use RxJS under the hood for our reactive operators and data streams. We are considering Mingo or similar technology for data transformation and filtering operations using MongoDB query language.

    Ecosystem Fitโ€‹

    Ocelloids SDK provides several advantages to the ecosystem:

    1. Ocelloids is the first open-source SDK to build complex monitoring applications. Its design provides a smooth experience for developers by abstracting away the underlying complexity of the monitoring logic.
    2. It provides reusable components that take care of common patterns for reactive sourcing and filtering, including call batching and multi-signature calls, which can be complex and time-consuming to implement manually.
    3. Ocelloids' domain logic for ink! smart contract monitoring will be a valuable addition to the Substrate ecosystem. Smart contract monitoring is an essential infrastructural piece for Dapp developers as seen by the popularity of services such as OpenZeppelin Defender and Forta detection bots. There is currently a lack of similar sophisticated services for ink! contracts and Ocelloids SDK will provide the necessary base to build powerful ink! monitoring applications.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    N/A

    Team's experienceโ€‹

    Marc Fornรณs has been designing and implementing software systems for 20 years. He is an expert in the area of distributed systems and data-intensive applications. His experience ranges from warehouse automation with radio-frequency terminals, to being the technical director of an airline post-sale revenue optimization software-as-a-service platform, generating millions in incremental revenue during eight years of operation. In the recent past, he was in charge of evolving a commercial Ethereum block explorer and bootstrapping an explorer for Substrate-based networks focused on the contracts pallet and ink! smart contracts.

    Xueying Wang pivoted to software development after completing an MSc. in Aerospace Engineering and has been in the industry for the past eight years. During this time, she pioneered conversational AI assistants for airlines, counting more than 20 assistants in production covering ten languages for customer service, FAQ and in-chat purchases. She also built a scalable publish-subscribe system to trigger actions on flight feed events for the automated agents. She participated in designing a composable Solid POD/RDF data browser and bootstrapping an explorer for Substrate-based networks focused on the contracts pallet and ink! smart contracts.

    We applied, implemented and delivered the following grants under our previous employer:

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic guide that explains how to set up and run a monitoring application.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.Core SDKAs described in Multi-chain Support and Core Components.
    2.ink! Contracts Domain LogicAs described in ink! Smart Contracts Monitoring.
    3.Example applicationA Node.js CLI tool to execute the ink! smart contract monitoring logic and log the alerts.

    Future Plansโ€‹

    Our long-term vision is to offer an end-to-end solution accessible as a web application to allow end-users to configure monitoring agents and subscribe to on-chain activities of interest. The web user interface exposes the domain logic components for monitoring use cases. For notifications, we will integrate with a notification centre solution, like Novu.

    We will start with contracts monitoring for parachains and solo chains that integrate pallet-contracts. Later, we plan to expand the offering to other pallets and networks, including custom pallets of parachains and solo chains. The key differentiator with existing solutions is the bundling of vertical logic per pallet with complex monitoring patterns.

    Additionally, we will explore integrating the core technology into Forta bots.

    Other enhancements:

    - + \ No newline at end of file diff --git a/applications/ocelloids_xcm_monitoring_service.html b/applications/ocelloids_xcm_monitoring_service.html index 1967c214751..918fa4f3eba 100644 --- a/applications/ocelloids_xcm_monitoring_service.html +++ b/applications/ocelloids_xcm_monitoring_service.html @@ -4,13 +4,13 @@ Ocelloids XCM Transfer Monitoring Service | Web3 Foundation Grants - +
    Skip to main content

    Ocelloids XCM Transfer Monitoring Service

    • Team Name: SO/DA zone
    • Payment Address: Fiat 04.05.2023, 16:37
    • Level: 2

    Project Overviewโ€‹

    This grant proposal is a follow-up to the Ocelloids Monitoring SDK, previously delivered and available here: https://github.com/w3f/Grant-Milestone-Delivery/pull/934

    The objective of this grant is to develop an open-source monitoring service using the Ocelloids SDK. This service will monitor XCM transfers across selected parachains. The primary purpose is to offer service providers integrating with a single chain (Asset Hub as starting point) and monitoring effects on other chains that are connected via HRMP and that use XCM as their message format. The service will support connecting to the configured networks through light clients in order to reduce infrastructure overhead for service providers. Users will have access to a self-hosted HTTP API to subscribe to XCM transfers and manage their subscriptions. A public Docker image will be published to facilitate service deployment.

    Project Detailsโ€‹

    The service will support bidirectional XCM transfers, namely asset teleports and reserve-based transfers, between selected parachains.

    The flow of the monitoring will work as follows:

    1. The service will monitor on the origin chain for the event xcmpqueue.xcmpMessageSent associated to the extrinsic sent by accounts of interest. The service will extract the XCM message hash from this event.
    2. The service will query the storage in parachainSystem.hrmpOutboundMessages at the block of the event to get all outbound messages and filter for recipient chain IDs that are supported. Subsequently it will decode the message data to get the set of XCM instructions to filter for combinations of instructions related to asset teleports or reserve-based transfers (i.e. ReserveAssetDeposited, ReceiveTeleportedAsset, WithdrawAsset, and DepositAsset). Then, it will get the blake2-256 hash of the message data to match it with the message hash obtained in Step 1. The service will store a persistent task to be matched in subsequent steps.
    3. At the destination chain, the service will monitor for the events xcmpqueue.success and xcmpqueue.fail. It will match the message hash extracted from these events with the message hash of the origin.
    4. It will send a notification to the configured webhook to inform of the status of the XCM transfer along with contextual information. See section Notifications for details.

    Before using the service, users will need to configure the supported networks and connection providers. An example configuration can be found in the section Service Configuration. We will support connections to the network using both RPC clients and light clients. Further details on supported Substrate clients can be found in the Supported Substrate Clients section.

    The service will expose an HTTP API for users to add subscriptions, specifying the channels they want to monitor and the accounts involved. Users can create multiple subscriptions and modify or delete them as needed. Users can also set up webhook endpoints to receive notifications related to their transfers. Detailed information about the API will be provided in the Subscriptions API section.

    To keep the project manageable, the current scope includes support for Asset Hub, Astar and Acala. In the future, we plan to expand support to include more chains.

    Notificationsโ€‹

    As previously mentioned, the monitoring service will accept webhook endpoints for delivering notifications. Initially, notifications will be provided for XCM message reception.

    The following types of notifications correspond to different scenarios:

    XCM Execution Success

    The XCM message sent from the origin chain was received and executed successfully. In this case, we will send an "XCM Transfer Success" notification, including contextual data such as the XCM message hash, block numbers of the XCM message on the origin and destination chains, sender account, beneficiary account, transferred asset and amount.

    XCM Execution Fail

    The XCM message was received at the destination chain but failed to execute correctly. In this case, an "XCM Transfer Fail" notification will be sent, including the XCM error returned in the event and additional contextual data.

    Service Configurationโ€‹

    The service will load a configuration file at startup, similar to the example provided below:

    {
      "networks": [
        {
          "name": "assethub",
          "id": 1000,
          "relay": "polkadot",
          "provider": {
            "type": "ws",
            "url": "wss://asethub-rpc"
          }
        },
        {
          "name": "parallel",
          "id": 2012,
          "relay": "polkadot",
          "provider": {
            "type": "smoldot"
          }
        }
      ]
    }

    Other common service options, such as the listening port for the Subscriptions API, will be configurable using environment variables.

    Subscriptions APIโ€‹

    API Methodsโ€‹

    POST /api/subscriptions/{id}

    Creates a new subscription document. To avoid the need for the client to store a server generated identifier, we will require the client to provide a unique subscription identifier. This will also allow the client to use meaningful identifiers e.g. 1000-2004-cohort1.

    Example request body:

    {
      "subject": "xcm-hrmp-transfers",
      "args":{ 
        "origin": {
          "network": "assethub",
          "senders": [
            {
              "accountId": "5GEWco3EGfM27Z9cAmVnzFnZ6Y7vkqNVvWM4NgQZj4n84Wh6",
              "type": "AccountId32"
            }
          ]
        },
        "destination": {
          "network": "moonbeam"
        },
      },
      "notification": {
        "type": "webhook",
        "url": "https://my-callback",
        "maxRetries": 50
      }
    }

    PATCH /api/subscriptions/{id}

    Accepts a JSON Patch operations array according to RFC6902

    Example:

    [
      {
        "op": "add",
        "path": "/args/origin/senders/1",
        "value": {
          "accountId": "5HWSEZr3DQXaN4Tk2Y9pYyAPKWeu28P94qeWWgUZ4k2mrbGB",
          "type": "AccountId32"
        }
      }
    ]

    The resulting patched document will be validated against the subscription document schema.

    DELETE /api/subscriptions/{id}

    Removes a subscription by ID.

    GET /api/subscriptions

    Returns the list of subscriptions.

    GET /api/subscriptions/{id}

    Returns the subscription document under the specified ID.

    PUT /api/subscription/{id}

    Replaces an existing subscription document by ID.

    Supported Substrate Clientsโ€‹

    We will support WebSocket RPC endpoints and light clients. However, please note that light client support may be limited due to its experimental nature.

    During preliminary testing, we identified some limitations:

    1. Using the Smoldot through Subtrate-Connect only support bootnodes configured with secure WebSocket connection. In our exploration, we've seen that only Astar and Acala have bootnodes with secure WebSocket connections. However, it is easy to overcome this limitation since Smoldot supports all the connection types. Reference: Github issue

    2. Some runtimes, such as Moonbeam, currently cannot be compiled by the light client. Reference: Github issue

    We will prioritize chains that are light client ready.

    Storageโ€‹

    We will provide persistent storage for operational data, including subscription configurations, processed block number and hashes, XCM messages and notifications. We will use Level as the database abstraction backed by LevelDB.

    Catch-up Mechanismโ€‹

    We will implement a mechanism to process missed blocks in case the monitoring service experiences downtime. For each processed block, its hash and block height will be saved in the database. When the service restarts, it will begin following the current finalized blocks. If the parent hash of the finalized block does not match the last-known hash stored in the database, the service will start processing the missing parent hash blocks until all missing ones are processed.

    Management Toolsโ€‹

    Since notifications and XCM message matching tasks are stored in the database and retried until success, we will provide a method to clear pending states. This is crucial to prevent indefinite retries of pending tasks. For example, if a webhook endpoint is changed while a notification is pending, it may never succeed.

    We will supply a script enabling administrators to inspect and remove XCM message matching and notification tasks from the database.

    Tech Stackโ€‹

    Ecosystem Fitโ€‹

    This project aligns well with the growing demand for robust tooling and infrastructure necessary to fulfill Asset Hub's vision of becoming the main place for asset management within the Polkadot ecosystem. To expand its user base, Asset Hub must provide a solution that abstracts away the technical intricacies of cross-chain transfers and enhances the user experience for managing assets across the expansive Polkadot ecosystem.

    The Integrations Team at Parity is already taking initial steps toward achieving this goal by working on the Assets Transfer API and the NoS launch script. These efforts target custodians, exchanges, and institutions, simplifying integration with Asset Hub and the construction of XCM messages. The importance of these tools, along with the overarching vision for Asset Hub, is comprehensively outlined in Iker's Polkadot forum post.

    The addition of the Ocelloids XCM monitoring service will enhance this toolkit, providing institutions with a straightforward method to track their cross-chain transfers. This corresponds to step 4 of the "Withdrawals User Journey Example" in Iker's post, as detailed here.

    With the inclusion of support for light clients in the service, institutions will experience a substantial reduction in infrastructure overhead since they will no longer need to run parachain nodes to monitor their transfers.

    Furthermore, the demand for a generalized monitoring solution with XCM support has been highlighted in discussions within the Polkadot community, as illustrated in this Polkadot forum post: Generalized multichain monitoring solution.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Marc Fornรณs
    • Xueying Wang

    Contactโ€‹

    N/A

    Team's experienceโ€‹

    Marc Fornรณs has been designing and implementing software systems for 20 years. He is an expert in the area of distributed systems and data-intensive applications. His experience ranges from warehouse automation with radio-frequency terminals, to being the technical director of an airline post-sale revenue optimization software-as-a-service platform, generating millions in incremental revenue during eight years of operation. In the recent past, he was in charge of evolving a commercial Ethereum block explorer and bootstrapping an explorer for Substrate-based networks focused on the contracts pallet and ink! smart contracts.

    Xueying Wang pivoted to software development after completing an MSc. in Aerospace Engineering and has been in the industry for the past eight years. During this time, she pioneered conversational AI assistants for airlines, counting more than 20 assistants in production covering ten languages for customer service, FAQ and in-chat purchases. She also built a scalable publish-subscribe system to trigger actions on flight feed events for the automated agents. She participated in designing a composable Solid POD/RDF data browser and bootstrapping an explorer for Substrate-based networks focused on the contracts pallet and ink! smart contracts.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-Time Equivalent (FTE): 2
    • Total Costs: 28,000 EUR

    Milestone 1โ€‹

    • Estimated duration: 2 months
    • FTE: 2
    • Costs: 28,000 EUR
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic guide that explains how to set up and run the monitoring service.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile to ease the deployment and execution of the service. A Docker image of the service will be published in Docker Hub and Github Container Repository.
    1.XCM Monitoring ServiceThe XCM monitoring service that supports asset teleports and reserve-based transfers between the following parachains: Asset Hub, Astar and Acala. The service will feature what was described in Project Details.
    2.Management ToolsAdministrator scripts to inspect and delete pending XCM messages matching and notification tasks, as described in Management Tools.

    Future Plansโ€‹

    For the XCM monitoring service, we have plans to expand its capabilities and reach which include:

    1. Support for More Networks: We plan to broaden the range of networks supported by the XCM monitoring service, enabling a more extensive and inclusive monitoring ecosystem.

    2. Support for More XCM Protocols: We will add support for XCMP when ready.

    3. Enhanced Notifications: Depending on user requirements and community feedback, we will extend our notification capabilities. This may involve providing notifications for asset transfers' initiation, such as when the block containing the XCM transfer is finalized on the origin chain. We are also considering notifications for when XCM messages sent through HRMP are processed on intermediate chains.

    Our long-term vision for Ocelloids extends beyond just monitoring XCM transfers. We aim to create a hassle-free, comprehensive monitoring portal for Substrate networks and smart contracts within the ecosystem. This portal will offer a set of advanced features, including:

    • Ready-to-use monitoring logic, i.e. monitoring programs, for the entire ecosystem. The XCM monitoring logic built through this grant could be one such monitoring program available.
    • Marketplace for monitoring programs where users can subscribe to the programs that correspond to their needs.
    • Advanced capabilities: anomaly and attack detection, machine learning, and forecasting.
    • Real-time actionable insights on network, contract performance, compliance, and security.
    • Multiple data centres for global, high-availability monitoring.
    • Seamless integration with existing systems like Prometheus and SIEM.

    In summary, our future plans encompass not only expanding the technical capabilities of the XCM monitoring service but also positioning as a central hub for monitoring and managing Substrate networks and smart contracts within the broader multi-chain ecosystem.

    - + \ No newline at end of file diff --git a/applications/odyssey_momentum.html b/applications/odyssey_momentum.html index 2595f3b7e09..053b9124f96 100644 --- a/applications/odyssey_momentum.html +++ b/applications/odyssey_momentum.html @@ -4,7 +4,7 @@ Odyssey - Momentum | Web3 Foundation Grants - + @@ -24,7 +24,7 @@ We see the metaverse as a new social communications medium and the potential driver for mainstream adoption of web3 technologies. The potential is designing and launching entirely new user experiences, rather than doing the web2/2d consumer experience and slapping a 3D background on it (a.k.a. a recorded concert in Fortnite that you can watch/consume or selling land). When unlocking the dotsama/ next generation of on-chain applications we enable consumers to become co-creators.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Odyssey has over 30 people working on Momentum and is still growing. Odyssey works in tracks with dedicated team members. The Token Track Team will be primarily responsible for building the Substrate Pallets.

    OVERALL ARCHITECT: Anton Starikov (CTO)

    TOKEN TRACK TEAM

    All team members are solely dedicated to the token Track.

    Contactโ€‹

    Team's experienceโ€‹

    Anton Starikov has been architecting and leading development of software solutions for over 20 years in academic (computational physics) and industrial (Shell, AVL) settings. In addition, he was working and consulting on the topics of optimization on various levels (from hardware level through software up to the processes). Currently working as CTO of Odyssey, Anton is performing the role of platform architect.

    Dave Hoogendoorn is an experienced programme manager and has been active in the space for over 5 years. Dave is co-founder of WEB3SCAN (W3F Grants WAVE 1 participant with Polkascan), former Kusama Treasury Council member (Polkascan multi-sig) and previously held a board position at the Polkascan Foundation. Dave has been following Substrate and the Dotsama ecosystem from the early beginnings.

    Denis Cavalli is a Senior Rust Software Engineer with a background on embedded systems and R&D. Since 2021 engaged with the WEB3 environment, has experimented on Ethereum/Solidity, Solana and worked professionally with Helium in 2022. Now is focused on building the metaverse that will empower people collaboration on the Dotsama ecosystem, using Substrate as the main framework.

    Tim Jansen is a Polkadot Ambassador and has been working on crypto and blockchain for over 7 years. He has developed smart contracts on Ethereum, implemented decentralized storage solutions such as swarm and IPFS, consulted on blockchain at ISO, audited smart contract code of TNO, launched several live applications using blockchain for auditing, supply chain and SSI at Visma and has a deep understanding of cryptography including zero knowledge proofs. In his free time he researches and experiments with new crypto technologies.

    Team Code Reposโ€‹

    GitHub accounts of our team members:

    Team LinkedIn Profiles (if available)โ€‹

    Organisation:

    Team:

    Development Status ๐Ÿ“–โ€‹

    Momentum is currently built as can been seen on GitHub. Momentum Release notes are regularly updated and can be found here.

    Treasury Proposals regarding the Kusamaverse can be found here:

    Our Discord Channel and Twitter Channel are used as general means of communication towards the Momentum and Kusamaverse community. It provides lots of information about community engagement, new developments and improvements.

    Academic references:

    Other channels are YouTube and our foundation website .

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Note: Please follow the disussion github for details on the costs.

    Milestone 1 Stake Palletโ€‹

    This milestone delivers at least one (but maybe more) pallets to enable staking in Momentum's User Profile, World, Space and Subspace NFTs (or possibly any asset) in order to incentivize the creators/ owners and reward the stakers.

    NumberDeliverableSpecification
    0a.LicenseGNU General Public License v3.0.
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1a.Basic stake palletStorage V1 defined and implemented as described in Milestone 1
    1b.Basic stake palletStaking / Unstaking on NFTs operational
    1c.Basic stake palletHandling Rewards operational
    2a.Extended stake palletStorage V2 defined and implemented as succesor of V1
    2b.Extended stake palletFractionalized NFTs implemented
    2c.Extended stake palletConfigurable parameters and rewards operational. Staking rewards are divided using some formula using configurable parameters per entity, that sets the ratio between the staker, the entity that has been staked in, and the commission an entity received and the amount received by the Treasury.
    2d.Management palletOptional pallet for managing the parameters and rewards and/or managing the payment of the rewards.
    3a.Generalized stake palletEnabling data type configuration to enable users to configure their data type at instantiation on the runtime.
    4a.Generalized stake palletDelivery of the Stake pallet (maybe more than one) enabling Staking on assets (NFTs) and rewards management including documentation.
    4b.Benchmarking report(s)Benchmarking reports available
    4c.Pallet(s) in productionPallet integrated on the parachain runtime as an example of the first implementation of the NFT stake pallet, enabling active maintenance of the repo based on lessons learned.

    Future Plansโ€‹

    Odyssey is planning a 25+ web3 community teams 4-week hackathon in May 2023, with leading Dotsama parachain and ecosystem parties, as part of a 9 month innovation program. During this program teams are guided to build new user experiences using Momentum and Dotsama tech and test how the DRIVE token strengthens their usecase. In September 2023 we will launch our DRIVE mainnet as a parachain on Kusama.

    In the coming years we will keep investing in the Kusamaverse and momentum ecosystems, meaning:

    Momentum provides a novel social communications medium and provides the infrastructure for a new user experience where social, economic and cultural activities, both on-chain and off-chain are intertwined. In these early beginnings we are only scratching the surface of what is possible. But we are convinced we are at the start of an exciting journey and with Momentum we are in for the long run.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?
    We have Personal recommendations from people at Parity including Raul Romanutti and Daniel Cake-Baly. We also have relations with other parties that have successfully applied for WEB3 Grant

    We have not yet applied for any grants with the WEB3 Foundation.

    Other information
    Last but not least, we are proud to we have the Sovereign Nature Initiative organising a Hackathon in Momentum for the Kenya Wildlife Trust. Momentum enables true collaboration happening in real-time among 13 teams spread over 5+ countries. SNI has been hosting events in Momentum up to the 9th of November. Check it out on SNI World.

    - + \ No newline at end of file diff --git a/applications/on-chain-cash.html b/applications/on-chain-cash.html index 8de83d32dfd..ee14f16de78 100644 --- a/applications/on-chain-cash.html +++ b/applications/on-chain-cash.html @@ -4,7 +4,7 @@ On-chain cash exchange | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ Under this project the main idea of the service will be redeveloped in a confidential and trustless manner using a smart-contract in a blockchain: each coupon will get two keys (codes) - a private and a personal one: the public one will be stored in the smart contract and the private key will be known only to a buyer/user from the entire coupon (it may be encrypted in a QR-code on the coupon or written in any other safe manner). The destination wallet address for the transaction will be signed by the private key so that no destination wallet spoofing could be done by scams.

    The new proposed smart-contract will become an on-ramp for fiat currencies: a native or non-native token of choice could be issued/exchanged for fiat within a coupon redemption. Some of anticipated ways of fiat-to-crypto exchange:

    As the token natively represents the bridge from fiat to crypto it can also enable an integration with a DeFi/CeFi environment on top and development of the same further down the road: further parts of the project include developing of a payment widget, that can make a transaction to a target wallet with a crypto-currency of choice without even issuing a personal wallet โ€“ straight coupon-to-crypto payments.

    Immediate benefits of the token system would be the integration with global FinTech platforms and NFT markets and potentially expansion of the coupon system to using coupon-issued stablecoins for all transactions. The key benefits are:

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Our team has extensive expertise on multiple levels starting from progressive vision all the way down to software and solution development. This blend of knowledge and skills ensure we tackle the most ambitious challenges and come up with commercially successful solutions in FinTech industry. Natural ability of some of the team member to navigate and predict future technological trends combined with technical experience and project management skills of other members translates into the clear roadmap.

    Gregor Knafelc is a trailblazer who developed a unique business model and software for selling crypto vouchers on POS. He built one of the most recognized regional brands serving regional bluechip companies and established a strategic partnership with the state oil company Petrol and a national Telecom. Gregorโ€™s company disrupted the crypto market being the first to start selling crypto through ATMs.

    Andrej Muzevic for the last 25 years acts as an Advisor and Investor for high tech businesses empowering and mentoring bright minds who build technologies of the future. He has the most experience in Blockchain, CeFi, DeFi, Data and other knowledge intensive areas. Andrej is also a very active member of Etherium Community.

    Sergey Cymbal is an experienced executive, leader and visioner responsible for the most disruptive innovations initiatives across Oil/Gas, Utilities, and Telcos in Russia. Ex-member of Sochi Olympics HQ, responsible for digitalization, Smart grid evangelist. Blockchain early follower, participates in several crypto initiatives.

    Sergey Zolotukhin has over 20 years of experience in R&D and software development with a deep focus on Machine Learning, Neural Networks and Mobile solutions design in Telcos and Pension Funds. Led several enterprise machine learning project, has various experience in crypto and blockchain development.

    Dmitrii Putilov has over 17 years of experience leading the teams creating and maintaining high availability sites. His portfolio contains creation of the robee.io investment platform included in top500 in coinmarketcap.

    Dmitrii Volodin has a background in IT. For over 15 years he has been helping customers build, implement, and maximize value of their critical IT infrastructure and solutions across Enterprise, Manufacturing and Healthcare industries.

    Ilia Shavrin is a solution architect and full stack software developer with over 12 years of experience in high load enterprise applications. His most recent focus is on blockchain and creation of decentralized applications.

    Anton Shramko is an experienced developer with 7 years of experience on various positions, including solution architect in Krypton. Anton active contributor to open source and blockchain communities, he is also a frequent speaker in DevCon conferences.

    Ksenia Baranova is an QA test engineer with over 5 years of experience. Ksenia has exceptional knowledge and skills in the field. She is highly referred within this team, as well as by her former teams.

    Alexey Vexin is product owner and project manager with 10+ years of experience in managing complicated telecoms and IT projects in Telco, Utilities and Governmental sectors with deep focus on business process management. Led a dozen of federal scaled projects for IT systems implementation and industry scaled technology development, standardization and implementation.

    Anton Borisov is a DevOps Engineer with broad experience. For over 15 years Anton was supporting, administering, and maintaining secure networks, servers, and clusters. He also has versatile experience with CI/CD, IT Infrastructure Monitoring, and Kubernetes on-premise and in Cloud. One of the most recent projects Anton participated in was building a first on chain casino.

    Bela Supernova has already apllied for a grant OpenEHR Integration

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    BitIns is a company that since 2016 has provided the fastest and easiest access to Bitcoin via buying a Bitcoin coupon, which is sold in Slovenia through partner shops and via SMS messages.

    Development Roadmap ๐Ÿ”ฉโ€‹

    At this stage weโ€™ll execute three deliverables:

    Milestones 3

    The project will be split in 2 milestones that will be supported by a group of 2 developers, 1 UI/UX designer, 1 PO and 1 QA.

    Overviewโ€‹

    Milestone 1 โ€” Design and development of an Ink! smart contractโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can run our smart contract and send test transactions, which will show how the functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.Liquidity pool management methodsWe will create methods for keeping and managing main liquidity pool, withdraw/top-up assets from/to main liquidity pool (service provider's pool)
    2.Coupon data storageWe will create a method for storing issued and sold coupons in the smart contract
    3.Coupon registrationWe will create a coupon registration method (for each registered coupon code an appropriate assets volume will be locked in the liquidity pool) and coupon code ZK-validation method (to prove to a coupon seller, that the coupon is registered and thereโ€™s enough liquidity locked for it without showing the private key)
    5.Coupon liquidationWe will create a coupon burn method upon itโ€™s redemption and corresponding transaction

    Milestone 2 โ€” Design and development of system management toolsโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can run our smart contract and send test transactions, which will show how the functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains what was achieved, how to use the new Dapp and what benefits what are the benefits of using the system
    1.Centralized management back-endWe will develop service providerโ€™s CLI tools for coupon lifecycle management including: coupon generation algorithm implementation, coupon storage DB, coupon registration in a blockchain. Also it will include tools for liquidity pool management โ€“ assets top-up or withdrawal, get balance. Each coupon will consist of a public and a private key. Public keys will be delivered to the smart contract for operations. Private keys will be accessible only to buyers and will validate the transaction upon coupon redemption. Upon registration of a coupon in the smart contract the appropriate sum of tokens will be locked in the service providerโ€™s pool as a collateral for the coupon balance.
    2.Buyer's web interfaceWe will develop a web UI for coupons' redemption for users that already have an existing wallet with non-zero balance. Validation of the coupon will be made straight by the smart contract with gas taken from the userโ€™s wallet.

    Future Plansโ€‹

    Above defined deliverables are just a start position for future development of the product โ€“ a unified platform for users for easiest exchange of their fiat assets to crypto and with a personal wallet that can be used for payments in the ecosystem without excessive transactions and gas fees. Also, this is going to be a service for sellers and service providers to add straight fiat-to-crypto payments to their apps and smart contracts. The easiest way to perform a reliable yet confidential way of payments.

    Our future plans for the project:

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Our team includes blockchain enthusiasts who have strong hi-tech experience and strive to implement their ideas and give maximum value to emerging blockchain and crypto markets. That's why the Grants Program is a self-evident knowledge for our team.

    - + \ No newline at end of file diff --git a/applications/open-node-framework.html b/applications/open-node-framework.html index 5fc82bf0d09..4f13332a7ea 100644 --- a/applications/open-node-framework.html +++ b/applications/open-node-framework.html @@ -4,13 +4,13 @@ Open Node Framework | Web3 Foundation Grants - +
    Skip to main content

    Open Node Framework

    • Team Name: Phala Network
    • Payment Address: DAI at 0x50DC97D0345d61B4D096e15313d50b6506972e5F
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Open Node Framework is an end-to-end DevOps (SRE) solution to deploy a Substrate node network for staking and other purposes. It's designed to address high availability, scalability, and flexibility, using the modern technology stack.

    Project Detailsโ€‹

    While developing a Substrate based parachain, we found it challenging to operate and maintain different types of nodes. Validators and collators require high availability and key security. Bootnodes and RPC nodes require high performance and flexible scalability. So Open Node Framework has the following design purpose:

    • Parachain first: Focus on the requirement of parachains
    • Flexibility: Integrate with any Substrate based blockchain easily
    • Multipurpose: Run validators, collators, full nodes, bootstrap nodes, or RPC nodes
    • High Availability: Add redundancy to nodes (validators & collators) for higher security and robustness

    There are a few existing projects that can partially meet the above requirements. Among them, Polkadot Deployer is a k8s-based network deployment and monitoring tool. However, it's mainly designed for bootstraping and operating a full Polkadot, which may not meet the typical requirement of running a parachain. Therefore we think it's a good idea to iterate on it and make it parachain ready and address the features mentioned above.

    Tere are other interesting projects as well. Polkadot Secure Validator implements a validator setup for Polkadot and Kusama coming with a monitoring system Polkadot K8s Monitor. Gantree is a W3F Grant funded Substrate DevOps framework supporting customized Substrate node. However it lacks the support of node HA, and like the other two projects, doesn't support cross-datacenter deployment, and is not built on modern Kubernetes stack.

    Open Node Framework wants to feature:

    • Multi IT infrastructure
      • Native Kubernetes architecture
      • Cross-datacenter / cloud providers deployment with a central dashboard for daily management
      • Support multiple cloud providers with Terraform
      • Scale up to a large node network easily
    • High availability
      • Upgradable node binary
      • Blockchain database backup and recovery
      • DDoS mitigation
      • Collator and validator redundancy
    • Hardened security
      • Ops jump servers / VPN behind a firewall
      • RPC authentication
    • Monitoring
      • Dashboard and data visualization with Prometheus and Graphana
      • Grafana / Loki stack for metrics, logging, tracing
    • Flexible node integration
      • Replacible Docker images for node binaries

    Open Node Framework has its MVP implementaion availabe at our Github Repo. It implemented a basic infrastructure as shown in the above diagram. The components are deployed in a Kubernetes cluster with the binaries defined by Docker images. It supports both Terraform and Google GKE deployment, and it has been tested on Polkadot and Phala Network testnets.

    In this grant, we are going to expand Open Node Framework in aspects:

    1. Switch the code base to a fork of w3f/polkadot-deployer
    2. Enable parachain and 3rd party binary config
    3. Cross-datacenter deployment with a central place to manage and view the dashboard
    4. HA collator validator setup

    We are interested in the following areas but want to leave them for future work:

    1. Secure Enclave protected Key Management Service
    2. Integrate with indexing tools like SubQuery
    3. Comprehensive UI for the end users

    Open Node Framework doesn't aim to build everything from scratch. We prefer to utilize the existing open source tools and potentially contribute to them. We plan to work on a fork of Polkadot Deployer, and contribute it to the upstream if possible.

    The other building block candidates are:

    Ecosystem Fitโ€‹

    Open Node Framework provides the infrastructure to deploy any Substrate based parachain or standalone blockchain for multiple purposes, including running a bootstrap network, a validator cluster, a full node RPC service network, or a temporary simulation network for experiments, with all the essential infrastructure. It allows other Substrate blockchains to integrate with it easily.

    The project serves standalone the Substrate blockchain, parachain, and relay chain operators, offering them a flexible and user-friendly infrastructure framework with production best practice.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Hang Yin: Lead & Software Engineer
    • Jun Jiang: Project Manager & Software Architect

    Contactโ€‹

    • Registered Address: 3 FRASER STREET #05-25 DUO TOWER SINGAPORE (189352)
    • Registered Legal Entity: HASHFOREST TECHNOLOGY PTE. LTD.

    Team's experienceโ€‹

    Open Node Framework is an open source project initiated by core members of Phala Network and other contributors. Phala Network is a confidentiality layer for Polkadot that provides general purpose confidential smart contract to parachains on Polkadot and Kusama. The Phala team got two W3F General Grants: pDiem and Web3 Analytics. Phala has launched 3 testnets and got 1200+ nodes and 2600+ registered miners.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    The MVP of Open Node Framework is available on Github but we are going to switch to build on polkadot-deployer on our fork instead. Please see Project Details.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 22,000 USD

    In the milestone deliverable table, the features marked with "(addition)" means add-on feature to the upstrea polkadot-deployer, and "(integration)" means some changes in the upstream are required.

    Milestone 1 - Basic features and operating security improvementโ€‹

    • Estimated Duration: 3 months (ETA: Mar 15, 2022)
    • FTE: 4
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDesign docs including the architecture of the system and the design choices (including which open source projects to integrate). Inline documentation of the config files.
    0c.Testing GuideA guide describing how to run the tests covering the cases in 0b.
    0d.Article/TutorialWe will publish a tutorial and an workshop that explains how the project can be used to deploy different types of blockchain network.
    1.Parachain supportAdd parachain config support. (addition)
    2.Custom Substrate supportEnable custom Substrate blockchain integration with the example configs to integrate with Substrate sample node (substrate/node/cli) (addition)
    3.Operating scriptsApply the declarative configs to: scale up / down the nodes (addition)
    4.Monitoring, and loggingImplement the monitoring infrastructure with Prometheus and Loki to collect metrics and logs. (integration)
    5.Grey releaseIntegrate with CI/CD pipeline and enable greyscale release inside the cluster. (addition)
    6.More deployment modesTemplates to deploy bootstrap nodes, API nodes, and simulation network. (addition)

    Milestone 2 โ€” Advanced Featuresโ€‹

    • Estimated Duration: 1.5 month (ETA: Apr 30, 2022)
    • FTE: 4
    • Costs: 12,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide high availability and session key management design docs, inline documentation of the config files and a basic tutorial that explains how to add HA setup, backup nodes, and alerts to the basic configurations as in M1.
    0c.Testing GuideA guide describing how to run the tests covering the cases in 0b.
    0d.Article/TutorialWe will extend the workshop to show how to deploy a hardened node network.
    1.Backup node and recoveryAdd sync node type and database backup & recovery routines. Add scripts to trigger and minotor the process. (addition)
    2.Session key managementAdd the script to interact with the node and the blockchain to generate and rotate the session keys, and add routines to migrate keys between validators and collators (or mount the keystore db to the assigned validators) (addition)
    3.AlertsDefine the collator / validator related warnings and metrics from Prometheus and Loki and add them to the alerm manager. (integration)
    4.HPA scalingAutomatically scale the storage and the size of the cluster based on load of the nodes. (addition)
    5.Authenticated RPCAdd the authentication layer to the node RPC for node operation (integration)

    Future Plansโ€‹

    Besides the future work we described in Project Details, the general plan is to make Open Node Framework an open and friendly open source project, lowering the barrier for Susbstrate developers to run their network. So we intend to use the project as a start point to build a developer community, and attract more contributors to sustain it.

    - + \ No newline at end of file diff --git a/applications/openPayroll.html b/applications/openPayroll.html index a6154b21602..a677d6111f8 100644 --- a/applications/openPayroll.html +++ b/applications/openPayroll.html @@ -4,7 +4,7 @@ Open Payroll | Web3 Foundation Grants - + @@ -20,7 +20,7 @@ It has some passing similarities with opengov and treasury, but our project is a smart contract instead of a pallet and is geared towards a much more simple use case. We found a smart contract that could be helpful for inspiration but it doesn't have the same approach as our vision. (https://docs.openbrush.io/smart-contracts/payment-splitter/)

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    We don't have a legal structure. We are a group of developers that want to build together. Probably we will create a legal structure for future projects. We plan on dogfooding the project and make our payments through the smart contract we are building

    Team's experienceโ€‹

    We know each other from different places but we began working together at the Polkadot Blockchain Academy 2023 in Buenos Aires, Argentina. We formed a tight knit study group and helped each other to better navigate the Academy's teaching and to complete the myriad of coding assignments we needed to do in order to get certified as a Blockchain developer, which we all accomplished.

    Here are some brief backgrounds on each of us:

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We started to work after we finished the Polkadot Blockchain Academy. We explored the Polkadot ecosystem and we found that there is a lot of potential for solving real world community problems with the technology currently available.

    To ensure a smooth and intuitive user experience, we've built a Wireframe that outlines the user flow of the project. This wireframe serves as a visual representation of how the user will interact with the project and provides a clear roadmap for the design and development process. By creating a wireframe at the early stages of development, we can identify any potential usability issues and make adjustments before investing significant time and resources into the design and development process. Ultimately, this will lead to a better user experience and a more successful project.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Described in project details.

    Overviewโ€‹

    Milestone 1 โ€” UI and Contract Developmentโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can generate its own smart contracts. Corresponds to step 7 of the Project Details.
    0c.Testing and Testing GuideThe code will have unit-test coverage to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a docker container with current milestones deliverables to easily run the application. The functionality to be implemented corresponds to step 6 of the Project Details.
    1.Desing frontend interface (Figma)The functionality to be implemented corresponds to step 1 of the Project Details section.
    2.Develop the interface based on the previous task result (React, Next.js, PolkadotJS wallet extension, Jest)The functionality to be implemented corresponds to step 2 of the Project Details section.
    3.Develop the payroll smart contract (Ink!, Rust)The functionality to be implemented corresponds to step 3 of the Project Details section.
    4.Integrate the UI with the contracts.The functionality to be implemented corresponds to step 4 of the Project Details section.
    5.Quality AssuranceThe functionality to be implemented corresponds to step 5 of the Project Details section.

    ...

    Future Plansโ€‹

    After the completion of this project, we would love to broaden its scope.

    Multiple Assets

    Pallet

    Cover Different Scenarios

    Token Streaming

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Polkadot Blockchain Academy

    - + \ No newline at end of file diff --git a/applications/openbrush-follow-up-2.html b/applications/openbrush-follow-up-2.html index 6996e583a5f..cb26dbe2280 100644 --- a/applications/openbrush-follow-up-2.html +++ b/applications/openbrush-follow-up-2.html @@ -4,7 +4,7 @@ OpenBrush | Web3 Foundation Grants - + @@ -46,7 +46,7 @@ PR&Marketing specialist with global brands work experience since 2018. Master degree Business Economics. Has worked with global international beauty brands: Lancรดme, Biotherm, Yves Saint Laurent, Kerastase, Valentino Beauty for 3 years. Blockchain PR&Marketing since 2021.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    The project is already in release 1.6.0.

    PSP22 - https://github.com/w3f/PSPs/pull/25

    PSP34 - https://github.com/w3f/PSPs/pull/34

    PSP37 - https://github.com/w3f/PSPs/pull/37

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    We have decided to describe a full roadmap of an OpenBrush here, with estimates. However, the funding we request at this stage is for milestones 6-7.

    Previous workโ€‹

    Milestone 1 - Implement reusable basic contracts in ink!, similar to Openzeppelinโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will enhance inline documentation, and create a tutorial on how to import/customize contracts.
    0c.Testing GuideWe will add unit tests to cover all basic logic and integration tests with Redspot, to verify that all works via contract-pallet
    1a.Fungible token(Erc20)We will implement reusable Erc20 analog on ink!
    1b.Non Fungible token(Erc721)We will implement reusable Erc721 analog on ink!
    1b.Multi token(Erc1155)We will implement reusable Erc1155 analog on ink!
    2a.AccessControlWe will implement reusable AccessControl analog on ink!
    2b.OwnableWe will implement reusable Ownable analog on ink!

    Milestone 2 - Simplify usage of library. Add a new features which extend ink!. Provide macroses that will allow creation of your own base implementationโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will enhance inline documentation, update previous documentation based on simplifications, documentation for new features.
    0c.Testing GuideWe will test macros, update tests according to new features, simplifications.
    1.Remove boilerplate codeWe will provide a macro which will allow to remove boilerplate during usage of library(Library provides implementation on rust level in internal trait. User must reuse internal implementation with ink! messages. Our macro will simplify it). It will simplify the code structure and usage.
    2.Derive for storagesWe will provide a derive macro to generate implementation for storage's structs. It will simplify integration of fields inside of struct and implementation of storage's traits for that fields.
    3.Support default implementation in external traitsWe will add mnemonic support of default implementations inside of trait definition(traits defined via #[ink::trait_definition]). It is mnemonic, because under the hood we will generate internal trait with default implementation that will be used in external trait.
    4.Support of modifiersWe will add support of modifiers, like in Solidity. User will be able to mark some function to use modifiers and it will simplify the code.
    5.ReentrancyGuardWe will add implementation of ReentrancyGuard
    6.Implement additional useful contractWe will implement PaymentSplitter, TimelockController and etc.

    Milestone 3. Reduce the size of Erc20 contractโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a report of how much each optimization reduced the size.
    1.Reduce the size of Erc20 contractNow the most critical moment with ink! is the huge size of contracts. This issue described the problem very well. The parity team works in this direction, and we want to help with ink! side. The ink! team created issue 906, 916 and 910. We want to briefly(not full change, only minimal changes to reduce the size) implement them and provide a report(re-working data structure, reducing monomorphization, using dynamic dispatch in some cases). Based on this report, the ink! team can decide how better to implement them and which part is more critical. During the implementation, we will build examples with our version of ink! (also maybe we will modify some sub-crates). So the output of this work is a report and custom version of ink!. The code can be reused, or if ink! team agrees we can try to implement these issues by ourselves later as separate work.

    Milestone 4. Pre-release - Standardization of tokens contracts. Implement extensions for contracts. Documentationโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide inline documentation for macros, create a tutorial on how to use macros in your own project, with a detailed description of how it works inside.
    0c.Testing GuideWe will add more tests to cover all macros, update tests according to new changes.
    1.Create Proposal for Fungible tokenWe will create a proposal for standardization of Erc20 token in case of ink! and contract-pallet. Based on the final decision regarding the proposal update the implementation in library.
    2.Implement extensions for tokensWe will implement extensions for Erc20, Erc721 and Erc1155 tokens.
    3.Create Proposal for Non Fungible token and Multi tokenWe will create proposals for NFT and multi token, when proposal for FT token will be approved. Based on the decisions of these approves, we will update implementation in library.
    4.Use original ink! instead of our ownWe will use ink! 3.0-rc6 version(or a new one if it will be compatible) instead of our own version of ink!.
    5.Refactor the contracts to be compatible with PSPsWe will refactor the contracts according to the PSP.
    6.Refactor the structure of the OpenBrush to provide agnostic traitsWe will refactor the structure of the OpenBrush to provide traits for each implementation of the contract without restriction and implementation related information:
    - Traits will be defined in a separate module.
    - The default implementation of that trait for a contract will be provided via unstable feature #![feature(min_specialization)].
    - We will provide a new macro to generate a wrapper around a trait. That wrapper can be used for cross-contract calls. So the user is enough of the trait definition to do a cross contract call.

    Milestone 5. Release - Contribution to inkโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide inline documentation, example of usage of extensions.
    0c.Testing GuideWe will add tests for extensions and for a new changes from ink! side.
    1.Contribute to ink! with fixing of eventsWe will help to fix the issue with events.
    2.Re-work the storage of contractsWe want to resolve the issue.
    3.Refactor of implementation according changes in ink!After changes in ink! we will refactor the code of library.

    Current work - Scope of this Grantโ€‹

    Milestone 6. Upgradable contractsโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a documentation of how to write upgradable contracts
    1.Implement delegate_call in contract-palletThe ethereum has a delegatecall function that helps to achieve upgradable functionality in contracts. We will add the support of that function into the contract-pallet. With that function the OpenBurhs will provide the implementation fo Proxy and Diamond patterns.
    2.Implement set_code_hash in contract-palletThe usage of Proxy pattern adds overhead during each execution of the contract. It increase the cost of execution, and size of the proof of verification. Instead of delegate_call the contract-pallet can provide a separate function to change the source code fo the contract. It simplifies the flow and allow to easy upgrade the contract in the future.
    3.Import delegate_call in ink! and update Proxy exampleSupport of delegate_call on ink! level and providing a user-friendly abstraction. The ink! already provides an abstraction for cross-contract communication, we will extend it to support delegate_call.
    4.Implement Diamond Standard in OpenBrush with ink!We will provide the implementation of the Diamond standard in OprnBrush. Anyone can easily reuse the implementation or use traits to interact with contracts.
    5.Implement Diamond Standard on raw Rust without ink!Right now the ink! adds a lot of overhead and increases the size of the contract. Implementation of the Diamond standard with raw rust will show the overhead impact and will provide an additional example for WASM developers on how to write contracts without ink!.
    6.Create an upgradable analog of each contract in OpenBurshOpenBrush provides many implementations of different contracts. With upgradability, we also need to provide an upgradable version of each contract.
    7a.Marketing - Write down article about OpenBrushWe are going to write the article abot the importance of OpenBrush and applied usage of it. Moreover, 727.ventures team will promote it in Twitter, Medium etc.
    7b.Marketing - Create 2 educational video for OpenBrushWe are going to work on educational video materials for OpenBrush and ink! Community. We see a huge gap in knowledge, understanding, and vision for the whole community in that sphere. Moreover, 727.ventures team will promote it in Twitter, Medium etc. We will create a lower entry threshold for newcomers by this educational program.

    Milestone 7. AssetPallet chains extensionโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a report of how to transition from PSP22 on contract level to PSP22 on pallet level. Add documentation about the workflow of PSP22 and Statemint parachain.
    1.Implement AssetPallet chain extension on substrate level to work with pallet-assets in runtimeWe will implement a chain extension on the substrate level that allows interaction of contract with pallet-assets. Any network with that chain extension allows developing contracts that store information regarding fungible tokens on the pallet-assets level instead of the contract level. That allows to reduce the size of PSP22 contracts and provide SCM support by default for fungible tokens.
    2.Implement AssetPallet chain extension in OpenBrushUsage of chain extension requires implementation on the level of the contract too, so we will implement it in OpenBrush. Anyone will be able to reuse chain extension.
    3.Implement PSP22 with that chain extension in OpenBrushThe OpenBrush will provide a default implementation for PSP22 implemented via AssetPallet extension. It will behave in the same way as PSP22 but the information will be stored on the level of pallet-assets.
    4.Create standards for AssetPallet Chain Extension and for PSP22Asset extensionThe AssetPallet extension can be used by anyone and on any network. It requires the standardization of the methods and data types that are supported. We will create standards for that in the PSP repository.
    5.Advanced ink! unit testing frameworkAdd support to the contract deployment, chain extension registration, and smart contract cross-contract calls into the ink! unit test framework.
    6.Support of XCM and cross transferring of PSP22 tokensIf the support of XCM by the pallet-assets is not ready, we will participate in the development process to speed up it. The final step is that anyone will be able to transfer assets of pallet-assets, that are managed by the contract, between parachains freely.
    7.Add support for ink! 4.0We will update OpenBrush to be compatible with ink! 4.0 releases
    8a.Marketing - Create 2 educational video for OpenBrush/ink!We are going to work on educational video materials for OpenBrush and ink! Community. We see a huge gap in knowledge, understanding, and vision for the whole community in that sphere. Moreover, 727.ventures team will promote it in Twitter, Medium etc. We will create a lower entry threshold for newcomers by this educational program.
    8b.Marketing - The website upgradeWe are going to update out current website and add more specific things to improve the search for OpenBrush website in Google.

    Future workโ€‹

    Milestone 8. UniquePallet/RMRKPallet chain extensionโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a report regarding size reductions. We will create documentation and standards to describe the workflow of Non-Fungible token chain extension, how to reuse it and how it works.
    1.Create PSP for NFT on RMRKWe plan to create a new standard for NFT tokens based on RMRK. We will work with the RMRK team on the finalization of the standard. We will try to be compatible with PSP34. Based on the result of the work we will decide to create the chain extension for the unique-pallet or for the rmrk-pallet.
    2.Implement chain extension for NFT on substrate levelIn the same way as for the AssetPallet extension, we plan to implement UniquePallet/RMRKPallet chain extensions on the substrate level. Based on the cooperation with the RMRK team we will decide how better implement Non-Fungible tokens.
    3.Implement chains extension in OpenBrushImplementation of contract versions of the UniquePallet/RMRKPallet chain extension. Anyone will be able to call the logic of pallets from the contract.
    4.Implement NFT contract via chain extensionsOpenBrush will provide a default implementation of contracts that are implemented via according chains extensions.
    5.Refactoring of trait system in the ink!Refactoring of trait system in the ink! to support default implementation inside of traits. It should improve the developer's experience with traits and simplify its usage.
    6.Marketing - Create 4 educational video for OpenBrush/ink!We are going to work on educational video materials for OpenBrush and ink! Community. We see a huge gap in knowledge, understanding, and vision for the whole community in that sphere. Moreover, 727.ventures team will promote it in Twitter, Medium etc. We will create a lower entry threshold for newcomers by this educational program.
    7.ink! storage docsThere is no documentation with clear description of how the storage works within ink!. As our team was the one doing the refactoring of ink! storage, we will create a comprehensive documentation on how the storage works in ink! 4, as well as detailed comparison on what was changed in comparison to ink! 3 storage, including examples of usage.

    Milestone 9. Multi token chain extensionโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a report regarding size reductions. We will create documentation and standards to describe the workflow of Multi token chain extension, how to reuse it and how it works.
    1.Implement chain extension for Multi token in substrate levelIn the same way as for the AssetPallet extension, we plan to implement MultiPallet extension on the substrate level. We hope that Paratoken Standard will be accepted and implemented and we will be able to integrate with it.
    2.Implement chains extension in OpenBrushImplementation of contract versions of the MultiPallet chain extension. Anyone will be able to call the logic of multi asset pallet from the contract.
    3.Implement multi token contracts via chain extensionsOpenBrush will provide a default implementation of contracts that are implemented via according chain extension.
    4.Reduce the size of the contracts more(investigation and implementation)After the support of main chain extensions, we plan to focus on the contract size reduction of all contracts in OpenBrush. We plan to contribute to ink! and participate in according issue.
    5.Advanced documentationFor the better understanding, we will post on the OpenBrush website - the clear technical checklist to become an ink!/OpenBrush engineer. It will attract more developers and builders in the ecosystem

    NOTES: During each milestone, we also will maintain OpenBrush to be compatible with a new version of ink! and contract-pallet:

    Future Plansโ€‹

    After, this Grant, we will create a grant related to upgradable contracts.

    We're going to make a strong impact in the community, making ink! simple and convenient for developers.

    Additional Information โž•โ€‹

    In the roadmap, you can see what was already done. Currently, we're on the 5th milestone. The 5th milestone depends on review from ink! team so we started 6th milestone in parallel.

    We`re organising the first WASM conference in the whole Polkadot ecosystem. This event is a part of Open Brush marketing strategy.

    How did you hear about the Grants Program? Web3 Foundation Website / Medium / Twitter / Element / Announcement by another team / personal recommendation / etc.

    Personal recommendation.

    - + \ No newline at end of file diff --git a/applications/openbrush-follow-up.html b/applications/openbrush-follow-up.html index 81136d31174..56c4bacce0e 100644 --- a/applications/openbrush-follow-up.html +++ b/applications/openbrush-follow-up.html @@ -4,7 +4,7 @@ OpenBrush | Web3 Foundation Grants - + @@ -42,7 +42,7 @@ BS in economics, MS in Quantitative Finance & Actuarial Science, experienced in, operations management, IB, financial and strategy consulting, including crypto, passed CFA II level

    Lera Laricheva
    Creative Designer
    "In 2019 I started to get involved in the IT area. At first, I tried myself as a developer, and eventually I went away from that, to design. At first, I tried myself in design, then when I saw the result, and understood that I liked it, so I found courses and got a diploma. Then I tried freelancing, like many other beginners, but came to the conclusion that the working for a company is much better, and that is where a person can get a tremendous amount of experience, while constantly evolving, because you have to keep up with the tasks, and most importantly to understand them and try to implement them correctly. At the same time, it is my third year studying in Karazin, specialty marketing."

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    The project is already in release 1.0.0.

    PSP - https://github.com/w3f/PSPs/pull/25

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    We have decided to describe a full roadmap of an OpenBrush here, with estimates. However, the funding we request at this stage is for milestones 3-5.

    Previous workโ€‹

    Milestone 1 - Implement reusable basic contracts in ink!, similar to Openzeppelinโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will enhance inline documentation, and create a tutorial on how to import/customize contracts.
    0c.Testing GuideWe will add unit tests to cover all basic logic and integration tests with Redspot, to verify that all works via contract-pallet
    1a.Fungible token(Erc20)We will implement reusable Erc20 analog on ink!
    1b.Non Fungible token(Erc721)We will implement reusable Erc721 analog on ink!
    1b.Multi token(Erc1155)We will implement reusable Erc1155 analog on ink!
    2a.AccessControlWe will implement reusable AccessControl analog on ink!
    2b.OwnableWe will implement reusable Ownable analog on ink!

    Milestone 2 - Simplify usage of library. Add a new features which extend ink!. Provide macroses that will allow creation of your own base implementationโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will enhance inline documentation, update previous documentation based on simplifications, documentation for new features.
    0c.Testing GuideWe will test macros, update tests according to new features, simplifications.
    1.Remove boilerplate codeWe will provide a macro which will allow to remove boilerplate during usage of library(Library provides implementation on rust level in internal trait. User must reuse internal implementation with ink! messages. Our macro will simplify it). It will simplify the code structure and usage.
    2.Derive for storagesWe will provide a derive macro to generate implementation for storage's structs. It will simplify integration of fields inside of struct and implementation of storage's traits for that fields.
    3.Support default implementation in external traitsWe will add mnemonic support of default implementations inside of trait definition(traits defined via #[ink::trait_definition]). It is mnemonic, because under the hood we will generate internal trait with default implementation that will be used in external trait.
    4.Support of modifiersWe will add support of modifiers, like in Solidity. User will be able to mark some function to use modifiers and it will simplify the code.
    5.ReentrancyGuardWe will add implementation of ReentrancyGuard
    6.Implement additional useful contractWe will implement PaymentSplitter, TimelockController and etc.

    Current work - Scope of this Grantโ€‹

    Milestone 3. Reduce the size of Erc20 contractโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a report of how much each optimization reduced the size.
    1.Reduce the size of Erc20 contractNow the most critical moment with ink! is the huge size of contracts. This issue described the problem very well. The parity team works in this direction, and we want to help with ink! side. The ink! team created issue 906, 916 and 910. We want to briefly(not full change, only minimal changes to reduce the size) implement them and provide a report(re-working data structure, reducing monomorphization, using dynamic dispatch in some cases). Based on this report, the ink! team can decide how better to implement them and which part is more critical. During the implementation, we will build examples with our version of ink! (also maybe we will modify some sub-crates). So the output of this work is a report and custom version of ink!. The code can be reused, or if ink! team agrees we can try to implement these issues by ourselves later as separate work.

    Milestone 4. Pre-release - Standardization of tokens contracts. Implement extensions for contracts. Documentationโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide inline documentation for macros, create a tutorial on how to use macros in your own project, with a detailed description of how it works inside.
    0c.Testing GuideWe will add more tests to cover all macros, update tests according to new changes.
    1.Create Proposal for Fungible tokenWe will create a proposal for standardization of Erc20 token in case of ink! and contract-pallet. Based on the final decision regarding the proposal update the implementation in library.
    2.Implement extensions for tokensWe will implement extensions for Erc20, Erc721 and Erc1155 tokens.
    3.Create Proposal for Non Fungible token and Multi tokenWe will create proposals for NFT and multi token, when proposal for FT token will be approved. Based on the decisions of these approves, we will update implementation in library.
    4.Use original ink! instead of our ownWe will use ink! 3.0-rc6 version(or a new one if it will be compatible) instead of our own version of ink!.
    5.Refactor the contracts to be compatible with PSPsWe will refactor the contracts according to the PSP.
    6.Refactor the structure of the OpenBrush to provide agnostic traitsWe will refactor the structure of the OpenBrush to provide traits for each implementation of the contract without restriction and implementation related information:
    - Traits will be defined in a separate module.
    - The default implementation of that trait for a contract will be provided via unstable feature #![feature(min_specialization)].
    - We will provide a new macro to generate a wrapper around a trait. That wrapper can be used for cross-contract calls. So the user is enough of the trait definition to do a cross contract call.

    Milestone 5. Release - Contribution to inkโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide inline documentation, example of usage of extensions.
    0c.Testing GuideWe will add tests for extensions and for a new changes from ink! side.
    1.Contribute to ink! with fixing of eventsWe will help to fix the issue with events.
    2.Re-work the storage of contractsWe want to resolve the issue.
    3.Refactor of implementation according changes in ink!After changes in ink! we will refactor the code of library.

    Future Plansโ€‹

    After, this Grant, we will create a grant related to upgradable contracts.

    We're going to make a strong impact in the community, making ink! simple and convenient for developers.

    Additional Information โž•โ€‹

    In the roadmap, you can see what was already done. Currently, we're on the 3-rd milestone.

    We have applied and got the grant to cover 1 and 2 milestones. This grant is a follow-up grant.

    How did you hear about the Grants Program? Web3 Foundation Website / Medium / Twitter / Element / Announcement by another team / personal recommendation / etc.

    Personal recommendation.

    - + \ No newline at end of file diff --git a/applications/openbrush.html b/applications/openbrush.html index b0c8a24ee35..8e8cd68954c 100644 --- a/applications/openbrush.html +++ b/applications/openbrush.html @@ -4,7 +4,7 @@ OpenBrush | Web3 Foundation Grants - + @@ -47,7 +47,7 @@ "In 2019 I started to get involved in the IT area. At first I tried myself as a developer, and eventually I went away from that, to design. At first I tried myself in design, then when I saw the result, and understood that I liked it, so I found courses and got a diploma. Then I tried freelancing, like many other beginners, but came to the conclusion that the working for a company is much better, and that is where a person can get a tremendous amount of experience, while constantly evolving, because you have to keep up with the tasks, and most importantly to understand them and try to implement them correctly. At the same time, it is my third year studying in Karazin, specialty marketing."

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    The project is already in a solid pre-release state.

    PSP - https://github.com/w3f/PSPs/pull/22

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    We have decided to describe a full roadmap of an Openbrush here, with estimates. However, the funding we request at this stage is only for the second milestone. The first milestone already has been done. Funds for the next milestones will be requested in the next grant.

    Current work - Scope of this Grantโ€‹

    Milestone 1 - Implement reusable basic contracts in ink!, similar to Openzeppelinโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will enhance inline documentation, and create a tutorial on how to import/customize contracts.
    0c.Testing GuideWe will add unit tests to cover all basic logic and integration tests with Redspot, to verify that all works via contract-pallet
    1a.Fungible token(Erc20)We will implement reusable Erc20 analog on ink!
    1b.Non Fungible token(Erc721)We will implement reusable Erc721 analog on ink!
    1b.Multi token(Erc1155)We will implement reusable Erc1155 analog on ink!
    2a.AccessControlWe will implement reusable AccessControl analog on ink!
    2b.OwnableWe will implement reusable Ownable analog on ink!

    Milestone 2 - Simplify usage of library. Add a new features which extend ink!. Provide macroses that will allow creation of your own base implementationโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will enhance inline documentation, update previous documentation based on simplifications, documentation for new features.
    0c.Testing GuideWe will test macros, update tests according to new features, simplifications.
    1.Remove boilerplate codeWe will provide a macro which will allow to remove boilerplate during usage of library(Library provides implementation on rust level in internal trait. User must reuse internal implementation with ink! messages. Our macro will simplify it). It will simplify the code structure and usage.
    2.Derive for storagesWe will provide a derive macro to generate implementation for storage's structs. It will simplify integration of fields inside of struct and implementation of storage's traits for that fields.
    3.Support default implementation in external traitsWe will add mnemonic support of default implementations inside of trait definition(traits defined via #[ink::trait_definition]). It is mnemonic, because under the hood we will generate internal trait with default implementation that will be used in external trait.
    4.Support of modifiersWe will add support of modifiers, like in Solidity. User will be able to mark some function to use modifiers and it will simplify the code.
    5.ReentrancyGuardWe will add implementation of ReentrancyGuard
    6.Implement additional useful contractWe will implement PaymentSplitter, TimelockController and etc.

    Future workโ€‹

    Milestone 3. Pre-release - Standardization of tokens contracts. Implement extensions for contracts. Documentationโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide inline documentation for macros, create a tutorial on how to use macros in your own project, with a detailed description of how it works inside.
    0c.Testing GuideWe will add more tests to cover all macros, update tests according to new changes.
    1.Create Proposal for Fungible tokenWe will create a proposal for standardization of Erc20 token in case of ink! and contract-pallet. Based on the final decision regarding the proposal update the implementation in library.
    2.Implement extensions for tokensWe will implement extensions for Erc20, Erc721 and Erc1155 tokens.
    3.Create Proposal for Non Fungible token and Multi tokenWe will create proposals for NFT and multi token, when proposal for FT token will be approved. Based on the decisions of these approves, we will update implementation in library.

    Milestone 4. Release - Contribution to inkโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide inline documentation, example of usage of extensions.
    0c.Testing GuideWe will add tests for extensions and for a new changes from ink! side.
    1.Contribute to ink! with fixing of eventsWe will help to fix the issue with events.
    2.Add support of default implementation in trait definition on ink! levelWe will help with the support of default implementation inside of trait definition. It will require discussions with the ink! team to define the best way how to implement that without conflicts with their future changes.
    3.Refactor of implementation according changes in ink!After changes in ink! we will refactor the code of library.

    Milestone 5 - Support of upgradable contractsโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide inline documentation, example of upgradable contracts.
    0c.Testing GuideWe will add tests to cover upgradability of contracts.
    1.Implement delegated callWe will find and provide the idea of how delegeted call can be implemented in contract-pallet. Help with it's implementation.
    2.Help with fallback functionWe will help with implementation of fallback function if it is not ready.
    3.Creation of Proxy contractsWe will provide an alternative of Proxy contracts.
    4.Documentation and examplesWe will add examples and documentation on how the upgradable contract must be implemented.

    Future Plansโ€‹

    We're going to make strong impact on the community, making ink! simple and convenient for developers.

    Additional Information โž•โ€‹

    So far we have taken it upon ourselves to fund this project. In the roadmap you can see what was already done, currently we're on the 2-rd milestone.

    We havenโ€™t applied for any other grant programs.

    How did you hear about the Grants Program? Web3 Foundation Website / Medium / Twitter / Element / Announcement by another team / personal recommendation / etc.

    Personal recommendation.

    - + \ No newline at end of file diff --git a/applications/openrollup-mvp-phase-1.html b/applications/openrollup-mvp-phase-1.html index 0ac3525f795..f5505cb23b3 100644 --- a/applications/openrollup-mvp-phase-1.html +++ b/applications/openrollup-mvp-phase-1.html @@ -4,7 +4,7 @@ Open rollup - MVP - Phase 1 | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ We are still considering and researching the proof and verification protocol, we can't provide very detailed details yet, we will design it while implementing this proposal.

    Ecosystem Fitโ€‹

    1) Open zk-rollup architecture Developers who want to participate in the Polkadot ecosystem do not need to invest in their own zk-rollup technology alone so that more developers can participate in the development of zkapp.

    2) increase scalability The off-chain zkapps greatly expands the scalability of the Polkadot/Substrate.

    3) Modularity The architecture of Open rollup is suitable for different proof and verify protocols, and can adapt to zkapps of different ZK protocols in the future

    1) The application developers that are in search of scaling their blockchain application, for example, the payment application. 2) The game developers who do not want to interact with the chain frequently only need to submit in batches for a period of time, which saves the cost of using the chain and improves the user experience.

    There are many zk-rollup projects, such as zksync, starknet, hermez, plonky2, they are basically in the Ethereum ecosystem. They are all operated by a central operator, and in our protocol, each zkapp is an operator.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Our team has a lot of experience in applied cryptography, blockchain research, and software development. Chris has been a software engineer for many years in the gaming industry and has led the development of various multiplayer online games. Recently he develop a hybrid consensus of Progpow and AuthorityRound https://github.com/chrisicen/openethereum-unity. He is currently devoted to the development of an off-chain ZK scalability solution for blockchain.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    not yet available

    Development Status ๐Ÿ“–โ€‹

    We've been working on techniques for zk-rollup, and verifiable computation for some time, including projects like zksync, halo2, plonky2, winterfell, hermez, and related papers and articles. We are starting to implement the rollup part.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement Substrate Modulesโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains what was done/achieved as part of the grant.
    1.Open rollup PalletWe provide the core data types and the functionalities(zkapp registration/user deposit/user exit/user full exit/zkapp batch submit/zkapp management/zkapp info api) which support currencies/tokens/NFTs as specified in Project Details.

    - Pallet Data structures
    - Zkapps: Map<programHash, zkappParams>, The zkappParams defining a zkapp, i.e., the ZkvmType, the submitter, and the inactive status
    - ZkappStates: Map<programHash, childTrieRootHash>, A child Trie holds Users' balances of the Assets in each zkapp

    - Pallet Functionality

    - fn zkappRegister(programHash: Hash, zkvmType: ZkvmType): Register a zkapp on the pallet
    - fn addAssetSuppport(programHash: Hash, asset: Asset): Add support of one asset in the zkapp
    - fn changeSubmitter(programHash: Hash, asset: Asset, newSubmitter: AccountId): Change the submitter of the zkapp
    - fn setInactive(programHash: Hash): Set the zkapp is inactive, no batch can be submitted in the future, and the users can send an exit transaction to withdraw their assets
    - fn submitBatch(programHash: Hash, oldStateRoot: Hash, newStateRoot: Hash, operations: Vec<Operation>, proof: Vec<u8>): Submit a new batch providing the L2 operations (transfer, swap, move, withdraw)
    - fn deposit(programHash: Hash, asset: Asset): Deposits a given amount of assets into the zkapp.
    - fn withdraw(programHash: Hash, asset: Asset): Withdraws a given amount of assets from the zkapp to the owner
    - fn moveAsset(fromProgramHash: Hash, toProgramHash: Hash, asset: Asset): Move a given amount of assets from one zkapp to another zkapp
    - fn exit(programHash: Hash): If one zkapp is inactive, the user can exit the zkapp and withdraw the assets
    2.Miden verifier in Open rollup PalletWe provide the verifier trait suitable for general apps, and a miden verifier that implements the verifier trait.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Recommendation from a friend in the Bifrost team.

    - + \ No newline at end of file diff --git a/applications/orochi-network-orosign-part1.html b/applications/orochi-network-orosign-part1.html index ba94c15f636..28de23b316a 100644 --- a/applications/orochi-network-orosign-part1.html +++ b/applications/orochi-network-orosign-part1.html @@ -4,13 +4,13 @@ Orochi Network's proposal for research and development MPC ECDSA | Web3 Foundation Grants - +
    -
    Skip to main content

    Orochi Network's proposal for research and development MPC ECDSA

    • Team Name: Orochi Network
    • Payment Address: 167Zj4mv1jBTzJimSe7LngcRS7SBixsx3ZSCFr45Eo1SjWCY (USDT Polkadot)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Users are now able to take advantage of the highest security feature similar to a cold storage while experiencing flexibility and convenience of the mobile app at minimal cost. Orosign is a self-managing custodial Mobile App for digital assets/identity that suits all demands of Web3.

    Project Detailsโ€‹

    Orosign project utilize cryptographic primitives and Multiparty Computation (MPC) to help people manage/secure their digital assets, it could provide highest security meanwhile friendly to end-users. Orosign provides following features:

    • Gasless Multi-signature: We use ECDSA proofs to perform off-chain voting to manage multi-signature wallet.
    • Gaming & NFT: Support gaming by providing automation transaction signing for Web3 game, this wallet can manage and display NFTs.
    • ZeroKey: A MPC based wallet, we build ECDSA on top of MPC to secure the signing process where user can perform the signing without any actual private key.
    • Web3 Passport: Support Proof of Carrying Data (PCD) for the Web3 authorization.
    • Account Abstraction with MPC: You could see the raise of Account Abstraction at the smart contract level, we want to take it a bit further with MPC. We want to provide a MPC based account abstraction for the end-users, so they can manage their digital assets in a more secure way.

    Ecosystem Fitโ€‹

    • Non-custodial Users are holding their own digital asset that meant the encrypted private keys is stored in their crypto wallet and hold the major secret shares in MPC wallet. Orosign was design to make sure no one able to touch people digital asset even Orochi Network.
    • High Customizability In gasless Multi-signature Wallet and MPC Wallet, user can customize number of participants and the threshold to perform signing process.
    • Highest Level of Security Orosign can be provide the first MPC Wallet on Polkadot.
    • NFT & games optimization Automatic showcase for all NFT collectibles, and support automation transaction signing for Web3 game.

    What is the benefit of this solution compared to others?

    • Multi-signature and MPC Wallet enable highest level of security in co-ownership for vast majority of Polkadot's users.
    • Providing the first MPC Wallet as a mobile application on Polkadot
    • Orosign is building toward the vision of Web3 passport, it allos user to manage their digital identity and assets in one place.

    Is this meant to be an enterprise-grade security wallet such as this SaaS wallet?

    • Orosign is a self-custodian wallet, we offer enterprise-grade security for retail and semi-retail users.

    Will it be cross-chain compatible or is it only meant for substrate chains?

    • In the budget of this proposal we only able to support Polkadot's chain and its parachains. We will consider to support other chains in the future.

    Can you further expand on the technical details of the wallet in the deliverables?

    • We implement DKG to generate secret shares that will be used to perform signing process without actual private key.
    • User will hold let's say 3 shares (2 sign shares and 1 backup) of 5 shares (Orochi Network hold 2). We created a threshold signature 3 of 5, it's required at least 1 share from user to perform transaction co-signing.
      • Orochi Network can't perform the signing process.
      • User can perform the signing process with or without Orochi Network.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Chiro Hiro - CEO Orochi Network Github
    • Hubert Nguyen - CGO Orochi Network Github
    • Minh - R&D Specialist Github
    • James - Front-end Developer Github
    • Kevin - Back-end Developer Github
    • Trang - Business Analysis

    Contactโ€‹

    • Registered Address: OROCHI NETWORK PTE. LTD,68 CIRCULAR ROAD , #02-01 , SINGAPORE (049422)
    • Registered Legal Entity: OROCHI NETWORK PTE. LTD,68 CIRCULAR ROAD , #02-01 , SINGAPORE (049422)

    Team's experienceโ€‹

    We are focusing in cryptography and especially ZKP, we want to utilize cryptography to provide Verifiable Computation.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    https://github.com/orochi-network

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2
    • Full-time equivalent (FTE): 2
    • Total Costs: $10,000

    Milestone 1โ€‹

    In this milestone, our team use cryptography to build a bridge from Digital Signature Algorithm (DSA especially ECDSA, EdDSA, Schnorr Signature) to Multi-Party Computation (MPC) allow the signing process to be performed without actual private key. There are 3 DSAs were used by Polkadot: secp256k1, ed25519, sr25519. Before we can build a MPC based DSA, we need to research the algorithm and figure out how we could fit MPC into it. You may notice that each curve have different parameters and different field, after the research we can specify how MPC should be implement without harm its security.

    • Estimated Duration: 2 months
    • FTE: 2
    • Costs: $10,000
    NumberDeliverableSpecification
    0a.LicenseCC0 1.0
    0b.ResearchResearching about Polkadot signature system and research their compatibility with MPC by which we can be fully comptabile with Polkadot and its parachains
    0c.ResearchPublic technical report for every research we made, everything published under CC0 1.0
    1.ResearchResearching about MPC in ECDSA (all supported signatures by Polkadot)
    2.ResearchResearching MPC for secp256k1 and providing the document that describe how the MPC will be built and its security consideration
    3.ResearchResearching MPC for ed25519 and providing the document that describe how the MPC will be built and its security consideration
    4.ResearchResearching MPC in sr25519 and providing the document that describe how the MPC will be built and its security consideration

    Future Plansโ€‹

    • Implement MPC as a Rust crate that supports secp256k1, ed25519, sr25519, supporting multiparty computation to perform transaction/message signing with mentioned DSA. This module will implement with Rust programing language and compile to Wasm opcode or native lib for React Native app.
    • Implement a node of MPC's distributed network to perform MPC.
    • Implement API interface for distributed system, allow Wallet API to connect to MPC nodes.
    • Integrate wallet API with node's RPC, provide back-end for Orosign front-end.
    • Integrate wallet API with Orosign front-end, allow users to use MPC wallet.
    • Integrate MPC in both front-end and back-end of Orosign, allow user to perform transaction signing with mobile device.
    • Support PCD (Proof of Carrying Data)

    Additional Information โž•โ€‹

    We do research about MPC, especially ECDSA threshold signature for 1 year, publish several articles on our blog (docs.orochi.network). Drafting the paper to consider right method to Implement threshold signature (ECDSA), considering different methods to for implementation. Have some related work on MPC ECVRF which is shared some similar primitives to ECDSA.

    • Are there are any teams who have already contributed (financially) to the project?
      • No, our project is self funded till now
    • Have you applied for other grants so far?
      • No
    - +
    Skip to main content

    Orochi Network's proposal for research and development MPC ECDSA

    • Team Name: Orochi Network
    • Payment Address: 167Zj4mv1jBTzJimSe7LngcRS7SBixsx3ZSCFr45Eo1SjWCY (USDT Polkadot)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Users are now able to take advantage of the highest security feature similar to a cold storage while experiencing flexibility and convenience of the mobile app at minimal cost. Orosign is a self-managing custodial Mobile App for digital assets/identity that suits all demands of Web3.

    Project Detailsโ€‹

    Orosign project utilize cryptographic primitives and Multiparty Computation (MPC) to help people manage/secure their digital assets, it could provide highest security meanwhile friendly to end-users. Orosign provides following features:

    • Gasless Multi-signature: We use ECDSA proofs to perform off-chain voting to manage multi-signature wallet.
    • Gaming & NFT: Support gaming by providing automation transaction signing for Web3 game, this wallet can manage and display NFTs.
    • ZeroKey: A MPC based wallet, we build ECDSA on top of MPC to secure the signing process where user can perform the signing without any actual private key.
    • Web3 Passport: Support Proof of Carrying Data (PCD) for the Web3 authorization.
    • Account Abstraction with MPC: You could see the raise of Account Abstraction at the smart contract level, we want to take it a bit further with MPC. We want to provide a MPC based account abstraction for the end-users, so they can manage their digital assets in a more secure way.

    Ecosystem Fitโ€‹

    • Non-custodial Users are holding their own digital asset that meant the encrypted private keys is stored in their crypto wallet and hold the major secret shares in MPC wallet. Orosign was design to make sure no one able to touch people digital asset even Orochi Network.
    • High Customizability In gasless Multi-signature Wallet and MPC Wallet, user can customize number of participants and the threshold to perform signing process.
    • Highest Level of Security Orosign can be provide the first MPC Wallet on Polkadot.
    • NFT & games optimization Automatic showcase for all NFT collectibles, and support automation transaction signing for Web3 game.

    What is the benefit of this solution compared to others?

    • Multi-signature and MPC Wallet enable highest level of security in co-ownership for vast majority of Polkadot's users.
    • Providing the first MPC Wallet as a mobile application on Polkadot
    • Orosign is building toward the vision of Web3 passport, it allos user to manage their digital identity and assets in one place.

    Is this meant to be an enterprise-grade security wallet such as this SaaS wallet?

    • Orosign is a self-custodian wallet, we offer enterprise-grade security for retail and semi-retail users.

    Will it be cross-chain compatible or is it only meant for substrate chains?

    • In the budget of this proposal we only able to support Polkadot's chain and its parachains. We will consider to support other chains in the future.

    Can you further expand on the technical details of the wallet in the deliverables?

    • We implement DKG to generate secret shares that will be used to perform signing process without actual private key.
    • User will hold let's say 3 shares (2 sign shares and 1 backup) of 5 shares (Orochi Network hold 2). We created a threshold signature 3 of 5, it's required at least 1 share from user to perform transaction co-signing.
      • Orochi Network can't perform the signing process.
      • User can perform the signing process with or without Orochi Network.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Chiro Hiro - CEO Orochi Network Github
    • Hubert Nguyen - CGO Orochi Network Github
    • Minh - R&D Specialist Github
    • James - Front-end Developer Github
    • Kevin - Back-end Developer Github
    • Trang - Business Analysis

    Contactโ€‹

    • Registered Address: Orochi Network LLC, Suite 305, Griffith Corporate Centre, Beachmont, Kingstown, Saint Vincent and the Grenadines (Postal code: VC0284)
    • Registered Legal Entity: Orochi Network LLC (ID: 1416 LLC 2021)

    Team's experienceโ€‹

    We are focusing in cryptography and especially ZKP, we want to utilize cryptography to provide Verifiable Computation.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    https://github.com/orochi-network

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2
    • Full-time equivalent (FTE): 2
    • Total Costs: $10,000

    Milestone 1โ€‹

    In this milestone, our team use cryptography to build a bridge from Digital Signature Algorithm (DSA especially ECDSA, EdDSA, Schnorr Signature) to Multi-Party Computation (MPC) allow the signing process to be performed without actual private key. There are 3 DSAs were used by Polkadot: secp256k1, ed25519, sr25519. Before we can build a MPC based DSA, we need to research the algorithm and figure out how we could fit MPC into it. You may notice that each curve have different parameters and different field, after the research we can specify how MPC should be implement without harm its security.

    • Estimated Duration: 2 months
    • FTE: 2
    • Costs: $10,000
    NumberDeliverableSpecification
    0a.LicenseCC0 1.0
    0b.ResearchResearching about Polkadot signature system and research their compatibility with MPC by which we can be fully comptabile with Polkadot and its parachains
    0c.ResearchPublic technical report for every research we made, everything published under CC0 1.0
    1.ResearchResearching about MPC in ECDSA (all supported signatures by Polkadot)
    2.ResearchResearching MPC for secp256k1 and providing the document that describe how the MPC will be built and its security consideration
    3.ResearchResearching MPC for ed25519 and providing the document that describe how the MPC will be built and its security consideration
    4.ResearchResearching MPC in sr25519 and providing the document that describe how the MPC will be built and its security consideration

    Future Plansโ€‹

    • Implement MPC as a Rust crate that supports secp256k1, ed25519, sr25519, supporting multiparty computation to perform transaction/message signing with mentioned DSA. This module will implement with Rust programing language and compile to Wasm opcode or native lib for React Native app.
    • Implement a node of MPC's distributed network to perform MPC.
    • Implement API interface for distributed system, allow Wallet API to connect to MPC nodes.
    • Integrate wallet API with node's RPC, provide back-end for Orosign front-end.
    • Integrate wallet API with Orosign front-end, allow users to use MPC wallet.
    • Integrate MPC in both front-end and back-end of Orosign, allow user to perform transaction signing with mobile device.
    • Support PCD (Proof of Carrying Data)

    Additional Information โž•โ€‹

    We do research about MPC, especially ECDSA threshold signature for 1 year, publish several articles on our blog (docs.orochi.network). Drafting the paper to consider right method to Implement threshold signature (ECDSA), considering different methods to for implementation. Have some related work on MPC ECVRF which is shared some similar primitives to ECDSA.

    • Are there are any teams who have already contributed (financially) to the project?
      • No, our project is self funded till now
    • Have you applied for other grants so far?
      • No
    + \ No newline at end of file diff --git a/applications/pacific_store.html b/applications/pacific_store.html index fe913d1fe70..037050e9f32 100644 --- a/applications/pacific_store.html +++ b/applications/pacific_store.html @@ -4,7 +4,7 @@ OpenSea.js on polkadot | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ No.
  • Are there are any teams who have already contributed (financially) to the project? No.
  • Have you applied for other grants so far? No.
    • - + \ No newline at end of file diff --git a/applications/pallet-drand-client.html b/applications/pallet-drand-client.html index 47c6a5f52f2..4a6634085a0 100644 --- a/applications/pallet-drand-client.html +++ b/applications/pallet-drand-client.html @@ -4,7 +4,7 @@ drand in substrate | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ We believe that the quality of the project delivery will bear witness to our claims.

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    The public docs from drand serve best as technical introduction to what drand is, and how it can be integrated into existing projects. We will also use Github's Projects feature or Issues to create a backlog and task our progress publically.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1: Create a Rust client library for drandโ€‹

    While there exists one drand Rust client library, it hasn't been updated in 2 years.

    We will create a new Rust library that

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide inline documentation alongside the code, a README explaining how it can be used, and a few examples demonstrating it's concrete usage.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. We will use standardized testing methods so tests can be pragmatically executed and updated by anyone.
    1.Drand client libraryWe will build out a drand client library with the requirements mentioned in the Milestoke 1 overview.

    Milestone 2: Build a Substrate pallet with a fully-featured/configured example chainโ€‹

    We will write a Substrate pallet that:

    We will also build an example Substrate node that:

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will create dedicated documentation in the repo of how to use the code and a basic tutorial that explains how a user can (example) spin up one of the Substrate nodes and interact with the chain in a way that utilized drand's randomness.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Example palletWe will create a pallet that integrates the drand client library from Milestone 1, and write a sample pallet that uses its features (eg. return a message from a list of messages at random, based on the public randomness it retrieves via the API).
    2.Randomness verificationThe pallet will be able to verify round randomness via the chain randomness information.
    2.Example chainWe spin up a testing chain to demonstrate how such a pallet works.

    Future Plansโ€‹

    Once randomness is available to Substrate developers, we would be interested to write a client that actually participates in the drand protocol. It may make sense for a common-good parachain to participate as a member of League of Entropy. We recognize the lack of accountability and other issues that can arise with an anonymous team maintaining such an important and foundational ecosystem component like a common-good parachain,, and we are open to discussion solutions relating to the development and maintenance of it.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? https://medium.com/web3foundation/web3-foundation-grants-program-reaches-400-projects-milestone-1k-grant-applications-received-93a7d3a5f942

    Thank you for your time. We're looking forward to discussing this project with you.

    - + \ No newline at end of file diff --git a/applications/pallet_maci.html b/applications/pallet_maci.html index 85f047f3b68..b9c602911f2 100644 --- a/applications/pallet_maci.html +++ b/applications/pallet_maci.html @@ -4,7 +4,7 @@ pallet-maci | Web3 Foundation Grants - + @@ -46,7 +46,7 @@ Quadratic funding seems like the best fit for aggregating people's preferences for funding some public goods, so the platform will implement the Constrained Liberal Radicalism algorithm (Quadratic funding) for calculating the funds for a specific project.

    Bellow are all the components that have to be developed before the platform is ready for use:

    Components overview

    Component nameDescription
    Web AppThe GUI used to present funding data to the users in an easy way.
    pallet-quadratic-fundingThe pallet will contain business logic and data of the funding campaigns and be used to operate the platform.
    pallet-user-registryPallet used to manage verified users of the platform to prevent any potential Sybil attacks.
    pallet-maciMinimum Anti-Collusion Infrastructure implementation for substrate-based chains

    Additional information

    Any additional information that you think is relevant to this application that hasn't already been included.

    Possible additional information to include:

    - + \ No newline at end of file diff --git a/applications/pallet_supersig.html b/applications/pallet_supersig.html index 8d0c0c8db60..a4a895354db 100644 --- a/applications/pallet_supersig.html +++ b/applications/pallet_supersig.html @@ -4,7 +4,7 @@ Supersig | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ Here is a recent contribution from Ramsey in a Substrate Seminar

    Timothรฉe Delabrouille (tdelabro) - Substrate / Rust Engineer, founder of Rusty Crewmates, contributor to Kabocha

    Nathan Gardet-Derc (erudyx) - Substrate / Rust Engineer, contributor to Kabocha, Rusty Crewmate. developer on pallet_mint

    Jan Kraus - Full stack deveveloper - Javascript / Typescript / React / Node.js / Next.js / Gatsby / Ruby on Rails

    Elio Prfiti - Substrate Engineer - Kabocha - Upgraded Substrate Recipes... https://wiki.kabocha.network/recipes

    Richard Wells - Decent Partners, Kabocha founding steward, key stakeholder and communicator.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    pallet started here: https://github.com/kabocha-network/pallet_supersig/tree/polkadot-v0.9.16

    Description in trello ticket: https://trello.com/c/qi4Nf2YT

    *We are now working on the Supersig pallet (pallet_supersig). This pallet will benefit multisig users of Substrate based chains.

    The Supersig pallet is a multisig with super powers. It allows you to add and remove members of the multisig. It extends the capabilities of a multisig so it can be fit for governance of larger funds.

    A multisig transaction acts more like a treasury proposal. And the signatures become votes, with a quorum that can be changed (but in the MVP is fixed to simpleMajority).*

    Development Roadmap ๐Ÿ”ฉโ€‹

    This section should break the development roadmap down into milestones and deliverables. To assist you in defining it, we have created a document with examples for some grant categories here. Since these will be part of the agreement, it helps to describe the functionality we should expect in as much detail as possible, plus how we can verify and test that functionality. Whenever milestones are delivered, we refer to this document to ensure that everything has been delivered as expected.

    Below we provide an example roadmap. In the descriptions, it should be clear how your project is related to Substrate, Kusama or Polkadot. We recommend that teams structure their roadmap as 1 milestone โ‰ˆ 1 month.

    For each milestone,

    pallet_supersig public methodsโ€‹

    Create a supersig

    create_supersig will create a supersig with specified parameters, and transfer an existencial deposit from the creator to the generated supersig account, to bring the account to life. The dispatch origin for this call must be Signed.

    The threshold is currently u128, but will be Enum.

    pub fn create_supersig(
       origin: OriginFor<T>,
       members: Vec<T::AccountId>,
       threshold: u128, 
      )

    Submit a call to a specific supersig

    submit_call will create a proposal on the supersig, that members can approve. This will lock an amount that depend on the lenght of the encoded call, to prevent spam. The dispatch origin for this call must be Signed, and the origin must be a supersig member.

    pub fn submit_call(
       origin: OriginFor<T>,
       supersig_id: T::AccountId,
       call: Box<<T as pallet::Config>::Call>,
      )

    Vote for a call in the supersig

    approve_call will add a positive, unique vote to the specified call proposal. If the numbers of votes on this proposal = SimpleMajority (51%), then the call is executed. The dispatch origin for this call must be Signed, and the origin must be a supersig member.

    pub fn approve_call(
       origin: OriginFor<T>,
       supersig_id: T::AccountId,
       call_index: CallIndex,
      )

    Remove a call from the supersig

    remove_call will remove a call from the poll. For trensparency reasons, the votes won't be removed. This will also unlock deposited funds. The dispatch origin for this call must be Signed by either the supersig or the account who submitted the call.

    pub fn remove_call(
       origin: OriginFor<T>,
       supersig_id: T::AccountId,
       call_index: CallIndex,
      )

    Add member to the supersig

    pub fn add_member(
          origin: OriginFor<T>,
       supersig_id: T::AccountId,
       call_index: CallIndex,
      )

    Remove member from the supersig

    pub fn remove_member(
          origin: OriginFor<T>,
       supersig_id: T::AccountId,
       call_index: CallIndex,
      )

    Milestone 1 to make a working, secure and usable pallet_supersig v0.1.0.

    Milestone 2 will make the Supersig as visible of an experience within the polkadot js UI as Multisig, The PR will be made, and if there is a blocker, then the apps.decentration.org fork will house the feature.

    Milestone 3 Will get feedback and make some improvements. One improvement is adding a "Super Beneficiary" option that allows a threshold of 2/n only if the Super Beneficiary is involved in the transaction. Else the transactio will default to a superMajority. This allows for greater than the usual 2/3 multisig, but without loss of security.

    โšก If any of your deliverables is based on somebody else's work, make sure you work and publish under the terms of the license of the respective project and that you highlight this fact in your milestone documentation and in the source code if applicable! Teams that submit others' work without attributing it will be immediately terminated.

    Overviewโ€‹

    Milestone 1 โ€” pallet_supersig MVPโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation of the supersig pallet's code, and a basic tutorial that explains how a user can spin up one of our Substrate nodes and send test transactions, which will show how the supersig functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains supersig pallet to developers on medium and subsocial; and a substrate workshop/seminar that explains that shows how the pallet was designed (if there available slot, else a video shared on youtube).
    1.Substrate module: pallet_supersigWe will create a Substrate pallet that will allow user you to create a "supersig" where users can be added and removed. All extrinsics will require a simpleMajority to approve. The clear difference from multisig is that the supersig address is not a composite of its signatories, therefore it will stay static when adding or removing signatories.
    2.BenchmarkingThe pallet will be benchmarked and unit tested using worst case weightings.

    Milestone 2 โ€” Supersig for Polkadot JS UIโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation and a tutorial with a polkadot-js apps fork that guides a developer to simply set up supersig pallet and UI.
    0c.Error messagesCore functions will be fully covered by very informative error messages.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with milestone 2. The dockerfile will be a polkadot JS UI fork, it will also be the smallest possible file size (MBs not GBs)
    0e.ArticleWe will publish an article that explains supersig pallet to the end-user. The article will be on medium and subsocial.
    1.Substrate module: pallet_supersigWe will create a Substrate module from Milestone 1 that will be connected to a substrate chain as mentioned in 2.
    2.Substrate chainWe will create a custom substrate template that will contain pallet supersig
    3.Polkadot JS Apps UI ForkWe will add the custom feature to a polkadot JS UI fork (and make a PR to the main repo), so that the user can see the pallet in action, end to end.

    Milestone 3 โ€” Testing Feedback and Improvementsโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will update inline documentation and tutorials based on updates and feedback gained from user interviews.
    0c.Testing GuideIf required we will update unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will update the Dockerfile from previous milestones.
    0e.ArticleWe will update our prior articles if we have made any changes during this milestone.
    1.User interviews, feedback iterationWe will conduct user interviews to collate feedback and put them in a task backlog. We will select priorities that fit within the scope of this grant, which will be updated. From the findings of our feedback, a backlog of future tasks may be added on our kanban baord to create minor/major version bumps, and would inform the priority of future work. This milestone is vague because we are using this time to finding out unknowns to make changes with care (and in Good Faith).
    2.Substrate module: pallet_supersigWe will make any necessary updates from previous milestones.
    3.Polkadot JS Apps UI: Polkadot JS UI ForkWe will make any necessary updates from previous milestones.

    Future Plansโ€‹

    Improvements:

    Additional Information โž•โ€‹

    Who can vouch for Ramsey(Decentration)? Josh Muir (Kusama Council and Dat Dot), Bruno ล kvorc, Dan Shields, Will Chevdor, Sacha Lanski...

    - + \ No newline at end of file diff --git a/applications/panic.html b/applications/panic.html index b3848f499d2..ec8e7949f61 100644 --- a/applications/panic.html +++ b/applications/panic.html @@ -4,13 +4,13 @@ PANIC | Web3 Foundation Grants - +
    Skip to main content

    PANIC

    • Team Name: Simply VC
    • Payment Address: 0x672b62B64abe450F8C6957785fA5c79E33422aEF (ETH/USDT)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    This grant request is a follow-up on a previous agreement that has been terminated to allow for a value-first approach for the delivery of PANIC increments.

    Overviewโ€‹

    PANIC by Simply VC is an open-source monitoring and alerting solution for blockchain node operators. PANIC monitors a node operatorโ€™s setup, and sends relevant alerts via multiple alerting channels. The main objectives are to give node operators insight about the state of their systems, and to promptly raise alerts in case of an issue that may degrade the availability of their service.

    This grant request revolves around expanding the base tool together with the UI to cater for high priority Substrate metrics. This will allow PANIC users to monitor and be alerted on a growing number of metrics. Below is a table of what is in scope for this grant:

    Table 1โ€‹

    TypeMetric
    ConsensusBlocks authored
    ConsensusValidator status in consensus (active, disabled, elected)
    ConsensusGrandpa consensus rounds
    ConsensusSlashing events
    ConsensusI'm online events
    ConsensusValidator rewards per era and pending payouts
    Governance ActivityPending votes for the validator
    NodeSyncing status
    NodeBest block height
    NodeFinalised block height
    NodeSync target height
    Node StashNew Controller
    PayoutPayout Occurred

    PANIC is built around the needs of our own node operations team. We believe in dogfooding as it allows us to better assess the strengths and weaknesses of what is being built and ultimately provide a better product for external node operations teams.

    Project Detailsโ€‹

    Mockups of UI componentsโ€‹

    For the scope of this iteration, the installer will remain mostly unchanged, with the exception of the Alerts Configuration page. During the installation process, the node operator can manage out-of-the-box thresholds and severities for a list of alerts that will include the metrics listed in Table 1

    The first iteration of the UI includes a high-level dashboard from which node operators will be able to review all implemented alerts across all chains setup during installation. Also provided is a low-level system metrics dashboard which displays real-time data related to the host systemsโ€™ performance. The UI will remain unchanged but node operators will be able to view new alerts on the metrics listed in Table 1.

    Technology stack being usedโ€‹

    • Alerter - Python
    • UI (backend) - Node.js, TypeScript
    • UI (frontend) - TypeScript, Stencil JS, Sass
    • Docker

    Core components and architectureโ€‹

    PANIC is a Publisher-Subscriber system consisting of a number of components where each component is either a publisher, a subscriber or both. PANIC uses RabbitMQ to forward messages between components classified the table below:

    Table 2โ€‹
    ComponentsDescription
    MonitorsThe role of a monitor is to track the status of a monitorable (node/repository/network) by periodically obtaining a set of metrics from various sources (such as prometheus/rpc endpoints) and forwarding these metrics to RabbitMQ
    Data TransformersEach data transformer listens to metric data from the monitors. Depending to what monitorable the data belongs to, the data transformer outputs two sets of data, one for saving and another for alerting
    AlertersThe role of the alerters is to load the alert rules set up during installation and listen to transformed data from the data transformer. When this is received, an alerter checks the alert rules and raises alerts with the appropriate severity when needed
    Data StoresThe data stores receive transformed data and store the metric data inside Redis and MongoDB. Redis data will be used to load the current metrics state in the UI dashboards, whereas MongoDB data will be used to load historic data on the UI
    Alert RouterThe role of the alert router is to forward the raised alert to the appropriate channel, depending on the severity-channel mapping set during installation
    Channels ManagerThe channels manager receives alerts from the alert router and forwards these alerts to the channel determined by the alert router. The channels manager contains all the logic required by PANIC to communicate with a specific channel

    PANICโ€™s architecture diagram can be found here.

    Ecosystem Fitโ€‹

    PANICโ€™s main objective is to become the go-to tool for node operators active on various chains, including Substrate-based ones. PANICโ€™s focus is on alerting in the event that an issue arises that directly impacts the service being maintained. This grant request is against the investigation, development, testing, and delivery of additional metrics with the goal of providing node operators with a more complete monitoring and alerting solution as per Table 1.

    Currently a number of node operators are using other tools, such as Grafana in collaboration with Alertmanager, but this is not without fault. Such solutions require considerable setup effort and offer no default configurations. On the other hand, PANIC is built with ease of use in mind. The node operator is taken intuitively through the installation process which is clean and quick, with out-of-the-box thresholds and severities that can be configured if required. Once the installation is finalised, the UI will be made available with visual representations of alerts in line with the setup installed.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Team lead and full stack developer: Dylan Galea
    • Full stack developer: Guilherme Zimmermann
    • Full stack developer: Daniel Cherrett
    • Full stack developer: Francesco Borg Bonello
    • Full stack developer: Rรญder Cantuรกria
    • Product owner: Christian Falzon

    Contactโ€‹

    • Registered Address: 33, Pope Alexander VII Street, Balzan, BZN 1530, Malta (subject to change)
    • Registered Legal Entity: SIMPLY VC LTD is a Limited Liability Company registered in Malta with the Company reg no C 61022.

    Team's experienceโ€‹

    For a more in-depth review of the teamโ€™s past experiences, go to the teamโ€™s LinkedIn profiles section.

    Dylan Galea has been involved in the development of PANIC for Polkadot in both frontend and backend work. He has been part of the backend team during the implementation of the Polkadot API server and PANIC for Cosmos and helped in the fulfilment of technical reviews for PANIC for Oasis.

    Guilherme Zimmermann was previously a full stack developer on the blog and promotions platform of Betsson Group. He was also involved in the public billing module of Philips Healthcare as a full stack developer. His efforts are now focused on the PANIC UI together with the development of Simply VCโ€™s open source UI Kit.

    In July 2019 Daniel Cherrett joined Betsson Group as a QA Engineer on their affiliates program. He is also the sole developer of Call2Let, a Maltese property letting platform. He is now involved in developing the PANIC backend.

    Francesco Borg Bonello worked as a developer for Melita, a Maltese telecommunications company. Together with Dylan and Daniel he is now working on PANICโ€™s backend.

    Team Code Reposโ€‹

    The GitHub accounts of the team members are listed below:

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Conversations with the Web3 Foundationโ€‹

    At Simply VC we strive to keep our external stakeholders aware of product progress. For PANIC, this is achieved by the issue of an end-of-month progress report, which includes our latest releases, changes to the team structure and way of working, current priorities, and what features will be tackled in the short-term. Also included is a high-level roadmap to allow for longer-term visibility.

    Initial investigationโ€‹

    Following an initial investigation, we envisage that for Substrate node monitoring and alerting, PANIC will operate as follows:

    1. When the Monitors Manager Process receives the configurations, it starts as many Substrate Node Monitors as there are Substrate configurations to be monitored.
    2. Each Substrate Monitor extracts the Substrate data from the node's websocket url and forwards this data to the Substrate Data Transformer via RabbitMQ.
    3. The Substrate Node Data Transformer starts by listening for data from the Substrate Node Monitors via RabbitMQ. Whenever a Substrate node's data is received, the Substrate Node Data Transformer combines the received data with the Substrate node's state obtained from Redis, and sends the combined data to the Data Store and the Substrate Node Alerter via RabbitMQ.
    4. The Substrate Node Alerter starts by listening for data from the Substrate Node Data Transformer via RabbitMQ. Whenever a Substrate node's transformed data is received, the Substrate Node Alerter compares the received data with the alert rules set during installation, and raises an alert if any of these rules are triggered. This alert is then sent to the Alert Router via RabbitMQ .
    5. The Data Store also receives data from the Substrate Node Data Transformer via RabbitMQ and saves this data to both Redis and MongoDB as required.
    6. When the Alert Router receives an alert from the Substrate Node Alerter via RabbitMQ, it checks the configurations to determine which channels should receive this alert. As a result, this alert is then routed to the appropriate channel and the Data Store (so that the alert is stored in a Mongo database) via RabbitMQ.
    7. When a Channel Handler receives an alert via RabbitMQ, it simply forwards it to the channel it handles and the Node Operator would be notified via this channel.

    For Substrate network monitoring and alerting, PANIC will operate as follows:

    1. When the Monitors Manager Process receives the configurations, it starts one Substrate Network Monitor per chain and keeps the configurations updated. A Substrate Network monitor chooses the first syncing and accessible node it finds to retrieve network metrics.
    2. Each Substrate Network Monitor extracts the Substrate network data from the selected substrate node's websocket url endpoint and forwards this data to the Substrate Network Data Transformer via RabbitMQ.
    3. The Substrate Network Data Transformer starts by listening for data from the Substrate Network Monitors via RabbitMQ. Whenever a Substrate network's data is received, the Substrate Network Data Transformer combines the received data with the Substrate Network's state obtained from Redis, and sends the combined data to the Data Store and the Substrate Network Alerter via RabbitMQ.
    4. The Substrate Network Alerter starts by listening for data from the Substrate Network Data Transformer via RabbitMQ. Whenever a Substrate Network's transformed data is received, the Substrate Network Alerter compares the received data with the alert rules set during installation, and raises an alert if any of these rules are triggered. This alert is then sent to the Alert Router via RabbitMQ .
    5. The Data Store also receives data from the Substrate Network Data Transformer via RabbitMQ and saves this data to both Redis and MongoDB as required.
    6. When the Alert Router receives an alert from the Substrate Network Alerter via RabbitMQ, it checks the configurations to determine which channels should receive this alert. As a result, this alert is then routed to the appropriate channel and the Data Store (so that the alert is stored in a Mongo database) via RabbitMQ.
    7. When a Channel Handler receives an alert via RabbitMQ, it simply forwards it to the channel it handles and the Node Operator would be notified via this channel.

    Development Roadmap ๐Ÿ”ฉโ€‹

    This grant request consists of a single milestone with the aim of expanding the base tool together with the UI to cater for high priority Substrate metrics.

    Overviewโ€‹

    • Total Estimated Duration: 71 days
    • Full-Time Equivalent (FTE): 3
    • Total Costs: ๏ผ„49,984 (USD)

    Table 3โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationUpdate of design and setup documentation present on our repository
    0c.Testing GuideBackend functions will be covered by unit tests. Frontend components will go through unit and end-to-end testing. When deliverables 1 - 7 are implemented and tested, a release candidate will be provided to our staking team for UAT
    0d.DockerOur system will run on Docker. We will make available Dockerfiles to make the running and testing of the product possible
    0e.ArticleDelivery of a Medium article on the need fulfilled by PANIC, together with a high-level description of the product and whatโ€™s coming next
    1.ResearchResearch about the metrics and data sources
    2.MonitorsDevelop Substrate monitors
    3.Data TransformersDevelop Substrate data transformers
    4.Data StoreDevelop Substrate data store
    5.AlerterDevelop Substrate alerter
    6.UIUpdate high-level dashboards with new metric information
    7.UATUser acceptance testing carried out by Simply VCโ€™s staking team

    Future Plansโ€‹

    We see PANIC as being the go-to tool for node operators active on Substrate, Cosmos, and Chainlink networks. For this to be achieved we will continue to introduce more metrics for monitoring and alerting from various data sources. Considerable time and effort will be invested in the UI to introduce new functionality such as MFA and low-level dashboards for additional visual representations on node, governance, and consensus data.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Element

    Work already doneโ€‹

    In its current state, PANIC provides node operators with:

    1. A base tool that monitors host systems that the Substrate/Cosmos-SDK/Chainlink nodes are running on.
    2. Monitoring and alerting on:
      • Chainlink nodes
      • Chainlink contracts
      • EVM nodes
      • GitHub repositories
      • DockerHub repositories
    3. Channels designed to notify node operators of the status of monitored metrics and any issues that might require immediate attention :
      • Telegram
      • Slack
      • Email
      • Twilio
      • PagerDuty
      • Opsgenie
      • Console
      • Log files
    4. Basic control over the alerter (such as mute alerts and check status) via Telegram bots and Slack apps.
    5. A quick installation through an intuitive UI setup and configuration process.
    6. Out-of-the-box alert thresholds for metrics monitored and associated severity levels of alerts (Info, Warning, Major, and Critical), customisable by node operators.
    7. A UI which consists of a high-level dashboard from which node operators can review all alerts together with a low-level dashboard which allows node operators to review the performance of their host infrastructure.

    May 2022 will see an additional release which will allow node operators to get alerted on high priority metrics for Cosmos based chains.

    - + \ No newline at end of file diff --git a/applications/parachain-staking.html b/applications/parachain-staking.html index 1ca5183f94f..0b31e93c623 100644 --- a/applications/parachain-staking.html +++ b/applications/parachain-staking.html @@ -4,13 +4,13 @@ Pallet-dPoS for Parachain Staking | Web3 Foundation Grants - +
    Skip to main content

    Pallet-dPoS for Parachain Staking

    • Proposer: Moonbeam Network
    • Payment Address: 0x9a66721302d9f30a9d11cf48a09c7ef1a842b5c8

    Project Overview ๐Ÿ“„โ€‹

    Moonbeam is an Ethereum-compatible parachain built with Substrate. Since January 2021, Moonbeam's runtime developer team has written and maintained a delegated Proof of Stake (dPoS) implementation designed specifically for parachains called parachain-staking. To make this code useful for other parachain teams, Moonbeam is applying for ecosystem funding to extend, benchmark, and document its dPoS implementation.

    Backgroundโ€‹

    In the Polkadot consensus model, parachains have different requirements and constraints than the relay chain. While frame/pallet-staking offers many features necessary for relay chain consensus and shared security, it is overkill for parachains, which operate with more limited execution resources.

    Instead of running an on-chain election, parachain-staking implements direct delegation with a bounded number of nominations per AccountId (maximum of Config::MaxCollatorsPerNominator per account). In this paradigm, token holders (nominators) express exactly which collator candidates they would like to support and with what quantity of stake.

    There is a new round every <Round<T>>::get().length = 600 blocks. At the start of each round, the top <TotalSelected<T>>::get() = 16 collator candidates (in terms of total backing stake) are chosen to be in the active collator set. At every block, a subset of this active collator set is chosen pseudorandomly by the author-filter pallet as valid block authors. Only valid block authors can produce blocks.

    Block authors are logged via the set_author_inherent method in the author-inherent pallet. The logic in this runtime method reports each block author to parachain-staking, which distributes inflation rewards after a 2 round delay.

    Team ๐Ÿ‘ฅโ€‹

    The PureStake team has extensive experience developing and delivering complex web2 software systems. In the last year, PureStake has built a number of web3 infrastructure projects including Algorand API Services (https://developer.purestake.io/) and the Goalseeker block explorer (https://goalseeker.purestake.io/), among others.

    Derek co-founded Fuze in 2006 and as CTO was responsible for engineering, technical operations, product management, and design as the company grew over time into a 700 person cloud business. Alan was responsible for large parts of the Fuze cloud backend. Before joining Fuze, Alan was on the Google Streetview Team and also worked at NVidia developing drivers.

    Antoine has been developing Web3 Dapps since 2016. He has participated in 3 projects inside ConsenSys (VariabL, Localties and Fathom) and helped HyperNetwork build their token system. Now, he's working for Moonbeam and has contributed to the polkadot-js suite (apps, common, api, etc).

    Joshy and Amar worked at Parity on the Substrate Recipes.

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 6 weeks
    • Full-time equivalent (FTE): 2 FTE
    • Total Costs: 30000 DAI

    Both milestones will be worked on in parallel, but UI development will lag changes to the pallet implementation.

    Milestone 1: Improve Parachain-Staking Palletโ€‹

    • Estimated Duration: 4 weeks
    • Costs: 20000 DAI

    In addition to updating Rust crate-level docs and outdated user-level docs in step (5), we will also pursue the following changes to the current parachain-staking implementation:

    1. Benchmark to derive transaction weights. This work has been started in this PR.

    2. Security Research Labs reported two critical vulnerabilities in parachain-staking: (i) total locked balance was not updated in {collator, nominator}_bond_more leading to a potential underflow error (which could trigger excessive issuance) (ii) bounded number of nominations per collator allowed any account to fill the slots with the minimum nomination thereby preventing higher nominations.

    3. The inflation logic implemented in parachain-staking is minimal. Instead of integrating pallet-staking's reward curve, the current implementation calculates per-round inflation derived from an annual inflation rate. Although the inflation rate can be updated by governance (sudo as of now), it is constant. Some parachain teams (i.e. Kilt) have requested configurable inflation that uses pallet-staking's reward curve instead because it has been audited and reviewed more closely.

    4. Moonbeam reserves 30% of inflation for future parachain bond(s). To support this functionality, parachain-staking added the storage item ParachainBondConfig. This storage item is updatable by the root origin; it configures the percent (30%) of inflation reserved as well as the AccountId which receives the reserved funds. This feature is convenient for parachains in the Polkadot ecosystem, all of which must pay rent to the network by locking funds in the parachain bond.

    NumberDeliverableSpecification
    0a.LicenseGPL3
    0d.DocumentationUpdate Rust crate-level docs and user-level docs with implementation details.
    1.BenchmarkBenchmark the existing implementation to derive transaction weights and discern optimization opportunities.
    2.Patch SR-Labs Critical VulnerabilitiesPatch both critical vulnerabilities reported by SR labs.
    3.Configurable InflationReplace sudo with governance origin for setting inflation rate. Provide instructions for replacing constant inflation with pallet-staking's reward curve logic.
    4.Configurable Parachain Bond ReservationAdd optional parachain bond configuration that enables reserving a portion of inflation for future parachain bonds.

    Milestone 2: Parachain-Staking Polkadot-JS UIโ€‹

    • Estimated Duration: 4 weeks
    • Costs: 10000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    1.Custom Polkadot-JS UIAn overlay UI using polkadot-js similar to the pallet-staking UI
    2.PR polkadot-js appsMake a pull request to polkadot-js apps with output

    Additional Information โž•โ€‹

    The current implementation has significant unit test coverage and this will be maintained throughout the changes listed in Milestone 1. There are also runtime integration tests written in Rust as well as TS integration tests. Maintenance is not explicitly included in the milestones because test coverage is already relatively comprehensive and we have an incentive to maintain it throughout the proposed changes.

    - + \ No newline at end of file diff --git a/applications/parami-protocol.html b/applications/parami-protocol.html index d83e58ec77b..7456aa2bf63 100644 --- a/applications/parami-protocol.html +++ b/applications/parami-protocol.html @@ -4,13 +4,13 @@ The Parami Protocol | Web3 Foundation Grants - +
    Skip to main content

    The Parami Protocol

    • Team Name: The Parami Team
    • Payment Address: 1ET2d5D2aDebVdrV21d6h9w2kuYV4fthv
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    The goal of Parami Protocol is to build a blockchain-empowered fair and transparent win-win private domain traffic advertising alliance, connecting the majority of advertisers, traffic owners and users, removing intermediaries, improving settlement efficiency, allowing users to take back their own digital sovereignty, and the revenue of all parties involved in digital advertising.

    Parami uses Substrate as the blockchain development framework, mainly for two reasons. From the technical level, Substrate framework is a general blockchain development framework launched by Polkadot. Substrate contains all the components needed to build a blockchain, including a p2p network, consensus mechanism, distributed database, transaction queue, and core runtime. The modulized framework provides a powerful tool for chain or side-chain development.

    On an ecological basis, the number of Polkadot developers and projects is growing at a rapid pace. The Web3 Foundation currently funds over 100 projects, most of which are related to Polkadot or Substrate. In terms of eco-applications, there are already nearly 100 projects based on Substrate. More and more talented developers and teams are joining the Polkadot ecosystem. These Web3.0 projects will all have the need for tokenized marketing, thus becoming an important business partner of Parami.

    The Parami protocol will provide a DID-based tokenized advertising preference solution for the whole Polkadot ecosystem, with its power of the parachain & relay-chain mechanism.

    We have done many attempts to combine blockchain with digital advertising, and have been bothered by traditional digital advertising. We have been keeping considering some questions:

    • How can users benefit from the advertising industry?
    • How can users re-gain their control of self digital sovereignty, and be freedom from digital exploitation?
    • How can participants in the digital advertising industry can mutually benefit from each other?

    So we come up with the Parami Protocol, an identity-driven and data-driven solution to digitial advertising.

    From the perspective of the advertising industry, the blockchain technology can get fairness and autonomy. On the other hand, from the blockchain's view, tokenized advertising can bring more opportunities and value growth to the web 3.0 ecosystem.

    Project Detailsโ€‹

    The main participants of the Parami protocol are advertisers and users. The full set of services is achieved through the cooperation of multiple components.

    Project Details

    Parami components include Runtime, Off-chain worker, RPC Interface. Runtime and Off-chain workers work together to implement the core of Parami. The core node code and is maintained by Parami, the nodes will be maintained by the community.

    Advertisers can create ad requests by accessing the Advertiser Portal, which interacts with RPC Interface.

    Users access various types of ads through different ad media. The social integration SDK will fetch and display Ad in IM explorer, then track and upload user interaction data to Advister server.

    Ad metadata is divided into two categories, the on-chain part and off-chain part(IPFS part).

    On-chain ad metadata contains ad parimary key and reward info:

    • issuerdid: issuer did of the ad
    • adid: ID of the ad
    • totalfund: all the fund has been deposited
    • remainfund: the maining fund has been deposited.
    • base: the basic reward for a single ad interaction.
    • bonus: the highest stardard of the bonus reward.

    Off-chain ad metadata will be stored on IPFS, including all other basic ad metadata:

    • id: ID of the ad
    • adomain: ad domain name
    • bundle: unique ID of app where ad is shown
    • url: ad jump url
    • tags: string array of ad topic
    • lang: language code of the ad using ISO-639-1
    • init: timestamp of the original instantiation of this ad
    • lastmod: timestamp of most recent modification to this ad
    • display: ad display data, including static picture url, or video links
    • ext: Optional vendor-specific extensions.

    Business Logicโ€‹

    All ads are pre-registered by advertisers via RPC Interface. So the advertisers know the ad's id, and set up the display of ad in its social platform or mobile apps.

    Life Cycle

    • When a user is to be shown an ad, the underlying RPC API SDK will be responsible for converting the ad id into ipfs metadata information to enable the display of the ad.
    • The SDK will then be responsible for passing the tracking data to the advertiser's server, which will be responsible for confirming the click and passing the confirmation information to the Parami's RPC Interface.
    • The off-chain worker is responsible for initiating reward transactions and updating the user's profile.

    The SDK will be a javascript library for advertisers to complete ad placements, with core functionality including๏ผš

    • DID registry: register/initialize new DID and profile for new user and bind the corresponding social platform ID.
    • DID read: get the DID according to the platform id.
    • Ad display: convert ad id to IPFS resources(metadata in JSON format)
    • Ad track: convert user interaction to track info.
    • Ad data upload: upload user ad data to advertiser server.

    Data Analysis Platformโ€‹

    Advertisers are always very concerned about the effectiveness of advertising. For this reason, we will develop a data analysis platform to facilitate advertisers to do further analysis of placement data and improve the effectiveness of advertising.

    Data Platform Prototype

    Ecosystem Fitโ€‹

    The Polkadot community alreay has a few standard DID solutions. The Parami DID will be a production-ready and domain-specific DID solution. We will add a referral system and use DID attributes as users' ad preference data.

    Projects like XCHNG, MAD Network, ADEX and Parpuys, use smart contracts to build infrastructure, which is expensive for normal users yet not appealing.

    Other projects, like Rebelai, adChain, are using blockchain to solve the problem of deception in traditional advertising, which neglects the value of user data and privacy.

    Parami combines DID with tokenized advertising, providing an Ad 3.0 paradigm to Web 3.0, decentralized privacy and data security, benefiting all participants.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Lucas WU, Team Leader
    • Dorian, Blockchain Architect
    • Yanping YANG, Full-stack Developer
    • Alex, Product Director

    Contactโ€‹

    • Registered Address: 140 PAYA LEBAR ROAD #10-09 AZ @ PAYA LEBAR SINGAPORE 409015
    • Registered Legal Entity: PROCHAIN FOUNDATION LIMITED

    Team's experienceโ€‹

    Lucas WU

    • Senior Blockchain Architect
    • Former experience in TRON Protocol and STEEM
    • OpenSource enthusiast
    • Github: @wubin01(https://github.com/wubin01)

    Dorian

    Yanping YANG

    • Full-stack Developer
    • blockchain enthusiasts and familiar with rust
    • Github: @Yanping YANG

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated duration: 4 months
    • Full-time equivalent (FTE): 3 FTE
    • Total Costs: 1 BTC

    Milestone 1 โ€” The Parami Protocolโ€‹

    • Estimated duration: 4 month
    • FTE: 3
    • Costs: 1 BTC
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.API DocumentationWe will provide inline documentation of the code and API documentation to help developers to integrate Parami DID into their project
    0c.TutorialWe will provide a standalone tutorial for endusers and developers. This will be a step-by-step guide.
    0d.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0b.TestnetSetup and run a testnet
    1.Substrate module: didWe will create a Substrate module that will generate and manage on-chain DID with detailed preference profile. A referral system will be integrated with DID
    2.Substrate module: adsWe will create a Substrate module that will manage ads metadata, including traditional ads metadata and rewarding settings
    3.Substrate module: pricesWe will create a Substrate module that will act as the price oracle to provide real-world prices of different kinds of assets
    4.Substrate chainAll above modules of our custom chain will interact to provide a useable Ad platform. There will be APIs to setup DIDs and ads and APIs that allow transfer assets via DID
    5.Web UI: Advertiser AppWe will create a web-ui for advertisers, hiding the raw APIs from advertisers, providing an easy access to the ad management system
    6.Wallet AppWe will create a web-based wallet that is embedded to WeChat MiniProgram, the tech stack will be vue.js
    7.Social Integration SDKWe will integrate ads to some social platforms like WeChat, allowing ad viewers to be verified as DID owners and gain rewards. To enable the combination of Wallet App and social platforms, we will rely on the open platform functionality provided by social platforms. The functionality will include DID registry, DID read, Ad display, Ad track and Ad data upload.

    Future Plansโ€‹

    We will continue to build a more decentralized Ad platform for the Polkadot ecosystem.

    • Refine oracle implementation. Engage ad-specific validation into it, like an anti-spam check, visibility validation, and so on.
    • Introduce offchain-worker to verify ads and rewards
    • Introduce chain governance logic to setup a more decentralized platform
    • Introduce NFT support for advertisers, allowing issuing coupons, vouchers, tickets, etc
    • Introduce a Zero Knowledge Proof based data module, enhancing data privacy

    Additional Information โž•โ€‹

    Any additional information that you think is relevant to this application that hasn't already been included.

    • What work has been done so far?

    Github projects: https://github.com/parami-protocol

    • Are there are any teams who have already contributed (financially) to the project?

    ProChain Foundation.

    • Have you applied for other grants so far?

    Substrate Builder Program.

    - + \ No newline at end of file diff --git a/applications/patron.html b/applications/patron.html index 151b96270e0..4957f615d91 100644 --- a/applications/patron.html +++ b/applications/patron.html @@ -4,7 +4,7 @@ Patron | Web3 Foundation Grants - + @@ -46,7 +46,7 @@ External API->>+Patron: Weather data response. Patron->>+Smart contract: set_weather_data method call

    This feature can be expanded with vast scripting support, allowing user to execute arbitrary off-chain code that interacts with external services and the smart contract itself.

    Ecosystem fitโ€‹

    Where and how does your project fit into the ecosystem?โ€‹

    Our platform can significantly improve the ink! ecosystem by covering transparency and security and providing versatile features, allowing developers and smart contract users to discover, discuss and improve.

    Who is your target audience?โ€‹

    Our target audience is WebAssembly smart contract developers, independent auditors, vulnerability researchers, and users who want to discover new smart contracts to use and discuss.

    What need(s) does your project meet?โ€‹

    Our project can significantly improve the general trust of users in smart contracts while also improving developer user experience by providing a versatile feature set.

    Are there any other projects similar to yours in the Substrate/Polkadot/Kusama ecosystem?โ€‹

    We are aware of Epirus Substrate explorer project (as well as an active project to create an ink! verification server).

    Epirus explorer provides smart contract explorer features, however, no known effort to create a smart contract manager (similar to OpenZeppelin Defender functionality) is ongoing.

    Verification will be part of the deploy flow and thus with mass adoption will be out of the box for every product deployed.

    Team membersโ€‹

    Contact

    Legal Structure

    Cay II, P. O. Box 2221, Road Town, Tortola, VG1110, British Virgin Islands.

    Team's experience

    CEO of 727.ventures, a blockchain entrepreneur, and a software engineer.

    I began my engineering career at the age of 15 and have since gained extensive experience in both engineering and leadership. Having founded a couple of startups, I also gained entrepreneurial experience. I was inspired to co-found and invest in Sector F, one of the top consulting companies in Ukraine that helps entrepreneurs to accelerate their growth.

    Head of Engineering

    Started programming his own games at the age of 15 as a hobby, then went to University to study informatics and object-oriented programming, becoming an Android developer and eventually switching to work in web3. Dominik played a crucial role in the OpenBrush and Sol2Ink development and is currently developing the ink! smart contracts tools as part of Brushfam.

    Blockchain Developer

    Blockchain developer with proficiency in the Rust programming language. Developed various libraries and applications using Rust, with a primary interest in developing the WASM smart contract ecosystem.

    Blockchain Developer

    Became interested in programming at the age of 16. At this time, he tried web development and created a website. Then decided to go to University to study system programming and object-oriented programming. Most often, he used C and C++ languages. Nameless likes innovations of web3 technologies and believes in the potential of Rust language and WASM standards for smart contracts.

    Blockchain Developer

    Student of Computer Science at the Kyiv National University of Taras Shevchenko. Participated in programming competitions of different stages in school since 2017 (C++). Was a Backend developer (Go), Solidity developer(Solidity, Hardhat, Typescript), and now a Blockchain developer (Rust, Typescript).

    Blockchain Developer

    Student of Applied Mathematics at the Kyiv National University of Taras Shevchenko. Started programming in 2016 and participated in a lot of Ukrainian and international competitions of competitive programming. Worked as a lecturer of algorithms at the school of competitive programming and as Intern Backend Engineer (Rust). Now works as Blockchain Developer on Polkadot Blockchain (Rust, Typescript).

    Matviy Matsipura

    Gained professional experience as a lead designer in a product company, where he was responsible for creating packaging and visual designs for a popular milk brand in Ukraine. Transitioned to the field of web3 design and is currently leading the design process for blockchain projects.

    Team Code Repos

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles

    Development roadmapโ€‹

    Overviewโ€‹

    Total duration: 7 weeks

    FTE: 3

    Total cost: 63,000 USD

    Milestone 1 - MVP with verification functionality onlyโ€‹

    Duration: 7 weeks (Frontend, Backend, CLI utility implementations).

    FTE: 3

    Total cost: 63,000 USD

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide API documentation for contributors to get along with the codebase, as well as a detailed self-hosting instructions for users to create their own nodes.
    0c.Testing guidelinesCore functionality will be covered by a comprehensive unit test suite.
    0d.DockerWe will prepare Docker images for users to spin up their own nodes more easily and conveniently.
    0e.ArticleWe will publish an article that explains the achievements done as part of the grant.
    1a.Backend storageBackend implementation with contract discovery and persistent storage.
    1b.Sync serverA separate server that catches new contract deployments and events will be implemented.
    1c.Smart contract builderImmutable, pre-configured smart contract builders are to be implemented for verified smart contract deployment.
    2a.Web UIA simple web UI will be implemented to expose Patron functionality.
    2b.Detailed contract informationFrontend to display detailed contract info (as well as verification status) will be implemented.
    2c.User authenticationWe will implement a web3-oriented authentication solution
    3a.Developer CLI utilityA deployment workflow unified, developer-oriented CLI utility will be implemented.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Personal recommendation

    - + \ No newline at end of file diff --git a/applications/perun_app_channels.html b/applications/perun_app_channels.html index fd9f8ee4077..92109af832f 100644 --- a/applications/perun_app_channels.html +++ b/applications/perun_app_channels.html @@ -4,7 +4,7 @@ Perun App Channels | Web3 Foundation Grants - + @@ -41,7 +41,7 @@ Back in 2020, Dieter Fishbein motivated the Perun team to apply for a grant. Since then, we have successfully completed two grant projects with the Web3 Foundation.

    Other project funding. The Perun project receives funding from the German Ministry of Education and Science (BMBF) through the StartUpSecure grants program.

    - + \ No newline at end of file diff --git a/applications/perun_channels-integration.html b/applications/perun_channels-integration.html index 57705477ef6..b10b4f3ad25 100644 --- a/applications/perun_channels-integration.html +++ b/applications/perun_channels-integration.html @@ -4,7 +4,7 @@ Perun Channels - Integration with go-perun | Web3 Foundation Grants - + @@ -44,7 +44,7 @@ In 2020, we joined the hyperledger foundation together with our industry partner BOSCH, with the goal of growing an open-source community around the Perun project.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Wallet Abstractionโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.Wallet abstractionWe provide an implementation of the wallet abstraction for Polkadot. The details are given in Project Details.

    Milestone 2 โ€” Channel Abstractionโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.Channel abstractionWe provide an implementation of the channel abstraction for Polkadot. The details are given in Project Details.

    Milestone 3 โ€” End-to-end testsโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a developer can use Perun channels on Polkadot, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.End-to-end testsWe provide end-to-end tests that test the interplay between the new components.

    Milestone 4 โ€” Improve Palletโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.Weight estimationCurrently, perun-polkadot-pallet functions have a dummy constant weight. We will provide reasonable weight estimations, e.g., using benchmarking. This will require adapting our test setup.
    2.Code CoverageWe provide code coverage results and add a code coverage badge to perun-polkadot-pallet.

    Milestone 5 โ€” CLI Demoโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article or workshop that explains what was done as part of the grant.
    1.CLI DemoWe provide a Perun Polkadot CLI Demo similar to perun-eth-demo. The demo lets users experiment with the technology and send payments between each other via a Perun Channel on Polkadot.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? After Dieter Fishbein joined the Web3 Foundation, he reached out to Sebastian Stammler in June 2020.

    Other project funding. The Perun project is supported by the German Ministry of Education and Science (BMBF) through a Startup Secure grant.

    - + \ No newline at end of file diff --git a/applications/perun_channels.html b/applications/perun_channels.html index 19a53c5f9cd..b1284904f99 100644 --- a/applications/perun_channels.html +++ b/applications/perun_channels.html @@ -4,7 +4,7 @@ Perun Channels | Web3 Foundation Grants - + @@ -44,7 +44,7 @@ We plan to provide the corresponding off-chain functionality written Go in the context of a follow-up grant application.

    Milestone 1 โ€” Setup & Core Types & Channel openingโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.SetupWe provide a repository that forms the basis of our deliverables.
    2.Core TypesWe provide the core data types, as specified in Project Details.
    3.Open/DepositWe provide the channel opening (i.e., deposit) functionality as specified in Project Details.

    Milestone 2 โ€” Channel disputes & settlementโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article or host a workshop that explains what was done as part of the grant.
    1.DisputeWe provide the channel dispute functionality as specified in Project Details.
    2.SettlementWe provide the channel settlement functionality as specified in Project Details.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? After Dieter Fishbein joined the Web3 Foundation, he reached out to Sebastian Stammler in June 2020 regarding grants, finally resulting in this application.

    Other project funding. The project is partially supported by the the German Ministry of Education and Science (BMBF) through a Startup Secure grant.

    - + \ No newline at end of file diff --git a/applications/pesa_pallet.html b/applications/pesa_pallet.html index a73073c56e3..ca3771147dd 100644 --- a/applications/pesa_pallet.html +++ b/applications/pesa_pallet.html @@ -4,13 +4,13 @@ PESA - On-ramp/off-ramp to crypto/local currencies for Polkadot | Web3 Foundation Grants - +
    Skip to main content

    PESA - On-ramp/off-ramp to crypto/local currencies for Polkadot

    • Proposer: jdoshi1
    • Payment Address: 3K37k6BQ1JwAczAyNzckS4cGRqhpL6UgYJ
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    PESA is a decentralized cross-chain mobile money protocol that enables anyone to buy, sell, send, receive, lend, borrow - crypto, and mobile money (i.e. tokenized minutes, data, WiFi) globally using a phone number.

    Overviewโ€‹

    The goal of this project is to make telecom and financial services open and accessible to all. Anyone with a mobile phone can utilize PESA to:

    • Access carrier-independent voice, text, data & WiFi (mobile money)
    • Send/receive crypto and mobile money to/from any phone number
    • Buy/sell crypto and mobile money using a phone number
    • Lend, borrow, crypto assets using a phone number

    PESA is structured as a decentralized carrier and acts as a mobile money system. The traditional mobile money systems like m-pesa use phone numbers to uniquely identify users. Similarly, PESA uses tokenized phone numbers. A phone number is universal across chains and mapped to respective wallet addresses.

    PESA aims to serve as an on-ramp/off-ramp to crypto/local currencies for the Polkadot users, applications, and developers. This is enabled by allowing users to purchase tokenized voice, text, data and WiFi credits using credit card, cryptocurrencies and eventually cash. To achieve this, we can either create our own Substrate-based blockchain or Parachain or work with Parachains like Plasm, Moonbeam, Acala, etc.

    Project Detailsโ€‹

    As a first step, we are proposing creating a pallet to perform Phone Number to Address resolution, reverse resolution, and execute transactions such as send & receive - crypto tokens, mobile money (i.e. tokenized minutes, data and WiFi) using phone numbers.

    PESA palletโ€‹

    The goal of PESA pallet is to resolve the phone number to an address and allow the phone number to execute transactions - send, receive. It will be extensible to allow more functionality like lend & borrow, etc. Furthermore, it will be beneficial to dapps building financial systems (DeFi) including allowing unbanked users to onboard onto the system by just using a phone number.

    Interface and Designโ€‹

    The PESA pallet will expose the following callable functions:

    register - allows the user to register a Phone Number to its address

    resolve - allows any user to resolve a Phone Number to an address

    reverse_look_up - allows the user to look up Phone Number from an address. Provided the owner of the phone number/address opted to make it public.

    transfer - allows the owner of the Phone Number/address to transfer ownership of the Phone number to another address.

    send - allows the owner to send tokenized mobile money (i.e. mins, data and wifi) and other tokens built on the parachain(s) using the Phone Number

    Mockups of PESA Dapp

    • Register Phone number with wallet address

      Register

    • Verify Phone number ownership

      Verify

    • Send transaction

      Send

    Ecosystem Fitโ€‹

    All web and mobile wallets like Airgap and Polkawallet can use PESA pallet to resolve phone numbers and access other pallet functions mentioned above. DeFi applications can also use the pallet to allow users to access financial services using a phone number.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Suruchi Gupta (Founder & CEO)
    • Jinesh Doshi (Engineering head)
    • Leo Anbarasan M (Tech Lead/ Lead developer)

    Team Websiteโ€‹

    Wificoin, a Delaware C corporation, 3165 Olin Ave, San Jose, CA 95117. We also have โ€œWificoin Foundationโ€ incorporated in Panama.

    Team's experienceโ€‹

    The team has extensive experience building and shipping web, mobile apps, and DevOps tools. Suruchi and Jinesh are co-founders and both hold a Masters in Computer Science. Prior to founding Wificoin, Suruchi was a full stack developer and Tech Lead at Juniper Networks. Jinesh in his most recent role is a Senior Developer at Salesforce, building DevOps tools. Leo has been building web2 applications for the last 12+ years.

    In the last year, Wificoin has built a pay-as-you-go, mobile-first carrier (a precursor to the decentralized carrier), that offers on-demand voice, text, data, and WiFi globally without needing to swap sim cards. Today, Wificoin users can access the internet on mobile via LTE eSIM in 45 countries (soon 113 countries), on the ground at 68M+ hotspots in 180 countries, on flights at 5000+ airplanes on 37 airlines (55% market penetration). In addition, users can call and text in 200 countries and get local phone numbers in US & Canada (soon 10 countries). Wificoin apps have been featured as a #1 Top grossing app in the Travel category several times. Over 11M credits (proxy for token) have been consumed by users.

    The team has also integrated with Telecom operators like AT&T, Claro, etc.

    Team Code Reposโ€‹

    • No public repos to share yet.

    • Apps in App store & Play store:

      Wificoin - iOS, Android

      Hoom - iOS, Android

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-time equivalent (FTE): 3
    • Total Costs: 2 BTC

    Milestone 1 - Implement Substrate Pallet "PESA"โ€‹

    • Estimated Duration: 1.5 months
    • FTE: 1.5
    • Costs: 1 BTC
    NumberDeliverableSpecification
    1.Substrate pallet: PESA1. Pallet will expose a function called register to allow caller to register the phone number to their wallet address
    2. Pallet will allow users to perform Phone Number to address look up.
    2.Create a dappCreate a custom chain with the PESA pallet and a dapp to allow users to enter a phone number and associate that with the owner's wallet address. Users will be able to perform address lookup by providing a phone number. Dapp will be in Angular/Javascript.
    3.Unit testsThe code will have proper unit-test coverage to ensure functionality and robustness. Readme will provide details on how to run the tests.
    4.DockerfileProvide a docker image with a substrate node using our pallet.
    5.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can interact with the substrate runtime to call the PESA palletโ€™s APIs.

    Milestone 2 โ€” PESA pallet send, receive tokens using phone number and reverse lookupโ€‹

    • Estimated Duration: 1.5 months
    • FTE: 1.5
    • Costs: 1 BTC
    NumberDeliverableSpecification
    1.PESA pallet - send, receive and reverse lookup functions1. Pallet will allow users to send and receive tokens using phone number instead of using complex hash.
    2. Pallet will allow users to perform reverse resolution of address to Phone number if the users opted to allow during register operation.
    2.Backend setup for Phone number verificationBackend will be in NodeJs to perform phone number verification/validation using Twilio.
    3.Demo of the above functionalities using a web dappDapp showing these features.
    4.Dockerfile(s)Provide a docker image with substrate node using our pallet. Docker image for backend.
    5.Unit Tests and DocumentationProvide documentation for:
    1. Steps to run the substrate node with PESA pallet.
    2. Steps to use web dapp to interact with it.
    3. Steps to run backend locally.

    Community engagementโ€‹

    The tutorials and Documentation that we provide will be published as articles in Medium and other social media platforms with due mention about Web3 grant.

    We also intend to engage community by providing grants in our tokens to add more support and improve our codebase.

    Future Plansโ€‹

    Our goal is to make telecom and financial services open and accessible to all. So we plan to continually increase the services that can be accessed using phone numbers (for eg: lend, borrow), aiming to unlock access to advanced financial services for the unbanked as well.

    Additional Information โž•โ€‹

    We are going to use this pallet for building a borderless mobile money system but anyone can extend it to support address resolution for other non-fungible tokens.

    - + \ No newline at end of file diff --git a/applications/php-rpc-lib-follow-up.html b/applications/php-rpc-lib-follow-up.html index a51b0b13ef8..1f7a7269b61 100644 --- a/applications/php-rpc-lib-follow-up.html +++ b/applications/php-rpc-lib-follow-up.html @@ -4,7 +4,7 @@ PHP RPC Lib Follow up | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    PHP RPC Lib Follow up

    • Team Name: gmajor
    • Payment Address: 0xC3094f0ddce699a1Ad9Ef2621DF68Cd297a4c44F (Dai)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    As Gavin mentioned in this CoinDesk article, WebAssembly is the future of smart contracts.

    However, WebAssembly, as the main Smart Contract in the substrate ecosystem, lacks the necessary infrastructure. Except for the lib of contracts provided by polkadot.js, there are no more third parties that can query the contract storage and interact with the package.

    PHP is one of the most popular development languages in the world, PHP is used by 77.8% of all the websites whose server-side programming language(https://w3techs.com/technologies/details/pl-php).

    Traditional PHP Website developers will lack the necessary SDK if they come into contact with the substrate, However, the lack of support for contracts in the current php-substrate-api makes it very difficult to use PHP as a development language to interact with the substrate.

    Therefore, this proposal is an extension of php-substrate-api to improve the practicability of this package further and increase support for smart contracts.

    Project Detailsโ€‹

    • Abi encode & decode, support contract metadata v0,v1,v2,v3,v4, this will be used to read and write smart contracts

    • Deploy wasm smart contract

    Example

    $api = new SubstrateRpc("websocket_or_http_url");
    $api->rpc->contracts->new("wasm_code", "gas limit","value");
    • Read contract values

    Example

    $api = new SubstrateRpc("websocket_or_http_url");
    $api->rpc->contracts->balanceOf("from","contract");
    • Send Contract transaction

    Example

    $api = new SubstrateRpc("websocket_or_http_url");
    $signer = new SubstrateRpc\Util\Keyring\Signer("privatekey");// or HD
    $api->setSigner($signer);
    $tx = $api->tx->contracts->transfer("to_address", 10000);
    $tx->signAndSend();

    Ecosystem Fitโ€‹

    CIt can help PHP language developers easily access the substrate (polkadot) ecology

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • gmajor

    Contactโ€‹

    individual

    Team's experienceโ€‹

    I have many years of php development experience and nearly five years of blockchain development experience, familiar with PHP, GOLANG, PYTHON, Nodejs, Rust

    Team Code Reposโ€‹

    https://github.com/gmajor-encrypt/php-scale-codec

    https://github.com/gmajor-encrypt/php-substrate-api

    https://github.com/gmajor-encrypt/sr25519-bindings

    https://github.com/gmajor-encrypt/scale-codec-comparator

    Development Status ๐Ÿ“–โ€‹

    Not yet

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1.5 months
    • Total Costs: 10000 DAI

    Milestone 1โ€‹

    • Estimated duration: 1.5 month
    • FTE: 1
    • Costs: 10000 DAI
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationDocumentation on how to use this lib and how to test
    1.ABIAbi encode & decode, contract metadata v0,v1,v2,v3,v4 will be supported
    2.Deployphp-substrate-api implement new method of deploy wasm smart contract
    3.Read contractImplement method read contract values and decode as human readable, similar to api-contract-read
    4.Write contractImplement method send Contract transaction, similar to api-contract-tx
    5.TestIncluding all the unit tests mentioned above
    6.ExampleProvide some simple examples of using this lib
    7.PackagistSubmit to Packagist for composer to use
    8.Github actionAuto Test when new commit

    Future Plansโ€‹

    This milestone still lacks support for smart contract verification, there is no better solution at present, and will be supported after research

    - + \ No newline at end of file diff --git a/applications/php-rpc-lib.html b/applications/php-rpc-lib.html index c58ba97272c..abe9510d60f 100644 --- a/applications/php-rpc-lib.html +++ b/applications/php-rpc-lib.html @@ -4,14 +4,14 @@ PHP RPC Lib | Web3 Foundation Grants - +
    Skip to main content

    PHP RPC Lib

    • Team Name: gmajor
    • Payment Address: 0xC3094f0ddce699a1Ad9Ef2621DF68Cd297a4c44F(Dai)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    PHP RPC Lib is PHP lib for query http rpc used by substrate.

    Overviewโ€‹

    • PHP is an extremely common development language in the web field, and currently there is no RPC library for substrate. I have already developed https://github.com/gmajor-encrypt/php-scale-codec in the previous grant. PHP RPC Lib is necessary to interact with the chain

    Project Detailsโ€‹

    • Sr 25519

    Since PHP does not have an encryption library for sr25519

    Will provide the following interfaces

    1. SR25519.NewKeypairFromSeed(seed)
    2. SR25519.sign(message),
    3. SR25519.verify(message, signature)
    • Send transaction

    Example

    $api = new SubstrateRpc("websocket_or_http_url");
    $signer = new SubstrateRpc\Util\Keyring\Signer("privatekey");// or HD
    $api->setSigner($signer);
    $tx = $api->tx->balances->transfer("to_address", 10000);
    $tx->signAndSend();
    • Read/subscribe HTTP/Websocket to RPC endpoints

    Example

    $api = new SubstrateRpc("websocket_or_http_url");
    $api->rpc->System->Heath();

    # or read storage 
    $api = new SubstrateRpc("websocket_or_http_url");
    $api->rpc->state->System->Account("/ALICE");

    Ecosystem Fitโ€‹

    Can help php language developers to easily access the substrate (polkadot) ecology

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • gmajor

    Contactโ€‹

    individual

    Team's experienceโ€‹

    I have many years of php development experience and nearly three years of blockchain development experience, familiar with PHP, GOLANG, PYTHON, JS

    Team Code Reposโ€‹

    https://github.com/gmajor-encrypt/php-scale-codec

    https://github.com/gmajor-encrypt/php-substrate-api

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Total Costs: 9000 DAI

    Milestone 1โ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: 5000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationSimple documentation on how to use this library
    1.HTTP RPC supportHttp Rpc support, include http/websocket
    2.sr25519sr25519 bindings
    3.Unit testIncluding all the unit tests mentioned above
    4.PackagistSubmit to Packagist for composer to use

    Milestone 2โ€‹

    • Estimated Duration: 1 month
    • FTE: 1
    • Costs: 4,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationSimple documentation on how to use this library
    1.Extrinsic encodeExtrinsic encode
    2.Signed Extrinsic sendSend transaction support, include ed25519&sr25519
    3.substrate rpc apisupport all substrate rpc like https://polkadot.js.org/docs/substrate/rpc
    4.Unit testIncluding all the unit tests mentioned above
    5.PackagistSubmit to Packagist for composer to use

    Future Plansโ€‹

    1. Long-term support, Because I found that the underlying changes of the substrate are still very frequent, like metadata, I expect will be a long-term job in the future
    - + \ No newline at end of file diff --git a/applications/php-scale-lib.html b/applications/php-scale-lib.html index 4d42150e239..239824a0095 100644 --- a/applications/php-scale-lib.html +++ b/applications/php-scale-lib.html @@ -4,14 +4,14 @@ PHP Scale Codec | Web3 Foundation Grants - +
    Skip to main content

    PHP Scale Codec

    • Team Name: gmajor
    • Payment Address: 0xC3094f0ddce699a1Ad9Ef2621DF68Cd297a4c44F

    Project Overview ๐Ÿ“„โ€‹

    Scale Codec is PHP lib for decode/encode used by substrate.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • gmajor

    Contactโ€‹

    Team's experienceโ€‹

    I have many years of php development experience and nearly three years of blockchain development experience, familiar with php, golang, python, js

    Team Code Reposโ€‹

    https://github.com/gmajor-encrypt/php-scale-codec https://github.com/gmajor-encrypt/php-substrate-api

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 8 weeks
    • Total Costs: 12000 Dai

    Milestone 1โ€‹

    • Estimated Duration: 4 weeks
    • Costs: 6000 Dai
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationSimple documentation on how to use this library
    1.Scale decodeThis deliverable includes the following types of https://substrate.dev/docs/en/knowledgebase/advanced/codec : Fixed-width Integers,Compact/General Integers,Boolean,Options,Vectors,Strings,Tuples, Structures, Enum
    2.Scale encodeThis deliverable includes the following types of https://substrate.dev/docs/en/knowledgebase/advanced/codec : Fixed-width Integers,Compact/General Integers,Boolean,Options,Vectors,Strings,Tuples, Structures, Enum
    3.Unit testIncluding all the unit tests mentioned above
    4.PackagistSubmit to Packagist for composer to use

    Milestone 2 Example โ€” Additional featuresโ€‹

    • Estimated Duration: 2 weeks
    • Costs: 6200 Dai
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationSimple documentation on how to use this library
    1.Metadata decodesupport recent runtime metadata decode
    2.Results encode/decodeResults types encode/decode, https://substrate.dev/docs/en/knowledgebase/advanced/codec#results
    3.Event decodestorage EventRecord decode
    4.Extrinsic decodeExtrinsic decode
    5.Custom Type regCan register a custom type through the file
    6.Unit testIncluding all the unit tests mentioned above
    7.PackagistSubmit to Packagist for composer to use

    Future Plansโ€‹

    1. Long-term support, Because I found that the underlying changes of substrate are still very frequent, I expect scale lib will be a long-term job in the future
    - + \ No newline at end of file diff --git a/applications/php-substrate-api.html b/applications/php-substrate-api.html index 5fbe446eb8c..787a1465106 100644 --- a/applications/php-substrate-api.html +++ b/applications/php-substrate-api.html @@ -4,7 +4,7 @@ php substrate api | Web3 Foundation Grants - + @@ -19,7 +19,7 @@ He is a Blockchain enthusiast and believes in its potential to bring about digital transformation in various industries.

    Tejbahadur Singh is a team manager and Blockchain developer cum researcher. He is well versed with technology like PHP, Rust, Python, Go for development. He is a full stack developer and tech enthusiast. He enjoys to give solution to different technical issues. He is having experience in email, medical, media domains. He has developed many enterprise email solutions. He has built and maintained enterprise and small scale website also. He is good at performance enhancement of website and debugging the issues. He is good at AWS services for maintaining performance and availibility of website. Good security researcher also.

    Neha Reddy is a software developer and Blockchain developer. She has built and maintained website and web applications by using PHP and JAVA technology. Also worked on API's for mobile application and third party API's integration. Neha is a passionate coder and works on different technical stacks as the situation demands and very eager to learn new things.

    Arati Bongale is a Software engineer. She is an enthusiastic developer. Eager to learn new technologies and methodologies. She has experience working with various Blockchain technologies like Hyperledger, Ethereum, Substrate and Programming languages like Go lang, Rust, Cpp, Java. She has done projects in Ethereum, Hyperledger Fabric; Web Application using Rust, Substrate etc. She is familiar with database like Postgres SQL, MySQL & tools like truffle, Remix . She has also used wallets like Ganache & Metamask for her Blockchain project. Always willing to innovate the new things which can improve the existing technology.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    For implementing the library class to make RPC endpoint call is being created. Work on initialisation of properties and methids is going on. Deliverables as comply to rfp are in progress.

    Development Roadmap ๐Ÿ”ฉโ€‹

    A class which can be instantiated in an application to use endpoints

    $testClass = new SubstrateInterface("http_url");
    echo $testClass->rpc->system->name();

    once RPC endpoints are consumed package it and make it usable for other applications to integrate it.

    composer require neha0921/substrate-interface-package

    Overviewโ€‹

    Milestone 1 Example โ€” Implement Substrate Modulesโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic example that explains how a user can use this library. A documentation containing class, function details.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.substrate RPC enpoint integrationIntegrate all substrate RPC endpoints in PHP to make them available in other PHP applications

    Milestone 2 Example โ€” Additional featuresโ€‹

    NumberDeliverableSpecification
    0.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    1.packaging application for integrationmake packagist of this integration to enable composer installation
    2.integration and usean example of how to use this package in PHP application

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We got a suggestion of Gautam from parity about start with some grant

    - + \ No newline at end of file diff --git a/applications/plip.html b/applications/plip.html index 66881c33cde..83803bdea28 100644 --- a/applications/plip.html +++ b/applications/plip.html @@ -4,7 +4,7 @@ People Local Interactions Protocol (PLIP) | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ Communications & Business Development Samantha Robertson

    Contactโ€‹

    We are a registered LLC in the United States.

    Team's experienceโ€‹

    Daniel Olano is a Rust/Substrate Guru, and grinding full time to bring his brain child, Valibre, into fruition. He is a Colombian living in Berlin. He was first inspired to create Valibre to facilitate seamless fiat to crypto onboarding for users with varied financial literacy to combat the plague of hyperinflation across Latin America, but is excited to expand to failing fiat economies worldwide. He is currently facilitating the first Rust developer workshop in Spanish to increase visibility of Substrate and Polkadot to developers across LATAM.

    Stanly Johnson is based in Bangalore, India and is a seasoned software engineer across the stack of programming languages underpinning Web3 technologies, including Rust, Python, and Solidity. He is currently working as a runtime developer part-time with Valibre specializing in cross-chain transfers and escrow. Stanlyโ€™s passion for distributed systems stems from the opportunity it provides to reach everyone by eliminating systemic barriers.

    Samantha Robertson is a globetrotter with expertise across Business Development, Product, and Strategy. Samantha desended into the cypherpunk realm after working in product at an AI company, becoming dismayed by the necessary data extraction tactics to train AI models. Samantha is most excited to help build Valibre because she believes that it has the potential to onboard thousands of users to the blockchain without extensive education on technical intricacies. Samantha became a Polkadot stan when she grew fed up with gas fees and MEV. She has vast experience leading international teams and beleives that Web 3.0 technologies represent the future of multilateral cooperation.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    As part of the Substrate builders program we have completed the MVP implementation of the escrow and local rates pallet of the VLN parachain.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    We plan to have a public testnet of the Valibre Network (VLN) with a dedicated Matrix server for the PLIP community that can showcase the usage of the escrow system through a modified element.io chat UI. We will also revamp our website and documentation to educate developers on how to develop applications with the Valibre Open Runtime.

    Milestone 1 โ€” testnet.valibre.networkโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up our local testnet and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a docker-compose file that set-ups the local testnet of the parachain with everything needed to test all the functionality delivered with this milestone.
    1.Escrow palletFeature complete and permissionless version of the Escrow pallet ready for production use(economically secure and are properly weighted)
    2.Rates palletFeature complete and permissionless version of the Rates pallet ready for production use(economically secure and are properly weighted)
    4.testnet.valibre.networkRuntime modules will be available for community testing in our public testnet

    Milestone 2 โ€” plip.communityโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up the custom element.io interface that connects to a local testnet.
    0c.DockerWe will provide a docker-compose file that set-ups the local testnet of the parachain with everything needed to test all the functionality delivered with this milestone.
    1.ValorImplement the ability to compile Valor to WebAssembly so the wallet API can run in the Web
    2.Summa walletCreate the initial version of the Summa plugin that can derive a logged-in user blockchain address from its Matrix device keys
    3.Developer docsAdditional to the standard inline documentation we would provide a more in-depth overview of the PLIP stack at dev.plip.community with a guide on how to develop and run custom Valor plugins as HTTP APIs that can talk to the blockchain.
    4.plip.communityValor and the wallet will be available for testing under plip.community that would showcase a custom version of the element.io chat with our tools running on top

    Future Plansโ€‹

    Valibre's primary ambition is to be come the decentralized WeChat, a "super app" that promotes community engagement and provides access to any multilde of services and marketplaces powered by a decentralized infrastruture (PLIP.) We plan to execute this in two distinct ways over the short and long term:

    Short Term

    In conjunction with the development strategy explained above, we will aggressively ramp up community engagement efforts by executing a social media strategy across Telegram, Element, Medium, and Twitter. We have already been approached by two prospective partners to use our technology as the backend to power their decentralized communities. As such, we will build communities across social media and plan to promote a basic UI demo by the end of Q3 2021. Additionally, we have already successfully submitted a proposal to the Kusama Tresury and plan to submit two more proposals before the end of the year as a means to sustain our development as well as increase our visibility in the Kusama and Polkadot ecosystems.

    Long Term

    Alongisde the promotion of our project, our team is working to define a buisness development strategy that aligns with both our resource constraints as well as the needs of the broader ecosystem. This will unfold as either:

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website, the Substrate Builder's Program, as well as a networking meeting with the Acala team.

    Previous Funding and Support

    Valibre is the brainchild of Daniel Olano, and ultimately attracted the attention of Valiu, a stablecoin payments platform for users in Venezeula. Valibre was temporarily contracted by Valiu while also remaining an independent organization. We have created the basic foundation of PLIP with the required functionality of Valiu (remittances) as the basis of our inspiration, but now we are upgrading the foundations of PLIP to accomdate a broadend scope of use cases. This grant application is our first attempt seeking indepenent funding of any kind.

    - + \ No newline at end of file diff --git a/applications/polk-auction.html b/applications/polk-auction.html index b2246a1c524..9101e37e5f3 100644 --- a/applications/polk-auction.html +++ b/applications/polk-auction.html @@ -4,7 +4,7 @@ Polk-Auction Website | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ https://github.com/CrommVardek/polkot-api (Polkadot client (WebSocket) in kotlin, to be used in polk-auction-core)

    Polk-auction-ui (started)โ€‹

    https://github.com/CrommVardek/polk-auction-ui

    See overview section for the mock-up

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 Implementation of the HTTP API (Polk-auction-core)โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationI will provide an API specification of the HTTP end-points. I will also provide a small documentation on how to run the project and how the project structure was done.
    0c.Testing GuideIntegration tests will be made, as the project does not have business functions, it is more important to ensure the correct data-flow. A guide on how to run the tests will be made
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.Current-Auction end-pointThe current auction end-point is an HTTP GET end-point to provide the current auction information of the ongoing auction of the specified chain (e.g. GET /auction/Kusama). Behind the end-point, the service query the correct node (chain) through an instance of side-car and complement the missing information with a custom Polkadot Websocket (inspired from both Polkaj and @Polkadot/api) then perform needed mapping.
    2.Current-Parachains end-pointThe current parachains end-point is an HTTP GET end-point to provide the current auction information of the running parachains (and parathreads) of the specified chain (e.g. GET /parachains/Kusama). Behind the end-point, the service query the correct node (chain) through an instance of side-car and complement the missing information with a custom Polkadot Websocket (inspired from both Polkaj and @Polkadot/api) then perform needed mapping.
    3.Current-Crowdloan end-pointThe current crowdloan end-point is an HTTP GET end-point to provide the current crowdloan information of the ongoing auction of the specified chain (e.g. GET /crowdloan/Kusama). Behind the end-point, the service query the correct node (chain) through an instance of side-car and complement the missing information with a custom Polkadot Websocket (inspired from both Polkaj and @Polkadot/api) then perform needed mapping.

    Milestone 2 Implementation of UI (Polk-auction-ui)โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationI will provide an API specification of the HTTP end-points. I will also provide a small documentation on how to run the project and how the project structure was done.
    0c.Testing GuideUnit tests (code coverage of 60%) will be done to ensure most important functionalities are working as planned. A guide on how to run the tests will be made.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.Current-Auction pageThe current auction page will display information from the API end-point /auction for the selected chain.
    2.Current-Parachains pageThe parachains page will display information from the API end-point /parachains for the selected chain. The page will looks like a list of the parachain with its specificities in the network.
    3.Current-Crowdloan pageThe current crowdload page will display information from the API end-point /crowdloan for the selected chain.
    4.Others pagesSome other pages will be included such as a FAQ section and an About section (describing the website/project).
    5.HeaderThe header of the website will contain the list of the relay-chains (for now Kusama and Polkadot) and some external links to the github page, the Polkadot website (network), etc.

    Milestone 3 Deployment of the websiteโ€‹

    NumberDeliverableSpecification
    0a.LicenseNA
    0b.DocumentationNA
    0c.Testing GuideNA
    0d.DockerNA
    0e.ArticleA Medium article or a Reddit post will be written to advertise the website and another article/post targeting the developer community will be written to present the project.
    1.Deployment of nodesDeployment on a dedicated VPS of a Kusama running node and a Polkadot running node in respective Docker containers (from parity/polkadot:latest image).
    2.Deployment of sidecar-apiDeployment on the same dedicated VPS of two side-car API in respective Docker containers (each one connected to one running node).
    3.Deployment of polk-auction-coreDeployment on the same dedicated VPS of the polk-auction-core API.
    4.Deployment of polk-auction-uiDeployment on the same dedicated VPS of the polk-auction UI website.

    Future Plansโ€‹

    Futur plans are :

    Additional Information โž•โ€‹

    Why do the FTE and duration do not match ? I have a full-time job as a developer, I'll take some days off for this project, however I won't take 10(+3) weeks of days off for the project, so I won't be able to work as 1FTE/month on this project. I'll work on evening and week-end to meet the milestones and deliveries.

    How did you hear about the Grants Program? Web3 Foundation Website and Reddit (/r/Polkadot, /r/Kusama and /r/dot) mainly.

    Additional information I've started to work in the back-end (polk-auction-core) as well as deployed two running nodes (one on Polkadot, one on Kusama) and their respective side-car API instances. I've applied to no previous grants neither received contribution for this project.

    - + \ No newline at end of file diff --git a/applications/polkadex.html b/applications/polkadex.html index e0fe82c052f..c2b0d9e90dc 100644 --- a/applications/polkadex.html +++ b/applications/polkadex.html @@ -4,7 +4,7 @@ Polkadex: A fully decentralized, peer-peer, cryptocurrency exchange for DeFi ecosystem in Substrate. | Web3 Foundation Grants - + @@ -15,7 +15,7 @@ We also intend to engage community by providing grants in our tokens to add more support and improve our codebase.

    Future Plansโ€‹

    We will be registering an LLC for taking this project ahead. We intend to host a the Web UI provided here. We will also be developing a cloud service to analyse and aggregate the market data to provide a wide range of technical indicators like Bollinger bands, RSI etc. We want to provide traders the maximum possible user experience compared to a centralized exchange.

    - + \ No newline at end of file diff --git a/applications/polkadot-contract-wizard.html b/applications/polkadot-contract-wizard.html index 8f63cbfa8c2..2e877d7a462 100644 --- a/applications/polkadot-contract-wizard.html +++ b/applications/polkadot-contract-wizard.html @@ -4,7 +4,7 @@ Polkadot Contract Wizard | Web3 Foundation Grants - + @@ -16,7 +16,7 @@ Our Developer will be Henry Palacios And the UI/UX expert is Agustin Longoni

    Contactโ€‹

    Team's experienceโ€‹

    Protofire has proven expertise in building decentralized infrastructure, protocols, applications, and developer platforms to accelerate growth of networkโ€™s ecosystems. By delivering hands-on coding and contributions, Protofire specializes in supercharging developer adoption, bootstrapping, and network usage We are not only a dev shop company, but we create long term partnerships with the projects we are part of, building and working as ambassadors for the community. We believe in the projects and also participate by running nodes and taking the validator or staker roles.

    Team Code Reposโ€‹

    GitHub accounts of team members.

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    As explained in step 1 of project details section, our first approach was a contract wizard similar to the one built by OpenZeppelin on Ethereum.

    After that, we realized that if we wanted our tool to be useful for all types of users, we needed to redesign the UX and add further functionalities.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Described in project details.

    Overviewโ€‹

    Milestone 1 โ€” UI and Code Generationโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can generate its own smart contracts.
    0c.Testing and Testing GuideThe code will have unit-test coverage to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a docker container with current milestones deliverables to easily run the application.
    1.Redesign frontend interfaceThe functionality to be implemented corresponds to step 1 of the Project Details section.
    2.Develop the interface based on the previous task resultThe functionality to be implemented corresponds to step 2 of the Project Details section.
    3.Compose the contract based on the selectionThe functionality to be implemented corresponds to step 3 of the Project Details section.
    4.Add syntax highlighting to the displayed smart contract codeThe functionality to be implemented corresponds to step 4 of the Project Details section.

    Milestone 2 โ€” Smart Contracts Deployment and Instantiation functionalityโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can instantiate a smart contract.
    0c.Testing and Testing GuideThe code will have unit-test coverage to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a docker container with current milestones deliverables to easily run the application.
    0e.ArticleWe will publish an article that explains what we have achieved building this project and how this will impact the ecosystem .
    1.Create a service that allows on demand contract compilation and deployment.The functionality to be implemented corresponds to step 5 of the Project Details section.
    2.Develop Instance functionalityThe functionality to be implemented corresponds to step 6 of the Project Details section.

    Future Plansโ€‹

    After the completion of this project, we would love to broaden its scope.

    Multiple Chains

    Custom contracts

    Social Interaction

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/polkadot-desktop-app.html b/applications/polkadot-desktop-app.html index fdb770cbfc6..3bbdb4b699f 100644 --- a/applications/polkadot-desktop-app.html +++ b/applications/polkadot-desktop-app.html @@ -4,7 +4,7 @@ Polkadot.{js} Desktop Application | Web3 Foundation Grants - + @@ -22,7 +22,7 @@ The following two designs are a result of our re-thinking of the user onboarding process. In this milestone we won't be working on the user onboarding yet. However, we might use parts of the following designs in the account creation modals. Preliminary design - First account creation Preliminary design - Adding a new account

    NumberDeliverableSpecification
    1.Accounts designDesign of Accounts application, including sidebar and visual components (in Figma).
    2.Updated UX flow for Account creationImplement redesigned account creation flow. Password validation improvements.
    3.Initial Style GuideDocument containing color palette and UI components for the application.
    4.Implement new styleImplement parts of the new designs, including consistent font usage, new navigation, minor improvements of layout and dark mode.

    Milestone 3โ€‹

    Improve User Experience in Accounts appโ€‹

    In this Milestone we'll tackle usability issues with Accounts.

    Currently, users face following difficulties:

    For sure coming up with an effective design will require some iterating over wireframes/prototypes, and possibly also with implementations.

    Code-wise, we'll remove dependencies on SUI library components where possible. Also, we're going to add more unit and UI automated tests and remove code duplication where possible.

    For a more detailed preliminary backlog, consult this list.

    NumberDeliverableSpecification
    1.Accounts list redesignFigma design that solve all usability issues mentioned above
    2.Accounts list implementationImplementing the designs in Polkadot-JS apps
    3.Accounts sidebar implementationRe-Implementing the sidebar that pops up after clicking on an account
    4.Accounts App modals improvementsImprove usability and consistency in Account modal, eg. Derive, Add Proxy. Remove code duplication between Create and Derive
    5.Documentation updatesWe'll add or update the relevant documentation where needed, including screenshots in polkadot wiki

    Additional Information โž•โ€‹

    Work done so farโ€‹

    Have you applied for other grants so far?โ€‹

    We have successfully applied for a grant on Polkadot.{js} Extension. We are now awaiting acceptance of the last milestone of this grant.

    Similar projectsโ€‹

    We're aware of the SubstrateIDE project, which also uses Electron to package the Polkadot.{js} app. However, in case of this project the focus is on providing a developer environment, of which the Polkadot Apps is just a part. In our grant application we focus more on providing an end-user solution.

    - + \ No newline at end of file diff --git a/applications/polkadot-js-extension-per-account-auth.html b/applications/polkadot-js-extension-per-account-auth.html index c88d4170d2f..86e1de59a2a 100644 --- a/applications/polkadot-js-extension-per-account-auth.html +++ b/applications/polkadot-js-extension-per-account-auth.html @@ -4,7 +4,7 @@ Privacy enhancement for Polkadot-js extension | Web3 Foundation Grants - + @@ -20,7 +20,7 @@ | 1. | new approval screen | Users will be able to see all their accounts, check which one they want to share with the website, and optionnaly select all accounts at once. | | 2. | new approval back-end | The current system of whitelist will be retired and a new system of authorization per website per account will be implemented. Note that the current account visibility feature (with the eye) will be kept untouched. | | 3. | website approval enhancement | The current parameter screen "Manage Website Access" will be enhanced where users can select per website what accounts are shared with each website. The account selection component will be re-used here so as to reduce maintenance hurdle. |

    Future Plansโ€‹

    Please include here

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Github RFP and personal recommendation

    - + \ No newline at end of file diff --git a/applications/polkadot-mempool-explorer-v2.html b/applications/polkadot-mempool-explorer-v2.html index c444513191d..c443982f962 100644 --- a/applications/polkadot-mempool-explorer-v2.html +++ b/applications/polkadot-mempool-explorer-v2.html @@ -4,13 +4,13 @@ polkadot-mempool-explorer-v2 | Web3 Foundation Grants - +
    Skip to main content

    polkadot-mempool-explorer-v2

    • Team Name: NA

    -Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Mempool Explorer enables Polkadot ecosystem members to monitor pending transactions across several parameters and gain meaningful insights.

    Follow-up of Mempool Dashboard - Version 1

    • Link to the phase 1 project: medium

    However the project was created by a different team, Protofire. Currently it's not in working condition, the provided link https://mempool.dot.protofire.io/ doesn't work anymore.

    Overviewโ€‹

    Version 2 of mempool dashboard, is a tool to monitor pending transactions in Polkadot, Kusama, Westend, Rococo and you can add your customized network.

    Current issues with the initial implementation

    version 1 of the mempool dashboard is not in working condition. I took this opportunity to revive the project and create a next version of the original project by fixing the current issues, creating a new UI to enhance user experience and readability and improvements to the API.

    My first task was to understand the codebase, identify the current issue and provide a fix for it. After applying a few patches I was able to restore back to the original state, however still with few issues.

    Noteable issues

    • lack of proper code documentation ( it was difficult for me to understand the codebase initially )

    and set of exhaustive open issues https://github.com/muddlebee/polkadot-mempool-explorer/issues

    track of patches/fixes done till date - https://github.com/muddlebee/polkadot-mempool-explorer/commits/dev

    We have fixed majority of the issues already.

    What's in version 2

    • fix the existing issues
    • enable CI/CD deployment to the hosted servers and fix docker scripts
    • series of tutorials on polkadot-js APIs

    Currently there's a lack of proper tutorials/education materials for anything polkadot-js API related stuff other than the official docs. I would like to create an extensive tutorial on how to consume polkadot-js APIs (more details in Milestone section).

    why create a separate set of tutorials?

    • currently the polkadot JS docs is difficult for beginners with zero or less technical knowledge about the polkadot architecture to understand properly.
    • easy to learn and develop using polkadot JS APIs/SDKs as compared to substrate in Rust

    Project Detailsโ€‹

    Github: https://github.com/muddlebee/polkadot-mempool-explorer

    API : /api folder

    Frontend: /web folder

    API uses nodejs on top of polkadot js API

    Frontend uses React to render the transaction blocks in the UI

    Note We already have done 50% of the proposed work, and its live in the url below

    mempool-ui

    Technology stackโ€‹

    • javascript, nodejs, react
    • polkadot js API
    • docker

    Ecosystem Fitโ€‹

    Solution that would allow members of the Polkadot ecosystem to monitor information related to pending transactions.

    More details has been published in the phase 1 delivery report medium

    Tutorials for polkadot JS APIs will help educate folks who are not expert in Rust/Substrate and want to adopt JS first approach first. We have many examples of live webapps integrating polkadot JS APIs like wallets, tools etc.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Name of team leader:โ€‹

    • Anwesh Nayak (@muddlebee)

    Names of team members:โ€‹

    • Arnav Nayak
    • Dikhyant Krishna

    Contactโ€‹

    • Contact Name: Anwesh Nayak
    • Registered Address: NA
    • Registered Legal Entity: NA

    Team's experienceโ€‹

    I have around 5 years of experience in full stack development. Currently work as a tech lead at B2B fintech firm. Also a polkadot ambassador and the community moderator of the official polkadot/kusama discord. I have been contributing to the ecosystem since last year. Also participated in Thousand Contributors Programme by w3f and have been adding suggestions/improvements across the w3f github projects.

    Arnav, our lead designer has 2 years of experience in product design prior to that used to work as a architect with few years of experience.

    Dikhyant, frontend developer has around 2 years of experience in web development, creating UI out of design specs.

    Team Code Reposโ€‹

    will move to a separate github repo once grant is approved

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 7-8 weeks
    • Full-Time Equivalent (FTE): 3
    • Total Costs: 9000 USD

    Milestone 1โ€‹

    version 2 of mempool dashboard and polkadot js API tutorialsโ€‹

    • Estimated Duration: 7-8 weeks
    • FTE: 3
    • Costs: 9000 USD
    NumberDeliverableSpecification
    0a.LicenseAPACHE 2
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to view pending transactions in dashboard
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.new UI for desktop and mobile view and fix existing issues
    2.enhance the APIs and fix existing issues
    3.enable CI/CDspin up a server instance for hosting the backend and deploying the frontend at github pages
    4apolkadot js API tutorialsWe will provide both inline documentation of the code and a series of tutorial that explains how to run sample examples
    4bGraphics/IllustrationsIllustrations wherever required to explain complex topics
    4cPublish tutorials onlineUse a technical documentation tool to publish the tutorials online

    Sample tutorials

    Chapters overview

    1. Explain the basics of polkadot architecture

    2. Role of polkadot JS API, substrate and how to interact with the live blockchain

    3. How to fetch the metadata, and what are the metadata of the blockchain? https://polkadot.js.org/docs/api/start/basics

    4. What's the purpose of polkadot js console and how to use it? https://polkadot.js.org/apps/#/

    5. Explain transaction lifecycle, and how to perform transactions through the API

    and more .....

    Overall goal it to curate a series of tutorials to build the concepts of polkadot blockchain.

    Cost breakupโ€‹

    Design - 1500 USD

    Frontend - 1500 USD

    API/backend - 2500 USD

    CI/CD setup + server costs/maintenance - 500 USD

    polkadot js API tutorials - 3000 USD

    Future Plansโ€‹

    Version 2 of polkadot JS tutorialsโ€‹

    • Create a extensive and expanded set of tutorials covering most of the polkadot JS APIs
    • Expand the goal of education through quality content
    • Add good explanatory graphics to explain the basic concepts
    - + \ No newline at end of file diff --git a/applications/polkadot_analytics_platform.html b/applications/polkadot_analytics_platform.html index 74b173cf387..d037d07e12b 100644 --- a/applications/polkadot_analytics_platform.html +++ b/applications/polkadot_analytics_platform.html @@ -4,7 +4,7 @@ Polkadot Analytics Platform: Stage 1 | Web3 Foundation Grants - + @@ -68,7 +68,7 @@ [4] Grant Application - A Knowledge-Oriented Approach to Enhance Integration and Communicability in the Polkadot Ecosystem: https://github.com/w3f/Grants-Program/pull/1420 [5] https://github.com/ibm-hyperknowledge [6] https://ibm-hyperknowledge.github.io/possibility-link-demo-iswc2022/

    Previous grants you may have applied for.

    https://github.com/w3f/Grants-Program/pull/1420

    - + \ No newline at end of file diff --git a/applications/polkadot_tests.html b/applications/polkadot_tests.html index 7002fca095c..71cd45023f0 100644 --- a/applications/polkadot_tests.html +++ b/applications/polkadot_tests.html @@ -4,7 +4,7 @@ Polkadot Conformance Tests PoC | Web3 Foundation Grants - + @@ -23,7 +23,7 @@ We have recently completed a grant on the research of an alternative host implementation.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Zondax AG

    Dammstrasse 16

    Zug 6300, Switzerland

    UID CHE-491.796.576

    Team's experienceโ€‹

    Over the last few years, Zondax has been involved in a large number of projects for most of the key players in the blockchain industry. Our team includes experts in most blockchain aspects, from cryptography to data and protocol engineering.

    Team Code Reposโ€‹

    Most of our contributions to the blockchain ecosystem can be found in our GitHub organization zondax

    Development Status ๐Ÿ“–โ€‹

    Not initiated.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Technical Scope:โ€‹

    The scope of our work will consist on:

    Overviewโ€‹

    Milestone 1 - PoC Implementationโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT
    0b.DocumentationWe will provide a inline documentation of the code and inline documentation of the code and a basic tutorial
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article explaining the research, design decisions and proof of concept
    1.PoC codeGeneral structure
    2a.CodePoC Tests: Host API: cryptography primitives
    2b.CodePoC Tests: Trie proof verification
    2c.CodePoC Tests: Scale encoding and decoding

    *Testing in point 2, will not be comprehensive. We will concentrate on different cases to proof that the architecture and design is adequate.

    Future Plansโ€‹

    After we have completed this PoC, we aim to prepare a proposal for a long term test suite.

    Additional Information โž•โ€‹

    Zondax has been contributing to the Polkadot ecosystem for several years, and has succesfully completed several grants. We have recently completed a grant on the research of an alternative host implementation. https://github.com/w3f/Grants-Program/pull/1324

    - + \ No newline at end of file diff --git a/applications/polkadotjs-ecdsa.html b/applications/polkadotjs-ecdsa.html index f381cfa6229..b1f9b22c002 100644 --- a/applications/polkadotjs-ecdsa.html +++ b/applications/polkadotjs-ecdsa.html @@ -4,13 +4,13 @@ ECDSA for Polkadot JS | Web3 Foundation Grants - +
    Skip to main content

    ECDSA for Polkadot JS

    • Proposer: @akru
    • Payment Address: bc1qccvrcny62epea360w0dvy2ynv90vz5luansmg9

    Project Description ๐Ÿ“„โ€‹

    Currently Polkadot/Substrate support three kinds of cryptographic primitives as MultiSignature data type:

    • Ed25519
    • Sr25519
    • ECDSA

    Unfortunately, right now Polkadot JS support first two only (enhancement issue: https://github.com/polkadot-js/common/issues/506). It's limiting using ECDSA keys for subkey CLI utility only, which makes user experience pipeline a bit difficult.

    Main aim of this project is providing comfortable environment for ECDSA key owners (Ethereum/Bitcoin holders) as same as for Sr/Ed25519 keys.

    Supporting wide range of cryptographic primitives is powerful side of substrate/polkadot ecosystem. This projects makes this side user-friendly introducing cryptographic primitives support on UI side.

    This project planned to be directly integrated into Polkadot JS which is part of Polkadot ecosystem.

    Plasm Network(https://plasmnet.io) is a scaling Dapps platform on Substrate. Plasm Network is planned to be a parachain in Polkadot ecosystem. Plasm token distribution model involves the use of a lockdrop approach in Ethereum and Bitcoin networks where Secp256k1 cryptography is a de facto standard. Plasm team is highly interested in making lockdrop participation process smoothly as much as it possible. ECDSA integration into Polkadot ecosystem is one of steps to makes it real.

    Team ๐Ÿ‘ฅโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 2 weeks
    • Total Costs: 0.6 BTC

    Milestone 1โ€‹

    • Estimated Duration: 2 weeks
    • Costs: 0.6 BTC

    Main aim of this is providing compatability layer for secp256k1 keypair into Polkadot JS key management system.

    NumberDeliverableSpecification
    1.Polkadot JS ECDSA sign/verify supportIntroducing secp256k1 keypair into Polkadot-js/common repository as same as sr25519 type: https://github.com/polkadot-js/common/blob/master/packages/util-crypto/src/types.ts, implementing Sing/Verify interfaces.
    2.Polkadot JS sign/verify testsIntegration tests for secp256k1 keypair.
    3.Polkadot JS Apps ECDSA supportIntroducing secp256k1 key types for Apps account management widget. ECDSA account should be possible to send extrinsics as same as Sr25519 or Ed25519 account.
    4.Improve documentationAdd ECDSA description paragraph into Polkadot-js documentation.
    5.Polkadot JS Apps demo videoProvide demonstration how Polkadot Apps works with Ethereum (secp256k1) private keys.
    - + \ No newline at end of file diff --git a/applications/polkadotjs-hardware.html b/applications/polkadotjs-hardware.html index 9cdb3f3dc1c..677ce32f937 100644 --- a/applications/polkadotjs-hardware.html +++ b/applications/polkadotjs-hardware.html @@ -4,13 +4,13 @@ Hardware ECDSA for Polkadot JS | Web3 Foundation Grants - +
    Skip to main content

    Hardware ECDSA for Polkadot JS

    • Proposer: @akru
    • Payment Address: Ekf4HssuTpYjmUEvzy9AAFuqpUcNm9AAkrMF1stTU6Mo1hR (Kusama)

    Project Description ๐Ÿ“„โ€‹

    Hardware wallets provide for end-user much more hight grade of security than traditional software wallets because of moving the private key out of general using PC. The most popular, Trezor (https://trezor.io/) and Ledger (https://www.ledger.com/), supports Ethereum / Bitcoin cryptography (ECDSA) by default. But ECDSA crypto is native for the Polkadot ecosystem too that makes hardware wallets fully compatible with Polkadot applications without any changes in hardware wallet firmware.

    This proposal improves already implemented software ECDSA keyring in PolkadotJS (https://github.com/w3f/Open-Grants-Program/pull/6) and planned to be directly integrated into Polkadot JS which is part of the Polkadot ecosystem.

    Plasm Network(https://plasmnet.io) is a scaling Dapps platform on Substrate. Plasm Network is planned to be a parachain in the Polkadot ecosystem. The Plasm token distribution model involves the use of a lockdrop approach in Ethereum and Bitcoin networks where Secp256k1 cryptography is a de facto standard. Plasm team is highly interested in making lockdrop participation process smoothly as much as possible. ECDSA integration into the Polkadot ecosystem is one of the steps to makes it real.

    Team ๐Ÿ‘ฅโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 10 weeks
    • Full-time equivalent (FTE): 0.6
    • Total Costs: 10,000 USDT

    Milestone 1โ€‹

    • Estimated Duration: 10 weeks
    • Full-time equivalent (FTE): 0.6
    • Costs: 10,000 USDT

    Ledger API support for Polkadot JS Apps.

    NumberDeliverableSpecification
    1.Ledger API ECDSA signerIntroducing Ledger API based signed for Polkadot JS. Required API methods already exposed by standard Ledger API: getPublicKey, signMessage.
    2.Improve documentationAdd Ledger hardware wallet paragraph into Polkadot-js documentation.
    3.Demo videoProvide demo video of Polkadot Apps sign transaction with Trezor wallet.
    - + \ No newline at end of file diff --git a/applications/polkadotjs_no_code.html b/applications/polkadotjs_no_code.html index 8161bb779fb..542c76e8a50 100644 --- a/applications/polkadotjs_no_code.html +++ b/applications/polkadotjs_no_code.html @@ -4,7 +4,7 @@ Polkadot.js NoCode Plugin | Web3 Foundation Grants - + @@ -35,7 +35,7 @@ Our team works only with Bubble for 3 years now, building templates, plugins, and apps for clients, we certainly can say that it is worth it.

    Here are a few numbers about Bubble:

    All our crypto-related plugins

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/polkaflow.html b/applications/polkaflow.html index ecdf985ce99..2386deea5f1 100644 --- a/applications/polkaflow.html +++ b/applications/polkaflow.html @@ -4,13 +4,13 @@ PolkaFlow | Web3 Foundation Grants - +
    Skip to main content

    PolkaFlow

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    The DOT open source developer community is expanding rapidly, yet there is currently no way to easily monitor development progress across various projects that integrates with the DOT ecosystem. Keeping track of development progress across various projects and monitoring developer contributions can provide valuable insights into the evolution of DOT ecosystem. With data dispersed throughout Github, including contributors, commits, issues, repositories, and PRs, it can be challenging to grasp the overall progress of the DOT ecosystem.

    I am presenting PolkaFlow to the DOT community as the ultimate solution for visualizing and analyzing open source projects within the ecosystem. It offers a comprehensive view of activities of projects and insights into the ecosystem's trends. The project will allow users to gain insights into the development activity, code contributions, issue resolution, and community engagement of the DOT ecosystem through open source projects. This information will be displayed through various visualizations and charts, which will be accessible through a web-based application named PolkaFlow.

    Project Detailsโ€‹

    PolkaFlow Website: https://polkaflow.vercel.app/

    Mockups

    Dashboard PageProject List PageProject Detail Page
    Screenshot 2023-03-06 at 01-03-22 PolkaPulseScreenshot 2023-03-06 at 01-29-06 ProjectsScreenshot 2023-03-06 at 01-03-48 Project Page

    Technical Scheme

    Scheme
    polkaflow-technical-scheme

    Technical Stack

    • Frontend: ReactJS, Tailwind CSS, Apache ECharts
    • Backend: Python
    • Database: Firebase Firestore
    • Additional Integrations: Typeform (for submitting project), Algolia (for search functionality)

    Ecosystem Fitโ€‹

    Target audience

    The target audience for PolkaFlow can include developers, researchers, and enthusiasts who are interested in monitoring the development and activity of open-source projects on the DOT ecosystem. The platform's analytical tools and visualizations can provide valuable insights into the performance of various projects, making it useful for those who want to gain a better understanding of the ecosystem's progress and the direction it's headed in.

    Besides, by tracking the activity of commits history, and issue resolution PolkaFlow can help developers identify areas where they can improve and streamline their own development processes. By offering detailed analytics, PolkaFlow can become an essential tool for anyone who is interested in the development and progress of the DOT ecosystem.

    Evidence for the need

    • Increased Interest in DOT Ecosystem: The growth of the DOT ecosystem and the increasing number of open-source projects being developed on the protocol highlight the need for a tool that can monitor and analyze the performance of these open-source projects. PolkaFlow can provide valuable insights for the projects within the ecosystem.

    • Lack of Comprehensive Analytics: There is a lack of reliable and user-friendly tools that can provide detailed analytics and visualizations for open-source projects on DOT ecosystem. Besides, the demand for better analytical tools in the blockchain space is increasing, and developers and stakeholders are seeking tools that can help them monitor and analyze the performance of the projects. PolkaFlow fills this gap for the DOT ecosystem.

    • Historical and Trend Data:: PolkaFlow can provide a historical and trend data of the Github activity in the DOT ecosystem, allowing developers and project managers to see first hand how the ecosystem is growing, evolving, and changing over time. This data can be used to identify patterns, trends, and areas of improvement, leading to more informed decision making and better outcomes for the projects within the ecosystem.

    Impact

    • Improve Project Visibility: By providing detailed analytics and visualizations for DOT projects, PolkaFlow can help increase the visibility of these projects, making it easier for developers and users to find and contribute to them.

    • Enhance Developer Productivity: With the ability to quickly access important data and metrics, developers can more easily identify areas of the project that need attention. This can lead to faster issue resolution and more efficient development cycles.

    • Encourage Community Engagement: By providing a centralized location for viewing project activity and contributions, PolkaFlow can encourage community engagement and collaboration. Users can easily identify areas where they can contribute to the project and engage with other developers and users.

    • See Ecosystem Evolution: PolkaFlow can help show the evolution of DOT projects over time by providing historical data and visualizations of key metrics, enabling developers to better understand the project's development trajectory and identify areas where protocol gains trends.

    • Stands Out: Currently, there is no project that provides a comprehensive analytics dashboard for open-source projects in the DOT ecosystem. PolkaFlow fills this gap and provides value by enabling developers and stakeholders to easily gain insights into the activity and performance of DOT projects.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Mert Kรถklรผ - Project Owner

    Contactโ€‹

    • Registered Address: N/A
    • Registered Legal Entity: Individual

    Team's experienceโ€‹

    Mert Kรถklรผ

    Served as the founding vice-chair of ACM Student Chapter and acted as an ambassador of many organizations including Microsoft and NVIDIA as Certified Instructor. In the Web3 space, he co-manage the AAVE Turkey Community and advocate for The Graph. Was working with AI video pipelines at an NVIDIA distributor company in Turkey before getting involved with blockchain.

    Develops ecosystem tools and applications with various tech stacks. AAVE and Filecoin grantee with an already accepted 3 projects and now developing open-source, user-friendly applications that add value to the DOT ecosystem.

    Team Code Reposโ€‹

    Github Account

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    PolkaFlow is already deployed on Vercel and can be accessed via polkaflow.vercel.app. The project is currently in the MVP stage with Milestone 1 completed. Initially 17 repositories are added to the platform because of the demo purposes. After the approve, the project will have more repositories curated by me (or requests from the DOT Team) and the more can be added by the DOT community via Submit button in the app.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-Time Equivalent (FTE): 1 FTE
    • Total Costs: 10,000 USD

    Milestone 1 - MVPโ€‹

    • Estimated duration: 2 month
    • FTE: 1 FTE
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationI will provide both inline documentation of the code and a basic how-to page that explains how the user can interact with the platform.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerNot applicable.
    1.DatabaseSet up a Firebase project and Firestore database for storing chart data and project metadata
    2.Python BackendImplement functionality that can fetch data from Github Rest and GraphQL APIs for all DOT projects.
    3.Frontend: Dashboard Page
    Backend: Data Process    		Implement Star Count for displaying the number of stars for DOT projects.
    4.Frontend: Dashboard/Project Pages
    Backend: Data Process    		Implement Commit History By Weeks (Line Chart) for visualizing commit activity over time.
    5.Frontend: Dashboard/Project Pages
    Backend: Data Process    		Implement Code Frequency (Stack Line Chart) for visualizing code changes over time.
    6.Frontend: Dashboard/Project Pages
    Backend: Data Process    		Implement Top Contributors (List) for displaying top contributors to the project.
    7.Frontend: Dashboard/Project Pages
    Backend: Data Process    		Implement Issue Activity (Line Chart) for visualizing issue activity over time.
    8.Frontend: Dashboard/Project Pages
    Backend: Data Process    		Implement Issue Count (Pie Chart) for displaying the distribution of issue types.
    9.Frontend: Dashboard/Project Pages
    Backend: Data Process    		Implement Recent Issues (List) for displaying the most recent issues.
    10.Frontend: Dashboard/Project Pages
    Backend: Data Process    		Implement Recent Commits (List) for displaying the most recent commits.
    11.Frontend: Dashboard/Project Pages
    Backend: Data Process    		Implement Pull Request Count (Pie Chart) for displaying the distribution of pull request types.
    12.Frontend: Project Page
    Backend: Data Process    		Implement Pull Request Activity (Bar Chart) for visualizing pull request activity over time.
    13.Frontend: Project Page
    Backend: Data Process    		Implement Project Info Card for displaying project information.
    14.Frontend: Project Page
    Backend: Data Process    		Implement Recent Stargazing Activity (Line Chart) for visualizing recent stargazing activity over time.
    15.Frontend: Project List PageCreate the Project List page that lists the DOT ecosystem projects in order of their respective stargazing counts.
    16.Integrate: AlgoliaEnhance the search functionality of the platform.
    17.Frontend: CategorizationThe projects will be categorized on their underlying protocol, such as Polkadot, Substrate, Kusama, etc., as well as further categories like DeFi, DEX, and others.
    18.Integrate: TypeformAllow ecosystem users to suggest new projects for PolkaFLow
    19.Integrate: Google AnalyticsTrack user engagement and adapt and improve the platform accordingly.
    20.Backend: ScheduleImplement scheduling mechanism to fetch and update every project data from the Github APIs on a regular basis (e.g. every 30 minutes).
    21.Frontend: UX & UIImprove the UX and UI of the platform. Increase responsiveness, add animations, enhance user interaction, etc.

    Future Plansโ€‹

    In the short term, we intend to use PolkaFlow to provide a comprehensive and user-friendly platform for developers and ecosystem users to track and analyze projects in the DOT ecosystem. We will continuously enhance and update the platform to ensure that it is the go-to resource for up-to-date information on DOT projects.

    In the long term, our team's plan is to continue supporting and improving PolkaFlow to meet the evolving needs of the DOT community. This includes incorporating additional metrics and data sources to provide more detailed insights into projects. Besides, if the platform is well-received by the community, and gains traction, we are going to open a Twitter account for PolkaFlow to engage with the community and promote top open-source projects on the DOT ecosystem.

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    • Referrer: -
    • Payment Address: -

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/polkaj_android_support.html b/applications/polkaj_android_support.html index 239d3094d69..ef190e0c5db 100644 --- a/applications/polkaj_android_support.html +++ b/applications/polkaj_android_support.html @@ -4,7 +4,7 @@ PolkaJ Android Support | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    PolkaJ Android Support

    • Team Name: Nathan Schwermann
    • Payment Address: 0x454cfAa623A629CC0b4017aEb85d54C42e91479d
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    This proposal is a follow-up to the PolkaJ grant https://github.com/w3f/Open-Grants-Program/pull/12 I am not affiliated with the original team, but I have spoken with them about this propoal and they have encouraged me to submit it.

    Overviewโ€‹

    The PolkaJ java client is built using Java 11 APIs and native x86 code which can not run on Android. This project proposal will make the necessary changes to support the Android platform as well as provide examples.

    Project Detailsโ€‹

    We will make the following changes and additions to the PolkaJ project in order to support Android versions 7 and up.

    • Build script changes to also compile the rust code to ARM in addition to x86 based on the target
    • Make necessary changes to JNI code to support ARM when needed and remove Java 9 dependency
    • Add RpcCallAdapter and SubscriptionCallAdapter to client Builder interface
    • Refactor polkaj-api-http and polkaj-api-ws which both use Java 11 and can not be used on Android to implement the new Call and Subscription Factory apis
    • Extract and refactor tests from polkaj-api-http and polkaj-api-ws to be reusable for any implementations of the factory as well as additional coverage for Builder changes to support factories
    • Add new module polkaj-okhttp which will implement RpcCallAdapter and SubscriptionCallAdapter using okhttp, the most widely adopted http client used in the Android development community.
    • Unit test against shared tests for java.net versions of factories, with the same or higher code coverage.
    • polkaj-ktx modules adding support kotlin extensions and coroutine support
    • Example Android app, uses existing command line examples in Android GUI
    • Update documentation for build script changes and for examples on each platform
    • Fix broken balance example on OSX
    • Add new artifacts polkaj-schnorrkel_android.jar, polkaj-okhttp.jar

    Ecosystem Fitโ€‹

    This is an improvement and addition to an existing project.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Nathan Schwermann

    Contactโ€‹

    Individual / Sole Proprietor

    Team's experienceโ€‹

    I have ten years of experience in Android client development in the telecom and payment industries. I have led and maintained development on applications with millions of monthly active users.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    • I have completed parts 1, 1b, 2a, 5, 90% complete 3a and 50% 4a from milestone 1.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 Months
    • Full-time equivalent (FTE): 1
    • Total Costs: 21,000 DAI

    Milestone 1 Client refactoringโ€‹

    • Estimated Duration: 1 month (2 weeks left after re-approval of milestone delivery)
    • FTE: 1
    • Costs: 7,000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and update the existing examples documentation with api changes
    0c.Testing GuideWe will maintain or improve current code coverage.
    1.schnorrkel module remove Java 9 dependency
    1b.schnorrkel module Mac OS CompatibilityFix native library loading on mac
    2a.api-base: FactoriesWe will add common Builder interface with added components for RpcCallFactory and SubscriptionFactory
    2b.api-base: Factory TestsWe will extract existing http/ws tests to new common factory tests suite
    3a.api-http: FactoryRefactor to implement RpcCallFactory
    3b.api-http: TestsUnit tests 90% coverage Integration tests with api base previously extracted from this module
    4a.api-ws: FactoryRefactor to implement SubscriptionCallAdapter
    4b.api-ws: TestsUnit tests 90% coverage Integration tests with api base previously extracted from this module
    5examplesFix Balance example not working on OSX

    Milestone 2 OkHttp / Java 8 Compatibleโ€‹

    • Estimated Duration: 1 month
    • FTE: 1
    • Costs: 7,000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and documentation for using okhttp module.
    0c.Testing GuideWill have 90% code coverage Unit tests and Integration test with api base
    1.polkaj-api-okhttp moduleWill add new module with RpcCallFactory and SubscriptionFactory implementations. Adds new artifact polkaj-okhttp.jar
    2.ExampleWill update examples and example documentation to allow switching between okhttp and http/ws socket implementations
    3.schnorrkel module Android CompatibilityWill build RUST code for ARM adds new artifact polkaj-schnorrkel_android.jar

    Milestone 3 Android and Kotlinโ€‹

    • Estimated Duration: 1 month
    • FTE: 1
    • Costs: 7,000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and documentation for using kotlin module and including polkaj inside an Android project.
    0c.Testing GuideWill have 90% code coverage Unit tests and Integration test with api base
    1.polkaj-ktx moduleWill include support for Kotlin coroutines and additional kotlin convenience methods
    2a.ExampleWill port desktop examples into an Android app with a simple GUI to select each example and allow user input where possible
    2b.Example blogWill write blog post and submit to medium explaining new changes to PolkaJ made to support Android and a walk through guide how to integrate PolkaJ into your Android project.

    Future Plansโ€‹

    I will continue to look for use cases where Android can be used in the polka dot network. I am excited to see the future and hope to remain involved.

    - + \ No newline at end of file diff --git a/applications/polkakeeper.html b/applications/polkakeeper.html index fea7c405653..5b7ffd1dde0 100644 --- a/applications/polkakeeper.html +++ b/applications/polkakeeper.html @@ -4,7 +4,7 @@ Polkakeeper Grant Proposal | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ Our R&D expenses have been covered thus far via RAMP DEFI with world class investors who took part in RAMP DEFIโ€™s private sale round such as Alameda Research, Mechanism Capital, Arrington XRP, Parafi Capital, among others.

    We have further investment interest for follow-on investment should the need arise between the use of this grant and our next source of funding, whether that be the General Grants program or another VC-led investment.

    Have you applied for other grants so far? No.

    How can I get involved? Anyone looking to get involved with RAMP DEFI is welcomed to reach out to us at: team@polkakeeper.com

    - + \ No newline at end of file diff --git a/applications/polkamusic.html b/applications/polkamusic.html index d2f634a09be..9d30f3d4e58 100644 --- a/applications/polkamusic.html +++ b/applications/polkamusic.html @@ -4,7 +4,7 @@ PolkaMusic | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ 2) Smart Streaming Platform contract using which anybody will be able to issue a coin with its own inflationary properties, and payout artists accurately using that. 3) Permissioned File Storage (using NFTs for granting permission) to distribute content to various SSPs.

    We plan to make PolkaMusic the go-to protocol for music businesses wanting to adopt blockchain technology, or existing music blockchains to connect with Polkadot ecosystem and leverage the interoperability of music economies.

    In the immediate short term, we have the following 3rd party SSPs/blockchains integrating into PolkaMusic once we are live:

    The long term features would include:

    Additional Information โž•โ€‹

    Storage: When a user creates a Smart Record Contract, she will be asked for the music file as well as the album cover. These files are saved on a centralized storage at the moment as anybody can download the files from ipfs with no benefit to the artist. Artist can individually choose the SSPs she would like to distribute the songs to, or can upload with them directly, and refer to the SRC Address for royalty payment purposes. In the future, we will implement decentralized file storage through IPFS with Access Control List, a permissioned version of IPFS where access is controlled by programmable smart contracts that contain an Access Control List (ACL). The modified ipfs client will serve files to the requestor only if the permission is approved in the ACL. This offers transparent, public and verifiable access without a central controller. Control is always in the hands of the data owner, the smart contract author. Every SSP will be required to run a ACL-IPFS node of their own.

    It must be noted that the above mentioned file storage mechanisms are based on high latency storage solutions and is for data transfer between the artist and the SSPs. The SSPs will have to maintain a local cache in order to serve files to the end user.

    Traditional Performing Rights Organizations: Every country has multiple local performing rights organizations who are running inefficient softwares with very high licensing costs. Such PROs can use a SSP Smart Contract instance to calculate royalties and send payments on the blockchain using currency of their choice.

    No. This is currently a self-funded project.

    We have attracted 3 open-source developers. Apart from this, we are well connected in the music industry and we have 100+ artists willing to upload their songs.

    - + \ No newline at end of file diff --git a/applications/polkasearch.html b/applications/polkasearch.html index 544cf6f3954..d514852c347 100644 --- a/applications/polkasearch.html +++ b/applications/polkasearch.html @@ -4,7 +4,7 @@ polkasearch.xyz | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ I have completed ink-boxes and ink-wizard grant in the past. They are into active development.
  • If there are any other teams who have already contributed (financially) to the project. No
  • Previous grants you may have applied for. Ink Boxes and Ink Wizard, both are accepted and completed.
    • - + \ No newline at end of file diff --git a/applications/polkashots.html b/applications/polkashots.html index 663215181b4..812aa4d7d8d 100644 --- a/applications/polkashots.html +++ b/applications/polkashots.html @@ -4,13 +4,13 @@ polkashots.io | Web3 Foundation Grants - +
    Skip to main content

    polkashots.io

    • Proposer: Nicolas Ochem
    • Payment Address: bc1qu45ws52gkjgmwgu8gmqh2ejkcf4clt93jnnvsm

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Implement, release and maintain a snapshot website for Polkadot and Kusama.

    Project Detailsโ€‹

    Substrate has an --export-chain and --import-chain feature to allow node operators to sync faster.

    This is a key feature to be able to recover quickly in case of node failure. This results in decreased downtime, which is beneficial for the ecosystem.

    This work will consist of an open source project, and a production website.

    polkadot-snapshot-generatorโ€‹

    The open-source project, polkadot-snapshot-generator, will consist of:

    • infrastructure code for running a Polkadot node (or Kusama, or any substrate node) on Kubernetes on a cloud platform, deployed with Terraform
    • code to take filesystem-level snapshot of a live chain, then run export-chain command
    • mechanism to upload the snapshot to a storage bucket and publish a website with the most recent snapshot
    • a master cronjob, the snapshot engine, that triggers snapshot creation on a schedule

    There will be 2 kind of generated snapshots: RocksDB and Parity DB, until RocksDB becomes deprecated.

    polkashots.ioโ€‹

    We will also deploy and maintain https://polkashots.io, a website hosted on Cloud Infrastructure which will make snapshots available for free for community members.

    The snapshot generation frequency will be configurable. 24 hours frequency seems reasonable. Nodes typically sync very fast from a 24 hour lag.

    Snapshots will be stored on a public Google cloud storage bucket. We will be providing Polkadot and Kusama snapshots.

    The snapshots will be clearly identified by block height and block hash. Hyperlinks will be provided to the main indexing websites (Polkascan, Polkastats) so the user can verify that the snapshot they are downloading is indeed the legitimate Polkadot chain.

    Additionally, the snapshots will be hashed and a signature will be published on the polkashots.io website.

    There will be static links (such as https://polkashots.io/dot/rocksdb) that always point to a recent snapshot, which should simplify setup of an automated recovery mechanism.

    We will modify our own existing projects, polkadot-k8s and polkadot-k8s-aux. We will configure the default behaviour when spinning up a new chain to download snapshots automatically from the polkashots website.

    Ecosystem Fitโ€‹

    To my knowledge, there is no other active snapshot website for Polkadot/Kusama.

    This page appears to be no longer updated.

    People on Riot Validator Lounges regularly ask for fresh snapshots.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Nicolas Ochem

    Team Websiteโ€‹

    MIDLDEV OU (incorporated in Estonia).

    Team's experienceโ€‹

    We are a blockchain SaaS infrastructure company and this project is in line with the range of services that we offer. We can deliver a solid codebase and a website that will be dependable, fast and relevant.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: One month
    • Full-time equivalent (FTE): 0.5
    • Total Costs: 1 BTC

    Note: the cost will cover the initial development as well as the costs related to hosting the website and snapshots for some time.

    Milestone 1โ€‹

    • Estimated Duration: 1 month
    • FTE: 0.5
    • Costs: 1 BTC
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationThe code will be easy to deploy, taking only a few utilities and one single command. The entire cycle - from spinup to teardown - will be clearly explained in the README
    0c.TutorialWe will be posting a follow-up on our post about deploying a Polkadot validator on Kubernetes to explain how to use snapshots to deploy a validator.
    1.TerraformA Terraform manifest to deploy all cloud resources in a simple way.
    2.DockerA set of Docker container descriptions (Dockerfiles and scripts) that are used to manage the snapshot website
    3.KubernetesA Kubernetes manifest, built with Kustomize, to deploy the containers and cronjobs for snapshot creation
    4.TestingWhile infrastructure code is not a natural candidate for testing due to its heavy reliance on external components, we will be providing a script to parse terraform, dockerfile and kubernetes codebase and check for consistency
    5.Live websiteDeploy polkashots.io with recently updated snapshots

    The open-source project will have three directories, terraform, k8s and docker. Their contents are described below.

    Terraformโ€‹

    The terraform module takes parameters such as chain_name, billing_account... as input, and uses the Terraform GCP provider. It creates a Google Cloud Project and a Kubernetes cluster.

    Inside the cluster, it deploys a configurable number of Kubernetes namespaces as described below.

    It also configures Google Cloud Build to automatically build the containers needed to run the snapshotting jobs, and push them to the cluster.

    The entire setup can be destroyed with terraform destroy.

    Kubernetesโ€‹

    A Kubernetes Deployment runs a Polkadot or Kusama node in a Pod with a Persistent Volume for storage.

    This node can optionally be brought up from a snapshot itself (in case the snapshot engine itself needs to be recreated).

    It is not possible to do export-chain on a running node, therefore it is necessary to leverage some cloud filesystem snapshotting capabilities.

    A Kubernetes Cron Job triggers a pod with special privileges that in turns triggers the following Kubernetes actions:

    • take a Persistent Volume Snapshot of the Polkadot node storage
    • create a persistent volume from the snapshot
    • triggers a Kubernetes job called "snapshotter" which:
      • mounts the persistent volume created from snapshot
      • runs the export-chain command against it
      • compresses, hashes the snapshot, then uploads it to a bucket
      • builds a Jekyll static website from source and pushes it to Firebase, with relevant metadata of the generated snapshot
    • tears down all objects created above

    Dockerโ€‹

    A series of custom-build containers built for performing the actions described in the previous section, namely:

    • snapshot-importer: imports a snapshot when initially kicking off the setup
    • snapshot-engine: the job that sends kubernetes control plane commands to generate a filesystem-level snapshot
    • snapshotter: the job that performs export-chain and pushes it to a bucket
    • website-builder: the job that builds the Jekyll static site

    The Dockerfiles and associated scripts to build the containers listed above will be shipped as part of the project.

    Community engagementโ€‹

    We will be announcing the website and the project on Medium.

    Future Plansโ€‹

    We may be extending offers to various Substrate chains to have their snapshots hosted on our platform.

    Additional Information โž•โ€‹

    Earlier we received a grant from the Tezos foundation, part of the purpose was to develop a similar snapshotting project for the Tezos blockchain.

    - + \ No newline at end of file diff --git a/applications/polkastarter.html b/applications/polkastarter.html index de7a4372586..6a975a1e9ef 100644 --- a/applications/polkastarter.html +++ b/applications/polkastarter.html @@ -4,7 +4,7 @@ Polkastarter | Web3 Foundation Grants - + @@ -49,7 +49,7 @@ functionality so that users can connect other wallets, like Parity Signer and Ledger to the interface.

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/polkastats.html b/applications/polkastats.html index 780738858f0..daf0c6b76fd 100644 --- a/applications/polkastats.html +++ b/applications/polkastats.html @@ -4,7 +4,7 @@ Polkastats | Web3 Foundation Grants - + @@ -19,7 +19,7 @@ That being said, we consider that polkastats has its own public and space in Polkadot ecosystem.

    Remarkably, the other (and earlier only) Polkadot block explorer out there is Polkascan, by which Polkastats has been undoubtedly heavily inspired. Still, Polkastats brings in some nice specs that make it unique and, we also believe, better for certain kinds of use. First of all, we find the interface to be much more user friendly.

    - + \ No newline at end of file diff --git a/applications/polket_toearnfun.html b/applications/polket_toearnfun.html index ed38c376f3f..9b1e9928b22 100644 --- a/applications/polket_toearnfun.html +++ b/applications/polket_toearnfun.html @@ -4,7 +4,7 @@ ToEarnFun | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    ToEarnFun

    • Team Name: Polket
    • Payment Address: 0xd35f9Ea14D063af9B3567064FAB567275b09f03D(ETH-USDT)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Where did the idea come from?โ€‹

    Inspired by the success of STEPN, we have great confidence in Web3 applications combined with life scenarios. Because to let the majority of users enter the Web3 world, the interactive way of life scenes is the easiest entry. So we started from the fitness field and developed a Web3 smart fitness application, allowing ordinary users to pick up fitness equipment, training daily + GameFi, and gradually understand how the Web3 world can bring them more value and fun.

    Although STEPN achieved great success and dazzling attention as soon as it was launched, it also exposed the following problems:

    1. Getting started is difficult and high risk. Beginners first need cryptocurrency and buy at least one virtual sneaker before they can start running. Due to the long-term price instability of cryptocurrencies, users cannot grasp the timing of buying cryptocurrencies, which can lead to serious losses.
    2. Insufficient decentralization. STEPN, like most GameFi, adopts the solution of decentralization of asset transactions and centralized gameplay. This is because due to the bottleneck of the current smart contract technology, it is impossible to achieve complete decentralization, so the game system has the risk of self-theft, such as inflated rewards, malicious bans, and service suspension.
    3. Incentives are not sustainable. The incentive tokens generated by STEPN running are freely circulated without restrictions, and the business model is unsustainable, and will eventually enter a death spiral.
    4. Is really cross-chain?. Although STEPN publishes the same kind of assets on both public chains, the asset values are different, and it is not a cross-chain in the true sense.

    After noticing the above problems, we finally adopted Substrate as the underlying technology in technology selection, and developed a blockchain named Polket. The goal of Polket is to create more commercial application scenarios for NFTs and connect to the Polkadot/Kusama network in a parachain manner. Based on the Polket chain, we will develop a smart fitness-type Web3 application to achieve capabilities that STEPN cannot achieve. We will name it ToEarnFun.

    Overviewโ€‹

    logo

    ToEarnFun is a fit to earn Web3 smart fitness application. Compared with other x-to-earn applications that only have SocialFi and GameFi elements, it can be connected with real smart fitness equipment. It relies on the encryption technology of the hardware chip to ensure that the sweat is paid fairly. The entry-level users of ToEarnFun do not need to purchase cryptocurrencies, but only need to purchase smart fitness equipment adapted to the application, and they can fit to earn immediately, greatly reducing the difficulty for ordinary users to enter the web3 world.

    Project Featuresโ€‹

    Easy To Useโ€‹

    After the fitness equipment producer has passed the official qualification certification of ToEarnFun, the producer will register the chip public-key on the blockchain for each piece of fitness equipment produced. The user purchases ToEarnFun fitness equipment in the store, and completes the activation in the App, then can get a VFE (Virtual Fitness Equipment, it can be understood as a type of NFT). Users train through fitness equipment every day, and the system calculates the corresponding rewards based on the VFE attribute value on the chain.

    Compared with STEPN, which requires users to use cryptocurrencies to purchase Sneaker, ToEarnFun does not require users to own cryptocurrencies, and it is easier to meet regional compliance requirements in terms of sales methods. The ToEarnFun community is formed by a group of users with real fitness needs, and is also a group that is optimistic about the future of Web3. Opens a door for Web2 users to enter the Polkadot ecosystem.

    Equipment Chip Embedding Proof Of Trainingโ€‹

    How to prove that the player has completed the training?

    In order to realize the Proof Of Training algorithm, we need to embed a crypto algorithm in the chip of the smart fitness equipment. The equipment needs to generate a key pair and register the public key on the blockchain before leaving the factory. After the user activates the equipment, each time he completes the training, the equipment will sign the training data and submit it to the blockchain to complete the proof, and finally the user will receive a fair reward.

    Since the private key of the equipment is generated by the chip before leaving the factory, the player cannot obtain it and cannot tamper with it, which prevents the player from modifying the training data through software, but the player can still cheat through physical plug-ins. However, with the development of technology, we will add motion sensors and biological inspection technology to the equipment to record more valuable data for player training and to prevent cheating by physical plug-ins.

    Fitness + GameFiโ€‹

    ToEarnFun not only has the advantages of smart fitness applications, but also realizes the gameplay of GameFi. The core of the game is VFE(Virtual Fitness Equipment) as the gameplay, VFE has a level system, with four basic attributes (efficiency, skill, luck, durability), four rarities (common, elite, rare, epic), and available power. When the user activates the equipment, they will get a VFE of common rarity and level 0 for free. Users can earn FUN by consuming energy through daily train, FUN is a consumable in VFE gameplay, used to: upgrade VFE level, VFE charging, Synthesize VFE, transaction fees, challenge events and more. VFE Get attribute points for each level up, and users can configure attributes independently. At present, the equipment we are implementing to interact with VFE is smart jump rope.

    VFE is shorthand for Virtual Fitness Equipment. It can be understood as a subclass of NFT (non-fungible token). We will create VFE such as Smart Jump Rope, Smart Hula Hoop, Smart Boxing, Spinning Bike on the chain. What the user gets is a unique VFE instance minted by VFE.

    Basic attribute description:

    • Efficiency: It affects the amount of FUN income. The higher the efficiency, the more stable the income growth. It is recommended for entry-level users to configure.
    • Skill: Affects the training score factor. The higher the skill, the higher the FUN income from training score conversion. Training score can dramatically increase or decrease your income, so recommended configuration for advanced users.
    • Luck: Affects the drop probability of items and the amount of income added by random numbers on the chain.
    • Durability: Affects VFE charging cost.

    Rarity Description:

    • Normal: Free with purchase of fitness equipment.
    • Elite: Collect VFE parts and combine with VFE chips to mint a new VFE, with a small probability to obtain.
    • Rare: ToEarnFun Official regular sales.
    • Epic: Participate in the ToEarnFun official event to get it.

    Base stats and upgrade points, common < elite < rare < epic.

    The gameplay is completely decentralizedโ€‹

    Most GameFi applications are implemented with asset transaction decentralization and gameplay centralized solutions. Because most Dapps are implemented based on smart contracts, limited by the execution efficiency and upgrade difficulties of smart contracts, it is difficult to achieve decentralized gameplay. Thanks to the forkless upgrade feature of Substrate, we can implement the gameplay on the chain, and more new gameplay can be implemented through the Runtime upgrade in the future, which will be a Web3 application in the true sense.

    Project Application Scenariosโ€‹

    Combination of Physical Industry and Blockchainโ€‹

    production

    Participants: Fitness Users, Equipment Producer, ToEarnFun Official.

    1. ToEarnFun Official first needs to create a VFE class on-chain. The first thing we implement is the VFE of the rope skipping.
    2. To cooperate with ToEarnFun, equipment producers need to complete qualification certification and deposit a certain amount of security deposit into the Producer Ledger on the chain, which will be used to deduct fees for subsequent minting of VFE instances.
    3. According to the deposit amount deposited by the equipment producer, the system grants the producer a certain number of VFE minting rights.
    4. After the equipment producer completes the qualification certification, the toearnfun-crypto-sdk is integrated into the fitness equipment chip to realize the encryption protocol.
    5. Before leaving the factory, fitness equipment needs to be registered on the Equipment Ledger, and a mintinng fee will be reserved from the Producer Ledger on-chain.
    6. Fitness users can buy ToEarnFun cooperative fitness equipment in the local store without cryptocurrency.
    7. Fitness users complete on-chain activation of fitness equipment through the ToEarnFun app.
    8. After the fitness equipment is successfully activated, Producer Ledger will pay a minting fee from the reserved balance to ToEarnFun Official Treasury.
    9. Because the producer has the minting right of the VFE class, a VFE instance will be minted on-chain to fitness users.
    10. Fitness users can get a VFE instance for free, in fact, the producer paid the minting fee when registering the equipment on the chain.

    This business model not only helps traditional fitness equipment producers enter the Web3 world, expands the user base, and promotes industrial development, but also brings stable income to ToEarnFun and motivates FUN on GameFi in the future. Modules provide the foundation.

    Fitness + GameFiโ€‹

    Fitness+GameFi

    Participants: Fitness Users, ToEarnFun Official.

    1. Fitness users use fitness equipment for daily training.
    2. The fitness equipment signature training data will be reported to the on-chain Training Ledger through the App.
    3. Calculate the reward according to the VFE attribute bound to the fitness equipment and the number of energy consumed during the training.
    4. The FUN incentive module issues rewards to fitness users, but there is a daily upper limit on rewards.
    5. Fitness users can use FUN to level up VFE instances to increase attribute points.
    6. Fitness users can sell their excess FUN to the FUN Buybck Pool.
    7. ToEarnFun official regularly buyback FUN in the pool.
    8. After each buyback of FUN, its buyback price will change. In order to ensure price stability, changes in the FUN Buyback Price will affect its inflation rate.

    This business model not only allows users who like fitness to get the equivalent of their sweat, but also allows users who are addicted to GameFi to have the goal of fitness.

    VFE Marketโ€‹

    VFE Market

    Participants: Fitness Users, ToEarnFun Official, 3rd-party IP.

    1. ToEarnFun Official can approve 3rd-party IP certain amount of VFE minting rights.
    2. Whether it is ToEarnFun Official or 3rd-party IP, as long as you have VFE minting rights, you can mint new VFE instances.
    3. However, every time a VFE instance is minted by a 3rd-party IP, the minting fee needs to be paid to ToEarnFun Official.
    4. The newly minted VFE instance will be put into the VFE market and will be sold by auction or fixed-price.
    5. Fitness users can consume FUN to unbind the VFE instance on the equipment.
    6. The unbound VFE instance can be sold to the VFE market.
    7. Fitness users can also buy their favorite VFE instances in the VFE market.
    8. Fitness users buy VFE instances with better attributes, and then bind them to the equipment for training, which is the most effective way to earn FUN.

    Compared with traditional games, GameFi has the characteristics of playability and possession, and game items have value. ToEarnFun Official can bring income through the sale of VFE, or it can also approve 3rd-party IP to mint VFE to bring income. Fitness users can also freely exchange VFE in the market to achieve arbitrage.

    Competition Challengeโ€‹

    Competition challenge

    Participants: Fitness Users, ToEarnFun Official, Public Welfare Organizations.

    1. ToEarnFun Official create competition template, set: registration fee, registration requirements, competition requirements, scoring rules, bonus distribution, cycle time limit, etc.
    2. The competition template will publish event instances periodically.
    3. Fitness users who meet the registration requirements can pay the registration fee to participate in the event.
    4. Fitness users use their own fitness equipment to challenge according to the requirements of the competition.
    5. The fitness equipment reports the training data to the on-chain competition record.
    6. After the game, the game record will be determined according to the scoring rules of the game.
    7. Prizes will be awarded to the winner of the competition.
    8. A portion of the funds raised by the event will be invested in the Public Welfare Treasury.
    9. The funds of the Public Welfare Treasury can be donated to public welfare organizations through the proposal of the Public Welfare Council.

    The use of blockchain to realize competition events is a very suitable application scenario. It not only makes the competition fair, open and transparent, but also greatly reduces labor costs and allows the Public Welfare Treasury to obtain more funds. At the same time, DAO is used to manage the Public Welfare Treasury, which ensures the sustainable development of public welfare undertakings.

    Project Architectureโ€‹

    Architecture

    More About This Projectโ€‹

    Ecosystem Fitโ€‹

    Where and how does your project fit into the ecosystem?โ€‹

    As we all know, it is more complicated for ordinary users to enter Web3. They need to buy cryptocurrencies and learn to use cryptocurrency wallets. Learn about different ecosystems and find out which Dapps are right for them.

    I try to simplify this entry through the combination of hardware + Substrate + Mobile App. Let ordinary people only need to buy a smart jump rope at the retailer, and training everyday, Web3 will give them another income. Gradually, they will learn about the Polkadot ecosystem, and they will slowly discover that Polkadot's parachains can bring them more value.

    Who is your target audience?โ€‹

    Our target audience are fitness enthusiasts and Polkadot ecosystem's users.

    What need(s) does your project meet?โ€‹

    • Use token incentives to promote people's daily training and get healthy body.
    • Through physical product sales, new users will be brought to the Polkadot ecosystem.

    Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?โ€‹

    Similar projects have not yet appeared in the Substrate / Polkadot / Kusama ecosystem. This table compares our project to similar projects in other ecosystems.

    ItemsSTEPNFitRToEarnFun
    Physical ProductNoNoYes
    Proof of TrainingThe App calculates the training data, and the central system provesSame as STEPNHardware calculates training data, blockchain proves
    IncentivesGST has no upper limit and transferable, GMT has pre-mined and transferableSame as STEPNFUN has no upper limit and is not transferable, PNT has no pre-mining and the official promise to buyback
    EcosystemSolana/BSC/EthereumBSCPolkadot/Kusama
    Target AudienceCrypto usersSame as STEPNCrypto users and fitness users
    Source of incomeNFT Sales, Market TaxSame as STEPNVFE Sales, Market Tax, Product Sales

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Zhiquan Mai: CEO. He once served as the development leader of cryptocurrency wallet system of Bitbank. In his spare time, he has developed some open-source iOS projects, such as Bitcoin Multisig wallet and CHKLineChart. Now he is responsible for the development of openwallet framework, which supports more than 70+ blockchain protocols.
    • Jianqiang Chen: System development engineer. Now he is responsible for the development of the openwallet developer platform, which provides APIs to help developers quickly build cryptocurrency wallet applications.
    • Dongxing Liang: System architect engineer. Now he is responsible for the back-end development of the openwallet.link enterprise-level digital-assets management system, and provides more than 70+ main chain assets and token asset custody services for digital financial companies.
    • Yinghao Fan: Front-end engineer. He is now responsible for the front-end of openwallet related applications, such as the back-end of enterprise asset management, wallet applications, etc.
    • Shuchao He: Cryptographic algorithm engineer. He is now responsible for the development of the underlying cryptographic library of openwallet, and supports the implementation of cryptographic algorithms such as ECC, Hash, and transaction verification for mainstream blockchains.

    Contactโ€‹

    • Registered Address: Zhongshan Meiju Industrial Park, 6th Floor, Building 9.
    • Registered Legal Entity: Zhongshan Shangyuzhou Technology Co., Ltd.

    Team's experienceโ€‹

    Our team has developed the openwallet framework and redefines a wallet system model compatible with multiple blockchains. At the same time, we have build an openwallet developer platform, which integrates 70+ blockchain protocols, which greatly reduces the cost of developers and users.

    Our team also uses the openwallet developer platform to provide enterprises with blockchain-related development services, such as: cryptocurrency wallets, enterprise-level cryptocurrency management systems, multi-chain multisig wallet systems.

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    • At present, we have completed the official website release.
    • At present, we have completed App Mockups, and some VFE and Smart Jump Rope Design.
    • Polket is under development and the Testnet has been deployed .
    • We have found a smart jump rope factory to develop a prototype product and embedded the encryption library we wrote into the product's chip. Each product generates a ECC keypair at the factory and implements the signature algorithm of the training data.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4 months
    • Full-Time Equivalent (FTE): 4 FTE
    • Total Costs: $30,000 USD

    Milestone 1 - Implement the gameplay of VFE on Polket, and implement App based on Flutterโ€‹

    • Estimated duration: 2 month
    • FTE: 4
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseGPL-3.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Substrate module: pallet-vfeThis module implements VFE gameplay, such as: producer_register, device_type_create, register_device, bind_device, sport_upload, power_recovery etc.
    2.Substrate module: pallet-unique-idThis module implements self-incrementing ID maintenance for stores in pallet-unique.
    3.Substrate module: pallet-currenciesThis module is an implementor of frame_support::traits::fungibles compatible with pallet-balances and pallet-assets.
    4.Substrate module: pallet-supportThis module provides standard traits definitions for data interaction between different pallets.
    5.Flutter App: Smart Jump Rope supportedThe App first supports smart jump rope, such as connecting equipment, generating keys in the equipment, and synchronizing training data.
    6.Flutter App: Integrate polkawallet-sdkThe App will integrate polkawallet-sdk to implement a built-in wallet that supports the polkadot ecosystem.

    Milestone 2 - Implement the buyback and VFE Market on Polket, and release Android App(Alpha-test)โ€‹

    • Estimated Duration: 2 month
    • FTE: 4
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseGPL-3.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains the features and gameplay of this app.
    1.Substrate module: pallet-buybackThe implementation of this module allows the buybackers to establish an asset buyback pool, set the buyback asset quota and buyback date, and allow participants to invest in asset A, which will be converted into asset B when the buyback date is reached.
    2.Substrate module: pallet-vfe-orderThis module implements the order book function of the VFE trading market.
    3.Flutter App: VFE Buyback PoolThe app implements the buyback pool function, allowing users to invest in asset A and get another asset B when the buyback date is reached.
    4.Flutter App: VFE MarketThe App implements the VFE trading market, allowing users to freely buy and sell VFE.
    5.Android Alpha-test ReleasedWe will release the first Alpha-test App supporting the android platform.

    When the milestones in the grant are completed, we will open source the entire project. Our projects are open source based on GPL-3.0 license.

    Future Plansโ€‹

    1. We plan to apply for some funding from the Kusama Treasury before launching the App beta version to meet the first batch of equipment production. We will invite internal test users to the community, and distribute the first batch of equipment to them for free testing experience.
    2. Polket plan to bid on Kusama's parachain slots to gain access to the Kusama ecosystem.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Substrate website.

    - + \ No newline at end of file diff --git a/applications/pontem.html b/applications/pontem.html index 29bc29c4699..4ca1f7d5ca6 100644 --- a/applications/pontem.html +++ b/applications/pontem.html @@ -4,13 +4,13 @@ Pontem Network (VM). | Web3 Foundation Grants - +
    Skip to main content

    Pontem Network (VM).

    • Team Name: Dfinance (Wings Stiftung).
    • Payment Address: 32AAAxmKJ9XxCsGSwt11oAuovCUHbgsgfY.

    Project Overviewโ€‹

    Overviewโ€‹

    Pontem Network aims to bring the Move VM and Move language, and ecosystem around it to Polkadot.

    The Move language and the Move Virtual Machine, both developed by Facebook Libra, are among the safest technologies out there that enable the creation of smart contracts. While having built-in security by design such as resource-oriented architecture and formal verification, Move VM still severely lacks toolsets and documentation.

    We are going to create the Move pallet to make it possible for developers to publish their Move VM modules and execute scripts, also, we already built a rich toolset and documentation for Move language, so we will need only adopt it for Polkadot.

    This is where our team has a unique experience, due to over 2 years spent working with Move and building tools around it. We have been working closely with Libra (as recognized technical adopters) as part of the Dfinance project which is utilizing the Move language and Move VM in order to run safe and usable smart contracts.

    Project Detailsโ€‹

    Implementation of Move VM pallet won't be an easy task, even taking into account our experience connecting Move VM with Cosmos SDK, achieved via integrating Move VM as GRPC service.

    In the case of Polkadot WASM Runtime we canโ€™t repeat the same approach with GRPC due to limitations of Runtime, but we can do a more elegant solution by utilizing Move VM inside Runtime. To be clear letโ€™s see our plan step by step.

    1. Move VM and language written in Rust language and can be compiled to WASM, unfortunately we canโ€™t use crates that depend on runtime. We will create a stable working pallet by forking of Move VM/language and replace creates with ones we can use.
    2. We will make Move VM outputs (writesets) compatible with Polkadot key-value storage, as during our latest research we discovered itโ€™s not going to work โ€œout of the boxโ€ and will require some time to build a solution. Same with address format SS58, and non VM balances.
    3. We need to make gas usage of Move VM compatible with Polkadot standards. At least by using the same units like other VMs/pallets using.
    4. Build a documentation around the Move pallet, adopt existing tools and docs about VM and language.

    We already have rich experience in these topics because of our current Dfinance project, so far we developed:

    Ecosystem Fitโ€‹

    • Developers can be interested to build their DApps on Polkadot using Move technology stack, as itโ€™s a safe and useful language which is getting more and more adoption.
    • Libra is developing and using Move, so Polkadot will have at least initial compatibility with Libra at least by allowing using the same modules in both networks.
    • Flow - Crypto Kitties creators blockchain also going to utilize Move VM and language, also by creating new language on top of it - Cadence, which can be adopted to Polkadot later.

    Teamโ€‹

    Team membersโ€‹

    • Oleg Gaidukov - CTO.
    • Boris Povod - R&D Lead and Blockchain developer.
    • Alexander Kozlovsky - Rust developer and Rust community enthusiast.
    • Dmitry Yakushev - Rust developer.
    • Vitaly Rudko - Dev Ops.

    Contactโ€‹

    • Registered Address: Gubbelstasse 11, 6300 Zug, Switzerland
    • Registered Legal Entity: Wings Stiftung

    Teamโ€™s experienceโ€‹

    We are an experienced team, our current project is Dfinance, in the past we've launched Wings platform, and before that we've developed Crypti (which became Lisk).

    Team Code Reposโ€‹

    Contributions to other projects (Libra & Cosmos SDK):

    Team LinkedIn Profilesโ€‹

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4 months.
    • Total Effort: 357 days.
    • Total Costs: 1.4658 BTC.

    Milestone 1 - Pre-Alpha version of Move palletโ€‹

    • Estimated Duration: 1.5 month
    • Working days x ppl. : 28 x 4
    • Effort: 112 days
    • Costs: 0.419 BTC
    NumberDeliverableSpecification
    0.Crates listBuilding a list of crates we have to replace with analogues could work in runtime or make our own versions which can work in runtime also.
    1.Crates developingDuring our research we can use sp-std for part of cases, but unfortunately we will have to fork it and add additional functional or create our analogue crates contains missed functional.
    2.Crates replaceAdopt Move VM for runtime using developed crates.
    3.Move PalletCreate a Polkadot pallet with Move VM inside. Alpha version, without processing of WriteSets.
    4.Addresses supportAdd support of SS58 addresses to Move VM.
    5.CompilerAdopt compiler to compile modules/scripts for Move VM inside pallet.
    6.Unit-testsBasic unit-tests coverage, at least 30%.
    7.DockerDocker-compose to quickly launch standalone version of Move VM.
    8.DocumentationInitial documentation how to run Move VM inside Pallet/standalone, execute scripts and publish modules.

    Milestone 2 โ€” Alpha version of Move palletโ€‹

    • Estimated Duration: 1.5 month
    • Working days x ppl. : 28 x 5
    • Effort: 140 days
    • Costs: 0.5508 BTC
    NumberDeliverableSpecification
    0.WriteSets processingProcess WriteSets from MoveVM to Polka storage. Read/Write operations, Del operations.
    1.Events processingProcess Move events format to Polkadot one and publish them to block.
    2.Publish TransactionCreate a transaction type to support Move module publishing.
    3.Execute Arguments ParsingTo enable execute script transactions support we need to parse script arguments.
    4.Standard LibraryMove Standard Library Module adoption for Polkadot.
    5.Execute TransactionCreate a transaction type to execute Move scripts.
    6.Unit-testsCover 60% of the pallet functional with unit tests.
    7.Resource viewerResource viewer to view Move resources from Substrate node storage.

    Milestone 3 โ€” Beta version & Ecosystemโ€‹

    • Estimated Duration: 1 month
    • Working days x ppl. : 21 x 5
    • Effort: 105 days
    • Costs: 0.496 BTC
    NumberDeliverableSpecification
    0.Gas compatibilityChange VM gas usage units and math to make it compatible with Polkadot.
    1.Non-VM balances compatibilityVM supports native coins inside smart contracts, example: DOT.
    2.REST APIREST API to compile, publish/execute modules and scripts.
    3.RPCRPC to publish/execute modules and scripts.
    4.DocumentationSupplement documentation with all features we provided: txs, compilers, smart contracts examples.
    5.Deployment of prod envSpin up instances on the top of DigitalOcean/Kubernetes cluster, set an auto deploy etc.
    6.disassembler adoptionAdopt current disassembler for Substrate node.
    7.Unit-testsCover 85% of pallet functional with unit tests.

    Future Plansโ€‹

    Wings Stiftung plans to continue supporting Move ecosystem. We want to build a bridge between Polkadot and Libra as Parachain, and launch our Parachain with Move VM pallet inside. Also, we going to proceed with further development of toolset (Move debugger, unit-testing framework, etc.) and extend our Wallet with Polkadot-specific features.

    Additional Informationโ€‹

    Wings Stiftung will be as well supporting financially this project. We are going to apply to another Grant for the implementation of the Pontem network.

    - + \ No newline at end of file diff --git a/applications/project_1001.html b/applications/project_1001.html index f8f267271c7..6d931a81036 100644 --- a/applications/project_1001.html +++ b/applications/project_1001.html @@ -4,14 +4,14 @@ Project 1001 - MVP - Phase 1 | Web3 Foundation Grants - +
    Skip to main content

    Project 1001 - MVP - Phase 1

    This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a > (such as this one) can be removed.

    See the Open Grants Program Process on how to submit a proposal.

    • Team Name: Uniwrap/1001 Group
    • Payment Address: 0x173553c179bbf5af39D8Db41F0B60e4Fc631066a (USDT)
    • Status: Terminated

    โš ๏ธ The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Project 1001 is a combination of wordToWorld and Uniwrap, and is also an experiment with NFTs and DeFi. It creates a very interesting game for users to play. It transforms spoken words into dynamic NFT stories in real-time using speech recognition and natural language processing. Users can generate stories with NFT models, the generated story is an NFT / a group of NFTs. A user who has the story could bid to exhibit it on a piece of land to the whole world.

    project 1001wordtoworld
    "1001"wordToWorld

    Project 1001 as a part of Substrate / Kusama / Web 3 Ecosystem

    Project Detailsโ€‹

    Featuresโ€‹

    • Speech interactive: let a bird fly just by saying "The bird is flying!", 1001 visualize a dynamic world according to users' spoken words.
    • Composable NFT story: NFTs from different networks could be integrated together into one story, the story itself as grouped NFTs could be used in multiple DeFi cases like lending, staking, or as an IDO permission.
    • DIY unique characters: Make your own characters by composing different body parts, see them come to life right away in your story.
    • Rentable land for stories: There are various lands for renting and telling stories. Users can bid for exhibiting their story for the land, and the story will be recorded in "world history".
    marketplacestory exposure
    marketplace-creationstory display
    land economymodel editor
    land-rentingmodel editor

    Token Usagesโ€‹

    In the game, the system token is used in all the cases involved with the economy, specifically:

    • A story could be minted as an NFT on different lands with system token.
    • The story elements like Action, Emoji, Sounds could be exchanged as NFT on the marketplace.
    • A story on different lands outputs different stories, and the land could be bought or rented with system token, so that a story could be displayed on the land.
    • Our model editor enables users to easily create models in 1001 and models could be minted as an NFT with system token as fee.

    Here is the flow of the token economics with KSM as the system token for example.

    token economics

    Ecosystem Fitโ€‹

    According to our research, we are the first project to build an NFT game on Substrate, and we hope to create a new era of NFT+DeFi.

    The 1001 project could make NFTs more interactive, add exposure, and enable NFT creation just by speaking by non-tech and non-art users, the created NFT could be further used in the internal DeFi scenarios, so it could greatly extend the NFT usability on Polkadot/Kusama.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Xinyue Yang - Team Lead
    • Leo Yang - Team technical Lead
    • Alex - Team fullstack technical engineer

    Contactโ€‹

    Team's experienceโ€‹

    Xinyue Yang, is the lead designer. is the founder of wordtoworld.io, the project is an extension of her bachelorโ€™s and masterโ€™s project at Kunsthochschule Berlin Weissensee, she joined DesignFarm Berlin, a design-in-tech accelerator in Berlin Germany in October 2020. Her Bachelor project โ€œScribbling Speechโ€ turns real-time speech into animated drawings. It was featured by Google Experiment (AI collection) and was exhibited at Google I/O 2019 video tent. She continued this topic and did my Masterโ€™s project โ€œWord to Worldโ€, which visualizes the spoken words into dynamic 3D animations. It opens up a new interactive experience of story-telling, and she decided to found a startup and develop a speech-interactive product for parents and kids to tell stories.

    Leo Yang, is the lead technical, he is the founder of UniWrap, which enables users to mint a group of token assets into NFTs and jointly participate in DeFi services. He has many years of software development experience and is a decentralized technology believer and a DeFi native. He has developed many successful Defi protocols, and participated or led the development of blockchain projects such as the chains and exchanges. He has rich project development experience in Bitcoin, Ethereum, Substrate, Nervos and other chains.

    Alex, is the fullstack technical engineer, he has 7 year of software development experience. He has developed many successful Cross-Chain Dapps such as exchanges and contracts IDE. He has rich project development experience on large Cross-Chain projects.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Estimated duration: 3 month
    • FTE: 3.5 FTE
    • Costs: 30,000 USD

    Roadmapโ€‹

    We will need to complete the NFT minting and composing logic, the land buying and renting logic, and the game with Unity in the next 4 months. At that time we will be able to have a playable mobile app game. Model Editor and DeFi utility will come in the second phase.

    Disclaimerโ€‹

    The currently 1001 team has no overlap with the wordToWorld team except Xinyue. In 1001 the team will create a new open-source game with an open source language processing engine.

    Contribution to the ecosystemโ€‹

    The 1001 project could make NFTs more interactive, add exposure, and enable NFT creation just by speaking by non-tech and non-art users, the created NFT could be further used in the internal DeFi scenarios, so it could greatly extend the NFT usability on Polkadot/Kusama.

    Deliverablesโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basictutorial that explains how mint/buy/lend project 1001 NFT with story and models.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains the work done as part of the grant.
    1a.Pallet module: 1Create the assets pallet for models, story and assets. 1 Week
    1b.Pallet module: 2Complete RMRK2.0 compatible pallet development. 1 Week
    1c.Pallet module: 3Enable model and story transfer, creation, enable compose different models into a story. 1 Week
    1d.Wallet moduleConnect the wallet creation with the game login process. 1 Week
    1e.Frontend module: 1Generate the basic world of the game in Unity. 2 Weeks
    1f.Frontend module: 1Bind the in-game story creation with on-chain extrinsics. 2.5 Weeks
    2a.Land module: 1Adding land as NFT into protocol, enable story placed into land. 1.5 Weeks
    2b.Land module: 2Enable land lending and land auction. 1 Week
    2c.Land module: 3Integrate the story creation. 2 Weeks
    3a.Integrate phase: 1Bind the in-game story creation and land lending with on-chain extrinsics. 2 Weeks
    3b.Integrate phase: 2Create tutorial for play in the app, and create stories. 1 Week
    3c.Integrate phase: 3Deliver a iOS app on TestFlight which could be download and play. 1 Week

    So the total duration will be 12 weeks, which is approximately 3 months. We will use Rust for pallets code, Ink! for smart contracts and Unity/Typescript for frontend UI.

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/project_aurras_mvp_phase_1.html b/applications/project_aurras_mvp_phase_1.html index c9e8035da94..986b8244a89 100644 --- a/applications/project_aurras_mvp_phase_1.html +++ b/applications/project_aurras_mvp_phase_1.html @@ -4,7 +4,7 @@ Project Aurras - MVP - Phase 1 | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ Dr. C. Pethuru Raj is currently working as Chief Architect and Vice president in the Site Reliability Engineering (SRE) Center of Excellence, Reliance Jio Platforms Ltd. (JPL) Bangalore. Previously worked as a cloud infrastructure architect in the IBM Global Cloud Center Of Excellence (CoE), IBM India Bangalore for four years. Before that, He had a long stint as TOGAF-certified enterprise architecture (EA) consultant in Wipro Consulting Services (WCS) Division, Also worked as a lead architect in the corporate research (CR) division of Robert Bosch Bangalore. In total, He has gained more than 17 years of IT industry experience and 8 years of research experience. Completed the CSIR-sponsored Ph.D. degree at Anna University, Chennai, and continued with the UGC-sponsored postdoctoral research in the Department of Computer Science and Automation, Indian Institute of Science, Bangalore. Thereafter, He was granted a couple of international research fellowships (JSPS and JST) to work as a research scientist for 3.5 years in two leading Japanese universities. Published more than 30 research papers in peer-reviewed journals such as IEEE, ACM, Springer-Verlag, Inderscience, etc. Having authored 25 books thus far that focus on some of the emerging technologies such as IoT, Cognitive Analytics, Blockchain, Digital Twin, Containerization, Data Science, Microservices Architecture, fog/edge computing, etc. Also have contributed more than 30 book chapters thus far for various technology books edited by highly acclaimed and accomplished professors and professionals. He is currently advising the team at HugoByte AI Labs on impactful technology innovations.

  • Muhammed Irfan K
    Muhammed Irfan K is a strategic thinker and implementer of innovative ideas with an emphasis on educating and bringing back privacy to the people. Having Co-Founded HugoByte AI Labs and Serving as CTO. He envisions a world where AI is open, distributed, and democratized by building a decentralized infrastructure and policy framework to regulate it. He has extensive experience in designing and building Highly Scalable Enterprise Architecture, Leading Team, Full-Stack Development, Microservices, Machine Learning.

  • Hanumantappa Budihal
    Hanumantappa Budihal has 4 years of experience as an Application Developer and Azure DevOps Engineer. His technical skills include .NET Core Framework, Azure DevOps, SQL Developer, ASP .NET MVC, REST Web API, WPF, Microsoft Azure, Cognitive Services, Algorithms Design for a complex business requirement, and Watson Discovery, with good knowledge of Application Architecture and Design pattern implementation and data analysis skills. He is a hard worker moreover eager to learn new skills. He has also worked on cognitive application development using various IBM Bluemix services such as conversation, Natural language understanding, Watson discovery, and developed few chatbots using Api.ai and Microsoft bot framework. He is currently working as a Solutions Architect in HugoByte AI Labs.

    • Team Code Reposโ€‹

    Source codes will reside in

    Repos for further reference

    Team Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Event Source - Substrate Event Feedโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDocumentation includes Inline Code Documentation, Configuration Documentation, Event Post Action Deployment guide, Docker and Docker compose setup documentation, Openwhisk Setup Documentation, Readme file
    0c.Testing GuideThe code will have unit-test coverage (min. 50%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    1a.Substrate Event Feed: ConfigurationReading Configuration based on Environment, Override Configuration if Environment Variables provided, Configrations for Chain endpoint Sections and Methods from extrinsic to Exclude, types, Openwhisk Endpoint, Openwhisk Auth Key, Trigger Endpoint, Kafka Topic and Brokers
    1b.Substrate Event Feed: Chain ModuleConnects to the chain, Add custom type to chain intialization if provided, Subscribes to system.events
    1c.Substrate Event Feed: Event ModuleFilters Events based on excludes provided, Post Events to trigger Endpoint
    1d.Substrate Event Feed: Docker ImageDockerfile for Substrate Event Feed Package
    1e.Substrate Event Feed: Docker Compose ConfigurationAdd Substrate Event Feed Service in Docker Compose Configuration
    1f.Substrate Event Feed: Helm Chart ConfigurationHelm Chart Configuration for Substrate Event Feed for Kubernetes
    2.Event Manager: Event Post ActionMinimal JS Implementation of Event POST Action with Payload as Kafka Topic, Broker and Event Data such as section, method and Event Payload

    Milestone 2 โ€” Event Manager - Part 1โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDocumentation includes Inline Code Documentation, Configuration Documentation, Kafka and Zookeeper Deployment guide, wskdeploy guide, Readme file
    0c.Testing GuideThe code will have unit-test coverage (min. 50%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    1a.Kafka Provider: ForkFork Existing openwhisk-package-kafka
    1b.Kafka Provider: Helm Chart ConfigurationHelm Chart Configuration for Kafka Provider for Kubernetes
    2.Database ServiceImplement DB Service, DB Integration, Connect DB provided through configuration variables, Dockerfile for Containerization, Docker Compose Configuration
    3a.Event Manager: Event Source RegistrationIntegrate with DB service - CouchDB, Register Source with Chain Name, Chain Specification, Create Unique topic for provided Section-Method, Return created topics - Section-Method Map
    3b.Event Manager: Kafka provider feed actionIntegrate with DB service - CouchDB, Add CREATE, READ, UPDATE, DELETE lifecycle methods for trigger, Validate parameters (Section-Method, broker, isJSONData, isBinaryValue, isBinaryKey), Get unique topic from DB using Section-Method param,Record topic and related trigger to DB on CREATE lifecycle
    3c.Event Manager: Deployment ConfigDeployment Config for wskdeploy tool
    3d.Event Manager: Intermediate ContainerDockerfile for Containerization, Container with wsk cli and wskdeploy util, Script to add Openwhisk auth key, Deploy Openwhisk Actions and Create Triggers and Rules
    3e.Event Manager: Docker Compose ConfigurationDocker Compose Configuration for Event Manager: Intermediate Container
    3f.Event Manager: Helm Chart ConfigurationHelm Chart Configuration for Event Manager: Intermediate Container for Kubernetes

    Milestone 3 โ€” Event Manager - Part 2โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDocumentation includes Inline Code Documentation, Configuration Documentation, Readme file
    0c.Testing GuideThe code will have unit-test coverage (min. 50%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.ArticleWe will write a Medium article that explains the work done as part of the grant.
    1a.Event Manager: Kafka Produce ActionValidate for parameters, Connect to provided brokers, Produce data to provided topic, Add deployment config to wskdeploy config
    1b.Event Manager: Kafka provider feed actionIntegrate with DB service - CouchDB, Delete trigger from DB on DELETE lifecycle, Read trigger from DB on READ lifecycle, Update trigger from DB on UPDATE lifecycle
    2a.Substrate Event Feed: ConfigurationCouchDB Config, Available Sections and Methods of the chain to create unique topics
    2b.Substrate Event Feed: Event Source RegistrationIntegrate with DB service - CouchDB, Save Unique ID in DB for topic provided through Event Manager: Event Source Registration

    Future Plansโ€‹

    We have planned immediate grant as second phase of our development (Draft with Complete deliverables can be found here https://github.com/MuhammedIrfan/Open-Grants-Program/blob/master/applications/project_aurras_mvp.md)

    Immediate Plans in the timeline Includes

    Our Roadmap includes

    Additional Information โž•โ€‹

    Any additional information that you think is relevant to this application that hasn't already been included.

    Possible additional information to include:

    - + \ No newline at end of file diff --git a/applications/project_aurras_mvp_phase_2.html b/applications/project_aurras_mvp_phase_2.html index 9ba61cb8037..392af910455 100644 --- a/applications/project_aurras_mvp_phase_2.html +++ b/applications/project_aurras_mvp_phase_2.html @@ -4,7 +4,7 @@ Project Aurras - MVP - Phase 2 | Web3 Foundation Grants - + @@ -19,7 +19,7 @@ Shreyas is an experienced software developer with great zeal in implementing solutions in the software domain. He is skilled in Blockchain, smart contracts, ethical hacking, Rust and Golang. He currently is the Development Team Lead at HugoByte AI Labs and is instrumental in driving the team to great success. He obtained his Bachelor's degree focused in Computer Science from Bapuji Institute of Engineering & Technology, Davanagere.

    Shanith K K
    Shanith is a Software Engineer and a Web developer. Having graduated his M.Sc in Software Engineering, he is a diligent and industrious technocrat. He has published a paper titled on "Segmentation: A review" in JETIR (JETIRCG06006). He has worked on machine learning using python programming. He has substantial and working knowledge about programming languages like Rust, Python, C, C++, and he is currently working on blockchain development in HugoByte AI Labs. He has an insatiable passion for coding and is exceptionally good at problem-solving.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Articleโ€‹

    Documentationโ€‹

    Codebaseโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Workflow Composer - Part 1โ€‹

    NumberDeliverableSpecificationUser Story
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide the following documentation: Inline Code Documentation, Flow design, Readme file
    0c.Testing GuideWe will compose a testing guide to describe how to run tests. The code will have unit-test coverage (min. 50%) to ensure functionality and robustness
    1a.Workflow Composer: Rust OpenWhisk Client LibraryWe will create a Minimal Implementation to OpenWhisk Rust ClientUsers can invoke workflows that employ certain pre-deployed actions in the OpenWhisk.
    1b.Workflow Composer: ComposerWe will build a Wrapper Library compose yaml to wasmUsers can compose the WASM from the workflow YAML.
    1c.Workflow Composer: PipeWe will build an interface to connect other operators and tasksUsers can facilitate the usage of the output of one task as the input of the next.
    1d.Workflow Composer: structured YAML fileWe will provide a YAML file with a predefined structure to configure the workflow composerUsers can utilize the pre-defined YAML file to create custom workflows.
    1e.Workflow Composer: Concat OperatorWe will build an operator interface to merge two flowsUsers can facilitate the concatenation of two tasks to get a combined final output that can be consumed by the next task.
    1f.Workflow Composer: Map OperatorWe will create an operator to map the inputs to the outputs of each flowUsers can facilitate the transformation of the output of one task to a format required by a subsequent task.
    2Predefined boiler plateWe will build a predefined Rust code for flow generationUsers can create workflow WASM that utilizes the boilerplate code to implement the necessary functionalities that carry out the tasks defined in the YAML.
    3a.Flow Provider for Tackle BoxWe will create a provider to employ the necessary hooks for the workflowUsers can use the flow provider to generate the code to implement the flow of data between the tasks.
    3b.Task Provider for Tackle BoxWe will create a provider that will generate a struct with the given macros and argumentsUsers can use the task provider to generate the code necessary to execute the tasks defined in the workflow YAML.
    3c.Workflow Provider for Tackle BoxWe will create a provider that will interface the operators and tasksUsers can use the workflow provider to generate the code necessary to execute the workflow as defined in the workflow YAML.

    Milestone 2 Workflow Composer - Part 2โ€‹

    NumberDeliverableSpecificationUser Story
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide the following documentation: Inline Code Documentation, Operator Documentation, Flow design, Readme file
    0c.Testing GuideWe will compose a testing guide to describe how to run tests. The code will have unit-test coverage (min. 50%) to ensure functionality and robustness
    0d.Docker FileWe will provide docker file for running the workflow composerUsers can utilize the docker image as a cli tool to generate workflow wasm from the provided yaml
    1a.Workflow Composer: Flow MacroWe will create three types of flows: init, pipe and terminator. The init is used to create the first task in the workflow and the terminator is used to create the last task. The pipe method is used to create other tasks that accept inputs and are dependent on other tasksUsers can utilize the flow macro that is used by the flow provider to generate the code to implement the flow of data between the tasks.
    1b.staking and payout features for scs/substrate-api-clientstaking functionalities and payout example. fixed bugs in staking moduleshttps://github.com/scs/substrate-api-client/pull/294

    Milestone 3 โ€” Web API/Backendโ€‹

    NumberDeliverableSpecificationUser Story
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide the following documentation: Inline Code Documentation, Operator Documentation, Flow design, Readme file
    0c.Testing GuideWe will compose a testing guide to describe how to run tests. The code will have unit-test coverage (min. 50%) to ensure functionality and robustness
    0d.ArticleWe will write a Medium article that explains the work done as part of the grant
    1a.Web API: Workflow RegistrationWe will create an API that is Exposed as a part of workflow deployment, where workflow will be registered as an OpenWhisk action and made available to specific namespaceUsers can deploy a workflow to execute the required tasks for a particular scenario.
    1b.Web API: User RegistrationWe will create an API for User to register themselvesUsers can register themselves to the system and receive a unique ID.
    1c.Web API: User Workflow ManagementWe will create an API for User to select workflow and provide argument values, Pause Workflow, Delete WorkflowUsers can update the inputs of a registered workflow.
    Users can pause an active workflow.
    Users can unfreeze a paused workflow.
    Users can delete a registered workflow.
    2a.Workflow Yaml Polkadot PayoutsWe will create a YAML file that defines the workflow for claiming the Polkadot validator payouts to the provided walletUsers can create a workflow YAML to claim PolkaDot payouts using the pre-defined YAML file.
    2b.Reward OpenWhisk actionsWe will create OpenWhisk actions to index the validator details to the Kafka topic that will invoke the validator payout workflowUsers can utilise the pre-deployed OpenWhisk actions to validate the validator ID and check claims for the particular validator.
    2c.Claim workflow moduleWe will create a plugins to carry out the tasks of claiming the validator rewards to the provided wallet as defined in the workflowUsers can claim Polkadot payout rewards using the registered workflow.
    2d.Polkadot API Derive macro for workflow taskWe will create derive macros that will provide the necessary functionalities for the task struct to perform RPC callsUsers can facilitate the execution of tasks that utilize the derive macro to perform RPC calls.
    3.Video TutorialWe will create a set of video tutorials to guide the users to use this MVP

    Future Plansโ€‹

    Immediate Plans in the timeline Includes

    Our Roadmap includes

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?
    We came across the Web3 Grants Program while perusing about the developments in the Web3 ecosystem on the Web3 Foundation Website.

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    Update & Amendmentsโ€‹

    28/12/2022โ€‹

    We have encountered a critical issue where we faced workflows fails due to certain Openwhisk actions timing out hence we took an alternative approach where we have made Polkadot API wasm compatible and included as a plugin to the wasm, due to this the timeline has now been exceeded by several months and has made certain components we developed obsolete.

    - + \ No newline at end of file diff --git a/applications/project_bodhi.html b/applications/project_bodhi.html index 353edae2312..c9936bd12bd 100644 --- a/applications/project_bodhi.html +++ b/applications/project_bodhi.html @@ -4,14 +4,14 @@ Project Bodhi - A Composable & Innovative Stack for EVM on Substrate | Web3 Foundation Grants - +
    Skip to main content

    Project Bodhi - A Composable & Innovative Stack for EVM on Substrate

    This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

    • Team Name: Acala
    • Payment Address: BTC address: 1Q88PtW866r4bfv2eMphobP78QnsDrRKfY

    The above combination of your GitHub account submitting the application and payment address will be your unique identifier during the program. Please keep them safe.

    Project Overview ๐Ÿ“„โ€‹

    If this application in response to an RFP then please indicate this on the first line of this section.

    Overviewโ€‹

    Backgroundโ€‹

    It is clear to us that building a better, faster and cheaper Ethereum is not nearly enough. Just like Ethereum can do things Bitcoin can never do and subsequently inspired many new innovations, Substrate and Polkadot are categorically different from Ethereum that will empower many new types of innovations outside of the sandbox.

    On a domain-specific chain like the Acala chain, there're many domain specific runtime optimizations. For example, thereโ€™re DeFi primitives, liquidity and users that can be tapped into, there are also innovations that are simply not possible on Ethereum - customizable economic policy, for example Acalaโ€™s Flex-Fee allows users to pay transaction fee with any supported tokens; native cross-chain capability; on-chain governance apparatus (no more locked funds); full upgradability (no more contract migrations) and more.

    Weโ€™d love to have all of these and EVM compatibility.

    Current Solutionโ€‹

    Current solution i.e. Frontier in principle is to emulate the Ethereum node experience. It aims to implement the full set of Ethereum RPC and emulates Ethereum block production process. This allows existing Ethereum tools such as Metamask and Remix to work with a Frontier enabled node seamlessly.

    Integrating Frontier have revealed the following challenges by their severity:

    1. Confined inside the EVM Sandbox (High): users will need to use a Substrate wallet (e.g. Polkadot-js Extension) and Metamask at the same time if they ever want to taste the real power of Acala, Substrate or Polkadot for that matter. This is certainly a deal-breaker for us.
    2. Making Nodes more Expensive (Medium-High): Substrate does not store transactions by hash nor historical events, nor does it provide any event filtering ability. Frontier injects special block importing logic, storing the transactions and events into an off-chain auxiliary store in order to power the query API required by Ethereum. This kind of goes against the goal to have a lightweight node to lower barriers for people from anywhere to run nodes which helps the network to be more decentralized.

    Our solution - Project Bodhi: Composable & Innovative Stack for EVM on Substrateโ€‹

    solution

    Project Bodhi offers these benefits

    1. Full-stack composability: expose pallets API as EVM precompiled contracts
    2. Single-wallet experience: emulate full Ethereum JS SDK client (bodhi.js)
    3. Lightweight while Queryable: Substrate node + Indexer node
    4. Iterate fast with Typescript
    5. Revamped EVM economics

    This solution can be very useful for any domain-specific chains that want to offer the full experience of runtime and Smart Contract.

    Project Detailsโ€‹

    We expect the teams to already have a solid idea about the project's expected final state.

    Therefore, we ask the teams to submit (where relevant):

    • Mockups/designs of any UI components
    • API specifications of the core functionality
    • An overview of the technology stack to be used
    • Documentation of core components, protocols, architecture etc. to be deployed
    • PoC/MVP or other relevant prior work or research on the topic

    Details documentations of the projectโ€‹

    • Project overview PPT here
    • Project brief & plan here

    PoCโ€‹

    We have completed a proof-of-concept to verify feasibility of the project here

    Technology Stackโ€‹

    • The SDK (bodhi.js): this will be a new provider SDK which gets injected into existing web3.js, and wraps around polkadot-js to do Ethereum and Substrate translations (transactions, RPC calls, weights to gas etc.). Written in Typescript.
    • The Substrate Node: implement additional RPC to interact with EVM
    • The Indexer server: integrate it with bodhi.js, EVM event logging etc. Current implementation here which both Laminar and Acala testnets have been using.

    Scopeโ€‹

    There are a lot of work involved to get all of these into a product-ready state, which is what we always aiming for, but it'd be too big to fit into one single open grant. Therefore we have carved out a scope specifically for this grant, followed by details for future work.

    Grant Scope: Project Bodhi MVP The MVP scope involves

    • building all necessary components for ERC20 playground
    • integrate with an existing Ethereum project that is reasonably sophisticated and requires us to build address mapping between Substrate & EVM addresses
    • integrate with one existing Ethereum deployment tool e.g. Waffle

    Future development

    1. Expose orml-currencies precompiles to EVM
    2. Expose orml-nft precompiles to EVM
    3. Implement and integrate with Indexer Node
    4. Integrate fully with Polkadot Extension
    5. EVM economics: state renting, contract existential deposit, contract deployment economics
    6. Replace Gas system with Weights system

    Ecosystem Fitโ€‹

    Nope, if so we'd be more than happy to leverage it than build it ourselves.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Architect: Bryan Chen
    • Product Manager: Bette Chen
    • Runtime Developer: Shaun Wang
    • Full-stack Developer: Nantian Duan
    • Full-stack Developer: Ermal Kaleci

    Contactโ€‹

    • Registered Address: 105 Cecil Street #15-01, The Octagon, Singapore 069534
    • Registered Legal Entity: ACALA PTE. LTD.

    Team's experienceโ€‹

    The team is made of experienced Substrate builders, various members are contributors to substrate, polkadot-js and other core libraries.

    Bryan Chen is an active contributor to substrate codebase, a Polkadot community ambassador, and substrate/polkadot lecturer. He's the architect and technical brainpower behind the Laminar & Acala project.

    Bette Chen has more than a decade product/program/project management experience with background in Software Engineering and MBA from Otago and Duke. She's in charge of product and operation for Laminar & Acala.

    Nantian Duan is a full-stack developer, who built DApps for ChainX and now Laminar exchanges, he also actively contributes to polkadot-js and other code-bases.

    Ermal Kaleci is a full-stack developer. He's an award winning mobile application (e.g. healthcare app developer turned Substrate developer.

    Shaun Wang has been contributing to several Polkadot ecosystem open source libraries, including Substrate, parity-common, type-metadata, etc.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Team Githubโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-time equivalent (FTE): 2FTE, the listed members would contribute to different deliverables based on their skill-set.
    • Total Costs: 1.79 BTC

    Milestone 1 ERC20 Playgroundโ€‹

    • Estimated Duration: 1.5 month
    • FTE: 2
    • Costs: 0.79 BTC

    Goal - Develop a web DApp & necessary components to allow users

    1. input token name, symbol, supply amount and deploy new ERC20 tokens
    2. input ERC20 address and query balances and allowance
    3. make transfer / transferFrom / approve transaction
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a tutorial that explains how a user can use the playground, and deploy their own ERC20 contracts
    0c.Testing GuideThe code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests
    1.SDK - bodhi.js: integrateIntegrate with one of an existing Ethereum JS library. e.g. ethers
    2.SDK - bodhi.js: translateTranslate Ethereum transactions to Substrate transactions; Translate some Ethereum RPC to Substrate RPC needed for the MVP
    3.Substrate pallet: modules-evmFork of pallet-evm from Substrate with necessary changes; Implements new RPC to allow SDK to emulate eth_estimateGas and eth_call
    4.Web DApp: ERC20 PlaygroundImplement the dapp
    5.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.

    Milestone 2 Example โ€” Additional featuresโ€‹

    • Estimated Duration: 1.5 month
    • FTE: 2.5
    • Costs: 1 BTC

    Goal - Integrate with one existing Ethereum project

    1. Be able to deploy & run e2e tests in Acala EVM
    2. Make sure the SDK provided by the project works with minimal changes
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a tutorial that explains how the existing Ethereum project is deployed and benefits
    0c.Testing GuideThe code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests
    1.SDK - bodhi.js: deployment toolIntegrate with one of an existing Ethereum deployment and testing tool e.g. Waffle
    2.SDK - bodhi.js: Address mappingUse module-evm-accounts to handle address mapping between Substrate & EVM addresses; Handles all Ethereum RPC used by project SDK
    3.Substrate pallet: module-evm-accountsprovide a two way mapping between Substrate accounts and EVM accounts so user only have deal with one account / private key
    4.Substrate pallet: modules-evmDrop the gas price mechanism from Ethereum in favor of the weights mechanism from Substrate
    5.IntegrationDeploy an existing contract and ensure it works e2e
    6.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.

    Future Plansโ€‹

    Our vision is to provide a composable and innovative stack for EVM on Substrate. We've seen the power of composibility in DeFi on Ethereum, and it's not limited to one domain. Meanwhile we also want to break-free from Ethereum constraints, and offer innovative economic models, fight scams, and improve usability. We're determined to make this next level unified experience happen on Substrate, through the the Project Bodhi stack. We are going to eat our own dog food to use it for Acala. And we believe it will be useful for most domain-specific parachains/parathreads who have custom runtime and also want to leverage smart contracts.

    Future development

    1. Expose orml-currencies precompiles to EVM
    2. Expose orml-nft precompiles to EVM
    3. Implement and integrate with Indexer Node
    4. Integrate fully with Polkadot Extension
    5. EVM economics: state renting, contract existential deposit, contract deployment economics
    6. Replace Gas system with Weights system

    Additional Information โž•โ€‹

    Any additional information that you think is relevant to this application that hasn't already been included.

    Possible additional information to include:

    • What work has been done so far?
      • we have done PoC to prove it's possible, evaluated edge cases and figured out to the full-scope for production ready development.
      • Project overview PPT here
      • Project brief & plan here
      • PoC code here
    • Are there are any teams who have already contributed (financially) to the project?
      • Just the Acala team
    • Have you applied for other grants so far?
      • Acala has a grant from W3F for stablecoin. Founding members of Acala project, Laminar and Polkawallet also received grants for their respective projects.
    - + \ No newline at end of file diff --git a/applications/project_silentdata.html b/applications/project_silentdata.html index 20e83acf7c9..c2bd01dc520 100644 --- a/applications/project_silentdata.html +++ b/applications/project_silentdata.html @@ -4,14 +4,14 @@ Silent Data Polkadot Integration | Web3 Foundation Grants - +
    Skip to main content

    Silent Data Polkadot Integration

    Team Name: Applied Blockchain Ltd

    Payment Address: USDC (Ethereum) address: 0x91a5ade2522ac8c3761922a4255e0fef89116a37

    Level:(https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2

    Project Overview ๐Ÿ“„โ€‹

    This application is in response to an RFP

    Overviewโ€‹

    Applied Blockchain has developed Silent Data as a platform for proving properties of private off-chain (web2) data in blockchain smart contract (web3) applications (dApps).

    Silent Data leverages hardware secure enclaves with attestation, in particular, Intel SGX in order to enable privacy-preserving retrieval and processing of off-chain data, and generation of cryptographic proofs that are verifiable in blockchain smart contracts. This ensures that sensitive information is never revealed, not even to those hosting the platform, and code attestation with a smart contract link ensures that the code used to retrieve the data and generate the proofs cannot be modified or interfered with by the operator.

    Silent Data proof certificates are powerful because they can verifiably demonstrate that private data meets certain requirements without the need to reveal that data, and without that data being accessible to Silent Data operators. The service is initially centrally hosted, and will be decentralised over time in order so that it cannot be censored by the operator. One of the properties of SGX is that it is possible to prove what code is being run inside a particular enclave. This means that we would be able to provide decentralised "nodes" with prebuilt enclaves that contain the code required to run the Silent Data service and then provision them with encrypted secret keys so that they can create compatible proof certificates. Once provisioned, these nodes would be able to run in a decentralised fashion, independent from the original operator.

    Silent Data enables verification of web2 account ownership, including social media services such as Instagram. This enables enrichment of web3 identities and assets with attestations from the web2 world, for example, if someone is using web3 to purchase from a brand with a web2 presence.

    NFT creators with verified Instagram accounts, for example, can use Silent Data to prove they are behind a specific wallet. This will help to reduce fraud in NFT and web3 commerce.

    Silent Data will also be extended to enable verification of web2 financial credentials, to augment web3 DeFi and tokenisation dapps.

    An indication of how your project relates to / integrates into Substrate / Polkadot / Kusama.

    Silent Data provides privacy-preserving cryptographic proofs about properties of web2 data. We refer to the output as a โ€œproof certificateโ€, consisting of a set of key-value pairs signed by a manufacturer attested hardware secure enclave. The signatures can be verified using various cryptography primitives available on different blockchains, including Polkadot (Substrate) and Ethereum. A blockchain wallet is associated with a Silent Data proof certificate by having the wallet owner sign the private data that is encrypted and sent to the enclave with their wallet private key.

    Silent Data will integrate with a Substrate chain to provide maximum coverage within the Polkadot ecosystem.

    Integrating and enabling Silent Data in Polkadot parachains will help to bring additional functionality and security to Polkadot dapps that have some reliance or interaction with the web2 world and web2 accounts.

    Pokadot will benefit through enabling identifies to be further verified where necessary using cryptographically verifiable proofs of web2 accounts (social media, such as Instagram, or otherwise), enabling the DeFi ecosystem to grow more securely beyond native on chain assets to those assets whose origin, provenance and/or price are anchored in web2 accounts (through additional integrations with other web2 accounts). Polkadot DeFi investors will benefit from increased cryptographic verifiability when backing off chain and real world assets.

    An indication of why your team is interested in creating this project.

    Applied Blockchain was founded by Adi Ben-Ari, in London in 2015 when the Ethereum code base was first released, and he spent the early months with some members of what became the Parity team exploring and understanding the platform. Since then Applied Blockchain has closely followed developments at Parity and Polkadot (including some minor collaborations along the way), and is particularly interested in bringing the Silent Data technology to Polkadot parachains and dapps.

    Polkadot parachains already offer a broad range of dapps and functions, and coupling the strong security fundamentals of Substrate with those of Silent Data will create compelling additional optionality for Polkadot dapp developers.

    Project Detailsโ€‹

    • Mockups/designs of any UI components

    September 2022

    • Data models / API specifications of the core functionality
    • September 2022
    • An overview of the technology stack to be used

    Silent Data includes a public facing web application and API that facilitate communication with a secure enclave. DApps can request an individual to securely transfer their data to the enclave for verification. Generally, the subject of a check will provide access to their data to the enclave via an OAuth flow which generates credentials that can be used to fetch data from APIs on behalf of the subject. These credentials are encrypted and sent to the enclave along with a signature of the private data used to verify ownership of a blockchain wallet.

    The enclave decrypts the credentials and uses them to retrieve data from trusted data sources over HTTPS (initially Instagram). The enclave will then perform the preconfigured calculations and checks on the data in order to verify that the input query is true or false. The wallet signature and decrypted credentials are also used to prove that the owner of the wallet had access to those credentials and is most likely the owner of the data.

    The enclave can optionally associate and attest to non-private data relating to the check (e.g. Instagram account name) by including it in the proof certificate data as key-value pairs. The proof certificate includes some standard information such as an identifier of the check performed, the wallet address of the user, a timestamp, and the identifier of the proof certificate on Silent Data, along with any extra non-private data. The enclave will then sign this certificate using an algorithm compatible with the target blockchain and send it to the the dApp smart contract for persistence and verification.

    Substrate dApp smart contracts will initiate the Silent Data proof of Instagram account ownership check. The smart contracts will receive the proof certificate from the Silent Data enclave, and verify the attestations, proving that the owner of the wallet is the owner of an Instagram account, but proving they have direct access to login to the web2 account.

    • Documentation of core components, protocols, architecture, etc. to be deployed

    Documentation of core components, protocols and architecture to be deployed can be found here: Silent Data Architecture

    • PoC/MVP or other relevant prior work or research on the topic

    Silent Data News: https://silentdata.com/news

    Ecosystem Fitโ€‹

    We believe that as part of the evolution of web3, web2 and web3 will converge before diverging. This will enable users to leverage their identities and assets, currently anchored in web2 to the web3 world. In order for this to occur, web3 DApps, including those deployed in many of the Polkadot parachains, need a way to securely and safely verify off-chain web2 data.

    Regular web2 API integrations require trust in additional third parties, as data can be compromised, viewed and manipulated. Standard blockchain oracles reveal sensitive web2 data to validators. With Silent Data, DApps can now fully verify web2 data properties, without any data being revealed.

    There are already numerous parachains deployed in the Polkadot ecosystem, primarily focussed on DeFi, NFTs, identity and tokenisation services. Many of those parachains and dApps can benefit from integrating with Silent Data to verify web2 credentials, including Instagram account ownership to provide proofs that can then be leveraged by the parachain dApps (for example to augment the identify of a seller wallet) without the need to share any user data during the verification process and without storing the user data in the parachain. Silent Data will also be extended to enable verification of web2 financial credentials, to augment web3 DeFi and tokenisation dapps.

    • What need(s) does your project meet?

    The project enables smooth and user-friendly proof of web2 account ownership and credentials in web3 dApps. This can be used to reduce fraud, but augmenting web3 wallet identities and assets with verified web2 account data (e.g. Instagram account ownership), without revealing sensitive account data and credentials to any third parties or platform operators..

    Silent Data can be used to verify web2 account ownership, such as social media accounts ownership such as Instagram, for example, to provide proofs that can be used inside the web3 environment. The solution guarantees complete confidentiality and that no user data is visible during the verification process, not even to the platform operator, nor is it persisted anywhere outside the web2 platform.

    NFT creators with verified Instagram accounts, for example, can prove they are behind an NFT and prove their wallet owns a certain verified Instagram account. With this they can avoid it being impersonated or having fake assets being associated with their identity by providing cryptographic proof of Instagram account ownership and associating this with their wallet and minted NFT.

    Future implementations will apply not only to Instagram and NFTโ€™s, but also to other identity and asset credentials useful in DeFi.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Adi Ben-Ari
    • Francesco Canessa, Andrew Campbell, Shawn Derouard, Mario Gemoll, Thomas Brooks, Shay Har-Zion

    Contactโ€‹

    Registered Address: One Canada Square, Canary Wharf, London E14 5AB, UK Registered Legal Entity: Level 39

    Team's experienceโ€‹

    Adi Ben-Ari is the founder & CEO at Applied Blockchain. Prior to starting the company Adi spent 20 years as a developer, technical lead and solution architect in telecoms, insurance and banking.

    LinkedIn: https://www.linkedin.com/in/adibenari/

    Francesco Canessa is the CTO at Applied Blockchain. Francesco is a seasoned technology expert and a serial hackathon winner, with a decade of experience in software development and four years within building blockchain applications. Francesco has worked on large-scale enterprise projects and with startups, building solutions for Sky TV Italia, 5Apps, and Quill Content to name a few. He has also developed tools and libraries for Ethereum and Bitcoin. Francesco is a fan of reading, writing and talking about software development, and is an open source enthusiast. When heโ€™s not looking at code, Francesco builds and rides electric skateboards.

    LinkedIn: https://www.linkedin.com/in/makevoid/

    Mario Gemoll leads R&D at Applied Blockchain. Mario studied Computer Science (BSc TU Munich, MSc Oxford) and has several years of experience as a software engineer. He joined Applied Blockchain in 2017. At the company, Mario has led research into blockchain protocols, advanced cryptography and hardware secure enclaves, as well as leading design and development of a major NFT platform. Mario leads the research and development of Silent Data for privacy-preserving proofs of off-chain data using Intel SGX secure enclave technology. Prior to Silent Data, Mario led development of the K0 blockchain protocol bringing transactional data privacy to existing smart contract blockchains using zero-knowledge proofs. Mario also led research and developed a secure multi-party computation protocol for privacy-preserving price discovery in trading environments. LinkedIn: https://www.linkedin.com/in/mariogemoll/

    Ricardo Seromenho is a full stack developer at Applied Blockchain. He is a Node.js application/services certified developer with a degree in Information Technology and 7 years experience. He is a hands-on software engineer with a big passion for best practices and reusable patterns and proficient in a wide range of technologies.

    LinkedIn: https://www.linkedin.com/in/rseromenho/

    GitHub: https://github.com/seromenho

    Thomas Brooks is one of the core developers on the Silent Data platform at Applied Blockchain. He joined the company after completing a doctorate in high energy particle physics, developing software and machine learning algorithms for 3D particle interaction reconstruction. Thomas has a broad range of experience in software development, from creating open source visualisation and analysis tools used by world leading biology labs to writing Ethereum smart contracts for DeFi applications.

    LinkedIn: https://www.linkedin.com/in/tom-brooks-a940a9a7/

    GitHub: https://github.com/tgrbrooks

    Andrew Campbell is the Head of Product at Applied Blockchain. He previously worked as solution architect with over 10 years of development experience including over 6 years industry experience. He has spent the last 6 years working with a range of London based startups. As an architect he has designed solutions for a range of enterprises including Shell, Vodafone, UN - World Food Programme, SITA. He has been the architect of tens of blockchain and advanced cryptography projects and many of his architectures have been taken into production.

    LinkedIn: https://www.linkedin.com/in/andylnd/

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    If you've already started implementing your project or it is part of a larger repository, please provide a link and a description of the code here. In any case, please provide some documentation on the research and other work you have conducted before applying.

    Silent Data Architecture: Silent Data Architecture

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Substrate Adapterโ€‹

    • Estimated duration: 2 months
    • FTE: 2.5
    • Costs: 30,000 USD
    NumberDeliverablesSpecification
    0a.LicenseMIT.
    0b.DocumentationWe already have a whitepaper describing the principles behind the Silent Data system, but we will also provide Polkadot specific setup instructions as well as supporting documentation (in the form of READMEs) for the example smart contract code.
    0c.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0d.Testing and Testing GuideThe testnet examples will be shared with Polkadot developers to integrate Silent Data into their dapps and parachains.
    0e.ArticleWe will publish an article/workshop that explains what was done/achieved in the extension and deployment of Silent Data confidential computing oracle.
    1.ExtensionWe will extend the Silent Data confidential computing oracle to generate proofs verifiable by ink! smart contracts by adding support for the sr25519 signature scheme and the polkadot{.js} wallet extension.
    2.LibraryWe will develop a JavaScript/TypeScript library to enable Node.JS backends to interact with the Silent Data API. The library will allow DApp creators to generate new proof certificate requests and fetch the results of checks.
    3.Smart ContractWe will develop an example ink! smart contract for verifying Silent Data proof certificates and extracting the verified proof data. The smart contract will take a signed certificate and signature as input verify either an sr25519 or ed25519 signature with a fixed enclave public key stored in the contract. The contract will then parse the CBOR encoded certificate data to extract the verified key-value pairs and optionally store them on chain. We will deploy the smart contract to a Polkadot testnet and provide an example DApp to demonstrate the flow of generating Instagram account verification certificates with Silent Data and verifying them in a smart contract.

    Future Plansโ€‹

    • Integration with other web2 social media platforms (Twitter, Google authentication, etc.).
    • Integration with other identity and asset related web2 data sources (open banking, identity and AML checks).
    • The team's long-term plan is to become the platform for providing properties of private web2 data for consumption by web3 applications.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/prosopo.html b/applications/prosopo.html index 5f5f261fe1a..f40de7358d0 100644 --- a/applications/prosopo.html +++ b/applications/prosopo.html @@ -4,7 +4,7 @@ Prosopo | Web3 Foundation Grants - + @@ -37,7 +37,7 @@ own software and the grant software, we can provide our entire project development plan for your understanding and to set expectations on delivery.

    All our schedules assume two full time equivalent software developers / designers (2 FTE).

    5.2 Milestone 1 - Prosopo Contract and Provider Service Developmentโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains a user can use the Contract docker image and Provider Service docker image. This will demonstrate how to register as a Provider from the command line and host and serve captcha data with a local Substrate Chain (Substrate Contracts Node).
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. We will describe how to run these tests in the project READMEs.
    0d.DockerWe will provide two Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that introduces Prosopo and the service it will provide. The contract features will be described in the README.md along with details how to run. (Content, language and medium should reflect your target audience described above.)
    1Prosopo Contract Development
    • Contract containing all set / get functions for Prosopo captcha service written in ink!
    • ink! Unit Tests for Prosopo Contract (80% coverage)
    • External ink! contract containing function to check DApp User reputation in Prosopo Contract
    2Prosopo Provider Service
    • Command line interface for Providers to:
      • store a local captcha database (MongoDB)
      • serve captchas to users
      • check captcha solutions
      • interact with the Prosopo Contract
    • Written in TypeScript
    • TypeScript unit tests (80% coverage)
    2External ContractExternal contract containing function to check DApp User reputation in Prosopo Contract

    5.3 Milestone 2 - Prosopo Client SDK & Deliveryโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will documentation that explains how to include the Captcha Client in a DApp website and smart contract. All previous documentation will be reviewed and finalised.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. We will describe how to run these tests in the project README.
    0d.DockerWe will provide Dockerfile(s) that can be used to test all the functionality delivered with this milestone. These come as a single docker-compose file for all three services (Prosopo Client SDK, Provider Service SDK, Prosopo Contract)
    0e.ArticleWe will create a demo website on GitHub pages that shows how to implement the Captcha Client and create an accompanying article about this.
    1Prosopo Client SDKThis is a frontend JavaScript client presented to a DApp User that will:
    • check account status
    • request captchas from the Prosopo Provider Service
    • submit solutions
    • validate captcha data with on-chain commitment from Provider
    • validate solution was approved on-chain
    Unit tests will be provided. The client will be written in TypeScript.
    2Demo WebsiteWe will create a demo website on GitHub pages that shows how to implement the Captcha Client.
    3Integration RepositoryScrips to run all components in developer environment

    6 Future Plansโ€‹

    The Prosopo captcha service will be deployed to a Substrate chain (chain to be confirmed) that implements pallet-contracts. This will be the initial version of the service and will help us refine before deploying on additional chains. Initially, Provider registrations will be invite only and will be opened up once the service is deemed to be properly functioning.

    6.1 Enhancementsโ€‹

    6.1.1 Captcha Service SDKโ€‹

    The following features will be added to the Captcha Service SDK:

    6.1.1.1 Multilingual supportโ€‹

    Initially, captchas will either be language-independent or English based. This will be expanded to cover as many languages as possible.

    6.1.1.2 Database supportโ€‹

    Captchas will initially need to be stored in a database on the Providers server. This feature will be improved to accept multiple different types of database and also distributed storage, such as IPFS.

    6.1.2 Prosopo Smart Contractโ€‹

    The following features will be added to the Prosopo smart contract:

    6.1.2.1 Difficulty Levelsโ€‹

    It will be possible for Dapp Operators to request captchas of different difficulties.

    6.1.2.2 Time-based Difficulty Schedulingโ€‹

    It will be possible for Dapp Operators to request captchas of different difficulties by different times of the day.

    6.1.2.3 Voting on Captcha Formatsโ€‹

    Initially, the captcha formats will be limited however it will be possible for community members to submit new formats in future and vote on their inclusion in the system. This will increase the variety of available verification methods. This opens up the possibility of distributed reputation stores that each hold their own database of account scores (or credit scores).

    6.1.2.4 Self-referencingโ€‹

    A self-referencing reputation system will be created by assigning some small amount of positive reputation to previously unknown new Dapp Users if they are vouched for by existing Dapp Users with large positive reputations. Vouching may involve some kind of staking.

    6.1.2.5 Provider FRAME Palletโ€‹

    A pallet may be introduced so that the Provider service can become part of the Substrate chain hosting it. This will reduce the need for multiple services to be run by Providers as the Provider Service SDK would not be required, instead replaced by a single substrate node. This strategy may also increase Provider numbers if a major chain adopts the pallet.

    6.2 Promotionโ€‹

    Prosopo will be promoted initially via campaigns directed at Dapp Operators in the Polkadot ecosystem. There are currently interested partners in the NFT space with a desire to prevent bots from registering en-masse to claim the majority of tokens from airdrops.

    6.3 Supportโ€‹

    Prosopo will be supported by the team members who will function as the governing body initially. These roles will eventually be rewarded via a native token and open up to the general public. A community forum and documentation centre will be created to encourage participation.

    Prosopo will be running at least one Provider service to ensure that the network has a constant supply of captchas.

    6.4 Long Term Plansโ€‹

    Prosopo will be ported to other Polkadot contact parachains such as the Moonbeamโ€™s, which enables contracts that use the EVM (Ethereum Virtual Machine).

    The team is committed to contributing to the Prosopo governing body in the long term and fostering community involvement.

    Ultimately, we would like to see innovations in bot detection in the blockchain space and believe that a marketplace for human verification methods is an optimal solution. Whilst captchas are currently the focus, future verification may involve grading the humanness of accounts based on account activity and connections. The Prosopo smart contract and Provider service will be flexible enough to accommodate these new formats.

    7 Additional Information โž•โ€‹

    7.0.1 How did you hear about the Grants Program?โ€‹

    Web3 Foundation Website

    7.0.2 Additional Infoโ€‹

    Financing of this proposal and non-grant related development has been funded by Prosopo Limited. There are no other parties involved other than those listed in this document. No previous funding has been received.

    - + \ No newline at end of file diff --git a/applications/psc.html b/applications/psc.html index 210f654a390..7725d84ae65 100644 --- a/applications/psc.html +++ b/applications/psc.html @@ -4,7 +4,7 @@ Polkadot Smart Chain | Web3 Foundation Grants - + @@ -24,7 +24,7 @@

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    The team is made up of many experienced professionals in the blockchain industry.

    Tianling(0xhelloweb3) was a former senior expert of Alibaba. After leaving it, he joined a blockchain company as the core developer for 6 years. He is familiar with the underlying blockchain design and substrate development and also was in charge of the architecture design. Now, he is the team leader of OmniBTC team.

    Jianbing Zhao(icodezjb) is a Substrate / Rust Engineer with 5 years blockchain experience, He is also the core developer of ChainX. Now he is the principal blockchain expert of OmniBTC team.

    Wei Dai(AAweidai) is a Substrate / Rust Engineer with 2 years blockchain experience, He is also the core developer of ChainX. Now He is the leader of our DOLA-Protocol which is the core application protocol on PSC.

    LiMing Sun has rich experience in product design and management. He has built many nice and user-friendly internet application. Now he is the senior product manager of OmniBTC team.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    We are not on LinkedIn.

    Development Status ๐Ÿ“–โ€‹

    We have completed the Testnet demo version of PSC. The first version is ready to be launch on polkadot as 2053 parachain.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Basic functionalityโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to complete the Native Currency transfer between relaychain and PSC through DMP/UMP, and how to deploy and call the evm contracts on PSC
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains how are ethereum address and substrste account related.
    1.Substrate module: pallet-assets-bridgeWe will create a Substrate module that is a bridge from substrate assets(wasm) into ERC20 tokens(evm).
    2.Polkadot Smart Chainpallet-assets-bridge of PSC will interact in such a way: Bind EVM address and Substrate account, bind WASM assets and Erc20 tokens, deposit and withdraw fungible assets between WASM and EVM
    3.Smart contracts: AssetsBridgeErc20We will deliver a set of evm smart contracts that are Erc20 contracts adapted to pallet-assets-bridge.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?
    Web3 Foundation Website.

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    - + \ No newline at end of file diff --git a/applications/quadratic-funding.html b/applications/quadratic-funding.html index 5c70b394474..96b8f8c8d71 100644 --- a/applications/quadratic-funding.html +++ b/applications/quadratic-funding.html @@ -4,7 +4,7 @@ Quadratic Funding Module | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ Gitcoin is currently using this mechanism to successfully fund and support public goods. However, Gitcoin's solution is centralized. The goal of the RFP is to develop a decentralized solution on top of Substrate, which can potentially be integrated into Kusama, Polkadot or any other Substrate-based chain as a pallet. The on-chain treasury could potentially sustainably fund the matching pool in the long-run. However, the Web3 Foundation would also be committed to fund a matching pool of the solution for initial test rounds.

    We will build a Substrate pallet in Rust.

    I have friends working at Gitcoin since 2018 and I'm a big fan of their work. I am already a Gitcoin user familiar of the CLR mechanism used in their grants, and think it's a great experiment trying to solve many real-world problems. Transparency has always been one of the highlights of blockchain, and by bringing a innovative and sophisticated funding mechanism on-chain will provide great utility to Polkadot ecosystem. The problem is challenging and fun to solve, and related to the DAO concept of my focus, therefore I decide to gear up and tackle the RFP.

    Project Detailsโ€‹

    We expect the teams to already have a solid idea about the project's expected final state. Therefore, we ask the teams to submit (where relevant):

    * Mockups/designs of any UI components
    * API specifications of the core functionality
    * An overview of the technology stack to be used
    * Documentation of core components, protocols, architecture etc. to be deployed
    * PoC/MVP or other relevant prior work or research on the topic

    The project is divided into two milestones, substrate module and web application.

    In the first milestone we will create a substrate module for the core CLR mechanism implementation, which will include struct, event, error code, and API function definitions. Then, we will build a substrate chain to host and demonstrate the module.

    In the second milestone, we will create a web application interacting with Polkadot.js browser extension to demonstrate the use case of the developed module. The features of the web interface will be similar to today's Gitcoin web UI, however, rather than retrieving the matching donation calculation results from a centralized server, our UI will talk to our substrate chain directly. Upon sending a donating transaction, a user is guaranteed that his/her donation has been recorded in substrate storage and corresponding matching fund will be arranged by the chain.

    A simple flow of the application is shown using below UML sequence diagram. Note that it only demonstrates the ideal case. Interruptions and error cases are omitted in the diagram.

    User flow diagram on Lucid Chart

    Diving deep into possible user scenarios, I find they are more complicated than initially thought. For example, we need to code a way to prevent collusion of two projects, one of which could possibly use the matching fund to vote for the other's application in order to get more funds. That said, we will start with the basic logic and address issues occurred on the way.

    Update #1

    We have completed the initial design of the web app wireframe, so I'm attaching it below. It contains two major pages, the Project Listing page and Project Detail page. The goals of those pages are to clearly present details of participating projects, as well as the matching amount to individual donation. I personally like the user comments and on-chain transactions elements at the bottom of the second page. Not only does it create a plaza for individual donators to speak out, it also connects the donation activity to those voices, thus creating a strong sense of authenticity.

    Web app wireframe on Lucidchart

    Ecosystem Fitโ€‹

    Are there any other projects similar to yours? If so, how is your project different?

    There are DAO projects such as PolkaDAO being built on Polkadot, providing utility for fund-raising of private companies. However, our focus is different. This project aims to provide an on-chain crowdfunding solution with a matching function. Specifically, it consists of two components, crowdfunding and matching donations.

    1. Crowdfunding: Individuals crowdfund donations towards public goods (for example: open source software).
    2. Matching donations: These individual contributions are โ€˜matchedโ€™ or โ€˜topped-offโ€™ by a government, grants program, or private philanthropist.

    Besides open-source program grant, the CLR mechanism can be applied to other crowdfunding for public goods, such as government electoral voting and non-profit funding. I have friends running an non-profit organization at Silicon Valley. My goal is to work with her to create the first real-world non-profit fundraising using CLR on Polkadot.

    Team ๐Ÿ‘ฅโ€‹

    Team nameโ€‹

    OAK Foundation

    Team membersโ€‹

    Contactโ€‹

    Individuals

    Team's experienceโ€‹

    Please describe the team's relevant experience. If the project involves development work, then we'd appreciated if you can single out a few interesting code commits made by team members on their past projects. For research-related grants, references to past publications and projects in a related domain are helpful.

    I worked at Microsoft for 4 years as a senior protocol (API) engineer before taking the leap into blockchain 2017, and have accumulated great experience with smart contract and application development on Ethereum, EOS, and RSK. Here are my achievements and expertise.

    My strongest programing languages are C++ & C#, and have been ramping up on Rust since Fall 2020.

    Team Code Reposโ€‹

    Update 2: UI Examplesโ€‹

    UI demos of the team's previous work, which includes

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    This section should break out the development roadmap into a number of milestones. Since the milestones will appear in the grant contract, it helps to describe the functionality we should expect, plus how we can check that such functionality exists in the product. Whenever milestones are delivered, we refer to the contract to ensure that everything has been delivered as expected.

    Overviewโ€‹

    Milestone 1 โ€” Implement Substrate Modulesโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains the usage of the API.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.TutorialWe will write tutorials on Medium that explains the work done as part of the grant.
    1.Substrate module: CLRWe will create a Substrate module that have below functionalities.
    1. Project: create, cancel, contribute, withdraw
    2. Proposal: create, vote, cancel, finalize, appeal
    3. Functions should be able to interact with Polkadot Identity Module and filter participants based on their identity information.
    2.Substrate chainModule CLR of our custom chain will be interacted with above defined functions through API
    3.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain

    Milestone 2 โ€” Web Application (Dapp)โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can interact with the application with Polkadot.js browser extension.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.TutorialWe will write Medium tutorials that explains the work done as part of the grant.
    1.Application ImplementationWe will incorporate the javascript library from the previous step and build a web application that interacts with our substrate chain. Note that the web is a separate product from polkadot.js.org/apps/#/rpc and will provide user friendly interface without necessary knowledge of API calls.
    2.Deployment InstructionsWe will provide one-line runner for the web application so others could spin up the app easily.

    Future Plansโ€‹

    Please include the team's long-term plans and intentions.

    In my opinion there are tons of things we can keep iterating on, but there are four important areas in terms of future development.

    1. User Study. We should invite a group of beta users for trial and feedback after launch. According to @semuelle, a few questions should be answered in the study plan. For example,

    2. Sybil resistance. As development of this mechanism progresses to production, a number of challenges such as collusion and Sybil attack need to be addressed. Vitalik has proposed a method MACI, or Minimal anti-collusion infrastructure and a project Governance OS Voting from Polkadot General Grant has been working on a solution. We will try our best to integrate those open source projects in order to fight against collusion.

    3. Generalization of incentive protocol. The CLR mechanism, if proven, is one of many ways to conduct crowd-funding for public goods. Just as Substrate provides a framework for any kind of state transition machine, the donation-matching, or even broadly, incentive part should be generalized to easily adapt to other methods. Although new methods need to be coded into the substrate module, but as it evolves, the module will contain most common used methods for the council to choose from.

    4. Reputation protocol integration. The incentive protocol layer sits on top of and relies on reputation protocol. Although the CLR can work without knowing the reputation of a wallet, a lot more advanced features will require a reputations system. For example, without reputation, the risk of cheating is minimum. Therefore, the incentive protocol needs a lot of heavy-lifting work, such as keeping tracking of the relationship of every wallet pair to prevent fraud. Ideally, there will be a reputation layer on Polkadot for our incentive protocol to build upon.

    5. Fund dispensing. We have this idea to raise money for public goods, however, could we also improve the way we spend the money? With the transparency of blockchain, the delivery of the work is open to public for examination. By connecting the developer to the public directly, the product will dramatically reduce the work required from the traditional middleman and create a fair competition among developers.

    6. Social experiment. The project is only valuable when put into real-world scenarios. It, along with Polkadot, are great exciting social experiments. I believe in beta and later production we will encounter challenges on both technical and philosophical sides. It will be an on-going effort to address those issues, and to improve the product as it's constantly put into test.

    Additional Information โž•โ€‹

    Possible additional information to include:

    We have gone through all tutorials on substrate.dev, played around with the framework and are ready to start.

    None

    No

    - + \ No newline at end of file diff --git a/applications/quantumLock.html b/applications/quantumLock.html index 2e726648329..02dc97ebc7f 100644 --- a/applications/quantumLock.html +++ b/applications/quantumLock.html @@ -4,14 +4,14 @@ Quantum Lock for QBITCOIN | Web3 Foundation Grants - +
    Skip to main content

    Quantum Lock for QBITCOIN

    • Team Name: BQP
    • Payment Address: 0x063c75324504D1595a972462A30A230d703f655e (ETH)
    • Level: 1
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    The application is for the new project, which introduces the Quantum Lock -- the proof of quantum work (PoQW).

    Overviewโ€‹

    We are developing an enhancement to the blockchain consensus protocol to enable it to run on a quantum computer. This enhancement allows an existing blockchain to be quantum enabled, and take advantage of the significant potential benefits that quantum computation promise to deliver.

    The most significant benefit is the potential to drastically diminish the energy consumption involved in a classical proof-of-work computation. As our Quantum Lock uses quantum computation with marginal energy cost that is only a fraction of its classical counter-part. (quantum computation is reversible and thermodynamically efficient, thus the expected marginal increase of energy usage of running quantum computation tends toward being comparatively negligible).

    Quantum computing is per se energy more efficient and energy consumption does not scale in the same way for classical computing. By some estimation, the reduction in energy consumption as result of processing data with quantum computing can be a factor of 10^-2 to 10^-3, which is huge. There will be competition in improving the ability to do quantum computing between the nodes but such competition cannot be trivially won by more brute force energy consumption. Consequently, we hope that there will be such a competition enabled by our protocol which can promote genial technological progress in quantum error correction, quantum circuit optimization and distributed quantum computation, which would in turn bring substantial positive impact in various domains. On the contrary, traditional PoW in many sense, unfortunately, has zeroed in on a pattern of destructive competition.

    The Quantum Lock is developed in Substrate and it will be utilised in the QBITCOIN. We aim to integrate the QBITCOIN with the rest of the Polkadot ecosystem, the way of integration (as an independent network with bridge or as a parachain) is to be determined. We are applying for funding in order to cover the initial development costs for the PoQW technology. Our team consists of several quantum algorithm researchers and quantitative finance specialists. The focus on blockchain and the implementation of quantum technologies is a natural fit for our product specialists.

    We chose this path as we realized that a quantum technology enabled blockchain can be energy efficient, as the nature of a proof-of-work can be radically changed with the application of quantum processors. This inspired us to develop the quantum lock and a blockchain ready for the quantum era. Being able to address one of the most pressing problems in blockchain is a major motivation for our work.

    Project Detailsโ€‹

    The Quantum Lock embodies the PoQW. The core of the PoQW is a Forrelation function which is, from the complexity-theoretic perspective, an optimal problem to separate bounded-error quantum polynomial-time (BQP), and the polynomial hierarchy (PH). Without detailing the formal definitions, the class BQP contains decision problems that can be efficiently solvable by a quantum computer within a bounded error. A problem separating BQP from PH can be thought of as the optimal problem to distinguish the capability of quantum from classical computers.

    The project focuses on the implementation of the mechanics of the Quantum Lock protocol. The complementary part of the project is the โ€œforgingโ€œ agent โ€“ the term forging is an analogy to classical mining with an iterative calculation of double hash function. The role of the mining agent is to efficiently perform iterative evaluations of the forrelation function such that the solution is found (see below for details). The calculation can be effectively performed using the quantum computer and this a separate stream of research work in our team. The Quantum Lock itself needs to evaluate the Forrelation function only once to verify the validity of the mined block. This task is achievable for any node with a standard computational resource.

    The first stage of our project aspires to implement the Forrelation function within the Substrate protocol and create a module that can be natively used. In the subsequent stages, we aim to incorporate the Quantum Lock protocol into a full PoQW consensus in a form of an independent blockchain QBITCOIN. We have separated the implementation of the Quantum Lock from the full protocol to stress the difference between the concept and its application.

    Furthermore, the Quantum Lock can be used in a more versatile way and the community could benefit from its independent application. As a complement to the Quantum Lock module, we will provide a wrapper for Python code which access Quantum Resources through Qiskit/Braket libraries. This will allow any Substrate user to easily access numerical modules with quantum subroutine and backends, and thus further stipulate the โ€œquantumโ€œ aspect within the Ecosystem.

    There is an alternative to the proof-of-work consensus protocol, namely do this off chain via offchain worker. This is intended as a further step, where would use the quantum work to serve as a proof of quantum authority (node has ability to perform quantum work). It will be certainly useful when thinking about quantum smart contracts and calculation of useful quantum tasks.

    Mathematical Background: Forrelation Functionโ€‹

    Let us consider two Boolean functions f1 and f2. The Boolean function is in the protocol represented as an array of binary of length nBit. The length of the array is

    nBit = 2 ^ nQubit

    where nQubit is the number of qubits, the parameter which drives the complexity of the problem. For nQubit, there 2^nQubit configurations of bits (and function can take 0/1 on every each of such configuration).

    The basic operation we need to do with the Boolean functions is to calculate forrelation. The forrelation is defined as

    forrelation = 0

    for i1=1,...,nBit for i2=1,...,nBit

    forrelation += b2PM(f1[i1]) b2PM(f2[i2]) (-1)**bXb(v2b(i1,nB),v2b(i2,nB))

    and the forrelation is normalised as

    forrelation=forrelation * 2 ^ (-3*nQubit/2)

    Further, b2PM(b) converts bit to +1/-1, and bXb calculates the dot-product of two bit arrays, which are obtained by function v2b (it converts the integer into bit array).

    The block is considered valid, if and only if:

    forrelation(f1,f2,nBit) within [target-precision;target_precision]

    inclusive the borders. We need to ensure that we use the fix precision of the numbers such that there is no inconsistency in the comparison.

    For forging the block, we need to have f1 and f2 such that the result is withing the allowed intrerval.

    For more references, see the QBITCOIN white paper.

    In order to incorporate the Quantum Lock into the blockchain protocol, we need to amend the information stored in the header. We need to include following items to the header (assuming that certain information is already there, like block id etc), the variables are mentioned in chronological order:

    • Hash of the previous blockโ€“ we use classical hash to refer to the previous block. We will use SHA512 (at least). This will ensure continuity of the chain. Type hexadecimal array of given length. Hash is calculated by double hashing. Hash is taken from the header (data are included through Hash of the Merkle tree).

    • Data โ€“ hash of Merkle tree of the transactions

    • Index of the block โ€“ integer, counting the blocks since genesis

    • Nonce โ€“ not needed (mentioned to stress out the difference to classical mining procedure). The function f2 plays a role of the nonce, the Quantum Lock forging protocol provides this piece of data

    • nBit โ€“ the number of bits to represent function with nQubits qubits used for a given block. This is an example of a value, which can be in the header but needs to be controlled by the protocol so miner cannot cheat. The verification of the block requires check of this value. nBit needs to be strictly smaller than nMax.

    • Precision โ€“ this value is provided by the protocol, it depends on the speed of forging over past the past history. The value can be stored in the header for reference, but needs to be verified by the protocol.

    • f1 โ€“ Binary array of length nMax, where nMax is the hardcoded parameter, which specifies the maximum number of qubits we consider.

      • The value is obtained as follows: Binary representation of the hash of the merkle tree (see data above) and the binary sum with the binary representation of the hash of the previous block. We consider last nBit bits of the array.

    • Target โ€“ The value which is target by forrelation the value is derived from the hash of the previous block โ€“ the link to previous block. Target is a number within (-a,a) interval, where a depends on nQubits.

    • f2 โ€“ Binary array of length nMax. Value forged for the quantum lock.

      • This value, together with f1, Target and Precision are basis of the Quantum Lock (this is a Quantum Lock analogue to nonce).

    • Time โ€“ the time at nanosecond level, when the block is published.

    • Hash-hash of the entire header. - This value does not need to be calculated nor stored, but this is the signature of the forged block.

    Remarksโ€‹

    The key variable determined by the protocol is the Target, which is to be aimed by the forrelation. The value depends on the nQubit. We set

    Target within [-1/2^nQubit;1/2^nQubit]

    The Target is obtained as follows:

    • Take the Hash of the previous block (hash and hash). The Hash is represented by nHash bits.

    • Split the interval [-1/2^nQubit;1/2^nQubit] into (2^nHash)-1 equidistant intervals and thus 2^nHash points, where the smallest one is -1/2^nQubit and the largest one is 1/2^nQubit.

    • The Target is then found by matching the grid point within the interval with the Hash value (when the binary representation converted to integer).

    The genesis block starts with nQubit0. The nQubit can be increased over time. The nQubit never goes down. The nQubit determines the Era of the protocol.

    Forrelation Parametersโ€‹

    Our team is in parallel conducting a research around to assess the parametrisation. In particular, the number of qubits is the leading parameter and will lead the divergence between quantum and classical computer performance.

    Technology Stackโ€‹

    UI Frontendโ€‹

    • A UI forks from the substrate frontend template with a new quantum style theme, used for visualization transactions and block information, add an extra visualization panel for quantum information.

    Blockchain Backendโ€‹

    • Adding a new consensus mechanism called QPoW (Proof of Quantum Work), it will be built as a substrate frame pallet that can be used in all the parachains and even Polkadot.

    • Building a blockchain node client based on substrate framework and PoQW with some modification to the block heads, which can run as an independent chain or a parachain in Polkadot ecosystem.

    • Adding more functions to RPC-API to implement the interaction between the node client and quantum forrelation solver backend.

    Forrelation Solver Backendโ€‹

    • Focusing on the forging part (solving the forrelation problem), built as an independent program.

    • Offering an RPC-API which gives access to forrelation solving ability on quantum computers. It can be used by the PoQW consensus pallet and any other program that needs a forrelation solver.

    • Implementation:

      • Classical solution: an algorithm can be run on a classic computer as a fallback solution when there is no quantum computer available. In the case of classical resources, we consider:

      • Amazon bracket solution: a forrelation solver implemented on the Amazon bracket system.

      • Qiskit solution: a forrelation solver implemented on the most widely used open-source quantum computing library which also contains adapter to many popular quantum computing systems like IBM Q.

    DevOps Pipeline for Scaling Clusters with Quantum Computersโ€‹

    • Building a devcontainer for developers, which can offer a stable rust development and quantum computing environment.

    • Dockerfiles and Scripts used for deploying and scaling clusters with quantum computing on IBM Cloud and AWS.

    Ecosystem Fitโ€‹

    Our project is based on Substrate. We use the modularity of the framework to build all the elements we need to end up with the layer using the proof of quantum work โ€“ the QBITCOIN. In addition, we aim to keep the blockchain connected with the rest of the ecosystem (the best way is to be determined, either to aspire to become a parachain or through bridges). The PoQW and concepts of quantum computation can enhance the entire ecosystem, making Substrate/Polkadot the first truly quantum enabled block chain.

    The primary audience are the users of the QBITCOIN, which is a blockchain on its own. We do however anticipate in the next iterations to deploy the Quantum Lock across different applications (bridges, for instance).

    Firstly, our project introduces the proof of quantum work and thus bridges the abrupt development in the quantum computing with the blockchain. Across the board, every industry is preparing for the adoption of quantum computing and the Quantum Lock is doing this task for the Polka ecosystem. Once the PoQW is deployed, the quantum resources can be further extended and used across (quantum) smart contracts. Secondly, the Quantum Lock gives an extra protection to the consensus against the adversarial quantum miners as the Quantum Lock scales with the growing quantum power and keeps it is proof of work integrity. Last but not least, the application of Quantum Lock and PoQW paves a way to significantly ameliorate the carbon footprint of classical PoW, since it is energy efficient and de facto serves as a proof of quantum authority rather than burning protocol burning significant amount of global available energy.

    Existing projects with quantum computing focus on quantum security, mainly using the lattice cryptography algorithm. Our approach is different, as we focus on integrating quantum technology with the consensus protocol itself. In addition, the Quantum Lock aims to create an economic activity for available quantum resources, which will in turn stimulate the continue development of the quantum computing industry, thus creating a desirable positive feedback loop. The ecosystem that adopts quantum resources early will first and for most enjoy the spring of opportunities coming with the dawning the quantum era.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    • Registered Address: N/A
    • Registered Legal Entity: (the legal entity will be specified in the coming weeks)

    Team's experienceโ€‹

    bqp1: Blockchain dimension, blockchain development, Substrate/Rust, distributed databases.

    bqp2: Quantum dimension, quantum computing, algorithms for use in financial trading using near term quantum processors.

    bqp3: System dimension, quantitative trading development, machine learning.

    bqp4: Commercial dimension, front office trading, quantum computing ventures.

    Team Code Reposโ€‹

    Our team repository is just being built up and we do not have anything in public domain yet.

    Development Status ๐Ÿ“–โ€‹

    The Quantum Lock project is in its development infancy from the Rust perspective. We have been focusing so far on the Quantum Computing side, where we have done extensive research in Qiskit/Braket framework (as part of this project, we will provide Rust wrappers to the Python functions accessing quantum resources, which will open the quantum resources to the Rust/Substrate community beyond our project).

    We have discussed the project with Polkadot team and we have been encouraged to apply for this project to start building the POC and implement the chain with proof of quantum work (QBITCOIN).

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1.5 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 10,000USD (ETH)

    Milestone 1: โ€” Implement Quantum Lock Substrate Modulesโ€‹

    • Estimated duration: 1 month
    • FTE: 2
    • Costs: 7,000 USD
    NumberDeliverableSpecification
    0a.LicenseFollow Substrate
    0b.DocumentationThe functionality will be documented in the code. In addition, we add detailed README and link it to the white paper.
    0c.Testing GuideForrelation and the adjoint functions will be covered with unit tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.White paperWe extend the existing White Paper we have with cross references to the code, which can also serve as complementary documentation.
    1.Substrate module: ForrelationThe Substrate module will be responsible for the calculation of the Forrelation function and management of the data structures.
    2.Substrate module: Quantum LockThe subsequent Substrate module will utilise the Forrelation module and implements the proof of work based on the Forrelation as described above.
    3.Substrate chainWe develop the basic framework to implement the consensus mechanism based on the Quantum Lock. The objective is to have a POC.

    Milestone 2: โ€” Quantum Computing Librariesโ€‹

    • Estimated duration: 0.5 month
    • FTE: 2
    • Costs: 3,000 USD
    NumberDeliverableSpecification
    0a.LicenseFollow Substrate
    0b.DocumentationThe White paper refers to the algorithms, which utilise the Quantum Computing (real QPU or simulators) to efficiently calculate the Forrelation.
    0c.Testing GuideFunctions will be tested through unit tests.
    0d.Docker/gitThe code will be part of the repository. Some of the routines requires login to resources (Qiskit, for example, offers free access to simulated resources, but personal account needs to be created) and thus the vanilla Docker may not be applicable (user provided config files may be needed).
    0e.White paperPart of the White paper refered above. The quantum routines are not important for the Quantum Lock itself, but they are important for the process of forging (mining using the proof of quantum work). We thus complement the Milestone 1 with these routines. In addition, this will bring the โ€œquantumโ€œ to the Substrate.
    1.Substrate module: Quantum Resource AccessWe provide a module using Foreign Language Interface PyO3 to wrap the Python functions, which are responsbile for managing and accessing the quantum resource. This module will have a complementary Python repository, which will hold the body of the functions.
    2.Substrate chainThis module complements the chain POC outlined above.

    Future Plansโ€‹

    Our long-term plan is to implement the full blockchain based on the proof of quantum work. We use Substrate to be able to bridge to other protocols. The Quantum Lock can be used across different projects and we consider this is a first step to bring the quantum computation into the blockchain โ€“ utlimately, we envisage the creation of the Quantum Smart Contracts, where Quantum Computation will be available through the contract.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Meeting with Parity team, who recommended us to join this programme. We have been admitted to bootcamp programme organised by Outliers Venture.

    - + \ No newline at end of file diff --git a/applications/rb_substrate_client.html b/applications/rb_substrate_client.html index b85e27fbc5b..da449b490cc 100644 --- a/applications/rb_substrate_client.html +++ b/applications/rb_substrate_client.html @@ -4,13 +4,13 @@ Ruby Substate Client | Web3 Foundation Grants - +
    Skip to main content

    Ruby Substate Client

    • Team Name: UNI-ARTS
    • Payment Address: 0xE7188c7e225D473eE9D99108482Af54952d71527 (USDT)
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Ruby Substate Client will support a efficient way to interface with substrate chain with ruby.

    This library will provide convenience methods to deal with SR25519, ED25519 sign and verify message.

    Encode/Decode the chain message, submit the sign message to chain by rpc.

    Through this grant, we hope to

    1. SR25519, ED25519 support.

    2. Submit sign extrinsics to chain.

    Project Detailsโ€‹

    1. Develop SR25519 gem.

    2. Develop rpc gems inlcude submit extrinsics and batch submit extrinsics.

    Apisโ€‹

    • SR25519.keypair_from_seed(seed)
    • SR25519.sign(message, keypair)
    • SR25519.verify(address, message, signature_result)
    • ED25519.keypair_from_seed(seed)
    • ED25519.sign(message, keypair)
    • Ed25519.verify(address, message, signature_result)
    • RbSubstrateClient.submit_sign_extrinsics(params, keypair)
    • RbSubstrateClient.utility_batch_submit(params, keypair)

    Technology stackโ€‹

    Ecosystem Fitโ€‹

    Similar projectsโ€‹

    https://github.com/polkascan/py-substrate-interface

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Xuxiaohu: full-stack developer
    • Tuminfei: architecture and blockchain consultant

    Contactโ€‹

    • Registered Address: 3 FRASER STREET #05-25 DUO TOWER SINGAPORE (189352)
    • Registered Legal Entity: UNI-ARTS FOUNDATION LTD.

    Team's experienceโ€‹

    The team is familiar with Ethereum and Substrate development.

    Xuxioahu Technical expert in blockchain and web development, has been using golang development since 2015 and ruby development since 2010. Has experiences of EVM smart contract technology and blockchain browser.

    Tuminfei is the architecture and blockchain consultant of Uniscan team. He has rich experience in the field of software development, especially in blockchain. He has implemented many projects as a leader. He is familiar with the development of Ethereum and Substrate. He is also a major maintainer of the UniArts chain.

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    Much of the technology is already implemented app.uniarts.network. But now the code is in the project, not written as a library. and it needs more tests. We expect that we can refactor, reuse and generalize existing code. write gems to help other ruby developers.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4 weeks
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 8,000 USD

    Milestone 1 โ€” SR25519/ED25519 sign verify messageโ€‹

    • Estimated duration: 2 weeks
    • FTE: 2
    • Costs: 3,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that run the code, which will show how the new functionality works.
    0c.apiWe will provide SR25519.keypair_from_seed(seed), SR25519.sign(message, keypair), SR25519.verify(address, message, signature_result), ED25519.keypair_from_seed(seed), ED25519.sign(message, keypair), ED25519.verify(address, message, signature_result)
    0d.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0e.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.

    Milestone 2 โ€” Submit sign extrinsicsโ€‹

    • Estimated Duration: 2 weeks
    • FTE: 2
    • Costs: 5,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.Documentation1. We will provide both inline documentation of the code.
    0c.apiWe will provide RbSubstrateClient.submit_sign_extrinsics(params, keypair), RbSubstrateClient.utility_batch_submit(params, keypair)
    0d.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0e.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    And, It will be used to run the server.

    Future Plansโ€‹

    • Support load the key from json file
    • Support load custom_types
    - + \ No newline at end of file diff --git a/applications/research-feasibility-go-runtime.html b/applications/research-feasibility-go-runtime.html index fe2ad934502..fd254ba750c 100644 --- a/applications/research-feasibility-go-runtime.html +++ b/applications/research-feasibility-go-runtime.html @@ -4,7 +4,7 @@ Research feasibility of a Go Runtime | Web3 Foundation Grants - + @@ -34,7 +34,7 @@ Theoretically, it might be possible to add support for it in TinyGo, but it will require a lot of effort in the long term, the support would be limited and performance might be unsatisfactory. To support an automatic memory management, the GC proposal would be handy. But the Wasm runtime supports only WebAssembly MVP currently, and the GC proposal is under development.
  • The standard library support in TinyGo is limited

    • Development Roadmap ๐Ÿ”ฉโ€‹

    Described below are the steps we think are necessary to get a deep understanding of how the current technical challenges we have found so far can be overcome:

    1. Go internals, runtime, memory allocation, garbage collection
      1. Get a deep understanding of how internals, runtime, memory allocation and garbage collection works in Go.
    2. WebAssembly GC proposal
      1. Thoroughly research the GC proposal for WebAssembly, such as its design and progress so far.
    3. Research TinyGo or alternative compiler toolchain in Go for the following addition of:
      1. How it works
      2. Features support
      3. Wasm support
    4. Build a PoC
      1. Manual memory allocator, Go compiler Runtime implementation
    5. Propose a specification, based on the previous steps

    Overviewโ€‹

    Milestone 1 โ€” Research feasibility of a Go Runtimeโ€‹

    This milestone will

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide Markdown documentation of the whole research, explaining the necessary steps needed to resolve the technical challenges for Polkadot Runtime implementation.
    0c.Testing GuideWe will provide a testing guide of the PoC manual memory allocator via FFI
    0d.DockerWe will provide a Dockerfile(s) that can be used to test the PoC.
    1.ResearchWe will start our research with Go internals, runtime, memory allocation and garbage collection.
    2.ResearchWe will continue our research with the WebAssembly GC proposal - check progress so far.
    3.ResearchWe will go through intensively TinyGo or an alternative compiler toolchain.
    4.ResearchWe will try building a PoC, including a manual memory allocator, and a Go compiler Runtime implementation.
    5.DocumentationWe will provide Markdown documentation, based on the previous steps.

    Future Plansโ€‹

    Having this research will give us clear understanding of how the technical challenges that Go has for Polkadot Runtime implementation can be resolved. By resolving them, Go will become an alternative language to Rust for Polkadot Runtime implementation.

    Additional Information โž•โ€‹

    LimeChain has been a long-time contributor to the Substrate ecosystem mainly focused on developer tooling. Due to our involvement in the space, we are working with various clients, developing smart contracts and working on parachains.

    - + \ No newline at end of file diff --git a/applications/research-feasibiliy-java-host.html b/applications/research-feasibiliy-java-host.html index 9ea815c3b14..93b754c7bca 100644 --- a/applications/research-feasibiliy-java-host.html +++ b/applications/research-feasibiliy-java-host.html @@ -4,7 +4,7 @@ Java Host Research Proposal | Web3 Foundation Grants - + @@ -64,7 +64,7 @@ will become the foundational block for the creation of the Java-based Host which would be the next step for the team after delivering this research.

    Additional Information โž•

    LimeChain has been a long-time contributor to the Substrate ecosystem mainly focused on developer tooling. Due to our involvement in the space, we are working with various clients, developing smart contracts and working on parachains.

    - + \ No newline at end of file diff --git a/applications/roloi-xcm-payment-automation.html b/applications/roloi-xcm-payment-automation.html index 3620bd64a74..c4c4e8bc404 100644 --- a/applications/roloi-xcm-payment-automation.html +++ b/applications/roloi-xcm-payment-automation.html @@ -4,14 +4,14 @@ Roloi - XCM Payment Automation | Web3 Foundation Grants - +
    Skip to main content

    Roloi - XCM Payment Automation

    • Team Name: NeoPower Digital
    • Payment Address: 1dz667uQX199rHyj6tizmL6EJe4AZxjH1RhnyrT1QuQ4pfS (Polkadot - USDT)
    • Level: 3

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    We are NeoPower, a Web3 software company. We are currently building a payment automation platform called Roloi.

    Last year we received a W3F Grant for the migration of our Streaming Smart Contract from Cosmos to Polkadot. We talk about this migration journey in a Medium Article.

    Roloi is based on three automation pillars:

    • Token streaming
    • Recurring payments
    • Conditional payments

    As a next step for Roloi, we are going to build the recurring payments feature.

    Roloi can achieve this by avoiding off-chain mechanisms thanks to OAK Network: the automation parachain.

    Project Detailsโ€‹

    Goalโ€‹

    Automate ink! smart contract transactions in a recurring way.

    How to achieve itโ€‹

    We need to notify our Smart Contract deployed on Shiden (Astar) whenever a scheduled transaction should be executed.

    XCM enables us to connect parachains. This way, we can schedule transactions on Shiden (Astar) with the assistance of Turing (OAK).

    Technical detailsโ€‹

    Creating products using XCM implies a complex journey today. Here is an example between Astar and OAK:

    W3F Grant - XCM Payment Automation

    There are some DX/UX issues while building products with the out-of-the-box approach:

    • The process to enable the connection between chains requires the configuration of Proxy Accounts on both chains.
    • Users have to manually top up their Proxy Accounts in order to allow them to pay for fees to act on their behalf.
    • XCM messages are complex to understand and generate.
    • Managing on-chain recurring transactions is always a complex task.
    • Polkadot.js is great for low-level development, but hard to use for user-oriented products.

    Our solutionโ€‹

    Our deliverable will include a Next.js UI and an ink! smart contract to create recurring transfers leveraging XCM features.

    The included features on the Next.js UI are:

    • โœ… Wallet connection
    • โœ… 1-click proxy accounts setup
    • โœ… Recurring payment creation
    • โœ… Incoming and outgoing payments section
    • โœ… useink() library

    For devs:

    • ๐Ÿ’ป Our own useful hooks and reusable abstractions in Typescript to encapsulate tasks such as:
      • Creating proxy accounts on both sides
      • Depositing funds into these accounts to cover fees
      • Wrapping the recurring transaction to be executed via Astar Proxy Account
      • Transmitting the recurring task configuration via XCM & HRMP
    • ๐Ÿ’ป ink! smart contract example used to trigger payments
    • ๐Ÿ’ป Recurring payment data model

    Some hook examples: W3F Grant - XCM Payment Automation - Hook examples

    This project will be generic and open source to serve the Polkadot builders community as a public good that teams can use to automate transactions leveraging cross-chain features.

    This will make building with XCM fast and simple.

    Wireframesโ€‹

    Wireframe

    Ecosystem Fitโ€‹

    This project is a public good for the Polkadot Builders community. For NeoPower, this will be a great experience since all of this work will give us more traction to grow Roloi.

    Our intention is to provide a generic and open-source project that can be the starting point to many real use cases of cross-chain payments using XCM.

    The code will be backed with robust and clear documentation. This will allow our platform to be easy-to-use and effortlessly scalable.

    We also plan on publishing a Medium Article to share our experience developing with XCM.

    At NeoPower, we are always contributing to the Polkadot Spanish community with educational content:

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    We are NeoPower, a Web3 software company. Our core team members:

    • Brian Sasbon (Co-Founder & CEO)
    • Pablo Corrado (Co-Founder & CTO)
    • Hernรกn Hermida (CGO)

    Contactโ€‹

    • Registered Address: Pacheco 2131, CABA, Buenos Aires, Argentina (CP1431)
    • Registered Legal Entity: NeoPower Digital, LLC

    Team's experienceโ€‹

    Foundersโ€‹

    We are Brian and Pablo, Software Engineers with a Degree from the National Technological University (UTN) from Buenos Aires, Argentina, and have more than 10 years of experience as developers for many different projects. We have strong experience working as Full-stack Developers and Team Managers for US traditional finance clients like Morgan Stanley, Visa, and JP Morgan.

    6 years ago we founded NeoPower, our own software company to work for different clients building freelance teams of designers, developers, and testers.

    We are building Roloi, a payment automation platform to enable on-chain payment flow automation in Astar. Our project was supported with a first grant from the Web3 Foundation.

    CGOโ€‹

    Hernรกn S. Hermida (aka Milstein) is a DeFi Researcher with more than two years of experience contributing to educational communities in Latam. Currently, he hosts #DeFiSpace, a weekly Twitter Spaces cycle, with more than 50 episodes, interviewing builders from different multi-chain projects, and creates content for โ€œLa Multisigโ€, a web3 educational YouTube Channel with its community.

    Heโ€™s the growth lead of DeFi Argentina a non-profit project that helps childrenโ€™s food banks in Argentina by collecting donations in cryptocurrencies.

    Heโ€™s also been an OAK ambassador since Nov 2022.

    Hernรกn is part of the Roloi team as CGO to help with the growth, research, and networking strategy, leveraging his knowledge about DeFi and communities.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2.5 months
    • Full-Time Equivalent (FTE): 3
    • Total Costs: $ 52,500

    Milestone 1 - UI on Rococo Testnetโ€‹

    • Estimated duration: 1.5 months
    • FTE: 3
    • Costs: $ 31,500
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a general tutorial for the user to understand how to use the dApp and technical documentation of the main functionalities.
    0c.TestingTo guarantee robustness, the main functionality will be covered by unit tests.
    1.UIAs expressed in the Project Details section, we will provide a Typescript Next.js Web App that includes key abstractions to simplify the developers' work when using XCM and connecting parachains. The scope of this UI includes connection to the Rococo Testnets of Astar & OAK and chain native token transfers. Libraries to use: Polkadot.js & useink.
    1a.React XCM toolingWe will provide reusable React hooks, generic components, state management and types to facilitate the creation and top-up of Proxy Accounts, and execution of XCM (v3) messages.
    1b.Home pageThis page will handle the wallet connection and will show the app dashboard.
    1c.Create a Recurring Payment PageOn this page, the user will be able to create recurring transfers using the previously defined XCM flow. The most tricky part of the process will be transparent for the user.

    Milestone 2 โ€” Smart Contract and Kusama Connectionโ€‹

    • Estimated Duration: 1 month
    • FTE: 3
    • Costs: $ 21,000
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will iterate the existing documentation to include the new functionalities.
    0c.TestingTo guarantee robustness, the main functionality will be covered by unit tests.
    0d.ArticleWe will publish a Medium Article about our development experience with XCM.
    1.UIWe will add the connection to the Kusama chains of Astar and OAK.
    1a.My Payments PageA page to show all the incoming and outgoing payments of the connected user.
    2.Smart ContractAn ink! smart contract that stores all the payment flows and monitors the security of the assets. All the token transfers will occur in Shiden. This enables transfers of non-native tokens.
    2a.Transaction - Configure new recurring transferWe will provide a message to configure a new recurring transfer between Shiden accounts.
    2b.Transaction - Modify the configuration of a recurring transferWe will provide a message to modify an existing recurring transfer between Shiden accounts.
    2c.Query - Get user recurring transfersWe will provide a message to get all the incoming and outgoing recurring transfers of the connected user.
    2d.Transaction - Execute a transferWe will provide a message to execute a transfer related to an existing recurring configuration. It will be triggered by the OAK scheduler, and the contract should validate the time according to the existing configuration.

    Future Plansโ€‹

    • Automate cross-chain token transfers.
    • Include conditionals to the transfers.
    • Scale this automation platform according to the ecosystem needs.
    • Integrate this code to Roloi to schedule payment flows.

    Additional Information โž•โ€‹

    We heard about the Grants Program through Twitter, and through personal recommendations from Parity developers we decided to apply.

    Links:

    - + \ No newline at end of file diff --git a/applications/rv-kmir.html b/applications/rv-kmir.html index 4ab540f83f3..4f6984b2779 100644 --- a/applications/rv-kmir.html +++ b/applications/rv-kmir.html @@ -4,7 +4,7 @@ KMIR: the K semantics of MIR | Web3 Foundation Grants - + @@ -58,7 +58,7 @@ These lack the completeness that "ships for free" with program verification tools such as the K Framework. Runtime Verification has successfully applied the techniques presented in this proposal to several projects, including other blockchain language semantics such as EVM, Plutus, and AVM. We are confident that the tooling resulting from this project, should it be financed, will be an important contribution to the Rust community, being a sound, complete and effective approach to Rust program verification.

    - + \ No newline at end of file diff --git a/applications/saito-game-protocol-and-engine.html b/applications/saito-game-protocol-and-engine.html index 47fec0a1bb6..86af5d79145 100644 --- a/applications/saito-game-protocol-and-engine.html +++ b/applications/saito-game-protocol-and-engine.html @@ -4,7 +4,7 @@ Saito Gaming Protocol and Library | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Saito Gaming Protocol and Library

    • Proposer: @trevelyan (David Lancashire)
    • Payment Address: bc1qvx6wzyxsjw5yza5f7qj4mprzj4hl49q9js0d46

    Project Overview: Introduction to Saitoโ€‹

    Saito is a data-network that allows developers to write web3 applications that run inside browsers. Our network is similar to a blockchain in the sense that it does not need an owner to pay for its servers. Where Saito differs from traditional blockchains is that it does not have miners or stakers or validators and does not have a permanent ledger.

    This can make Saito confusing on first encounter. The network has some of the properties of a layer-one blockchain, but it is also a transient broadcast layer. Our community is building chat, email, gaming and other web3 applications, but these applications need to integrate with other blockchains when they want to add asset-transfer and smart contract functionality. When it comes to the rest of the blockchain space, Saito's role in the ecosystem is basically bringing the throughput and cryptographic tools to shoulder the burden of handling off-chain data flows, and generating fee-bearing transactions for other blockchains (or parachains) where permanent on-chain transactions are required.

    Because of this, the most similar thing to Saito in the cryptocurrency space is metamask. Both allow developers to write applications that run in web-browsers and use blockchains. The difference is that metamask relies on Infura to provide a network while Saito provides one that pays for itself. The Saito approach is superior because it is an open network layer that cannot be privatized. And it elegantly pays for user-facing network infrastructure without the need for IFPs or corporate subsidies. Saito is also blockchain agnostic in the sense it can be deployed as a UI-layer without the need for the underlying blockchain if network operators are willing to accept zero-fee transactions.

    We believe that as Saito continues to grow developers will look at applications like the Saito Arcade and embrace this method of developing web3 applications. To make the applications our community is building truly web, we need our platform to be able to interact with Polkadot and its parachains so that Saito applications can send-and-receive NFTs and other financial assets. To use the metamask analogy above, this is essentially the step where we add ETH support and our community starts to incorporate money-functions directly into their games and other applications.

    This proposal outlines how we would like to accomplish this. Our goal is to increase the power of Saito as a metamask-layer by enabling our applications to interact with the non-transient ledgers provided by Polkadot and its parachains. To make sure this delivers value to the Polkadot ecosystem, we propose to start by integrating the gaming applications that are driving double-digit monthly growth on our platform. We believe this will be a win-win move. Polkadot will gain gaming traffic and transaction volume, while Saito users can start deploying parachains and transferring financial assets across them directly in their browsers.

    Overviewโ€‹

    To accomplish this in a manner that will attract developers, we propose integrating Polkadot and Polkadot parachains with the web3 games that are driving growth in our community. We believe this will help both projects. About eighty percent of Saito transaction volume is coming from online gaming, so this is a practical area where we can deliver transaction growth and developer attention to Polkadot along with a new class of gaming applications. Having Polkadot integration and the ability to interact with NFTs and parachains meanwhile makes Saito more compelling as a user-facing network layer.

    To understand how Polkadot can benefit from integration with an open web3 gaming library, let us briefly explain what it is that we are building. Historically, most "blockchain games" in the industry use blockchains to deposit and withdraw money, hold random number lotteries, or to manage NFTs that represent in-game assets (weapons, land, etc.). These use-cases require blockchains to serve as a holder of financial assets. The standards for how these assets are created and managed on-chain are best defined by POLKADOT developers and is not the sort of standard we are discussing. Substrate can simplify the process of deploying these tremendously.

    The standard we are building concerns how to define the language of game moves in sequence. To make this clearer, understand that in the games that developers are building on Saito, players broadcast moves to each other and execute them in parallel from a stack of gaming instructions that are kept synchronized via the metamask-like network. This approach eliminates the need for middlemen like Steam to connect users or control gameplay, while it enables cryptographic techniques like "mental poker"12 to be used to ensure provably-fair deck shuffling, dice rolls and other core game functions.

    We already have over a dozen sophisticated games that people can play that adopt this approach: sharing moves between players and executing them in parallel in the browser of each player. These games use an open protocol we have been developing that define how game moves should be broadcast and executed in browsers. This protocol (instantiated in a supporting library) removes the need for developers to implement common techniques like deck-shuffling, random number generation, card deals and otherwise complicated tasks like simultaneous moves. It is important to note that this protocol and library are chain-agnostic: while the games our community are building are deployed atop Saito, it is possible to deploy them on other blockchains or even non-blockchain peer-to-peer networks.

    Integrating NFT and asset-transfer functionality means expanding this protocol so that in additional to handling shuffling, turn-management and those sorts of common cryptographic operations, it also provides ways for developers to transfer in-game assets on Polkadot simply by broadcasting a game move. In the next section we provide more details about how our web3 protocol standard and reference implementation works in order to make it clear why this is necessary and the benefits it will bring to the web3 ecosystem. Section IV then outlines how we will deliver it in three stages spread across two months. Section V closes this proposal with examples of real applications that already exist - making it clear we are talking about solving practical problems that deliver applications that will be immediately able to interact with Polkadot and benefit from parachain deployment.

    Project Detailsโ€‹

    The overarching goal of having a protocol and reference game library is simplifying Web3 game development by creating a standardized method for describing common game moves that can be executed in parallel on different user computers rather than in smart contracts managed by a central blockchain. The reference library is also needed so developers can build games with it directly or consult it as a reference tool when tackling similar problems or porting games between networks by developing competing reference implementations.

    To make it clear what we are talking about and why it is important, let's start by describing a practical problem common to many games - the need to shuffle a deck of cards and deal them out to many players. In a typical game, this is handled by custom code or the use of closed game-engines that don't play nicely with the open web3 ecosystem.

    In the stack-powered development method, a developer that wishes to have cards dealt to a player needs only add a single instruction to the game stack. This can be done by broadcasting the move to all other players in the game who add it to their respective stacks on receipt of the move. As an example, the following command instructs the game engine to DEAL a total of 5 cards from card deck 1 to player 2:

    DEAL 1 2 5

    When this command is executed in parallel on all player computers, the underlying game engine takes over, adding sub-moves to the stack that prompt players to send player 2 the necessary keys they need to decrypt the 5 cards they are pulling from the deck. Control then passes to the next instruction on the stack, which may prompt player 2 to select one of their newly issued cards, or perhaps discard two cards and then re-shuffle the deck. Each game is obviously unique: the point of the protocol (and supporting library) is to eliminate the need for developers to touch the underlying cryptography and let them focus on game-specific UI and logic.

    The starting point for a robust gaming protocol / engine is:

    • shuffling cards (game assets)
    • dealing cards to players (private)
    • dealing cards to piles (public)
    • moving into a player turn
    • rolling-dice (secure random number)
    • simultaneous card-selection
    • simultaneous game moves
    • player alerts and log management

    While the protocol can ultimately be ported to any language, our starting place is javascript (NodeJS) as browsers provide the UI for most web3 blockchain games, and this is what our developers are building and where they need integration with permanent ledgers like Polkadot and its parachains.

    Our work on developing this library and adding features is ongoing: at present our standard handles somewhere over half of these requirements. Features tend to get added as games are added which need them, and documentation is developed after the fact. To simplify Polkadot integration, we will prioritize implementing the remainder in a standardized javascript (NodeJS) implementation that is well-documented, has an intuitive API with non-ad-hoc naming conventions ("DEAL", "SHUFFLE", "ROLL") that is available under a flexible open-source license. This will enable games and web3 development to occur across multiple blockchains and networks. \

    Our proposal begins with the next step: extending this open standard to add commands that let developers programmatically handle blockchain / asset / NFT transfers within games as well as the in-game moves it already supports. Just as the gaming protocol / library permits developers to trigger a deal or shuffle a deck, so must it support users making deposits, confirming receipt of assets and/or NFT tokens, transferring them to other players, or otherwise engaging with assets on external ledgers. This functionality is needed both within gameplay as well for industry-focused cases such as letting users prove that they have purchased a game or handling real-time payments to game publishers on game creation.

    The protocol needs to support the following use cases that should be provided by permanent ledgers:

    • checking account balances
    • sending tokens to accounts
    • confirming receipt of tokens

    Adding asset-transfer commands into the game engine will create a powerful backend that can be deployed across different parachains (no user or developer lock-in) and permit integration between asset-transfer networks and the high-throughput web 3.0 data services supported by the metamask-layer. The game library meanwhile abstracts away everything that is difficult about on-chain game creation.

    Adding these features will also web3 games to support use cases like: ensuring users pay the game publisher prior to being able to play the game, in-game transfers of funds or NFT assets between players depending on what happens in gameplay. There are many use-cases where a large gaming community or tournament may even want to create a dedicated parachain to manage ranked-games, leaderboards, buy-ins and payouts and more.

    Our goal building this is encouraging third-party developers to roll out more games using open standards, raising awareness of the power of blockchains for on-chain gaming via the Web3 Foundation and taking part in the shift that is coming from centralized to decentralized gaming networks. Funding is sought to justify prioritizing resources on Polkadot integration and make sure we can devote the needed time to apply polish to the documentation and other developer-focused assets so the library/engine can be of use to external developers.

    Ecosystem Fitโ€‹

    Saito is deeply committed to web3 and our stack is focussed firmly on helping make it simple for developers to bring truly decentralized applications, on line automomy and new business models to users. Adding the ability to interface with parachains, as a bridge to the Polkadot ecosystem opens up a world of financial and other tools to those developers, and provides developers working in or interested in the Polkadot ecosystem a fast simple way to get started. Gaming is the perfect proving ground for this.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • David Lancashire
    • Richard Parris
    • Clayton Rabenda

    Team Websiteโ€‹

    Proclus Technologies Limited. 1101 299QRC, 299 Queens Road Central, Hong Kong.

    Team experienceโ€‹

    Saito's founders have both worked leading development and broader IT teams in China for over 10 years. The team has worked on projects in a variety of fields, and are all early 'cyrpto adopters'.

    Team Code Reposโ€‹

    Saitoโ€‹

    Non-Saito Cryptoโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 8 Weeks
    • Full-time equivalent (FTE): 1.5 FTE
    • Total Costs: 1.65 BTC

    Milestone 1 โ€” Saito Polkadot API Moduleโ€‹

    • Estimated Duration: 3 Weeks
    • FTE: 1.5
    • Costs: 0.9 BTC
    NumberDeliverableSpecification
    1.Saito ModulePolkadot module that allows Saito applications to connect to a Polkadot API access point to send / receive network Polkadot data. This module would be the equivalent of "metamask" application for all of the existing games and applications already running on Saito. It would run fully in-browser.
    2.DocumentationInline documentation and published how to guide.
    3.Environment BuildBuild and test environment containing Polkadot node and Saito Stack.
    Test interoperability and benchmark performance.
    Document configuration, deployment and management.
    Deploy against public test net.
    4TutorialDeveloper tutorial showing how applications can integrate with Polkadot module on a base-level (i.e. without the need for use of the gaming API layer), making Polkadot a first-class citizen for all Saito Web3 applications and allowing all of them to send and receive payments in DOT.

    Details:

    The point of building this module first is to have a set of local API functions that our own communications stack can use when the open game library needs to make API queries to the external Polkadot chain. Relying on local interface simplifies the coding of the game library so that networking and chain-specific connection information can be abstracted away. This is critical for keeping the game library cross-chain portable, ensuring that it will run on any blockchain or parachain, and removing the need for the game library itself to handle networking code.

    A side-benefit of building this module first is that Polkadot and parachain tokens become A-class citizens on the Saito network. Getting this module written and documented first allows all games and other (non-stack) developer applications to send and receive Polkadot. Polkadot or parachain developers who want to port or hack any existing Saito applications will be able to do so while having the application handle their own native token.

    A plug-and-play Saito module will also simplify building UI components and web applications for Polkadot that monitor or interact with the chain through an API-access point. Getting this functionality out first allows us to reach out to the Polkadot community with an immediately-useful solution for certain classes of Web3 application-development work. \

    Timeline Notes: Three weeks should be adequate for building and documenting this module, as well as putting together a tutorial demonstrating how independent Web3 modules can make API requests and check account balances. Part of this work will obviously require setting up and running API infrastructure so we can make the process as painless as possible for developers, etc.

    Milestone 2 โ€” Asset Transfers in Gaming Protocolโ€‹

    • Estimated Duration: 3 Weeks
    • FTE: 1.5
    • Costs: 0.75 BTC
    NumberDeliverableSpecification
    1.Protocol and Library UpgradeToken-specific transfer instructions added to game engine / protocol.
    Code addig Stack-based instructions for applications adding the following common game mechanics:
    • player Y deposits assets
    • player Y sends assets to player X
    • player Y requests balance
    2.DocumentationInline and published documentation of library extensions.
    3.GameProvision of at least a single open-sourced game demonstrating the features.

    Details:

    Combine the previous API work with the game protocol work to add financial asset transfers and payment functionality into the underlying protocol and game engine. This will be entirely new functionality. It will allow developers to do things like check that payments have been made prior to gameplay or send and receive assets during play.

    We suggest the creation of a "play-for-charity" game to demonstrate the required financial use-cases (players deposit tokens, players send those tokens to each other and in case of loss send the funds to a charity) without the need to worry about legal issues surrounding gaming. Another idea might be a game that requires players to submit proof-of-payment to be permitted to play the game.

    Regardless, this work is done last as it builds on the experience of both the initial Polkadot module, as well as the work expanding and systematizing the protocol. Since in some ways it is the most interesting part of the project, we also want to leave it for last so that the community will be aware of the work being done and ideally come in with suggestions on which games to port and which particular features to focus on first.

    Timeline Notes:

    We expect it to take about four weeks to do this work. Two weeks are probably sufficient for the initial protocol and game library work. We will need to add another two weeks to get a workable / fun game built that demonstrates the functionality and has enough polish and design work done that it feels like more than a playable tutorial. We hope to get a sense of the best sort of game to build by talking with other gaming projects in the Polkadot ecosystem to get a sense of what they are doing with NFTs on their parachains.

    Community engagementโ€‹

    The Saito team will publish regular updates on developments and milestone completions. This project represents a great developer outreach opportunity for Saito, and to bring much anticipated features from the Polkadot ecosystem. There will be many opportunities to promote this to our growing community and specifically to developers working on Saito, and those in the Polkadot space.

    More importantly Saito will seek out a partner project working on NFTs or other tokens on a parachain to colaborate on building a game in which these tokens are issued as prizes, trophies, in game assets, achievement badges or similar. This would cap off the work done as part of this grant, and set the stage for broader colaboration.

    Future Plansโ€‹

    Our hope is that this work continues well into the future, and that the Polkadot community embraces not only the sort of open source games that our community is producing, but the more flexible style of application design that comes from in-browser stack-based program execution instead of offloading everything into smart contracts.

    Should it become apparent that a game protocol compliant substrate module could be valuable to Polkadot and the community, we would investigate building such. Either under a separate grant or in colaboration with the Polkadot community.

    Our criteria for success is our ability to build community around feature-rich games. Our hope is that integration with Polkadot and other financial parachains brings value to Polkadot users, programmers, and our own gamers. We are happy to work with other chains and communities to bring their valuable features into our gaming environment. The shared goal is an open ecosystem that is more attractive than closed source competitors like Steam and the Apple Store.

    Our criteria for failure would be spending a significant amount of our time building foundational tools that do not drive game development and community growth. We think this unlikely, as our own community is growing rather quickly and there is a clear need for Web3 games to integrate with asset-class blockchains and parachains.

    Additional Information โž•โ€‹

    The Saito Project has seed support.

    The images below are from playable games that are currently running on the Saito network (https://saito.io/arcade). In addition to building their own games, developers are able to start building payment functionality on top of these and other games immediately upon this project being completed.

    Games generally available for play around the network include Chess, Wordblocks, Twilight Struggle, Red Imperium, Poker, President, Solitrio, Scotland Yard, Thirteen Days, Pandemic, and several others. Most games support anywhere from 2 to 8 players and take anywhere from 15 minutes to 6 hours of time to play through completion.

    ###Game Images

    Twilight Struggleโ€‹

    Twilight Struggle

    Pokerโ€‹

    Poker

    Red Imperiumโ€‹

    Red Imperium

    Wordblocksโ€‹

    Wordblocks

    Notesโ€‹

    1. https://en.wikipedia.org/wiki/Mental_pokerโ†ฉ
    2. https://apps.dtic.mil/dtic/tr/fulltext/u2/a066331.pdfโ†ฉ
    - + \ No newline at end of file diff --git a/applications/sandox.html b/applications/sandox.html index bed8ad9c657..e7bbd46eee8 100644 --- a/applications/sandox.html +++ b/applications/sandox.html @@ -4,7 +4,7 @@ SanDOx | Web3 Foundation Grants - + @@ -34,7 +34,7 @@ 11) PWA 12) New IDE themes, themes constructor 13) Plug-ins support for adding features by other teams

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    - + \ No newline at end of file diff --git a/applications/sarp-basic-functionality.html b/applications/sarp-basic-functionality.html index b24875ce70c..6311727ccdd 100644 --- a/applications/sarp-basic-functionality.html +++ b/applications/sarp-basic-functionality.html @@ -4,14 +4,14 @@ SARP - A Static Analysis Tool for Runtime Pallets | Web3 Foundation Grants - +
    Skip to main content

    SARP - A Static Analysis Tool for Runtime Pallets

    • Team Name: Supercomputing Systems AG (SCS)
    • Payment Address: 0xd24622311a22470353bd21d9bcd9e02ba0cfebbe (USDC)
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    This application is a response to the RFP Static Analysis for Runtime Pallets

    Overviewโ€‹

    Runtime Pallets are modules for writing the business logic of blockchains in Substrate (a Rust framework for building blockchains). These are usually concise pieces of standalone code with relatively few dependencies and clear specifications, hence tractable targets for performing static analysis and verification. The code quality of a runtime pallet is crucial, as even minor defects can result in major exploits like DoS attacks or the stealing of funds by a malicious party. A static code analysis can help to automate the auditing processes and prevent introduction of defects throughout the software life-cycle.

    Therefore we would like to develop a tool - SARP (Static Analysis tool for Runtime Pallets) to perform static analysis with reasonable soundness guarantees. In particular, we would like to target vunerability classes that are detectable using dataflow analysis techniques like tag analysis and taint analysis.

    Our team has no prior knowledge in static code analysis, but has a good understanding of substrate and Rust.

    Project Detailsโ€‹

    We will base our work on MIRAI and extend it with checks on substrate pallets. For details see the Development Roadmap

    Ecosystem Fitโ€‹

    The tool will help any team developing substrate pallets. It can further be integrated in the CI pipelines of the teams, providing a continuous quality check on the pallet code.

    In the long term it could be interesting to connect the work done here with the new emerging auditing DAOs (like Fuzzland or QRUCIAL DAO).

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Sabine Proll: Project Lead
    • Bigna Hรคrdi: Developer
    • Edith Chevrier: Developer
    • Thomas Niederberger: Developer

    Contactโ€‹

    • Registered Address: Technoparkstrasse 1, 8005 Zรผrich, Switzerland
    • Registered Legal Entity: Supercomputing Systems AG

    Team's experienceโ€‹

    Supercomputing Systems AG is a contractor with 130 engineers, working in the fields of software, electronics and system design. Profound know-how, solid methodological competence as well as efficient project management are the foundation of our success. Within the company we have a team of 5 blockchain developers, who have experience in the Polkadot ecosystem.

    Our blockchain team has been a contributor to the ecoysystem since 2019. We started with grants from the Web3 Foundation to build the basis for Integritee (see our grants from waves 1, 3 and 5). After that, our team has worked for Integritee and Encointer as a contractor. Recently the team received grants from the Kusama treasury for maintaining and improving the substrate-api-client, see our proposals for Nov 22 - Jan 23 and Feb 23 - Apr 23.

    Team Code Reposโ€‹

    The team has mainly worked on the following repositories

    Github accounts of the team members

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    We will base our work on MIRAI and the RFP Static Analysis for Runtime Pallets

    We have not started to work on this.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 0,5 months
    • Full-Time Equivalent (FTE): 0,8 FTE
    • Total Costs: 10.000 USD

    Vulnerability Classesโ€‹

    For this project we want to address the following vulnerability classes:

    Milestone 1 - Researchโ€‹

    • Estimated duration: 0,5 months
    • FTE: 0,8 FTE
    • Costs: 10.000 USD

    In milestone 1 we want to investigate how the above stated vulnerability classes, can be detected by extending MIRAI.

    Deliverablesโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.User DocumentationWe will provide a basic tutorial that explains how to use the tool on a substrate pallet.
    0c.Testing and Testing GuideA first set of tests will be provided, together with a testing guide, that describes how to run them.
    1.Prototype CodePrototype code to approach the above two stated vulnerability classes.
    2.DocumentationTechnical documentation
    • describing the approach we plan to implement in milestone 2, incl. its limitations.
    • with (interesting) examples of the vulnerability classes.
    3.EngagementEngage with teams at Web3 Foundation and Parity for prioritization.

    Future Plansโ€‹

    The next steps for the tool would be to:

    1. Implement a first simple version of the tool, together with tests and documentation.
    2. Improve the usability, by providing
      • means to surpress warnings
      • a comprehensive user tutorial, incl. documentation on the risks of each vulnerability
    3. Add more features including checks on the following vulnerability classes:
      • tracking bad randomness: ensure bad randomness does not leak into sensitive functions.
      • detect panics statically to avoid potential DoS attacks: these include unsafe arithmetic operations, access outside bounds, assertion failures, etc.
      • tracking unsanitised input leakage for sensitive functions.

    Once we have a tool with a good feature set and basic usability features, we want to promote it to the Polkadot developers. Once the tool is in use, we hope to receive feedback on further features and improvements by the developers.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We have previously received grants by the Web3 Foundation for other projects (substratee and substrate-api-client).

    - + \ No newline at end of file diff --git a/applications/scale-codec-comparator.html b/applications/scale-codec-comparator.html index ad40a0de92d..142d6f49b66 100644 --- a/applications/scale-codec-comparator.html +++ b/applications/scale-codec-comparator.html @@ -4,7 +4,7 @@ SCALE Codec Comparator | Web3 Foundation Grants - + @@ -16,7 +16,7 @@ use.

    I have already developed https://github.com/gmajor-encrypt/php-scale-codec && https://github.com/gmajor-encrypt/php-substrate-api in the previous grant.

    Project Detailsโ€‹

    1. Providing an FFI to Rust's reference implementation
    2. Tested with rust's FFI along with the scale lib https://docs.substrate.io/reference/scale-codec/
    3. Passing the test will release the scale code badge of the GitHub action
    4. Add Github action ci automatically test if these libs are updated

    Ecosystem Fitโ€‹

    Help developers choose suitable the scale code package in the ecosystem to avoid unknown errors

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    individual

    Team's experienceโ€‹

    I have many years of php development experience and nearly five years of blockchain development experience, familiar with PHP, GOLANG, PYTHON, Nodejs, Rust

    Team Code Reposโ€‹

    https://github.com/gmajor-encrypt/php-scale-codec

    https://github.com/gmajor-encrypt/php-substrate-api

    Development Status ๐Ÿ“–โ€‹

    Not yet

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationSimple documentation on how to use and how to test
    1.enable Unit testProviding a FFI make test for scale.go, php-scale-codec,scale.rb,py-scale-codec,polkadot-js
    2.github actionAuto test when comparator commit code

    Milestone 2โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationSimple documentation on how to use and how to test
    1.enable Unit testProviding a FFI make test for as-scale-codec,cScale,scale-codec-cpp,scale-codec-js-library,go-substrate-rpc-client,scale-ts
    2.github actionAuto test when comparator commit code

    Milestone 3โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationSimple documentation on how to use and how to test
    1.GitHub badgeCreate a GitHub badge for SCALE feature complete libs
    2.GitHub Ci ensure badgeLibs are tested with github actions if they are released

    Future Plansโ€‹

    I have been maintaining php scale code and php api lib for 2 years, and this application will continue to be maintained

    - + \ No newline at end of file diff --git a/applications/sensio_network.html b/applications/sensio_network.html index 53881c100ea..398d43c5d00 100644 --- a/applications/sensio_network.html +++ b/applications/sensio_network.html @@ -4,13 +4,13 @@ Sensio Network | Web3 Foundation Grants - +
    Skip to main content

    Sensio Network

    • Proposer: woss
    • Payment Address: BTC: 3HLaefnngXW515Zr6MDdz3W2XpLojABeBW
    • Keybase Sensio

    Legendโ€‹

    AcronymName
    PoEProof-Of-Existence
    PoCLOProof-Of-Camera-Lens-Ownership
    SSISelf Sovereign Identities
    DIDDistributed Identifier
    IPFSInterplanetary file system
    PGPPretty Good Privacy
    PKIPublic key infrastructure

    Project Description ๐Ÿ“„โ€‹

    SensioNetwork is a decentralized protocol that empowers content creators to sign, permanently record, and claim statements about their ownerships and copyrights, allowing them to license their work and get paid. SensioNetwork is an integral part of a much larger project called Sensio which consists of two more sub-projects.

    SensioNetwork's applications(dApps), Sensio Photo and People-2-People marketplace, have a potential of reaching millions of people and boosting the ecosystem's reputation and adoption.

    SensioNetwork will be implemented as a Substrate-based chain with its token, currently named THT.

    SensioNetwork is the backbone of the Sensio project. Building the SensioNetwork with Substrate and in the Polkadot, ecosystem matches our principles and views on interoperability and interconnectivity. One of the Sensio's goal is to establish a fair and trustworthy multimedia market, primarily for photography, and we can do that only with a flexible blockchain solution.

    Team ๐Ÿ‘ฅโ€‹

    • Members: Daniel Maricic
    • LinkedIn Profiles: https://www.linkedin.com/in/danielmaricic/
    • Code Repos: https://gitlab.com/sensio_group
    • Website: https://sensio.group/sensio-network
    • Legal Structure: 7signals Ltd, Sepapaja tn 6, 15551, Tallinn, Estonia
    • Team's Experience: Daniel has over 12 years of developing experience, mostly in backend development. He has been working in various IT sectors. He has started being involved in blockchain space a little over a year ago when he started researching on a blockchain solution for the Sensio project. He is very quick with acquiring new knowledge and very enthusiastic about Polkadot in general. That is why he applied for the Ambassador program.๐Ÿ˜Ž

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 6 weeks
    • Total Costs: 0.5 BTC

    Building the modules follows a least-dependency approach, which means that we will build the modules that are most dependent on first.

    Milestone 1โ€‹

    In this milestone, we want to build a working Substrate-based chain and PoE runtime module.

    PoE is an essential step towards generating any kind of statement. The ruleset in SensioNetwork is based on the flexible implementation of PoE. Each of the Proof-of-* modules depend on the information to exist before it can be verified. The structure is slightly different for each of the input types. In the case of the photo, there is more than one identifier since each photo can contain the metadata. Our tasks in this milestone are to define the generic structure and rule-set as well as the rules specific for the photo type. The rules should be much interoperable as they can. One potential solution to this is utilising the CID and multihash library.

    • Estimated Duration: 2 weeks
    • Costs: 0.5 BTC
    NumberDeliverableSpecification
    1.Substrate based chainBuilding the substrate based chain
    2.PoE runtimeGeneric PoE for any kind of data which is using the statement module
    3.Unit testsRudimentary tests for both runtime
    4.Docker imageCreate docker image
    5.Tutorial && docsFinalise the docs and write a tutorial on how to use the implemented features
    1. Substrate based chain implementation
    2. The PoE runtime must record when the specific item was seen for the first time regardless of the copyright and ownership.
    3. Rudimentary tests for both runtime modules
    4. Self-explanatory
    5. Self-explanatory

    Milestone 2 - Canceled via Elementsโ€‹

    In this milestone we will start working on PoCLO, implementing the connection to PoE and working on the implementation of the rules and data validations. By the end of this milestone, we will have the working runtime that validates that equipment information already exists in PoE and has never been claimed and can create the ownership statement for a given input.

    We have developed the algorithm for PoCLO in nodejs and the workflow is built with different architecture in mind. We must change it to fit the current solution. This module will be in charge of creating records for provable camera/lens ownership statements. The current implementation is built with React in our Proof-of-Concept webapp. PoCLO is a process that is very similar to what is used in image forensics. It's our first step to registering provable ownership statements. Our current solution uses PKI and CID, which we will keep in the future together with the SSI and DID.

    • Estimated Duration: 4 weeks
    • Costs: 0 BTC
    NumberDeliverableSpecification
    1.PoCLO runtime moduleThis part will be dedicated to creating generic structure and defining the API
    2.UI for showcaseCreate working simple UI which can demo the whole workflow
    3.Unit testsRudimentary tests for both runtime
    4.Docker imageUpdate docker image
    5.Tutorial && docsUpdate the docs and tutorial on how to use the implemented features
    1. The PoCLO must provide the validation rules, validate them and create or revoke the statements. In this milestone, we will focus on creating the working validation rules, storage and API methods.
    2. Simple UI to verify the equipment based on the uploaded photo
    3. Self-explanatory
    4. Self-explanatory
    5. Self-explanatory

    Additional Information โž•โ€‹

    Gentle overview on the process:

    Ownership and copyright process

    • What work has been done so far?

    At the moment we have PoC, web app + Graphql API + naive DAG, that we built as a showcase. We have the core functionality of all three sub-projects (very basic so far), photo upload and editing, claiming ownership and copyrights, selling ( for free, as it's a PoC ) and copyright request with approving and declining outcomes. We truly believe that (D)PKI or its variants are the future, that's why all users are given ed25519 asymmetric keys and passphrase emailed. That key is used for signing and verification.

    • Are there are any teams who have already contributed (financially) to the project?

    Only the founders, Daniel Maricic and Elena Tairova.

    • Are there any other projects similar to yours? If so, how is your project different?

    Some projects share a similar approach, like the majority of PoE/TimeStamping, but none of them does what we are trying to accomplish. Sensio, at the moment, is the only project out there that provides verifiable ownership and copyright claims based on real workflows, not first came -> first hashed it -> owns it.

    • The team's long-term plans and intentions with this project.

    SensioNetwork is the core part of Sensio and its applications which development is underway. First, the Digital Asset Management software for professional photographers will be launched, and later, with this community acting as ambassadors, we can expand to the mass market of smartphone holders. Well-established user-base and strong USP (connectivity, optimal protection of online IPR) will in its turn put Sensio in a position to disrupt the market of stock photography and video. Once launched, People-2-People marketplace will allow publishers, marketers and other creatives to acquire quality content directly from its author. Thus, a fairer and more efficient market for all the actors.

    Signaturesโ€‹

    All the assets have been signed with https://keybase.io/woss and standard GPG tools. For GPG, append .sig and for keybase .signed.saltpack to the end of any image URL within this document.

    - + \ No newline at end of file diff --git a/applications/sequester.html b/applications/sequester.html index 07c4dbf87c3..85e539e3a28 100644 --- a/applications/sequester.html +++ b/applications/sequester.html @@ -4,13 +4,13 @@ Sequester | Web3 Foundation Grants - +
    Skip to main content

    Sequester

    • Team Name: Sequester
    • Payment Address: bc1quup4v5el5s7m6szh24d6sn6cl25yjvr8mlymnt
    • Level: 2

    Project Overviewโ€‹

    Overviewโ€‹

    Since Polkadot-based chains are fee-optional, transaction fees currently being used as an anti-spam mechanism can be leveraged to make every transaction on Polkadot carbon negative, without requiring any changes to the user experience. We propose a common good parathread on Polkadot, named Sequester, that provides the functionality of aggregating transaction fees, exchanging them into carbon-backed tokens, and retiring underlying carbon offsets that meet the communityโ€™s specifications.

    Sequester is a toolkit that will allow any chain in the Polkadot ecosystem to easily buy carbon-backed assets and retire associated carbon credits. By retiring these carbon credits, we aim to incentivize the creation of more high-quality carbon reduction projects by substantially increasing demand and the economic viability of this work.

    Due to Polkadotโ€™s shared security model, the network is uniquely positioned to utilize existing network activity to natively power a carbon sink. With the widespread adoption of Sequester across its growing ecosystem, Polkadot has the potential to power one of the largest carbon-offsetting entities worldwide.

    For more information, see our full white paper.

    Project Detailsโ€‹

    To allow chains to sustainably leverage their transaction fees to buy carbon credits on-chain, we will need to handle:

    1. Receiving tokens sent from other chains
    2. Exchanging those tokens into carbon-backed tokens, and
    3. Initiating retirement of the underlying assets for the carbon-backed tokens

    This grant addresses step 1. Specifically, we will implement a pallet that will calculate a chainโ€™s transaction fees over a period of time and allow any chain connected to Polkadot or Kusama to send a percentage of them to Sequester.

    Ecosystem Fitโ€‹

    Sequester is building the infrastructure to allow any chain in Dotsama to donate a portion of their transaction fees towards buying and retiring carbon-backed assets. We aim to provide parachain developers a simple way to integrate Sequesterโ€™s functionalities into their chain. We hope to lead the charge in implementing Polkadotโ€™s environmental strategy. With the widespread adoption of Sequester across its growing ecosystem, Polkadot has the potential to be one of the largest carbon-offsetting entities worldwide. We visualize and explain this process in the diagram below:

    High-Level Diagram Detailing Sequesterโ€™s Role in the Polkadot Ecosystem

    Teamโ€‹

    Team membersโ€‹

    • Brendan Edelson - Full Stack Developer
    • Ethan Brown - Full Stack Developer

    Contactโ€‹

    • Registered Address: UniSearch Inc. 800 N. State Street, Suite 403, Dover, DE 19901, United States
    • Registered Legal Entity: Sequester Chain LLC.

    Team's experienceโ€‹

    • Brendan Edelson - Software Engineer at CTRL-Labs. Bachelor of Science, Computer Science from Stanford University.
    • Ethan Brown - Software Engineer at Instagram. Bachelor of Science, Computer Science from Stanford University.

    Team Github Reposโ€‹

    Individual Github Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Statusโ€‹

    For the past two+ months, we have been fleshing out the technical implementation details and meeting regularly with several members of Web3 Foundation and Parity Technologies: Marta Moranduzzo, Joe Petrowski, Raul Romanutti, Otar Shakarishvili, and a one-off intro meeting with David Hawaig.

    The Bitgreen team will be our initial ecosystem partner and will be responsible for bridging Carbon Credits on-chain in a sustainable manner.

    We also attended the AmsterDOT conference and established working connections with several parachain teams in the ecosystem.

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated duration: 5 weeks
    • Total Effort: 2 FTE
    • Total Costs: $25000

    Milestone 1โ€‹

    • Estimated duration: 5 weeks
    • Total Effort: 2 FTE
    • Costs: $25000

    Goal - Implement a pallet that allows chains to calculate transaction fees used on-chain during a period of time and send those funds from their treasury via XCM to the Sequester chain.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide documentation on how to add our pallet to a Substrate chain and an overview of the configuration options.
    0c.TestingOur code will have full unit-test coverage to ensure functionality and robustness. We will also provide documentation describing how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) to run a test node in order to test that our pallet functions correctly.
    1.Calculate Transaction FeesInside our pallet, we will create a method that calculates the transaction fees over a period of x blocks. For the fee-calculation, we will be using an off-chain worker to index the transaction fees on a per-block basis and store that calculation in off-chain storage.
    2.Send to SequesterImplement a method that will retrieve the sum of transaction fees from offchain-storage and will send a percentage (a configurable variable) of them to Sequester's chain via XCM every x blocks (also a configurable variable). This transfer process will be automated so that no manual transfer will be needed by the parachain through governance. This method will also handle resetting the proper off-chain variables.
    3.Article/TutorialWe will provide a full tutorial outlining how to add the pallet to your chain. This will be added to the wiki of the sequester website.
    4.Weight estimationWe will provide reasonable weight estimations, e.g., using benchmarking.

    Future Plansโ€‹

    1. Creation of Common-Good Chain to receive tokens from chains that implement the Transaction Fee pallet
    2. Integration with leading ecosystem DEX to swap substrate tokens for carbon credit-backed tokens
    3. Auditing and security analysis of Sequester chain and pallet
    4. Sequester website to host our documentation and wikis to allow easy onboarding for other chains
    5. Onboarding of Sequester onto Kusama
    6. Integration with our first parachain partner for initiating carbon retirement functionality
    7. Onboarding of partner Parachain teams
    8. Onboarding of Sequester onto Polkadot
    9. UI for visualizing Sequesterโ€™s impact
    10. Integration with future partners and increased offerings of ESG tokens

    Additional Informationโ€‹

    How did you hear about the Grants Program? Personal Recommendation

    - + \ No newline at end of file diff --git a/applications/setheum-launchpad-crowdsales-pallet.html b/applications/setheum-launchpad-crowdsales-pallet.html index 22177456cac..cdec1d0a7b3 100644 --- a/applications/setheum-launchpad-crowdsales-pallet.html +++ b/applications/setheum-launchpad-crowdsales-pallet.html @@ -4,7 +4,7 @@ Setheum HighEnd LaunchPad Crowdsales Module | Web3 Foundation Grants - + @@ -15,7 +15,7 @@ We are working on the Setheum node Implementation.

    Technology Stackโ€‹

    The substrate pallet is written in rust based on the FRAME Substrate framework. The pallet types in types.json are generated in JSON, and the Test Node will be a fork of the Setheum Node based on the substrate-node-template, the node leverages the ORML stack for a lot of functionalities especially Multi-Currency functionalities. And the GUI to be used in the tutorial is a custom React.JS app utilising Polkadot.JS.

    Non-Goalsโ€‹

    I muat be very clear that we are not intending to implement the Setheum HighEnd LaunchPad Proocol as is described in our Whitepaper. Rather, this is only a stepping stone towards those goals. This will only implement a simple launchpad crowdsales substrate pallet. While we intend to implement this protocol in Setheum, it is not yet ready for production and might currently have unknown issues, therefore this does not represent the final state of what is intended to go into production on our main chain implementation, and we do not intend the current implementation to have the robust functionalities of a production-level launchpad platform. This will instead only result in an initial test network for evaluation purposes.

    Ecosystem Fitโ€‹

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Not set up yet.

    Team's experienceโ€‹

    I am building the Setheum Network project and all related code works in the organisation. I have a Computer Science degree (currently in my final year of study) and I have been working on Setheum for a few years now. And will be launching this year by God's grace. I have been an active programmer in a few more programming languages and frameworks. I have been working and learning on the Substrate/Polkadot/Kusama ecosystem for a few years now.

    I have previously applied for this grant about 10 months ago (then TERMINATED, the best thing that happened to me) when I (Muhammad-Jibril BA.) was very new to FOSS and both Rust & Substrate. And Setheum has evolved a lot since then, and so have I learnt a lot from the Substrate community and from trial and error in building Setheum from a beginner in rust to current status. All thanks to God and thanks to the Web3 Foundation.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We have started development of this specific protocol in this repository. And posted a Medium article on the design concept of the protocol and its proposed final/production state here. We have also created some GitHub Milestones and issues to track the progress of the development.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 Example โ€” Implement Substrate Modulesโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0dCI/CDAutomate build and tests with GitHub Actions.
    0e.Article/TutorialWe will publish an article that explains what was done/achieved as part of the grant and a short tutorial on how it works in a demo node.
    1.Substrate module: launchpad-crowdsalesWe will create a Substrate module that will allow teams/individuals/projects to raise funds through a crowdsales launchpad where they can sell their tokens to the public in a token sales event fashion similar to an ICO.
    2.Types GenerationWe will create a types.json file that defines the types in the launchpad-crowdsales Substrate module.
    3.Demo nodeThe Pallet will be added to a demo substrate node fork of Setheum node
    4.Docker fileProvide a docker file with the demo chain that demonstrates this project
    5.CLient APIProvide a custom Client API for interacting with the pallet
    6.Simple UIProvide a simple UI for interacting with the pallet
    7.BenchmarkingAdd benchmarking to the pallet

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? personal recommendation.

    - + \ No newline at end of file diff --git a/applications/setheum.html b/applications/setheum.html index 0a39cb28928..1a520e7e31e 100644 --- a/applications/setheum.html +++ b/applications/setheum.html @@ -4,7 +4,7 @@ Setheum | Web3 Foundation Grants - + @@ -26,7 +26,7 @@ No, so far we are fully self-funded
  • Have you applied for other grants so far? No, we have not applied for any other grants so far, but we have applied to the Substrate Builders Program We are providing the Entire Project under the Apache 2.0 license.
    • - + \ No newline at end of file diff --git a/applications/shadows-network.html b/applications/shadows-network.html index e67001c86ce..6779d58381e 100644 --- a/applications/shadows-network.html +++ b/applications/shadows-network.html @@ -4,14 +4,14 @@ Shadows Network | Web3 Foundation Grants - +
    Skip to main content

    Shadows Network

    • Payment Address: 198yWGziNfUgrTXf6QiUC5QqEhJ34cyxf
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Shadows Network is a Polkadot parachain based on Substrate. As long as you consider valuable assets, they can be synthesized on the chain through Shadows Network. And Shadows network is a decentralized financial integrated platform integrating stablecoins, collateral lending, asset synthesis, and derivatives trading. will introduce a trillion-level derivatives market into the Polkadot ecosystem.

    Overviewโ€‹

    Shadows Network is a Polkadot parachain based on Substrate, focusing on synthesizing derivative assets into the Polkadot ecosystem. It is like the "shadows" of real assets on the blockchain. Shadows Network will open up the channel for real assets to be synthesized to the blockchain. Real assets that you think are valuable can be synthesized through the Shadows protocol to achieve decentralization of asset value. Shadows Network pioneered the "debt pool" model, which has the advantages of unlimited liquidity and zero slippage on-chain transactions. It has a more friendly transaction experience and lower transaction costs than other centralized exchanges and SWAP.

    Shadows network will strive to become one of the Polkadot parachains by participating in the parachain slot auction. However, even if the slot usage rights are not successfully obtained by then, the shadows network will also be counted as parathreads to obtain cross-chain capabilities.

    Most of our team members come from first-line Internet companies, cryptocurrency wallet companies and cryptocurrency exchanges. They have participated in the development of multiple blockchain projects and have in-depth research and accumulation of blockchain technology. We have developed many dapps based on Ethereum. Due to the limitations of Ethereum itself, many of our ideas cannot be implemented and realized on Ethereum. We have done in-depth research on Polkadot and Substrate technology, Polkadot's cross-chain technology, parachain slot, governance model, etc. We believe that Polkadot is one of the most advanced technologies and concepts at present. What Shadows Network wants to do is to synthesize assets into the blockchain, so that everyone can truly control their assets and realize asset security and asset transaction security.

    Project Detailsโ€‹

    The Shadows Network architecture design includes: DOSใ€MintXใ€Exchangesใ€Fee Poolใ€Debt Poolใ€Liquidation and Off-chain Workers.

    DOS

    DOS token is a governance token issued by Shadows Network. All synthetic asset are backed by DOS token. synthetic asset are minted when DOS holders stake their DOS as collateral.

    MintX & xUSD

    DOS holders can mint xUSD through MintX by stake DOS. MintX is a reactor for synthetic assets. xUSD is a stable currency issued by Shadows Network. xUSD is minted by stake DOS and The mortgage rate of DOS must not be less than 800%. All synthetic asset transactions will be conducted around xUSD.

    Exchanges

    Shadows.Exchange provides many advantages over centralised exchanges and order book based DEXโ€™s. All trades are executed against the contract, known as P2C (peer-to-contract) trading. Assets are assigned an exchange rate through price feeds supplied by Off-chain workers, and can be converted using the Shadows.Exchange dApp. This provides infinite liquidity up to the total amount of collateral in the system, zero slippage, and permissionless on-chain trading.

    Fee Pool

    When SyAs are exchanged through the Shadows Exchange, a 0.3% fee is extracted and sent to the fee pool to be claimed by DOS stakers. When claiming fees (also called SyAs exchange rewards) a staker also claims their DOS staking rewards, which reward them with extra DOS for staking the DOS they currently have.

    Debt Pool

    The system tracks the debt pool (as well as each individual stakerโ€™s debt) each time an DOS holder mints or burns Synths. It does this by updating the Cumulative Debt Delta Ratio. This measures the DOS stakerโ€™s proportion of the debt pool at the time they last minted or burned, as well as the debt change caused by other stakers entering or leaving the system. The system uses this information to determine the individual debt of each staker at any time in the future, without having to actually record the changing debt of each individual staker.

    Liquidation

    In order to avoid systemic risks, We introduced the introduced liquidation. When the staker's position is lower than 750%, the system will prompt the liquidation risk. If the position has not been increased for a period of time, the collateral will be liquidated.

    Ingester

    Ingester is our implementation of Off-chain workers. The prices of all synthetic assets in the Shadows system need to query and/or process off-chain data before it can be included in the on-chain state. The conventional way of doing this is through oracles. But oracle still has several flaws with respect to security, scalability, and infrastructure efficiency.

    To make the off-chain data integration secure and more efficient, We use Substrate off-chain workers. The off-chain worker subsystem allows execution of long-running and possibly non- deterministic tasks (e.g. web requests, encryption/decryption and signing of data, random number generation, CPU-intensive computations, enumeration/aggregation of on-chain data, etc.) that could otherwise require longer than the block execution time.

    Ecosystem Fitโ€‹

    We have a deep understanding of many projects in the Polkadot ecology, and found that there are several projects that we think it is necessary to list to make a difference explanation, Acala, Laminar and Coinversation:

    The main difference between Shadows Network and Acala Network is that Acala's swap and liquidity mining have the risk of lack of liquidity and the pain points of high slippage. The original "debt pool" mechanism of shadows network has the advantages of unlimited liquidity and zero slippage trading. Acala's stablecoin and lending business rely heavily on the third-party oracle chain link, which has some shortcomings in security, scalability, and basic efficiency. The shadows network will use the off-chain workers provided by Substrate to improve this. , Safer and more efficient.

    Laminar relies heavily on off-chain asset collateral, such as U.S. dollars, which has the shortcomings of inefficiency and inflexibility, while the shadows system uses digital assets such as DOT, DOS, BTC, ETH as collateral, which is more flexible, efficient and safe, and users The options are more extensive.

    Coinversation is not a parachain and based on the ink! smart contract depends on the existing parachain. The shadows network develops parachains based on substrate. Based on the rust language and Substrate's forkless runtime upgrades, the shadows network is more efficient and flexible.

    Coinversation currently relies on a centralized oracle, which has the risk of being opaque and easy to operate, while the shadows network parachain is based on the off-chain worker of the substrate, which can achieve little dependence on the oracle, which means that the oracle is brought about The risk is also smaller. We haven't seen any "Liquidation" plan in Coinversation, and shadows network has a more complete liquidation mechanism to avoid systemic risks.

    From the above analysis and comparison, shadows network has obvious differences from several other products. Shadows has a more complete design and better technical solutions, and we have considered more mature risk control.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Zoujun Chen: Co-Founder. He once worked for the Fortune 500 Amphenol Group. He entered the blockchain industry in 2013. He is the main person in charge of multiple blockchain projects and has many years of industry experience.

    • Mingchang Lin: Co-Founder. Cryptographic System Engineer once worked for Baidu, and participated in the development of multiple blockchain projects since 2014.

    • Ling Cai: Head of commerce and marketing. He once worked in a first-line exchange company.

    • Xinan Li: A traffic expert, with in-depth understanding and practical experience in Internet industry traffic, and very familiar with traffic promotion methods.

    • Zhuliang Li: A financial expert. He once worked for Ping An Bank of China (one of the largest commercial banks in China). He is familiar with the design of financial products, the simulation and calculation of financial models, and financial risk control.

    • Hehong Wu: Front-end engineer, has in-depth research on various front-end technologies. Guang Xiao: Senior UI designer, once worked in China's first-line game development company๏ผšNetDragon and Nasdaq:NTES.

      We also have several developers from the member companies of Polkadot China Technology Alliance who contributed code to the shadow network.

    Contactโ€‹

    • Contact Name: Polkadot (China) Technology Alliance
    • Registered Address: Room F01, 3rd Floor, Annex Building, F Zone F, Fuzhou Software Park, No. 89 Software Avenue, Gulou District, Fuzhou City, Fujian Province, China

    Team's experienceโ€‹

    Most of the members of our team come from Polkadot (China) Technology Alliance. Most of them have worked in first-line Internet companies, cryptocurrency wallet companies and cryptocurrency exchanges. They have participated in the development of multiple blockchain projects and have in-depth knowledge of blockchain technology. Research and accumulation have also accumulated a lot of blockchain industry resources in China.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    We expect that the entire project will be split into two grants. The first grant includes the development of parachains and the implementation of core modules. But only documents, test cases and api are provided. But through the API, you can already participate in the casting and trading of synthetic assets. The second grant will include the development of a complete user interface, dapp, and wallet. It will be a complete product that can be experienced by then. Users can directly experience the functions without knowing the technical details.

    -----------------------------------------------------------
    | Substrate chain with MintX & Ingester & Exchange module  |  <---- This grant
    -----------------------------------------------------------
    | User interface with Dapp & Wallet                        |  <---- Future grant
    -----------------------------------------------------------
    | More synthetic Assets (e.g S&P500, TSLA)                 |
    -----------------------------------------------------------

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-time equivalent (FTE): 5
    • Total Costs: 1.35 BTC

    Milestone 1 โ€” Implement Substrate MintX&Ingester Moduleโ€‹

    In this milestone, we developed the MintX module and the Ingester module. MintX is used to mint synthetic assets, while Ingester is used to query the price of assets outside the chain. After completing this milestone, we can experience the entire process of casting synthetic assets.

    • Estimated Duration: 1.6 month
    • FTE: 3
    • Costs: 0.7 BTC
    NumberDeliverableSpecification
    0.LicenseApache 2.0
    1.DocumentationInstructions and examples for use MintX and Ingester
    2.Testing Guideprovide test suite (mock and test files) for the MintX and Ingester describing how the module can be tested.
    3.Substrate module: MintXWe will create a Substrate module MintX. DOS holders can mint xUSD by stake DOS. And Debt Pool is also implemented in the MintX module.
    4.Substrate module: IngesterWe will create a Ingester module that is a off-chain worker used to query and/or process off-chain data.
    5.TutorialWe will write an tutorial about how to use MintX & Ingester.
    6.TestingThe code will have proper unit-test coverage to ensure functionality and robustness.
    7.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain with MintX and Ingester moudle.

    Milestone 2 โ€” Implement Substrate Exchange Moduleโ€‹

    At this milestone, we developed the exchange module. The first milestone has been able to mint synthetic assets. When this milestone is completed, our synthetic assets will be available for trading.

    • Estimated Duration: 1.4 month
    • FTE: 3
    • Costs: 0.65 BTC
    NumberDeliverableSpecification
    0.LicenseApache 2.0
    1.DocumentationInstructions and examples for use Exchange.
    2.Testing Guideprovide test suite (mock and test files) for the exchange describing how the module can be tested.
    4.Substrate module: ExchangeWe will create a exchange module that will be used to trade synthetic assets. And Fee Pool is also implemented in the Exchange module.5.
    5.TutorialWe will write an tutorial about how to use MintX & Ingester.
    6.TestingThe code will have proper unit-test coverage to ensure functionality and robustness.
    7.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain with Exchange module

    Future Plansโ€‹

    There are many different kinds of SyAs that can be added to the system to provide greater utility to Shadows.Exchange. These include leveraged assets that are not available on other platforms as well as indices like the S&P500 and equities like APPLE and TSLA.

    Additional Information โž•โ€‹

    So far we have completed the project possibility verification evaluation, completed the Substrate-based architecture design, and released the project white paper.

    - + \ No newline at end of file diff --git a/applications/signac.html b/applications/signac.html index bbfaf0f95c9..deef25110f0 100644 --- a/applications/signac.html +++ b/applications/signac.html @@ -4,7 +4,7 @@ Signac - a monorepo plugin for developing multiple Parity ink! smart contracts | Web3 Foundation Grants - + @@ -20,7 +20,7 @@ This includes deploying contract, running the test chain, and setting up a task to run. The cli binary aims to cover whole feature in ink-waterfall.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDocumentation of Signac will be provided in gitbook
    0c.Testing GuideTesting guide will be provided as a tutorial in gitbook documentation
    0d.DockerThere will be a dockerfile included in the codebase to run local substrate node with contract pallet
    1.Signac RepoThe entire code for the binary will be shared in a github public repository.
    2.Article & VideoWe will write an article that explains the work done as part of the grant, as well as release a video walk through demonstrating Signac

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? I applied before.

    - + \ No newline at end of file diff --git a/applications/signet.html b/applications/signet.html index b2413bddfc2..e69a1b6e352 100644 --- a/applications/signet.html +++ b/applications/signet.html @@ -4,14 +4,14 @@ Signet - Talisman | Web3 Foundation Grants - +
    Skip to main content

    Signet - Talisman

    • Team Name: Paraverse Foundation
    • Payment Address: 128tk6D5CvYvGFtvjTgZT8yrD2wPWZyczBoj8LzkmGpTNbo9 (USDC/AssetHub)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Signet is blockchain-native financial workflow management software for enterprises.

    The goal of Signet is to enable enterprises to perform blockchain operations such as treasury management, payments, staking and governance in a way that is friendly to non-technical users but include similar "best practice" risk management controls to how they may operate in web2 today.

    We believe enterprise adoption will be one of the central narratives of the transition to Polkadot 2.0, and the capabilities of the Signet platform will enable this to happen in Polkadot, enabling enterprises to feel comfortable to inject liquidity into the ecosystem.

    Signet is built natively on top of Substrate, including the multisig, proxy, governance and staking pallets, but adds an open-source self-hostable software layer on top that enables configurable workflows for the purpose of internal risk mititgation.

    Signet was initially created out of Talismanโ€™s user research, which revealed that teams faced many difficulties and risked mistakes when trying to run their on-chain financial operations, and ended up choosing convenience over security. In mid 2023, the Signet team was formed within Talisman to focus on B2B and enterprise opportunities.

    We believe what we are proposing is a great candidate for W3F funding because of two reasons:

    1. The common good aspect of a documented, integratable Sign in with Substrate (SIWS) reusable component, coupled with the halo effect it will have on Substrate adoption by providing a new avenue for both existing web2 and current web3 developers to build for the ecosystem.
    2. The importance of usability for larger organizations, enterprises and institutional users, who find it difficult today to use overly technical tools such as Polkadot.js. We believe strongly that ease of use and understanding are extremely important when trying to achieve security, in practice, in an enterprise context, and by delivering this, Signet will enable liquidity to flow into the ecosystem.

    Project Detailsโ€‹

    We will first describe the architecture of the current system, and then the improvements and additions we plan to implement in the course of this grant.

    Architecture Overviewโ€‹

    Signet's architecture provides the ability to manage offchain enterprise workflows along with supporting data like address books in a secure manner. With access controls and the ability to self host the instance, clients can choose the level of security and privacy for their implementation.

    architecture

    Our system is designed around the idea that a multisig unit is a keyless any proxy controlled by a Substrate multisig. We use a magic link system that encodes the proxy address and the member addresses of the multisig, which can then be shared with other signers to import it into their instance of Signet. The frontend is built in React and Typescript.

    Offchain data used to support Enterprise Workflows are stored in a Postgres Database via Hasura, which offers at least 2 levels of authorisation. Requests to access data in the database are authorised using a combination of on-chain and off-chain data to satisfy various business needs, followed by role based access control built into Hasura. Access is restricted so that the Hasura server is the only service that can call the database.

    We use Sign in with Substrate (SIWS) to authenticate users. This allows our backend to confirm that whoever claims to own an address and wants resources relevant to that address actually owns the address and is able to sign a challenge message to provide proof. SIWS has been created specifically for Signet, and is run in a nodejs sidecar.

    Signet is designed in a modular way, so that specific workflows or extrinsics can be have a custom UI that enables non-technical users to perform blockchain actions.

    The initial version of Signet was developed as part of a Polkadot Treasury Proposal and aimed at DAOs and smaller teams in Polkadot. We have since decided to focus on larger enterprises who require more complex workflows and risk mitigation.

    Key Focus Areasโ€‹

    For the purpose of this grant, we are looking to build on top of the work and architecture presented above and address the following two issues:

    1. No standard for Sign in with Substrate: While other projects have built custom solutions for logging into an app using Substrate, there are currently no reusable components to make it easy for developers to build apps and services on top of Substrate login.
    2. Improve existing UX for Selecting Validators: Validator selection is currently difficult and error prone, and users have no easy way to double-check the addresses they are assigning in the process.

    The following diagram shows Signet as it is being built out currently (in black), as well as the additions enabled by this grant (in green).

    capabilities

    SIWS is a building block towards a shared address book for multisigs/organizations, which can enable migration of shared enterprise information from computer to computer or authorized person to authorized person, as well as allows for easier selection of validator addresses for all signers to leverage and is a key part of improving the experience of using Substrate-based proxy-multisigs.

    Ecosystem Fitโ€‹

    The project is built on Substrate, using Substrate native features. The goal of the project is to enable entities (corporations, asset managers, web3 companies etc.) to feel comfortable enough operationally to manage a significant amount of assets on Substrate.

    Target Userโ€‹

    The target audience is enterprises and larger organizations who require workflows and risk management in order to be comfortable to deploy capital into the Polkadot ecosystem. This may include enterprises already operating on-chain in Substrate, enterprises with a large web2 footprint, including, potentially, customers of Mythical Games, Aventus, Peaq, Energy Web, etc, or more traditional organizations evaluating moving into Substrate including, potentially, Deloitte, Sony or Toyota. Signet would allow C-Levels and Finance/Operations departments at these types of companies to feel comfortable integrating blockchain into their workflows.

    Similar Projectsโ€‹

    There are a number of multisig front-ends or multisigs in development in the Polkadot ecosystem, including: Multix, PolkaSafe, Saturn. While ostensibly there is an overlap in functionality related to being a multisig, Signet is designed to sit at a layer above the multisig and aimed at a different target audience:

    1. Signet is designed to be self-hostable to enable an organization to manage it's own off-chain data and workflows in a way that meets it's internal devops and security needs.
    2. Signet's main value-add is not simply to provide a more friendly multisig UX, but rather to enable an organization to implement their own workflows on top of the multisig process. It's likely that these workflows require, at least at this time, off-chain operations and data storage that enhance the underlying blockchain.
    3. Signet's direction is to become a platform that integrates with different multisig front-ends or multisig pallets, rather than competing with them.

    Regarding Sign in With Substrate, there are a few projects that have implemented bespoke methods of logging in with a Substrate keypair to their own dapps, however we believe these fall short of the user-friendly and developer-friendly needs to truly function as a component that can be reused, as well as to grow an ecosystem of apps and services on top of a Substrate login:

    • The messages signed are unintelligble bytes, rather than human readable messages
    • The format of the login has not been standardized/structured to enable implementation into wallets/signers
    • The component(s) are not packaged, available and deployable in developer-friendly ways
    • The documentation doesn't exist that enables a developer to implement the sign-in functionality.

    Regarding managing a staking position, most institutional holders still use Polkadot.js, as it is the most longstanding and trusted tool, though due to a confuing UI, using it can easily lead to confusion or potential mistakes.

    Alternate methods of managing staking positions, such as Polkadot Staking Dashboard, are available to users, but they are focused on retail usage at the current time, and do not support the more complex needs of institutional or enterprise users.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Team leader: William Chen
    • Team members: Nipsey, Glide, Chris Ling

    Contactโ€‹

    • Registered Address: 2nd Floor Whitehall House, 238 North Church Street, George Town, PO Box 31489, Cayman Islands KY1-1206
    • Registered Legal Entity: Paraverse Foundation

    Team's experienceโ€‹

    William is the COO of Talisman. He has first hand experience with intricacies of managing fully-on-chain entities, including treasury management, distributed workforce compensation processes and other internal financial and operational processes on both Polkadot and Ethereum.

    Nipsey is the co-founder and CTO of Talisman. Nipsey leads the effort around Talisman's nomination pools, which, together, are the largest in Polkadot, containing over 3 million DOT.

    Glide has led a number of products in Web3 at Defi projects such as Sushi, DAOs including DeepDAO and on NFTs from 2017 before the ERC-721 standard. She has been a key contributor to Web3 product design community from 2018, speaking at events including Web3 Summit on User Data Design Considerations & Devcon on User testing practices for Mechanism Design. Prior to that, she led new product development and core banking transformations at large Banks and Financial institutions including BNP Paribas, Australian Super and UBS often working with industry regulators, compliance and security. Most recently she has worked in Defi, specialising in tokenomics design and implementing Multisigs on Ethereum to manage token distribution for DAOs and Treasuries.

    Chris has been a lead developer at a project in the Ethereum ecosystem, was previously on the identity team at Grab -- the only p0 (e.g. mission critical) team at the company -- and has worked on numerous web2 auth projects. In his spare time, he dabbles in MEV, Geth and Substrate.

    Various Talisman contributors will contribute on architecture, design, UX and testing.

    We have not previously applied for a grant at the Web3 Foundation.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    n/a

    Development Status ๐Ÿ“–โ€‹

    The product is currently being developed as a separate app inside the Talisman Portal repository (https://github.com/TalismanSociety/talisman-web/tree/multisig).

    For a UI walkthrough for existing functionality, please see this slideshow: Signet UI Walkthrough

    Conversations with W3Fโ€‹

    We have spoken briefly to David Hawig at the W3F to introduce the project, as well as to inquire about the W3F efforts to bring credit card processing/settlement to Polkadot (ISO20022, ISO8583). We also discussed the difficulty of staking (e.g. nominating or changing validators) today using Polkadot.js, especially as complex proxy and multisig structures come into play, which has informed this proposal.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1 month
    • Full-Time Equivalent (FTE): 1,5 FTE
    • Total Costs: 26,400 USDC

    Talisman uses a blended rate for grants and proposals (see previously funded initiatives here, here and here). This allows us to ensure the needed resources can be allocated to product development as well as running the company, including, as needed, to supplement the FTEs with the expertise of senior Talisman members as needed, with the goal of executing at our product quality standards. In this case, due to the value added program provided by the W3F and to show our support for the W3F mission in helping to bring new products and technologies into existence, we are applying a reduced rate.

    Milestone 1 โ€” Sign in with Substrate (SIWS) Releaseโ€‹

    We have modeled our substrate login functionality (Sign in with Substrate - SIWS) on Sign in with Ethererum, and we hope this can catalyze the development of applications that build upon Substrate keypairs. We will extract the work that we have in integrating the login with Signet into an independent package that can be integrated by any team, provide website and documentation around the package, and set this on the road to becoming a standard.

    Authenticating a user with a Substrate key was initially developed as part of Signet, however we believe it should have a number of improvements before it can be released as a service or component ready for use by third parties:

    1. The version as implemented uses the JSON format with minimal payload data and only supports the server-side nonce check. We should augment this by supporting a string field that can contain information such as a welcome message or the terms of service of the dapp.
    2. We will implement both text and JSON formats for the message to be signed, for both the presentation of the message client-side, and verification of the message server-side.
    3. We will implement a field for expressing time validity/expiration of the signature, as well as the corresponding server-side check.

    We will also create an example โ€œboilerplateโ€ NextJS Dapp that integrates SIWS.

    On the frontend: We will prepare 3 pages to demonstrate how SIWS works can protect an appโ€™s data:

    • Sign in page with SIWS button to trigger sign in flow
    • Signed in page that fetches a secret message from backend
    • Unauthorized page that does not have access to get the secret message.

    On the backend: We expose 3 API endpoints:

    • /api/nonce: To generate a nonce for user to sign on the frontend
    • /api/verify: To verify that the signed message is valid and issue a JWT
    • /api/secret: A protected endpoint that returns a secret text only if the JWT is valid

    The demo app will be in a configuration that enables developers to easily deploy it on Vercel.

    Weโ€™d like to address these improvements in the course of packaging Sign in With Substrate (SIWS) as a releasable component.

    • Estimated duration: 0,5 month
    • FTE: 1,5
    • Costs: 13,200 USD
    • Relevant Chains: Polkadot & Kusama
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up a SIWS service and authenticate wallets, which will show how the new functionality works.
    0c.Testing and Testing GuideWe will include documentation on verifying your SIWS integration is performing correctly.
    0d.DockerThis component will need to be integrated into a dapp before being deployed, so Docker is not applicable.
    0e.ArticleWe will publish an article that explains how the service works, the work done for this grant, and direction on how to integrate SIWS into other apps
    1.JS Package: Sign in with SubstrateWe will extract our Substrate sign-in service into an independent javascript package that is hostable and easily integratable into other projects
    2.Feature: Custom messageWe will add the ability to specify a custom message with the payload that can, for example, function as a welcome message from the dapp or specify the terms of service for the dapp
    3.Feature: ExpirationWe will add the ability for the front end to specify an expiration time for the signed message
    4.Feature: Message FormatsWe will add the ability to create the message payload both as a human-readable string, in addition to the existing JSON format
    5.Feature: Message VerificationWe will add the ability to verify the signed message payload in either string or JSON format
    6.Example: Integrate SIWS into SignetWe will integrate the newly created SIWS package back into Signet, replacing the initial implementation from before. This will allow Signet to function as a reference implementation for SIWS, including a front-end and back-end.
    7.Example: Create example dapp for SIWSWe will create an example โ€œboilerplateโ€ NextJS Dapp that integrates SIWS, including a frontend with login functionality and a backend that can verify the login and return data to logged in users.
    8.Public Docs: Sign in with SubstrateWe will create a public documentation site/landing page for Sign in with Substrate, in order to catalyze adoption by other projects, as well as eventual standardization.

    Milestone 2 โ€” Signet Staking Module Improvements re: Validator Selection & Rotation UIโ€‹

    We would like to improve the use cases (a.k.a. modules) enabled by Signet, by enabling user-friendly validator selection. We believe this is a core use cases for organizational and institutional multisigs in Polkadot/Kusama, and would be a foundational aspect of workflows to be built out in future releases. Currently selecting or rotating validators requires complex copy and pasting actions to assemble Polkadot.js Apps extrinsics, and we believe a purpose-built front end would alleviate the pain in performing the following actions:

    1. Selection/rotation of validators for a nomination pool where the nomination pool controller is a pure proxy controlled by a multisig
    2. Selection/rotation of validators by the stash, where the stash is a pure proxy controlled by a multisig
    3. Selection/rotation of validators where the staking proxy is a pure proxy controlled by a multisig.
    • Estimated duration: 0,5 month
    • FTE: 1,7
    • Costs: 13,200 USD
    • Relevant Chains: Polkadot, Kusama, AssetHub Polkadot, AssetHub Kusama
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up Signet, including the feature improvements here, which will show how the new functionality works.
    0c.Testing and Testing GuideWe run end to end tests on the application.
    0d.DockerWe support deployment from git at this point in time, and will have instructions on this in the repository.
    0e.ArticleWe will publish an article that explains Signet and the work done for this grant
    1.Feature: Nom Pool Validator SelectionThis feature enables an intuitive UX around viewing currently selected validators, as well as updating the validators for a nomination pool, using the nominationPools.nominate extrinsic
    2.Feature: Staking Stash Validator SelectionThis will build upon the feature above to present an intuitive UX around the selection of validators for a pure proxy stash, using the staking.nominate extrinsic
    3.Feature: Staking Pure Proxy Validator SelectionThis will build upon the above features to present an intuitive UX around selection of validators for a staking proxy which is a pure proxy backed by a multisig, using proxy.proxy and staking.nominate extrinsics

    Future Plansโ€‹

    Talisman initially embarked on the Signet project in order to "scratch its own itch" and bring it's user-friendly approach to multisigs. Signet has grown into its own project focused on larger enterprises and organizations, with the mission to build out a platform that enables institutional liquidity to flow in Polkadot.

    For SIWS, we are interested in promoting wider adoption, as we believe that it can unlock a use cases where off-chain data is combined with on-chain data, and this may span enterprise apps/integrations or even consumer apps or games. After this grant, we will take a look at how to garner support/adoption of the technology, and collaborate with others in the ecosystem to put this on the path to becoming a standard.

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    You can find more information about the program here.

    • Referrer: n/a
    • Payment Address: n/a

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Element

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    Financial Supportโ€‹

    The Signet team is an independent team within Talisman, and receives financial, development, UI/UX and testing support as necessary.

    Previous Workโ€‹

    Beyond the work in the initial treasury proposal referenced below, we have made a number of significant additions:

    1. CSV upload for easier batched sends
    2. An initial implementation of SIWS (in progress), Note - the addition of SIWS will remove the need to use the magic link.
    3. An initial address book implementation (in progress)
    4. Refactoring and rearchitecting to meet upcoming needs

    Previous Grantsโ€‹

    The initial version of this web app was funded by the Polkadot Treasury in February 2023.

    Polkadot Spending Proposal: Business-Friendly Polkadot Multisig

    This proposal is for a business-friendly multisig frontend to lower the difficulty for teams and businesses when running their financial operations on Polkadot. Teams currently face many difficulties when trying to perform these operations, risking mistakes along the way, and leading them to choose convenience over security. We will apply Talismanโ€™s UX and design philosophy to create improvements for standard workflows for Polkadot multisig usage (based on the current multisig pallet), and eventually integrate upgrades when improvements to the multisig pallet itself are available.

    - + \ No newline at end of file diff --git a/applications/sirato_substrate_phase3.html b/applications/sirato_substrate_phase3.html index c0369319739..a09c4223201 100644 --- a/applications/sirato_substrate_phase3.html +++ b/applications/sirato_substrate_phase3.html @@ -4,13 +4,13 @@ Sirato (Epirus) Substrate Explorer - Phase III | Web3 Foundation Grants - +
    Skip to main content

    Sirato (Epirus) Substrate Explorer - Phase III

    • Project Name: Sirato (Epirus) Substrate Explorer - Phase III
    • Team Name: Web3 Labs Ltd
    • Payment Address: Fiat payment address provided on invoice dated 23/06/2023.
    • Level: 2

    Project Overviewโ€‹

    We recently rebranded from Epirus to Sirato

    This is an application for a follow-up grant for the Epirus Substrate Explorer that has completed two grants previously:

    Phase I:


    [Application](https://github.com/w3f/Grants-Program/blob/master/applications/epirus_substrate_explorer.md)
    [Delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/527)

    Phase II:


    [Application](https://github.com/w3f/Grants-Program/blob/master/applications/epirus_substrate_phase_2.md)
    [Milestone 1 Delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/652)
    [Milestone 2 Delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/742)

    Overviewโ€‹

    From our previous grants we have built:

    • A Wasm contracts explorer that supports smart contracts deployed on pallet-contracts
    • A verifier service that verifies, through reproducible builds, the source code files for a specific on-chain code hash.

    In this grant, we intend to expand Sirato to support essential base data such as blocks, extrinsics and system events.

    Project Detailsโ€‹

    In our current architecture, there are several components:

    • Squid Archive (built on the Subsquid framework): the squid archive connects to the Substrate network node and indexes base data such as blocks and extrinsics, exposing a GraphQL API
    • Squid Processor (built on Subsquid framework): the squid processor ingests data from the squid archive, filtering and transforming the relevant data to the data models for the Explorer. Currently, our squid processor is focused on Wasm contract data from pallet-contracts. The squid processor exposes a GraphQL API.
    • Explorer UI: The explorer UI is made up of a set of composable components that consumes the API of the Squid processor and renders the web application.

    The below diagram illustrates the high-level architecture and how the components interact with each other:

    Current Architecture

    In this grant, we will add data handlers and data models for the base data. Since the Squid Archive directly exposes the network base data of blocks and extrinsics, we will use the GraphQL API of the squid archive in the UI to retrieve this data.

    Network Data Supportโ€‹

    The Squid Archive already exposes blocks, extrinsics and events data through its GraphQL API. We will consume this API from the explorer UI and build the components to show:

    • Blocks list
    • Extrinsics list
    • Block page: contains block details and all extrinsics and events included in this block
    • Extrinsics page: contains extrinsic details and all events emitted from the extrinsic

    Mock-upsโ€‹

    Mock up of how an extrinsic page will look:

    Extrinsic Page

    Technology Stackโ€‹

    We plan to build on top of our current explorer, so we will continue using the same technology stack:

    • Subsquid Framework, with Typescript, for data processing.
    • React.js and Tailwindcss for the UI

    Out of Scopeโ€‹

    Due to time and resource constraints, we will leave the following items for future development:

    • Additional query endpoints for interrogating the contract registry
    • The ability to interact directly with verified smart contracts

    Ecosystem Fitโ€‹

    There is currently a lack of high-quality open-source explorers for smart contract networks in the Substrate ecosystem. Polkadot.js is the de facto explorer and it is very modular and flexible. However, it was designed more for development and lacks the ability to filter, sort and search through data on the network. In the space of user-facing explorers, Subscan is currently the most popular solution and has the most comprehensive support for Substrate pallets. On the other hand, Subscan is mostly close-sourced and introduces an economic entry barrier for new networks.

    This dominance by Subscan is something that has been highlighted recently during an in-depth discussion on the Polkadot Forum.

    While a number of open-source alternatives have emerged, none of them have support for smart contracts. In our previous grants, we have expanded the open-source explorer offerings to include WASM contracts on Substrate. At the same time, we also want to provide the essential base data like blocks and extrinsics so that smart contract networks can have a feature-complete explorer at their fingertips.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1 month
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 25,000 EUR

    Milestone 1โ€‹

    NยบDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation of the code and documentation on how to set up an explorer instance.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. We will describe how to run these tests in the guide.
    0d.DockerWe will provide a Dockerfile and Docker Compose file(s) to ease the deployment and execution of the system.
    1.Updated Explorer UI - Base data supportThe Explorer UI will connect to the Squid archive GraphQL endpoint and display block, extrinsic and system event data.
    2.Public explorer instanceA publicly accessible instance of the Explorer connected to a development network with WASM smart contracts support, with additional display of blocks, extrinsics and events.

    Team ๐Ÿ‘ฅโ€‹

    Contactโ€‹

    • Registered Address: 7 Bell Yard, London, England, WC2A 2JR
    • Registered Legal Entity: Web3 Labs Ltd, CRN 10783824

    Team Code Reposโ€‹

    Future Plansโ€‹

    We plan to add open-source support to other popular Substrate pallets in the future. Some interesting pallets we are considering are assets and XCM related pallets, to be able to track asset movements across the DotSama networks.

    The Frontier EVM and EVM+ pallet by Acala are also valuable addition to the ecosystem that we wish to support at some point. On top of that, we also plan to add some proprietary modules for the explorer to be able to sustain our growth long-term. Our goal is to provide a full-fledged open-core explorer with comprehensive data and intuitive UI that networks can customise to their needs.

    Besides the core explorer, we also want to expand the functionality of our ink! verifier service. Right now, it only supports the verification and metadata hosting of ink! smart contracts.

    Our goal is to support any WASM smart contracts and evolve the service to a multi-VM metadata registry that can scale up to cater for the entire Substrate and DotSama ecosystems.

    - + \ No newline at end of file diff --git a/applications/skyekiwi-protocol.html b/applications/skyekiwi-protocol.html index 9fef0f8f326..c42481d2d4d 100644 --- a/applications/skyekiwi-protocol.html +++ b/applications/skyekiwi-protocol.html @@ -4,13 +4,13 @@ SkyeKiwi Protocol | Web3 Foundation Grants - +
    Skip to main content

    SkyeKiwi Protocol

    This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

    • Team Name: SkyeKiwi Team

    • Payment Address: 0xa5E4E1BB29eE2D16B07545CCf565868aE34F92a2

      *The above combination of your GitHub account submitting the application and payment address will be your unique identifier during the program. Please keep them safe.**

    Project Overview ๐Ÿ“„โ€‹

    The SkyeKiwi Protocol is a generic, efficient and customizable secret sharing protocol for end-users and blockchain nodes.

    Project Detailsโ€‹

    The SkyeKiwi Protocol hides secrets under bright day lights. It is designed to be generalized useable blockchain library to package/manage encrypted content on blockchain. We designed it to be capable of efficiently processing a few bytes to GB size of secrets. It's a series of cryptographic process with help of storage network and smart contract/Substrate runtime pallet.

    The process can be graphed as:

    Group 1

    It will take in a two inputs: a byte stream wrapped under the File API, an EncryptionSchema that outlines the sharing behavior and an optional SealingKey and any related blockchain identity seed/signer.

    The high level wrapper of the SkyeKiwi Protocol exposes four APIs: upstream, donwstream, updateEncryptionSchema and verifyProofOfAccess. And will be released in two phase:

    1. Phase One - PoC Phase: Connects to a smart contract of a Substrate style WASM smart contract enabled blockchain; the Crust Network for storage; Public IPFS Pin Service & Gateways, with a SkyeKiwi ran IPFS Cluster as backup IPFS nodes.
    2. Phase Two: Connects to the SkyeKiwi Network pallet-secrets instead of a smart contract for general secrets registry; the Crust Network for storage; Public IPFS Pin Service & temporary IPFS nodes from the Crust Network ecosystem solutions.

    Usage Example on Node.js/Browser:

    const mnemonic = process.env.SEED_PHRASE
    const blockchain = new SkyeKiwi.Blockchain(
      // seed phrase
      mnemonic,
      // contract address
      '3cNizgEgkjB8TKm8FGJD3mtcxNTwBRxWrCwa77rNTq3WaZsM',
      // contract instance endpoint
      'wss://jupiter-poa.elara.patract.io',
      // storage network endpoint
      'wss://rocky-api.crust.network/',
    )

    const encryptionSchema = new SkyeKiwi.EncryptionSchema({
      numOfShares: 2, 
      threshold: 2, 
      author: author, 
      unencryptedPieceCount: 1
    })
    encryptionSchema.addMember(author, 1)

    const key = new SkyeKiwi.Seal({
      encryptionSchema: encryptionSchema, 
      seed: mnemonic
    })

    // upstream the file, it take two major actions: 
    // upload files to the Crust Network & Write to a smart contract to generate a vaultId
    await SkyeKiwi.Driver.upstream({
      file: fileHandle[0].file,
      seal: key,
      blockchain: blockchain
    })
    const stream = fs.createWriteStream(outputPath, {flags: 'a'})
    await SkyeKiwi.Driver.downstream({
      vaultId: vaultId,
      blockchain: blockchain,
      keys: [key1, key2 ... ], // private key of recipeints
      writeStream: stream,
    })
    // upon finishing, the encryptionSchema will be updated
    await SkyeKiwi.Driver.updateEncryptionSchema({
      vaultId: vaultId,
      newEncryptionSchema: encryptionSchema,
      seed: mnemonic,
      keys: [key1, key2 ... ], // private key of recipeints
      blockchain: blockchain
    })

    Technology Stackโ€‹

    1. Cryptographic Library: tweetnacl for x25519 encryption/decryption, xsalsa20-poly1305 symmetrical encrypt/decrypt
    2. Random Number Generator: tweetnacl - randomBytes OR browser crypto APIs.
    3. Threshold Secret Sharing: @skyekiwi/secrets a fork of audited SSS library secret.js
    4. Crust Network for persistent storage
    5. ink! wasm smart contract & smart contract dev kit by Patract Labs
    6. Substrate for pallet-secrets
    7. IPFS JS - the JavaScript IPFS implementation
    8. Polkadot.js - to operate well in browsers & add in support for encryption/decryption and curve conversation

    Ecosystem Fitโ€‹

    The SkyeKiwi Protocol has a wide applicable areas. It's a generalized and customizable solution. For instance:

    • Extend the NFT landscape to introduce NFTs with concealed content and strict access control of the content
    • Contract signature, build a decentralized contract signing platform, a DocuSign alternative.

    Moreover, SkyeKiwi will take the SkyeKiwi Protocol and built into the SkyeKiwi Network featuring concealed smart contract execution and secret processing. Where the SkyeKiwi Protocol is the schema used to communicate between blockchain nodes and between end-users to blockchain nodes.

    Team ๐Ÿ‘ฅโ€‹

    Contactโ€‹

    • No legal entity yet

    Team's experienceโ€‹

    We have a draft implementation of the SkyeKiwi Protocol under development of SkyePass for a Web3 Foundation grant and delivered the PoC as the first milestone. We had won first place in the Polkadot Hackathon by Web3 in India with the SkyeKiwi Protocol and one of its application.

    Development Status ๐Ÿ“–โ€‹

    We have implemented a very very drafty version of the SkyeKiwi Protocol as part of our previous application to SkyePass. Under our discussion in LINK we are now extracting the SkyeKiwi Protocol development out from the original grant application and port our previous work on this new application.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4 months (16 weeks)
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: $30,000 (payable in DAI)

    Milestone 1 - Phase 1โ€‹

    Phase One - PoC Phase: Connects to a smart contract of a Substrate style WASM smart contract enabled blockchain; the Crust Network for storage; Public IPFS Pin Service & Gateways, with a SkyeKiwi ran IPFS Cluster as backup IPFS nodes.

    • Estimated duration: 2 month
    • FTE: 2
    • Costs: 12,000USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can integrate the SkyeKiwi Protocol into their project.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests on both Node.js and Browser environment.
    1.Core ProtocolImplements the upstream downstream updateEncryptionSchema and verifyProofOfAccess APIs.
    2.Smart ContractImplements and test for the smart contract used for registering secrets and access control write access to the secret.
    3.Polkadot.jsAdd in encryption/decryption functionality to @polkadot/keyring and @polkadot/extension so that the protocol can run without the needs to read the private key of users.

    Milestone 2 - Phase 2โ€‹

    Phase Two: Connects to the SkyeKiwi Network pallet-secrets instead of a smart contract for general secrets registry; the Crust Network for storage; Public IPFS Pin Service & temporary IPFS nodes from the Crust Network ecosystem solutions.

    Note: We won't be 100% sure of the availability of the Crust Network temporary IPFS solution but will actively engage with the Crust Network for this part. Therefore, we'd like to mark it as optional. Worst thing worst, we still have our own IPFS cluster running.

    • Estimated duration: 2 month
    • FTE: 2
    • Costs: 18,000USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can integrate the SkyeKiwi Protocol into their project.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests on both Node.js, Browser and Rust environment.
    1.pallet-secretsPort the ink! smart contract to be a runtime pallet and integrate it to the SkyeKiwi Protocol source code.
    2.Rust ImplementationPort the SkyeKiwi Protocol to Rust, so that it works between blockchain nodes as well.

    Future Plansโ€‹

    We will build a Substrate based blockchain with the SkyeKiwi Protocol. The blockchain is gonna feature:

    1. Three registry: registry for SecretKeeper Nodes (TEE enabled nodes who keep a secret and process state transition functions on secrets), registry for general secrets (included in Milestone 2), registry for encrypted states (encrypted states are secrets that represents the state of secret contracts, the registry will mark the lazy execution position, checkpoint status of these states, and which nodes are processing the secrets).
    2. Two Rotation: the small rotation - on par with the session key rotation of Substrate, the big rotation - rotate the sealing key of the encrypted states in TEE enclaves, and package the current states of the secret with the SkyeKiwi Protocol and publish it to the registry
    3. One Lazy Execution Queue: an append-only log that records all transactions happened on a secrets, that can be subscribed by any nodes with access to the secret.

    The blockchain (SkyeKiwi Network) will be able to execute concealed smart contract executions.

    - + \ No newline at end of file diff --git a/applications/skyepass.html b/applications/skyepass.html index 0b22fca1112..61b23122941 100644 --- a/applications/skyepass.html +++ b/applications/skyepass.html @@ -4,13 +4,13 @@ SkyePass | Web3 Foundation Grants - +
    Skip to main content

    SkyePass

    This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

    • Team Name: SkyeKiwi Team
    • Payment Address: 0xa5E4E1BB29eE2D16B07545CCf565868aE34F92a2
    • Status: Terminated

    The above combination of your GitHub account submitting the application and payment address will be your unique identifier during the program. Please keep them safe.

    Project Overview ๐Ÿ“„โ€‹

    SkyePass is a decentralized and customizable identity management software. On the surface, it is a decentralized, open source and modern password manager.

    Product Detailsโ€‹

    As a long-term password manager software user myself, I have been really frustrated of the services like LastPass, 1Password for either lack of functionalities or the idea of storing ones entire digital identity on their corporate servers. Existing open-source solutions are too technically complicated to use.

    At the very basis of it, a password manager is no more than an encrypted database, an APP and a browser extension to interact with the database.

    Therefore, our team create a new password manger software that has pretty and intuitive UI/UX, fully decentralized (i.e. our team own no backend servers) and hackable by providing an open API for people to develop extensions with.

    Users who signup will first create a blockchain wallet and have the mnemonic (and a master password) as their sole identity credentials (pretty standard blockchain wallet stuff). Later, each database instance is called a vault (standard name for all password managers) and they are light-weight file based databases (lowDB seems to be a great choice). User can be given options to choose the encryption behavior of their database. By default, the vault will be split into some pieces with a Shamir's secret sharing mechanism.

    For instance, for a simplest sharing schema, when the vault is created to be shared with 2 other family members, the vault will be split into 4 parts (we call them horcrux, for those who do not know the Harry Potter reference ) with a minimum quorum of 2 to be decrypted. One piece will be sent to IPFS without encryption, the other 3 pieces will be encrypted by each member's public key and be sent to IPFS. An NFT will be minted for the owner. The ID of the NFT will be the vault ID and the NFT's URI will be a metadata piece that only the owner can change as exampled below:

    {
        "pieces": 4,
        "quorum": 2,
        "nounce": 18,
        "owner": "5Ef9ES1SLQZU4KucGsjvs8qexvppQFmDgHiqoqVptJ9nZDeu",
        "members": [
            "5EKj6S1SLQZU4KucGsjvs8qexvppQFmDgHiqsdsdtJ9nZ123",
            "5EJK1S1SLQZjkLKucGsjvs8qekdjpQFmDgHiqoqVptJ9nZ978"
        ],
        "unencrypted_cid": "QmaTX2v2QuwkQvEERw17w2xACcr2WZhy9t3NAEPBjvqPSX",
        "encrypted_cids": [
            {
                "cid":       "QmaTX2v2QuwkQvEERw17w2xACcr2WZhy9t3NAEPBjvqPSX",
                "member": "5EKj6S1SLQZU4KucGsjvs8qexvppQFmDgHiqsdsdtJ9nZ123"
            },{
                "cid":       "QmaTX2v2QuwkQvEERw17w2xACcr2WZhy9t3NAEPBjvqPSX",
                "member": "5EJK1S1SLQZjkLKucGsjvs8qekdjpQFmDgHiqoqVptJ9nZ978"
            }, {
                "cid":       "QmaTX2v2QuwkQvEERw17w2xACcr2WZhy9t3NAEPBjvqPSX",
                "member": "5Ef9ES1SLQZU4KucGsjvs8qexvppQFmDgHiqoqVptJ9nZDeu"
         }]
    }

    The reason why we design such mechanism serves 3 purposes.

    1. Reserve the capacity for advanced users to create more complicated sharing schema.
      • For instance, a user can create a vault and assign trustee to take over one's estate when the user passes away. The user can split the vault to 5 horcrux and set the minimum decryption quorum to 3. 2 pieces encrypted with the user's own public key, 1 piece encrypted with a trustee A's public key, 1 piece encrypted with another trustee B's public key and 1 last piece to the user's lawyer. In event of death, A and B can go to the lawyer and decrypt the vault and inherit the user's digital identities.
      • A team can create a vault that requires 2 members to decrypt a vault, or require the owner's piece to decrypt a vault etc.
    2. Because the historical metadata states are all stored on the blockchain, it is not hard to rebuild the change history of the vault.
    3. Make it easier to check the integrity of the vault and recover the vault.
    4. Leave the option open for future commercial projects to offer zero-knowledge vault backup service.

    To manage access for users, we assume two common roles: write and read and, of course, owner. Because each time when the database is updated (i.e. new password saved), the IPFS CID will be updated, managing access is easy. The owner can add the member's address to be approved to change the URI in the smart contract and be responsible to update all CIDs when a client is updating the database. While those who have a horcrux but not in the approved list in the smart contract, they cannot update the database because they cannot update the metadata.

    So far, we have discussed a system to securely create, share and manage a minimalism decentralized file-based database. Our team believe there are more we can do with the database file itself and that's why we are calling SkyePass hackable. If we think about blockchain wallet applications, they are web applications that store some private keys and call APIs like Web3.js. Taking inspiration from Ledger, we believe if we expose some APIs for developers to make extensions(like the idea of Applications for Ledger), we can make a password manager infinitely interesting. Because the vault is shareable to others, users can share a whole workspace to others will all sensitive information included. These extensions can be made both in a desktop applications or a browser extension.

    Some ideas we have had so far:

    • Crypto Wallet: shared hot wallet. The owner of the vault can install an Ethereum extension and store the private key with it. And, of course, DApp browsers.
    • SSH Login Tool: a whole team can share login credential to their server effortlessly.
    • Shared Phone Number: a shared Google account that registered on Google Voice can be stored, and the whole family can receive verification code for services.

    Password Manager & an Identity Management Solutionโ€‹

    Based on some thinking of the basis nature of NFTs. We believe that a password manager is an ideal medium to deliver tokenized digital identities. Therefore, we think each username-password-OTP combination as an atomic token, a vault as a collection of these identities, and an extension as a service injected with an identity.

    • If we assume all identity tokens have two states: "public identity" or "private identity". A public handle is the public identity of a user. (i.e. a twitter handler, a Github handle or a Venmo handle etc. ) Therefore, we are building a solution to link to one's public off-chain profiles. Also, we can implement a ENS-like or @username style handle system.
    • Therefore, simple sharing behavior (i.e. share my spotify account to my girlfriend) can take two forms: if she has an account with this password manager, simple @her, set some rules for using this password(or not) and press share. If she has not, a one time sharing link will be sent, her browser will generate an ephemeral key pair, and that ephemeral key pair will be used to encrypted the entry and send the encrypted password entry over and make it self-destruct soon.
    • For teams or families, they are using a shared identity. They can link their profiles and get a handle like @team, while the team will use some secret sharing schema for privilege management.

    For more on this, please refer to Future Plan/Integrated Identity Solution section.

    Ecosystem Fitโ€‹

    I don't think there are anything like SkyePass so far, both within the Substrate community or all blockchain communities. The reason that Substrate will be an ideal platform for SkyePass is because the flexibility the framework offers. We plan to deploy 4 smart contracts:

    • Contract 1: A NFT contract that issues an NFT token for vault creator, store metadata of the vault and manage permission to update the vault. (the vault metadata contract)

    • Contract 2: A NFT contract that generate an NFT token that represents an atomic digital identity to users (the atomic digital identity contract)

    • Contract 3: A generalized handle system (an ENS-like system) on a Substrate-based chain that issue user handle ownership NFTs (the substrate identity handle contract)

    • Contract 4: An identity control smart contract that verify and store off-chain user handle(s), in compliment to the substrate identity handle contract (the off-chain identity linkage contract)

    From all smart contract platforms, we choose the Substrate stack for development because:

    • When more customizations are needed, we won't be limited by the platform. The option to develop a parachain is still available.
    • Because these identity management smart contract is designed to be more generalized, we have the option to deploy them on different chain. For instance, we can deploy contract 1 and 2 to a faster/less secure/low tx cost focused parachain. While, contract 3 & 4 to a secure and relatively more decentralized parachain. Most likely we will not mess with Bridging of the Substrate stack but the option is still open for future.

    For extensions: we plan to host a Github public repo as described in Milestone 2

    UI/UX Mockupโ€‹

    MacBook Pro - 5

    MacBook Pro - 1

    MacBook Pro - 2

    MacBook Pro - 4

    MacBook Pro - 3

    Cross-Comparison with Other Password Managersโ€‹

    We have not included all popular ones. These are just ones we have actually used.

    SkyePass1PasswordLastPassNordPassRememBearKeePass
    Release Year202120062008201920182003
    Zero-Knowledge VaultYesYesYesYesYesYes
    Product TypeOpensourceCommercialCommercialCommercialCommercialOpensource
    Account & Vault MetadataStored On BlockchainCorporate ServersCorporate ServersCorporate ServersCorporate ServersLocal by default
    DecentralizedYesNoNoNoNoKind of
    2FA Login ProtectionNoYesYesYesNoN/A
    Shared VaultYesYesNoNoNoKind Of
    Custom Sharing SchemaYes & expose APIs to do soYes. With Business accountsNoNoNoWith plugins
    Intuitive & Morden UI/UXIntuitive and BeautifulGood but Not IntuitiveIntuitive But not so BeautifulIntuitive and BeautifulIntuitive and Astonishing; Possibly the BestOld, professional users only
    Fill Web Forms & Websites Auto LoginYesYesYesYesYeswith plugins
    Password Strength ReportNot by default but open for pluginsFantasticGoodOKOKNo
    Digital LegacyYes!NoYesNoNoNO
    Import From BrowsersNot Now. Will be Supported after Beta ReleaseYesYesYesYesWith plugins
    ExtensibilityCore Feature!NoNoNoNoYes!

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    • No legal entity yet

    Team's experienceโ€‹

    Besides private work for companies that cannot be shared, Song developed a simple server-less React.js Blog system(can be seen on his Github profile); a private event participation checkin application, based on Ethereum smart contract, React.js for frontend, Coda.io API and a Telegram bot for administration.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 16 weeks
    • Full-time equivalent (FTE): 2.5 FTE
    • Total Costs: $28,500

    Milestone 1 โ€” PoCโ€‹

    • Estimated Duration: 3 Weeks

    • FTE: 2

    • Costs: 6480 DAI (2 FTE 35 Hours per week 3 Weeks * $38 Hourly Wage. Of course, I'll be surprised if we will actually work less than 50 hours per week.)

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationsA guideline of how to run and test all functionalities described below.
    1.Smart ContractThe core smart contract that store IPFS hash, generate unique vault ID and implement access management.
    We are using ink! and the smart contract development suite maintained and developed by Patract Labs for developing environment, unit testing and deployment.
    2.Client Side PoC1. Local data storage schema and adapters with lowDB
    2. IPFS (add, cat, pin) on the Infura IPFS nodes;
    3. ECIES encryption & decryption with eccrypto
    4. Shamir secret sharing with a simplest 4/2 schema powered by audited lib Secrets.js
    5. A full run down of the process (from a user creating a vault, add in some password items, to the encryption, publish to IPFS, interact with a local blockchain, to access management when sharing with two other users)
    6. Unit testing for most of these functionalities
    3.Client Side UI/UXan simple Electron UI/UX not wired up with logic yet

    Milestone 2 โ€” Desktop App & Browser Extensionโ€‹

    • Estimated Duration: 10 Weeks / Est. Start Early 2022

    • FTE: 4

    • Costs: 22,020 DAI

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.Developer Resource/API Documentation/Community- A comprehensive API spec documentation
    - Riot group for support, suggestions and questions
    0c.Security AuditingAudited by a trusted 3rd party
    1.Desktop App/Browser ExtensionCreate an open Github repo for extensions, build a management system for open PR of new integrations. The "marketplace" in the desktop app will pull a list of available integrations from the repo.
    Support at least 2 password importing source
    Support unencrypted password exporting
    Add in support for browser extension to inject hot wallet like Metamask
    Desktop App
    A React.js + Electron App. The App will implement as close as possible to the graphic design (per 3).
    - Wallet Creation / Backup Phase / Create Master Password
    - Wallet Import / Signin
    - Autolock after timed inactivity or manually lock the App
    - Create/Share/Manage Vaults
    - Add/Update/Delete Password Items (with 2FA OTP support)
    - Add/Update/Delete Secure Note/Credit Card
    - Basic ETH wallet extension
    - Basic Polkadot wallet extension
    - Application Marketplace
    - sharing a single password item directly to another user

    Browser Extension
    - Communication to Desktop Application
    - Auto-fill account/passwords

    2.Smart ContractsAll contract tested and audited and we will deploy the V1.0 contract to the appropriate parachains.
    4.Mobile AppsDraft up UI/UX designs for mobile apps.

    Future Plansโ€‹

    We do plan to build a for-profit business and seek equity investments, but we believe that a good password manager should be a common goods.

    For the core password managerโ€‹

    For local usage, that means no syncing between devices, no sharing with others, we think it would be absolutely ridiculous to charge people for that, because it basically does not cost us anything. However, for other use cases, on a public V1.0 launch, there can be cost related to IPFS storages and smart contract calls, but it is gonna be way cheaper than any other commercial products. I think it would be safe to assume a cost of \$2/year for one user with extra-heavy usage. For a team of 10 people, 1Password will charge (\$7.99 X 12 months X 10 users) \$960 per year. SkyePass will change this charging schema.We want to make the pricing as transparent as possible.

    When a user, Alex, created a wallet/account and choose to go for "premium features" (i.e. syncing between devices, sharing with others etc.). We want to ditch the idea of "Alex's account at SkyePass" but to "Alex's account on a generic blockchain". Alex can fund her account either by transferring some funds from Coinbase or other crypto wallets, or we will hook up a credit card to crypto portal (like MoonPay). We are going to give Alex a simple estimation calculator of how much she would need to top-up per year based on how many devices of vaults she plans to create and share. Usually, for a typical user (add in 300 items, password, notes or credit cards, one vault for herself, one vault for the family and one vault for work), we would recommend somewhere about \$5 per year compare to a $40 bill I pay for a commercial alternative. A percentage (somewhere between 20% to 40%)of the inbounding funds will be taken to form a treasury. And, of course, we will show Alex how much she can save compare to commercial options. Alex has complete control over her account. She can send out the funds she holds other wallets when she wants. When she is sharing a vault with others, she can choose to send funds to other's account if she allows them to make changes to the vault.(Just in the same way when a team leader of a team handles all bills for a SaaS product).

    In summary, we are giving the freedom back to our users and let them decide how they want to pay. We will design UX to make managing funds really easy like a commercial alternative.

    Integrated Identity Solutionโ€‹

    1. We plan to build an auction market for user handle on a Substrate-based public chain. (refer above in More Potential For a Password Manager)
    2. We plan to build a market for trading digital identities.
    3. We plan to offer the identity solution in a consulting package for business teams.

    Hardware Wallet Integrationโ€‹

    We can also create a special version of SkyePass (or a special login method to use hardware wallet) to support only vault creation from hardware wallet.

    Meta Transactionโ€‹

    One of the main reason that we choose Substrate/Polkadot is because we can choose a suitable chain to interact with smart contract calls fast and cheap. The option to develop commercial meta transaction or state channel solutions on Polkadot is still open for consideration.

    Backup/Secret Keeping Nodesโ€‹

    Because we are building a Shamir secret sharing mechanism at our very core encryption schema, we can explore the idea of providing an optional, commercial and centralized backup nodes.

    Marketplaceโ€‹

    We allow and encourage our community members to build paid extensions on top of our APIs. One idea can be a subscription-based password watchtower service and like all platforms, we will take a percentage of the proceeding to the treasury.

    Treasuryโ€‹

    Treasury is built for those who contributes to the community: those who translate documentations, those who build extensions and those who contribute to the core code base. SkyeKiwi team will permanently hold 29% voting rights in decisions and 3 veto rights per calendar year, partners before the official launch will also be granted 20% voting rights. And we leave the rest to all other treasury contributors proportionally. These numbers or proposals are not final. We still have a lot to figure out.

    Additional Information โž•โ€‹

    • We have a simple PoC of the core encryption schema built up in a sandbox. UI/UX and other graphic resources are made.
    • We have not applied for other grants yet.
    - + \ No newline at end of file diff --git a/applications/skynet-substrate-integration.html b/applications/skynet-substrate-integration.html index d984b9a4d6a..eb5db8661b7 100644 --- a/applications/skynet-substrate-integration.html +++ b/applications/skynet-substrate-integration.html @@ -4,13 +4,13 @@ Pallet for Decentralized Off-Chain Storage on Skynet | Web3 Foundation Grants - +
    Skip to main content

    Pallet for Decentralized Off-Chain Storage on Skynet

    • Team Name: Skynet Labs
    • Payment Address: ETH 0xa4e14Aa5F82Cd903d97BE09B921c97E7Fc43d909

    Project Overview ๐Ÿ“„โ€‹

    If this application is in response to an RFP, please indicate this on the first line of this section.

    If this is an application for a follow-up grant (the continuation of an earlier, successful W3F grant), please provide name and/or pull request of said grant on the first line of this section.

    Overviewโ€‹

    Our intention is to build the initial parts needed for an integration with Skynet, allowing Substrate developers to make use of decentralized off-chain storage from any project using FRAME.

    Skynet is a decentralized storage and web application platform built to use the Sia blockchain network for storage, but in a way that's accessible via the web and available to anyone, without concerning themselves with cryptocurrencies or special software. Skynet provides hosting of robust web-app frontends and storage of application data in a way where users retain control over their data and application data is interoperable between applications.

    Off-chain storage is an important problem to solve for blockchain applications, and Skynet meets storage needs well on several fronts by providing:

    • a decentralized architecture matching the ethos of blockchains themselves
    • strong, cryptographic guarantees on immutable data
    • mutable data using private keys for write access
    • portals used to access data, allowing for either managed access or running your own software. (With managed access, users and developers don't have to integrate another cryptocurrency running on a separate chain into their architecture.)
    • equal access to Skynet no matter what portal is used or how it is accessed

    Our team wants to take on this project to expand the possibilities of what can be done with web3 applications and decentralized storage.

    At this point, we have a JS SDK to easily expose Skynet in the browser to users, who can upload files and then store the unique URI (skylink) on-chain. Later, those can be retrieved and easily downloaded in the browser. We'd love to see developers building applications where blockchains themselves can interact more deeply with Skynet, writing data to Skynet, either for later access or for consumption by other web applications.

    Project Detailsโ€‹

    In its final form, the Skynet Substrate SDK made for use in Off-chain Worker Pallets would allow projects built with Substrate FRAME to access any Skynet Portal on the network using off-chain workers in order to do the following on Skynet:

    • Upload a file or directory and return the skylink for use by the runtime
    • Download a skyfile to storage or for use by runtime
    • Registry Read: read from Skynet's mutable data layer using public keys
    • Registry Write: write to mutable storage, authenticated by signing using a private key
    • Support any Skynet portal and portal account
    • Support v2 Skylink compatability
    • Interact with mutable SkyDB and MySky files
    • Data Verification for all interactions with a portal, using storage proofs from the Sia network.
    • Subscribing to registry entry changes (pending future Substrate development of long-running off-chain worker processes).

    Communication with portals happens by utilizing portal HTTP APIs along with additional processing and cryptography on the client-side. Although Skynet interaction can appear to be merely REST-styled API requests, certain cryptographic tools are needed to 1) created well-formed requests and 2) verify the cryptographic proofs and signatures returned alongside HTTP responses. Without this additional tooling that requires "client-side" processing, most of Skynet's power is cutoff from the application.

    In addition to this, decentralization is at the core of Skynet's ethos, so the SDK must account for additional complexities over interacting with portal APIs that might not exist for a traditional API endpoint, including supporting portal accounts (similar to authorization), dealing with not-shared-in-common portals (where nodes could supply their own portal URL and API key), and porting our Skynet utility libraries to Rust to ensure full inoperability with browser javascript applications and creating and signing items like registry entries to enable SkyDB and Skylink v2 (allowing content updating for a constant URL which can point to immutable skyfiles). For greater clarity and flexibility, we will separate the example pallet codebase from the SDK library of action and helper utils.

    To be more specific on the functionality needing to be built out in Milestone 1:

    Note: This work is implementing interaction with a pre-existing protocol, so much of the work will be porting code from our Javascript SDK to Rust in a way that feels ergonomic for Substrate developers.

    Authentication & Portal Preference for HTTP Requestsโ€‹

    • All below actions requiring interaction with a Skynet portal should be assumed to be interacting only with the preferred portal and using an authentication mechanism. (Currently we support only encrypted JWTs, but may extend to API keys too.)
    • For example, repinning Skylinks requires a simple HTTP request with optional authentication.

    Immutable Skyfilesโ€‹

    • Skyfile downloads are just HTTP GET requests.
    • Skyfile uploads come in 2 varieties:
      • Small Files: Simple HTTP POST requests that return a skylink from the portal
      • Large Files: Orchestrated HTTP requests implementing the tus protocol for increasing reliability by retrying failed chunks.

    Mutable Registry Entriesโ€‹

    • Registry entries have a specific structure including a public key, data key (which together identify it for lookup), a revision number, data (limited to 70 bytes), and a signature signing the aforementioned using the public key's corresponding secret key.
    • Reading registry entries involves making an HTTP GET request, then verifying the signature against the data (Key pairs and signatures all using ed25519).
    • Writing registry entries involves creating a registry entry (getting the revision number can be done by first reading, or trusting you know the correct revision), and then signing the entry before making a POST request to the portal.
    • Registry entries have a complicated concurrency model, so attention will need to be given to revision number usage and tracking.
    • Registry entries are the core mutable primative for the rest of Skynet, including MySky, SkyDB, and Skylinks v2. The 70 bytes can be used to create custom data structures and is enough space to hold 2 Skylinks.
    • For creating a Skylink v2, this is a coordination of getting or creating a Skylink to point at, converting the link from Base64 to a byte array, and writing this to a registry entry. This data field then acts like a pointer in the Skylink v2.
    • Then a hash of the public key and data key is taken and encoded into a skylink format (combining with a version number) before encoding to Base64 to generate the v2 Skylink.
    • Reading a Skylink v2 involves a GET request, which returns the data from the pointed to immutable Skylink (if the Skylink v2 points to another Skylink v2, if acts recursively until immutable file is resolved). The portal also returns a "proof" containing the chain of registry entries (each a Skylink v2) that need their signatures verified.

    For this grant, we seek the support of the Web3 Foundation for doing an initial build-out of Skynet functionality. The Skynet Labs team (formerly Nebulous, creators of the Sia blockchain network) have extensive experience in blockchain development, but have much less experience in Rust and the Polkadot ecosystems. We would view this as an opportunity to build out support for many of the Skynet primitives and utility functions while working to find the most developer friendly way of exposing those to applications building with Substrate.

    For more information on Skynet and our SDKs, see our support guide and our SDK documentation.

    Ecosystem Fitโ€‹

    The most similar project in the ecosystem that we are aware of is the offchain:ipfs fork of Substrate that implements an ipfs node in Rust along with an example pallet.

    IPFS has many differences in performance, ease-of-use, availability and infrastructure as compared to Skynet. The most critical to this conversation is that Skynet Web Portal take care of much of the overhead that an IPFS node would, but without equal data verifiability guarentees. Because of this, we do not intend to need to make modifications to Substrate core for integration, instead working from the perspective of a pallet, allowing for easier maintenance and community up-take in the long term.

    Some use cases where we believe Skynet will be useful for Substrate devs:

    • Chains where interaction focuses on client-side web apps
    • Off-chain storage for NFTs
    • On-chain referencing of user-generated-content
    • Indirect communication for chain-external data (where another service can publish to skynet, to be consumed by the off-chain worker)
    • Persistance of runtime data that isn't saved to storage
    • Off-chain publishing of on-chain data

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Leader: David Vorick, CEO | Skynet Labs
    • Skynet Labs Team Members including:
      • Chris Schinnerl
      • Peter-Jan Brone
      • Matthew Sevey
      • Daniel Helm
      • Marcin Swieczkowski
    • Skynet Labs Community Contributors:
      • TBD
    • Polkadot Ecosystem Collaborators:
      • TBD

    Contactโ€‹

    • Registered Address: 177 Huntington Ave Ste 1703, PMB 71942, Boston, Massachusetts 02115-3153 US
    • Registered Legal Entity: Skynet Labs

    Team's experienceโ€‹

    The Skynet Labs team (recently renamed from Nebulous) was responsible for the development and oversight of the Sia blockchain network and several projects in its ecosystem for many years. The team's most recent significant project is Skynet, a web-accessible decentalized storage protocol built to enable usage of Sia storage for users and developers without reliance on running any specialized software or obtaining any cryptocurrency. Skynet hosts over 200 community-created web apps, and has seen many signifigant partnerships and integrations.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Preliminary research has been undertaken into the Polkadot ecosystem generally and substrate development specifically for the purposes of writing this proposal, along with coordinating with the Web3Foundation and Parity team member to make sure the the implementation plans and technical details were thorough and sensible.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 8 Months
    • Full-time equivalent (FTE): 0.1875 FTE (see)
    • Total Costs: $30,000

    Milestone 1 - Exploratory Skynet Immutable Off-Chain Storage SDK (Immutable Data Functionality)โ€‹

    • Estimated Duration: 8 months
    • FTE: 0.1875 FTE
    • Costs: $30,000
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and technical documentation that explains how a user can use the SDK in a pallet for basic off-chain functionality.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Sample Node with OCW Pallet & Read-Only FrontendWe will document and provide a node and frontend for a trivial use case that integrates our SDK into an example ocw-pallet based off the Substrate Node Template. This also acts a minimal implementation example for developers to see how to use the SDK.
    1.Skynet Substrate SDK for Off-Chain Worker Pallet (Skyfiles)We will create a pallet to interact with Skynet from an off-chain worker. For Milestone 1, this will include uploading and downloading immutable files from Skynet using content-addressable skylinks, tying these uploads to a portal account.
    2.Skynet Substrate SDK for Off-Chain Worker Pallet (Registry Entries)Additional logic necessary to derive secret and public keys from a seed, construct registry entries, sign them and verify signatures. This is the core mutable primative needed for other mutable data.
    3.Skynet Substrate SDK for Off-Chain Worker Pallet (Skylink V2)Building on registry entries, we will create the functionality to create and access v2 Skylinks. These are Skylinks that point to other Skylinks, which the portal resolves and returns the pointed to immutable skyfile.
    4.Skynet Substrate SDK for Off-Chain Worker Pallet (Repin)Expose the ability to request that a portal pin an already exisiting Skyfile by only passing the skylink.

    Future Milestone - Skynet Immutable Off-Chain Storage Pallet (Mutable Data Functionality)โ€‹

    We intend to take the lessons learned from the first version of this pallet and extend Skynet functionality according to the needs of developers. What follows are some steps we would look to take outside of the scope of this grant.

    NumberDeliverableSpecification
    1.Skynet Substrate SDK for Off-Chain Worker Pallet (SkyDB and MySky File support)We will extend the SDK from milestone 1 to interact with the primatives built on Skynet's registry. This mutable storage layer acts as key-value database from which SkyDB and MySky files are constructed. This allows getting and setting arbitrary data and pointing to JSON files, encrypted files, and arbitrary skyfiles pointed to by consistent MySky file paths. These use public/private key combinations for access-control. This will also contain functionality for generating decryption and derivation keys that are interoperable with Skynet's MySky SDK.
    2.Skynet Substrate SDK for Off-Chain Worker Pallet (Verification)We will extend the SDK from milestone 1 to allow for two important features: Verification of storage proofs for full end-to-end trustless infrastructure, and, pending Substrate's addition of long-running off-chain workers, subscribing to changes of SkyDB entries using Websockets. If this functionality is not yet in place for FRAME, we hope to work with core developers to prepare for implementing this functionality when the feature becomes available.

    Community engagementโ€‹

    Skynet has a very active developer community, and we'll be sure to create various content around the integration, including promotional write-ups and a highlight video as part of our SiaTV YouTube content.

    We engage general audiences and developer audiences with our outreach media, and we'd include content for each audience.

    Future Plansโ€‹

    Skynet Labs will continue to develop Skynet by furthering integrations with blockchain projects needing decentralized, off-chain storage and front-end hosting, while also supporting client-facing applications that fall outside of blockchain programming. Our goal is that the data for these use-cases becomes increasingly interoperable and empowers users to have control over their data. Our medium-term plans include a robust monetization ecosystem that builds on our client-side, fully decentralized identity solution MySky.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? - Parity & Web3 Foundation Representatives

    No work outside preliminary research has been done on the pallet so far. Skynet Labs does have investors, but we have no other contributors or grants related to this specific project.

    Update & Amendmentsโ€‹

    02/25/2022โ€‹

    We grossly underestimated the number of blockers and competing priorities we'd encounter as a team, and the timeline has now been exceeded by several months. We are ready to submit our work, and will do so soon.

    As we better understood the ecosystem, we realized that a library for using Skynet in an off-chain worker was much more flexible for developing an application off-chain worker than was a proper pallet. As part of our deliverables, we now include the SDK library code skynet-substrate, along with a substrate example off-chain worker and front-end showing how to use various features of the SDK.

    This amendment also updates our company name, URL, and payout address.

    - + \ No newline at end of file diff --git a/applications/slonigiraf.html b/applications/slonigiraf.html index 4040b754c72..0f74d15f160 100644 --- a/applications/slonigiraf.html +++ b/applications/slonigiraf.html @@ -4,7 +4,7 @@ SLON - a recommendation letter system | Web3 Foundation Grants - + @@ -33,7 +33,7 @@ bioinformatics and one year of Rust/Substrate experience.

    Team Code Reposโ€‹

    Company:

    Team leader:

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement Substrate Moduleโ€‹

    NumberDeliverableSpecification
    0a. License Unlicense
    0b. Documentation We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c. Testing Guide Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d. Docker We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e. Article We will publish an article that explains what was done/achieved as part of the grant. (Content, language and medium should reflect your target audience described above.)
    1. Substrate module Publicly exposed methods:
    Function to penalize a referee. Will allow a worker to enable employer to penalize the referee. Should test if referee and worker signatures are valid and a letter was not previously used.
    pub fn reimburse(
       origin: OriginFor&lt;T&gt;,
       letter_id: u32,
       referee_id: H256,
       worker_id: H256,
       employer_id: H256,
       ask_price: BalanceOf&lt;T&gt;,
       referee_sign: H512,
       worker_sign: H512,
      ) -> DispatchResultWithPostInfo

    Function to see if the letter is valid. Should return TRUE if referee was not penalized yet.

    fn was_letter_used(
      referee: H256,
      number: usize,
     ) -> bool

    Runtime Storage defined by your module:
    Invalid letters are planned to be stored as Map of boolean arrays with key consisted of referee address concatenated to index of window where letter id resides.
    # [pallet::storage]
    # [pallet::getter(fn letter_of_owner_by_index)]
    pub(super) type OwnedLetersArray&lt;T: Config&gt; =
    StorageMap&lt;_, Twox64Concat, (H256, u64), Vec&lt;bool&gt;, ValueQuery&gt;;

    Private functions:
    Function that creates a part of datastore to mark fraud letter. See runtime storage definition.
    fn mint_chunk(
      to: H256,
      chunk: usize,
     ) -> DispatchResult

    Function to see if chunk of datastore exists.
    fn chunk_exists(
      to: H256,
      chunk: usize,
     ) -> bool

    Conversion from letter index to coordinates of it in datastore.
    fn coordinates_from_letter_index(number: usize) -> LetterCoordinates

    Conversion from coordinates in datastore to letter index.
    fn letter_index_from_coordinates(coordinates: LetterCoordinates) -> usize

    See if letter is fraud.
    fn was_letter_canceled(
      guarantee: H256,
      number: usize,
     ) -> bool

    Mark letter as fraud.
    fn mark_letter_as_fraud(
      guarantee: H256,
      letter_number: usize,
     ) -> DispatchResult

    Benchmarking:

    Data structures to run benchmarks and create weights

    benchmarks! {
     create {
      ...
     }: _(RawOrigin::Signed(caller))

     reimburse {
      ...
     }: _(RawOrigin::Signed(caller), origin, letter_id, referee_id, worker_id, employer_id, ask_price, referee_sign, worker_sign)
    }

    impl_benchmark_test_suite!(
     ...
    );

    Weights
    pub trait WeightInfo {
     fn reimburse() -> Weight;
    }

    pub struct SubstrateWeight&lt;T&gt;(PhantomData&lt;T&gt;);
    impl&lt;T: frame_system::Config&gt; WeightInfo for SubstrateWeight&lt;T&gt; {
     fn create() -> Weight {
      ...
     }
    }

    impl WeightInfo for () {
     fn create() -> Weight {
      ...
     }
    }

    2. Example UI Recommendation letter creation
    Template/Example React.js component that allows to create a letter of recommendation for guarantees.
    Contains a text area where guarantee can specify text of the letter; text field to specify a public
    key of worker; a button to sign a transaction; QR code of the signed letter to be transferred to the worker.

    Penalization right transfer
    Template/Example React.js component that transfers a right to penalize guarantees to employer.
    Creates a QR code that can be shown to an employer to transfer the letter text, guarantee and
    worker public keys, signatures of guarantee and worker.

    Penalization submission to a blockchain
    Template/Example React.js component for employers to send recommendation letter for penalization of
    guarantees. Contains a text field to show a text of the letter; a button to send a penalization transaction
    to the blockchain.

    Simple UI
    Should contain React.js components mentioned above combined in a single page web application based
    on the [substrate-front-end-template](https://github.com/substrate-developer-hub/substrate-front-end-template).

    Use case diagram

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Personal recommendation. Checkout the paper version of this protocol that can be used in any educational process:

    - + \ No newline at end of file diff --git a/applications/slothunter.html b/applications/slothunter.html index 583e1dcc83f..7aafa331c70 100644 --- a/applications/slothunter.html +++ b/applications/slothunter.html @@ -4,7 +4,7 @@ Slothunter | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ Teams/users can deploy the Telegram bot and receive the latest auction status in a group.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Personal. (no legal structure entry)

    Team's experienceโ€‹

    Xavier Lau

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Overviewโ€‹

    Milestone 1 Slothunter CLI toolโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationThere will be a guide to tell people how to use this.
    0c.Testing guideThere will be a docker file and a guide to tell the auditor how to run the tests. It will guide you how to setup an auction and do the tests.
    1.Auction winner calculatorBased on the 0c., run the binary, you should see the current winner from the terminal log.
    2.Notification componentBased on the 0c., run the binary, you should receive these notification correctly.
    3.Auto bidding/contributing componentBased on the 0c., run the binary, you should see you are bidding/contributing your parathread from the Polkadot Apps.
    4.Slothunter configuration componentBased on the 3., you can customize your bidding/contributing strategy in a toml file, you should see your bidding/contributing behavior works the same as the strategy defined.
    5.ReleasesLinux, macOS, Windows prebuilt binaries, and crates.io release.

    Milestone 2 Slothunter notification Slack/Telegram bot setup guideโ€‹

    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationThere will be a guide to tell people how to use this.
    0c.Testing guideThere will be a guide to tell the auditor how to run the tests.
    1.Telegram bot.A telegram bot program to receive the auction notification and easy to deploy on any Ubuntu 20.04+ server.
    2.Workshop repositoryFollow the tutorial in this repository to setup the bot, and you should see the notification appear in Slack and Telegram.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    We could talk about the bidding/contributing strategy. It's really flexible. If anyone got more ideas. I can integrate them into the program.

    I have talked to some teams few months ago. Because they ask me what script did I use during the bidding. Can I share it? Actually, I set some proxies accounts and share them with my team members. Then we watch the auction manually. If there is a new winner we could bid immediately.

    As I said before, there is even an empty auction in Kusama. This is not friendly and not good for the ecosystem. So, I decided to develop this. And I think it is valuable.

    How did you hear about the Grants Program? GitHub.

    - + \ No newline at end of file diff --git a/applications/social_recovery_wallet.html b/applications/social_recovery_wallet.html index 845ef9974e4..edc3db62dc0 100644 --- a/applications/social_recovery_wallet.html +++ b/applications/social_recovery_wallet.html @@ -4,14 +4,14 @@ Social Recovery Wallet | Web3 Foundation Grants - +
    Skip to main content

    Social Recovery Wallet

    • Team Name: Hypha Hashed Partners
    • Payment Address: bc1q7axtazzhsdttextp0qspueaagv4pgfm5l9ne64 (BTC)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Proposal for the RFP titled Social Recovery Wallet.

    Overviewโ€‹

    We develop Flutter wallets. We have experience developing social recovery wallets in Flutter. We develop the SEEDS Light wallet, found at the Android store and the iOS store.

    We have implemented social recovery in that Flutter wallet. It operates on Telos.

    Project Detailsโ€‹

    Recovery Screen Mockups / Descriptionsโ€‹

    These screens include:

    • Splash and main screen (mockup)
    image
    • Set / Remove social recovery accounts ("guardians")
    image
    • Recover account screens - generate recovery link to send to guardians
    image
    • Recovery wait countdown screen
    image
    • Process recovery URL to recover someone's account (see video of existig wallet)
    • Cancel recovery - prevent maliciuous actors (see video of existing wallet)

    The process overall will look similar to the existing Seeds Light Wallet process

    See the video here https://www.youtube.com/watch?v=Vpb8IbHvcNU

    To make recovery easy for a user, we provide a deep link users can share with their guardians.

    To make recovery more difficult to attack, we require the user to send the link to their recoverers outside the wallet.

    The recoverers then just click on the recovery link.

    Sign and Broadcastโ€‹

    In addition to social recovery, we will also migrate our Sign and Broadcast feature. It scans the QR code provided by polkadot.{js}, signs it, and broadcasts it to the network.

    Improvement on Parity Signerโ€‹

    Parity Signer scans QR codes that are produced by polkadot.{js}. Parity Signer is a fully airgapped wallet, so the payload is signed on the device and the signed QR code is scanned back into browser plugin to be broadcast.

    Our wallet will scan the same QR codes, but broadcast it to skip the step of having to scan the QR back in. Scanning QR codes from mobile back into a webcam is an extra step. It is the most time consuming part because you have to align the phone over the webcam correctly, and it always takes another second or two to focus on the QR code.

    With social recovery fully implemented, wallet users can be more confident leaving their mobile wallets online.

    Scopingโ€‹

    • Features - All steps of the Social recovery on Substrate article will be implemented.
    • Deployment - We will deploy the wallet to iOS and Android application stores.
    • Maintenance - We will maintain the components on the mainline releases of Substrate for no less than 2 years

    Team ๐Ÿ‘ฅโ€‹

    Team Membersโ€‹

    We have already been learning Substrate and we are partnering with the Hashed Network. Many of our users are already planned to migrate over.

    Contactโ€‹

    • Registered Address: 30 N. Gould St, Ste R, Sheridan, Wyoming
    • Registered Legal Entity: Hypha DAO LLC

    Team's experienceโ€‹

    We have deployed and implemented the Seeds Light Wallet. Nikolaus Heger and Gerardo Guijarro specced, implemented, and deployed social recovery for the Seeds Light Wallet. We also implemented the smart contracts. Smart contracts were deployed on Telos, an EOSIO fork. Hypha is a Hashed Network launch partner.

    Team Code Reposโ€‹

    Hypha develops two products, the Hypha DAO, and the SEEDS regenerative currency, DAO, and ecosystem.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We have started research of how to integrate Polkadot JS into the flutter app.

    https://github.com/JoinSEEDS/seeds_light_wallet/tree/feature/polkadot1

    We have deployed a full implementation in the Seeds Light Wallet

    We created a video showing off how the feature works on Telos - it's going to be a bit different due to the way Polkadot recovery pallet works, but 90% of the design and specifications are going to be the same (wait on recover, prevent hacks, set up guardians). It's less than 5 minutes, enjoy!

    https://www.youtube.com/watch?v=Vpb8IbHvcNU

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 2.5 FTE
    • Total Costs: 45,500 USD

    Languagesโ€‹

    • All deliverables will be written in Flutter/Dart.

    Milestonesโ€‹

    Milestone 1 โ€” Screen Designs and Configure Recoveryโ€‹

    • Estimated duration: 4 weeks
    • FTE: 2.5
    • Costs: 14,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can deploy the app on their mobile phone.
    0c.Testing GuideBusiness logic functions will be fully covered by unit tests to ensure functionality and robustness. We will describe how to run these tests.
    0d.App BinariesWe will provide an APK for Android and deliver the app on both Android and iOS platforms via the respective testing tracks in the Google Play and Apple App stores.
    0e.VideoWe will record and publish a video explainer and demonstration of all features.
    1.Screen DesignsWe will work with our designer to design the screens for all of the steps required. Designed in Figma, images will be in repository.
    2.Configure RecoveryFunctionality for a user to add recovery configuration to their account. Identify a list of existing accounts to serve as guardians, and select threshold
    Pallet calls
    create_recovery

    Milestone 2 โ€” Initiate Social Recovery, Vouch, Claim, and Recoverโ€‹

    • Estimated duration: 5 weeks
    • FTE: 2.5
    • Costs: 17,500 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can deploy the app on their mobile phone.
    0c.Testing GuideBusiness logic functions will be fully covered by unit tests to ensure functionality and robustness. We will describe how to run these tests.
    0d.App BinariesWe will provide an APK for Android and deliver the app on both Android and iOS platforms via the respective testing tracks in the Google Play and Apple App stores.
    0e.VideoWe will record and publish a video explainer and demonstration of all features.
    1.Recovery LookupThe ability to add guardians and an indicator whether that an account has a an active recovery.
    2.VouchThe ability to vouch for user that has an active recovery requesting signature from the account in the wallet.
    3.Claim and RecoverWhen threshold is met, user will have the ability to claim and recover their tokens.

    Pallet callsโ€‹

    TypePallet call
    queryactiveRecoveries
    extrinsicinitiate_recovery
    extrinsicvouch_recovery
    extrinsicclaim_recovery
    extrinsicas_recovered
    extrinsicclose_recovery
    extrinsicremove_recovery

    Milestone 3 โ€” Scan QR code, Sign, and Broadcastโ€‹

    • Estimated Duration: 4 weeks
    • FTE: 2.5
    • Costs: 14,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can deploy the app on their mobile phone.
    0c.Testing GuideBusiness logic functions will be fully covered by unit tests to ensure functionality and robustness. We will describe how to run these tests.
    0d.App BinariesWe will provide an APK for Android and deliver the app on both Android and iOS platforms via the respective testing tracks in the Google Play and Apple App stores.
    0e.VideoWe will record and publish a video explainer and demonstration of all features.
    1.QR Code FormatFlutter library for scanning polkadot.{js} QR codes
    2.Node SelectorUser can configure which network they are connecting to
    3.Sign and BroadcastIntegrate Sign and Broadcast for Flutter
    4.DeploymentWallet deployed to iOS and Android app stores

    Future Plansโ€‹

    We plan to continue enhancing the wallet. Many of our users are migrating to Hashed Network and will require Flutter modules for custom pallets.

    Other Palletsโ€‹

    Support for multisig and proxy pallets, plus other similar pallets.

    Enhanced Sign and Broadcastโ€‹

    Sign and Broadcast also establishes a trusted link between the browser and the device. The transaction results are reported on both the device and the browser. This feature uses the Flutter implementation of Anchor Link.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Referral - Max Gravitt

    - + \ No newline at end of file diff --git a/applications/societal_grant2.html b/applications/societal_grant2.html index 127e713a419..008bc5bcf35 100644 --- a/applications/societal_grant2.html +++ b/applications/societal_grant2.html @@ -4,13 +4,13 @@ Societal | Web3 Foundation Grants - +
    Skip to main content

    Societal

    • Team Name: Societal Labs Ltd.
    • Payment Address: Ethereum - USDC: 0xcDcCF94f10d8A7165C1A336DD3795430a6CDE530
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    This is the second grant for the Societal Labs team, after the sucessful submission and merge of our first W3F grant.

    Overviewโ€‹

    Societal is a specialized blockchain for the creation and management of Decentralize Autonomous Organizations (DAOs). Societal allows all types of groups or communities to build their own online, transparent, and decentralized organization. Societal bundles all of the tools required to create and manage a DAO in one place. Creators will be empowered to construct a DAO with fungible, non-fungible, or a combination of governance tokens. Societal also offers DAO management tooling features like treasury management, specialized governance, task boards, legal structuring, and accounting. This removes the need to utilize siloed platforms to manage the operations of a DAO. Whether a creator is looking to build a DAO for their organization, raise and deploy investment capital, or decentralize governance of an NFT project, Societal has the necessary tooling for a seamless end-to-end experience.

    Utilizing Polkdaotโ€™s layer-0 infrastructure and ecosystem, Societal will provide DAOs with both maximum functionality and a cohesive user experience. With features including agnostic token compatibility, zero gas fees, a freemium entry point, and a SaaS-based membership pricing, Societal combines best-in-class features into one vertically integrated product. With integrations into DeFi, privacy, and identity protocols, Societal will enable web3 organizations to seamlessly transition and manage their DAOs into the future.

    The Societal team has been building in the Polkadot ecosystem for the past two years. While at a previous Polkadot project, the Societal team noticed a lack of integrated DAO tooling - not only in the Polkadot ecosystem, but in the broader web3 industry as a whole. After analyzing how we might transition and manage our previous project into a DAO, there was no clear path. This, along with the team being both members and council members of various DAOs and noticing the lack of infrastructure, we decided to build a solution - Societal.

    Project Detailsโ€‹

    Societal Labs has been designing the product vision of the Socital platform for quite some time. We will go over the project details and blockchain architecture in this application and provide references below for more in-depth context.

    In Societal's final state, it will offer four main services; Create, Transition, Transfer and Manage. Create will allow any web3 user to create their own DAO. Transition will allow protocols to progressively move towards community ownership. Transfer will allow DAOs to transfer their DAO from an expensive siloed chain to the Sociteal platform. Manage will provide DAOs all the required product features to manage their organization, whether it is a small investment club or a large community-governed protocol.

    Societal will offer a wide range of features to create and manage a DAO. The features are split into three categories; Operations, Treasury, and Governance. The Operations features are: job & task boards, payroll, customizable feeds, legal tooling, on-chain reputation, and web & mobile application. The Treasury features are as follows: treasury wallets (multi-sig), DeFi integrations, on-chain cap table, accounting and private asset integrations. The governance features are: zero gas fee governance, proposal calendar, built-in governance models, governance treasury execution, and private voting.

    Societal will vertically integrate with projects to advance its tech stack and product offering, something not seen in most web3 projects today. For example, Societal can integrate DeFi services by working with projects like Acala, Parallel, and Composable Finance, which will allow for active treasury management for DAOs managed with Societal. For private assets and voting, projects like Manta and Phala can provide privacy-enabling functions like zero-knowledge proofs and trusted execution environments to make this possible. For on-chain credentials, projects like KILT and Litentry can provide KYC and member credentialing services that can be used by DAOs for governance and recruiting.

    Finally, Societal plans to progressively transition into a DAO itself. Once the token is launched, a community-run treasury will grow over time until the entire network is owned and operated by the community.

    For more information, please refer to the following resources:

    • Societal Whitepaper here
    • Societal Docs here
    • Societal Protoype Demo here
    • UI Mockups (High Res.) here
    • Societal MVP Article

    Ecosystem Fitโ€‹

    As it stands today, the DAO landscape within the Polkadot ecosystem is not as mature as other ecosystems such as Ethereum. This is due to insufficient DAO creation and tooling infrastructure in the ecosystem. Currently, the Polkadot ecosystem does not have the creation, governance, treasury management, and payroll tooling products as other major blockchains. By building these tooling products on Polkadot, both the Polkadot DAO landscape and the broader DAO management tooling space are primed for innovation by utilizing the unique technical abilities that Substrate provides.

    The target audience of the Societal application are web3 users who require a platform to easily create and manage their DAO. Using the technical capabilities that Substrate provides, Societal will design our chain to be token agnostic, allowing current MetaMask users to easily connect to our chain and start using the governance application right away. By doing this, our project will meet the needs of the Polkadot community to create their own DAOs and have the tools to manage them as seen in other ecosystems.

    The projects like Societal in the Polkadot space are Polkassembly, SubDAO, and DoraFactory. Societal differs from these projects in multiple ways. First, Polkassembly is not building their own parachain and is only a governance platform for large Polkadot projects. Societal wants to allow any web3 user to create their own DAO - not just catering to large established protocols. SubDAO has recently been focusing on smart contract deployments on multiple chains and does not appear to be building a parachain. Societal will build its own parachain and use the technical capabilities of Substrate to be truly token agnostic, connecting with widely used wallets such as MetaMask, to avoid doing multiple chain deployments via smart contracts. Dora Factory is similar to Societal in the sense that they are building their own parachian, however we plan to offer zero gas fees and a SaaS based pricing model to enhance our user's experience. Societal will also seek to integrate with other parachains, having cross-chain smart contract execution.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Graeme Fox
    • Tyler Gellatly
    • Oleh Kalenyk
    • Alibek Sansyzbayev

    Contactโ€‹

    • Registered Address: Brookfield Place, Suite 2700, 225 6 Ave SW, Calgary, AB T2P 1N2
    • Registered Legal Entity: Societal Labs Ltd.

    Team's experienceโ€‹

    Graeme Fox is the Co-Founder & CEO of Societal, a specialized blockchain designed for the creation and management of DAOs. He was accepted to inaugural the Polkadot Blockchain Academy, held at Cambridge University. Graeme is also a volunteer at the Canadian Blockchain Consortium, where he holds a role on the web3 committee. Prior to this, Graeme has held many roles in and out of web3. In web3, he was previously Head of Product at Ruby Protocol, a privacy project implementing Functional Encryption to combat Trusted Execution Environments (TEEs) and Zero-Knowledge Proofs (ZKPs). Prior to web3 he was the Lead Product Manager at Connectus. During this time, he was in charge of both internal and external development teams that created a web-based application using a MERN stack development, along with a supporting phone application on iOS and Android. It was during this role when Graeme was first introduced to blockchain development, as the main product line integrated with the Corda Blockchain to allow for automatic and secure payments following the completion of specific KPIs. Graeme has held other engineering roles in the past and holds a Bachelor of Engineering from Dalhousie University. He lives and breathes the entrepreneurial mindset, being involved in early-stage startups for the last five years.

    Tyler Gellatly is the Co-Founder & COO of Societal and has been building and scaling early stage start-ups for the last 4+ years. He was employee #1 and Director of Operations & Partnerships at Cuboh (a YC-backed SAAS middleware operating within the ghost kitchen industry) More recently, Tyler helped found Ruby Protocol, a novel privacy protocol building on the Substrate framework, and is still involved in a strategic advisory capacity. Currently, he sits on the DAO council for the Illuminati Collective, which currently has a 1000 ETH treasury under management. Tyler holds a Bachelor of Commerce from the University of Victoria, specializing in corporate strategy and finance. A well-rounded business operations leader with a background in finance, operations, capital fundraising, and strategic partnerships, Tyler is mission driven to bring web3 communities together at scale by utilizing blockchain technology.

    Team Code Reposโ€‹

    Org:

    Team:

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Societal has already been working on our project and has completed our MVP. The two main repositories of the Societal project are the societal-node and the societal-client. These repositories represent the societal blockchain (built with substrate) and the UI. To date or MVP includes the following features: Create a DAO with its own governance token, elect council members, create proposals, and vote on them with your MetaMask wallet.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 30,000 USDC

    Milestone 1 โ€” Add Reservable & Lockable Traits to Asset Palletโ€‹

    • Estimated Duration: 1.5 months
    • FTE: 2
    • Costs: 15,000 USDC
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up one of our Societal's nodes and interact with the Reservable & Lockable Asset Pallet.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Substrate Module: Reservable & Lockable Asset PalletThe main delivery of this milestone will be adding the 'ReservableAsset' and 'LockableAsset' Traits to the current Substrate Assets Pallet. By doing this, fungilbe tokens generate from the new Assets Pallet will have the same Reservable and Lockable features as the chain's native token from the balances pallet. These fungible tokens may then be used with the current Substrate Democarcy pallet, allowing DAOs create on Societal's chain to have similar feautres to Polkadot's Governance v1.
    2.Client ModulesA minor UI will be made to allow the user to interact with the new Asset Pallet and show that the functionality works. However, the major UI creation will be completed in milestone 2.

    Milestone 2 โ€” UI To Display Functionalityโ€‹

    • Estimated duration: 1.5 months
    • FTE: 2
    • Costs: 15,000 USDC
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up our Substrate client and test the functionality of the interact with the Reservable & Lockable Asset Pallet via Societal UI.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a tutorial that explains how to use and interact with the Reservable & Lockable Asset Pallet via Societal UI.
    1.Client ModulesWe will create a client facing UI that will interact with the Reservable & Lockable Asset Pallet. The main functionly of the UI will be to show how the fungilbe tokens generated from the new Assets Pallet can be used with the current Substrate Democracy Pallet. This will allow DAOs that have been created on the Societal network to have similar features to Polkdaot Governance v1 system, that only parachains can use right now.

    Future Plansโ€‹

    Societal plans to secure fundraising and expand the development team. After the completion of the milestones stated above, Societal plans to expand the product offering by implementing a DAO Dapp Market Place and a subscription pricing mechanisim. Societal has also applied to be a part of the Substrate Builders Program. Finally, Societal plans to launch its own parachain and be the go to DAO Creation and Mangament platofrm.

    Additional Information โž•โ€‹

    All information already included in above.

    - + \ No newline at end of file diff --git a/applications/societal_saas_pricing.html b/applications/societal_saas_pricing.html index 7ffde9f1898..f83f2aeb633 100644 --- a/applications/societal_saas_pricing.html +++ b/applications/societal_saas_pricing.html @@ -4,13 +4,13 @@ Societal | Web3 Foundation Grants - +
    Skip to main content

    Societal

    • Team Name: Societal Labs Ltd.
    • Payment Address: Ethereum - USDC: 0xcDcCF94f10d8A7165C1A336DD3795430a6CDE530
    • Level: 3

    Project Overview ๐Ÿ“„โ€‹

    This is the third grant for the Societal Labs team, after the sucessful completion of two previous grants.

    Societal is also a member of the Substrate Builders Program.

    Overviewโ€‹

    Societal is a specialized blockchain for the creation and management of internative-native organizations. Societal allows all types of groups or communities to build their own online, transparent, and decentralized organization. Societal bundles all of the tools required to create and manage a DAO in one place. Creators will be empowered to construct a DAO with fungible, non-fungible, or a combination of governance tokens. Societal also offers DAO management tooling features like treasury management, specialized governance, task boards, legal structuring, and accounting. This removes the need to use siloed platforms to manage the operations of a DAO. Whether a creator is looking to build a DAO for their organization, raise and deploy investment capital, or decentralize governance of an NFT project, Societal has the necessary tooling for a seamless end-to-end experience.

    Utilizing Polkdaotโ€™s layer-0 infrastructure and ecosystem, Societal will provide DAOs with both maximum functionality and a cohesive user experience. With features including cross-chain governance and subscription pricing, Societal combines best-in-class features into one vertically integrated product. With integrations into DeFi, privacy, and identity protocols, Societal will enable web3 organizations to seamlessly transition and manage their DAOs into the future.

    The Societal team has been building in the Polkadot ecosystem for the past two years. While at a previous Polkadot project, the Societal team noticed a lack of integrated DAO tooling - not only in the Polkadot ecosystem, but in the broader web3 industry as a whole. After analyzing how we might transition and manage our previous project into a DAO, there was no clear path. This, along with the team being both members and council members of various DAOs and noticing the lack of infrastructure, we decided to build a solution - Societal.

    Project Detailsโ€‹

    Societal Labs has been designing the product vision of the Socital platform for quite some time. We will go over the project details and blockchain architecture in this application and provide references below for more in-depth context.

    In Societal's final state, it will offer four main services; Create, Transition, Transfer and Manage. Create will allow any web3 user to create their own DAO. Transition will allow protocols to progressively move towards community ownership. Transfer will allow DAOs to transfer their DAO from an expensive siloed chain to the Sociteal platform. Manage will provide DAOs all the required product features to manage their organization, whether it is a small investment club or a large community-governed protocol.

    Societal will offer a wide range of features to create and manage a DAO. The features are split into three categories; Operations, Treasury, and Governance. The Operations features are: job & task boards, payroll, customizable feeds, legal tooling, on-chain reputation, and a web & mobile application. The Treasury features are as follows: treasury wallets (multi-sig), DeFi integrations, on-chain cap table, and accounting. The governance features are: subscription based governance, proposal calendar, built-in governance systems, and private voting.

    Societal will vertically integrate with projects to advance its tech stack and product offering, something not seen in most web3 projects today. For example, Societal can integrate DeFi services by working with projects like Acala and Moonbeam, which will allow for active treasury management for DAOs managed with Societal. For private assets and voting, projects like Manta and Phala can provide privacy-enabling functions like zero-knowledge proofs and trusted execution environments to make this possible. For on-chain credentials, projects like KILT and Litentry can provide KYC and member credentialing services that can be used by DAOs for governance and recruiting.

    Finally, Societal plans to progressively transition into a DAO itself. Once the token is launched, a community-run treasury will grow over time until the entire network is owned and operated by the community.

    For more information, please refer to the following resources:

    • Societal Whitepaper here
    • Societal Docs here
    • Societal Protoype Demo here

    Ecosystem Fitโ€‹

    As it stands today, the DAO landscape within the Polkadot ecosystem is not as mature as other ecosystems such as Ethereum. This is due to insufficient DAO creation and tooling infrastructure in the ecosystem. Currently, the Polkadot ecosystem does not have the creation, governance, and treasury management tooling products that other major blockchains do. By building these tooling products on Polkadot, both the Polkadot DAO landscape and the broader DAO management tooling space are primed for innovation by utilizing the unique technical abilities that Substrate provides.

    The target audience of the Societal application are web3 users who require a platform to easily create and manage their DAOs. Our project will meet the needs of the Polkadot community to create and managane their own DAOs and will be a governace scaling solution for ETH based DAOs.

    The projects like Societal in the Polkadot space are Polkassembly, SubDAO, and InvArch. Societal differs from these projects in multiple ways. First, Polkassembly is not building their own parachain and is only a governance platform for large Polkadot projects. Societal wants to allow any web3 user to create their own DAO - not just catering to large established protocols. SubDAO has recently been focusing on smart contract deployments on multiple chains and does not appear to be building a parachain. Societal will build its own parachain and use the technical capabilities of Substrate to be truly token agnostic, connecting with widely used wallets such as MetaMask, to avoid doing multiple chain deployments via smart contracts. InvArch Factory is similar to Societal in the sense that they are building their own parachian, however we plan to offer a SaaS based pricing model so we can change the DAOs a monthly subscription fee and eliminate the fees for the organizations members. Societal will also seek to integrate with other chains, having cross-chain governace execution.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Graeme Fox
    • Tyler Gellatly
    • Oleh Kalenyk
    • Alibek Sansyzbayev

    Contactโ€‹

    • Registered Address: Brookfield Place, Suite 2700, 225 6 Ave SW, Calgary, AB T2P 1N2
    • Registered Legal Entity: Societal Labs Ltd.

    Team's experienceโ€‹

    Graeme Fox is the Co-Founder & CEO of Societal, a specialized blockchain designed for the creation and management of DAOs. He was accepted to inaugural the Polkadot Blockchain Academy, held at Cambridge University. Graeme is also a volunteer at the Canadian Blockchain Consortium, where he holds a role on the web3 committee. Prior to this, Graeme has held many roles in and out of web3. In web3, he was previously Head of Product at Ruby Protocol, a privacy project implementing Functional Encryption to combat Trusted Execution Environments (TEEs) and Zero-Knowledge Proofs (ZKPs). Prior to web3 he was the Lead Product Manager at Connectus. During this time, he was in charge of both internal and external development teams that created a web-based application using a MERN stack development, along with a supporting phone application on iOS and Android. It was during this role when Graeme was first introduced to blockchain development, as the main product line integrated with the Corda Blockchain to allow for automatic and secure payments following the completion of specific KPIs. Graeme has held other engineering roles in the past and holds a Bachelor of Engineering from Dalhousie University. He lives and breathes the entrepreneurial mindset, being involved in early-stage startups for the last five years.

    Tyler Gellatly is the Co-Founder & COO of Societal and has been building and scaling early stage start-ups for the last 4+ years. He was employee #1 and Director of Operations & Partnerships at Cuboh (a YC-backed SAAS middleware operating within the ghost kitchen industry) More recently, Tyler helped found Ruby Protocol, a novel privacy protocol building on the Substrate framework, and is still involved in a strategic advisory capacity. Currently, he sits on the DAO council for the Illuminati Collective, which currently has a 1000 ETH treasury under management. Tyler holds a Bachelor of Commerce from the University of Victoria, specializing in corporate strategy and finance. A well-rounded business operations leader with a background in finance, operations, capital fundraising, and strategic partnerships, Tyler is mission driven to bring web3 communities together at scale by utilizing blockchain technology.

    Team Code Reposโ€‹

    Org:

    Team:

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Societal has already been working on our project and has completed our MVP. The two main repositories of the Societal project are the societal-node and the societal-client. These repositories represent the societal blockchain (built with substrate) and the UI. To date or MVP includes the following features: Create a DAO with its own governance token, slecect a governance type (Gov1, ownership weighted voting, NFT voting), create and vote on proposals, and bounties. The Societal chain is also EVM compatible.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 40,000 USDC

    The main purpose of this grant will be creating a subcription based pricing system, that can be implemented into any subsrate chain.

    Societal will use this subcription based pricing system to charge the DAOs on its network a monthly fee, which will allow the DAOs members to interact on-chain without paying gas fees. This will bring current web2 pricing models to web3, increasing user experience and ease of adoption for DAOs, as their members will not have to pay gas fees or hold the chain token to interact with it.

    Milestone 1 โ€” Subscription Pricing Palletโ€‹

    • Estimated Duration: 1.5 month
    • FTE: 2
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Substrate module: Subscription Pricing PalletWe will create a Substrate pallet that will require organizations on substrate chain's network to pay a monthly subscription, which will allow the organizations members to interact on-chain without paying gas fees. The pallet will do four main things. It will accept a subscription payment from a DAO to the substrate chain's treasury. It will open or lock functions for the DAOs members based on if and when the payment has been made. It will have a time limit for these functions to be open, before another payment is required. Finally, it would specify a maximum amount of function calls that can be executed before the functions are locked and another payment is required, preventing DDos attacks.

    Milestone 2 โ€” Add Subscription Tiers to Palletโ€‹

    • Estimated Duration: 1.5 months
    • FTE: 2
    • Costs: 15,000 USDC
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Substrate Module: Add Subscription Tiers to PalletThe main delivery of this milestone will be adding differnt subscription tiers to the pallet that was created in milestone 1. This milestone will allow the developer to define different subscription tiers, the price of each tier, what functions and/or pallets are allowed in each tier, and the maximum amount of function calls for each tier. Based on what subcription tier the DAO is paying for, only those functions will be allowed to be called by the DAO and its members. Finally, this milestone will also allow each tier to have a maximum amount of members allowed in the DAO.

    Milestone 3 โ€” Add Recurring Subcription Payment to Palletโ€‹

    • Estimated duration: 1 month
    • FTE: 2
    • Costs: 10,000 USDC
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish a tutorial that explains how to use and the functionality of the grant.
    1.Substrate Module: Add Recurring Subcription Payment to PalletThe main delivery of this milestone will be allowing the DAO to approve recurring subscription payments from the DAOs treasury. The approval for the automic recurring subcription approval will come in the form of a governance proposal. The subcription payment will allow for monthly recurring payments until the subscription in canceled. If funds are not avaible at the time of paymnet, all of the DAO functions except for paying the subscription will be locked. This milestone will make it easier for the DAOs to pay the subscription and not need to approve a proposal every month.

    Future Plansโ€‹

    Societal plans to launch its own parachain and be the go-to DAO Creation and Management platform for Polkadot and all of web3. We believe that this subscription pricing system will be a great on-ramp of DAOs from other ecosystems into Polkadot, as the organization members do not have to purchase the Societal token to participate in on-chain transactions. This will reduce the barrier for these DAOs to use a governance scaling solution for their organization, such as Societal. This subscription payment system can also be used by many substrate chains to reduce this barrier adoption as well.

    Additional Information โž•โ€‹

    All information already included in above.

    - + \ No newline at end of file diff --git a/applications/sol2ink-follow-up.html b/applications/sol2ink-follow-up.html index 8cf54ed2583..438bef9a7e1 100644 --- a/applications/sol2ink-follow-up.html +++ b/applications/sol2ink-follow-up.html @@ -4,7 +4,7 @@ Sol2Ink | Web3 Foundation Grants - + @@ -72,7 +72,7 @@ Started programming own games at age of 15 as a hobby, then went to University studying informatics and object oriented programming, becoming an Android developer in 2018. In 2017 he started his crypto venture by investing in BTC and Ethereum and getting more knowledge regarding smart contracts and DeFi protocols during DeFi summer 2020. As a programmer, he wanted to know more behind the scenes of smart contracts, so he started to develop his own smart contract applications for Ethereum and then becoming a Rust and Ink! developer in , since he believes that WASM with its benefits over EVM is the future of smart contract applications. As a part of his Android developer career, Dominik was working on porting of applications from C++ to Android/Java, for which he also worked on a tool to ease this process, describing the process of transformation of code base from one language to another in his bachelor's thesis.

    Green Baneling
    Blockchain Core Developer
    Primary programming languages are: C++, Go, Rust

    Finished the faculty of applied mathematics(Master degree). Participated in programming competitions during education. Has worked as a programmer for around 6 years.

    Was a freelancer the first year, creating an application for IOS(Swift), creating modules for the desktop application on C++. After that, spent 2 years in a company which created software for TV devices(C++/ Haxe). After which, for 3 years, worked on different blockchain projects(C++/Go/Rust/Solidity/Js).

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    The project is already in release 1.0.0.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    We have decided to describe a full roadmap of an Sol2Ink here, with estimates. However, the funding we request at this stage is for milestone 2.

    Previous workโ€‹

    Milestone 1 โ€” Implement Sol2Ink cli tool for simple contract parsingโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a documentation for the user on how to use our tool for simplification of their process of transformation of Solidity code to Rust and Ink! code, along with inline documentation of code so the developers can better understand the processes in the backend
    1.Sol2Ink CLIA CLI application which will take a Solidity file as the input and produce a transformed Rust file with Rust and ink! code as the output
    2.Integrate OpenBrushSince OpenBrush is a tool to ease and fasten the smart contracts development in ink!, we will add this library to the smart contracts generated by Sol2Ink
    3.Website with guidesWe will provide a website where we will compare a transformation of Solidity code into Rust and ink! code, along with issues which may occur (for example handling of Assembly blocks etc.).

    Current work - Scope of this Grantโ€‹

    Milestone 2 โ€” Upgrade focused on complex Smart contract applications parsingโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will enhance both the inline documentation as well as the website with guides to reflect new features implemented in this milestone
    0c.Testing and Testing guideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. Documentation will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Website with guidesWe will enhance the existing guides to reflect new features implemented in this milestone; The website with guides is something like an enhanced documentation, the inline documentation just describes the functions of the program, the guides go deeper into how it works, and it also contains a tutorial for usage of Sol2Ink
    2.Split contract into traitsCurrently all logic and storage is in one contract file. This upgrade will generate traits for each contract that the contract is using, splitting logic and storage into separate traits. This will also nicely handle inheritance of Solidity smart contracts
    3.Sol2Ink transpiler updateWe will update the transpiler to deal with code which it currently does not support or parses incorrectly
    3a.Functions with valueSupport calls with value transferring
    3b.Chained selectorsFix parsing of chained selectors
    3c.Updating structs inside of a mappingFix how Sol2Ink rewrites fields of a structure inside a mapping
    3d.ModifiersFix some occassions where parsing of a modifier causes the output code to be uncompilable (for example if there is a function call as a modifier argument
    3e.Fix bugsFix many small bugs which can occur, after this a more complex contracts (e.g. Uniswap) can be fully covered with Sol2Ink
    4.Library parsingWe will implement the parser for Solidity libraries; currently Sol2Ink only looks for definition of a contract or an interface, since libraries must be handled in a different way, meaning that there is no problem in parsing of Solidity code of a library, but the output code of a Solidity library must be handled in a different way, which is the goal of this deliverable
    5.Handling dependencies and generalizationThis will be implemented via traits
    6.Multi-file project parsingThis will be implemented via traits

    Future Plansโ€‹

    NumberDeliverableSpecification
    0.ArticleWe will publish an article which explains the advantages of using Sol2Ink
    1.Handle Solidity specific casesDelegate calls, assembly code, try/catch blocks etc.
    2.Sol2Ink web applicationWeb app for an even easier work with Sol2Ink
    3.MaintenanceKeeping up with new ecosystem standards, fixing issues from community

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? personal recommendation

    - + \ No newline at end of file diff --git a/applications/sol2ink.html b/applications/sol2ink.html index ab6463630a1..017a92aa827 100644 --- a/applications/sol2ink.html +++ b/applications/sol2ink.html @@ -4,7 +4,7 @@ Sol2Ink | Web3 Foundation Grants - + @@ -71,7 +71,7 @@ Started programming own games at age of 15 as a hobby, then went to University studying informatics and object oriented programming, becoming an Android developer in 2018. In 2017 he started his crypto venture by investing in BTC and Ethereum and getting more knowledge regarding smart contracts and DeFi protocols during DeFi summer 2020. As a programmer, he wanted to know more behind the scenes of smart contracts, so he started to develop his own smart contract applications for Ethereum and then becoming a Rust and Ink! developer in Supercolony, since he believes that WASM with its benefits over EVM is the future of smart contract applications. As a part of his Android developer career, Dominik was working on porting of applications from C++ to Android/Java, for which he also worked on a tool to ease this process, describing the process of transformation of code base from one language to another in his bachelor's thesis.

    Green Baneling
    Blockchain Core Developer
    Primary programming languages are: C++, Go, Rust

    Finished the faculty of applied mathematics(Master degree). Participated in programming competitions during education. Has worked as a programmer for around 6 years.

    Was a freelancer the first year, creating an application for IOS(Swift), creating modules for the desktop application on C++. After that, spent 2 years in a company which created software for TV devices(C++/ Haxe). After which, for 3 years, worked on different blockchain projects(C++/Go/Rust/Solidity/Js).

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    The project development has not started yet, we have just tested a very simple prototype on our commercial projects, which is able to parse Solidity interfaces into Rust traits with Ink! usage.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement Sol2Ink cli tool for simple contract parsingโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a documentation for the user on how to use our tool for simplification of their process of transformation of Solidity code to Rust and Ink! code, along with inline documentation of code so the developers can better understand the processes in the backend
    1.Sol2Ink CLIA CLI application which will take a Solidity file as the input and produce a transformed Rust file with Rust and ink! code as the output
    2.Integrate OpenBrushSince OpenBrush is a tool to ease and fasten the smart contracts development in Ink!, we will add this library to the smart contracts generated by Sol2Ink
    3.Website with guidesWe will provide a website where we will compare a transformation of Solidity code into Rust and ink! code, along with issues which may occur (for example handling of Assembly blocks etc.).

    Future Plansโ€‹

    After this grant, we plan to upgrade the parser to handle more complicated Solidity codebases (e.g. generalization, storage manipulation, delegate calls), parsing of whole projects (multiple files) with dependencies and making a web application of this tool. We also plan to maintain the project to keep up with new emerging ecosystem standards and listen to issues from community and update the tool to make the process of transformation a nicer experience for the developers and teams.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? personal recommendation

    - + \ No newline at end of file diff --git a/applications/solidity-trie-verifier.html b/applications/solidity-trie-verifier.html index 599e26f5ea1..b7f0d416346 100644 --- a/applications/solidity-trie-verifier.html +++ b/applications/solidity-trie-verifier.html @@ -4,13 +4,13 @@ solidity-trie-verifier | Web3 Foundation Grants - +
    Skip to main content

    solidity-trie-verifier

    • Team Name: Polytope Labs
    • Payment Address: 0x486cbad2d704bc76f8d0cdda6aa93c94d53297b9 (Ethereum DAI)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    This project aims to deliver an implementation of the parity trie verifier as required by state proof checking algorithms (read_child_proof_check, read_proof_check_on_proving_backend) in the Solidity programming language, which would include various sub implementations (for example NodeCodec for both layoutv0 & layoutv1) required to build trustless bridging protocols from the Polkadot ecosystem to the EVM ecosystem.

    Goal: To create a primitive for more generalized bridging protocols like IBC, it is more efficient to verify Parachain state/storage than to use custom implementations which Darwinia and Snowfork do.

    Project Detailsโ€‹

    APIsโ€‹

    function VerifyProof(root bytes32, proof bytes[], keyValues KeyValue[]) public external returns (bool)

    struct KeyValue {
        key bytes;
        value bytes;
    }

    Technology Stackโ€‹

    • Solidity

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Seun Lanlege,
    • Sam Omidiora, Femi Bankole

    Contactโ€‹

    • Registered Address: Harneys Fiduciary (Cayman) Limited, 4th Floor, Harbour Place, 103 South Church Street, Cayman Islands
    • Registered Legal Entity: Polytope Labs Ltd.

    Team's experienceโ€‹

    Polytope Labs is a collective of core blockchain engineers, researchers & scientists from varying blockchain protocol backgrounds passionate about the proliferation of networks over platforms and enabling this future through blockchain research & education, tooling and core infrastructure development.

    • Seun Lanlege: Previously core developer at Parity Tech, Ethereum and Polkadot with over 4 years of industry experience, core contributor of the code utilized by the ecosystem who recently joined the Polkadot fellowship program and Mad Scientist at Polytope Labs.
    • Sam Omidiora: Senior Blockchain Engineer with over four years of industry experience, previosly at Aave, Ambire and Advanced Blockchain working with the solidity programming language and Lab Scientist at Polytope Labs.
    • Femi Bankole: Blockchain engineer at Matchx_iot + MXC Foundation and Lab Intern at Polytope Labs.

    Team Code Reposโ€‹

    Team GitHub Profilesโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 6 Weeks
    • Full-Time Equivalent (FTE): 2.5 FTE
    • Total Costs: 30,000 USD

    Milestone 1 Implementationโ€‹

    • Estimated duration: 6 Weeks
    • FTE: 2.5
    • Costs: 30,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationA documentation on how to use this library in form of a README on the project repository.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that covers what was done/achieved as part of the grant.
    1Solidity SCALE CodecThis will include support for enum{option/result}, Vec<Vec<u8>> decoding and other types required for verifying state proofs as current implementations(Darwinia, Snowfork) don't support.
    2.KeyspacedDBProvide the solidity implementation of the following; https://github.com/paritytech/substrate/blob/129fee774a6d185d117a57fd1e81b3d0d05ad747/primitives/trie/src/lib.rs#L426.
    3.MemoryDBProvide the solidity implementation of the following; https://github.com/paritytech/substrate/blob/129fee774a6d185d117a57fd1e81b3d0d05ad747/primitives/trie/src/lib.rs#L163.
    4.NodeCodecProvide solidity implementation of the following; https://github.com/paritytech/substrate/blob/129fee774a6d185d117a57fd1e81b3d0d05ad747/primitives/trie/src/node_codec.rs#L81.
    5.NodeProvide the solidity implementation of the following; https://github.com/paritytech/trie/blob/42f086bc8748f25e978da10a9cefdb396a72b158/trie-db/src/node.rs#L184.
    6.NodePlanProvide the solidity implementation of the following; https://github.com/paritytech/trie/blob/42f086bc8748f25e978da10a9cefdb396a72b158/trie-db/src/node.rs#L507.
    7.NodeHeaderProvide the solidity implementation of the following; https://github.com/paritytech/substrate/blob/129fee774a6d185d117a57fd1e81b3d0d05ad747/primitives/trie/src/node_header.rs#L26.
    8.NibbleSlicePlanProvide the solidity implementation of the following; https://github.com/paritytech/trie/blob/42f086bc8748f25e978da10a9cefdb396a72b158/trie-db/src/node.rs#L454.
    9.NibbleSliceProvide the solidity implementation of the following; https://github.com/paritytech/trie/blob/42f086bc8748f25e978da10a9cefdb396a72b158/trie-db/src/nibble/mod.rs#L180.
    10.Layoutv0Provide the Solidity implementation of following; https://github.com/paritytech/substrate/blob/ece32a72e934f6fe6705a7d418bbf3e71b4931ad/primitives/trie/src/lib.rs#L60.
    11.Layoutv1Provide the Solidity implementation of the following; https://github.com/paritytech/substrate/blob/ece32a72e934f6fe6705a7d418bbf3e71b4931ad/primitives/trie/src/lib.rs#L63 .
    12.Trie VerifierProvide the Solidity implementation of the following; https://github.com/paritytech/trie/blob/42f086bc8748f25e978da10a9cefdb396a72b158/trie-db/src/triedb.rs#L233.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website.

    - + \ No newline at end of file diff --git a/applications/solidity-verifier-for-accountable-light-client.html b/applications/solidity-verifier-for-accountable-light-client.html index 3effe7715d3..99cb1ebe367 100644 --- a/applications/solidity-verifier-for-accountable-light-client.html +++ b/applications/solidity-verifier-for-accountable-light-client.html @@ -4,14 +4,14 @@ Solidity Verifier Implementation for Accountable Light Client | Web3 Foundation Grants - +
    Skip to main content

    Solidity Verifier Implementation for Accountable Light Client

    • Team Name: Itering
    • Payment Address: 0x5FD8bCC6180eCd977813465bDd0A76A5a9F88B47 (Ethereum USDC)
    • Level: 3

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    As a developer company contributing to Darwinia, Itering is working on implementing an on-chain accountable light client verifier using the Solidity language. The accountable light client design is based on a recent paper published by the Web3 Foundation.

    Darwinia is constantly following innovations in the cross-chain space, especially from the Web3 Foundation and Polkadot, with a goal of implementing these innovations in practical settings. Currently, Darwinia is prioritizing the development of on-chain light clients as the cross-chain solution. We recognize the importance of the accountable light client system presented in the paper.

    Project Detailsโ€‹

    After reading the paper, we found it to be extremely valuable. It presents an efficient method for utilizing SNARK to verify the aggregated public key of signers, while still holding those signers accountable. This approach greatly improves the speed and cost-effectiveness of proof generation.

    Darwinia has created a beacon light client from ethereum to darwinia, which is based on the BLS aggregate signature verification. The cross-chain gas is effectively reduced by aggregate signatures, but it is still too high because the light client smart contract needs to be aware of the entire list of public keys. If there are too many pubkeys, this could be a serious issue.

    So, we are searching for a more effective solution to the aggregate signature pubkeys problem. We concentrate on the honest computation provided by zero-knowledge proof solutions. It allows us to off-chain the verification step. But through our study, we discovered that the generic SNARK solutions have so many limits that not only took a long time to produce the proof, but also required an extremely powerful device. We were stuck here until we came across this paper and Alistair's explanation video and slides.

    This verifier will be implemented based on the BLS12-377 and BW6-761 elliptic curves, which is consistent with the implementation in the paper and W3F's PoC implementation.

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem?

      When Polkadot/Substrate/Kusama bridges to a blockchain that is EVM-compatible, this verifier will be helpful.

    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

      The users of this verifier will be the cross-chain messaging/bridge service providers.

    • What need(s) does your project meet?

      Precompiled versions of BLS12-377 and BW6-761 should ideally be supported by the blockchains that use this verifier.

      If gas and speed are not a concern, you can also use the no-precompiled curves.

    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

      This kind of verifier hasn't been implemented in solidity yet, as far as we know.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    • Registered Address: 3 FRASER STREET #05-25 DUO TOWER SINGAPORE (189352)
    • Registered Legal Entity: ITERING TECH PTE. LTD.

    Team's experienceโ€‹

    Itering is a team of passionate blockchain technology enthusiasts. We believe that blockchains should be interoperable with each other. Itering has accumulated significant expertise in the field of cross-chain technology through several years of experience. Our expertise spans various cross-chain approaches, with a focus on light client.

    We are well-versed in Polkadot/Substrate technology. We leverage the Polkadot/Substrate technology stack to power most of our blockchain development. Our blockchains, Darwinia and its canary network Crab, are based on Substrate and currently operate as parachains of Polkadot and Kusama respectively.

    Additionally, we have extensive experience with the Solidity programming language. Notably, we have already implemented a beacon light client in Solidity that has been successfully running on the Darwinia Chain.

    Team Code Reposโ€‹

    Github accounts of team members:

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 6 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 60,000 USD

    Milestone 1 โ€” Curve precompilesโ€‹

    • Estimated duration: 2 month
    • FTE: 2
    • Costs: 20,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.BLS12-377 precompileWe will create a EIP-2539 compatible BLS12-377 precompile which can run inside frontier. It will be developed using Rust programming language. The libraries we plan to use are arkworks-rs/curves library or the substrate host function calls provided by this Pull Request.
    Other references:
    https://github.com/celo-org/celo-blockchain/pull/1157
    https://github.com/celo-org/celo-blockchain/pull/1341
    2.BW6-761 precompileWe will create a EIP-3026 compatible BW6-761 precompile which can run inside frontier. The programming language and libs to use are the same as BLS12-377 precompile.
    Other references:
    https://github.com/celo-org/celo-blockchain/pull/1282

    Milestone 2 โ€” Basic & Packed verifierโ€‹

    • Estimated Duration: 4 month
    • FTE: 2
    • Costs: 40,000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and an example to verify the proof generated from W3F's PoC example.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Libraries preparationWe will prepare the import libraries which are critical to the implementation of the verifier in solidity.
    1. Fiat-shamir transformation. A solidity friendly replacement to the Merlin::Transcript.
    2. Lagrange evaluation.
    3. KZG verification. We will write a froniter precompile to do it.
    2.Basic APK verifierWe will implement the basic verifer which will check the apk is correct. We plan to use the PoC code from apk-proofs as a reference to implement this verifier. It can verify the proofs generated by the PoC example. We will implement it using Solidity language.
    3.Packed APK verifierWe will implement the packed verifer which will check the apk is correct. We plan to use the PoC code from apk-proofs as a reference to implement this verifier. We will implement it using Solidity language.
    4.BLS verifierWe will implement the bls verifier which will check if the aggregate signature is signed by the apk. We will use the BLS12-377 precompile implemented in Milestone 1. We will implement it using Solidity language.
    5.Signers threshold checkerCheck if the bitvector of pubkeys contains enough signers. We will implement it using Solidity language.

    Future Plansโ€‹

    • We intend to leverage this verifier to develop our on-chain light clients after the grant is completed.
    • Adapt to other EVM chains that satisfy the curves' requirements.
    • Follow the revision of the W3F paper.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website / personal recommendation

    Additional information:

    • Darwinia truth layer currently include Beacon light client, BSC light client and Darwinia light client.
    • Helix Bridge which have bridges based on Darwinia cross-chain messaging protocol.
    - + \ No newline at end of file diff --git a/applications/spacewalk-bridge.html b/applications/spacewalk-bridge.html index fbeb7fe0496..913c949f80f 100644 --- a/applications/spacewalk-bridge.html +++ b/applications/spacewalk-bridge.html @@ -4,13 +4,13 @@ Spacewalk: a Stellar bridge | Web3 Foundation Grants - +
    Skip to main content

    Spacewalk: a Stellar bridge

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Spacewalk is a bridge between Substrate-based parachains and Stellar which enables asset transfers to and from Stellar. This grant application is for developing the Spacewalk protocol and pallet. The Spacewalk bridge is built by the team behind the Pendulum network (an upcoming parachain that connects fiat tokens from across multiple blockchain ecosystems).

    Project Detailsโ€‹

    Spacewalk bridge is developed to be a decentralized and trustless bridge to Stellar. This bridge enables two main activities:

    • Deposit: bridge any Stellar asset to Substrate-based chains. The tokens of the source asset are transferred to some dedicated vault in Stellar where they are locked. The bridge then mints wrapped tokens in the target chain and transfers them to the recipient account.
    • Withdrawal: bridge wrapped tokens in Substrate-based chains to Stellar. First, the user instructs the bridge to burn wrapped tokens in the Substrate-based chain. Afterwards, an appropriate vault unlocks tokens and transfers them to some target account.

    Stellar is not smart contract capable โ€“ therefore we follow the recommendation laid out in the Polkadot documentation and base our bridge design on XCLAIM, which is based on the following four core features:

    • Implement a chain relay for Stellar in the bridge pallet
    • Employ collateralization in order to ensure that the vault exhibits good behavior
    • Ensure that the economic value of the collateral exceeds the value of the vault
    • Enable a decentralized network of vaults

    XCLAIM has been implemented and further improved by Interlay for the open source Bitcoin bridge interBTC. Spacewalk is based on the interBTC implementation. It differs from interBTC as follows:

    • Currently Stellar does not use Merkle trees inside its blocks. Therefore, there is no efficient way to prove that a transaction is included in a block given only the block header โ€“ a prover would require to complete the complete set of transactions instead of a Merkle path.
    • Stellar does not employ Nakamoto consensus but a custom consensus algorithm called Stellar Consensus Protocol. For that reason it is not possible to infer from sequences of block headers alone which sequence is valid โ€“ย for Nakamoto consensus this is simply the sequence with the highest amount of work.
    • Stellar supports custom assets: every account holder can create new assets and mint their own tokens. Spacewalk supports to bridge any Stellar asset to the Substrate chain. This implies that the Spacewalk pallet can dynamically create and mint new assets that are not known beforehand.

    The first two differences imply that there is no efficient way to implement an SPV client and a chain relay for Stellar. Spacewalk will address this by replacing the chain relay with an oracle for Stellar.

    Architecture

    Stellar Bridge Web3 Grant(5)

    The architecture of the bridge consists of the following components:

    • Vaults: this is a set of escrow accounts used to lock assets in Stellar. Their behavior is defined in XCLAIM and interBTC. In Spacewalk they have an additional property: each vault has an allow list of assets that it can lock and support for bridging operations between Stellar and the Substrate chain. This allow list is implemented through trustlines of the Stellar account. There can be at most 1000 supported assets per vault due to limitations in Stellar. Stellar users initiate a deposit by sending tokens to an appropriate vault, which they request from the bridge pallet prior to the deposit. Likewise vaults will unlock and send tokens back to Stellar accounts during a withdrawal. Every vault needs to lock a certain amount of DOT or KSM (or related) tokens as collateral with the bridge pallet. These tokens are slashed in case the vault misbehaves.
    • Bridge Pallet: this is the main component of the Spacewalk bridge that implements all logic on the side of the Substrate-based chain. Its behavior is based on interBTC. It is particularly responsible for minting tokens during deposits and burning tokens during withdrawals. It is able to support any Stellar asset by employing the Tokens and Currrencies pallets of the Substrate Open Runtime Module Library. The storage of the bridge pallet maintains the complete state that is required for the bridge to work correctly. This state contains (among others): the account ids of the vaults, the asset allow lists of each vault and book keeping information about the state of the Stellar network.
    • Stellar Oracle: is a decentralized system that provides information about the state of the Stellar network to the bridge pallet. In interBTC this is implemented through a Bitcoin chain relay. However, for reasons explaned above we cannot implement a chain relay for Stellar in the same way. The Stellar oracle is trustless and reliable and its functionality is based on specific unique aspects of Stellar:
      • The Stellar network has multiple levels of tiers, where the nodes in Tier 1 enjoy the highest level of trust of its peers. There are currently 23 Tier 1 nodes; this set and its structure is rather static and only changes rarely. It only ever changes through a voting process. We will incorporate complete information about the Tier 1 network in the bridge pallet.
      • Every Stellar node has a static signing key pair and signs messages that it gossips to the network. Particularly, every node announces through a signed message that a block has been finalized. The decentralized oracle will forward these signed messages from Tier 1 nodes to the bridge pallet. This way the bridge pallet can reliably infer what Stellar blocks are finalized.

    Out of scope

    The following aspects are out of scope of the current proposal and subject to future applications:

    • Stellar protocol updates that are required to implement a chain relay/light client/simplified payment verification for Stellar as a Substrate pallet

    Ecosystem Fitโ€‹

    The Spacewalk bridge is the first bridge between the Stellar network and the Polkadot/Kusama ecosystem, which opens up a flow of stable tokens from the Stellar network into the Polkadot/Kusama ecosystem and, simultaneously, allow any Substrate-based blockchains to implement a direct Stellar bridge.

    As part of the Pendulum goal of bringing as much fiat-based token liquidity to the parachain ecosystems, Spacewalk plays a central role. Furthermore, the entire community can benefit from this bridge by innovating on the open source code.

    Currently, we are not aware of any projects in the Substrate/Polkadot/Kusama ecosystem that are building a bridge to the Stellar network, but similar bridges are being built for Ethereum layer 2 networks, such as the Newscrypto bridge between Polygon and Stellar.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Meinhard Benn, Chairman
    • Dr. Torsten Stรผber, CTO
    • Gonza Montiel, Full stack engineer

    Contactโ€‹

    • Registered Address: The Sotheby Building, Rodney Village, Rodney Bay, Gros-Islet, St. Lucia.
    • Registered Legal Entity: Pendulum Development Ltd.

    Teamโ€™s experienceโ€‹

    Meinhard Benn

    • Involved in blockchain since 2011
    • One of the first miners of the Ethereum network
    • SatoshiPay developed one of the first payment channels in Bitcoin

    Dr. Torsten Stรผber

    • Ph.D. in theoretical Computer Science
    • 7 year academic researcher and lecturer in
      • formal languages, automata theory, complexity theory, computational logic, natural language processing, machine learning, cryptography
    • author of a WASM cryptography library

    Eng. Gonzalo Montiel

    • Computer Science Engineer
    • Degree orientation in production systems and automation
    • 10 years in the software industry as: Core/backend developer, technical Leader, team manager
    • 1 year as researcher in computer vision

    Team Code Reposโ€‹

    Members:

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    A single-node prototype of the bridge has been developed. See the link:

    A detailed bridge concept is currently being researched (described in this grant application)

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 Months
    • Full-Time Equivalent (FTE): 0.5
    • Total Costs: 30,000 USD

    Milestone 1 โ€“ Multi asset supportโ€‹

    • Estimated duration: 1 month
    • FTE: 0.5
    • Costs: 3,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can employ the bridge pallet and the Spacewalk protocol to build a working bridge.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains how we extend interBTC to support multiple Stellar assets and that provides an overview of the upcoming milestones of the protocol.
    1.Protocol specificationThe protocol will describe how vaults need to behave in order to support multiple Stellar asset.
    2a.Multi asset depositAdd support for a deposit operation involving any possible Stellar asset.
    2b.Multi asset withdrawalAdd support for a withdrawal operations involving any possible Stellar asset.
    2c.Stellar asset allow list1) Allow vaults to register the set of allow listed Stellar assets with the Spacewalk pallet. 2) Allow users to query vaults and their supported assets from the Spacewalk pallet.

    Milestone 2 โ€“ Stellar oracleโ€‹

    • Estimated duration: 2 months
    • FTE: 1
    • Costs: 12,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can employ the bridge pallet and the Spacewalk protocol to build a working bridge.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains the completed Spacewalk protocol and pallet that we built as part of the grant.
    1.Protocol specificationThe protocol will specify how the Stellar oracle behaves and what messages it forwards to the bridge pallet.
    2.Stellar oracle consensusThe bridge pallet processes information received from the oracle, which comprises signed messages from Tier 1 Stellar nodes. This is used to reliably find consensus about finalized Stellar blocks and incoming deposits.

    Milestone 3 โ€“ Multi asset collateral managementโ€‹

    • Estimated duration: 2.5 months
    • FTE: 1
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can employ the bridge pallet and the Spacewalk protocol to build a working bridge.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.Protocol specificationThe protocol will describe how vaults need to behave in case of vault liquidations involving multiple Stellar assets.
    2.Monitoring of collatoralThe bridge pallet monitors whether vaults need to be liquidated. This requires to take all locked tokens for every supported token of a specific vault into account.

    Future Plansโ€‹

    This application covers the open source Spacewalk pallet and API/protocol definition. A fully functioning instance of a Spacewalk bridge will be implemented in parallel for Pendulum. With close connections in the Stellar ecosystem, Pendulum will encourage participation in the bridge network through key partnerships.

    The Spacewalk project grows beyond the first version alongside the community of users and open source contributors, as we have seen interest in both the Stellar and Substrate communities for such a bridge. Pendulum itself will be the first use case for the bridge and will naturally justify further investment in maintenance and expansion.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    Any other grants? The Pendulum prototype was supported with a grant from the Stellar Development Foundation.

    - + \ No newline at end of file diff --git a/applications/spartan_poc_consensus_module.html b/applications/spartan_poc_consensus_module.html index 0d212895aa0..732216e723d 100644 --- a/applications/spartan_poc_consensus_module.html +++ b/applications/spartan_poc_consensus_module.html @@ -4,13 +4,13 @@ Spartan: PoC Consensus Module | Web3 Foundation Grants - +
    Skip to main content

    Spartan: PoC Consensus Module

    • Team: Subspace Labs
    • Payment Address:: (DAI) 0xeF9da023c8FAF3F84E6b3F2A2A902B03e7E72E7D

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Tagline: Proof-of-Capacity Consensus for Substrateโ€‹

    The key objective of this grant is to design and build a production ready substrate chain which employs Spartan, a simple proof-of-space consensus algorithm. Our long-term goal is to implement Subspace, a new Proof-of-Capacity (PoC) consensus blockchain, in Substrate through a follow-up general grant. After careful analysis, we have determined that implementing the full plan for Subspace goes well-beyond the scope of an open grant. However, as any proof-of-replication is based on a proof-of-space, we can begin with the simpler task of implementing the more abstract notion of proof-of-capacity consensus. Based on our experience working with Substrate so far, implementing a novel consensus mechanism is non-trivial and requires a deep understanding of the internals of FRAME and Substrate. We would therefore like to take the time to do this right.

    Relevance to Substrate & Polkadotโ€‹

    With respect to Substrate, existing consensus mechanisms include proof-of-authority (Aura), proof-of-stake (Babe), and proof-of-work (Kulupu). We would like to extend this with two more constructions: proof-of-space (Spartan) and (in a later grant) proof-of-storage (Subspace). Both of these are instances of a more general class of of proof-of-capacity protocols, which seek to replace "one-CPU-one-vote" with "one-disk-one-vote". Upon completion, this grant would serve to further demonstrate the flexibility of Substrate and FRAME for any abstract blockchain. Other teams seeking to implement slot-based PoC blockchains would also be able to re-use the core crates to reduce development time. Note that any proof-of-replication implies an underlying proof-of-space. We therefore intend to begin with the much simpler task of implementing Subspace as a pure proof-of-space consensus protocol (Spartan) before extending it into a full proof-of-storage (or replication) protocol envisioned in our whitepaper.

    Team Motivationโ€‹

    Ultimately we want to make it as easy possible for developers to build applications where users can have full control over their data. We believe blockchain-based decentralized applications reflect the best hope for this future, but have been disappointed with the sustainability, scalability, and fairness of existing options. We are building Subspace in an effort to remedy this gap, while making decentralized storage central to the design. With respect to this grant, our goal is to master the internals of Substrate so that we may leverage its rich ecosystem to create a solid foundation for our own chain, while providing an extensible set of interfaces that may be used to build any abstract proof-of-capacity blockchain.

    Project Detailsโ€‹

    Key Deliverablesโ€‹

    1. A set of abstract crates for Proof-of-Capacity (PoC) consensus: sp_consensus_PoC and sc_consensus_PoC.
    2. A proof-of-space consensus pallet, pallet_spartan, which implements these primitives using sp_consensus_spartan and sc_consensus_spartan.
    3. An implementation of substrate-node-template which employs pallet_spartan to construct a PoC blockchain client.
    4. A decoupled farmer, responsible for plotting and evaluating challenges, which connects to the client via the existing RPC.
    5. A demonstration of a live test network, consisting of multiple nodes (farmer/client pairs), with variable sized plots and adaptive difficulty.
    6. Extensions to polkadot-js which display the new relevant consensus information within the block explorer.

    These crates and pallets will begin as forks of sp_consensus_babe, sc_consensus_babe, and pallet_babe. Spartan and Babe share the same notion of timeslots and epochs as expressed in Ouroboros Praos. The key differences are that Spartan has no notion of authorities (it is permissionless) while we may largely replace the VRF evaluation & verification with evaluation of the farmerโ€™s plot and verification of the proof-of-space. Spartan and Subspace also have much in common, as they both use the same underlying SLOTH permutation, they have almost identical farmer implementations, and the consensus mechanisms are the same. The key difference is that Spartan is based on permuting a deterministic genesis piece with a nonce, while Subspace is based on permuting the actual blockchain history. This means that we can later extend Spartan consensus into Subspace consensus with minimal rework.

    Imgur

    Imgur

    User Interfaceโ€‹

    The UI will consist of a simple CLI for the farmer and client with relevant extensions to the Polkadot-js GUI.

    Imgur

    Spartan-Farmerโ€‹

    This has a deliberately simple CLI with two commands: plot and farm. The plot command allows the user to specify the plot size (in bytes), an optional storage path, and an optional seed for the private key. Plotting time depends on the hardware used but will take roughly 36 hours for a 1 TB plot using a standard quad-core machine. The plotter displays a progress bar showing percent complete and outputs some plotting statistics on completion. Once a plot has been created, the farm command may be used to connect to a client with an optional Web Socket address. The farmer will display relevant log messages during operation.

    Spartan-Clientโ€‹

    No new commands will be added to the client CLI, though we will add additional logging messages to reflect interaction with the farmer.

    Spartan-Browserโ€‹

    No new commands will be added to the browser-based polkadot-js GUI, though we will modify the display of relevant consensus information.

    Technology Stackโ€‹

    The farmer will be written in Rust. The CLI will be constructed using clap. Connection to the Substrate client will be mediated using jsonrpsee. The plot file itself will be written directly to disk using async-std. The binary search tree, used for evaluating the plot, will be built using RocksDB. All cryptographic primitives (signatures, hash functions, HMACs) will come from Substrate libraries. The SLOTH permutation is based on our own implementation of SLOTH using rug. The client will be based on the standard substrate-node-template. All consensus pallets will be based on pallet_babe and relevant slot based consensus crates. The browser GUI will extended from polkadot-js with all modification written in Typescript.

    Proof-of-Concept (prior work)โ€‹

    An initial implementation of Subspace was previously written in Rust, from scratch, without forking another chain. While we were able to get a rudimentary transactional blockchain working, which used proof-of-storage consensus, it quickly became clear that going from proof-of-concept to production ready (with all relevant tooling) was far beyond the capabilities of our team. We then learned about Substrate and began exploring the feasibility of porting over our work. This resulted in a smoke test of sorts, which showed that we could hack pallet_babe into pallet_spartan, connect to a spartan-farmer, and hook into the block production pipeline. The purpose of this grant is to take the lessons learned from writing our own implementation using this quick and dirty hack of babe, to create a production ready set of components which leverage the Rust trait system and the idiomatic FRAME methodology of decoupled crates and pallets, in order to build the foundation for a proof-of-capacity blockchain, which can leverage the full power of Substrate and provide a novel distributed storage solution for the Polkadot ecosystem.

    Non-Goalsโ€‹

    We must be very clear that we are not intending to implement the proof-of-storage consensus, distributed storage layer, or decoupled execution protocol as described in our technical whitepaper. Instead, this is only a stepping stone towards those goals. This will only implement a simple transactional blockchain powered by proof-of-space consensus. While we do intend for this implementation to be secure against all known attacks, we do not plan to launch Spartan as an actual production parachain or independent blockchain. Instead, this will only result in an initial test network for evaluation purposes.

    Ecosystem Fitโ€‹

    Background on Subspaceโ€‹

    Subspace is a blockchain secured by free disk space. This space is used to store provably-unique replicas of the history of the blockchain itself. This is in contrast to blockchains like Burst, Mass, Chia, and Spacemesh, which employ consensus based on a useless proof-of-space of random data. Similar to Filecoin, we employ a useful proof-of-storage, or a proof-of-replication, but instead of storing off-chain user generated date, the data is the history of the blockchain itself, i.e., the block headers and transaction data, yielding a proof-of-history or a proof-of-archival-storage.

    User generated data may still be retained by embedding it within a transaction, providing a permanent and immutable form of distributed storage, in contrast to the temporary and mutable distributed storage provided by Filecoin. This is most similar to the archival storage provided by Arweave. However, we base consensus entirely on disk space while ensuring many unique replicas of the blockchain are stored, whereas Arweave bases consensus on proof-of-work while only ensuring a single copy of the blockchain is retained (in the case of a single large mining pool). Since we can also estimate the amount of space pledged to the network by the average quality of the proofs-of-storage, and we know the size of the blockchain itself, we can then dynamically adjust the transaction fees to reflect the cost of storage. Unlike other networks, this allows for an efficient market for permanent distributed storage based on supply and demand.

    Subspace has also been specifically designed to maintain the security, decentralization, and permissionless nature of Nakamoto consensus, as exemplified by blockchains such as Bitcoin and Ethereum. It retains safety and liveness, given that a majority of the space pledged to network is controlled by rational farmers. It also designed to overcome a series of subtle mechanism design challenges unique to proof-of-space/storage blockchains which we refer to as the farmer's dilemma. This allows Subspace to apply a variety of layer one scaling proposals to achieve high transaction throughput and low confirmation latency, without sacrificing the security or decentralization of the network.

    Relevance to Polkadotโ€‹

    Subspace provides a scalable distributed storage layer for Polkadot, by allowing parachains to have a native, low-cost, and permanent storage option. Within the polkadot ecosystem, we are targeting other parachains and dApp developers on smart contract capable parachains. We are also exploring similar use-cases outside of the Polkadot ecosystem. Subspace can ensure the longevity and availability of data which is too expensive (i.e. by tx costs) to store on the source chain, or would negatively impact the decentralization of the chain (i.e., by increasing blockchain bloat).

    We intend to eventually launch Subspace as a parachain on Polkadot. This will allow any other parachains within the Polkadot network to utilize Subspace for permanent distributed storage. In the extreme form, each parachain block could be backed-up on the Subspace network, allowing for higher levels of decentralization and permanent data availability (even if the parachain later ceases to exist). In the average case, a parachain could employ Subspace to retain data which is too large to store internally, either through the native runtime logic or by individual smart contracts. While the same functionality is theoretically possible with networks like Filecoin and Arweave, if Subspace is also a parachain, the cost of cross-chain communication would be much lower.

    Inside the Polkadot ecosystem, Crust Network is the only existing option for off-chain distributed storage. Crust resembles Filecoin in many ways, except that it uses a Trusted Execution Environment (TEE) in places of proofs-of-replication. This limits the storage capacity of the network to providers who have special purpose hardware, making it far less decentralized and more expensive. In contrast, Subspace allows anyone with free disk space and minimal computation to act as a storage provider, allowing it to scale to many orders of magnitude larger network storage capacity. Crust, like Filecoin, also provides temporary and mutable storage, whereas Subspace provides permanent and immutable storage, which is often more suitable for blockchain-based applications and smart contracts.

    Outside of the Polkadot ecosystem there are several storage-based networks. At a high level Subspace provides both an alternative consensus mechanism (proofs-of-archival-storage) and a distributed storage network for arbitrary data. In the first case it builds on the work of blockchains such as Burst, Mass, Chia, and Spacemesh, while resolving the incentive challenges related to the farmerโ€™s dilemma (described in our whitepaper), and is therefore much more suitable for scalability. In the second case, it provides a generic platform for distributed storage, similar to Sia, Storj, Filecoin, and Arweave. Our construction is closest to Arweave, but far more incentive-compatible since consensus is based entirely on proofs-of-storage, whereas Arweave is mainly secured by proof-of-work.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Jeremiah Wagstaff (team leader)
    • Nazar Mokrynskyi (lead engineer)

    Contactโ€‹

    • Registered Address: 2320 Bowdoin Street, Palo Alto CA 94306
    • Registered Legal Entity: Subspace Labs, Inc. (Delaware C-Corp)

    Team's experienceโ€‹

    We each have three years experience designing and building blockchains and decentralized protocols at Subspace Labs. We also each have 1.5 years experience working with Rust. We recently completed 18 months of primary research for a National Science Foundation Small Business Innovation Research Grant (NSF-SBIR), which resulted in our technical whitepaper. Nazar is a full-stack engineer with over ten years experience working with PHP and Javascript and has contributed to numerous open-source projects. Jeremiah is an entrepreneur, blockchain researcher, and full-stack developer with over six years experience working in Python and Javascript.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 12 weeks
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 29,999 DAI

    Milestone 1 โ€” Implement Local Development Chainโ€‹

    • Estimated Duration: 4 weeks
    • FTE: 2
    • Costs: 10,000 DAI

    This milestone will allow for the operation of a local development chain, with a single substrate client connected to a single farmer. The farmer will be entirely decoupled, and connect over the existing RPC, though it will still be written in Rust and re-use shared primitives. The client will employ a set of consensus crates, based on modifications to pallet_babe and its dependencies. The blockchain will not have a finality gadget and will only support basic payment transactions.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up a Spartan farmer and client to create a local development chain. Once the node is up, it should produce blocks when the farmer presents a valid solution.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the documentation and blog post, we will describe how to run these tests.
    0d.ArticleWe will publish a blog post that explains the architecture of Spartan as it relates to Substrate, how it can be used for any abstract slot-based, proof-of-space consensus protocol, and how to run a local development chain.
    1.Design DocumentA detailed description of the architecture and interfaces for all FRAME pallets and modules that will be used to implement Spartan
    2.sp_consensus_PoCAbstract Proof-of-Capacity consensus primitives
    3.sc_consensus_PoCClient functionality for abstract Proof-of-Capacity consensus
    4.sp_consensus_spartanSpartan Proof-of-Space consensus primitives
    5.sc_consensus_spartanClient functionality for Spartan Proof-of-Space consensus
    6.pallet_spartanFull implementation of Spartan PoS consensus. This shall integrate with substrate-node-template and operate as a spartan-client
    7.spartan_farmerA decoupled farmer implementation which can plot, connect to spartan-client via RPC, and farm (solve challenges)
    8.spartan_clientAn implementation of substrate-node-template which runs under pallet_spartan consensus and connects to the spartan-farmer.
    9.DockerWe will provide dockerfiles to demonstrate the full functionality that runs a local development chain with a single farmer.

    Milestone 2 โ€” Implement Test Network and Browser Clientโ€‹

    • Estimated Duration: 4 weeks
    • FTE: 2
    • Costs: 10,000 DAI

    This milestone will extend the local development chain into a test network. Full and light clients will be able to synchronize the chain state. Multiple nodes (client/farmer pairs) will be able to co-farm simultaneously, with an a adaptive work difficulty that adjusts based on the amount of disk space pledged to the network. The status of the network may be monitored from the block explorer within polkadot-js.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up a Spartan farmer and client, connect to the client via the browser, and create a local test network.
    0c.Testing GuideHigher level functionality will be covered by integration tests. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish a blog post that shows the Spartan testnet is live and how it can be benchmarked via the browser app.
    1.Full Client SyncClient commits and an integration test which shows two full clients can sync with one another
    2.Light Client SyncClient commits and an integration test which shows a light client may sync with a full client.
    3.Browser Client GUI updatesA set of extensions for Polkadot-JS which render relevant consensus & chain information in the browser.
    4.Dynamic Solution RangeClient commits and an integration test, that demonstrate a dynamic solution range as farmers with different amounts of space join and leave.
    5.DockerWe will provide a dockerfiles to spin up multiple nodes, create a local test network, and run all integration tests.

    Milestone 3 โ€” Implement Secure Testnetโ€‹

    • Estimated Duration: 4 Weeks
    • FTE: 2
    • Costs: 9,999 DAI

    This milestone will extend naive consensus to be secure against all known attacks, as described in the technical whitepaper. Each attack will be analyzed through a security simulation, which will compare the operation of two nodes with slightly different implementations, or working off different branches of a fork, with different storage capacity.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationEach security simulation will include inline documentation describing the attack and how to interpret the results.
    0c.Testing GuideA different security simulation will be provided for each attack. In the guide, we will describe how to run these simulations and interpret the results. Note these simulations will not result in an objective test, but will instead show the probability that an attack might succeed or the amount of additional resources required to execute the attack.
    0d.ArticleWe will publish a blog post that the describes the nature of each attack and how Spartan preforms.
    1.Safety testDemonstrate the ability to retain safety less than 1/2 adversarial fraction of storage.
    2.Liveness testDemonstrate the ability to retain liveness less than 1/2 adversarial fraction of storage
    3.Equivocation testExtend and demonstrate that if a farmer equivocates, their plot will be burned.
    4.Sybil resistance testExtend and demonstrate that sybil plotting consumes more CPU for no advantage.
    5.Compression attack testExtend and demonstrate that the compression attack requires continuous plotting for a small constant advantage.
    6.Simulation attack testExtend and demonstrate that simulation provides a negligible advantage.
    7.DockerWe will provide a dockerfiles to run all simulations.

    Future Plansโ€‹

    Short-termโ€‹

    • Apply to the Substrate Builders Program.
    • Develop a formal proof-of-security for Subspace consensus.
    • Close our seed fundraising round and build our our engineering and product teams.
    • Begin an outreach program for storage farmers (supply-side) within the Polkadot user ecosystem.
    • Begin a customer discovery process for storage use-cases (demand-side) within the Polkadot developer ecosystem.

    Long-termโ€‹

    Apply for a series of follow-on open grants to implement the protocol enhancementsโ€‹

    • Open Grant 1: Implement the technical whitepaper
      • Spartan -> Subspace Consensus
      • Distributed Storage Network and Client SDK
      • Decoupled Execution Framework
    • Open Grant 2: Implement the scalability proposals (based on forthcoming paper)

    Continue on the road to mainnet launchโ€‹

    1. Launch a public testnet under Spartan Consensus.
    2. Convert to an incentivized testnet under Subspace Consensus.
    3. Convert to mainnet, as a Polkadot parachain.
    - + \ No newline at end of file diff --git a/applications/sr25519_donna.html b/applications/sr25519_donna.html index e38f907816d..680accec0af 100644 --- a/applications/sr25519_donna.html +++ b/applications/sr25519_donna.html @@ -4,7 +4,7 @@ sr25519-donna | Web3 Foundation Grants - + @@ -16,7 +16,7 @@ There are some features already implemented, although need some improvement, you can check the repo here https://github.com/TerenceGe/sr25519-donna
  • Are there any other projects similar to yours? If so, how is your project different? Sr25519_port Implementation by usetech-llc - which only have the sign/verify features. https://github.com/usetech-llc/sr25519 We will support all the features the rust version have, including HDKD, VRF and MulSig.
    • - + \ No newline at end of file diff --git a/applications/stable-asset.html b/applications/stable-asset.html index 07b05cb8f28..cf1790a8530 100644 --- a/applications/stable-asset.html +++ b/applications/stable-asset.html @@ -4,13 +4,13 @@ Stable Asset | Web3 Foundation Grants - +
    Skip to main content

    Stable Asset

    • Project Name: Stable Asset
    • Team Name: NUTS Finance
    • Payment Address: 0x679824d755B054a2a50358008472a6F400740319

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    There are vastly emerging assets in the Polkadot ecosystem, including both Polkadot native assets and assets bridged from other blockchains such as Ethereum and EOS. These assets introduce diversity in architecture and business model, but also fragmentizes the ecosystem since applications need to build separate markets for each of these assets. For example, stables coins can be divided into three categories: fiat-backed, crypto-backed and algorithmic stable coins, and on Ethereum each category has more than ten stable coin protocols. DEX benefits from such asset diversification but other protocols such as lending and options find it difficult to accommodate all these various assets.

    Asset synthesis is a common approach to unify asset values and hedge asset risks. One approach is to synthesize several mainstream assets or assets belonging to the same niche so that the synthetic assets represents the general trend of the underlying assets. In this approach the synthetic assets acts similiar to an index fund, and how to fairly price and adopt the synthetic assets becomes a new question. The second approach is to synthetize several assets of the same value peg such as BTC, ETH or USD. The synthetic asset has the same value peg, and it could simplifies financial application development since only one synthetic asset needs to be supported for each peg type.

    Stable Asset is an asset synthetic protocol of the second approach. It is also built with integrated swap and saving functionalities using the basket of assets.

    Project Detailsโ€‹

    The Stable Asset is an asset synthetic protocol based on Curve's StableSwap algorithm as shown below:

    Stable Swap Algorithm

    Widely adopted as swap algorithm among assets with the same peg, it also works perfectly as an asset synthesis algorithm with a basket of assets with the same peg due to the following properties:

    • When the prices of all underlying assets in the basket are equal, the number of each underlying assets in the baskets are equal as well. At this moment, the value of the synthetic asset equals the total number of underlying assets in the basket, and the collateral ratio reaches 100%;
    • Whenever the price of any underlying asset differs from each other, the value of StableAsset is smaller than the total number of underlying assets so that the collateral ratio is larger than 100%. Since all assets in the baskets are of the same value peg, their prices should fluctuate about the peg prices with low variation expected so that the overall collateral ratio should be slightly over 100%;
    • Users of the underlying swap can help to maintain the basket balance subject to underlying assets price shift.

    The Stable Asset system consists of three major components: Stable Asset, Stable Swap and Stable Savings.

    Stable Assetโ€‹

    Stable Asset is a synthetic asset with value peg such as BTC or USD. It's backed by a basket of assets with similar peg, and it provides more reliability and better peg compared to individual asset in the basket.

    The value of Stable Asset is derived from Curve's StableSwap algorithm. When there is shift in price from individual asset in the basket, the value of Stable Asset remains unchanged: The total value of Stable Asset is always the total amount of assets in the basket when their prices are all equal.

    Stable Swapโ€‹

    Stable Swap is a DEX built on top of the basket which is backing Swap Asset. It serves several purposes in the systems.

    • First, it enhances the capital efficiency of the baskets. Instead of staying still, the asset basket is used as DEX;
    • Second, it helps maintain peg of Stable Asset. Since the prices of individual asset might shift over time, DEX users can adjust the basket composition in order to reflect the current underlying asset value;
    • Third, the trading fee, along with the Stable Asset redemption fee, provide native yield to the Stable Asset holders.

    Stable Swap component is built with Curve's StableSwap algorithm with enhancement to better support the value of Stable Asset. It's different from the Curve DEX in that:

    • Its value composition is calculated based on the instrinic value of the Stable Assets instead of value of the underlying assets;
    • It has more robust and flexible basket management functionalities which are not required in DEX;
    • It's optimized in asset value computation.

    Ecosystem Fitโ€‹

    Equilibrium is planning to deliver a Curve AMM which is also based on StableSwap algorithm. Stable Asset, on the other hand, is a synthetic asset protocol built on top of the StableSwap algorithm with the following enhancement worth highlighted:

    • Liquidity providers received a strongly peg asset instead of LP token so that they don't lose usability of their assets;
    • Users of the DEX helps the synthetic assets to maintain peg in cases of asset price shift;
    • Holders of Stable Asset have native interest coming from the system itself.

    In short, Equilibrium is a DEX while uses the bonding curve to compute the balance of the underlying assets, while StableAsset is a synthetic asset which uses the bonding curve to maintain the derived value of the basket.

    Similar to Equilibrium, Sunrise DEX is a DEX that focuses on swap functionalities. On the other hand, StableAsset focus on asset synthesis and the Stable Swap module is an internal system that helps keep the basket balanced.

    Laminar is an over-collateralized synthetic asset protocol that uses various underlying assets to generate a value pegged assets. StableAsset is highly optimized for asset synthesis with a basket of assets with the same peg, and it can achieve a collateral ratio closed to 100%.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Daniel Tang, Co-founder
    • Terry Lam, Co-founder

    Contactโ€‹

    • Registered Address:ย PO Box 309, Ugland House, Grand Cayman, KY1-1104, Cayman Islands
    • Registered Legal Entity:ย ACoconut

    Team's experienceโ€‹

    NUTS Finance is a blockchain development DAO. Our team is composed of experienced developers, financiers and serial entrepreneurs. We build open source, secure and composable technology solutions to empower developers and financial services providers to launch decentralized financial applications on the blockchain.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration:ย 1 month
    • Full-time equivalent (FTE):ย 2
    • Total Costs:ย 20,000 DAI

    Milestone 1 โ€” Implement Stable Swap Moduleโ€‹

    • Estimated Duration:ย 1.5 week
    • FTE:ย 2
    • Costs:ย 7,000 DAI
    NumberDeliverableSpecification
    0LicenseApache 2.0 / MIT / Unlicense
    1DocumentationProvide documentation on components, working algorithms, and deployment processes
    2Substrate module: Stable Swap Substrate moduleThis module will implement core Stable Swap algorithm to maintain balance of the basket, e.g.
    computeD
    computeDy
    computeSwapAmount
    swap.
    Part of the algorithm is implemented in Solidity in acBTC's ACoconutSwap contract.
    3TestingComprehensive tests that cover Stable Swap Substrate module
    4DockerProvide a docker image with a Substrate chain that demonstrates this project

    Milestone 2 โ€” Implement Stable Asset Moduleโ€‹

    • Estimated Duration:ย 1.5 week
    • FTE:ย 2
    • Costs:ย 7,000 DAI
    NumberDeliverableSpecification
    0LicenseApache 2.0 / MIT / Unlicense
    1DocumentationProvide documentation on components, working algorithms, and deployment processes
    2Substrate module: Stable Asset Substrate moduleThis module will contain core functionalities for Stable Asset, which includes both how Stable Asset is minted/redeemed, e.g.
    getMintAmount
    mint
    getRedeemProportionAmount
    redeemProportion
    getRedeemSingleAmount
    redeemSingle
    getRedeemMultiAmount
    redeemMulti,
    and how the basket assets are managed. The first part is partly implemented in Solidity in acBTC's ACoconutSwap contract.
    3TestingComprehensive tests that cover the Stable Asset Substrate modules
    4DockerProvide a docker image with a Substrate chain that demonstrates this project

    Milestone 3 โ€” Support Yield in Stable Assetโ€‹

    • Estimated Duration:ย 2 week
    • FTE:ย 2
    • Costs:ย 6,000 DAI
    NumberDeliverableSpecification
    0LicenseApache 2.0 / MIT / Unlicense
    1DocumentationProvide documentation on how to handle yield in stable asset pools
    2Substrate module: Stable Asset Substrate moduleThe Stable Asset module supports yield assets, e.g. LDOT/LKSM whose intrinsic values increase over time. It's able to collect yield generated by the yield asset to generate additional total supply of the stable asset. The Stable Asset module also supports increasing swap available liquidity within the same price range to better support price shift of DOT/KSM derivatives such as LDOT/LCDOT.
    3TestingComprehensive tests that cover yield asset and amplification parameter change.
    4DockerProvide a docker image with a Substrate chain that demonstrates this project

    Future Plansโ€‹

    We are going to launch token economics and governance to support the system.

    We are also going to launch multiple Stable Assets on Polkadot and reach DeFi applications for community adoption.

    Additional Information โž•โ€‹

    We've successfully launched our first StableAsset, acBTC, on Ethereum. It receives positive feedback from the community and reaches peak total supply of 577 acBTC. The source code for acBTC can be found here.

    cBTC is an implementation of the core algorithm and used to prove our concept in Ethereum. The StableAsset will be a full-fledged asset protocol with the following anhancements:

    • Stable Asset is a Substrate module in Polkadot ecosystem;
    • Stable Asset is a generic asset module which allows anyone to create synthetic value peg asset with integrated swap and saving functionalities;
    • Stable Asset provides complete and flexible asset management solutions which is currently not available in acBTC.
    - + \ No newline at end of file diff --git a/applications/staking-rewards-collector-front-end.html b/applications/staking-rewards-collector-front-end.html index d40da1e726c..c0f932fb986 100644 --- a/applications/staking-rewards-collector-front-end.html +++ b/applications/staking-rewards-collector-front-end.html @@ -4,14 +4,14 @@ Staking Rewards Viewer | Web3 Foundation Grants - +
    Skip to main content

    Staking Rewards Viewer

    This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a > (such as this one) can be removed.

    See the Open Grants Program Process on how to submit a proposal.

    • Team Name: Jackson Harris III
    • Payment Address: Ethereum (DAI) payment address 0x2E07c8624da45FF0Bd4ba18dE7b9156995C44034.

    โš ๏ธ The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.

    Project Overview ๐Ÿ“„โ€‹

    This application is in response to Front-End for Staking Rewards Collector

    Overviewโ€‹

    This is a Staking Rewards Viewer for Polkadot and Kusama allowing users to view their staking rewards and easily download their search results. This implementation will take the work started in the staking-rewards-collector and integrate it with an easy to use modern front end using Next.js and deployed on Vercel with the goal of deploying to IPFS.

    I am interested in utilizing my current Software engineering skills to contribute to the Polkadot ecosystem. I have been following the project for a few years and have been looking for a way to participate.

    Propsoal Repo with a screenshot of mockup created in Adobe Xd. Here is a quick demo video of a work in progress Video and a Deployed demo on vercel. (currently, the vercel version is not making requests. Looking at swapping out the curlRequest for fetch API calls.

    Project Detailsโ€‹

    MockUpโ€‹

    Technologiesโ€‹

    We expect the teams to already have a solid idea about your project's expected final state. Therefore, we ask the teams to submit (where relevant):

    • Mockups/designs Adobe Xd
    • Front End: Next.js, Material Design Bootstrap React
    • Back End: N/A (The applicatoin will use a serverless design on Vercel/Fleek)

    Ecosystem Fitโ€‹

    The staking-rewards-collector is a tool to gather staking rewards for given addresses and cross-reference those with daily price data. This is a very useful tool for every validator and nominator in the ecosystem. However, since it has currently a CLI and requires some technical knowledge to set up (git, nodejs, yarn). A front-end hosted on a website could help many users getting access to this tool and enjoy the benefits.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    • Registered Address: Can Provide Home Address offline
    • Registered Legal Entity: Freelance/Contractor for tax purposes I am an Independent Contractor

    Team's experienceโ€‹

    Jackson Harris: Software Engineer 3 years, Digital Marketing/Business Development 10 years.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    If you've already started implementing your project or it is part of a larger repository, please provide a link and a description of the code here. In any case, please provide some documentation on the research and other work you have conducted before applying. This could be:

    • Original RFP (requests for proposal),
    • Conversation reference to my original submission with @axl of w3f

    Development Roadmap ๐Ÿ”ฉโ€‹

    Milestone 1 (Implementation & Testing)โ€‹

    • Estimated Duration: 12 days
    • FTE: 12
    • Costs: 4000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.UI for user inputDevelop an UI to request necessary data from the users.
    2a.Address LookUp FunctionalityAllow users to enter multiple wallet addresses for either or both the Polkdaot and/or Kusama networks and deploy these features to Vercel.
    2b.CSV/JSON DownloadEnable users to download a copy of their lookup results in either CSV or JSON format.
    3.Form validationAdd form validation to wallet address input while still allowing for multiple addresses to be entered. Validation for fiat amounts that will properly display based on the selected currency.
    4.UI for data visualizerDevelop an environment to display the output (.csv and .json) for the end user in a pleasurable way.
    5.Tooltips/HelpersImplement help texts and tooltips to explain the different features and inputs to users.
    6.TestingWrite tests to confirm the application behaves as expected
    7.Polishing & DeliveryReach out for feedback to the Grants Team. Integrate final feedback on functional, as well as cosmetic changes like font size, colors, typos etc.

    Future Plansโ€‹

    • Collaborate with the original RFP proposer to determine how to best promote the finished application throughout the community.
    • Ask the community for suggestions to improve and add new features as necesary.
    • Refactor and Deploy to IPFS

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    • I watched a video, on youtube, with Gavin Wood where he mentioned the Web3 Foundation and the grants program.
    - + \ No newline at end of file diff --git a/applications/stardust.html b/applications/stardust.html index 25a73ca362c..aaf2934efc1 100644 --- a/applications/stardust.html +++ b/applications/stardust.html @@ -4,7 +4,7 @@ Derivative Powered Uncollateralized Stablecoin Research and Design | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Derivative Powered Uncollateralized Stablecoin Research and Design

    This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a > (such as this one) can be removed.

    See the Grants Program Process on how to submit a proposal.

    • Team Name: Stardust Labs Inc.
    • Payment Address: 0xF3d5F194D9eF961a85a4d5be05EFda7B2B33005d (DAI, Ethereum Mainet)
    • Level: 1

    โš ๏ธ The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.

    Project Overview ๐Ÿ“„โ€‹

    This proposal is in response to an RFP for an Uncollateralized Stablecoin (Specifically: https://github.com/w3f/Grants-Program/blob/master/rfps/uncollateralized-stablecoin.md).

    Overviewโ€‹

    • A brief description of your project.

    We are proposing a functionally different approach for an uncollateralized stablecoin. Extant uncollateralized stablecoin solutions are based on creating and burning an ERC20-style token. By monitoring exchange rates and managing the token supply, these uncollateralized stablecoins seek to balance supply and demand to peg the exchange rate to a reference currency. To date, none have achieved commercial success and the inherent limitations and flaws of this architecture are quickly becoming apparent even with a theoretically perfect implementation. This paper dives deeper into the current challenges (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3952045), the first of which is a baseline support level of demand for operational stability which this RFP seeks to address.

    Stardust Labs is proposing a fundamentally different approach that uses financial derivatives to programmatically and algorithmically generate a "synthetic" derivatives-based stablecoin that can be originated or settled on demand.

    At a high level, the primary focus of stablecoins is risk mitigation. Modern commercially successful architectures derisk by having a centralized entity issue tokens based on physical reserves of the pegged currency held in custody. The primary problem here is trusting the custody of a centralized entity, a particular challenge considering most are cross-border, transnational companies with limited auditing and opaque balance sheets.

    Our proposal is to utilize the latest advancements in decentralized finance to instead originate synthetic financial derivatives on demand. This securitized financial instrument would emulate the stability and utility of a stablecoin without requiring collateral or physical custody. In short, put-call parity allows the algorithmic construction of a synthetic financial instrument from perpetual contracts that effectively locks the value relative to the pegged currency at the risk free rate. By securitizing this construct into a token we can generate a synthetic stablecoin on demand as well as close them on demand as long as a perpetual contract can be accessed and decentralized markets maintain enough liquidity in the perpetual contract market.

    • An indication of how your project relates to / integrates into Substrate / Polkadot / Kusama.

    What we are proposing is relatively unprecedented but there are promising signs. Angle Labs launched on Ethereum last year as an ERC20 token in order to provide a stablecoin pegged to the Euro. They term themselves "the first decentralized, capital efficient and over-collateralized stablecoin protocol" (https://www.angle.money/). Angle Lab's stablecoin is collateralized with Ethereum and more specifically over-collateralized to ensure safety. In July of 2021 they published a whitepaper indicating that they were going to deploy self-minted perpetual contracts as a tool to bring in additional collateral and protection against large price moves. These perpetuals provide additional outsourcing of risk in addition to directly increasing ETH collateral. 5 months ago, they raised $5M from a16z and others to explore the technology. Our proposed architecture would bring that attention and innovation to the Polkadot network. More importantly for the Polkadot ecosystem, our proposal is decentralized and truly uncollateralized as it manages risks entirely through derivatives, and can generate synthetic stablecoins between any arbitrary pairs provided there is a perpetual contract market with sufficient liquidity.

    • An indication of why your team is interested in creating this project.

    Stardust Labs is focused on developing foundational advancements in distributed ledgers that improve consumer and user safety. Our overall goal is to build safer, more efficient financial infrastructure for the public. While extant distributed ledger applications have largely solved the use case of peer to peer payments, extant implementations of stablecoins currently have challenges that limit their use or safety.

    Stardust Labs is specifically drawn to this RFP as our team has extensive expertise in developing safe and efficient financial products for traditional commercial banks and specific subject matter expertise in decentralized finance and financial engineering. We ultimately believe an uncollateralized, independent stablecoin would have unprecedented utility in the space.

    Project Detailsโ€‹

    Historically stablecoins have been roughly one of two types. The first are asset-backed tokens controlled by centralized entities that maintain custody of physical assets. These assets could be fiat currencies, a basket of cryptocurrencies, or physical commodities. Examples of this are Tether (USDT), Gemini Dollar (GUSD), and Paxos Gold (PAXG). The second are algorithmically maintained ERC20 tokens that are actively minted or burned based on dex trading exchange rates to maintain parity.

    The challenge with the former is that a user is implicitly trusting the centralized entity to maintain those assets with no guarantees. With the latter, it is easy to mint coins during periods of increasing demand, but it is very difficult to burn tokens during periods of decreasing demand.

    Stardust labs recommends a fundamentally different approach. The primary utility of any stablecoin is mitigating the risk of future price movements. The past year has seen strong developments in decentralized financial markets and powerful tools for de-risking in the form of options and perpetual contracts. We can use these products and financial engineering to create a synthetic financial instrument that replicates the performance of a stablecoin on demand. As long as the underlying asset can reach a sufficiently liquid options pair, we can combine products to create a stable structure that ultimately results in a fixed future return in the pegged currency at the risk free rate thanks to put-call parity. If this relationship is broken, that mathematically means that a profitable risk-free arbitrage opportunity exists which should be very short-lived in efficient, open financial markets.

    Defirate has a good in-depth explanation of both how perpetual contracts work and how they can be hedged to earn the nominal interest at the risk-free funding rate. (https://defirate.com/perpetual-contracts/)

    Ultimately, our proposed stablecoin isn't a managed token or backed by an underlying asset. Instead, the stablecoin smart contract purchases and returns a tokenized, engineered bundle of options and perpetual contracts that, combined, ensure a stable price relative to the pegged currency in the future. We term this type of asset a 'synthetic' stablecoin, termed because it is the exact same process as building a synthetic option. In addition, this process is similar to securitization whereby several financial products are pooled to yield a purchasable interest-bearing security with a different risk-reward curve.

    The astute reader will observe that constructing these synthetic options will incur a cost. However, the advent of flash loans and depository institutions like AAVE allow the capital in the smart contracts to be deployed to generate risk-free interest, allowing the stablecoin contract to offset the cost of purchasing these options. We envision the smart contract assessing either a transaction fee for origination or a penalty for early withdrawals where users have not held the synthetic stablecoin long enough for the interest to offset the contract purchase fees and transaction costs. Though it varies dramatically, Bitcoin futures seem to have a 3.69% risk-free rate (https://quantpedia.com/what-is-the-bitcoins-risk-free-interest-rate/), the risk free rates at Binance for Perpetual contracts (the funding rate) is 0.01% every 8 hours (or an annualized rate of 11.57%). Meanwhile, the fee to enter a perpetual ranges from 0.05%(dxdy) - 0.02% (Binance) so it is likely that these fees would be entirely covered by the interest payments on the overall stabilized value.

    Why Now & Risksโ€‹

    Ultimately this is only possible today thanks to both the recent advancements in decentralized finance, and more importantly the liquidity in the market. One of the outstanding risks to this stable coin is if liquidity quickly dries up. An example of the impact of liquidity shocks on securitized financial derivatives is best seen by the 2008 financial crisis. Unlike traditional financial markets however, positions are monitored in real-time and can be forcefully liquidated, preventing direct losses. However, there are fundamental limits on how much stability this construct or any uncollateralized stablecoin could absorb. One of the key outstanding questions, and the main exogenous risk that is currently unknown, is the strength of correlation between overall crypto prices, volatility, and its impact on the liquidity of decentralized financial markets.

    One of the primary anticipated challenges is the lack of regulatory oversight in the markets and the ability of individual companies to offer arbitrary leverage ratios. For example, Binance is offering 125x leverage meaning some perpetual contracts are at risk of being forcibly liquidated even with less than a 1% price movement. (https://bitcoinist.com/binance-125x-leverage-sparks-criticism-from-community/) Our smart contract can simply repurchase another perpetual contract during liquidation, however a risk exists that market liquidity would dry up during periods of unprecedented volatility such as a major market crash. Without liquid markets with leveraged counter-parties willing to absorb the risk, the synthetic stablecoin would be forced to return the money to the user in the underlying currency at the price of the stable peg, having done its job, but at the same time being unable to offer continued stability.

    Due to the use of options, perpetuals, and lack of human intervention, our proposed system is able to absorb far more volatility than algorithmically managed uncollateralized stablecoins. These implementations have strong negative feedback loops during periods of decreasing demand and, as of date, no robust solution for reducing supply. These struggles have caused many to fail even under benign conditions and these challenges will be dramatically amplified in the type of major market crash where liquidity in financial markets begins to dry up. At that point, the only efficient solution would be custodied collateralized assets by trustworthy centralized entities.

    Ecosystem Fitโ€‹

    A decentralized uncollateralized synthetic stablecoin has significant utility for decentralized financial applications and would be a transformative development beyond just the Polkadot ecosystem. In addition to providing a stable store of value that works synergistically with demand in the market, the smart contract mathematics are entirely fungible and can be set up for any arbitrary currency as the underlying asset and pegged currency provided a sufficiently liquid options market exists.

    The primary target demographic and audience would be decentralized financial applications and any user who seeks a stable store of value that isn't dependent on a centralized third party, instead risk has been decentrally allocated to the participants on decentralized markets.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Team Lead: Adit Patel
    • Team Member: Theresa Garcia

    Contactโ€‹

    • Registered Legal Entity: Stardust Labs Inc. is a registered C-corp incoporated in Wyoming

    Team's experienceโ€‹

    Adit is a technical expert on cryptography, distributed ledgers, financial markets, and new product development. He graduated Columbia in 2011 with a BSc in Applied Physics and a minor in Econ. During his time there, he took additional coursework focused on cryptography, statistics, and fundamental computer science. After graduating, he joined Capital One and quickly rectified the failing, newly launched small business brand. These efforts made him well known as the go-to analyst for successful new product development, strategy and launch. He was tapped to design and launch financial products for Hispanic consumers and tapped again to build Capital Oneโ€™s B2B financial products. During his tenure there, Adit experienced first hand the hard learnings that lead to efficient risk mitigation in financial products and the intricacies of financial engineering. He has a decade of technical experience at the intersection of finance and technology.

    Theresa has a particularly deep knowledge on the current dynamics, consumer sentiment and market opportunities of the distributed ledger ecosystem. Sheโ€™s been personally involved with distributed ledgers and their commercial applications for 5+ years. She has successfully launched and commercialized multiple new products. Throughout her career, Theresa has repeatedly driven outsized results, helping launch multiple products from emotional education devices for children disguised as teddy bears to documentary streaming sites. In addition to multiple successful product launches as an employee, she has started and launched her own successful e-commerce business on her own from the ground up. There she developed her own products, stood up supply chains and manufacturers, created and executed international marketing campaigns and sales funnels, and managed employees all over the world to support her global operations, successfully growing her company from an idea to $70,000/month in sales.

    Both Adit and Theresa are also full stack developers who have successfully deployed a crypto wealth management mobile to building their own blockchain binary.

    Stardust Wealth iOS App: https://stardust.finance/app Our test blockchain network: https://explorer.stardust.finance/

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Through this grant proposal, we aim to provide a well-detailed analysis of the current state of industry for stablecoins, extant and historical stablecoin solutions including failures, and a summary of the current view by the US Federal Government. These materials will also be used to generate a well-defined framework for a derivatives based synthetic stablecoin capable of originating and closing positions.

    Overviewโ€‹

    • Total Estimated Duration: 5 Weeks
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 10K

    Milestone 1 โ€” State of the Industry on Stablecoinsโ€‹

    • Estimated duration: 2 Weeks
    • FTE: 2
    • Costs: 5k USD
    NumberDeliverableSpecification
    0.RightsAll developed materials will be publicly accessible and public domain.
    1.Research GoalWe will provide an overview of the current state of the modern stablecoin ecosystem including a summary of demand and historical growth over time, industry size and a rough forecast of future growth, the largest existing players, and the main revenue and cost drivers for service providers.
    1a.Specific CoverageCoverage will span historical and current industry volumes, academic sources, and recent developments.

    Milestone 2 โ€” Terra Collapse Deep Diveโ€‹

    • Estimated duration: 3 Weeks
    • FTE: 2
    • Costs: 5K USD
    NumberDeliverableSpecification
    0.RightsAll developed materials will be publicly accessible and public domain.
    1.Research GoalStardust will breakdown and perform a deep dive into the collapse and ultimate failure of Terra to maintain it's peg to USD.
    1a.Specific CoverageSpecific deep dives at this time are an overall summary of events and the price changes in early May 2022, the large and consistent outflows from their lending protocol Anchor, the complete saturation of lending pools on Curve that contained UST, and finally the deployment of BTC reserves by the Luna Foundation Guard (LFG).

    Future Plansโ€‹

    • We'll follow up with a future research grant on historic failures of stablecoins, a summary of articulated Federal Government viewpoints on stablecoins, and its potential impact on the future regulatory landscape. Our long-term vision is to build an understanding of the stablecoin infrastructure environment and then develop and deploy an improved version on the Polkadot Network.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/starks_network.html b/applications/starks_network.html index 817d4b78c26..64c8a62d28c 100644 --- a/applications/starks_network.html +++ b/applications/starks_network.html @@ -4,13 +4,13 @@ Starks Network | Web3 Foundation Grants - +
    Skip to main content

    Starks Network

    This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

    • Proposer: gbctech
    • Payment Address: bc1qcx9jcqlvppyp2welewtmvwqvyl36sgeh09dyqk

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Brief Descriptionโ€‹

    Zero-knowledge proof (zkp) is a cryptographic technology which enables you to prove that you know a secret without revealing it. It is a powerful tool in the paradigm of Web 3.0 where people can prove certain attributes about themselves without giving away their private data. It can also be used to prove computational integrity which can result in novel applications such as a private smart contract on a blockchain.

    However, it requires tremendous expertise to construct a zkp for certain computation. This hinders the adoption of this powerful technique for everyday use. Wouldn't it be great if we can construct a zkp for any general purpose computation without a deep understanding of zkp? Enter the Distaff VM, a zk-STARK virtual machine written in Rust. For any program executed on Distaff VM, a STARK-based proof of execution is generated. This proof can then be used by anyone to verify that a program was executed correctly without knowing the inputs to the program or even the program itself.

    The Starks Network is a zk-STARK based zkp parachain for the Polkadot/Kusama ecosystem. At its core, it uses the Distaff VM for zk-STARK proof generation and verification. Powered by the Substrate blockchain framework, the Starks Network can serve other blockchains and enable applications such as private smart contract and private credential verification.

    Substrate/Polkadot Integrationโ€‹

    Substrate is a powerful blockchain framework. It enables us to bootstrap the skeleton of the Starks Network in a short time. The Starks Network blockchain serves several purposes:

    • It keeps a record of all the proof verifications;
    • It provides a way to setup a smart contract for a computation and to carry out subsequent actions based on the proof verification result;
    • It enables the flow of economic incentives among the users and the verifiers.

    As already mentioned, other blockchains in the Polkadot/Kusama network can interact with the Starks Network via cross-chain message passing. Developers on other chains can design smart contract which benefit from zkp and they don't have to be experts of zkp at all.

    Team Interestโ€‹

    The Glacier Blockchain team is an advocate of the Web3 ideology. It strives to help build an open, transparent and inclusive network which returns the sovereignty of data to their owners. It is a member of the DIF and has contributed to the international standardization of decentralized identity and verifiable credentials. The Glacier Blockchain team has also co-founded the Web3 Identity Lab with the KILT Protocol team to work on scientific research and technical solutions from verifiable credentials to user privacy protection.

    We have been fascinated by the progress of latest cryptographic primitives such as zero-knowledge proof. We have learned the potential of the Distaff VM project regarding privacy protection and computation integrity through our frequent discussions with the author of the project. We truly believe the combination of a general purpose zk-STARK virtual machine and the Substrate framework will make the Starks Network a valuable player in the Polkadot/Kusama ecosystem.

    Project Detailsโ€‹

    Introduction to the Distaff VMโ€‹

    A high level architecture of the Distaff VM is shown as the following.

    distaff_overview

    The Distaff VM provides a set of assembly language which can be used to construct a general purpose computation into a program which can be interpreted by the virtual machine. The basic work flow of the VM is:

    a. Takes 2 inputs: a program and a set of inputs for the program;

    b. Executes the program with the given set of inputs;

    c. Outputs hash of the inputs, hash of the outputs generated by the program, and a STARK proof attesting to the correct execution of the program.

    Then the verifier can take the hash of the program, hash of the inputs, and hash of the outputs, and uses them to verify the STARK proof. As such, the user can prove to the verifier that she owns some secret data which, when used as the input of a program, can yield certain output. She never has to reveal the input data to the verifier; thus her privacy is protected.

    One way to automate this process is to set up a smart contract on the blockchain which can perform the proof verification. As such, a lot of real-world verification work can be moved on-chain and the users never have to give away their secrets for e.g. credential verification.

    Architecture of the Starks Networkโ€‹

    The overall system architecture and the basic work flow of STARK proof generation and verification on the Starks Network is shown as following.

    system_disgram

    a. A verifier will set up an on-chain smart contract with a target Distaff VM program embedded.

    b. A user will interact with the smart contact, get the program and generate a proof with their secret inputs using the Distaff VM embedded in the user client application (Step 1, 2 and 3).

    c. The user sends the hashes and proof data (results) back to the smart contract via a transaction (Step 4).

    d. The smart contract will verify the results using the Distaff VM built in the blockchain node binary, make a decision and update its state (Step 5 and 6).

    As such, the user has interacted with an on-chain smart contract without revealing their secret data. It should be noted that the Distaff VM will be made as part of the user client application for proof generation. It will also be made as part of the blockchain node binary and accessible to the on-chain smart contracts.

    Existing Problem and Our Solutionโ€‹

    It seems straightforward to perform step c in the previous section on a Substrate blockchain. However, it is actually not feasible and here is why. Compared to other zkp techniques such as zk-SNARK or Bulletproofs, one disadvantage of zk-STARK is the relatively large proof size. The typical size of a Distaff VM proof is around 100KB. It would be unrealistic to store all the proofs on-chain as the blockchain storage is kind of expensive.

    So, is there a way to store the proof data off-chain while we can still make use of them for zkp smart contract verification?

    Thanks to the Substrate framework, we have a tool to solve this problem. An off-chain worker (ocw) is a Substrate subsystem which can process off-chain data in an asynchronous way. It can perform non-deterministic tasks such as Web requests or CPU-intensive computations and write the computation results back to the chain as signed transactions. As such, we can have some stark data nodes in the system which will cache the proof data sent by the user in a local data store or even a decentralized data storage such as IPFS. The ocw will check the data store periodically, process the proof data, get the verification results and update the state of an on-chain smart contract with a transaction. This approach can solve the storage problem of off-chain proof data.

    But there are again issues as a result of this approach. What if a node runner tries to cheat with their proof? What if a malicious node sends back incorrect verification results intentionally? We have designed counter measures regarding these threat models and they will be unfolded as our project progresses. In the scope of this grant application, we will focus on the PoC where an on-chain smart contract interacts with the Distaff VM using proof data stored off-chain.

    We expect the teams to already have a solid idea about the project's expected final state.

    Ecosystem Fitโ€‹

    There are some existing projects which can be related to the Starks Network. In general, they fall into the following categories:

    • Blockchain projects which provide confidential computing service using a hardware Trustable Execution Environment (TEE). Phala Network and SubstrateTEE are good examples of such projects. The main difference is that we use zkp instead of hardware chips to provide similar functionalities. Our approach makes the Starks Network immune to hardware bugs/failures/backdoors in proprietary CPUs.
    • Zerochain is a Substrate based zkp blockchain project. The main difference from the Starks Network is that it uses zk-SNARK instead of zk-STARK VM as its zkp power house. The zk-SNARK is well known for its small proof size. But it requires a trust setup process to get started which limits its usage. In addition, the function of the Zerochain is focused on private transaction, while the Starks Network aims to provide zkp service for general purpose computations.
    • The Cairo project from StarkWare (inventor of the zk-STARK technology) announced a few days ago. As explained in the press release, "Cairo is the first production-grade platform for generating STARK proofs for general computation". The description of its functionalities have a lot of similarities to what our Starks Network have to offer. It is fair to say the Cairo project is a powerful counterpart of the Starks Network--only it is built in the Ethereum ecosystem. The whitepaper, documentation and related tooling are yet to come in the next few months (unsure if it is open sourced). And we will closely watch its development as it is exciting and inspiring to have more projects coming in the field of zk-STARKs application.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Dr. Xiao Zhang - CEO/Project Lead/Blockchain Researcher
    • Ming Chow - System Architect/Substrate Developer
    • Xinran Chen - Substrate Developer
    • Jinjiao Yin - Full-stack developer
    • Linjun Lu - DevOps

    Team Websiteโ€‹

    Glacier Blockchain Technology is a company registered in Yantai, Shandong, P. R. China.

    Team's experienceโ€‹

    Dr. Xiao Zhang is a researcher with experience in computer architecture, blockchain and cryptography. He holds a PhD in computer science from the University of Twente of the Netherlands. He is an active advocator of Web3 and also one of the first Polkadot ambassadors in China. His current research interests include decentralized identity, verifiable credentials and zero-knowledge proof technology for privacy protection.

    Ming Chow has a bachelor's degree in computer science. He has 10 years of experience in system architect and software development. He has worked in several high-tech companies in Guangzhou and Shenzhen in China and lead the design of several core business software. He is responsible for the Substrate system architecture design for the Starks Network.

    Xinran Chen has worked for many years in Internet companies such as Talkingdata, PingCAP and Qiniu.com. He has started working on blockchain product since 2019. He has contributed codes to Boltdb for Tendermint. He is the Substrate developer for the Starks Network.

    Jinjiao Yin is a senior computer science student of Shandong Technology and Business University. She is the group leader of the Student Blockchain Lab. During her college time, she has won multiple computer science competition awards. She is specialized in full-stack web app design for blockchain project.

    Linjun Lu is a senior software engineering student of Shandong Technology and Business University. She is a senior member of the Student Blockchain Lab. She is particularly interested in application DevOps on Linux platforms.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1 month
    • Full-time equivalent (FTE): 3
    • Total Costs: 1.83 BTC

    Milestone 1 โ€” Integration of the Distaff VM as a Substrate Native Runtime Moduleโ€‹

    • Estimated Duration: 1 month
    • FTE: 3
    • Costs: 1.83 BTC
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can run our Substrate node. Once the node is up, it will be possible to interact with the Distaff VM module via API calls to perform e.g. zk-STARK proof verification.
    0c.Testing GuideWe will provide a full test suite (mock and test files) for the VM module describing how the module can be tested. We will also provide a guide on how to perform the tests.
    1.Substrate module: Distaff VMWe will reorganize the Distaff VM project, split its functions into a primitive module and a frame pallet following the conventions of the Substrate framework. In the primitive module, we will separate the proof generation and proof verification function and keep only the proof verifier on chain.
    2.Substrate chainThe Distaff VM will be embedded as a native runtime module in the Substrate node. It can serve the off-chain worker, which will be a Wasm runtime module, via the runtime_interface feature of the Substrate framework.
    3.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain.

    Community engagementโ€‹

    We will publish an article on medium upon the completion of this project. Meanwhile, we will give talks and do AMA sessions to advertise the project to the Polkadot community.

    Future Plansโ€‹

    • The Starks Network plans to become a parachain for both the Polkadot and the Kusama network.
    • This application covers milestone 1 in stage 1 of the Starks Network project. In stage 2 of the project, we will focus on the UX/UI design and provide several typical use cases (credential, smart contract) for evaluation. A MVP will be running in a testnet.
    • In stage 3, we will experiment the cross-chain communication with other parachains. If things go well, we will provide zkp support to the smart contracts in other parachains (Plasm or Edgeware are our choices right now).
    • After its main functionalities are finalized and tested, the Starks Network will issue its own tokens. And we hope other parachains in the ecosystem can benefit from its zkp service. The network will receive economic incentives in the process to sustain its service model.

    Additional Information โž•โ€‹

    • What work has been done so far?

      We have preliminarily integrated the Distaff VM as a native runtime module into the Substrate framework. We have saved the locally generated proof data as binary files and sent them to the Distaff VM module via RPC request. As show in the screenshot below, the VM in Substrate can function correctly and send back verification results indicating a passed/failed verification.

      test_result

    • Are there are any teams who have already contributed (financially) to the project?

      No.

    • Have you applied for other grants so far?

      No, we are self-funded so far.

    - + \ No newline at end of file diff --git a/applications/stone-index-on-substrate.html b/applications/stone-index-on-substrate.html index a2e9f828d6d..3062f783e75 100644 --- a/applications/stone-index-on-substrate.html +++ b/applications/stone-index-on-substrate.html @@ -4,7 +4,7 @@ Stone Index on Substrate | Web3 Foundation Grants - + @@ -15,7 +15,7 @@ Alternatively if user wants to redeem the underlying index, they can choose to deposit the index token back into the Stone Platform. Subsequently the underlying tokens would be sent back to the userโ€™s wallet.

    Use case diagramโ€‹

    Stone index use case flow

    There are 2 types of actors in Stone Index:

    Runtime module/chain - Indexed basket management moduleโ€‹

    Public exposed methodsโ€‹

    // To create an index with 2 tokens and weight per token with an unique name, and return with the newly created index ID
    create_index(origin, name Vec<u32>, address1 Address, weight1 u8, address2, weight2 u8) -> Result<i64, Error>

    // To update the details of an existing index
    update_index(origin, index_id u32, name Vec<u32>, address1 Address, weight1 u8, address2, weight2 u8)

    // To purchase an index with desired token(deduct tokens from user), and mint an index token(The token will be sent to the user address)
    * purchase_index(origin, index_id i64, amount u32) -> Result(Error)

    // To redeem token with index token, it will burn the index token and transfer the underlying token back to user address
    * redeem_index(origin, index_id, amount u32)

    Runtime storageโ€‹

      trait Store for Module<T: Trait> as StoneIndex {
          Index: map haser => StoneIndex;
      }

    MockUIโ€‹

    Stone Index for DOT

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Individual

    Team's experienceโ€‹

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 - Liquid staked DOT tokenโ€‹

    In the grant program, the Stone Team aims to provide liquidity of staked tokens on Polkadot ecosystem, and the special LP token which bounds to staked assets, like DOT token. We are aware that there are multiple teams are actively working on Polkadot ecosystem and more exciting projects on the roadmap, we'll focus on DOT-bound staked assets like aDOT first for the milestone 1 We'll also provide an easy-to-use web based UI that connects to the chrome based DOT wallet, and user can buy/sell the index using their DOT tokens easily, this UI will be part of https://stonedefi.io

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialPublish tutorials and documentation in different channels, e.g. Stone Medium and other social media platforms
    1.UI/UX for Stone PlatformUpdate and add a new UI component that allow user to buy/sell stone index using different crypto assets, DOT for milestone 1
    2.Indexed basket managementAn indexed basket management module is a set of Substrate pallet which allows creation and update the indexed basket, as well as mint and burn index token function
    3.DEX integrationWe will build the DEX trade function on top of another Polkadot Program PolkaDex

    Future Plansโ€‹

    Upon the completion of Milestone 1, the team will potentially add more functions like:

    Stone Index will be part of Stone Platform, and this grant program is the very first attempt of extent to Polkadot ecosystem in Stone Platform. The Stone team will continuously add more valuable instruments, and the team is aware that more and more teams and projects are rushing into Polkadot ecosystem, so we'll keep an eye on the new initiatives, and onboard those legitimate assets once they are ready

    Additional Information โž•โ€‹

    RockX(https://rockx.com) founded by veterans and hardcore developers in Blockchain space, Rockx has been developing critical tools and applications for various Blockchains. RockX team is actively involved in building a better blockchain community and won quite some grants last year, the 2 examples are:

    RockX helps the Stone Team to build the Stone Platform and bring Stone Platform to multiple blockchain platforms, so that allow Stone Platform users with one stop investment solution and the best user experience.

    - + \ No newline at end of file diff --git a/applications/subalfred.html b/applications/subalfred.html index 96851a8366c..ac38aaf2a64 100644 --- a/applications/subalfred.html +++ b/applications/subalfred.html @@ -4,7 +4,7 @@ Subalfred | Web3 Foundation Grants - + @@ -22,7 +22,7 @@ There are around 30+ features. Please note this is a part of milestone 1.

    I'd love to convert these milestone to issues on the repository. It will be much easier to track the status.

    Amendingโ€‹

    - + \ No newline at end of file diff --git a/applications/subauction.html b/applications/subauction.html index 256c0742498..fc60f2cbb6d 100644 --- a/applications/subauction.html +++ b/applications/subauction.html @@ -4,7 +4,7 @@ Subauction | Web3 Foundation Grants - + @@ -16,7 +16,7 @@ Council will be able to set fees, fund interesting activities from the treasury or create proposals/referendums for the community. Council can elect curators that will manage platforms content. It is expected that council will drive the project towards more interesting and experimental use-cases than plain auctions of art - a lot of stuff can be tokenized and may be attractive for the community to be able to sell different item categories.

    There are several approaches to implementing the actual governance module.

    Part of the auction palletโ€‹

    This makes the most sense at the first sight because we can utilize the power of Substrate to implement governance via collectives, democracy and voting pallets. However, our plan is to make the auction pallet really flexible and introducing governance can pollute auctions with unnecessary complexity regarding the governance (and thus make it less re-usable for anybody who would like to implement another system on top of our pallet). Also, there are plans for having multiple instances of the auction pallet on chains supporting NFTs so it's also a question how we would keep only single instance of governance in this case.

    Separate palletโ€‹

    This seems like an ideal solution because it has a benefit of using Substrate but factors out all governance functionality to a separate pallet. Downside would be that each NFT platform where we plan to integrate our auction-pallet would have to integrate two pallets instead of one to their runtime.

    Smart contractโ€‹

    Smart contract approach has following advantages

    However, downside is obviously not exploiting great capabilities that Substrate offers and having to implement a lot of stuff by reinventing the wheel.

    Tokenโ€‹

    We have decided to use Basilisk as the home chain so the auctions will leverage Basilisk's fungible as well as non-fungible tokens for transfers and governance. As it uses FRAME's Uniques pallet it will be possible to easily migrate and reuse the solution on other Substrate based chains.

    Curatorshipโ€‹

    Curatorship is closely tied to the governance since only approved members can have elevated privileges over the system (e.g. vote on removal of inappropriate content). Any user can report offensive content to the curators. Curators then remove the content or reject the report. We will probably run a Discord/Telegram channel to open a discussion about a right way to do the curatorship and what kind of stuff is acceptable for public auctioning and what is not

    Content curationโ€‹

    Positive motivationโ€‹

    Users will be incentivized to provide a good quality content by either getting tips from the council for a good catch or fullfilling bounties which were announced by other uses. As an example, there can be a user who wants to own a digital art collectible but is not able to or does not have time to search for it. If another user provides such a collectible to the marketplace, they can be rewarded not only by the collectible price but a bounty on top of it.

    Negative motivationโ€‹

    On the other hand, we're aware the content needs to be moderated to some extent because of possible unsolicited character. In the first place we aim to combat this by starting with VIP auctions that will be pre-approved by the council before public launch. Eventually we plan to open the auction creation process a bit more and start to allow create auctions without council approvement based on gaining reputation by using our platform without violation of rules. Once our solution starts to offer these kind of public auctions for almost anyone to create, we want to introduce a penalty system to control that unsolicited content will be removed and the person who advertises it will be punished depending on the level of severity. The slash might be taken from a security deposit at the time user creates the auction.

    Offence levelContent propertyExamplePunishment
    1InappropriatePornographySlash up to 50% of the reserved funds for a specific purpose (e.g. auction) + up to 10% of total funds
    2OffensiveExplicit brutal content like violence/accidentsSlash up to 100% of the reserved funds for a specific purpose (e.g. auction) + up to 20% of total funds
    3HarmfulChild porn/Women abuseSlash up to 100% of the total funds

    Business Model Mechanicsโ€‹

    To keep on moving this project forward, we need predictable revenue streams to secure resources of different parts of our NFT marketplace such as content curation, new NFT content partnerships, and of course ongoing product development. We'll research applicable business models and go-to-market strategies that align with our overall vision of the NFT marketplace.

    Ecosystem Fitโ€‹

    We aim to build a feature-specific auction pallet that possibly integrates with already being developed NFT infrastructure projects and allows creating and bidding on NFT auctions of different auction types. The point is to provide easy integration to existing NFT implementations that can be re-used across the whole ecosystem. Also, there will be different auction types and some of them have never been implemented in the Polkadot space so it's definitely something that will push the whole ecosystem forward and we might even find some other means of token distribution models that can benefit all the projects (for example adjustments to the Dutch auction).

    Also, we are already in touch with several leading NFT projects within the Polkadot ecosystem and they are very interested in having an auction system on top of their platforms. For instance, we have discussed that with Kodadot and we definitely want to work together in the future.

    NFT integrationโ€‹

    There are multiple different approaches to NFT implementation on the market with no official standard set in stone yet on Polkadot. We want to keep our solution as flexible as possible and have the ability to be integrated with a broad spectrum of NFTs. At this point, the closest resemblance of an NFT standard we could find was the ORML by Acala so we started and will continue building based on this library. On the other hand it should be easy in the future to migrate the solution to a different kind of NFT implementation or a Polkadot standard.

    UPDATE 2021-09-28: The solution has been migrated from ORML to FRAME's Uniques pallet.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Team Websiteโ€‹

    Team's experienceโ€‹

    We participated in the Encode hackathon winning 2nd prize in the Polkadot category. We were also in touch with the Acala team managing the ORML pallets and we discussed a couple of our proposals to enhance the NFT pallet and they have accepted our PR. Our team members are also graduates of Substrate Runtime Developer Academy. Last but not least, we run the biggest Polkadot community in Czechia/Slovakia (Polkadotters) where we gather valuable market feedback.

    Besides blockchain development, each member has 5+ years of experience in Computer Science in different areas such as BI, software development, and enterprise-grade engineering.

    Team Code Repoโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Technologies usedโ€‹

    Milestone 1: Implement Auction Type Generalisationโ€‹

    See Auction Type Generalization for definitions.

    Milestone 2: Implement New Auction Typesโ€‹

    See Candle Auction Type and Top-up Auction Type for definitions.

    Candle Auction Typeโ€‹

    Candle auction is a variant of the English auction where the last part of the auction is randomized in the sense that it can be concluded anytime. This prevents bidders from leaving their bids to the last few minutes or seconds and it's fairer in the internet environment where bots can bid on behalf of the buyers. The configuration of such an auction will be very similar to the English one.

    Candle Auction Type Diagram

    Top-up Auction Typeโ€‹

    This is a very popular auction type used by charities. Each participant will pay a "top-up fee" which is based on the bid he made minus the closest lower bid. This effectively means that each participant will pay the top-up fee except the first and the last bidder. The last bidder wins the auction, obtains the item, and only pays the item's price. We believe that bringing this kind of auction type enables entities to raise funds for good causes so that we can connect socially responsible projects with supporters and philanthropists.

    Top-up Auction Type Diagram

    Community engagementโ€‹

    We are well-positioned within the Polkadot ecosystem to create our own product since we started the Polkadotters community that is currently having over 4,000 members and supporters. Therefore we will have plenty of space to carefully test our product and receive valuable feedback from the community. We will also try to gather support from other Polkadot ecosystem projects since we already have a good reputation within a space and we are confident that we will be able to promote the project properly.

    Our progress will be regularly published on social media to gain enough attention and for the sake of transparency of the whole project.

    Our channels

    Future Plansโ€‹

    We're huge fans of NFT space and we do believe that the Polkadot ecosystem will benefit from having the feature-specific auctino pallet that can be able easily integrated into other NFT solution standards developed on Polkadot. Our end result should be a feature-specific pallet that could be plugged into other blockchain applications and an NFT auction marketplace application with DAO curated exclusive content. But this is only beginning, we believe that huge innovations are going to happen in the NFT space and we want to follow those changes as closely as possible to make our auction system thrive!

    - + \ No newline at end of file diff --git a/applications/subdex.html b/applications/subdex.html index 7caf7ff82d4..a194b942ce5 100644 --- a/applications/subdex.html +++ b/applications/subdex.html @@ -4,13 +4,13 @@ SubDEX | Web3 Foundation Grants - +
    Skip to main content

    SubDEX

    • Proposer: subdarkdex
    • Payment Address: 36RukKN8Qa1QTjsQqCfZ5CzrvAKVg2vro8

    Project Description ๐Ÿ“„โ€‹

    SubDEX is a decentralized cross-chain exchange based on AMM (automated market maker) protocol. This project was initially submitted to Hackusama. The SubDEX team's goal goes beyond what was produced in the hackathon. We aim to continue to build SubDEX and hope it becomes a parachain that connects to Kusama and Polkadot networks, so that other parachain assets can be exchanged on it with privacy in a decentralised way.

    Centralised Exchanges (CEXs) have grown exponentially in last decade, because

    1. demands for fiat to crypto asset exchange
    2. demands for assets exchange between different blockchain assets
    3. different blockchains are isolated from each other like islands in oceans

    Users have to rely on a middle man (CEX) to exchange different blockchain assets.

    DEXs have existed on Ethereum blockchain a few years, but they usually have low liquidity and bad user experience. Vitalik's research inspired Uniswap team and Uniswap's success inspired us. We think it is time for DEXs to disrupt CEXs

    Uniswap's success is exciting, but it is mainly used to only exchange Ethereum assets (ETH and ERC20 tokens). Some solutions such as REN exists for user to exchange BTC with Ethereum assets, but most of other blockchain assets cannot be traded on Ethereum DEXs. Furthermore, as AMM protocol evolves, we have seen that Uniswap V1 evolved to Uniswap V2 and Bancor evolved to Bancor V2, both old and new versions have to co-exist because the old version cannot be seemlessly upgraded to new version on Ethereum.

    Kusama / Polkadot's cross-chain protocol and on-chain upgrade make them the perfect blockchain to build a DEX. We are aware there are other DEXs such as Polkaswap and Acala being built now, however, SubDEX is designed to align with the substrate FRAME framwork and adds to the ecosystem with a set of pallets that are reusable and a interface for good user experience.

    The team met during the hackthon and have established strong inter-team relationships through a common goal - to provide a DEX that is built by, used by and maintained by the community.

    Team ๐Ÿ‘ฅโ€‹

    • Members: Arsen Kondratiev, Belsy Yuen, Fei Yang, Herry He, Stasi Kondaurova
    • LinkedIn Profiles: https://www.linkedin.com/in/arsen-kondratiev-031801172/, https://www.linkedin.com/in/belsy/, https://www.linkedin.com/in/fyang1024/,,https://www.linkedin.com/in/kstasi/
    • Code Repos: https://github.com/subdardex
    • Website: http://subdex.io.s3.eu-west-2.amazonaws.com/index.html
    • Legal Structure: Individuals
    • Team's Experience:
      • Arsen is a software engineer, particularly interested in the blockchain domain. During the last year was mostly focused on substrate runtime development at Joystream and Liqum projects. Earlier, worked on infrastructure backends for DAPPs, based on TRON and EOS blockchain platforms.
      • Belsy is a software engineer who focused on working with the substrate framework in the last year. Prior to that, she has worked as a full stack engineer for other blockchain projects on Ethereum, Hyperledger Burrow / Fabric.
      • Fei has been a full stack software engineer for over 10 years and he got involved in blockchain development in May 2017. He worked in centralised exchanges such as Bitfinex and SDCE and believes DEX is the future.
      • Herry is a 6-year e-commerce entrepreneurial veteran as well as an enthusiast of blockchain. After a lecture by Brian from Acala in 2019, where she was shocked by Substrate technology, she decided to devote herself into the tide of Polkadot.
      • Stasi is is a software engineer, technology-agnostic who prefers working on DApps for developing Blockchains like Tezos or TON. But also has expertise with more sustainable blockchains: Ethereum, Stellar, EOS, UTXO-based blockchains, currently works on Quipuswap (DEX on Tezos), has a hobby to draw mock-ups and write articles

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 8 weeks
    • Full-time equivalent (FTE): 2 FTE
    • Total Costs: 2.5 BTC

    Milestone 1โ€‹

    In this grant application we aim to provide as many features that can be packaged into reusable components as possible, the aim is so that when the development of parachains and XCMP are more mature, the community or the subdex team will be able to use / build on such components to realise the goal of a DEX parachain.

    NumberDeliverableSpecification
    1.UI connectionUpdate UI to support user specified connections to Subdex parachain nodes and connection to browser wallet
    2.UI featureAllow user to set allowed slippage
    3.UI ThemeProvide 2 themes for UI -- light and dark and allow user to choose which one
    4.Dex PalletImplement Uniswap V2 AMM protocol with full test coverage and eliminate overflow/underflow risks in calculation in the chain, publish as a standalone pallet
    5.Dex XCMP PalletHandle relay chain asset creation and test this placeholder XCMP pallet that will be used to create demo for testnets for this milestone
    6.Generic Token Dealer PalletCreate a generic token dealer pallet that can handle generic assets and/or native parachain currency, based on the token dealer pallet example and publish as a standalone pallet
    7.UI InfrastrctureDeploy frontend to IPFS
    8.Network InfrastructureDeploy to secured and high reliability server(s) to host a demo relay chain and parachains testnets.

    Community and Documentationโ€‹

    Our initial focus will be development, but we will setup medium and twitter account to start building community as well. We will provide a tutorial on how to use the Pallets created to connect a DEX parachain to a generic parachain with the Generic Token Dealer pallet.

    Additional Information โž•โ€‹

    We have broken down the SubDEX product roadmap into small manageable steps and would like to get feedback from the community and the foundation every step of the way, and we intend to apply for other grants after this milestone, which will put all that is built in this milestone to the test with the connection to the Roccoco testnet.

    The overview of the features SubDEX intend to have are the follow:-

    • Implements an AMM protocol
    • Liquidity provider fee - which will be set to 0.3% initially but will be set by the Liquidity providers and traders through the democracy module when the network has enough users.
    • Node runner fee - will be set to 0.1% initially but will be set by the node runners through the democracy module when the network has enough community nodes
    • Support exchange of KSM & DOT and other parachain assets
    • Support other blockchain assets such as ETH, XTZ, BTC when the bridges are ready
    • Customizable user interface (user can select any DEX node to connect to, user can adjust allowed slippage, user can select favorite theme etc).
    • Optional privacy for users
    - + \ No newline at end of file diff --git a/applications/subquery.html b/applications/subquery.html index 1b884025cd8..23ee05588f2 100644 --- a/applications/subquery.html +++ b/applications/subquery.html @@ -4,7 +4,7 @@ SubQuery | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    SubQuery

    This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

    The above combination of your GitHub account and payment address will be your unique identifier during the program. Please keep them safe.

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Almost every substrate project has a need to process and query data. SubQuery is a open-source tool to provide a complete solution to this problem and will become core infrastructure for the Polkadot ecosystem. We expect it to solve how to Extract, Transform, Persist, and Query data intially, and then how to Connect and Present data in the future.

    SubQuery is NOT an ETL tool, the persisted data is minimized and shaped from the perspective of how it will be used.

    SubQuery aims to support all substrate-compatible networks.

    Project Detailsโ€‹

    In this proposal, we provide a complete workflow to create a live data query system.

    Step #1: Create a SubQuery projectโ€‹

    1. use @subql/cli tool we provide to create a SubQuery project
      • it is written in typescript
      • user needs to config the project, define a schema and implement mapping functions
    2. use @subql/cli to generate types from the given schema
    3. use @subql/cli to compile and pack the SubQuery project

    Step #2: Run an indexerโ€‹

    Prerequisites

    • A Postgres database
    • Non-archive full node. If storage query is used, then an archive node is required to extract chain data. OnFinality provides an archive node with a generous free tier that should be more than able to cover most cases.
    • A moderately powerful computer to run an indexer in the background

    Then start our @subql/node with the path of local SubQuery project as arguments, @subql/node will handle the rest.

    Step #3: Run a Query Serviceโ€‹

    We do have plan for a custom built graphql query service @subql/query, but in this stage we will use Harura to do the job.

    Componentsโ€‹

    Npmjs Packages to published:

    • @subql/cli
    • @subql/node

    Ecosystem Fitโ€‹

    The original intentions are different and that leads to different technical decisions.

    • These two projects are both created by a substrate-based blockchain team in order to fulfill the needs of their own chains in the beginning and then adapted into standalone projects.
    • The motivation of us is to make a tool that solves query demands of all substrate blockchains right from the start. We also plan to then provide a full managed and hosted service to lower the barriers of entry further.

    The differences:

    1. Secure execution of mapping functions are not a top concern for them, but is a hard requirement for us and will be supported in the proposal.
    2. We don't want to depend on 3rd party libraries in the core code of the project, libraries such as warthog used by Hydra.
    3. API access within the mapping functions will be supported
    4. Our proposal aims for OLTP, and allowing customisation of indexing process which are different from ETL like projects. The outcome of indexed data is that it is shaped for the need of its specific usecase, and be consumed by browser and mobile apps.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Sam Zou: Project manager
    • Ian He: Team leader
    • Jay Ji: Fullstack developer

    Partime membersโ€‹

    • James Bayly: Marketing and Partnerships

    Team Websiteโ€‹

    OnFinality Limited, New Zealand

    Team's experienceโ€‹

    We are the team behind OnFinality which is an infrastructure SaaS platform for blockchain teams and users to launch nodes and gain access to a large range of blockchain protocols. Our mission is to help Polkadot/Substrate developers build the next generation of dApps.

    We have supported many Polkadot ecosystem projects already including Acala, Darwinia, Plasm, and Edgeware.

    Ian He led a team and won 2nd price in the substrate hackathon in Hangzhou 2019.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1.5 month
    • Full-time equivalent (FTE): 2
    • Total Costs: 1.75

    Milestone 1โ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 1.2 BTC
    NumberDeliverableSpecification
    1.@subql/cliWe will create @subql/cli that helps to generate types, builds, and packs the SubQuery project. To be specific, mapping functions will be compiled from .ts to .js and will be packed into a single tarball file together with project manifest and GraphQL schema
    2.@subql/nodeWe will create @subql/node that can load a SubQuery project and index the specified blockchain.
    2.1@subql/nodewill support block handler async function handlerFn(block: SignedBlock): Promise<void>, call handler async function handlerFn(extrinsic: Extrinsic): Promise<void> and event handler async function handlerFn(event: EventData): Promise<void> from the SubQuery project that user provided.
    2.2@subql/nodeThe call handler will support module and call_name filter. The event handler will support event_name filter
    2.3@subql/nodeWe will use vm2 to create an isolated scope to execute mapping functions, and we will provide additional NetworkPolicy configs to strengthen the security further when run it in K8s.
    3.DeployWe will generate a dockercompose file and Kubernetes deploy YAMLs
    4.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can create, run and serve their SubQuery project.
    5.TestingUnit tests and integration tests for @subql/cli and @subql/node

    Milestone 2โ€‹

    • Estimated Duration: 2 weeks
    • FTE: 2
    • Costs: 0.55 BTC
    NumberDeliverableSpecification
    1.@subql/cliA subcommand will be added to @subql/cli that can create a scaffold of a SubQuery project, including a series of step-by-setp interactions that guides the user to complete customisation of the project.yaml and create handlers of selected type. The generated SubQuery project will have sufficient code comments and instructions in README.md so people can easily understand and start working with it.
    2.@subql/node@polkadot/api will be accessible within the mapping functions and we will patch the API instance that be injected in the scope to lock storage queries to current processing block so that the indexing result will be deterministic.
    3.DeployWe will provide a dockercompose file and Kubernetes deploy YAML
    4.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can create, run and serve their SubQuery project.
    5.ExamplesWe will list and provide new users access to example SubQuery projects
    6.TestingUnit tests and integration tests for @subql/cli and @subql/node

    Community engagementโ€‹

    We will publish a series of articles on Medium and videos demonstrating the usage of this tool too. We will engage with users in our community on Telegram.

    Future Plansโ€‹

    • With the help of this tool, anyone can create and run queries easily. But there're still issues for when a user wants to consume the query service in production, our intention to close this gap by providing a hosted service.
    • In regard to functionality, we also plan to support SubQuery composition and data subscription for users that use our hosted service.
    • Smart contracts including Solidity and ink! support are in our future roadmap.
    • We are intending to reach out to all major chain explorer teams and engage with the community to see how our service can benefit it.

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/subrelay.html b/applications/subrelay.html index e18a07b3e4c..b54f6db73ce 100644 --- a/applications/subrelay.html +++ b/applications/subrelay.html @@ -4,14 +4,14 @@ SubRelay | Web3 Foundation Grants - +
    Skip to main content

    SubRelay

    • Team Name: SubRelay
    • Payment Address: 0x1aE740dC9F0F2f7404feA35bEb0D59105B9121Cf (USDT - Ethereum Network)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    SubRelay is a no-code solution to build automation workflows on any Substrate-based chain. The application helps users to create their off-chain automated workflows by subscribing to on-chain events through the interface. We aimed to make the app easy for average users but remain a powerful tool for advanced users. With this in mind, we designed Subrelay to be generic and flexible with any use cases. Additionally, the SubRelay can integrate with any runtime of any blockchain building on the Substrate, such as Polkadot, Kusama, and Statemine.

    The app was motivated by our desire to monitor the on-chain events and send webhook requests to our internal system. We wanted to build a solution that not only can solve our problems but also benefit the entire ecosystem of Substrate/Polkadot. Our vision is to make SubRelay the most popular event relay service for any chain in the Polkadot ecosystem.

    Project Detailsโ€‹

    Wireframeโ€‹

    Welcome screen & authenticationโ€‹
    imageimage
    Workflow listโ€‹
    image
    Create a new workflowโ€‹
    1. Triggerโ€‹
    imageimageimageimageimageimage
    2. Actionโ€‹
    imageimageimageimage
    Executions historyโ€‹
    image

    Database schemaโ€‹


    Table user {
      id varchar [pk]
      address varchar
    }

    Table chain {
      uuid varchar [pk]
      chain_id varchar // chain_id in block
      created_at datetime
      version varchar
      name varchar
      img_url varchar
      config jsonb
      latest boolean
    }

    Table event {
      id varchar [pk]
      chain_uuid varchar
      name varchar
      description varchar
      fields jsonb
      sample jsonb
    }

    Table workflow {
      id varchar [pk]
      user_id varchar
      created_at datetime
      updated_at datetime
      status varchar
    }

    Table workflow_log {
      id varchar [pk]
      started_at datetime
      finished_at datetime
      workflow_version_id varchar
      input jsonb
      status varchar
    }

    Table workflow_version {
      id varchar [pk]
      workflow_id varchar
      name varchar
      chain_uuid varchar
      created_at datetime
      version varchar
    }

    Table task_log {
      task_id varchar pk
      workflow_log_id varchar pk
      started_at_at varchar
      finished_at datetime
      status boolean
      output jsonb
      input jsonb
     }
     
    Table task {
      id varchar [pk]
      name varchar
      workflow_version_id varchar
      type varchar
      config jsonb
      depend_on varchar
     }

    Ref: chain.uuid > event.chain_uuid
    Ref: task.id > task_log.task_id
    Ref: user.id > workflow.user_id
    Ref: chain.uuid > workflow_version.chain_uuid
    Ref: workflow_version.id > task.workflow_version_id
    Ref: task.id > task.depend_on
    Ref: workflow_version.workflow_id > workflow.id
    Ref: workflow_log.workflow_version_id > workflow_version.id
    Ref: workflow_log.id > task_log.workflow_log_id

    API specsโ€‹

    *GET /chains*โ€‹
    • Response
        [
          {
            "uuid": "849e9dec-5ab8-11ed-9b6a-0242ac120002",
            "name": "Polkadot",
            "img_url": "string",
            "version": "v1.2.0",
          }
        ]
    *GET /chains/{chain_uuid}/events*โ€‹
    • Response
        [
          {
            "id": "849e9dec-5ab8-11ed-9b6a-0242ac120002",
            "name": "balances.deposit",
            "description": "string",
          },
          {
            "id": "849e9dec-5ab8-11ed-9b6a-0242ac120002",
            "name": "balances.transfers",
            "description": "string",
          },
          {
            "id": "849e9dec-5ab8-11ed-9b6a-0242ac120002",
            "name": "ntf.minted",
            "description": "string",
          }
        ]
    *GET /chains/{chain_uuid}/events/{event_id}*โ€‹
    • Response
        {
          "id": 123,
          "name": "balances.deposit",
          "description": "string",
          "fields": [
            {
              "name": "data.who",
              "type": "string",
              "description": "who sent"
            },
            {
              "name": "data.amount",
              "type": "number",
              "description": ""
            },
            {
              "name": "status",
              "type": "string",
              "description": "status of this event"
            },
            {
              "name": "extrinsic.name",
              "type": "string",
              "description": "this event belong to this extrinsic"
            }
          ],
          "sample": {
            "id": 123,
            "name": "balances.deposit",
            "description": "",
            "data": {
              "who": "",
              "amount": 123
            },
            "status": "success",
            "extrinsic": {
              "name": "balances.deposit"
            },
            "block": {
              "hash": "",
              "number": 123,
              "timestamp": ""
            }
          }
        }
    *GET /workflows*โ€‹
    • Query params
    Query ParamDescriptionExample
    limitThe number of workflows per page10
    offsetpage0
    searchSearch workflow by name"foo"
    chain_uuidFilter workflows by chain UUID2
    statusFilter workflows by status."running"
    • Response
    {
      "workflows": [
        {
          "id": 10,
          "name": "name 1",
          "chain": {
            "uuid": "uasdasdsd",
            "name": "Acala"
          },
          "created_at": "2022-11-02T03:12:39.018Z",
          "updated_at": "2022-11-02T03:12:39.018Z",
          "status": "running"
        }
      ],
      "limit": 10,
      "offset": 0,
      "total": 1
    }

    *POST /workflows*โ€‹
    • Request body
    {
      "name": "workflow 1",
      "tasks": [
        {
          "name": "trigger 1",
          "type": "trigger",
          "config": {
            "event": "balances.deposit",
            "chain_uuid": 1,
            "conditions": [
              [
                {
                  "variable": "data.amount",
                  "operator": "greaterThan",
                  "value": 1
                }
              ],
              [
                {
                  "variable": "data.amount",
                  "operator": "lessThan",
                  "value": 10
                }
              ]
            ]
          },
          "depend_on_name": null
        },
        {
          "name": "notify webhook",
          "type": "notification",
          "config": {
            "channel": "webhook",
            "config": {
              "headers": {
                "API_KEY": "encrypted"
              }
              "url": "https://webhook.com"
            },
            "depend_on_name": "trigger 1"
          }
        }
      ]
    }
    • Response
    {
      "id": 22,
      "created_at": "2022-11-02T03:12:39.018Z",
      "updated_at": "2022-11-02T03:12:39.018Z",
      "status": "running",
      "name": "workflow 1",
      "chain": {
        "uuid": "asdasdasd",
        "name": "Acala"
      },
      "tasks": [
        {
          "id": 1,
          "name": "trigger 1",
          "type": "trigger",
          "config": {
            "event": "balances.deposit",
            "chain_uuid": "asdasdasd",
            "conditions": [
              [
                {
                  "variable": "data.amount",
                  "operator": "greaterThan",
                  "value": 1
                }
              ],
              [
                {
                  "variable": "data.amount",
                  "operator": "lessThan",
                  "value": 10
                }
              ]
            ]
          },
          "depend_on": null
        },
        {
          "name": "notify webhook",
          "type": "notification",
          "config": {
            "channel": "webhook",
            "config": {
              "headers": {
                "API_KEY": "encrypted"
              },
              "url": "https://webhook.com"
            },
            "depend_on": 1
          }
        }
      ]
    }
    *DELETE /workflows/{workflow_id}*โ€‹
    *GET /workflow/logs*โ€‹
    • Query params
    Query ParamDescriptionExample
    limitThe number of logs per page10
    offsetpage0
    searchSearch logs by workflow name"foo"
    chain_uuidFilter logs by workflow's chain uuid2
    statusFilter logs by status."running"
    • Response
    {
      "logs": [
        {
          "id": 10,
          "workflow": {
              "id": 10,
              "name": "name 1",
              "chain": {
                "id": 1,
                "name": "Acala"
              },
          },
          "started_at": "2022-11-02T03:12:39.018Z",
          "finished_at": "2022-11-02T03:12:39.018Z",
          "status": "success"
        },
        {
          "id": 11,
          "workflow": {
              "id": 10,
              "name": "name 1",
              "chain": {
                "id": 1,
                "name": "Acala"
              },
          },
          "started_at": "2022-11-02T03:12:39.018Z",
          "finished_at": "2022-11-02T03:12:39.018Z",
          "status": "failed"
        }
      ],
      "limit": 10,
      "offset": 0,
      "total": 2
    }

    Techstackโ€‹

    Ecosystem Fitโ€‹

    As mentioned above, SubRelay can integrate with any Substrate-based chain, bringing a massive benefit to the Substrate/Polkadot ecosystem.

    There is a wide range of our target users, but we think there are a few main groups of the user:

    • Normal blockchain user: The interface of SubRelay is designed to support normal users who want to do a simple task such as watching the change in their balance by setting a notification.

    • Crypto experts: Although SubRelay's interface is easy to use to support normal users who need a simple workflow, it also is a powerful tool for experts. There is no limitation on what can build with SubRelay. For example, a defi farmer can monitor their liquidity pools, borrowing, and lending positions, or an NFT trader can watch their favorite collections' prices.

    • Developers/ Team: From the developer's perspective, there is no easy way to integrate an existing system with a blockchain. Our solution will help the teams save time and resources to focus on solving their business requirements instead of wasting their time building a service to integrate with the chain.

    Web3Go MoonPush looks similar to our project, but SubRelay is more generic and flexible. There are a few key differences:

    • SubRelay can integrate with any Substrate-based chain.
    • SubRelay supports subscribing to any runtime events.
    • SubRelay provides a highly customizable event filter and action configuration.
    • SubRelay has log systems that allow users to manage workflow performanceย by recording all success and failure pipelines.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Chi Tran - Team Leader
    • Anh Thi Chieu
    • Bu Le

    Contactโ€‹

    We are very early and have not set up a legal identity. If necessary, we will set it up as soon as possible. Otherwise, we want to spend our resources on product development.

    Team's experienceโ€‹

    Our team has five-year experience in software development for SaaS startups, and provide custom enterprise solutions for top brands. We also have been spending more than a year in blockchain research and development so far. With these experiences, we know the best way to build a great product that connects web2 to web3.

    Team Code Reposโ€‹

    Organization repos

    Team members

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 5 months
    • Full-Time Equivalent (FTE): 1.5
    • Total Costs: 30,000 USD

    Milestone 1: Core functionsโ€‹

    • Estimated duration: 2.5 months
    • FTE: 1,5
    • Costs: 15000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a basic tutorial that explains the concept of SubRelay, how to create a workflow, and other features
    0d.DockerWe will provide a Dockerfile(s) for the self-hosted version
    1.Feature: Authentication by PolkadotJs walletThe dashboard and api will allow user to authentication by PolkadotJs wallet
    2.Feature: Create a new workflowCreate a new workflow page which the same as the wireframe above. But Email, Telegram and Discord integrations will not in scope of this milestone.
    3.Feature: List of workflowsA page display workflows of user same as the wireframe above.
    4.Feature: Executions of workflowsA page display workflows execution history of user same as the wireframe above.
    5.APIWe will release an api version which include create workflow, list workflow and list workflow executions.
    6.IntegrationWe will integrate the interface features (listed in 1, 2, 3, 4) with the api.

    Milestone 2: Extensions development and testingโ€‹

    • Estimated duration: 2,5 months
    • FTE: 1,5
    • Costs: 15000 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide the tutorial for the new features added in milestone 2
    0c.Testing and Testing GuideThe interface and API will be covered by unit tests and e2e tests. We will provide documentation on how to run the tests and setup CI to run the tests
    0d.DockerWe will release a new Docker file which includes new features added in milestone 2
    0e.ArticleWe will publish an article that explains the concepts and features of SubRelay, and the grant
    1.Feature: Email integrationIntegrate with Email to send the notification about on-chain event.
    2.Feature: Telegram integrationIntegrate with Telegram to send the notification about on-chain event.
    3.Feature: Discord integrationIntegrate with Discord to send the notification about on-chain event.
    4.Feature: Workflow execution detailA page display workflow execution in detail.
    5.APIWe will release an api version which include email, telegram, discord integration and workflow exection detail
    6.IntegrationWe will integrate the interface features (listed in 1, 2, 3, 4) with the api.

    Future Plansโ€‹

    In the short-term plan, we will launch a community cloud version to get the tractions and feedback from the users to improve the product. We will add more features such as parallel workflow, workflow templates, and user onboarding processes for the long-term plan.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/subscript_lang.html b/applications/subscript_lang.html index 77d17b1f440..2aac939d800 100644 --- a/applications/subscript_lang.html +++ b/applications/subscript_lang.html @@ -4,13 +4,13 @@ Subscript | Web3 Foundation Grants - +
    Skip to main content

    Subscript

    Subscript: Substrate smart contact written in AssemblyScript

    • Proposer: synote
    • Payment Address: bc1qzv5ljrt0sngjjnn25s4jzsu7qtts5d74cq8tz5

    Project Overview ๐Ÿ“„โ€‹

    We are intergrating AssemblyScript into substrate smart contract which is similar to parity's ink. It involve buillding substrate contract runtime api, builtin modules, and development sdk. we name the language and sdk as Subscript.

    Overviewโ€‹

    Subscript is a smart contract language written in AssemblyScript for substrate based chain. We will provide essential substrate api and builtin tools to support contract development.

    Similar to parity ink, Subscript is built on top of AssemblyScript and follow all AssemblyScript syntax. Subscript is more like a development kit with some builtin module and tools. As assemblyscript is easy to interact with TypeScript and JavaScript, Subscript is much more friendly for dapp developers.

    Project Detailsโ€‹

    Subscript is designed as standard AssemblyScript with builtin contract api. First of all, Subscript libray will provide basic contract pallet runtime api access.

    • contract runtime envionment
    • contract memory management
    • state storage access, set and get value by key.
    • event data generation and storage

    The Subscript library also add support for contract interaction utilties, including:

    • contract metadata generator
    • basic data structure: dynimic array, map, list,
    • user struct storage layout
    • account and balance interface
    • contract call abstraction
    • builtin utility fuctions

    The package will provide contract template and intergation tool with substrate node.

    There is no plan for EVM Pallet support.

    Ecosystem Fitโ€‹

    Some of the function of Subscript are similar to LimeChain's work of AssemblyScript Runtime, but they are made for different scenario. LimeChain AssemblyScript Runtime focus on building substrate runtime with wasm compiled from AssemblyScript. It involves building all the substrate runtime environment entry with AssemblyScript and other basic library. Subscript aims to implement all the substrate smart contract low level interface with AssemblyScript. Subscript also add support for basic contract lib and project template for easy development. We may benefit previous work from LimeChain such as SCALEcodec, runtime entry implemention.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Symon Ho: Fullstack developer Leading consensus R&D and engineering in multichain system. Prior to that, developer of openstack project, engaged in performance tools and monitoring system for cloud platform.
    • Ice Min: 10+ years experience in c/c++ development, real time database products and digital currency transaction platform products expert. Developer of BitCoin and Ethereum wallet.

    Team Websiteโ€‹

    Team's experienceโ€‹

    We implemented the fruitchain consensus integrated with ethereum, and used pbft to provide finalization in blockchain system. Fruitchain mainnet launched in 2019 and privide 500+ TPS for transaction validation.

    We alse engaged in smart contract tools interaged with vyper for contract audit and testing.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    We only provide milestone1 here for contract runtime api implementation. Full milestones are list in the general grant repo

    Overviewโ€‹

    • Total Estimated Duration: 2 month
    • Full-time equivalent (FTE): 2
    • Total Costs: 2 btc

    Milestone 1 โ€” Implement smart contract low level apiโ€‹

    • Estimated Duration: 2 month
    • FTE: 2
    • Costs: 2 btc

    In this milestone, all the basic substrate contract runtime api will be implemented in AssemblyScript. This stage will deliver a AssemblyScript package which provide encapsulation of current substrate contract api. With the AS api, contracts can be compiled to wasm and deployed on substrate contract node. We may benefit from the reference implemention of parity Ink and provide similar api.

    The AS package will cover the following substrate contract api:

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.TestingThis milestone will have unit-test for all the following runtime api impemented. We will mock most of the contract runtime api to simulate host functions. Integration test will be delivered in next milestone.
    0c.DocumentationWe will provide both inline documentation of all the sdk api and basic code example that show how developers use the api.
    1.contract runtime environmentcontract builder and execution to initailize the contract code
    2.core typesadd core component: AccountId, Balance, Hash, Block
    2.storage accesscontract low level storage read and write with key
    3.object packing utiltyProvide user-defined data structure packing and unpacking method to storage access.
    4.memory manipulationImplement memory make and getter, setter
    5.contract event generationGenerate event from contract call
    6.contract call methodProvide method for make contract call.
    7.hash utilityMake digest of encoded input to generate hash image
    8.SCALE codecBuiltin codec functions to serialize and deserialize input. We may directly use LimeChain as-scale-codec implementation.
    9.example for demonstrationProvide ERC20 contract example to test on substrate node

    Future Plansโ€‹

    After the Subscript presentation , we may make our effort to bring more tool for contract development.

    A simulated contract sandbox similar to ganache is needed to debug and test contract.

    We may add more intergated tool and IDE packge for contract developer.

    Additional Informationโ€‹

    We expect any developer who is interested in AssemblyScript smart contract join us and build efficient framework.

    - + \ No newline at end of file diff --git a/applications/substats.html b/applications/substats.html index 09de810ab99..38348dd939b 100644 --- a/applications/substats.html +++ b/applications/substats.html @@ -4,13 +4,13 @@ Substats (The framework of lightweight block explorer) | Web3 Foundation Grants - +
    Skip to main content

    Substats (The framework of lightweight block explorer)

    • Team Name: CESS LAB
    • Payment Address: 0x96a661ee0D829DF7c424D4415a51FFc256EEEd8A(USDC)
    • Level: 2

    Project Overviewโ€‹

    Overviewโ€‹

    Backgroundโ€‹

    The block explorer is the important portal for on-chain data visualization. It can record and count information such as each block, each transaction and address of different blockchain networks. The essence of the block explorer is to reasonably display native data and derived data to various users according to the actual situation of the blockchain network. The users of block explorer include at least: developers, users, token holders, miners, regulators, researchers, and people interested in blockchain.

    With the goal of building a multi-chain ecosystem, Polkadot has gradually become the preferred solution for many blockchain projects. As more and more blockchain networks join the ecosystem, users have higher and higher requirements for block explorer.

    The most influential block explorer in the Polkadot ecosystem is Polkadot native explorer. it provides a large and comprehensive blockchain explorer, any blockchain network built on The Substrate can apply for access, and supports one-click Toggle, which is currently the primary option for many ecological project. Its characteristics can be summarized as follows:

    1. Rich real-time data display. Provides the display of a large amount of data on blockchain such as blocks, validators, and community governance.

    2. Support wallet management. Contains most functions of the wallet, and supports wallet management functions such as account generation, import, and token transfer.

    3. Developer friendly. It contains a wealth of developer tools, and supports practical functions such as chain state query, transaction initiation, and RPC call.

    4. One-click import. All blockchains developed based on the Substrate framework basically implement the same set of basic interfaces, and the Polkadot.js App only needs to provide a websockets link to implement the import.

    But everything has two sides. The following inconveniences also exist behind such a powerful block explorer platform:

    1. Front-end resources are bloated and network latency is high.

    2. Since the web side of platform directly obtains and renders data through blockchain nodes, it leads to slower data reading speed.

    3. Likewise, on-chain resources are relatively precious, resulting in more meaningful statistics that need to be processed that cannot be kept on-chain. However, these statistics have a direct impact on user experience.

    Based on the above characteristics, Polkadot.js App is more suitable for the needs of developers and wallet-related operation scenarios. For more common query scenarios such as retrieving transactions, querying balances of wallet address, checking the basic status of the network, and querying miner information, the actual needs of users are "fast" rather than "more". Just like if you just want to buy a bottle of beer, then the convenience store in the community may be more suitable for your needs than the supermarket that is farther away.

    Polkadot.js App is like a large supermarket with a wide variety of products. However, for the simple daily needs of users, convenience stores (lightweight block explorer) will be a good complement to it. So is there a lightweight block explorer that is easy enough to use in the current Polkadot ecosystem? The following is the situation of our research.

    Current Solutionโ€‹

    Subscan is a block explorer that provides operations management services. It supports about 20 Substrate-based parallel chains and offers basic functions. At the same time, it also provides paid customization services for users who have higher API requirements. This model is more convenient for developers, however, the customization service fee can be as high as tens of thousands of USDT, and developers may abandon some functions due to financial concerns.

    Polkascan is an open-source block explorer that is relatively lightweight and simple in data display. However, through code analysis on its Github, it has limited capability in data processing since it doesn't have a database and cannot perform data analysis.

    In summary, we believe that there is a lack of a better open source lightweight explorer in the current Polkadot ecosystem. That's why we designed Substats - a lightweight block explorer framework. Different from Polkadot.js App, Substats provides lightweight components to reduce the dependence on the network and provides customized data display functions. And by building a stable background and database services to obtain more powerful data processing capabilities.

    Featuresโ€‹

    โ— On-chain data processing station: A processing station is built between users and the blockchain network, which includes a cache (database) layer and a computing (data processing) layer. The cache layer is responsible for pulling the data on the chain to the local database for storage. The computing layer is responsible for processing the on-chain data in the database, so that it can be combined into more meaningful data for users, such as historical data statistics, network-wide computing power rankings, etc.

    โ— Convenient data display and retrieval: Compared with reading blockchain network data through RPC nodes, it is more convenient and faster for the client's wxplorer to read directly in the database of the processing station built by Substats.

    โ— One-click construction: Learn from the features of Polkadot.js App. The Substats framework only needs to configure a small amount of information to achieve one-click deployment and startup. Significantly reduce development costs.

    โ— Modular UI components: The UI components of Substats are all decoupled, allowing developers to customize the development of UI components with low threshold.

    โ— Open source and security: Substats only provides completely open source code, and is not responsible for replacing management and operation services. All services are deployed and operated by the project party, avoiding trust costs.

    Project Detailsโ€‹

    We have designed a set of explorer modular components for the Substrate ecosystem, which can be used by stakeholders (such as miners and storage users) and other users.Polkadot, Kusama and Rococo will be supported in first version. Users can inquire about basic information in the network, such as space information, rankings, blocks, transactions, addresses, visual trend charts, etc. Substats is open-source and has flexible scalability in both network and its functionalities. Hence early-stage projects or individual developers can easily integrate our components based on their business needs. The data analysis module and custom components are the two core functions of Substats.

    High level designโ€‹

    Proposal architecture

    Figure 1: Proposal architecture

    โ— Data Processing: Data processing can be divided into the following steps: data acquisition, data parsing, and persistent storage. As a block explorer framework, Substats optimizes each process to reduce unnecessary workload and improve efficiency for developers. For example, it supports custom data acquisition; realizes the separation of data read and write through the buffer queue; supports various types of data acquisition methods: RPC communication of full nodes, P2P protocol of peer nodes, etc.

    โ— Data Rendering: In addition to providing developers with APIs for crawling block data and derived data, Substats also provides developers with a front-end framework which displays data such as block info, transaction info, and address info in a modular way, and each module can be customized. And Substats has a wealth of themes and icons to choose from.

    Typical exampleโ€‹

    Workflow

    Figure 2: Workflow

    1. The node service synchronizes the block data of the blockchain network. The node services here include full nodes of the network, third-party data retrieval services, etc.
    2. The data crawling module obtains block data from blockchain nodes. Substats supports full node, P2P node, local database and other types of node service connection, and supports custom data read interfaces.
    3. It writes the block data crawled from the node service to the buffer queue. The buffer queue is used to separate the process of crawling data and parsing data, and supports data integrity checking and exception handling.
    4. The block data is taken out of the buffer queue and sent to the parser in order.
    5. The parser parses the block data and writes it to the database in time. The parsing process is accelerated by concurrent execution.
    6. For general block data, Substats provides a series of database table structure that enables developers to use it out of the box. For custom Pallet data, developers need to define the relevant table structure.
    7. The front-end component periodically reads the relevant data in the database through the HTTP API to render the web page.

    Mockups/designs of any UI componentsโ€‹

    • Network Overview

    Overview

    • Address Analysis

    addressDetails

    • Transaction Details

    transaction

    • Block Details Details

    blocks

    API specifications of the core functionalityโ€‹

    • Substats: List of the publicly exposed methods
    No. 1
    Method NameGeneral
    Method TypeData request
    ReturnsDictionaryList
    DescriptionGet all dictionary list
    No. 2
    Method NameBlock query
    Method TypeData request
    ReturnsBlockStates
    DescriptionQuery states info from block
    No. 3
    Method NameTransaction query
    Method TypeData request
    ReturnsTransactionResults
    DescriptionQuery states info from transactoin
    No. 4
    Method NameEvent query
    Method TypeData request
    ReturnsEventResults
    DescriptionQuery states info from events
    No. 5
    Method NameConsensus query
    Method TypeData request
    ReturnsConsensusResults
    DescriptionQuery states info from miner

    Ecosystem Fitโ€‹

    Help us locate your project in the Polkadot/Substrate/Kusama landscape and what problems it tries to solve by answering each of these questions:

    • Where and how does your project fit into the ecosystem?

    Our project provides the Polkadot/Substrate ecosystem a quick and convenient service that is in an open-source and lightweight way for creating their block explorers.

    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

    Parachain/dapp/wallet/developers

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Teh Sunn Liu
    • Shaka Lavigne
    • Elden Young
    • Yeou Sunn Liu
    • Ted Zhang

    Contactโ€‹

    • Registered Address: 22 St Leonard's Ave, Lostock, Bolton BL6 4JE, England
    • Registered Legal Entity: Paul David Humphreys

    Team's experienceโ€‹

    โ— In 2019, the CESS team was established and began to design the prototype design of the storage system network's underlying construction.

    โ— In 2020, CESS completed the design of the Random Rotational Selection consensus mechanism (RยฒS), Multi-format Data Rights Mechanism (MDRC) and Proof of Data Reduplication and Recovery (PoDRยฒ).

    โ— In 2021, released CESS v0.1 white paper. Released CESS Demo v0.2, started BSC testnet storage mining. The end of the same year, CESS was awarded 1st place in the Polkadot Hackathon APAC Edition.

    โ— In February 2022, CESS joined the Substrate Builders Program. In July CESS passed all milestones in W3F to receive a grant for developing a storage pallet for Substrate. CESS launched its testnet the same month.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 5 months
    • Full-Time Equivalent (FTE): 2
    • Total Costs: 24,000 USD

    Milestone 1 Implement The Backend Infrastructureโ€‹

    • Estimated duration: 2 months
    • FTE: 2
    • Costs: 9,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to use the product, display and explain the function of each component.
    0c.Testing GuideUnit testing will be applied to ensure reliability. Documentation of tests and results will be provided.
    1a.Develop the webserviceWe will use the express.js framework to build the basic back-end services, and install the database link toolkit to achieve stable network communication, database connection and other functions to prepare for upper-layer applications.
    1b.Develop the polkadot.jsWe will use the polkadot.js API to interact with the PRC nodes of the blockchain network developed based on Substrate. And implement interfaces including block query, transaction query, Account query, Miner query, and new block subscription.
    1c.Develop the APIWe will define the back-end API specification for the front-end service to call, including the data structure, request parameters, request event processing function, return data format, etc. At the same time, we will implement the construction of the interface layer to meet the custom development needs of developers.
    1d.Create the databaseWe will build MySQL database service, create Table structure, complete index creation, data structure constraints, and implement MYSQL connection driver through Node.js.

    Milestone 2 Implement Data Processing Toolsโ€‹

    • Estimated Duration: 2 months
    • FTE: 2
    • Costs: 9,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to use the product, display and explain the function of each component.
    0c.Testing GuideUnit testing will be applied to ensure reliability. Documentation of tests and results will be provided.
    1a.Data Reading ModuleIt contains on-chain data of blocks, addresses, transactions, events, miners. It supports network switching of Polkadot, Kusama and Rococo, for instance.
    1b.Data Processing ModuleIt includes synchronization for block information, miner information, account lists, on-chain power timing recording, transaction data statistics and sorting.
    1c.The API ModuleWe will develop functional interfaces to return the results of data processing to front-end services in the form of a unified interface. The interface includes block information acquisition, historical statistical data acquisition, and the entire network computing power ranking.
    2a.API DocumentationWe will complete a backend API documentation explaining how the API interacts with the data.
    2b.Operation ManualWe will write an operation manual explaining how data reading, how network switching and processing can be used.

    Milestone 3 Complete The Front-End Componentsโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 6,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to use the product, display and explain the function of each component.
    0c.Testing GuideUnit testing will be applied to ensure reliability. Documentation of tests and results will be provided.
    0d.ArticleWe will publish an article explaining the problems that Substats solves and how it can benefit other projects.
    1a.Front-end FrameworkWe will provide lightweight React.js front-end components with styles based on LESS CSS extensions. These components can be customized and extended by developers.
    1b.APIWe will define specifications for the API requests.
    1c.Develop InterfaceWe will complete the development of the front-end webpage and make it web and mobile compatible.
    2.UI DesignWe will provide a basic version of the user interface, based on the ant-design/charts icon component library. The other projects can customize the page style based on their needs.
    3.Operation ManualWe will complete the operation manual, including sections on front-end component usage and data requests.

    Future Plansโ€‹

    In the coming months, we will be promoting our project in Europe, South America and SouthEast Asia. We will build a bigger developer community and start testing. We will continue to maintain the component format to adapt to any updates in Substrate, meanwhile optimizing the product and providing the explorer components with more functions.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We have heard from Parity Asia.

    What work has been done already? We have already implemented a design prototype.

    Have you ever applied for other grants? We had applied for two.

    1. grant 1 , which had passed all the milestone deliveries on January, 2022.
    2. grant 2 , which had passed all the milestone deliveries on July, 2022.
    - + \ No newline at end of file diff --git a/applications/substrate-identity-directory.html b/applications/substrate-identity-directory.html index 7f84d529f9f..24fe5ac8ea4 100644 --- a/applications/substrate-identity-directory.html +++ b/applications/substrate-identity-directory.html @@ -4,7 +4,7 @@ Substrate Identity Hub | Web3 Foundation Grants - + @@ -18,7 +18,7 @@ List view


    ![Single page view](https://i.imgur.com/7u04sRV.png)

    Milestone 2 Implementing logic for sending tokens. Support for the offline mode.โ€‹

    NumberDeliverableSpecification
    1.Implement logic for sending tokensImplement logic for sending tokens; retrieve balance, parse inputs, display transaction fee, create the transfer transaction.
    2.Make the web service work offlineWeb service can be used in offline mode; the user can specify a local node to which will the service connect.

    Milestone 3 Index data and queryโ€‹

    Requirements for the milestone:โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how the user can utilize the basic application.
    0c.Article/TutorialWe will write an article or tutorial that explains the work done as part of the grant.
    1.Backend developmentProvide endpoints for data queries related to governance and treasury activities
    2.Fetch data on frontendConsume provided endpoints and display data on frontend

    Mockup:
    Identity activities

    Future Plansโ€‹

    After finishing milestones 1 and 2 users can utilize the basic application which supports querying by address, index or identity fields. Application has a list page and a single page view with a basic info column fully functional. Users will be able to set their own node endpoint. There will be a follow-up for the project that would support a plug-in ecosystem for different sub-views of identities. On-line version would come with some default plug-ins deactivated and an off-line version would support simple installation of other plug-ins. Default plug-ins would be basic info, governance, treasury and validator, and optional plug-in would be transaction history, identity history, remark history and society plug-ins.

    Additional Informationโ€‹

    Possible additional information to include:

    - + \ No newline at end of file diff --git a/applications/substrate-parachain-PoS-template.html b/applications/substrate-parachain-PoS-template.html index b206dfa5cc4..c925ea7d05d 100644 --- a/applications/substrate-parachain-PoS-template.html +++ b/applications/substrate-parachain-PoS-template.html @@ -4,7 +4,7 @@ substrate-parachain-PoS-template | Web3 Foundation Grants - + @@ -24,7 +24,7 @@ With more developers using this template, it will further help us find problems when upgrading the runtime or client of aband-parachain. Make Aband-Network more secure.

    Ecosystem Fitโ€‹

    This project makes up for Polkadot's lack of official PoS parachain templates. At the same time, it also makes up for the shortcomings of moonbean, because their Staking is very different from Substrate's Staking. This is more friendly to both developers and users. It is born for better use of substrate to develop PoS parallel chains.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 - Based on the nimbus consensusโ€‹

    Based on the nimbus consensus, make a PoS parachain development template with Polkadot Staking and Staking related modules.

    โ— The default deliverables 0a-0d below are mandatory for all milestones, and deliverable 0e at least for the last one.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationAdd documentation explaining how these modules fit together to complete the entire PoS process.
    0c.Testing and Testing GuideAdd manual tests to prove that the entire PoS runs successfully. Provide unit testing and benchmarking for the Collators pallet.
    0d.DockerProvide Docker to the chain, allowing anyone to quickly run the chain
    1client codeProvide a client with the same functions as https://github.com/substrate-developer-hub/substrate-parachain-template/tree/main/node. Such as having the try-runtime command, etc.
    2Substrate Modlue: CollatorsThe role of the Collators pallet is to provide a validator set for consensus. The validator can come from the staking module, which can also be set by ensure_root in this module, which means that with this template, you can also use the Staking function in the case of PoA, which is very useful if you just only want to reward collators.

    Future Plansโ€‹

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    You can find more information about the program here.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website / Medium / Twitter / Element / Announcement by another team / personal recommendation / etc.

    personal recommendation

    - + \ No newline at end of file diff --git a/applications/substrate-tutorials.html b/applications/substrate-tutorials.html index 090ee6d9a1c..fd94eda5788 100644 --- a/applications/substrate-tutorials.html +++ b/applications/substrate-tutorials.html @@ -4,7 +4,7 @@ Substrate Tutorials | Web3 Foundation Grants - + @@ -23,7 +23,7 @@ We saw every Substrate companies struggling to hire, our bet is that they will be happy to have their links on a repository which becomes an obvious step for everybody learning Substrate.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    The work we have already done so far can be found here: https://github.com/rusty-crewmates/substrate-tutorials
    No other teams have contributed financially to this project.
    No other grants have been apllied for at the moment, but we had several talks with people at Edgeware DAO whom were willing to support this project to apply for some funds of them.

    - + \ No newline at end of file diff --git a/applications/substrate_client_java.html b/applications/substrate_client_java.html index 9bfbbdcd661..ee65a0e8ea1 100644 --- a/applications/substrate_client_java.html +++ b/applications/substrate_client_java.html @@ -4,7 +4,7 @@ Substrate Client for Java | Web3 Foundation Grants - + @@ -16,7 +16,7 @@ When a processor faces a parameter like Some<String> value, it injects the Strings's writer into the writer of Some.

    GC Manageable requests.โ€‹

    We take care of either lost responses or canceled futures by not holding handlers that are needed to match an RPC request with a response.

    Tests run with substrate node.โ€‹

    All API methods related to the substrate node will be tested for operability and compatibility. Currently we use test containers and docker image parity/substrate:v3.0.0. But we have plans to increase number of supported versions.

    Our vision of the APIโ€‹

    How to generate scale codec for DTO (implemented)โ€‹
    @RequiredArgsConstructor
    @Getter
    @ScaleWriter
    public class SignedExtra<E extends Era> implements Extra, SignedExtension {
        @Ignore
        private final long specVersion;
        @Ignore
        private final long txVersion;
        @Ignore
        private final BlockHash genesis;
        @Ignore
        private final BlockHash eraBlock;
        private final E era;
        @Scale(ScaleType.CompactBigInteger.class)
        private final BigInteger nonce;
        @Scale(ScaleType.CompactBigInteger.class)
        private final BigInteger tip;

        @Override
        public AdditionalExtra getAdditionalExtra() {
            return new SignedAdditionalExtra(specVersion, txVersion, genesis, eraBlock);
        }
    }
    How to generate RPC interface (implemented)โ€‹
    @RpcInterface(section = "author")
    public interface Author {
        @RpcCall(method = "hasKey")
        CompletableFuture<Boolean> hasKey(@Scale PublicKey publicKey, String keyType);

        @RpcCall(method = "insertKey")
        CompletableFuture<Void> insertKey(String keyType, String secretUri, @Scale PublicKey publicKey);

        @RpcCall(method = "submitExtrinsic")
        @Scale
        CompletableFuture<Hash> submitExtrinsic(@Scale Extrinsic<?, ?, ?, ?> extrinsic);

        @RpcSubscription(type = "extrinsicUpdate", subscribeMethod = "submitAndWatchExtrinsic", unsubscribeMethod = "unwatchExtrinsic")
        CompletableFuture<Supplier<CompletableFuture<Boolean>>> submitAndWatchExtrinsic(@Scale Extrinsic<?, ?, ?, ?> extrinsic,
                                                                                        BiConsumer<Exception, ExtrinsicStatus> callback);
    }
    Create instance of API (TBD)โ€‹
    Api api = Api.builder()
            .useWs()
            .withNodes("127.0.0.1:9944", "127.0.0.2:9944")
            .scanAnnotatedFrom("com.my_company.first", "com.my_company.second")
            .build();
    RPC: call method (implemented but not integrated into the API)โ€‹
    CompletableFuture<RuntimeVersion> versionFuture = api.getRpc()
            .getState()
            .getRuntimeVersion();
    RPC: subscribe (implemented but not integrated into the API)โ€‹
    CompletableFuture<?> unsubscribe = api.getRpc()
            .getChain()
            .subscribeNewHeads((ex, header) -> { print(header); });
    Pallet: transaction (TBD)โ€‹
    api.pallete(MyPallet.class)
            .myExtrinsic(someValue)
            .signAndSend(KEY_PAIR);

    Features Roadmapโ€‹

    The following list shows the features which are already implemented ([x]) as well as those yet to be implemented ([]).

    Ecosystem Fitโ€‹

    How does substrate-client-java fit into the ecosystemโ€‹

    We have identified that many teams dealing with both legacy and up-to-date Java systems need to define appropriate approaches to communicate with Substrate-based blockchains. For example wrapping the polkadot javascript client or trying to build their own implementation. We intend to make this work easier by offering to the community a ready to use and production ready library to be used in all Java application. We will use this solution ourselves in our production environment, since we have multiple applications running on different versions of Java platform that needs to communicate with the Polkadot ecosystem.

    Target audience and needs met by substrate-client-javaโ€‹

    With our solution we meet the need of any Java developer who needs to write new Java applications or adapt existing Java applications to communicate with a Substrate based blockchain.

    Other projects similar to substrate-client-javaโ€‹

    To our knowledge only one other project has tried to create a java library to communicate with Substrate-based blockchain, java-client. This project however was focused mainly on implementing what we indicated as "Declared known RPC sections and methods", and is targeting Java 11.

    Our solution targets Substrate instead of Polkadot, and is implemented with code generation technique, which brings a more generic, flexible and adaptable library. Our client is designed so that a custom pallet can be easily consumed without writing much code. And we support Java 8+ which still is the most popular version according to multiple surveys:

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Grateful if you could also copy the email address doken.network@gmail.com in all official communications.

    Team's experienceโ€‹

    Vadim has over 10 years of experience as as a software enfgineer and 3 years as Rust developer. Plamen is a Senior Engineer with over 15 years experience in particular in Java and cryptography. Vahram is a Senior Engineer with over 7 years experience in particular in Java. Teodor is a junior developer who recently joined the team, with a particular focus in Java development.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    The development of the substrate-client-java has been ongoing for some months now and we currently have already implemented the features indicated with [x] in the Features Roadmap section above.

    The current version of the substrate-client-java is available at https://github.com/strategyobject/substrate-client-java.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Queries APIโ€‹

    Implement a query api similar to the one of polkadot-js.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    1.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can execute queries.
    2.TestingCore functions will be covered by unit and integration tests to ensure functionality and robustness.
    3.WikiWe will publish a wiki page that explains the details of the implementation for queries within the substrate-client-java library.
    4.Query APIWe will add queries capabilities to the substrate-client-java.

    Milestone 2 โ€” Events supportโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    1.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can handle events.
    2.TestingCore functions will be fully covered by unit and integration tests to ensure functionality and robustness.
    3.WikiWe will publish a wiki page that explains the details of the implementation for events within the substrate-client-java library.
    4.Events supportWe will add event-handling capabilities to the substrate-client-java.

    Milestone 3 โ€” Transactions APIโ€‹

    Implement a transactions api similar to api.tx of polkadot-js.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    1.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can submit transactions.
    2.TestingCore functions will be fully covered by unit and integration tests to ensure functionality and robustness.
    3.WikiWe will publish a wiki page that explains the details of the implementation for transactions within the substrate-client-java library.
    4.Transactions APIWe will add transactions capabilities to the substrate-client-java.

    Milestone 4 โ€” Handling of Metadataโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    1.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains about handling of metadata.
    2.TestingCore functions will be fully covered by unit and integration tests to ensure functionality and robustness.
    3.WikiWe will publish a wiki page that explains the details of metadata handling within the substrate-client-java library.
    4.Metadata supportWe will add metadata capabilities to the substrate-client-java.

    Milestone 5 โ€” RPC sections and methodsโ€‹

    Implement RPC sections and methods that remained unimplemented from the previous steps.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    1.DocumentationWe will provide inline documentation of the declared RPC sections and methods.
    2.TestingCore functions will be fully covered by integration tests to ensure functionality and robustness.
    3.WikiWe will publish a wiki page that explains the details of the implementation for RPC sections and methods within the substrate-client-java library.
    4.RPC methodsWe will add missing RPC sections and methods to the substrate-client-java.

    Milestone 6 โ€” ED25519โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    1.DocumentationWe will provide both inline documentation of the code and a basic tutorial that covers ED25519.
    2.TestingCore functions will be fully covered by unit tests to ensure functionality and robustness.
    3.WikiWe will publish a wiki page that explains the details of using ED25519 within the substrate-client-java library.
    4.ED25519We will add ED25519 support to the substrate-client-java.

    Milestone 7 โ€” Constants APIโ€‹

    Implement Constants API similar to api.consts of polkadot-js that allows access to the runtime constants.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    1.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to access the runtime constants.
    2.TestingCore functions will be fully covered by unit and integration tests to ensure functionality and robustness.
    3.WikiWe will publish a wiki page that explains the details of the constants api within the substrate-client-java library.
    4.ConstantsWe will add constants access capabilities to the substrate-client-java.

    Future Plansโ€‹

    We intend to use the substrate-client-java to integrate our corporate Java-based ecosystem with our Substrate-based solutions. Moreover we are ready to share the client library we are developing and its source code to the community, further develop and maintain it. We have resources and are ready to deliver later bugfixes, improvements, new features and keep the client up to date with the newer versions of Substrate. We plan to grow a community of Java developers who need to integrate their applications to a Substrate-based blockchain and the usage of substrate-client-java will ease their work.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We heard about the Grants Program by Web3 Foundation and we have been in contact with managers at parity.io who guided us towards this application.

    We have indicated the work we have already done in the section Features Roadmap above, where we indicated the already implemented features with [x].

    There are no other teams who have already contributed to this project, not previoulsy grants we applied for.

    - + \ No newline at end of file diff --git a/applications/substrate_core_polywrapper.html b/applications/substrate_core_polywrapper.html index a7d34723740..75fd8b93554 100644 --- a/applications/substrate_core_polywrapper.html +++ b/applications/substrate_core_polywrapper.html @@ -4,14 +4,14 @@ Substrate Core Polywrapper | Web3 Foundation Grants - +
    Skip to main content

    Substrate Core Polywrapper

    • Team Name: ChainSafe
    • Co-Sponsor: Polywrap DAO (Approved Grant Proposal)
    • Payment Address: 0x85D81Ab61Fe16CDcaeF2Ca556ED4577A51b9b07C (USDC preffered)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    For this proposal, we'll be developing:

    1. Substrate Core RPC Polywrapper: Polywrapper in Rust that enables users to interact with substrate-based chains using any language on any platform.
    2. Substrate Signer Provider Plugin (js): Polywrap Plugin for Javascript host that allows signing of messages and transactions to be done using the polkadot-js browser plugin.
    3. Developer Documentation: Documentation showing developers how they can use the substrate core wrapper within their dapps and wrappers.

    In the future, we'd like to continue this work by developing:

    1. Token Balance Interface: Polywrap standard interface that defines common functionality for all pallets supporting "balances".
    2. Balances Implementation Wrapper: An implementation of the "Token Balance" interface that interacts with the Balances pallet's ABI.
    3. [Pallet ABI -> Polywrapper] Codegenerator: A code generator that generates Polywrap code based on a Pallet's ABI (leveraging the chain's metadata).
    4. Developer Documentation: Documentation showing developers how they can use the Balance wrapper, implement their own Balances implementation, and generate Polywrappers from pallet ABIs.

    Future proposals will be made for the above. Below we'll explain the work in its entirety.

    About Polywrap: Polywrap is a dev toolchain that enables easy integration of Web3 protocols into any application. It makes it possible for software on any device, written in any language, to read and write data to Web3 protocols.

    https://polywrap.io/#/

    Project Detailsโ€‹

    Polywrapper will be written in Rust and compiled to WASM so that it can be used by developers to call substrate methods by simply invoking graphql calls. We will deploy the Substrate wrapper to IPFS.

    Project heavily relies on the Polywrap toolchain and Polywrap team support.

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem?

      Polywrap will allow polkadot dapp developers to integrate protocol logic into dapps in a simple, familiar way, regardless of their implementation language.

      Additionally it will enable a new "standardization layer" for dapps developers to use, enabling the aggregation of multiple similar-but-different chains. The first standard interface we'll be developing in the future will be the "token balance" interface. We will create an implementation of this interface for the Substrate Balance Pallet.

    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

      Our initial target audiences are dapp/wallet developers, as well as the broader web3 developer ecosystem since Polywrap is architected in a chain-agnostic way. We'll be working with the Talisman team to ensure the work we're doing aligns with their wallet's needs. We've already had preliminary conversations with them, and they're excited to work with the software we build for this grant.

      Additionally the Talisman team has confirmed that, if this Polywrap integration suites their needs like they/we think it will, they are willing to help contribute to the codebase(s) going forward along with ChainSafe and the Polywrap DAO.

    • What need(s) does your project meet?

      Polywrap meets the needs of dapp developers who want a simple way to integrate protocol logic into their dapps. The Polywrap integration experience should be extremely familiar to any develop who has integrated a Web 2.0 API. The dapp dev simply needs to add the Polywrap client into their dapp, and then they will be able to send GraphQL queries to an endpoint to execute protocol functions.

      Additionally, as previously stated, we've noticed that in the multi-para-chain future there is a need for another layer of standardization. This is because pallet ABIs may be different amongst multiple chains, but be effectively serving the same purpose (Tokens, AMMs, Profiles, Governance, etc). With Polywrap developers can create standard interfaces that can be implemented in many different ways, depending on the pallet being used. The dapp developer simply uses the standard interface methods/types, and doesn't have to care about the implementation details of the chain/pallet. We feel that this goes hand-in-hand with the "enriched metadata & typeinfo" feature that was recently merged.

      Lastly, it's worth noting that polywrappers can be downloaded and executed at run-time due to the security and portability of WebAssembly. This means that dapps using the "Token Balance" interface can potentially update themselves without having to be rebuilt, dynamically supporting new chains as they come online.

    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

      There are not other projects solving the integration issue today at the SDK layer. As previously mentioned, the "enriched metadata & typeinfo" PR solves the introspection problem at the chain-level, but there is more to do farther down the integration pipeline at the dapp level. This is where Polywrap will help.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Matthias Seitz - Team Lead
    • Tianyi Zhang
    • Willes Lau
    • Willem Olding

    Contactโ€‹

    • Registered Address: 251 Spadina Ave, Unit 204, Toronto, Ontario, Canada
    • Registered Legal Entity: ChainSafe Systems Inc.

    Team's experienceโ€‹

    ChainSafe is a global leader in blockchain protocol and infrastructure solutions for Web 3.0. The firm encompasses top engineering talent from around the world. The company is architecting official client implementations on Ethereum 2.0 (โ€œLodestarโ€), Polkadot (โ€œGossamerโ€), Filecoin (โ€œForestโ€™โ€™), a Rust implementation of the Mina Protocol, and many more.

    ChainSafe rounds out their deep Web 3.0 portfolio with undertakings into product development via their privacy-first file storage solution ChainSafe Files, the ChainSafe Gaming SDK, as well as their flagship product ChainBridge.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 1 month
    • Full-Time Equivalent (FTE): 2 Software Engineer, 0.5 Project Manager
    • Total Costs: 50,000 USD
    • Total Polywrap DAO Costs: 27 000$ & 60 WRAP (Approved Grant Proposal)
    • Start Date: 11. April 2022

    Milestone 1 - Substrate RPC Polywrapperโ€‹

    • Estimated duration: 1 month
    • FTE: 2 Software Engineer, 0.5 Project Manager
    • Costs: $50,000
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can interact with polywrapper
    0c.Testing GuideCore functions will be fully covered by unit tests and e2e tests using polywrap recipes json tests
    0d.ArticleWe will publish an article that explains the what/why/how of integrating Substrate based chains using Polywrap. Some examples from the BlockWatch team's Tezos integration: launch article, dev docs.
    1.Schema DefinitionsDescribed below
    2.signer-provider Polywrap Client JavaScript PluginDescribed below
    3.rpc-wrapper WrapperDescribed below

    NOTE: 2 & 3 can be developed in parallel once schemas are defined.

    1. Schema Definitionsโ€‹

    There will be 2 Polywrap schemas:

    • signer-provider - Low-level interface for accessing the application's configureable signer / provider.
    • rpc-wrapper - Higher-level interface for interacting with a substrate based chain. This depends upon on an implementation of the substrate-signer-provider interface above.

    To get a better idea of what this "separation of concerns" looks like in practice, please refer to this example specification for the Polywrap <> Near integration that's actively being developed.

    2. signer-provider JavaScript Pluginโ€‹

    Plugins, in the context of Polywrap, are a special type of wrapper. Instead of being run as WebAssembly, they run as native modules in the application's language (ex: JavaScript). This allows the wrappers to access the application's native capabilities (ex: filesystem access), unlike WebAssembly wrappers which are run within their own nano-process sandboxed.

    The Substrate signer-provider plugin will enable the rpc-wrapper to:

    • Get all available accounts within the application's wallet (Keyring).
    • Sign arbitrary messages.
    • Sign transaction payloads.

    Polkadot.js will be used as the backing Keyring, enabling developers to use the browser-based wallet provided by the Polkadot.js extension, or additionally use a FileStore which can be used to load a wallet from the filesystem.

    The plugin would typically be instantiated and configured when instantiating the Polywrap Client, like so:

    import { substrateSignerProviderPlugin } from "substrate-signer-provider-plugin-js";
    import { PolywrapClient } from "@polywrap/client-js";

    const plugin = substrateSignerProviderPlugin();

    const client = new PolywrapClient({
      plugins: [{
        uri: "ens/substrate-signer-provider.chainsafe.eth",
        plugin
      }]
    })

    // Now we can use the above client to invoke the RPC wrapper,
    // which requires "ens/substrate-signer-provider..." as a dependency
    const accounts = await client.invoke({
      uri: "ens/substrate-rpc-wrapper.chainsafe.eth",
      method: "getSignerProviderAccounts"
    });

    Additionally, users can configure the plugin with their own SignerProvider instance, like so:

    import {
      substrateSignerProviderPlugin,
      KeyringSignerProvider
    } from "substrate-signer-provider-plugin-js";
    import { Keyring } from "@polkadot/ui-keyring";
    import { FileStore } from "@polkadot/ui-keyring/stores";

    // Load keystore from a directory
    const filestore = new FileStore("/path/to/keystore/dir");

    // Create your own keyring
    const keyring = new Keyring();

    // Load the keystore into the keyring
    keyring.loadAll({ store: filestore });

    const plugin = substrateSignerProviderPlugin({
      provider: new KeyringSignerProvider(keyring)
    })

    To get an idea of what the substrate-signer-provider schema might look like, please see the Near plugin's schema here.

    3. rpc-wrapper Wrapperโ€‹

    The Polywrapper is a set of WASM modules that contain the bulk of the logic needed to interact with substrate based chains. The Polywrapper calls the aforementioned JavaScript Plugin only when necessary to perform signing tasks.

    A call to the Polywrapper might look something like this (TS/JS application):

    const result = await client.invoke({
      uri: "ens/substrate-rpc-wrapper.chainsafe.eth",
      method: "chainGetBlock",
      args: {
        url,
        number: 0
      }
    });

    if (!result.ok) {
      handleError(result.error);
      return;
    }

    const blockOutput = result.value;

    Or by using the Polywrap toolchain's application codegen, you can have this be fully typed like so:

    import { Substrate_Module, Substrate_BlockOutput } from "./wrap";

    const result = await Substrate_Module.chainGetBlock({
      url,
      number: 0
    }, client);

    if (!result.ok) throw Error("...");

    const output: Substrate_BlockOutput = result.value;

    The rpc-wrapper exposes the following interface that maps closely to the default Substrate node RPC:

    • getSignerProviderAccounts
    • chainGetMetadata
    • blockHash
    • genesisHash
    • chainGetBlock
    • constant
    • getRuntimeVersion
    • getStorageValue
    • getStorageMap
    • getStorageMapPaged
    • rpcMethods
    • accountInfo
    • getNonceForAccount
    • palletCallIndex
    • sign
    • send
    • signAndSend

    We will be heavily leverage existing Rust crates in the substrate developer ecosystem to implement the wrapper detailed above.

    Future Plansโ€‹

    As stated above, we'd like to continue to build upon the work done within this proposal, by enabling multi-chain token balance aggregation (through the use of Polywrap interfaces).

    We hope that with this work complete, a team like Talisman will be able to continuing using the tooling we've developed to fully realize their vision of having a fully featured multi-para-chain wallet.

    The work created by this grant will be stewarded by the ChainSafe & Polywrap DAO teams, as well as the Talisman team if they decide to build upon what we've created.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? personal recommendation

    - + \ No newline at end of file diff --git a/applications/substrate_startkit_GUI.html b/applications/substrate_startkit_GUI.html index 223abfea1a7..6115abdd604 100644 --- a/applications/substrate_startkit_GUI.html +++ b/applications/substrate_startkit_GUI.html @@ -4,7 +4,7 @@ Substrate startkit GUI | Web3 Foundation Grants - + @@ -15,7 +15,7 @@ We are also members of the Ethereum Enterprise Alliance and the Stellar Development Foundation.

    The UX/UI of the app will be an essential part. So let me share with you some of our previous work on dribbble -https://dribbble.com/mvpworkshop.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Milestone 1โ€‹

    NumberDeliverableSpecification
    1.Design components for GUIVisual design of application components (in invision)
    2.Design UX flowsCreate a UX that is pleasant to work with
    3.BackendpostgresSQL database, node.js project setup
    4.GUI web applicationSet React app project structure
    5.Documentation & specificationExplore all the runtime pallets intentions and define their relations in the project documantation
    6.Github OAUTH2 IntegrationIntegrate Github OAUTH so users can login and later deploy codebase on their account

    Milestone 2โ€‹

    NumberDeliverableSpecification
    1.GUI web applicationReact app components
    2.Github IntegrationIntegrate Github library so the user could generate a initial commit with the code base on his account
    3.BackendAPI's for handling the code base structure and setting configuration and dependencies with and corresponding tests
    4.Demo videoVideo showcasing how to use the app
    5.DocumentationDescribe functionalities and instructions on compiling and running the app, including a feature list and written tutorial.
    6.Continuous Integration environmentPipeline that build the web applications
    7.Automated testsfor the whole app

    Deliverables will be dockerized.

    Long term plans and the target users of such an applicationโ€‹

    The target users would definitely be beginners and even people that wanna play a bit and not really start a production-ready blockchain. Experienced blockchain devs beginning to build a project with Substrate are probably familiar with how to start, and whoever has to deep dive into the code so they are not the ones that will benefit the most. We didn't consider the possibility of online chain running in this phase of the project, but it could be an option for some future version. Looking long term, this GUI would be the place for everyone to quickly get informed on runtime pallets so it should be periodically updated with new information. So the primary purpose is educational but also promotional. We added in the deliverables features focused on education such as:

    - + \ No newline at end of file diff --git a/applications/subvt-telegram-bot.html b/applications/subvt-telegram-bot.html index d85333a4ef2..86798a22cc6 100644 --- a/applications/subvt-telegram-bot.html +++ b/applications/subvt-telegram-bot.html @@ -4,13 +4,13 @@ SubVT Telegram Bot for Kusama and Polkadot | Web3 Foundation Grants - +
    Skip to main content

    SubVT Telegram Bot for Kusama and Polkadot

    • Team Name: Helikon Labs
    • Payment Address: bc1qxjy7sw0ffvpq86t6hj3mmqhnfz2hxt6pk7zdz0 (BTC)
    • Level: ๐Ÿฃ 1

    ๐Ÿ“ฃ 10th of May, 2022 Development Updateโ€‹

    Despite the initial plan to upgrade the existing 1KV Telegram Bot, SubVT Telegram Bot has been rewritten from scratch in Rust and is fully integrated with the SubVT Backend. You may find the Telegram bot crate in the SubVT Backend repository.

    Release and submission date for the bot including all milestones is the 19th of May 2022. It's going to be an overdelivery with the following additional features on top of the complete initial promises:

    • Extra commands:
      • /referenda: Lists the open on-chain referenda for the network, and the user can click on one of them to view the contextual information fetched from Polkassembly, and the information also shows the votes of the validators on the chat for the selected referendum.
      • /nfts: Displays a paged list of the NFTs on the stash account of a selected validator. User can then select an NFT and get redirected to its web URL. This command uses the sub.id API.
      • /networkstatus: This command was included under Future Plans in the initial proposal. It is implemented and is going to be available on the release.
      • /contact: Lets the user to post bug reports and feature requests directly from the bot to the dev team.
      • /summary: Summary information of all the validators on the chat. Useful to get an overall view of the validators such as which ones are active, which ones are active next session, their nominator count and active/inactive nomination amounts etc.
    • Extra notifications when:
      • A validator is going to be active/inactive next session (early notification for possible preparation or checks).
      • A validator has outstanding payouts.
      • A validator votes for a referendum.
      • There's a new referendum open for vote.
      • Referendum passed / not passed / cancelled.
      • There's a new democracy proposal.
      • A validator has delegated or undelegated its votes.

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    SubVT Telegram Bot is an upgrade for the existing Helikon Polkadot/Kusama 1KV Telegram Bot to support all validators on Kusama and Polkadot with increased functionality and performance.

    Future upgrades aim for adding support for other proof-of-stake (PoS) Substrate-based networks such as HydraDX, Darwinia (Crab), Edgeware and more, and Telemetry data access to support more real-time node data and notifications.

    The 1KV Bot currently serves 221 out of 359 valid nodes on Kusama and 90 out of 129 valid nodes on Polkadot. Relatively high adoption rates (61% on Kusama and 69% on Polkadot) with very little announcement have resulted in our interest in extending the bot's support to all Kusama and Polkadot validators, and other Substrate-based PoS networks in the future.

    This upgrade consists of migrating the bot to use the backend services and storage of SubVT (Substrate Validator Toolkit), which is an under-development native mobile application project for iOS and Android phones, tablets and wearables, supported by the Kusama Treasury.

    Project Detailsโ€‹

    The 1KV Bot currently has a number of issues such as:

    • No support for validators outside the 1KV. It's also not possible for it to support networks other than Kusama and Polkadot in its current state.
    • New nomination notification doesn't work for nested calls such as multi-sigs, batch calls and proxied calls. It only works for top-level nominate extrinsics.
    • /stakinginfo command displays only an overview of the nominations backing the validator. The command response is slow on Kusama and even slower on Polkadot since it fetches and indexes the nomination data for the validator after every command call.
    • No account age information.
    • No chart for 1KV rating history.
    • No 1KV score information.
    • Missing notifications for:
      • Lost nominations.
      • validate extrinsic.
      • On-chain identity change.
      • Payouts.


    Current state of the 1KV Bot

    SubVT backend, under development for the SubVT mobile applications, is near its first-phase completion and can provide very fast data access required by the current 1KV Bot functionality and more. Below is a diagram of the proposed upgrade for the 1KV bot to utilize the SubVT backend services.


    Proposed upgrade

    SubVT backend is being developed in Rust. Proposed upgrade for the bot is going to improve and re-structure the current Javascript codebase to have the following modules:

    1. Telegram Bot API communication component.
    2. Information services component, which serves the commands sent from the user device.
    3. Notifier component, which delivers notifications as Telegram messages to the user's phone through the Telegram Bot API.


    SubVT Telegram Bot components

    Below is a list of commands that the bot will have after the upgrade.

    CommandDescription
    /validator-infoComplete chain data and (optional) 1KV data about the validator.
    /nominationsAn overview of the active and inactive nomination data. Number of nominators and total amounts.
    /nomination-detailsBreakdown of all active and inactive nominations. Includes nominator addresses and identities and number of other nominees per each nomination.
    /rewardsA chart that displays the total rewards earned by the validator per month and the total amount earned.
    /payoutsA chart that displays the total rewards paid out by the validator to nominators per month and the total paid-out amount.
    /settingsNotification settings.
    /addAdd a new validator to the chat.
    /removeRemove an existing validator from the chat.
    /helpA list of commands and their descriptions.
    /aboutDevelopment, codebase and contribution details.

    And below are the list of notifications after the upgrade:

    • New notifications:
      • New nominations in batch, multi-sig and proxy calls.
      • Nomination lost.
      • New validate extrinsic.
      • Identity or parent identity changed.
      • Payout call for an era, or multiple eras in a batch call.
    • Existing notifications:
      • Active set inclusion and exclusion.
      • Block(s) authored.
      • Validator chilled.
      • Offline offence committed.
      • Commission changed.
      • Controller changed.
      • 1KV-related.
        • Validity changed.
        • Rank changed.
        • Binary version changed.

    Ecosystem Fitโ€‹

    There are currently two more bots for the Polkadot and Kusama validators, both production-level and robust. One is by CryptoLab, and the other by Ryabina, both with Kusama and Polkadot versions.

    Ryabina bot is a more generalized one that supports configurable alerts for all extrinsics and events, yet it doesn't provide more validator-specific functionality such as in-chat reward reports, and the configuration is not very user-friendly due to the generalized nature of the solution. It also doesn't support 1KV data.

    CryptoLab bot is a validator bot with the strength of Telemetry support, yet it's also missing the in-chat reports and 1KV data.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Kutsal Kaan Bilgin

    Contactโ€‹

    • Registered Address: Omer Avni Mah. Balcik Sok. 4/4 34427 Beyoglu Istanbul Turkey
    • Registered Legal Entity: Helikon Teknoloji ve Medya Tic. Ltd. Sti.

    Team's experienceโ€‹

    I am a software developer with a bachelor's degree in Computer Science and 20 years of experience in development and leading. After a series of positions mostly in enterprise software development settings, I focused on native mobile development for iOS and Android between 2012 and 2019, in which year I was introduced to the world of blockchain and cryptocurrencies when I got hired by Tari. For a duration of 1 year and 8 months I led the development of Aurora, the Tari cryptocurrency wallet for Android and iOS. The app got received very well by the Tari community thanks to its lean, eye-pleasing design and simple UX. I learned a lot at Tari about how blockchain systems work and the cryptocurrency ecosystem in general. Working with a product management team thatโ€™s super-focused on usability and simplification gave me a perspective on the value of good UX and UI in a field thatโ€™s notorious for its technical difficulties for the not-so-technical users.

    After my time at Tari I got interested in Polkadot and Kusama ecosystems and started running a Kusama validator enrolled in 1KV. I developed the Kusama 1KV Bot just to scratch my own itch, then ported it to Polkadot. After experimenting a bit with Substrate storage and RPC interface, I developed the idea of SubVT and prepared a treasury spending proposal for the project, which got accepted by the Kusama council. I have been working with Klad, supervising the UX and UI design for the project, which is now complete. I've also been working on the SubVT backend, which is also near completion, bringing SubVT to its second stage: Android and iOS applications development.

    Team Code Reposโ€‹

    Helikon Labsโ€‹

    Team Membersโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    N/A

    Development Status ๐Ÿ“–โ€‹

    The original 1KV Bot for Kusama and Polkadot has been running successfully for nearly 9 months. SubVT backend is near completion with the deadline of the 13th of December with complete tests and documentation.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 0.33
    • Total Costs: 9,600 USD

    Milestone 1 โ€” Migration to the SubVT Services, Extended Support and Initial Fixesโ€‹

    • Estimated duration: 1.5 months
    • FTE: 0.33
    • Costs: 4,800 USD
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationMilestone progress report and inline code documentation. GitHub README that explains how to run an instance.
    0c.Testing GuideSeparate markdown in the GitHub repository that documents the complete test cases and how to run them.
    0d.DockerA Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleAn article that documents the development process and the outcome.
    1.SubVT Services MigrationMigrate the bot to use the SubVT backend services.
    2.Support for All ValidatorsExtend the bot to support not just 1KV validators but all Kusama and Polkadot validators.
    3.Notification FixesFix the notification logic so that the bot supports nominate notifications for multi-sig, batch and proxy calls.

    Milestone 2 โ€” New featuresโ€‹

    • Estimated Duration: 1.5 months
    • FTE: 0.33
    • Costs: 4,800 USD
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationMilestone progress report and inline code documentation. GitHub README that explains how to run an instance.
    0c.Testing GuideSeparate markdown in the GitHub repository that documents the complete test cases and how to run them.
    0d.DockerA Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.ArticleAn article that documents the development process and the outcome.
    1.Improve Validator Info MessageInclude account age and optional 1KV score data in the validator info message.
    2.Implement New NotificationsExtend the bot with new notifications for lost nominations, on-chain identity change, validate extrinsic and payouts calls for a single era or multiple eras in a batch call.
    3.Implement New CommandsImplement the new /nomination-details and /payouts commands.

    Future Plansโ€‹

    • Telemetry integration.
      • Notifications for peer count and bandwidth thresholds, and possibly others related to the Telemetry data
    • /network-info command.
      • Displays a summary of the network's status and overall staking data.
    • Support for additional Substrate-based PoS networks.
    • Score spider chart for 1KV members.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    I read about the program when I was initially researching into the Polkadot ecosystem in early 2021.

    In October 2021 Marcin Gรณrny kindly offered support for the extension of the 1KV Bot to all Kusama and Polkadot validators in an issue he posted to the 1KV Bot repository.

    - + \ No newline at end of file diff --git a/applications/subwallet.html b/applications/subwallet.html index 145d0635d81..735f353ff22 100644 --- a/applications/subwallet.html +++ b/applications/subwallet.html @@ -4,13 +4,13 @@ subwallet | Web3 Foundation Grants - +
    Skip to main content

    subwallet

    • Proposer: Faber
    • Payment Address: 1BHAopuz14S7L58oea1e6eTZpXuzYt8Ap9

    Project Description ๐Ÿ“„โ€‹

    subwallet is a light command line interface wallet for Polkadot/Substrate. subwallet will be like bitcoin-cli, includes address management and extrisinc(transaction) management. It will be implemented with Rust.

    Team ๐Ÿ‘ฅโ€‹

    Faber is a backend developer with 10+ years of strong experience. Learned and researched blockchain technology about 3 years. Familiar with Rust and Substrate.

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 8 weeks
    • Total Costs: 0.8 BTC

    Milestone 1โ€‹

    • Estimated Duration: 4 weeks
    • Costs: 0.3 BTC
    NumberDeliverableSpecification
    1.Command helpsubwallet --help prints help information
    2.Address generationsubwallet getnewaddress [label] will generate a random address and save to local file.
    3.Address listsubwallet listaddresses will list all generated addresses
    4.Backupsubwallet backup [address_or_label] will backup address as json that compatible with https://polkadot.js.org/apps
    5.Restoresubwallet restore [file] will restore address from the file that compatible with https://polkadot.js.org/apps
    6.Unit TestsWrite unit tests for commands: getnewaddress, listaddresses, backup and restore.
    7.DocumentationUsages and demos of every command.

    Milestone 2โ€‹

    • Estimated Duration: 4 weeks
    • Costs: 0.5 BTC
    NumberDeliverableSpecification
    1.Set RPC urlsubwallet setrpcurl [url] save the RPC url to local file for other commands(transfer/syncextrinsics)
    2.Display balancessubwallet getbalances will also show balances of addresses
    3.Balance transfersubwallet transfer [from] [to] [amount] transfer amount balances from from address to to address
    4.Sync extrinsicssubwallet syncextrinsics [address_or_label] download and save address related extrinsics from remote node to local file through RPC.
    5.Extrinsic listsubwallet listextrinsics [address_or_label] lists all downloaded extrinsics of address
    6.Unit TestsWrite unit tests for every command.
    7.DocumentationUsages and demos of every command.

    Additional Information โž•โ€‹

    • This will be version 0.1. In the future, more RPC methods will be implemented and will support other Substrate-based chains.
    - + \ No newline at end of file diff --git a/applications/sukhavati_poc_module.html b/applications/sukhavati_poc_module.html index 93d455b4fc0..ddceb49928f 100644 --- a/applications/sukhavati_poc_module.html +++ b/applications/sukhavati_poc_module.html @@ -4,13 +4,13 @@ Sukhavati PoC Module | Web3 Foundation Grants - +
    Skip to main content

    Sukhavati PoC Module

    • Team Name: Sukhavati Labs
    • Payment Address: 0x4756b4a72Fb08d936a9ee780f36e411B3F9E1873
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Sukhavati is a decentralized cloud service network focused on storage. It uses the MASS Proof of Capacity (PoC) protocol as its consensus protocol so that it can reuse existing PoC capacity power and quickly establish a strong consensus layer. The MASS PoC consensus algorithm is very energy efficient. After the initialization operation, it requires only a small amount of computing and IO resource consumption to maintain high security consensus, allowing most resources to be used for other meaningful work.

    Currently the MASS PoC network has a total of about 230PB in capacity power, making it the second-largest PoC network. Sukhavati takes PoC as the entry point. After incorporating a wide range of PoC miners into the consensus network, Sukhavati will continue to build the needed infrastructure to serve the Web3.0 ecosystem on these PoC devices, taking full advantage of idle computing and bandwidth resources and truly decentralized network topology. Sukhavati eventually intends to build a decentralized data access gateway that covers both Web3.0 and Web2.0 storage services and that provides unified data storage, retrieval, and management services that can meet various local compliance requirements for Web3.0 applications.

    After completing the first version (which is based on the original codebase) and idea validation, Sukhavati plans to migrate to the Substrate framework (planned for Q2). The powerful and flexible features such as off-chain workers, on-chain governance and runtime upgrade provided by Substrate can bring Sukhavati great convenience and enable us to easily develop the storage and content distribution functions in the future steps.

    While enjoying all these features, we would like to give back to the community by providing a PoC Module for Substrate based on the MASS PoC consensus protocol, so that any blockchain developed based on Substrate can choose to use this module to implement PoC consensus and be able to reuse existing MASS PoC capacity power. This โ€œpiggybackingโ€ allows them to quickly have the same underlying device resources and potential influence as we do, thereby further exploiting the idle resources of the vast number of PoC mining devices. Through the implementation of this module, we hope to establish a connection between the substrate and the PoC ecosystem, giving web3.0 builders more options and room for imagination.

    Project Detailsโ€‹

    Plot Algorithm and Capacity File Importโ€‹

    The plot algorithm will generate two HashMaps, of which the latter one is kept as the capacity file.

    The plot process is as follows:

    1. Generate a root_key through secp256k1/ECDSA
    2. Using BIP-44 to derive child key pairs (pk, sk) from the root_key
    3. Set a BitLength and runs Plot algorithm with pk and BL as follows:
      • Generate a unique ID = doubleSHA256(pk) of the capacity file
      • For each x in [0, 2^BL-1], calculate y = SHA256(โ€˜MASSโ€™||ID||x). Generate a HashMap A with y as the index and x as the value
      • For each index y in HashMap A, flip each bit of it to get yโ€™, use yโ€™ as the index to find the corresponding xโ€™
      • For each x in [0, 2^BL-1] and corresponding xโ€™, calculate z = SHA256(โ€˜MASSโ€™||ID||x||xโ€™). Generate the HashMap B with z as the index and (x, xโ€™) as the value
    4. Use HashMap B as the efficient capacity

    The import method can be derived from the above process:

    1. Import the existing root_key from the mass miner
    2. Load the existing capacity file
    3. Derive child keys from root_key and match the public keys with the ID of the capacity files
    4. We can now use these existing capacity files for our own PoC consensus

    PoC Consensus Engineโ€‹

    Block Productionโ€‹
    1. Get challenge c from previous block
    2. The miner tries to find (x, xโ€™) and its corresponding BitLength and ID from HashMap B that satisfies:
      • cuthash(c, bl) == cuthash(SHA256(โ€˜MASSโ€™||ID||x||xโ€™), bl)
      • cuthash(y, bl) == flipped(cuthash(yโ€™, bl)), where y = SHA256(โ€˜MASSโ€™||ID||x) and yโ€™ = SHA256(โ€˜MASSโ€™||ID||xโ€™)
    3. If the above proof is found, the miner then calculates quality = (2^BitLength * BitLength ) / [256 - log2(H)], where H = SHA256(block_timestamp // slot_length, x, x', height)
    4. If the quality is higher than difficulty, the miner produces the block, creates the proof sig and signs the block.
    Block Validationโ€‹

    When a node receives a new block, it verifies all the signatures and PoC proof as follows:

    1. Verify the block signature and capacity proof signature
    2. Get PoC proof (x, xโ€™, bl), publickey pk and challenge c from block header and verify if they satisfy:
      • cuthash(c, bl) = cuthash(SHA256(โ€˜MASSโ€™||doubleSHA256(pk)||x||xโ€™), bl)
      • cuthash(SHA256(โ€˜MASSโ€™||doubleSHA256(pk)||x)) = flipped(cuthash(SHA256(โ€˜MASSโ€™|| doubleSHA256(pk)||xโ€™)))
    3. Calculate quality of the proof, and verify if itโ€™s higher than difficulty
    Difficulty Adjustmentโ€‹

    The desired block time is maintained by the following difficulty adjustment algorithm on every block:

    diff = parent_diff + parent_diff // 2048 * max(1 - (new_block_timestamp โ€“ last_block_timestamp) // 10, -99)

    Fork Choiceโ€‹

    When there is a potential new best chain, the node checks the following rules in sequential order to make the choice:

    1. The one with greater total difficulty
    2. The one with a better proof quality
    3. The one with an earlier block timestamp
    4. If all the above conditions are the same, choose the one with a smaller block hash

    Ecosystem Fitโ€‹

    The PoS/PoC consensus mechanism is starting to attract more attention with the rise of Chia. We notice that there are some other teams who are also building PoS/PoC consensus module for substrate, such as Subspace. The main difference between our protocols is that we are not trying to create a new PoC algorithm from scratch. What we want to do is to compatibly reuse the existing PoS/PoC consensus powers to form our own consensus layer and promote our blockchain to these miners, so that we can utilize their idle resources.

    In this proposal, we hope to make this capability of reusing PoS/PoC consensus power available as a substrate pallet. We believe some connection can be established between the substrate ecosystem and the PoS/PoC ecosystem, bringing more options and resources to Web3.0 builders.

    After establishing the underlying infrastructure, we hope to serve the Polkadot ecosystem as a parachain or parathread and provide a data access gateway for all Web3.0 DApps.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Sukhavati Dev Team

    Contactโ€‹

    • Registered Address: Vistra corporate Services Centre, Wickhams Cay II, Road Town, Tortola, VG1110, British Virgin Islands.
    • Registered Legal Entity: Sukhavati Labs Ltd.

    Team's experienceโ€‹

    • Rami: Blockchain Hardware Architect and consultant with a PhD in Electrical and Computer Engineering.

    • Chen: Expert in blockchain development and crypto economy modeling.

    • Hairu: Senior backend developer with over 10 years experience.

    Team Code Reposโ€‹

    https://github.com/Sukhavati-Labs/go-miner

    https://github.com/Sukhavati-Labs/go-wallet

    https://github.com/Sukhavati-Labs/web-wallet

    https://github.com/Sukhavati-Labs/skt-data

    https://github.com/Sukhavati-Labs/explorer

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 1.5
    • Total Costs: 4,000 DAI

    Milestone 1 โ€” Implement Capacity Management Palletโ€‹

    • Estimated Duration: 4 weeks
    • FTE: 1
    • Costs: 1,000 DAI

    This milestone will provide a PoC capacity management pallet. It allows miners to do the plot operation and import existing MASS PoC keys and capacity files.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to plot files and how to import existing capacity files with this module.
    0c.Testing GuideA guide describing how to run the tests covering the cases in 0b.
    1.Capacity Management PalletThis pallet will implement features include: 1) PoC key management, 2) plotting, 3) capacity import.
    2.TestUnit test and test cases.

    Milestone 2 โ€” Implement Sukhavati PoC Consensus Palletโ€‹

    • Estimated Duration: 8 weeks
    • FTE: 1.5
    • Costs: 3,000 DAI

    This milestone will provide a poc consensus pallet. Together with the capacity managemnt pallet in Milestone 1, developers can easily build their own chain that can reuse the MASS capacity power.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to use this PoC consensus engine.
    0c.Testing GuideA guide describing how to build a PoC blockchain with this module.
    1.PoC Consensus PalletThis pallet will implement the Sukhavati PoC Consensus engine including block production, block validation, difficulty adjustment and fork choice.
    2.TestUnit test and test cases.

    Future Plansโ€‹

    1. Research PoC/PoS power reuse, such as Chia.
    2. Help promote and develop channels of communication between blockchains based on this module and the miner community.

    Additional Information โž•โ€‹

    Sukhavati Labs has raised a seed round of funding.

    We are in contact with several PoC pools and the information we have received so far shows that PoC mining devices have a substantial amount of idle resources available, and most miners are very interested in being able to further upgrade their devices in order to provide real, meaningful use.

    - + \ No newline at end of file diff --git a/applications/sunrise-dex.html b/applications/sunrise-dex.html index c9cb76a50fc..0307f2d9891 100644 --- a/applications/sunrise-dex.html +++ b/applications/sunrise-dex.html @@ -4,7 +4,7 @@ Sunrise DEX | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Sunrise DEX

    • Team Name: Sunrise Protocol
    • Payment Address: bc1qv2jhx5ykm4szuu9lp4ehtxclf67v6n7dprcgyl
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Sunrise is building a decentralized protocol on a dedicated Polkadot parachain. We will enable deep liquidity starting with support for tokens on Sunrise Chain, Ethereum, and all parachains. Sunrise will support additional blockchains in the future.

    Our Decentralized EXchange (DEX) uses a bonding curve factory which supports liquidity pools for unpegged tokens such as ETH,DOT, LINK, ACA etc. Sunrise will support stable coin pools offering very low slippage and fees (e.g. DAI-USDT) and in the future stable coins that have different pegs (e.g. srsUSD-srsCNY).

    Sunrise Chain Vision Deployment

    The first phase of the project will be built and deployed on a parachain via Rococo. Our standalone parachain Sunrise Protocol Daybreak will be the precursor. Sunrise is also evaluating the ability to deploy an Intrachain DEX (running on our partners) parachain, this will be done either publishing a DEX crate, updating ORML libraries, or directly contributing to partners codebase with a pull request to their repository.

    Polkadot Ecosystem Benefits

    Sunrise protocol lays the foundation for the seamless exchange of assets, efficiency of stable coin transactions and advanced aggregation. Our product will attract the decentralized finance (DeFi) community and provide more liquidity that helps drive increased adoption for the Polkadot Network. The DEX is multi-platform and bridges across parachains allowing the community to access the latest protocols and initiatives. Sunrise has identified numerous gaps to capitalize on, in relation to the infrastructure of the most popular decentralized exchanges, which includes liquidity pool customization, limit order functionality and compliance functionality.

    Why are we creating this project

    This project provides a foundational layer for the Sunrise Protocol.

    Our team consists of founders, researchers, builders and strategists for blockchain and decentralized finance. We have built a layer 1 blockchain at Harmony (public blockchain with sharding and open staking), have launched private permissioned chains on ethereum and hyperledger fabric and have been actively involved in the Decentralized Finance community. We have chosen to build this project on Polkadot because Substrate allows us to focus on the Protocol and business logic. We feel the Partners in the ecosystem are laying the foundation for interoperable decentralization and we want to contribute to the community.

    Project Detailsโ€‹

    Please see this product overview presentation and Sunrise Protocol Whitepaper for an overview of the Sunrise Protocol vision.

    This Project is specifically for the Sunrise Dex Factory which is a foundational component for the Sunrise Protocol

    The Sunrise Decentralized Exchange (DEX) combines the use of multiple bonding curves and price oracles to support liquidity pools for unpegged tokens, and stable coin pools. Below is an excerpt from the Sunrise Protocol Whitepaper

    3. Sunrise DEX Factoryโ€‹

    The Sunrise DEX Factory will support the creation of Liquidity Pool Contracts. The bonding curves for these liquidity pools, will be slightly different depending on the use case. Each exchange contract can be configured to the specific needs of the liquidity pool.

    3.1 Sunrise Factory/Registry Contractโ€‹

    All contracts will have a uniform interface for liquidity management and swap management. Thus abstracting away the underlying complexity from liquidity providers and traders, giving them a uniform mechanism to interact with all Sunrise liquidity pools.

    Below is a list of the configuration parameters input into the factory contract when creating an exchange contract.

    Sunrise Protocol Seven Key Parameters

    1. T Token Weight : Weight of Token in the Pool
      • Tokens: T. Assume there are n type of tokens in one liquidity pool, we denote them as (T1,T2,... Tn).
      • weight parameter: Wi(0<=Wi<=1) is the parameter of token i in our model, which is a constant defined when creating the pool. We always assume the sum of Wi =1.
      • initial balance: (x1,x2,...,xn) are the initial amounts a liquidity provider puts into a liquidity pool.
    2. epsilon Fees : Liquidity Provider and Protocol Fees
    3. beta Depth : Depth of Pool before slippage occurs
    4. Delta Slippage: The rate at which price slippage increases
    5. Alpha Max Min: Maximum and Minimum Token allocation for each reserve
    6. lambda Dynamic fees : Unbalancing Penalty Fees
    7. k Market Price Alignment: Alignment of the Bonding Curve with Price Oracle

    Sunrise Bonding Curves The three types of bonding curves use the following variables

    3.1 MultiToken Bonding Curve (1,2)

    3.2 StableCoin Bonding Curve (1,2,3,4,5,6)

    3.3. Proactive Bonding Curve (1,2,3,4,5,6,7)

    There will be default values for each of these parameters based on the Bonding Curve Type.

    When not utilized the variable will be set to a default value having a nonconsequential effect.

    Sunrise Protocol Overviewโ€‹

    Sunrise Protocol is creating an open decentralized financial framework. Sunrise is building a complete suite of financial tools and non custodial services within a compliant framework . This will be done in a trustless decentralized environment. With the goal of disrupting and streamlining current solutions offered by Centralized Exchanges and International remittances.

    The following information is a short summary of the other features of the protocol

    Sunrise Bridge is used to create a multi-platform, multi-asset protocol using cryptocurrencies (tokens) as building blocks. We will start with Polkadot parachains, ERC-20 tokens and then other blockchains.

    Once the primitives of a multi-platform, multi-asset DEX have been realized, decentralized financial protocols can leverage this for their liquidity needs.

    Sunrise Protocol will then add limit orders, a compliance framework and smart wallet functionality to give cost effective alternatives to Centralized Exchanges and International remittances.

    Below are the high level modules that can be integrated into the Sunrise Ecosystem. A number of these will be implemented by our partners and the community, some of which may be subsidized by Sunrise Protocol grants.

    Sunrise Ecosystem

    Ecosystem Fitโ€‹

    Sunrise Protocol is building an open decentralized framework. This grant application is for the Sunrise DEX, a sub-component of the larger Sunrise Protocol.

    We have done a comprehensive review of the other DEX projects which include Polkaswap, Reef, Mangata, HydraDx, Polkadex, Subdex. We see there are gaps in the current DEX Approaches, these include stable coin support, limit order functionality and compliance functionality. We feel that these DEX projects cannot be leveraged as part of our protocol due to the mentioned gaps and the different technical approaches.

    We are the only protocol to offer multi-asset pools, optimized stable coin support, multiple bonding curves, adjustable transaction fees and limit orders. We combine this with bridging capabilities for multi-platform support, limit order capabilities, combinatorial staking for better rewards, synthetic asset support, a compliance framework and smart wallet functionality to drive mass adoption.

    This application is specific to the DEX Pallet and lays the foundation for the larger vision which can be seen in our draft white paper.

    DEX Evolutionโ€‹

    Sunrise Reference Protocols

    The following protocols offer specific functionality and are often leaders in their respective areas. The points below walk through a chronological evolution of DEX and cross-chain capabilities.

    • Uniswap introduced a simple bonding curve supporting two token liquidity pools.
    • It later introduced itโ€™s UNI token which is now table stakes for all Decentralized Exchanges, Sunrise Protocol extends this combining trading, protocol and liquidity balance rewards.
    • Multi Asset Pools were introduced by Balancer and adopted by Curve who introduced the first bonding curve to support stable coins.
    • Price Oracles being utilized by Automated Market Makers are being evaluated by Sunrise and DodoEx wrote a good white paper about the topic.
    • Sunrise protocol adds to this with multipe bonding curves which supports multi asset pools, stable coins, and traditional tokens.
    • Our Liquidity Providers can set the transaction fees when creating a Liquidity Pool similar to Balancer and Curve.
    • We also introduce limit orders powered by our unique off-chain worker capabilities.
    • Polkadot and Ethereum are supported initially with more platforms to come powered by our integrated bridging technology.
    • Reef and PolkaDex are also building on Polkadot which provides the ability to create dedicated parachains.
    • A Compliance Framework will be leveraged by Sunrise Protocol to provide cost effective solutions which compete with Centralized Exchanges and International remittances.
    • Smart Wallet Functionality will also be provided to simplify the user experience and drive mass adoption.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    John and Geoff will be the major contributors for this phase of Sunrise Protocol

    • John Whitton: Sunrise Protocol Founder
    • Geoff: Sunrise Protocol Core Protocol Engineer and Solution Architect

    Additional team members will be announced shortly and contributing to this and other components of Sunrise Protocol

    Contactโ€‹

    • Registered Address: N/A
    • Registered Legal Entity: N/A

    Team's experienceโ€‹

    The team all have strong experience building Layer 1 Blockchain Platforms and Decentralized Financial Protocols.

    Relevant Contributions are

    John Whitton: John Whiton has been passionate about software and technology since high school. He graduated from the University of Queensland in Computer Science and travelled globally leading the design and development of many Service Oriented Architectures. He has built private permissioned blockchains on Ethereum and Hypersphere Fabric, partnering with firms such as IBM and Deloitte. He then grew the ecosystem for a public blockchain at Harmony. He has worked extensively with decentralized financial protocols, bringing a unique perspective by combining his extensive corporate experience with IBM, SAP, Deloitte and KPMG with the disruptive financial models being developed on blockchain.

    John originally met Gavin Wood in 2016 and worked briefly with Tomasz Drwiฤ™ga on Parity before taking a role as CTO of a small Blockchain Startup based on Ethereum which then moved to Hyperledger. He did further research into Polkadot and Substrate in 2019 and did strategy work on smart contract protocols and digital assets in 2019 including working on Cowri (now shell protocol),a stablecoin exchange protocol, before taking a role with Harmony as an Ecosystem Architect with a focus on Developer tooling and Ecosystem growth. At Harmony, John helped launch the Mainnet while also being intimately involved with hiring decisions and business strategy. His technical Portfolio is here and more information can be found on johnwhitton.dev.

    Geoff: Prior to joining Sunrise Protocol where Geoff leads the SRS token design and works on core protocol development. Geoff worked as a Blockchain Engineer and Research analyst, leading technical due diligence on Decentralized Financial Protocols and Layer 1 Protocol offerings. He has reviewed thousands of whitepapers and tokenomics models. He has mentored many founders and blockchain startups and created investor briefings including strategy review, market fit and technical due diligence. Technical contributions include Decentralized Financial Protocols, Layer 2 Solutions, Decentralized Identity and encrypted data storage as well as protocol and infrastructure work such as consensus algorithms, sharding, smart contracts design and standards (Open Zeppelin). He has done extensive smart contract design and development with an in depth knowledge of decentralized financial protocols and tooling; including prototyping and development of DeFi Standards across multiple platforms.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    In this phase we plan to develop the initial decentralized exchange pallet for the Sunrise Protocol.

    This application is specific to the DEX Pallet and lays the foundation for the larger vision which can be seen in our draft white paper.

    Overviewโ€‹

    • Total Estimated Duration: 3 Months
    • Full-time equivalent (FTE): 2 FTE
    • Total Costs: 0.9 BTC

    Milestone 1: Framework design and minimal DEX Palletsโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 0.4 BTC
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how to create a liquidity pool and provision funds to it.
    0c.Testing GuideThe code will have proper unit-test coverage (e.g. 90%) to ensure functionality and robustness. In the guide we will describe how to run these tests.
    The tests will cover basic functionlity like
    i. Creating a Liquidity Pool
    ii. Adding and removing liquidity
    iii. Swapping based on exact amount in and exact amount out
    1.Multi-currency BaselineSupport Multiple Currencies being traded this will leverage and expand upon the following from FRAME and ORML
    FRAME:support:currency trait
    FRAME:pallet-balances
    orml-tokens
    orml-currencies
    2.Pallet: sunrise-dexWe will create a Pallet that will implement a simplified multi-token bonding curve.
    We will begin prototyping with a two token pool similar to uniswapV2Pair
    Then enhance to a multi-token-pool see balancer as a reference implementation
    2a.Liquidity Pool ManagementWe will create functions that will implement liquidity management samples included below
    Pool Creation
    Add liquidity
    Remove Liquidity
    Pool creation will be configurable based on the seven parameters mentioned above
    2b.Swap FunctionalityWe will create functions that will implement swap functionality including samples included below
    calcSpotPrice
    calcOutGivenIn
    calcInGivenOut
    calcPoolOutGivenSingleIn
    calcSingleInGivenPoolOut
    calcSingleOutGivenPoolIn
    calcPoolInGivenSingleOut
    Reference Implementation from Balancer
    2c.Sunrise RouterWe will create functions that will implement routing capabilities samples included below
    processPaths
    processEpsOfInterestMultiHop
    getPricesOfInterest
    calculateBestPathIdsForPricesOfInterest
    getSwapAmountsForPriceOfInterest
    getExactSwapAmounts
    Reference Implementation from Balancer
    3.Substrate chainWe will Host this on our Dawn Parachain on Rococco or our Daybreak Standalone Chain
    4.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain

    Milestone 2: Full version of SRS modelโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 0.3 BTC
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how to create a liquidity pool and provision funds to it.
    0c.Testing GuideThe code will have proper unit-test coverage (e.g. 90%) to ensure functionality and robustness. In the guide we will describe how to run these tests.
    Tests will include
    i. Creating a stable coin pool
    ii. Adding and removing liquidity
    iii. Swaps
    iv.Rewards staking and earning
    v. Testing functionalitly using explorer Extrinsics
    1.Pallet: sunrise-dexWe will enhance the sunrise factory to support a stable coin bonding curve.
    Reference implementations include curve and shellprotocol
    2.Pallet: sunrise-rewardsWe will create a Pallet that will implement basic reward functionality.
    Reference implementations include uniswap, balancer and sushiswap
    4.Substrate chainWe will Host this on our Dawn Parachain on Rococco or our Daybreak Standalone Chain
    5.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain

    Here is an overview of the Sunrise Reward design

    Sunrise Rewards Design

    Milestone 3: Sunrise DApp on Test Networkโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 0.2 BTC
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can deploy the Sunrise Protocol DApp and the polakdot-js app forked by Sunrise Protocol with DEX Capabilities.
    0c.Testing GuideThe code will have proper unit-test coverage (e.g. 90%) to ensure functionality and robustness. In the guide we will describe how to run these tests.
    Tests will include
    i. Testing all functions via explorer using extrinsics
    ii. Testing functionality via the DApp
    1.Polkadot-js app DEX CapabilitiesWe will fork polkadot-js app and provide dex functionality
    2.Sunrise Protocol DAppWe will build Sunrise Protocol DApp with DEX Functionality
    3.Applications Deployed and Hosted on DawnWe will deploy a hosted application that connects to Dawn.
    4.Substrate chainWe will Host this on our Dawn Parachain on Rococco or our Daybreak Standalone Chain
    5.Community EducationWe will publish Medium Articles in English and Chinese and also posts on twitter. Explaining the DEX Functionality.

    Future plansโ€‹

    We plan to make our chain one of the leading parachains in the polkadot ecosystem. Thus, there is still a lot of work to be done. Here are a few of them:

    1. Support for Multi-Currencies via INK or EVM conforming to psp-3
    2. Enhance Deployment capabilities of the Sunrise DEX for other chains (either as an ORML module or as an INK Contract)
    3. Implement SRS Incentivization Functionality
    4. Bridging Functionality (XCMP Parachain Integration and Ethereum snowfork like integration)
    5. Sunrise Order Book and Limit Order Functionality
    6. Application Functionality (Sunrise Dapp, polkadot-js apps, wallet)
    7. Governance model using SRS
    8. Parachain Functionality (Launching on Rococco initially)
    9. Proactive Bonding curve integrated with price oracles
    10. Compliance Framework
    11. Smart Wallet Functionality
    12. Governance model using SRS

    Additional Informationโ€‹

    Work done so far has included research and prototyping.

    No other teams have contributed to the project.

    This is Sunrise Protocol's first grant application. However John wrote a previous application for a DEX Pallet. The original application has been archived and the vision has been refined based on feedback from David Hawig and knowledge gained working on substrate over the past months by the Sunrise Protocol team.

    For a more comprehensive Sunrise Protocol Vision please read the following

    Here is an overview of the Sunrise Order Book design

    Sunrise Reference Protocols

    - + \ No newline at end of file diff --git a/applications/sunshine-keybase.html b/applications/sunshine-keybase.html index dcec46cb152..0226f86a7e6 100644 --- a/applications/sunshine-keybase.html +++ b/applications/sunshine-keybase.html @@ -4,13 +4,13 @@ Sunshine Keybase | Web3 Foundation Grants - +
    Skip to main content

    Sunshine Keybase

    • Proposer: 4meta5
    • Payment Address: 16uCivZhPAy4RiK5ZA1TEMo6Xq5pGTh4BA

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    sunshine-keybase implements Keybase's Local Key Security to associate a set of keys with a UID and manage this set of keys to sign and authenticate messages on the user's behalf. The implementation uses a Substrate runtime to enforce the rules of interaction with the keystore, especially as it pertains to revoking keys for a provisioned storage device.

    The project provides a usable keystore for local first applications using substrate. The sunshine-identity pallet provides structure to control a set of keys with a UID and track storage metadata associated with the given UID. The client uses ipfs-embed to store sensitive data offchain and encrypted on the local hardware. The sunshine-chain pallet uses the same stack to coordinate storage of chain data amongst a closed set of clients.

    We believe sunshine-keybase provides a reusable identity architecture for other projects in the Web3 space. Moreover, the sunshine-chain client and pallet demonstrate minimal design to set and enforce the storage of offchain data among a permissioned set of clients. This infrastructure will prove useful to substrate projects that need to coordinate and enforce private network storage of data offchain.

    Project Detailsโ€‹

    The project includes two pallets and a Flutter UI for Android.

    Chain Palletโ€‹

    The chain module is a reusable abstraction for building private proof of authority chains using ipfs and using substrate to provide authorization and consensus on the current head of the chain. When authoring a block on ipfs a race condition can occur. Due to substrate providing a total order of transactions only one transaction will succeed in updating the head of the chain, the other client will create a new block on the head of the chain and retry the failed operation.

    chain_module.svg

    Keybase Palletโ€‹

    The keybase identity module manages the user's chain that stores the user key, device keys, password and social media accounts using the sunshine chain pallet. Private data shared between devices is encrypted with the user private key. When a new device is provisioned a key is generated locally on the device, and a provisioning protocol is used to communicate between the new device and the provisioning device.

    keybase-module.svg

    Password changes are stored encrypted in the user chain. When a device receives a block with a password change it reencrypts it's local device key using the new password. This ensures that the user only needs to remember one password.

    Social media accounts are linked to a chain account, by submitting a proof in the social media profile and on the user's chain. Other users can find the on chain account on the social media page and verify that they are both controlled by the same cryptographic identity. This allows us to use github usernames as aliases without compromising the decentralized nature or security that blockchains provide. While resolving the social media account to an on chain identity requires the service to be online, already resolved identities are stored locally. This means that even if github is offline, transfers to already verified github accounts can be performed.

    Flutter Android UIโ€‹

    The Flutter UI allows Android users to initialize a local keystore and device identity using the sunshine-identity pallet. It allows the user to initialize the keystore, set a passphrase, and change the passphrase. The UI also allows the user to paste links to github gists to prove ownership of github accounts.

    Ecosystem Fitโ€‹

    There are other approaches to creating an identity graph, but we have yet to find another substrate project that implements device-oriented key revocability. The native keystore leverages ipfs-embed to store sensitive data in an encrypted form on the local hardware. Over time, we expect ipfs-embed to evolve with the needs and requirements of users.

    The current design coordinates the storage of private offchain data on permissioned client networks. Our project will use this identity infrastructure for sharing encrypted messages and backing up encrypted files, privately and within teams with membership tracked transparently on-chain.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Team Websiteโ€‹

    Sunshine Systems LLC

    16192 Coastal Highway, Lewes, Delaware 19958, County of Sussex

    Team's experienceโ€‹

    Amar started and maintained the Substrate Recipes as an employee at Parity. He wrote the sunshine-bounty runtime, node, client, and CLI under Sunshine's first grant. He is an experienced substrate runtime developer.

    David worked on substrate core development as an employee at Parity. He is the lead maintainer of ipfs-embed and contributes upstream often to substrate-subxt to meet Sunshine's Rust client requirements.

    Shady is an experienced Typescript, Flutter, and Rust developer with contributions to many open source projects (i.e. nest-access-control). He is a pioneer in Rust-Dart FFI development with generic components released alongside his work on the Sunshine Flutter infrastructure i.e. flutterust.

    Team Code Reposโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    There is only one milestone.

    Milestone 1 โ€” Sunshine-Keybase + UIโ€‹

    • Estimated Duration: 6 weeks
    • FTE: 2
    • Costs: 1.5 BTC
    NumberDeliverableSpecification
    0a.LicenseUnlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that shows how to run the local dev node alongside the Flutter UI to register and manage a sunshine-identity on a local network.
    0c.Testing GuideThe client will have substrate-subxt integration tests that verify behavior at the network level to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    1.Substrate module: ChainWe will create a pallet that allows a closed set of signers to build private proof of authority chains using ipfs and substrate. These chains consists of private data shared among the closed set.
    2.Substrate module: IdentityWe will create a pallet that uses the Chain module to manage data relevant to the registered identity. This module adds more granular management when storing the user key, device keys, password and social media accounts.
    3.Flutter UIWe will write a Flutter UI that communicates directly between our Rust substrate-subxt client and our Flutter interface to express the user identity configuration interface.
    4.Substrate chainFlutter UI works with local node to enable identity registration, password reset, and github authentication.
    5.DockerWe will provide a dockerfile to demonstrate the full functionality of our chain

    Community engagementโ€‹

    We will publish an article on dev.to upon completion.

    Future Plansโ€‹

    Sunshine Chain will launch in Q1 2021. We are continuing to build infrastructure that is useful for the interchain community as well as other individual substrate chains.

    Past Workโ€‹

    We wrote a blog post listing open source contributions funded by our first Web3 grant. Highlights include

    • 7 governance pallets, configured into a runtime and node to express a Substrate DAO Chain
    • Rust client and CLI for interacting with the node
    • substrate-subxt contributions to support native Rust clients and light clients (w/ 2 Parity projects now using substrate-subxt for this purpose -- ledgeracio, cargo contract)
    • Rust client which uses ipfs-embed for storage of data not necessary for Substrate runtime storage
      • including tooling around ipfs-embed to facilitate error handling and improve the overall API
    • Rust-Dart FFI to call Rust client code from Flutter Dart User Interface
      • with intermediate infrastructure open sourced for the wider Rust and Flutter ecosystems
      • native keystore supports modern key management i.e. key rotation
    - + \ No newline at end of file diff --git a/applications/sup.html b/applications/sup.html index 63939adf723..cd536dce2c6 100644 --- a/applications/sup.html +++ b/applications/sup.html @@ -4,14 +4,14 @@ Sup | Web3 Foundation Grants - +
    Skip to main content

    Sup

    • Proposer: clearloop
    • Payment Address: 1NKWsqRaWZDNX17cuzfyykcAA317njqzSn

    Project Overview ๐Ÿ“„โ€‹

    sup is a substrate package manager using git, it allows developer new node-template and upgrade substrate dependencies in one comamnd.

    Hope this project can help more and more developers to join the ecosystem.

    Team ๐Ÿ‘ฅโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 2 days
    • Full-time equivalent (FTE): 0.285
    • Total Costs: 0.1 BTC

    Milestone 1 โ€” Generate Node-Template in one commandโ€‹

    • Estimated Duration: 1 day
    • FTE: 0.285
    • Costs: 0.05 BTC

    Just run:

    $ cargo install sup
    $ sup new <node-template>
    $ cd <node-template> && cargo build

    And it will work.

    NumberDeliverableSpecification
    0sup new <node-template>New node-template in one command
    1sup updateUpdate sup registry
    2sup source --query <pattern>List substrate dependencies with versions
    3sup tag --limit <n>List avaiable registry tags

    Milestone 2 โ€” Upgrading Substrate depencidencies in one commandโ€‹

    • Estimated Duration: 1 day
    • FTE: 0.285
    • Costs: 0.05 BTC

    Run: 

    $ sup upgrade --tag <substrate-tag> --registry <substrate-based-registry>
    • Upgrades the registry of substrate by tag for the current project.
    • Supports customize subtrate registry(including substrate-based registry)
    NumberDeliverableSpecification
    0sup new <node-template> --tag <t> --registry <r>New node-template with specified tag and registry
    1sup update --registry <r>Update target registry
    2sup source --tag <t> --registry <r>List substrate dependencies with versions
    3sup tag --registry <r>List avaiable tags of target registry
    4sup upgrade --tag <t> --registry <r>Upgrade current project to the target or latest tag of the current or target registry

    Community engagementโ€‹

    The tutorials and Documentation that we provide will be published as articles in Medium, rust.cc and other social media platforms with due mention about Web3 grant.

    - + \ No newline at end of file diff --git a/applications/supersig_fellowship.html b/applications/supersig_fellowship.html index ffc5097ac2a..39991bbd802 100644 --- a/applications/supersig_fellowship.html +++ b/applications/supersig_fellowship.html @@ -4,7 +4,7 @@ Supersig | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ Here is a recent contribution from Ramsey in a Substrate Seminar

    Nathan Gardet-Derc (erudyx) - Substrate / Rust Engineer, contributor to Kabocha, Rusty Crewmate. developer on pallet_supersig. Alumni of Polkadot Blockchain Academy

    Tsubasa Mori (KingdomParadise) - Full stack developer - Javascript / Typescript / React / Rust / Node.js / Next.js

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    pallet started here: https://github.com/kabocha-network/pallet_supersig/tree/polkadot-v0.9.37

    *Supersig is functional, accessible and usable for developers to integrate and for their end users.

    Development Roadmap ๐Ÿ”ฉโ€‹

    This section should break the development roadmap down into milestones and deliverables. To assist you in defining it, we have created a document with examples for some grant categories here. Since these will be part of the agreement, it helps to describe the functionality we should expect in as much detail as possible, plus how we can verify and test that functionality. Whenever milestones are delivered, we refer to this document to ensure that everything has been delivered as expected.

    Below we provide an example roadmap. In the descriptions, it should be clear how your project is related to Substrate, Kusama or Polkadot. We recommend that teams structure their roadmap as 1 milestone โ‰ˆ 1 month.

    For each milestone,

    Milestone 1 To make changes to pallet_supersig and apps frontend so that it is up to scratch with system chain level use, accepted by polkadot-js apps, and prepared for Fellowship review.

    Details for pallet:

    We will likely be making a limit on call data size and a cap on the number of "live proposals" there can be per chain.

    Limit Call Data Sizeโ€‹

    1. Limit call data size: Introduce a maximum call data size limit in the configuration trait. This limit can be set to a reasonable default value, which can be changed as required. Users will be prevented from submitting call data exceeding this limit:
    #[pallet::config]
    pub trait Config: frame_system::Config {
        // ...
        /// The maximum size of call data allowed (in bytes).
        #[pallet::constant]
        type MaxCallDataSize: Get<u32>;
        // ...
    }
    1. Check call data size: Before storing the call data in create, approve, and other relevant functions, ensure that its size is within the specified limit.
    // In the `create` function
    ensure!(
        call_data.len() <= T::MaxCallDataSize::get() as usize,
        Error::<T>::CallDataTooLarge
    );

    // Similarly, add checks in the `approve` and other relevant functions.

    1. Add a new error variant for oversized call data:
    #[pallet::error]
    pub enum Error<T> {
        // ...
        /// The call data size exceeds the maximum allowed limit.
        CallDataTooLarge,
        // ...
    }

    Limit Number of Live Proposalsโ€‹

    1. Add the LiveProposalMaximum associated type to the pallet's Config trait:
    pub trait Config: frame_system::Config {
        // ...
        type LiveProposalMaximum: Get<u32>;
        // ...
    }
    1. Add a storage item to track the number of active proposals for each Supersig account:
    #[pallet::storage]
    #[pallet::getter(fn active_proposals)]
    pub type ActiveProposals<T: Config> = StorageMap<_, Twox64Concat, SupersigId, u32, ValueQuery>;
    1. Modify the submit_call extrinsic to check the number of active proposals before allowing a new one:
    #[pallet::weight(T::WeightInfo::submit_call())]
    pub fn submit_call(origin: OriginFor<T>, supersig_id: SupersigId, call_data: Vec<u8>) -> DispatchResultWithPostInfo {
        let who = ensure_signed(origin)?;
        // ...

        let current_active_proposals = Self::active_proposals(supersig_id);
        ensure!(current_active_proposals < T::LiveProposalMaximum::get(), Error::<T>::TooManyActiveProposals);

        // ...
    }
    1. Increment the number of active proposals for the Supersig account when a new proposal is submitted:
    ActiveProposals::<T>::mutate(supersig_id, |active_proposals| *active_proposals += 1);
    1. Add an error variant for the case when there are too many active proposals:
    #[pallet::error]
    pub enum Error<T> {
        // ...
        TooManyActiveProposals,
    }
    1. Decrement the number of active proposals when a proposal is approved or rejected. You can do this in the approve and reject extrinsics:
    ActiveProposals::<T>::mutate(supersig_id, |active_proposals| *active_proposals = active_proposals.saturating_sub(1));

    As a non binding idea to test, we shall also be exploring the idea of enabling off-chain signing, though this will require a lot of refactoring:

    Enable off-chain signing (optional work)โ€‹

    To incorporate off-chain signing in the supersig pallet while maintaining the same features such as adding and removing members, we would need to do the following:

    1. Create a CallHash type alias to represent the hash of the call data:
    pub type CallHash<T> = <T as frame_system::Config>::Hash;
    1. Change the CallData storage item to use the CallHash instead of the actual call data:
    #[pallet::storage]
    #[pallet::getter(fn call_data)]
    pub type CallData<T: Config> = StorageMap<_, Twox64Concat, SupersigId, CallHash<T>, OptionQuery>;
    1. Modify the create and approve functions to accept a call_hash parameter instead of the call data:
    pub fn create(origin: OriginFor<T>, call_hash: CallHash<T>, ...);
    pub fn approve(origin: OriginFor<T>, call_hash: CallHash<T>, ...);
    1. In the create and approve functions, calculate the call hash and ensure it matches the provided call_hash parameter:
    // In the `create` function
    let actual_call_hash = T::Hashing::hash_of(&call_data);
    ensure!(
        actual_call_hash == call_hash,
        Error::<T>::InvalidCallHash
    );
    // as well add the check in the `approve` function.
    1. Add a new error variant for mismatched call hashes:
    #[pallet::error]
    pub enum Error<T> {
        // ...
        /// The provided call hash does not match the actual call hash.
        InvalidCallHash,
        // ...
    }
    1. Update the extrinsics and RPCs to work with call hashes instead of call data.

    Refactor Page-Supersig UI for polkadot js fork

    Milestone 2 Custom UI foundation MVP, and act on feedback from Fellowship.

    โšก If any of your deliverables is based on somebody else's work, make sure you work and publish under the terms of the license of the respective project and that you highlight this fact in your milestone documentation and in the source code if applicable! Teams that submit others' work without attributing it will be immediately terminated.

    Overviewโ€‹

    Milestone 1 โ€” pallet_supersig MVPโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation of the supersig pallet's code, and a basic tutorial that explains how a user can spin up one of our Substrate nodes and send test transactions, which will show how the supersig functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains supersig pallet to developers on a blog post; and a substrate workshop/seminar that explains that shows how the pallet was designed (if there available slot, else a video shared on loom/youtube).
    1.Substrate module: pallet_supersigWe will refactor the pallet so that it does not store unbounded call data.
    2.Supersig-app: polkadot-js-uiWe need to make various changes and use a lot of polkadot js hooks in order Jaco to accept the PR: refactoring converting a lot of hooks to be the native polkadot-rs hooks rather than our own hooks; linting; changing augment-types; linting, and 300 errors when building for the polkadot-js PR.
    3.BenchmarkingThe pallet will be benchmarked and unit tested using worst case weightings.

    Milestone 2 โ€” Supersig UI and feedback from Fellowshipโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation and a tutorial with a polkadot-js apps fork that guides a developer to simply set up supersig pallet and UI.
    0c.Testing messagesCore functions will be fully covered by e2e testing guide and informative error messages.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with milestone 2. The dockerfile will be a polkadot JS UI fork, it will also be the smallest possible file size (MBs not GBs)
    0e.ArticleWe will publish an article that explains supersig pallet to the end-user. The article will be on medium and subsocial.
    1.React/Typecript: Supersig UIWe will build a custom user interface so that users can interact with supersig.
    2.Substrate chainWe will create a custom substrate template that will contain pallet supersig
    3.Polkadot JS Apps UI ForkWe will add the custom feature to a polkadot JS UI fork (and make a PR to the main repo), so that the user can see the pallet in action, end to end.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    Who can vouch for Ramsey(Decentration)? Josh Muir (Kusama Council and Dat Dot), Dan Shields, Will Chevdor, Sacha Lanski...

    - + \ No newline at end of file diff --git a/applications/tdot.html b/applications/tdot.html index 7356117ae60..7422eeffaa9 100644 --- a/applications/tdot.html +++ b/applications/tdot.html @@ -4,13 +4,13 @@ tDOT | Web3 Foundation Grants - +
    Skip to main content

    tDOT

    • Team Name: NUTS Finance
    • Payment Address: 0x679824d755B054a2a50358008472a6F400740319(DAI)
    • Level: 2
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    This application is a follow-up of the Stable Asset grant.

    Overviewโ€‹

    DOT serves three distinct purposes in Polkadot: governance, staking and bonding. These critical functions have increased DOT's demand but also segregated DOT's liquidity across multiple applications.

    Several parachains and protocols arise to enhance DOT's capital efficiency, which includes:

    • Staked DOT, e.g. Acala's LDOT and Parallel's xDOT
    • Crowdloan DOT, e.g. Acala's LCDOT and Moonbeam's stDOT

    These DOT derivatives, which represents different forms of DOT across the Polkadot network, further spread out DOT's liquidity. DOT's liquidity fragementation has caused several crucial issues:

    • Each DOT derivative need to bootstrap their own liquidity and find a stable pricing
    • Polkadot application builders need to support multiple forms of DOT assets

    These hurdles are extremely difficult to overcome, given Polkadot network liquidity is still relatively low. tDOT aims at solving these issues by generating unified DOT liquidity across Polkadot applications.

    Project Detailsโ€‹

    tDOT is a DOT-pegged derivative built on top of the stable asset protocol.

    Stable asset is based on Curve's stable swap algorithm and is back by a pool of assets with the same peg. It utilizes traders to dynamically rebalance pool composition while maintaining a consistent pool value, thus generating a synthetic asset whose peg is much stronger than any of the underlying assets.

    taiKSM is the first KSM-pegged derivative deployed on the Dotsama ecosystem. It aggregates liquidity from KSM and Acala's LKSM to generate unified KSM liquidity in Karura.

    image

    tDOT extends the idea of taiKSM to provide unified DOT liquidity over the whole Polkadot network. Its architecture is shown above:

    • For each xDOT, a separate xDOT-DOT stable swap pool is created on the parachain where xDOT is native;
    • Each xDOT-DOT pool can mint and burn tDOT on parachain A which is tDOT's hosting chain;
    • If xDOT is not on parachain A, e.g. cDOT and dDOT, xDOT-DOT pool uses XCM to mint and burn tDOT.

    Each xDOT-DOT pool is a trading pair between xDOT and DOT. It allows a dynamic trading range between xDOT and DOT but ensures the value of pool derivative is pegged to DOT. Each xDOT represents a different form of 1 DOT in Polkadot network. According to the stable asset algorithm, when the exchange rate between xDOT and DOT trades at 1:1, tDOT is 100% collateralized and is backed by exactly 1 DOT. When the exchange rate shifts, tDOT is over-collateralized and the collateral ratio increases as the exchange rate shifts further. Each xDOT-DOT pool can control how fast the collateral ratio increases with its own parameter values.

    Since each xDOT-DOT pool can maintain pegging of its own pool derivative, it's a natural choice to unify these pool derivatives into a single tDOT. This brings extra benefits:

    • It ensures a single tDOT and it can be bridged to any parachain;
    • It unifies all xDOTs over the Polkadot network. New xDOT assets can be included by deploying new xDOT-DOT pool on their native chains;
    • It provides sufficient application scenarios for each xDOT. Other than the xDOT-DOT swap, it allows xDOT holders to mint and use tDOT in DeFi applications;
    • It can be used as cross-chain swap medium. Assume that bDOT is native in parachain B and cDOT is native in parachain C. Users can mint tDOT with bDOT and then redeem tDOT to cDOT. This user effectively swaps bDOT on parachain B to cDOT in parachain C.

    Ecosystem Fitโ€‹

    tDOT will be minted on a single parachain which is the hosting parachain for tDOT. It can be migrated to a different parachain or even a dedicated parachain. The hosting parachain can deploy its own xDOT-DOT pools so that tDOT is minted locally.

    Any other parachains such as Acala and Parallel which have their own native DOT derivatives can deploy xDOT-DOT pools on their own chains and mint tDOT on the hosting chain as remote minters. Their benefits include:

    • The xDOT-DOT pool provides a stable swap between xDOT and DOT;
    • The xDOT-DOT liquidity is locked in its original chain while minting tDOT so the parachains can retain its TVL;
    • The minted tDOT can be bridged to other chains other than the hosting parachain. For example, the minted tDOT can be bridged back to Parallel and be used as collateral of Parallel's lending applicaiton.

    For the whole Polkadot network, a standardized DOT derivative can service the entire Polkadot ecosystem; it can unify all forms of DOT liquidity and unleash maximum usability for DOT across Parachains.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Daniel Tang, Co-founder
    • Terry Lam, Co-founder
    • Shengda Ding, Co-founder

    Contactโ€‹

    • Registered Address: PO Box 309, Ugland House, Grand Cayman, KY1-1104, Cayman Islands
    • Registered Legal Entity: ACoconut

    Team's experienceโ€‹

    NUTS Finance is a blockchain development DAO. Our team is composed of experienced developers, financiers and serial entrepreneurs. We build open source, secure and composable technology solutions to empower developers and financial services providers to launch decentralized financial applications on the blockchain.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4 weeks
    • Full-Time Equivalent (FTE): 2
    • Total Costs: 14,000 DAI

    Milestone 1 โ€” Stable Asset XCM Palletโ€‹

    • Estimated duration: 1 week
    • FTE: 2
    • Costs: 4,000 DAI

    Stable Asset XCM pallet is a new module which will be deployed in the host chain only. It manages balances and limits for each individual stable asset pools and acts as the portal to mint and redeem tDOT.

    Stable asset LPs will be divided into two layers:

    • Local LP, which is the LP of individual stable asset pools and managed by stable asset pallet;
    • Aggregate LP, which is the LP generated by local LPs and managed by stable asset XCM pallet.

    image

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationProvide documentation on the architecture of tDOT.
    0c.TestingProvide comprehensive tests that covers stable asset pool management functionalities.
    0d.DockerProvide a Docker image with Substrate chain that demonstrate this project.
    1.Substrate module: Stable Asset XCMThe stable asset XCM module tracks and manages individual stable asset pools across multiple parachains. It tracks balances of each stable asset pools in each parachain and sets mint limits for each pool.

    Milestone 2 โ€” tDOT Mintingโ€‹

    • Estimated duration: 2 weeks
    • FTE: 2
    • Costs: 5,000 DAI

    This milestone implements minting tDOT both locally on the host chain and remotely on the guest chains. In either case, minting is triggered in the stable asset pallet.

    image

    image

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationProvide documentation on the architecture of tDOT and flow diagrams of tDOT minting process.
    0c.TestingProvide comprehensive tests that covers minting tDOT locally in host chain and remotely in guest chain.
    0d.DockerProvide a Docker image with Substrate chain that demonstrate this project.
    1.Substrate module: Stable Asset PalletUsers can mint tDOT on stable asset pallet with underlying asset or with local LP. If minting fails in host chain, the whole extrinsic is reverted. If minting fails in guest chain, user will get local LP.
    2.Substrate module: Stable Asset XCM PalletHandles the actual aggregate LP minting. It accepts XCM mint request from guest chain with local LP, and sends back XCM message if minting fails due to mint limit exceeds.

    Milestone 3 โ€” tDOT Redeemingโ€‹

    • Estimated duration: 2 weeks
    • FTE: 2
    • Costs: 5,000 DAI

    This milestone implements redeeming tDOT on host chain.

    image

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationProvide documentation on the architecture of tDOT and flow diagrams of tDOT redeeming process.
    0c.TestingProvide comprehensive tests that covers redeeming tDOT to host chain or to guest chains.
    0d.DockerProvide a Docker image with Substrate chain that demonstrate this project.
    0e.ArticleWe will publish an article that explains the architecture of tDOT and how minting and redeeming tDOT works. The article will discuss potential attack vectors of tDOT and how does tDOT addresses it.
    1.Substrate module: Stable Asset XCM PalletHandles the aggregate LP redeeming request, eitehr in proportion or to a single asset. If redeeming to a local stable asset pool fails, the whole extrinsic is reverted. If redeeming to a remote stable asset pool fails, users will get local asset on the guest chain instead.

    Future Plansโ€‹

    We will upgrade taiKSM to tKSM with similar architecture shortly after the launch of tDOT.

    - + \ No newline at end of file diff --git a/applications/tokenomics-survey-2022.html b/applications/tokenomics-survey-2022.html index 6e1bdda4b56..2bec4cfca04 100644 --- a/applications/tokenomics-survey-2022.html +++ b/applications/tokenomics-survey-2022.html @@ -4,7 +4,7 @@ Tokenomics Scoping Review: Annotated Bibliography | Web3 Foundation Grants - + @@ -29,7 +29,7 @@ Initial flow-chart/decision-tree development that will help developers place their token in the following contexts:

    NumberDeliverableSpecification
    0a.Copyright and LicensesCreative Commons Attribution 4.0 International License (article), Dual Apache 2 or MIT License (code)
    0b.Documentation/TutorialWe will provide both artifacts documentation of the deliverables and a basic tutorial that explains how a user can (for example) execute the code included or can visualize data or use any artifacts included.
    0c.MethodologyDetailed explanation of how the results were achieved and how to reproduce/verify the results.
    0d.InfrastructureWe will provide the list of all infrastructure requirements (text editors with proper versions, software packages, data packages, etc) that can be used to verify the deliveries with this milestone. LaTeX for article production.
    0e.ArticleWe create a draft article (with source code), in the English language. There will be an acknowledgement "This work was supported by a research grant from the Web3 Foundation. The analysis and opinions expressed are the authors and do not reflect the opinions of the Web3 Foundation."
    0e.1- Appendix: MethodologyAs described in the methodology section above
    0e.2- Section: Polkadot ParachainsInitial Parachain summary
    1.List of academic papersCollect published and network papers, as described in the methodology section above
    2.Data to be extracted from the papersAs described in the methodology section above
    3.Analysis proceduresAs described in the methodology section above

    Milestone 2 โ€” Outline Articleโ€‹

    NumberDeliverableSpecification
    0a.Copyright and LicensesCreative Commons Attribution 4.0 International License (article), Dual Apache 2 or MIT License (code)
    0b.Documentation/TutorialWe will update both artifacts documentation of the deliverables and a basic tutorial that explains how a user can (for example) execute the code included or can visualize data or use any artifacts included.
    0c.MethodologyUpdate the detailed explanation of how the results were achieved and how to reproduce/verify the results.
    0d.InfrastructureWe will update the list of all infrastructure requirements (text editors with proper versions, software packages, data packages, etc) that can be used to verify the deliveries with this milestone. LaTeX for article production.
    0e.ArticleWe will send a draft article (with source code), in the English language. There will be an acknowledgement "This work was supported by a research grant from the Web3 Foundation. The analysis and opinions expressed are the authors and do not reflect the opinions of the Web3 Foundation."
    0e.1ArticleWe will publish an working paper as indicated above.
    0e.2- Section: Published modelsInitial annotated bibliography
    0e.3- Section: Polkadot Parachain EconomiesParachain summary updated with references to published models

    Milestone 3 โ€” Finalize Articleโ€‹

    Finalize the flow-chart/decision-tree that will help developers place their token in the following contexts:

    Finalize the annotated bibliography. Promote the working paper, incorporate feedback. The report/working paper will be posted to SSRN (e.g. FEN - Cryptocurrency Research eJournal), IDEAS, ResearchGate.

    NumberDeliverableSpecification
    0a.Copyright and LicensesCreative Commons Attribution 4.0 International License (article), Dual Apache 2 or MIT License (code)
    0b.Documentation/TutorialWe will update both artifacts documentation of the deliverables and a basic tutorial that explains how a user can (for example) execute the code included or can visualize data or use any artifacts included.
    0c.MethodologyUpdate the detailed explanation of how the results were achieved and how to reproduce/verify the results.
    0d.InfrastructureWe will update the list of all infrastructure requirements (text editors with proper versions, software packages, data packages, etc) that can be used to verify the deliveries with this milestone. LaTeX for article production.
    0eArticleWe will update a draft article (with source code), in the English language. There will be an acknowledgement "This work was supported by a research grant from the Web3 Foundation. The analysis and opinions expressed are the authors and do not reflect the opinions of the Web3 Foundation."
    0e.1- Section: IntroductionPlace the topic in perspective and motivate non-specialist readers. Text and tables where relevant/appropriate.
    0e.2- Section: Published modelsUpdate annotated bibliography
    0e.3- Section: Polkadot ParachainsParachain summary updated with references to published models
    0e.4- Appendix: MethodologyThe research methodology. Text and tables where relevant/appropriate.
    0e.5- Section: SummaryWhere are we and where to next?
    1.FeedbackCollect published, working and network papers, as described in the methodology section above
    2.PublishThe working paper will be posted to SSRN (e.g. FEN - Cryptocurrency Research eJournal), IDEAS, ResearchGate

    Future Plansโ€‹

    Please include here

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/tracking_chain.html b/applications/tracking_chain.html index 80b5a5114c8..ae9391842f1 100644 --- a/applications/tracking_chain.html +++ b/applications/tracking_chain.html @@ -4,13 +4,13 @@ Tracking Chain | Web3 Foundation Grants - +
    Skip to main content

    Tracking Chain

    • Team Name: Federico Cicciarella
    • Payment Address: 15ofeBpTMQ7MNbqViRRRbkVz2y3eQt8SCgBy6yVVfsTKhMn2 (USDT)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    During this time, I have had the opportunity to work with several companies that wanted to adopt blockchain technology. However, I have observed that they often face challenges that hinder their adoption, mainly due to the following reasons:

    • Difficulties integrating legacy software with blockchain, such as dealing with long confirmation times or scalability issues when handling a large number of transactions. I have personally spoken with clients who need to handle over a million transactions per year, with peaks of thousands of requests per minute.

    • Concerns regarding wallet security, custody, accounting management, and the purchase of tokens for transaction fees.

    • Challenges in querying the blockchain to retrieve or interpret transactions over time, lacking a user-friendly interface.

    • High cost of using the blockchain (those who are not familiar with the blockchain world have heard of ethereum and how much it costs to do operations on it)

    There is a significant market potential for smart contracts, such as tracking the lifecycle of a product or certifying the immutability of sensitive files, among other use cases. While these challenges may seem trivial, integrating existing and well-tested software with experimental projects like blockchains (this is the common thinking of web2 companies) often leads to insurmountable issues, resulting in project abandonment.

    Our project offers an intuitive and user-friendly tool to simplify blockchain integration for all businesses.

    We are aware of the interest expressed by various companies in using blockchain technology, and we want to demonstrate how easy and advantageous it is to integrate blockchain into their business processes.

    We aim to convey that adopting blockchain is no longer a complex and costly process but can be accomplished effortlessly with our intuitive tool, leveraging the scalability capabilities of Polkadot and its Parachains.

    Our ultimate goal is to help companies embrace the benefits offered by blockchain, opening the doors to a new way of doing business. We firmly believe that our project can be a turning point for widespread adoption of blockchain in the corporate sector, simplifying the integration process and providing a seamless and positive experience.

    We have already scheduled several demos with our clients, including one that has requested a demonstration of how to support a high number of transactions launched within a short timeframe and how to effectively manage them.

    The client's request highlights the importance of efficient transaction management in a high-volume blockchain environment.

    Furthermore, we will illustrate our transaction management strategies that enable fair and optimized resource allocation, avoiding overload issues and ensuring a continuous flow of operations.

    Overviewโ€‹

    To address these challenges, I have decided to create a web application specifically designed for companies and users who are eager to venture into the world of blockchain. The application aims to bridge the gap between "Web2" and "Web3" by providing a simple API call to feed data into smart contracts, with an immediate response providing a unique identifier.

    To achieve this, I am developing a microservices architecture capable of handling millions of requests and scaling to accommodate peak traffic. Over the years, I have gained significant experience in building such systems, including a web application that processed tens of thousands of daily orders (including data-heavy files like photos for immediate printing) and effectively scaled during peak periods (e.g., the holiday season).

    My plan involves creating an endpoint that can be accessed from Web2, exclusively responsible for collecting data values to be inserted into a smart contract. Currently, I am focusing on storing key-value pairs; however, I intend to dynamically handle more complex cases in the future. In this way, the Web2 user will be relieved of any concerns regarding the bottleneck presented by the blockchain, as their task will already be completed (which we address through our bridge development), we can manage an unlimited number of requests per second, ensuring a smooth user experience. Upon successful transaction completion, we will send a registration notification to the customer, including all relevant onchain transaction data. Additionally, we will provide a graphical tool enabling users to verify their transactions onchain, ensuring transparency and data correctness.

    The application will handle all the necessary infrastructure setup for transaction transmission, including endpoint creation, failed transaction recovery, private key security, among others. The customer's role will be to select the appropriate smart contract type and chain for deployment, based on their future needs. For instance, in the future, certain data inputs may generate NFTs representing the final products, which could be utilized in other contexts through interoperability. Please note that this initial idea will not be present in the alpha version. Furthermore, we can leverage interoperability to store data in backup smart contracts created on secondary blockchains in case the primary chain faces congestion or other issues.

    Project Detailsโ€‹

    The project will consist of 9 microservices, each with a well-defined task.

    TrackingChainSchema

    StepTracking

    1. Triage API:

      • Purpose: Receives tracking requests, consults the registry, and associates a destination smart contract with each request based on a Profile.
      • Scalability: Can scale by increasing endpoints during high load periods due to no concurrency access issues.

    2. Aggregator Pool Worker:

      • Purpose: Moves tracking requests from Triage to the Pool after pre-filtering.
      • Scalability: Cannot scale due to concurrent access management but can handle large workloads efficiently.

    3. Tx Generator Worker:

      • Purpose: Sends transactions on-chain for tracked items in the Pool.
      • Behavior: Doesn't wait for transaction responses, only saves the returned Hash.

    4. Tx Watcher Worker:

      • Purpose: Monitors tracked items in the Pool with associated transactions for finalization.
      • Outcome: Inserts successful transactions into the transaction Registry; performs recovery actions for failed transactions.

    5. Frontend Admin:

      • Purpose: Manages the creation of associated accounts.

    6. Frontend Monitor:

      • Purpose: Monitors and manages tracking statuses in various states.

    7. Frontend Registry:

      • Purpose: Provides a user-friendly visualization of all tracked codes with direct links for on-chain verification.

    8. Web Application:

      • Purpose: Give the possibility to enter or view the status of onchain traced codes. (it will be fundamental for the demo that will have to lead us users to use the blockchain).

    9. Tx Monitor Worker:

      • Purpose: Monitor the status of transactions to proceed with any automatic actions or to launch alerts in the event of transactions that cannot be managed automatically.

    Overview of the technology stack to be usedโ€‹

    We are planning on using a combination of blockchain technology, cloud services, and front-end development tools to build a performant, secure, and user-friendly platform.

    Blockchain Layer:

    • Smart Contracts: Ink! and Solidity version for store the tracking values.

    Backend Layer:

    Frontend Layer:

    • Asp.Net MVC: These libraries will be used for interacting with the API from our frontend application.

    Ecosystem Fitโ€‹

    I plan to develop a WASM version, integrating the SubstrateGaming https://github.com/SubstrateGaming library developed by Ajuna and EVM smart contracts (C# will be utilized with the Nethereum library https://nethereum.com/ for interaction with compatible EVM networks).

    To ensure user authenticity, all smart contracts and wallets created on various chains will integrate with Kilt, associating a digital identity with each user utilizing the smart contract to certify data ownership.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Federico Cicciarella

    Contactโ€‹

    Team's experienceโ€‹

    My name is Federico Cicciarella, and I have been a Microsoft .Net (C#) developer for almost 20 years. In recent years, I have developed a strong interest in the blockchain, particularly in the use of Polkadot ecosystem (I am actively involved in Ajuna and Moonbeam as an ambassador, in Astar where I participate in the Ink! Academy and the Italian community).

    Over the years, I have gained significant experience in building such systems, including a web application that processed tens of thousands of daily orders (including data-heavy files like photos for immediate printing) and effectively scaled during peak periods (e.g., the holiday season).

    I'm working on a project for a censorship-resistant decentralized video platform.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 6.5 month
    • Full-Time Equivalent (FTE): 1
    • Total Costs: 16.200 USD

    Milestone 1 โ€” Basic functionalityโ€‹

    • Estimated duration: 3 month
    • FTE: 1
    • Costs: 8.500 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a basic tutorial that explains how a user can configure the data entry for create profile for to associate the tracking requests to a smart contract transaction.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains how to use.
    1.API: TriageWritten in Asp.Net, The Triage API acts as the gateway between the "Web2" world, which receives the Tracking requests, and the "Web3" world, where these requests will be saved. To do this it will verify that the incoming request is compatible with one of the profiles associated in the configuration, if so it will save the request in the Triage (and return an Guid to client) which will then be processed by the next service. In case the incoming request does not match any profile, it will be rejected. The Triage operation does not involve any concurrent processing, allowing for seamless scalability. It can accept requests simultaneously or even create multiple endpoints. The API expects a POST call with the following data: field Code used as a Key in the smart contract, field valueData used as one of the elements of the Value and the field Category that will be used to associate a profile with Tracking
    2.Aggregator Pool WorkerWritten in C#,The Aggregator Pool Worker will used to transfer processable data from Triage that has no time dependencies into the Pool. A transaction is transferable when there is no pending Transaction with same Profile to be completed in the pool
    3.Tx Generator WorkerWritten in C#,The Tx Generator Worker Worker will used to take data from Pool and make a transaction on onchain via smartcontract. In this case each worker instance takes one of the transactions entered into the pool and will process it by calling the selected smartcontract (this selection of smartcontract has already been made by Triage). Once the transaction has been made, it will save the HASH of the Tx so that it can be used by the next service. This service supports both (Ink! and EVM) TrackingChain smart contracts. The selection of the version of the smart contract to use will be given by the profile that was associated in the Triage phase
    4.Tx Watcher WorkerWritten in C#,The Tx Generator Worker Worker will used to check all Tx pending for finalized (or failed) status. Each worker instance takes a pending transaction and through the hash it will verify if it has been finalized successfully. This service supports both (Ink! and EVM) TrackingChain smart contracts. The selection of the version of the smart contract to use will be given by the profile that was associated in the Triage phase
    5.API: RegistryWritten in C#,Provide API for check the status of each Tracking request. Wich Guid of tracking request is possibile to watch the status of transaction. For example, the API will tell if the Tracking is in Trigae/Pool/Pending/Complete status and will provide all the times with which it moved from one status to another, as well as the onchain transaction information (gas used, hash tx. ..)
    6.Web ApplicationWritten in Asp.Net MVC pages for manage the insert tracking and views. A web interface from which it will be possible through a simple form to select the fields required to make a request towards the triage.
    7.Ink! Smart contracts.We will deliver a set of Ink! smart contracts that will able to track the key values. In particular, it will take care of saving in a dictionary key-value formed by a "Key" byte32 and the "Value" a list of bytes. A get call will also be available, which given a "Key" byte32 returns the entire "Value" list of Bytes saved over time, also providing the block number in which the transaction was carried out. It will also include the C# function that the "Tx Generator Worker" service will have to do to write onchain and the read call that will be used by the "Tx Watcher Worker" service. The implementation will partially reuse the C# SubstrateGaming library
    8.EVM Smart contractsWe will deliver a set of EVM smart contracts that will able to track the key values. In particular, it will take care of saving in a dictionary key-value formed by a "Key" byte32 and the "Value" a list of bytes. A get call will also be available, which given a "Key" byte32 returns the entire "Value" list of Bytes saved over time, also providing the block number in which the transaction was carried out. It will also include the C# function that the "Tx Generator Worker" service will have to do to write onchain and the read call that will be used by the "Tx Watcher Worker" service. The implementation will partially reuse the C# Nethereum library

    Milestone 2 โ€” FrontEnd UIโ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: 1.500 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a basic tutorial that explains how a user can use a frontend to easily configure profile and usage.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains how to use.
    1.Frontend Admin ToolsWritten in Asp.Net MVC, The frontend for manage all configuration like smart contract used, wallet used, profile association.
    2.Frontend Transaction MonitorWritten in Asp.Net MVC, The monitor to watch all tracking request. A graphical tool that allows you to display the status of all queues on screen. For example showing how many Triage there are, how many Pending, how many failed transactions. Including the detail of each single Tx within the Triage, Pool, pending and Registry
    3.Frontend RegistryWritten in Asp.Net MVC, The frontend for user friendly graph of specific product tracked onchain. For each value Key will be show all data Values insured and in wich block/time was performed

    Milestone 3 โ€” Monitor and Recovery functionalityโ€‹

    • Estimated duration: 1.5 month
    • FTE: 1
    • Costs: 4.500 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a basic tutorial that explains how watch the transaction status and use recovery tool for failed transactions.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains how to use.
    1.Tx Generator/Watcher WorkerIt will be improved to handle any errors that may arise and to retry the process for a configurable number of times. Once the maximum number has been exceeded, it will go into error status and the Watcher will manage the next phase which may be an attempt to re-enter the transaction again starting from the pool or put it definitively in permanent error status so as to be able to process the subsequent elements that were pending of the completely of the Transaction failed
    2.Tx Recovery/Monitor WorkerWritten in C#, The Tx Recovery/Monitor Worker will used to managed all transaction in failed status. It takes care of trying to re-process any transactions that have ended in error. in case of a new error, the transaction will be cancelled. It will also take care of generating alerts to be sent by email whenever a something goes wrong
    3.Tx Cleaner WorkerWritten in C#, The Tx Cleaner Worker will used to delete all transactions in status Completed from the Triage, PEnding and Pool to make the database lighter, The history will be present in the Registry
    4.Tx Unlocker WorkerWritten in C#, The Tx Unlocker Worker will used to to unlock any transactions left Unlocked due to unhandled errors or system crashes that cause a server restart. (very remote hypothesis but very important to manage in order not to lead to a block of all transactions due to unmanaged Unlocks)
    5.Frontend Admin ToolsImprovements to decide which failed Tx's to try to reprocess or mark them as permanently failed and possibility of marking as Aborted the Tx present in the Triage but not yet in Pool status

    Milestone 4 โ€” Ink Generation Call Improvementโ€‹

    • Estimated duration: 3 weeks
    • FTE: 1
    • Costs: 1.700 USD
    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide a basic tutorial that explains how configure the transaction with this improvement enable.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains how to use.
    1.Tx Generator WorkerImprovement to wait for the transaction to be finalized in order to skip the "Tx Watcher Phase" (this mode will be an option present in the configuration) it's will also allow for better support for chains that don't have access to subscans. To achieve this we will listen via socket in order to wait for the finalization of the generated Tx

    Future Plansโ€‹

    • Present the demo to customers and onboard our first major customer.
    • Continue meetings with customers interested in entering the web3 and onboard other customers.
    • Participate in events to be able to demonstrate how our demo works, also showing the portfolio of customers who have already chosen to use it.
    • Integration DID with Kilt
    • Resolve all open issues
    • Continue development of other features
      • Dynamic smart contract data instead of single key-value pairs
      • Support message bus (like RabbitMQ)
      • Use a dedicated database for each individual component
      • Support complex case of triage profile
      • Migrate to Dot Net Core 8 and AOT where supported
      • Improve security of sensitive data (like private key)
      • Improve Frontend Registry pages
      • Tool for massive Triage call
      • Implement any improvements requested by users
      • Improve Frontend Admin Tools (dynamic creation smartcontract, chainstatus monitor...)

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    • Referrer: Patrizia De Bella
    • Payment Address: BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) payment address. Please also specify the currency. (e.g. 0x8920... (DAI))

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? I've been actively following polkadot for a few years, I'm an ambassador for some projects including Ajuna, Moonbean and I'm part of Astar Ink! Academy

    1. Work you have already done
      • Starting in June 2023 to developing the project's code. Over the past year, we've been offering our product to potential customers, gathering valuable feedback along the way. These inputs guided us in creating the current version of the product, which we presented through an engaging demo and which piqued the interest of many customers.
    2. If there are any other teams who have already contributed (financially) to the project.
      • No, all "Future Plans" will be covered by new clients or carried forward by me.
    3. Have you applied for other grants so far?
      • No
    - + \ No newline at end of file diff --git a/applications/tribal_protocol.html b/applications/tribal_protocol.html index 741f34b34a6..e0029588403 100644 --- a/applications/tribal_protocol.html +++ b/applications/tribal_protocol.html @@ -4,7 +4,7 @@ Tribal Protocol Smart Contract Development - Phase 1 | Web3 Foundation Grants - + @@ -118,7 +118,7 @@ 4-)+5: CANCEL_TRIBE_FOUNDING 5-)-4: CANCELLED end

    To activate an instantiated tribe, all listed founders must accept the terms, and conditions of said tribe, as defined in the initial create_tribe event.

    In the above diagram, after all the founders accept the creation of the tribe, the tribe is set to an active state. Once the tribe is active, it can participate in content leasing events.

    Alternatively, as depicted in the diagram above, if any founder rejects the create_tribe event, the tribe **will not be activated,** and is marked as closed.

    In order to continue, a new tribe must be created from scratch, and once again be approved by each founder.

    Lease Content

    Content leasing is how we expect to enable individual content ownership and distribution. Leasing expects 2 actors: the content creator (lessor) and the tribe (lessee).

    lease_content contract creates the on-chain representation between the specified tribe and the user-owned content by creating a cryptographic key that unlocks the original cryptographic content key which is used to decrypt that specific userโ€™s content.

    This model allows content to be encrypted with a single key-pair, that is stored using the userโ€™s own key-pair. A lease will decrypt the original content key, and create a new cryptographic key which can also unlock the original contentโ€™s key. Any key that is able to unlock the original content key will be derived from the original.

    Technology Stackโ€‹

    The tribal smart contracts will be written in ink!, which is native rustlang. The CLI, and other core components will use reputable libraries like clap to construct the actual CLI, and tokio to provide asynchronous task execution from within our libraries.

    All cryptographic functions will be derived from stock substrate libraries, and pallets.

    Most lower-level blockchain related functionality will also initially use stock substrate pallets like BABE and/or GRANDPA.

    At this time, any UX functionality will be mostly custom, with the exception of base substrate modules that can be loaded via WASM. We expect to have some client-side services to communicate with back-end services in real time via REST calls, and web sockets to communicate with multiple back-ends simultaneously. We expect all of this communication to be contained within what we are calling the Orchestrator, which will negotiate backend data, and transaction signing/submission with user approval. Because of the nature of itโ€™s utilities, we have determined that this workload should exist client-side exclusively.

    Proof-of-Concept (prior work)โ€‹

    Anย initial implementation of Tribal Protocol was written in C# from scratch without forking another chain to work out some of our system design questions. While we were able to get past rudimentary P2P networking and proof-of-stake consensus issues, the enormity of the task ahead caused us to re-evaluate. In the course of re-evaluating we determined that a language like C#, while powerful in its own right, was not suited to developing a L1 blockchain. This led us to Rust, and eventually to Substrate.

    Once we settled on the proper tooling, we were able to think more clearly about the problem domain, and how to go about implementing it. We discovered that we had to have smart contracts at the heart of our system if we wanted it to have the utility desired while remaining open to decentralization.

    After deep diving in ink! we realized that Substrate mitigated many of our network level architecture concerns, and gave us a smart contracting framework to build from. We spent some time building out small projects in Rust (including these crates: 1,2) and basic ink contracts in order to get more familiar with Rust, ink!, and Substrate prior to this grant submission.

    Non-Goalsโ€‹

    Weโ€™ll take this chance to be very clear that the work associated with this grant is not intended to create a production ready network or a consumer quality user interface. This is a designed to be the first major milestone towards building out our Tribal Network. Think of it as the first real development epic after completing our research spike on Substrate, ink!, and Rust over the last few months. The outputs of this grant are limited to the key deliverables detailed above and the deliverables outlined in the milestones below.

    Ecosystem Fitโ€‹

    Tribal Protocol will be a social media protocol that enables anyone to create their own web3 native social media platform on top of it. There are plenty of others that are attempting to fulfill a similar vision of โ€œdecentralizing social mediaโ€:

    However we donโ€™t believe that any of these projects have found sufficient levers and ways of mixing crypto and social to unlock the user growth needed for meaningful consumer adoption.

    What makes Tribal Protocol unique is our full stack approach to serve a very specific customer - people who want to become founders, co-owners, and contributors to entirely new niche social networks that they control. The vast majority of the space today is attempting to enable the โ€œdecentralized twitter or facebookโ€ products while not actually enabling early stage social networks to form. Our most critical differentiator from all other attempts in this space is the creation of DAOs that are directly tied to niche social networks. The economic alignment that DAOs unlock combined with the content moat from user driven content leasing is the secret sauce that allow nascent social networks to form.

    We will be โ€œdog-foodingโ€ our own stack to build out multiple non-crypto user base focused social networks with the goal creating 10 tribes / tribal protocol based apps each with 5K Daily Active Users (solid base of 50K DAU across protocol). Once we reach this milestone we plan to productize our no-code platform for non-technical individuals to launch and manage their own social networks built on tribal protocol. This last step would amount to something like a Wix for social media app creation + day-to-day DAO management tooling that weโ€™ll either build out or integrate with existing products from the ecosystem.

    The open source tech stack weโ€™re developing will help move the substrate and Polkadot ecosystem forward in ink! smart contract development, practical applications of DAOs and their associated management tooling. Please reference our whitepaper for more depth on the use cases Tribal Protocol unlocks and insight into our go to market strategy.

    Teamย ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Chris, Alec, and Jason launched a startup called CloutCast in April of 2021 and were a part of the first DeSo Foundation Octane Fund backed projects. CloutCast is โ€œweb3โ€™s promoted post platformโ€ - and aims to re-imagine what sponsored posts look like in the emerging web3 social media space. This project was a full contact immersion into web3 and gave us a lot of our technical and personal exposure to the major ecosystems and players in decentralized social media today.

    Prior to CloutCast the three members of this team met and built products together for a Miami based corporate startup studio. At that time Chris was the lead software architect, Alec was head of Dev-Ops, and Jason was head of product - churning out scalable software products from ideation to scale for a now $10B public company.

    From our years of working at a startup studio and our experience building out products on top of current social media products and protocols - we realized that we could do a better job of building a full stack solution in this space rather than continuing to play within other protocolโ€™s limitations. Taking on the L1 Tribal Protocol allows us to have full technical design flexibility as well as being able to capture the upside if our vision succeeds.

    Chris is a software engineer, system architect, and entrepreneur with 25+ years of experience.

    Alec is a software engineer, Dev-Ops leader, and entrepreneur with 10+ years of experience.

    Jason is a product leader, entrepreneur and a former US Army Officer with 10+ years of experience.

    Team Code Reposโ€‹

    https://github.com/cloutcast/cloutcast-ui

    https://github.com/cloutcast/cloutcast-api

    https://github.com/desphere

    Team LinkedIn Profilesโ€‹

    Development Statusย ๐Ÿ“–โ€‹

    Tribal Protocol White Paper

    Open Source Rust familiarization work

    Development Roadmapย ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    **Milestone 1 โ€” Implement Local Development Chain + Create Tribes**โ€‹

    A Tribe is the key actor in the tribal protocol - it is the DAO entity that allows for co-ownership of social networks on the protocol. This milestone will allow for the operation of a local development chain, including the custom Tribal Substrate pallet. The key output of this milestone is the ability to create tribes via an ink smart contract. In this milestone we will implement the basic structure of the Tribe entity and validations around Tribe creation.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can create a basic Tribe and how to create a local development chain. Once the node is up, it should produce blocks and tribes can be created.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the documentation and blog post, we will describe how to run these tests.
    0d.ArticleWe will publish a blog post that explains the architecture of Tribal as it relates to Substrate, how to create tribes on the protocol, and how to run a local development chain.
    1.Design DocumentA detailed description of key system components, entities, and pallets that comprise the local development tribal chain.
    2.tribal_palletPallet initialization to contain Tribal smart contracts
    3.Ink! Contract: create_tribeExtensible ink! contract to spawn a tribe entity
    4.Initial Tribe StructRepresent tribe entity within Tribal Pallet. Tribe entity includes metadata to support said tribe.
    5.Orchestrator ClientInitial Orchestrator lib crate

    **Milestone 2 โ€” Implement Content Leasing Ink! Contract**โ€‹

    As a social media protocol content management, ownership, and control is critically important. A fundamental component of Tribal is the ability for users to โ€œleaseโ€ content to tribes, as well as for tribes to dictate the conditions under which content can be leased.

    In this milestone the primary deliverable is the extensible ink smart contract for content leasing between user and tribes.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can create leased content and how to create a local development chain.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the documentation and blog post, we will describe how to run these tests.
    0d.ArticleWe will publish a blog post that explains the smart contract implementation and implications of content leasing for production use cases going forward.
    1.Design DocumentA detailed description of key system components, the tribal pallet, and the ink contracts in play.
    2.ink contract: lease_contentExtensible ink! contract to lease content between user and tribes.
    3.Content leased to a specific tribe can be identified and listedAPI allows for the identification and listing of all leased content to a specified tribe. This becomes important for UI rendering in future development.
    4.Txn level validation testingEnsure content keys are not able to be leased multiple times, handle insufficient funds, conditional leasing checks
    5.Pallet Release v0.2Implementations of Milestone 2, wrapped in a compiled pallet.

    **Milestone 3 โ€” Extend Ink! Contract for Revoke Content Lease & End to End Functional/Integration Code Coverage**โ€‹

    The final milestone will focus on delivering the ability to revoke content leases initiated from either member of the lease (user or tribe) as well as deliver integration testing so the community benefits from clean, usable code.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can create and revoke leased content and how to create a local development chain.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the documentation and blog post, we will describe how to run these tests.
    0d.ArticleWe will publish a blog post that explains the smart contract implementation and implications for production use cases going forward.
    1.Design DocumentA detailed description of key system components, the tribal pallet, and the ink contracts in play.
    2.revoke_leaseImplement revoke_lease contract, and transaction types.
    3.Integration/Functional Test(s): Mock ContentMock Content can be Created. CREATE_CONTENT dummy transaction. (targeting ~75%+ Code Coverage)
    4.Integration Test: Lease ContentContent can be leased to a tribe. LEASE_CONTENT transaction against a CREATE_CONTENT transaction. (targeting ~75%+ Code Coverage)
    5.Integration Test: Multi Tribe Content LeasingContent can be leased to multiple tribes simultaneously. LEASE_CONTENT to a tribe. (targeting ~75%+ Code Coverage)
    6.Integration Test: Revoke Lease from one of multipleContent can be revoked from one tribe, but not on another. REVOKE_CONTENT from a tribe. (targeting ~75%+ Code Coverage)
    7.Integration Test: Revoke Lease from all tribesContent can be revoked from all tribes. REVOKE_CONTENT from ALL tribes. (targeting ~75%+ Code Coverage)
    8.Pallet Release v0.3Implementations of Milestone 3, wrapped in a compiled pallet.

    Future Plansโ€‹

    Short-termโ€‹

    Long-termโ€‹

    Apply for a series of follow-on open grants to implement protocol enhancements:โ€‹

    Continue towards mainnet launchโ€‹

    1. Launch a public Tribal Protocol testnet.
    2. Convert to an incentivized testnet under Tribal Protocol.
    3. Convert to mainnet, as a stand alone L1 or parachain depending on technical discovery.

    Additional Informationย โž•โ€‹

    How did you hear about the Grants Program?

    Jason was seeking some mentorship and advise from Jeremiah Wagstaff, co-founder of SubSpace, who recommended that we seriously consider a web3 grant as a great way to enter the ecosystem. Very glad those two connected!

    - + \ No newline at end of file diff --git a/applications/tux0.html b/applications/tux0.html index 7b7420eb180..1a55735cb64 100644 --- a/applications/tux0.html +++ b/applications/tux0.html @@ -4,7 +4,7 @@ Tux0 | Web3 Foundation Grants - + @@ -32,7 +32,7 @@ We also started sketching out some code for a Tuxedo piece, but nothing worth mentioning.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Research phaseโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can add a new protocol, run the benchmarks, and verify the results.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article on our GitHub blog that explains our research process, the results, and why we decided to proceed with a certain protocol.
    1.Benchmarking programWe will develop a Rust program that will automatically run zk protocols benchmarks and export the results in a readable format, like JSON.
    2.Protocols integrationWe will provide an integration of at least 3 protocols for the benchmarking program, which will be used to produce the results. We will document the reasons for the choice of these protocols rather than other potential candidates.
    3.Data Visualization toolWe will provide a single page webapp to easily visualize and compare the benchmark results, usingย C3.js or a similar library. The core of this page will be embedded in the article as well.

    Milestone 2 โ€” Development phaseโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how Tux0 can be included in a Tuxedo runtime, and how to interact with it, using Tuxedo's Template Wallet.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Tux0We will develop a Tuxedo piece that manages a DAP token using zero knowledge proofs. It will be written in Rust, and it will leverage the library identified in the first milestone.
    2.Tuxedo Wallet ExtensionWe will extend the Tuxedo Template Wallet to support Tux0 balances and to send Tux0 transactions. This will also be written in Rust.

    Future Plansโ€‹

    We intend to continue to maintain Tux0 at least until a proper release of Tuxedo's parachain support - which might even come before the delivery of this grant.
    We are interested in testing the zero-knowledge protocol we chose for Tux0 in a parachain environment.

    Bader @CrackTheCode016 suggested we could deploy a Tux0 parathread on Rococo, which would be a huge step forward for Tuxedo as well.

    Referral Program (optional) ๐Ÿ’ฐโ€‹

    Additional Information โž•โ€‹

    We have been part of the Substrate ecosystem since early 2022, so we had the chance to hear about the W3F Grants from various sources: Substrate Builders Program, Polkadot Blockchain Academy, Parity employees, Sub0 2022, and probably more.
    However, it was Joshy the one who suggested us to ask for a grant for this idea, and he deserves a big thank you from both of us.

    - + \ No newline at end of file diff --git a/applications/tuxedo.html b/applications/tuxedo.html index d235dce4496..8ab1457de3e 100644 --- a/applications/tuxedo.html +++ b/applications/tuxedo.html @@ -4,13 +4,13 @@ Tuxedo | Web3 Foundation Grants - +
    Skip to main content

    Tuxedo

    • Team Name: Off-Narrative Labs
    • Payment Address: 0x5a335908df9D2C47304338E3b744579Ed7C6a64d (DAI)
    • Level: 2 ๐Ÿค

    Project Overview ๐Ÿ“„โ€‹

    Develop Substrate runtimes based on the UTXO model.

    Overviewโ€‹

    Tuxedo is a framework for developing Substrate runtimes based on the Unspent Transaction Output (UTXO) model. The letters utxo are contained in the word tuxedo, hence the name.

    In the broader blockchain space, there are essentially two models for creating state machines, or runtimes, as they are known in the Substrate ecosystem. Those two models are the Account System as seen in Ethereum, Polkadot, and others, and the UTXO System as seen in Bitcoin, Monero, Cardano, and others. Currently the defacto way to write Substrate runtimes is with FRAME, which is based on the account system, and any project wishing to build on the utxo system is left to write a runtime from scratch or find a home in another ecosystem. Tuxedo would be a couterpart to FRAME based on UTXOs rather than accounts.

    Tuxedo would make the UTXO model more visible and accessible in the Substrate ecosystem and begin to create a diversity of runtime frameworks in addition to FRAME, a trend that we hope will continue beyond Tuxedo itself.

    Project Detailsโ€‹

    The primary advantage of UTXOs is that they are highly parallelizable. This fits well in Polkadot's multichain ecosystem where parachains execute and communicate asynchronously, and will be an even bigger advantage if (hopefully when) DAG based chains become popular, a trend that is already kicked off with projects like Aleph Zero, and many others outside the Polkadot ecosystem, including Hedera Hashgraph, Nano, and Casper Labs.

    The UTXO data model is relatively well established by Bitcoin as well as research from IOHK in their Abstract Model and Extended UTXO Model. Our primary tasks would be to implement this in Rust and expose a standard API for chain developers to build on. This is analogous to the API exposed by FRAME System and the Pallets built on top.

    Our core data types follow similarly, to the IOHK research cited above. The primary differences are that we do not assume a native cryptocurrency and rely on Tuxedo Pieces (analogous to FRAME Pallets) to provide the validation logic, rather than the UTXOs themselves.

    /// A UTXO transaction specifies some inputs to be consumed, and some new outputs to be created.
    struct Transaction {
      /// The inputs refer to currently existing unspent outputs that will be consumed by this transaction
      inputs: BTreeSet<Input>,
      /// Similar to inputs, Peeks refer to currently existing utxos, but they will be read only, and not consumed
      peeks: BTreeSet<Input>,
      /// The new outputs to be created by this transaction.
      outputs: Vec<Output>,
    }

    /// A single output of a transaction which has an owner and some associated data
    struct Output {
      /// The address that owns this output. Based on either a public key or a Tuxedo Piece
      owner: Address,
      /// The data associated with this output. In the simplest case, this will be a token balance, but could be arbitrarily rich state.
      data: Vec<u8>,
    }

    /// A single input references the output to be consumed or peeked at and provides some witness data, possibly a signature.
    struct Input {
      /// A previously created output that will be consumed by the transaction containing this input.
      output: OutputId,
      /// A witness proving that the output can be consumed by this input. In many cases including that of a basic cryptocurrency, this will be a digital signature.
      redeemer: Vec<u8>,
    }

    The core of the API exposed developers who create Tuxedo Pieces, will roughly follow this trait. We expect this will have to get more specific as our development shows us what we haven;t yet considered.

    /// The API of a Tuxedo Piece
    trait TuxedoPiece {

      /// The type of data stored in Outputs associated with this Piece
      type Data;

      /// The validation function to determine whether a given input can be consumed.
      fn validate(transaction: Transaction, input: Input) -> bool;
    }

    This grant does not strive to create the entire rich ecosystem of Tuxedo pieces that we hope to eventually be developed on top of Tuxedo. Rather it strives to create the core of the Tuxedo system and a few of the most important and exemplary pieces. Specifically, we strive to develop the analogs to FRAME Executive, FRAME System, Pallet Balances, and Pallet Transaction Payment.

    Ecosystem Fitโ€‹

    Tuxedo is a framework for writing Substrate runtimes. Substrate is the toolkit for building virtually all parachain nodes as well as many standalone blockchains. As such, Tuxedo provides a richer set of options to runtime developers, and hopes to attract teams to the Substrate / Polkadot ecosystem who may have otherwise gone elsewhere.

    The primary users of Tuxedo will be parachain and runtime developers who will use Tuxedo directly to structure their runtimes. Of course, the user base will trickle downstream as well to users of those parachains that choose to build with Tuxedo. However, chain users will use Tuxedo only indirectly.

    There are no projects like this in the Substrate ecosystem, although they do exist in the broader blockchain space; Cardano being the most notable example.

    While it fulfills a similar role, Tuxedo is not intended to compete with FRAME, but rather to compliment it, by welcoming projects that fit naturally with the utxo model into the Substrate ecosystem, as FRAME does for projects that fit the accounts model.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    • Contact Name: Joshy Orndorff
    • Contact Email: joshyorndorff at proton dot me
    • Registered Address: The address you'll use in the invoices

    Team's experienceโ€‹

    Joshy entered the Substrate ecosystem in 2019 as part of the Substrate Developer Hub team. There he created and hosted the weekly Substrate Seminar, and contributed significantly to the Substrate Recipes. In 2020, he moved to the Moonbeam team where he was a core developer. While at Moonbeam, Joshy wrote the Nimbus consensus engine which is used in several production parachains, and helped pioneer the technique whereby EVM contracts can interact with native Substrate pallets. In 2022, Joshy began contributing to the Polkadot Blockchain Academy, teaching in both Cambridge and Buenos Aires.

    Andrew entered the Substrate ecosystem from a curiosity point of view back in June 2021. From there he learned blockchain and Substrate via documents and tinkering in his off time after work. In December 2021 received a fulltime job for a venture builder to build a parachain to eventually connect to Polkadot. Andrew graduated from the first Polkadot Blockchain Academy cohort in 2022 in Cambridge. After Cambridge Andrew moved on from the venture builder to dive into education in the Polkadot Ecosystem by instructing and developing course curriculum for the Polkadot Devcamp #2 online. For Andrew's current work he is contracting as an instructor at the Polkadot Blockchain Academy for Parity Technologies lecturing and creating educational content for Blockchain Fundamentals(Specifically lecturing on UTXO vs Accounts models), Substrate, and XCM modules. Also Andrew is doing Rust Core development work for the Integritee Parachain. Andrew shares a passion for allowing blockchain developers the ability to build upon the UTXO model in Substrate.

    Joshy and Andrew met in Cambridge in 2022 at the first Polkadot Blockchain Academy. There Andrew chose the Frameless UTXO Project cited above as his final project.

    Development Status ๐Ÿ“–โ€‹

    The team has done previous work on this topic:

    • Joshy maintained the Substrate UTXO Workshop code as part of the Substrate Developer Hub team, and has continued to maintain it out of personal interest even years after leaving that team.
    • Andrew ported this code to work without FRAME as part of the Polkadot Blockchain Academy.

    The development so far has focused specifically on the cryptocurrency use case, whereas this grant proposes to generalize the code to be a framework for broader runtime logic development.

    As teaching staff at the Polkadot Blockchain Academy in Buenos Aires, Joshy and Andrew found themselves, on two occasions, in conversations with other teaching staff in which it was noted that a diversity of runtime development frameworks would make the Substrate ecosystem stronger and attractive to a broader development base. This idea was supported by Kian Paimani and Shawn Tabrizi among others.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 9 weeks
    • Full-Time Equivalent (FTE): 1.5 FTE (Joshy and Andrew will both work roughly three quarters time on this)
    • Total Costs: $30,000 (USD)

    Milestone 1 โ€” Tuxedo Core and Cryptocurrency Pieceโ€‹

    • Estimated duration: 3 weeks
    • FTE: 1.5
    • Costs: 10,000 USD

    Split the existing FRAMEless UTXO project into the generic Tuxedo core, and the first Tuxedo piece which represents a cryptocurrency.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up the example node and transfer tokens
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.Tuxedo CoreWe will create the core of the Tuxedo System, analogous to FRAME Executive and FRAME System
    2.Token PieceWe will create the first Tuxedo piece that serves as a cryptocurrency, analogous to Pallet Balances
    3.Tuxedo Node TemplateWe will create a Substrate node with the runtime built with Tuxedo and including the Token piece. Together this will represent a bitcoin-like token (not PoW though, only the token logic is bitcoin-like)

    Milestone 2 โ€” Wallet and Multisigโ€‹

    • Estimated Duration: 3 weeks
    • FTE: 1.5
    • Costs: 10,000 USD

    Create the second Tuxedo piece, and a user-facing wallet

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up the example node and transfer tokens
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.User WalletWe will create a CLI wallet that users can use to track their tokens in a Tuxedo-based cryptocurrency. This makes the example node actually useable by common users who are curious to explore but not yet ready to dig into the code. The wallet will be written in Rust and communicate with Substrates jsonrpsee endpoint.
    2.Multisig PieceWe will expand the ecosystem of Tuxedo pieces by creating a multisig wallet. In addition to making the Tuxedo ecosystem a bit more complete, this also demonstrates to future piece developers how to couple pieces.

    Milestone 3 โ€” Full Docs and Tutorialโ€‹

    • Estimated Duration: 3 weeks
    • FTE: 1.5
    • Costs: 10,000 USD

    Fully document the Tuxedo paradigm, existing pieces, CLI wallet, and provide a tutorial for runtime developers

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up the example node and transfer tokens
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    0e.Full written and Video TutorialWith a node template, piece template, and user-facing wallet now complete, we can get serious about user and developer documentation. We will create a full written tutorial and video walkthough that covers how to build and run the Tuxedo Node Template, and send tokens around with the wallet. We will then dive into how to add the multisig piece to your runtime, and how to develop your own simple piece starting from the piece template.
    1.Piece TemplateWe will create the template Tuxedo Piece analogous to the FRAME pallet template. This will allow runtime developers to have a concrete starting place when building their own utxo based Substrate runtimes.

    Future Plansโ€‹

    Being a framework for runtime development, we plan to continue developing the ecosystem of Tuxedo Pieces including Pieces for NFTs, Governance Mechanisms, Proof of Stake, and even smart contracts.

    Joshy has long had a vision of a UTXO based smart contract language based on the pi calculus. With Tuxedo core complete, it will be possible to develop such a contracting platform.

    The UTXO model allows concurrent processing of unrelated transactions (those that do not compete to consume any inputs). It would be exciting to extend Substrate itself to support a DAG structure rather than a linear chain to take advantage of this ability, although the feasibility of this extension has not yet been studied.

    Additional Information โž•โ€‹

    The team has been in the Substrate ecosystem for a long time, so we have heard of the grants program in many ways. From colleagues, grant recipients speaking highly the program, and grant recipients looking for help understanding Substrate.

    - + \ No newline at end of file diff --git a/applications/tuxedo_parachain.html b/applications/tuxedo_parachain.html index 90815da8f8c..9b1a98c4ab7 100644 --- a/applications/tuxedo_parachain.html +++ b/applications/tuxedo_parachain.html @@ -4,7 +4,7 @@ Tuxedo Parachain | Web3 Foundation Grants - + @@ -31,7 +31,7 @@ We hope that the simplicity of the UTXO model will allow performance increases, but right now that is just a theory.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up the example node and transfer tokens
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile that can be used to test all the functionality delivered with this milestone.
    1.Benchmark ReportFull report of throughput for {Transfer, Remark} transactions in {FRAME, Tuxedo} runtimes operated in {Standalone, Parachain} contexts.

    Future Plansโ€‹

    Near Termโ€‹

    We have a vision for a Tuxedo parachain that acts as an Atomic Swap hub for DOT ecosystem assets to foreign UTXO chains like Monero, Zcash, Cardano, etc.

    The Farcaster provides a Monero Bitcoin atomic swap protocol. We intend to extend this protocol to support Tuxedo chains. And thanks to Polkadot's XCM, this would allow atomic swaps between other DOT ecosystem assets and foreign UTXO chains as well.

    Following completion of this grant, the path to working Atomic Swaps would be roughly

    1. Extend Farcaster to support swaps with Tuxedo.
    2. XCM integration with Tuxedo for Cross-chain UTXOS.
    3. Testing, auditing, etc.

    Medium Termโ€‹

    Other dreams we have for Tuxedo include:

    Additional Information โž•โ€‹

    As mentioned above, we have completed one previous grant on this topic:

    - + \ No newline at end of file diff --git a/applications/typechain-polkadot-follow-up-2.html b/applications/typechain-polkadot-follow-up-2.html index c384666dee3..ff387c704ce 100644 --- a/applications/typechain-polkadot-follow-up-2.html +++ b/applications/typechain-polkadot-follow-up-2.html @@ -4,7 +4,7 @@ Typechain-Polkadot Follow-up-2 | Web3 Foundation Grants - + @@ -20,7 +20,7 @@ Blockchain Developer.

    Student of Computer Science at the Kyiv National University of Taras Shevchenko. Participated in programming competitions of different stages in school since 2017 (C++). Was a Backend developer(Go), Solidity developer(Solidity, Hardhat, Typescript), and now Blockchain developer(Rust, Typescript).

    Artem Lech Blockchain Developer.

    Student of Applied Mathematics at the Kyiv National University of Taras Shevchenko. Started programming in 2016 and participated in a lot of Ukrainian and international competitions of competitive programming. Worked as a lecturer of algorithms at the school of competitive programming and as Intern Backend Engineer (Rust). Now works as Blockchain Developer on Polkadot Blockchain (Rust, Typescript).

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    The project is already a work-in-progress.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    We have decided to describe a full roadmap of a Typechain here, with estimates. However, the funding we request at this stage is for milestone 3.

    Previous workโ€‹

    Grant #1โ€‹

    Grant #2โ€‹

    Current work - Scope of this grantโ€‹

    Milestone 1 - High-level improvements, flexibility and simplifying of usageโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will cover new-added features in documentation and usage examples.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains how to integrate the typechain library into a project and describes the types of connection options (directly or via compiler).
    1.User-defined pluginsWe will provide an opportunity for users to make their plugins, for instance, how to use parsed types, adding new fields and so on.
    2.Subscribing to eventsWe will research and subscribe to events the contract emits, which will be handy for developers.
    3.Typechain-compilerThe tool will be easy for big projects to compile Rust code and generate Typechain definitions. Itโ€™ll be helpful for TDD when users can write code and develop everything in one CLI command instead of generating a typechain-code file by file. In plans, we want to make a wrapper for running user scripts (like hardhat run) and also functionality to initialize the environment for typechain usage
    4.Openbrush integration testsWe will test typechain on openbrush integration tests to ensure everything is working correctly and is easy to use.
    5.typechain/types packageWe will make a separate package for types that typechain use to reduce the usage of the same code and separate static code from generated code.

    Future workโ€‹

    After this grant, we will maintain the project to keep up with new emerging ecosystem standards, listen to community issues, and update the tool to make the transformation process a more excellent experience for the developers and teams.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Have a number of approved applications:

    - + \ No newline at end of file diff --git a/applications/typechain-polkadot-follow-up.html b/applications/typechain-polkadot-follow-up.html index 8e43f3b04d1..aa52cf1c8ae 100644 --- a/applications/typechain-polkadot-follow-up.html +++ b/applications/typechain-polkadot-follow-up.html @@ -4,7 +4,7 @@ Typechain-Polkadot Follow-up | Web3 Foundation Grants - + @@ -22,7 +22,7 @@ Blockchain Developer.

    Student of Computer Science at the Kyiv National University of Taras Shevchenko. Participated in programming competitions of different stages in school since 2017 (C++). Was a Backend developer(Go), Solidity developer(Solidity, Hardhat, Typescript), and now Blockchain developer(Rust, Typescript).

    Artem Lech Blockchain Developer.

    Student of Applied Mathematics at the Kyiv National University of Taras Shevchenko. Started programming in 2016 and participated in a lot of Ukrainian and international competitions of competitive programming. Worked as a lecturer of algorithms at the school of competitive programming and as Intern Backend Engineer (Rust). Now works as Blockchain Developer on Polkadot Blockchain (Rust, Typescript).

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    The project is already a work-in-progress.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    We have decided to describe a full roadmap of a Typechain here, with estimates. However, the funding we request at this stage is for milestone 2.

    Previous workโ€‹

    Milestone 1 - MVP, first application and testing.โ€‹

    NumberDeliverableSpecification
    0aLicenseMIT
    0bDocumentationWe will provide TypeScript code examples of this package in use, inline documentation, JSDoc, and the description of its features.
    1TS TypesWe will research & match types from ABI to TypeScript, compatible with polkadot{.js} v8 library. Separately, for methods' arguments and return values. Files with types definition will be generated.
    2Runtime CodePrepare output(its draft can be seen in technical specification) of runtime code with contracts' methods implementation. At this point we have minimal viable coverage of the ABI types, original methods' names, and general types for methods' options, without specifics for contract's namespaces.
    3TestingMinimal coverage of PSP22 contract with integration tests. We will be testing correctness of the derived types of the arguments and return values.
    4NPM PackagingPrepare the repository to work through CLI as a package. In TypeScript, as is, without translation to JavaScript. We will publish the package to NPM repository and provide set-up instructions (i.e. for installation, input & output).

    Current work - Scope of this grantโ€‹

    Milestone 2 - Full coverage for ABIsโ€™ types. Contracts deployment.โ€‹

    NumberDeliverableSpecification
    0aLicenseMIT
    0bDocumentationCover new-added features in documentation and usage examples. Prepare generated code to have more informative IDE hints based on TSDoc and the output type system (if needed).
    1Investigation & RefactoringBroaden types definitions for methods arguments and return values (to full coverage). Also, refactor project structure to monorepo for future development
    2Parser & generators modulesDesign and implement a new parser module for ABI JSON to work with different versions of the ABI. Parser's output structure serves as an input for generators. Refactor, replace inline generation with the parser to generator flow.
    3Contract deploymentAdd availability to deploy contracts with Constructors field, using *.contract files.
    4aContract classes extensionExtend generated contract classes with valuable properties ordinarily available on the contract (e.g., address, name, signer, etc.). Also, provide the ability to change signer and contract address easily without creating a new contract manually.
    4bMethods' namesFormat methods' names in the output from the original MethodTrait::method_name to a more user-friendly methodName naming scheme while resolving overlap in formatted names.
    5TestingComplete coverage of PSP22 contract with integration tests. Both for contract usage and deployment. We will be testing arguments' & return values' types' correctness.
    6ArticleWe will publish an article that explains features of Typechain, how to use it in projects
    7BrandingMake logotype for typechain and better README

    Future workโ€‹

    Milestone 3 - High-level improvements, flexibility and simplifying of usageโ€‹

    NumberDeliverableSpecification
    0aLicenseMIT
    0bDocumentationWe will cover new-added features in documentation and usage examples.
    1User-defined pluginsWe will provide an opportunity for users to make their plugins, for instance, how to parse types or what generated code will look like.
    2Subscribing to eventsWe will research and subscribe to events the contract emits, which will be handy for developers.
    3Typechain-compilerThe tool will be easy for big projects to compile Rust code and generate Typechain definitions. Itโ€™ll be helpful for TDD when users can write code and develop everything in one CLI command instead of generating a typechain-code file by file. In plans, we want to make a wrapper for running user scripts (like hardhat run) and also functionality to initialize the environment for typechain usage
    4Openbrush integrationWe will test typechain on openbrush integration tests to ensure everything is working correctly and is easy to use.
    5typechain/types packageWe will make a separate package for types that typechain use to reduce the usage of the same code and separate static code from generated code.
    6ArticleWe will publish article that explain how to connect it to the project and describe the types of connection options (directly or via compiler)

    After this grant, we will maintain the project to keep up with new emerging ecosystem standards, listen to community issues, and update the tool to make the transformation process a more excellent experience for the developers and teams. We are going to work on integration with the Swanky project.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Have a number of approved applications:

    - + \ No newline at end of file diff --git a/applications/typechain-polkadot.html b/applications/typechain-polkadot.html index 55707304b15..321850cb028 100644 --- a/applications/typechain-polkadot.html +++ b/applications/typechain-polkadot.html @@ -4,7 +4,7 @@ Typechain-Polkadot | Web3 Foundation Grants - + @@ -19,7 +19,7 @@ Has 5 years of experience in front-end development. Primarily working with React-based applications with Flux state management systems, written in TypeScript. Produced many modular solutions & dealt with NPM packaging. Latest experience is with projects on Polkadot blockchain.

    Varex Silver Blockchain Developer.

    Student of Computer Science at the Kyiv National University of Taras Shevchenko. Participated in programming competitions of different stages in school since 2017 (C++). Was a Backend developer(Go), Solidity developer(Solidity, Hardhat, Typescript), and now Blockchain developer(Rust, Typescript).

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    The project is already a work-in-progress.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    We are describing a full roadmap of the TypeChainPolkadot here, with estimates. However, the funding we request at this stage is for Milestones 1

    Technical specifications can be found here.

    Current work - Scope of this Grantโ€‹

    Milestone 1 - MVP, first application and testing.โ€‹

    NumberDeliverableSpecification
    0aLicenseMIT
    0bDocumentationWe will provide TypeScript code examples of this package in use (some can be already found here). As well, as inline documentation, JSDoc and its features description.
    1TS typesWe will research & match types from ABI to TypeScript, compatible with polkadot{.js} v8 library. Separately, for methods' arguments and return values. Files with types definition will be generated.
    2Runtime codePrepare output(its draft can be seen in technical specification) of runtime code with contracts' methods implementation. At this point we have minimal viable coverage of the ABI types, original methods' names, and general types for methods' options, without specifics for contract's namespaces.
    3TestingMinimal coverage of PSP22 contract with integration tests. We will be testing correctness of the derived types of the arguments and return values.
    4NPM PackagingPrepare the repository to work through CLI as a package. In TypeScript, as is, without translation to JavaScript. We will publish the package to NPM repository and provide set-up instructions (i.e. for installation, input & output).

    Future Plansโ€‹

    Milestone 2 - Full coverage for ABIsโ€™ types. Contracts deployment.โ€‹

    NumberDeliverableSpecification
    0aLicenseMIT
    0bDocumentationWe will cover new-added features in documentation and usage examples.
    1InvestigationBroaden types definitions for methods arguments and return values (to full coverage).
    2Parser & generators modulesDesign and implement a new parser module for ABI JSON to work with different versions of the ABI. Parser's output structure serves as an input for generators. Refactor, replace inlne generation with parser to generator flow.
    3Contract deploymentSupport of parsing *.contract files. Provide means for contract deployment.
    4TestingFull coverage of PSP22 contract with integration tests. Both for contract usage and deployment. We will be testing arguments' & return values' types correctness.

    Milestone 3 - Optimization. Improve type system of the generated code.โ€‹

    NumberDeliverableSpecification
    0aLicenseMIT
    0bDocumentationWe will cover new-added features in documentation and usage examples.
    1Precise methods definitionsRefine definitions and bahavior of contracts methods (i.e. methods' arguments and returns), depending on namespace, call options and properties of the method, like payable & mutable. E.g. preamptive querying for transaction calls, controlled by a call options flag.
    2Methods' namesFormat methods' names in the output from original MethodTrait::method_name to more user-friendly methodName naming scheme, while resolving overlap in formatted names.
    3Contract classes extensionExtend generated contract classes with useful properties, normally available on the contract (e.g. address, name, signer, etc.). Rely on usage experience in doing so.
    4IDE hintsPrepare generated code to have more informattive IDE hints, based on both JSDoc and output typesystem itself (if needed). Rely on usage experience in doing so.
    5NPM PackageTranslate package's code to JavaScript upon deployment. Provide informattive CLI, when needed. Make sure to have a cross-platform CLI support.

    After this grant, we will be maintaining the project to keep up with new emerging ecosystem standards and also listen to issues from community and update the tool to make the process of transformation a nicer experience for the developers and teams.

    Additional Information โž•โ€‹

    We havenโ€™t applied for any other grant programs for this project.

    How did you hear about the Grants Program?

    Have a number of approved applications:

    - + \ No newline at end of file diff --git a/applications/uke-protocol.html b/applications/uke-protocol.html index 4a6c637aeca..16af73cdbfa 100644 --- a/applications/uke-protocol.html +++ b/applications/uke-protocol.html @@ -4,14 +4,14 @@ Uke Protocol PoC & App (revised) | Web3 Foundation Grants - +
    Skip to main content

    Uke Protocol PoC & App (revised)

    See the Grants Program Process on how to submit a proposal.

    • Team Name: Uke
    • Payment Address: bc1qttjsaqr0m8sxm46wnfdupzpl6rjemts3uxsuu5
    • Level: 1

    DISCLAIMERโ€‹

    This is grant proposal is very similar to one I had submitted previously. This was due to it being terminated, which you may view here.

    I have since severely changed the design of the protocol / project to provide a pallet-based architecture henceforth bringing more value. I realized the other proposal was not sustainable anyways (contract-based architecture), and this future-proofs and brings more value to the ecosystem as a whole.

    I hope mitigate any sort of conflict as interest as there was before. Please let me know if this is sufficient!

    Project Overviewโ€‹

    Overviewโ€‹

    The Uke Protocol is a p2p, completely distributed messaging protocol. It utilizes local cryptography and a Substrate blockchain instance to verify, send, and receive messages in real time - just like any other conventional messaging protocol, and can be used to construct messaging apps, or any other application in which real time messaging is needed.

    Substrate is a key part of this solution, as uke essentially defies the need for any sort of traditional backend in favor of a completely DLT based infrastructure.

    Initially, the PoC for this phase will be messaging app, however key components will be built that will allow for many more applications in the future. The eventual goal is a universal messaging protocol that can be implemented anywhere, and is not dependent on any one centralized backend.

    The purpose of this messaging app is to have it entirely independent of any third party service for both messaging and users - a true representation of web3.

    There is more to uke than just peer to peer messaging - itโ€™s to demonstrate a lot more can be created with DLT than just another cryptocurrency. Rather than exchange currency one another, uke aims to take those same concepts and apply them to data and messaging.

    I am passionate about bringing more value to web3 via this sort of application - something that can be used by people, but also in a wider context of businesses and confidential, secure messaging.

    Project Detailsโ€‹

    Project Expectations & Goals

    The initial goal for this grant is to allow for the development of a PoC of this messaging protocol in the form of a mobile app.

    In the future, as the protocol becomes more defined, the goal is to develop a suite of SDKs and docs centering around secure and confidential messaging for any use case - with Substrate and its extensive functionality being the core of the solution.

    Uke has a few primary goals and standards to upkeep:

    1. Privacy - each message sent is completely, and purely, peer to peer - no one else can intercept or decrypt the message.

    2. Fault Tolerance / Reliability - By using DLT, we remove the need for a central server, meaning as long as an amount of nodes are kept online, users can still talk to one another. This is especially useful in emergency scenarios, as users can even opt to run their own nodes to ensure 100% runtime.

    3. Anonymity - since each user is essentially just a cryptographic key paired with an id, userโ€™s can easily stay anonymous on and off chain if they so wish to choose.

    Technology Stack

    For the front end, Ionic will be used for all web, Android and iOS versions.

    The backend will purely be DLT based - for this one, a Substrate instance will be run to send messages back and forth between accounts. A custom pallet to interact and properly store messages in Substrate storage will be developed to do so.

    Below are the summarized languages / tech stack

    • Typescript / Javascript
    • Rust
    • Ionic

    High Level Architecture

    As a general overview, each message will be a signed extrinsic, and each user is essentially merely an account on the blockchain.

    Components

    For the purposes of defining the Uke PoC / MVP, the initial functionality of the uke pallet will only handle messaging and message storage. However, in the future, it is planned to implement further functionality, such as a more robust identity registrar and account filter system.

    1. UKE PALLET

    Using Substrate allows for the creation of a custom pallet, which will have two primary functions for this PoC:

    • Handle message transmission and conversation storage (via a few key StorageMaps for managing active and ongoing conversations).

    • Basic identity mapping (register() function to allow for a mapping of BoundedVec<u8> to AccountId for easy lookup).

    The messages will be stored and read from the Substrate storage via a common StorageMap for the time being. Functionality will be included to retrieve the conversation state without having to load all messages as well.

    In order to identity unique conversations, an ID (convo_id) is used to retrieval the correct conversation between two particular users. This id is generated by hashing the sender and recipient addresses to create a unique, yet deterministic way to identity conversations in storage.

    For identifying each user, a mapping for cryptographic addresses to more human readable names will also be created within the pallet. It essentially it maps unique, human readable ids to otherwise illegible addresses.

    With this mapping of addresses, users can then look up other users and add them to their contacts, or write them a new message, or any other package of data in theory.

    1. Substrate Instance

    The Substrate Instance will allow for all messages to be propagated, consensus to take place, as well as smart contracts to be deployed in a guaranteed environment as needed.

    1. Uke Messaging App

    The eventual conclusion, and primary deliverable of this proposal is representing all of the aforementioned technology into an easy to use, hybrid mobile app that will be released for use. This app can be used across either Kusama or custom Uke networks, whatever is deemed fit upon launch. The app will encrypt messages on the client side, where the encrypted text will be stored within the Substrate node.

    Mockups and Design of PoC App

    Keep in mind these are mockups, and are subject to change

    Ecosystem Fitโ€‹

    The eventual goal is to provide a streamlined way to for the following in the Substrate / Polkadot ecosystem:

    1. Provide a common, and easy to use identity solution
    2. Provide an out-of-the-box, flexible, and confidential messaging protocol which can be used for many different usecases.

    The target audience here is our own user-base eventually, but also developers through opensourcing all work done here along with documentation on how one can also setup their own messaging using our tools.

    Currently, there is no standard for how one can build a dapp quickly, and that does something common. This can serve as a baseline for how a dapp can function without the use of cryptocurrency or the like.

    What makes us different:

    1. No traditional backends are used here. Everything is purely based off of Substrate, as shown in the architecture diagram.

    2. In our designs, the use of DLT/blockchain is not shown - this is intentional, as it allows users to merely experience a secure messaging experience without the cumbersome interface.

    Teamโ€‹

    Team membersโ€‹

    • Bader Youssef - Team Lead, Architect, and Fullstack Developer.

    Contactโ€‹

    • Registered Address: N/A
    • Registered Legal Entity: N/A

    Team's experienceโ€‹

    Bader has previously built over systems on both Ethereum and the NEM/Symbol blockchain - part of which you may see on his Github. He mainly has focused on creating front-end applications and architecture around purely DLT architectures for multiple companies. He is proficient in a number of programming languages and protocols, as well as general solution architecture for both low and higher level software.

    Some notable projects include:

    1. A PoC IoT device that logged sensor data directly to a blockchain. This included a custom UART serial protocol to convert Arduino code to blockchain transactions.

    2. Portable battery powered nodes, utilizing a Raspberry Pi. (I'd like to do this for Substrate as well!)

    3. The nftize project, an app that allowed for anyone to convert a physical asset to a digital one with ease.

    4. Implementing Shamir secret sharing for an "offline multi sig" and private key sharding model.

    5. A supply chain tracking system in which crop from the US was tracked to Japan over a private NEM blockchain instance.

    In his spare time, he also wrote many articles centered around using blockchain in practical and real world scenarios, which you may find here: https://iodlt.com/iodlt-blog/

    He is also published on Hackernoon, with articles gaining some traction (plans to write more!): https://hackernoon.com/u/crackTheCode

    If any more proof / material is needed, then it will be provided!

    Team Code Reposโ€‹

    The eventual code regarding uke will reside in the following repository:

    Team LinkedIn Profiles (if available)โ€‹

    Development Statusโ€‹

    There is currently a WIP repo that is being constructed in parallel with this proposal, which will be shared as soon as possible. To clarify:

    • A working pallet is currently in place for sending and receiving messages.

    • The front end is mostly implemented for the mobile app, along with a login / signup system using polkadotjs & the Keyring APIs.

    • The initial architecture is all complete, with pallet development very active.

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-Time Equivalent (FTE): 1 (one) for the duration of the project
    • Total Costs: $9,000 USD

    Milestone 1 โ€” Implement Uke Pallet for Basic Message Storage & Identity Functionalityโ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: $4,500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how anyone can deploy the pallet in their own Substrate node, as well as properly run unit tests for the Uke pallet.
    0c.Testing GuideThe pallet will be unit tested to the maximum with proper documentation and justification.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Uke PalletFully functioning pallet that allows for the transmission and storage of user conversations as well as a basic global identity mapping.
    1a.Uke Pallet - Conversation StorageStore conversations and messages in the Substrate node.
    1b.Uke Pallet - Basic Identity SchemeStore a mapping of user addresses to usernames for readability and easy user lookup.

    Milestone 2 โ€” Front-end completion, Substrate & polkadot.js integration into Ionic Appโ€‹

    • Estimated Duration: 1 month
    • FTE: 1
    • Costs: $4,500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how anyone can build the Ionic project for iOS, Android, or web.
    0c.Testing GuideThe front-end will contain a minimum of 50% unit test coverage, of which these will be covered in the guide.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will write a full blog post on Hackernoon & Medium on how Uke was created, what powers it, and what exact work was completed on it (as well as future goals).
    1a.Uke Ionic Application: Data ModelsCreate the appropriate data structures and models to represent users, accounts, and messages coming from a Substrate instance.
    1b.Uke Ionic Application: Login and Signup ServiceUsage of the polkadot.js SDK to create, store, and secure user account's locally. Proper authentication guards will also be created for the Ionic application.
    1c.Uke Ionic Application: Message Delivery & ConfigurationCreate the necessary services for messages to be retrieved, sent, and verified from a Substrate instance.
    1e.Uke Ionic Application: In-App Notification SystemA minimalistic notification system for notifying users of in-app events, such as received messages.

    Future Plansโ€‹

    In the short term, I plan to begin marketing a beta program for this project in order to gain user feedback and viability. Based off of this, I will further the protocol as needed.

    Short Term Goals

    • Gather initial feedback for the app
    • Immediate planning to streamline the protocol
    • Design uke SDK and developer docs for others to use
    • Demonstrate uses of web3 beyond cryptocurrency

    Longer Term Goals

    • Develop separate Identity, Account Filter, & Messaging Pallets for common Substrate use.
    • Implement a encrypted pub-sub protocol directly into the Substrate node.
    • Develop client-side appropriate modules for business use
    • "Disappearing", or temporary secure messaging
    • Optional payment integrations for users, if applicable
    • Custom Substrate Uke network implementation for private or public use

    Additional Informationโ€‹

    How did you hear about the Grants Program?

    I found it while exploring the Polkadot / Substrate ecosystem for development purposes.

    • Work you have already done.

    I already have completed a significant part of the front end work, all that is needed is the Substrate and polkadotjs implementation.

    • If there are any other teams who have already contributed (financially) to the project.

    None, this is an independent project.

    • Previous grants you may have applied for.

    I have applied once, and the grant was terminated due to the code being too similar to another repo. This has been recitifed, and I have embarked on creating a completely original pallet, with any engineering inspirations behind it being cited as needed.

    - + \ No newline at end of file diff --git a/applications/uke.html b/applications/uke.html index 793f5c5c88f..8dd0c5a2c5f 100644 --- a/applications/uke.html +++ b/applications/uke.html @@ -4,14 +4,14 @@ Uke Messaging - PoC - Phase 1 | Web3 Foundation Grants - +
    Skip to main content

    Uke Messaging - PoC - Phase 1

    See the Grants Program Process on how to submit a proposal.

    • Team Name: Uke
    • Payment Address: bc1qttjsaqr0m8sxm46wnfdupzpl6rjemts3uxsuu5
    • Level: 1
    • Status: Terminated

    โš ๏ธ The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.

    Project Overviewโ€‹

    Overviewโ€‹

    Uke is a p2p, completely distributed messaging protocol. It utilizes local cryptography and a Substrate blockchain instance to verify, send, and receive messages in real time - just like any other conventional messaging protocol, and can be used to construct messaging apps, or any other application in which real time messaging is needed.

    Substrate is a key part of this solution, as uke essentially defies the need for any sort of traditional backend in favor of a completely DLT based infrastructure.

    Initially, the PoC for this phase will be messaging app, however key components will be built that will allow for many more applications in the future. The eventual goal is a messaging protocol that can be implemented anywhere, and is not dependent on any one centralized backend.

    The purpose of this messaging app is to have it entirely independent of any third party service for both messaging and users - a true representation of web3.

    There is more to uke than just peer to peer messaging - itโ€™s to demonstrate a lot more can be created with DLT than just another cryptocurrency. Rather than exchange currency one another, uke aims to take those same concepts and apply them to data and messaging.

    Personally, I am passionate about bringing more value to web3 via this sort of application - something that can be used by people, but also in a wider context of businesses and confidential, secure messaging.

    Project Detailsโ€‹

    Project Expectations & Goals

    The initial goal for this grant is to allow for the development of a PoC of this messaging protocol in the form of a mobile app.

    In the future, as the protocol becomes more defined, the goal is to develop a suite of SDKs and docs centering around secure and confidential messaging for any use case - with Substrate and its extensive functionality being the core of the solution.

    Uke has a few primary goals and standards to upkeep:

    1. Privacy - each message sent is completely, and purely, peer to peer - no one else can intercept or decrypt the message.

    2. Fault Tolerance / Reliability - By using DLT, we remove the need for a central server, meaning as long as an amount of nodes are kept online, users can still talk to one another. This is especially useful in emergency scenarios, as users can even opt to run their own nodes to ensure 100% runtime.

    3. Anonymity - since each user is essentially just a cryptographic key paired with an id, userโ€™s can easily stay anonymous on and off chain if they so wish to choose.

    Technology Stack

    For the front end, Ionic will be used for all web, Android and iOS versions.

    The backend will purely be DLT based - for this one, a Substrate instance will be run to send messages back and forth between accounts.

    Below are the summarized languages / tech stack

    • Typescript / Javascript
    • Rust
    • Ionic
    • ink! (where applicable)

    High Level Architecture

    As a general overview, each message will be a transaction, and each user is essentially merely an account on the blockchain.

    Components

    For the purposes of defining the Uke PoC / MVP, the initial functionality of both modules will be represented via an ink! smart contract. However, in the future, it is planned to become a full pallet as needs become more apparent. If it is preferred for the initial implementation to be a pallet, then we can arrange that.

    1. Human DNS Module / Contract (future pallet)

    Using Substrate allows for the use of an ink! Smart contract, which in this case is used for mapping cryptographic addresses to more human readable names, just like a DNS. We call this the Human DNS, and essentially it maps unique, human readable ids to otherwise illegible addresses.

    With this mapping of addresses, users can then look up other users and add them to their contacts, or write them a new message, or any other package of data in theory.

    1. Account Rules Module / Contract (future pallet)

    Users can define rules for whether they wish to be contacted or not, and who can contact them. They essentially can create whitelists to explicitly allow who is permitted to message that specific account, along with what data can be sent in the future.

    This measure prevents a common issue with phone numbers, email, and even other apps - spam. Using smart contracts ensures the rules are kept in place, and the user is safe from any malicious or unwanted messages.

    Each message is a transaction on the blockchain, which depending on the rulings, can be deemed valid or invalid. In theory, one could set up their own Uke messaging network with very specific rulings in the future.

    1. Substrate Instance

    The Substrate Instance will allow for all messages to be propagated, as well as smart contracts to be deployed in a guaranteed environment.

    It's worth noting that I plan to implement the concept of light clients into each client-side instance, so as to provide

    1. Uke Messaging App

    The eventual conclusion, and primary deliverable of this proposal is representing all of the aforementioned technology into an easy to use, hybrid mobile app that will be released for use. This app can be used across either Kusama or custom Uke networks, whatever is deemed fit upon launch.

    Mockups and Design of PoC App

    Keep in mind these are mockups, and are subject to change

    Ecosystem Fitโ€‹

    The eventual goal is to provide a streamlined way to for the following in the Substrate / Polkadot ecosystem:

    1. Provide a common, and easy to use identity solution
    2. Provide a way to define account rules and filters in order to customize what transactions, messages, or accounts can interact with an account.
    3. Provide an out-of-the-box confidential messaging protocol which can be used for many different usecases.

    The target audience here is our own user-base eventually, but also developers through opensourcing all work done here along with documentation on how one can also setup their own messaging using our tools.

    Currently, there is no standard for how one can build a dapp quickly, and that does something common. This can serve as a baseline for how a dapp can function without the use of cryptocurrency or the like.

    What makes us different:

    1. No traditional backends are used here. Everything is purely based off of Substrate, as shown in the architecture diagram.

    2. In our designs, the use of DLT/blockchain is not shown - this is intentional, as it allows users to merely experience a secure messaging experience without the cumbersome interface

    Teamโ€‹

    Team membersโ€‹

    • Bader Youssef - Team Lead, Architect, and Fullstack Developer.

    Contactโ€‹

    • Registered Address: N/A
    • Registered Legal Entity: N/A

    Team's experienceโ€‹

    Bader has previously built over systems on both Ethereum and the NEM/Symbol blockchain - part of which you may see on his Github. He mainly has focused on creating front-end applications and architecture around purely DLT architectures for multiple companies. He is proficient in a number of programming languages and protocols, as well as general solution architecture for both low and higher level software.

    Some notable projects include:

    1. A PoC IoT device that logged sensor data directly to a blockchain. This included a custom UART serial protocol to convert Arduino code to blockchain transactions.

    2. Portable battery powered nodes, utilizing a Raspberry Pi. (I'd like to do this for Substrate as well!)

    3. The nftize project, an app that allowed for anyone to convert a physical asset to a digital one with ease.

    4. Implementing Shamir secret sharing for an "offline multi sig" and private key sharding model.

    5. A supply chain tracking system in which crop from the US was tracked to Japan over a private NEM blockchain instance.

    In his spare time, he also wrote many articles centered around using blockchain in practical and real world scenarios, which you may find here: https://iodlt.com/iodlt-blog/

    He is also published on Hackernoon, with articles gaining some traction (plans to write more!): https://hackernoon.com/u/crackTheCode

    If any more proof / material is needed, then it will be provided!

    Team Code Reposโ€‹

    The eventual code regarding uke will reside in the following repository:

    Team LinkedIn Profiles (if available)โ€‹

    Development Statusโ€‹

    There is currently a WIP repo that is being constructed in parallel with this proposal, which will be shared as soon as possible. To clarify:

    • The front end is mostly implemented for the mobile app, along with a login / signup system using polkadotjs.

    • The initial architecture is all complete, with future plans for pallet development.

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-Time Equivalent (FTE): 1 (one) for the duration of the project
    • Total Costs: $9,000 USD

    Milestone 1 โ€” Implement ink! Human DNS & Account Rules Contractsโ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: 4,500 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how anyone can submit the contract to a valid Substrate node, as well as how to properly run unit tests for the contract in question.
    0c.Testing GuideBoth contracts will be unit tested to the maximum with proper documentation and justification.
    1.Human DNS ink! Smart ContractFully functioning smart contract, queryable that keeps a mapping of addresses to users, allowing for user IDs and accounts to be identified.
    2.Account Rules ink! Smart ContractFully functioning smart contract which maps rules to registered accounts. Each account is either "opted in", or out. Accounts can then set and define rules relating to who they wish to filter out from their messages.

    Milestone 2 โ€” Front-end completion, Substrate & polkadot.js integration into Ionic Appโ€‹

    • Estimated Duration: 1 month
    • FTE: 1
    • Costs: 4,500 USD

    ...

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how anyone can build the Ionic project for iOS, Android, or web.
    0c.Testing GuideThe front-end will contain a minimum of 50% unit test coverage, of which these will be covered in the guide.
    0d.ArticleWe will write a full blog post on Hackernoon on how Uke was created, what powers it, and what exact work was completed on it (as well as future goals).
    1a.Uke Ionic Application: Data ModelsCreate the appropriate data structures and models to represent users, accounts, and messages coming from a Substrate instance.
    1b.Uke Ionic Application: Login and Signup ServiceUsage of the polkadot.js SDK to create, store, and secure user account's locally. Proper authentication guards will also be created for the Ionic application.
    1c.Uke Ionic Application: Message Delivery & ConfigurationCreate the necessary services for messages to be retrieved, sent, and verified from a Substrate instance.
    1e.Uke Ionic Application: In-App Notification SystemA minimalistic notification system for notifying users of in-app events, such as received messages.

    Future Plansโ€‹

    In the short term, I plan to begin marketting a beta program for this project in order to gain user feedback and viability. Based off of this, I will further the protocol as needed.

    Short Term Goals

    • Gather initial feedback for the app
    • Immediate planning to streamline the protocol
    • Design uke SDK and developer docs for others to use
    • Demonstrate uses of web3 beyond cryptocurrency

    Longer Term Goals

    • Develop Human DNS and Account Ruling Pallets for common Substrate use
    • Develop appropriate modules for business use
    • "Disappearing", or temporary secure messaging
    • Optional payment integrations for users, if applicable
    • Custom Substrate Uke network implementation for private or public use

    Additional Informationโ€‹

    How did you hear about the Grants Program?

    I found it while exploring the Polkadot / Substrate ecosystem for development purposes.

    • Work you have already done.

    I already have completed a significant part of the front end work, all that is needed is the Substrate and polkadotjs implementation.

    • If there are any other teams who have already contributed (financially) to the project.

    None, this is an independent project.

    • Previous grants you may have applied for.

    This is my first time applying to the Web3 grants program.

    - + \ No newline at end of file diff --git a/applications/unified_collator_node_deployment.html b/applications/unified_collator_node_deployment.html index d90eaed2761..9d726be6722 100644 --- a/applications/unified_collator_node_deployment.html +++ b/applications/unified_collator_node_deployment.html @@ -4,14 +4,14 @@ Unified deployment for the collator node | Web3 Foundation Grants - +
    Skip to main content

    Unified deployment for the collator node

    • Team Name: Blaize.tech
    • Payment Address: 0x7a83b5F20e69dfFe2c8FC942b54b159460C3D3d2
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    This application is the response to the Polkadot Collator Setup RFP

    Overviewโ€‹

    The main goal is to provide production-ready deployment for the Collator node that could work for any parachain with very few adjustments.

    There are a lot of parachains in the substrate ecosystem, and each of them has its guide on how to spin up a collator node astar, datahighway, moonbeam, hydradx, oak. Most of those guides are just examples of how to start a collator for testing purposes and are not production-ready. That complicates life for those who want to manage collators for several parachains because each new parachain requires an entirely new setup. We aim to pack a common part of infrastructure and Collator node deployment into functional building blocks that could be used with any parachain and make it highly extendable and configurable for each specific case.

    Every collator node has common steps to run it that do not depend on concrete parachain:

    • build
    • containerize
    • terraform infrastructure
    • deploy

    All of that could be automated and templated for all existing and parachains future. Even if building and containerization are relatively simple tasks, most teams handle them in their own way, sometimes far away from IaC best practices. Unfortunately, there is still no unified way approved \ recommended by Web3 so we aim to fill this gap.

    Project Detailsโ€‹

    First, we want to start from two unified Dockerfile templates for building and running collator node that suits best practices like minimal runtime, no root user, minimal port exposure, etc. Those templates could be easily extended with all required dependencies if needed.

    The next step is to provide reproducible and configurable infrastructure via terraforming one of the supported clouds. In most cases, Collator nodes have similar requirements on infrastructure, but in case of special requirements, it would be pretty easy to configure terraform scripts for the needs.

    Last step that requires most of the confgurability is a deployment step which would be handled by ansible scripts. We would provide unified deployment with configuration for the relay chain and common Collator parameters.

    Componentsโ€‹

    • Terraform deployment of the Collator infrastructure to the corresponding AWS and GCP clouds
    • Ansible scrips for the configurable deployment of a Collator node for different parachains

    Technologiesโ€‹

    • Docker as virtualization for the collator node
    • Terraform as IaC for the reliable and reproducible infrastructure deployment
    • Ansible as deployment automatization tool

    Ecosystem Fitโ€‹

    Currently, most parachains provide a setup guide on how to run the Collator on bare metal; however, it is neither automatized (hence non-reproducible) nor suits high availability standards. Our solution will provide most parachains with the out-of-the-box instrument for spinning up Collator. That would increase the reliability of the existing parachains as they may utilize reliability, high availability and scaling of Kubernetes. As well will significantly reduce the time and cost of spinning up the Collator for those who want to support several parachains

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Mark Tsyrulnyk - Blockchain Solutions Architect at blaize.tech, CTO at momo.finance
    • Oleksandr Bortnik - Senior DevOps at blaize.tech

    Contactโ€‹

    • Registered Address: Sichovykh Striltsiv St, 20, Dnipro, Dnipropetrovsk Oblast, 49000. Ukraine
    • Registered Legal Entity: LIMITED LIABILITY COMPANY "BLAIZE TECHNOLOGY"

    Team's experienceโ€‹

    Blaize is a blockchain development company with 5+ years of experience and 60 people on board. Core expertise: DeFi, app development, smart contracts development, and security audits.

    Team Code Reposโ€‹

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2.5 months
    • Full-Time Equivalent (FTE): FTE 1.5
    • Total Costs: 24500 USDT

    Milestone 1 Unify collator node deploymentโ€‹

    • Total Estimated Duration: 2.5 months
    • Full-Time Equivalent (FTE): FTE 1.5
    • Total Costs: 24500 USDT
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationDocumentation includes a comprehensive guide of deployment options, recommended infrastructure and minimal requirements, step-by-step guide on how to deploy, maintain and monitor the collator node
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive infrustructure tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.ArticleWe will publish an article that explains the architecture, possible tweaks and benefits of using a unified collator deployment solution
    1.Unified Infrastructure as CodeTerraforming scrips and deployment scripts for spinning up a Collator node on AWS and GCP clouds
    1a.Terraform scripts for setting up Collator infrastructureConfigurable deployment via terraform to Kubernetes cluster running on AWS and GCP clouds
    1b.Ansible scripts for spinning up Collator nodeConfigurable scripts to run collator node over the infrastructure

    Future Plansโ€‹

    • Provide more vendor-specific deployment like Azure, Vultr, IBM Cloud etc.
    • Provide different tiers for Availability \ SLA for the collator node

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/universaldot-me.html b/applications/universaldot-me.html index bc3ece57f18..3e8e0b29120 100644 --- a/applications/universaldot-me.html +++ b/applications/universaldot-me.html @@ -4,7 +4,7 @@ universaldot.me | Web3 Foundation Grants - + @@ -19,7 +19,7 @@ https://github.com/UniversalDot/universal-dot-node

    Front-End: https://github.com/UniversalDot/universal-dot-front-end

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Design/Infrastrucutre/Substrate Modulesโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic video tutorial that explains how a user can create profiles, tasks and organization. This will demonstrate basic functionality.
    0c.Testing GuideUnit tests for each pallet. We will include documentation on how to run tests. (Using Mocks)
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an medium/blog article that explains the main features of our dApp.
    1.Substrate module: ProfileWe will create a Substrate module that will create user profiles with some metadata such as reputation, interests. See Additional Information
    2.Substrate module: TaskWe will create a Substrate module that will enable users to create and publish tasks. These tasks will have task requirements and promised reward. See Additional Information
    3.Substrate module: DAOWe will create a Substrate module that will create organization which will collect different tasks and users. See Additional Information
    4.Substrate chain (testnet)Modules will be deployed to the substrate runtime and will run on a testnet network.

    Milestone 2 โ€” UI Implementation/support Pallets?/ Reference dAppโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide inline documentation of the code. This documentation will be build with rust doc and published on designated subdomain to be easily accessible by the community.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the repo description, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an User Manual that explain how to interact with the application.
    1.React module: ProfileWe will create a React module that will display blockchain information from Substrate Profile Pallet via RPC. The user will be able to input, delete this data from the UI.
    2.React module: TaskWe will create a React module that display task information and will enable users to assign tasks.
    3.React module: DAOWe will create a React module that will enable user to create decentralized organizations.
    4.App moduleWe will create a React skeleton app with basic theming for the application. This app will contain all new modules mentioned above.
    5.Substrate chain (mainnet)Launch mainnet comprised of new substrate modules together with React modules.

    ...

    Future Plansโ€‹

    In the short term we expect the enhance the functionality of the product using Substrate Builders Program.

    We expect to launch a native token from a treasury account. The native coin will be a utility token, and each token will represent unit value of work done (tasks completed on the network).

    In the long run, we expect to become Polkadot Parachain.

    Additional Informationโ€‹

    Use Case Diagram Architecture Design

    Additional Requirement: Each pallet will be provide Weight Estimation for each extrinsic using Benchmarking.

    Bellow are provided minimal requirements/implementation details for each pallet.

    Note: The final version may contain more storage items and functions.

    Profile Pallet

    HashMap Profile <Key: AccountID, value: profile> 

    profile: {  
      owner:
      balance:
      interests:
      reputation
    }

    RPC Methods: 
    create_profile(origin: OriginFor<T>, interests: Vec<u8>) -> DispatchResult
    update_profile((origin: OriginFor<T>, interests: Vec<u8>) > DispatchResult
    delete_profile((origin: OriginFor<T>) > DispatchResult

    Task Pallet

    HashMap Task <Key: hash, value: task> 

    task: {
      creator:
      requirements:
      budget:
      state:
    }

    RPC Methods:
    create_task(origin: OriginFor<T>, requirements: Vec<u8>, budget: u32) -> DispatchResult
    start_task(origin: OriginFor<T>, task_id: T::Hash) -> DispatchResult 
    finish_task(origin: OriginFor<T>, task_id: T::Hash) -> DispatchResult

    DAO Pallet

    HashNMap Profile

    RPC Methods:
    create_organization(origin: OriginFor<T>, name: Vec<u8>) -> DispatchResult
    add_member(origin: OriginFor<T>, AccountID) -> DispatchResult
    remove_member(origin: OriginFor<T>, AccountID) -> DispatchResult
    add_task(origin: OriginFor<T>, AccountID) -> DispatchResult

    How did you hear about the Grants Program? Web3 Foundation Website

    - + \ No newline at end of file diff --git a/applications/universaldot.me.html b/applications/universaldot.me.html index 9c7a1e77744..54ca97d2081 100644 --- a/applications/universaldot.me.html +++ b/applications/universaldot.me.html @@ -4,7 +4,7 @@ universaldot.me | Web3 Foundation Grants - + @@ -20,7 +20,7 @@ https://github.com/w3f/Grant-Milestone-Delivery/pull/396

    The funding is requested to further scale up the team and development of additional features.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Roadmap Figure 2. Roadmap for 2022

    Overviewโ€‹

    Milestone 1 โ€” (Release 0.7)โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a external documentation of the new functionality
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an wiki document that explains what was developed and how users can interact with the functionality.
    1.Improve Profile,Task, Dao palletsRevamp pallets design with additional functionality.
    2.Tensorflow IntegrationIntegrate Tensorflow components into the existing technology stack.
    3.DAO RedesignComplete Redesign and reimplementation of DAO pallet and front-end application.
    4.IPFS Design DocumentCreate Design for integration of Substrate with IPFS.
    5.CI/CDComplete CI/CD pipelines and automated testing.
    6.Udot WikiComplete wiki documentation on how the open-source community can use the dApp to start digital organizations. Available at https://docs.universaldot.me

    Complete Github User Story breakdown of the milestone can be found here.

    Milestone 2 โ€” (Release 1.0)โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a external documentation of the new functionality
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an wiki document that explains what was developed and how users can interact with the functionality.
    1.IPFS integrationSubstrate pallet Integration with IPFS.
    2.Tensorflow IntegrationComplete integration of Tensorflow with trained ML models.
    3.Docker ComposeDockerize the whole stack (Docker Compose)
    4.Integration testsComplete Integration Tests Suite with >90 test coverage.
    5.Front-endFinalized React application with improved components and overall design
    6.Udot WikiComplete documentation on how the open-source community can use the implemented infrastructure to further build features. https://docs.universaldot.me/docs/build

    Complete Github User Story breakdown of the milestone to be updated [here] once Milestone 1 has been completed.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    We intend to create a start-up company out of this project.

    Thus, the funds will be used to further expand the team and continue development on the existing product.

    Additional Questionsโ€‹

    Profile Palletโ€‹

    CharacteristicDescriptionTypeEntry
    AccountIDPrimary ID for a profile. One profile per AccountIDPub keyAutomatic
    UsernamePersonal description of profileStringManual, Mandatory
    InterestsPersonal interests of the user. Can incorporate skills, preferences, etc.Array of StringsManual, Mandatory
    ReputationScore of points that the User has earnedNumberAutomatic
    BalanceCryptocurrency balance in the native chain coinNumberAutomatic
    PortfolioUser can showcase personal portfolio, additional description, etcString (may contain list of IPFS documents)Manual, Optional
    AvailabilityHours per week the User is AvailableNumber (approx. Or list of 10hr,20hr,30hr)Manual, Mandatory
    Profile HistoryPrevious work history of the UserArray of TasksAutomatic

    Task Palletโ€‹

    CharacteristicDescriptionTypeEntry
    TaskIDUnique Identifier for each taskHashAutomatic
    TitleTask Title that describes the taskStringManual, Mandatory
    RequirementsDefinition that specifies the requirements of the taskString (RichTextEditor?: JSON-Strigify)Manual, Mandatory
    BudgetThe budget for a taskNumberManual, Mandatory
    DeadlineExpected end time for the taskDatetimeManual, Mandatory
    AttachmentsAdditional information that is relevant to a task.File (Referenced by IPFS Hash)Manual, Optional
    KeywordsFew words used to filter the task (mainly used for the recommendation)Array of StringsManual, Optional
    FeedbackComments that are added to the task. Intermediary steps of communication between the initiator and volunteerStringManual, Optional
    Initiator?The User who created the taskAccoundIDAutomatic
    Volunteer?The User who Volunteered for the taskAccountIDAutomatic
    CurrentOwnerThe user who currently is working on the task and thus has ownership of it.AccountIDAutomatic
    RelatedGroup of tasks that are related to the current task.List of TasksManual
    StatusThe current status of the taskEnum [Created, InProgress, Closed] To be expanded?Automatic
    CreatedThe time the task was createdDateTimeAutomatic
    LastUpdatedTime when the task has been updatedDateTimeAutomatic
    CompletedTime when the task was completedDateTimeAutomatic

    DAO Palletโ€‹

    IDUnique identifier for an organizationUUID or similarAutomatic
    NameThe name of the organizationStringManual, Mandatory
    DescriptionBasic description regarding the organization, industry, and goalsStringManual, Optional
    OwnerThe account that owns the organization. The initial owner is the founder. Ownership should be able to be transferred to other accounts.Account IDAutomatic, Mandatory
    VisionDocument that describes company VisionString (Hash to IPFS Document)Manual, Mandatory
    MembersMembers that belong to an organizationArray of AccountIDManual, Mandatory
    TasksTasks that belong to a certain OrganizationArray of TaskIDManual, Mandatory
    ApplicantsUsers that have applied to join to a certain organizationArray of AccountIDAutomatic
    CreatedThe date when the organization was createdDateTime, BlockAutomatic
    LastUpdatedThe date when the organization had an updateDateTime, BlockAutomatic
    PropertiesCustom collection of properties that can be added.An array of ObjectsManual, Optional
    - + \ No newline at end of file diff --git a/applications/upgradeability-by-proxy.html b/applications/upgradeability-by-proxy.html index 1000af68681..ee5f63fa7e3 100644 --- a/applications/upgradeability-by-proxy.html +++ b/applications/upgradeability-by-proxy.html @@ -4,7 +4,7 @@ ink! Smart Contract Upgradeability | Web3 Foundation Grants - + @@ -77,7 +77,7 @@ an ink! directive that automatically generates the delegation methods.

    There's also the chance that some patterns or functionality would be better implemented directly into the smart contracts pallet, so that other features, unrelated to upgrades, can take advantage of them.

    Additional Information โž•โ€‹

    This proposal is slightly research oriented.

    - + \ No newline at end of file diff --git a/applications/uplink.html b/applications/uplink.html index 86960060184..145f5dc230d 100644 --- a/applications/uplink.html +++ b/applications/uplink.html @@ -4,7 +4,7 @@ UpLink | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ Figure 2. Architecture for the connectivity stack implemented for the Android app. The controller is shown on the left, while the model is shown on the right.

    This implementation consists of a Bluetooth Low Energy connectivity layer that manages the connectivity stack and all buffered I/O using native Android BLE frameworks. HypeLabs already maintains a production-grade implementation of such drivers, although those are deeply coupled with the Hype SDK, the companyโ€™s main product. For that reason, these drivers must be ported and isolated before being made available as a library dependency for other apps.

    One important aspect of this setup is the fact that, after connecting, the devices perform a handshake. This handshake constitutes a negotiation process between the two devices, with the intent of exchanging meta configurations and status information. The information includes whether the devices are connected to the Internet, for the purposes of role selection, and itโ€™s performed every time that this status changes. This handshake is performed in accordance with the Communication Protocol.

    Android Appโ€‹

    Figure 3. Mockup for the Android app. The screen on the left enables users to see their balance and to request transactions, while the screen on the right provides verified confirmation of a transaction request.

    The Android app enables users to manually request the implemented network functions. This app is simple in nature, since it is not the purpose of the project, but rather serves the purpose of testing and showcasing the networkโ€™s functions. Rather, other apps may implement the same functionality, simply by adding the implemented logic as a dependency, one that will be provided to the public in open source form and as a library dependency.

    The app is written in Java and built with Gradle, as is common for Android.

    Relay Serverโ€‹

    The Relay Server receives, decodes, and interprets requests from any Requester. This process of decoding and interpreting requests can be understood as the serverโ€™s Business Logic, according to the illustration in Figure 4. For example, the Relay Server must decide what Substrate API endpoints to call and in what order. As a result of that process, the server redirects the requests to the Substrate Network, and mediates the communications with the Requester. All cryptographic challenges are forwarded between the two as well, meaning that the Relay Server is not capable of faking transactions, although it does have visibility over the operations that occur.

    Figure 4. Architecture for the Relay Server, illustrating how a transaction request is relayed to the Substrate Network. Proxy devices query the Relay Server's API, which interprets the requests and propagates to the Substrate Network.

    The Relay Server is to be implemented as an AWS Lambda function that can be called publicly. Given that this server also integrates the Communication Protocol, it will be implemented in Java. It is also composed of a full fledged CI/CD pipeline, implying that updates to the deployment are easy to process. Given its implementation in Lambda, this server will be horizontally scalable, and capable of processing many millions of transactions per second.

    In future reviews, this logic should be optionally integrated directly into Substrate, with the intent of having Substrate and off-the-grid devices communicate end-to-end, without the need for mediators. However, due to the complexity of that endeavour, the Relay Server will replace that setup for an initial version.

    Ecosystem Fitโ€‹

    UpLink is targeted at the following audiences:

    Other similar projects can be identified, namely:

    UpLink can be distinguished from those projects because:

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    ModuleStatus
    BLE DriversPort needed
    Communication ProtocolDesign and implementation needed
    Relay ServerImplementation needed
    Android AppTemplates exist

    Some of the templates for the Android App can be found on HypeLabs' GitHub page.

    The Communication Protocol is not yet designed, since one of the key requirements of it is that it matches closely with the Substrate API. This is an exercise that will be performed given the grant, creating as output the design and implementation for a peer-to-peer protocol that relates one-to-one with the Substrate API. For this initial implementation, only a subset of Substrateโ€™s functions should be implemented, however.

    The Bluetooth Low Energy (BLE) Drivers already exist and are used by HypeLabs extensively in production environments. These drivers are a component of the Hype SDK (HypeLabsโ€™ main product) and need to be ported as an isolated binary dependency, since the Hype SDK will not be used for this project.

    Development Roadmap ๐Ÿ”ฉโ€‹

    DeliverableDescription
    BLE DriversAn implementation of a peer-to-peer communication framework using Bluetooth Low Energy.
    Communication ProtocolA binary peer-to-peer network protocol that mimics Substrateโ€™s API and I/O arguments.
    Relay ServerA server that mediates communications between the app and the Substrate network.
    Android AppAn Android app that implements the described functionality.

    Once the grant is obtained, the deliverables are to be met at the following times:

    WeekDeliverables
    1stNone
    2ndBLE Drivers (Implementation)
    3rdNone
    4thCommunication Protocol (Architecture and Design), Android App (BLE Binaries)
    5thNone
    6thRelay Server (Functions)
    7thNone
    8thAndroid App (Binary)

    Overviewโ€‹

    This submission proposes the implementation of a binary peer-to-peer communication protocol that mimics Substrateโ€™s API. This enables devices to communicate with Substrate even without Internet access, by relying on proxies.

    Milestone 1 โ€” BLE Driversโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationThe code will be documented inline with a format that enables for quick docs generation, such as Doxygen. The project also includes a README file with general guidelines, onboarding information, and licensing.
    0c.Testing GuideThe project will have a minimum test coverage of 50%. The testing process should be described in the README file.
    0d.Article/TutorialThe onboarding processes will be described in the README file.
    1.ImplementationThis deliverable consists of existing Android BLE drivers that will be ported to an isolated library dependency. The delivery will be in both source and binary form, and distributed on GitHub and HypeLabsโ€™ website.

    Milestone 2 โ€” Communication Protocolโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationThe code will be documented inline with a format that enables for quick docs generation, such as Doxygen. The project also includes a README file with general guidelines, onboarding information, and licensing.
    0c.Testing GuideThe project will have a minimum test coverage of 50%. The testing process should be described in the README file.
    0d.Article/TutorialThe onboarding processes will be described in the README file.
    1.Architecture and DesignThe protocol will be designed before being implemented, implying the design of binary packet formats, a security evaluation, and performance profiling. This delivery will be in the form of a document, including the design, the security assessment results, and the profiling results.
    2.ImplementationThe implementation will be open source and available as a binary library dependency. The source code will be available on GitHub, and the distribution will be made available on HypeLabsโ€™ website.

    Milestone 3 โ€” Relay Serverโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationThe code will be documented inline with a format that enables for quick docs generation, such as Doxygen. The project also includes a README file with general guidelines, onboarding information, and licensing.
    0c.Testing GuideThe project will have a minimum test coverage of 50%. The testing process should be described in the README file.
    0d.Article/TutorialThe onboarding processes will be described in the README file.
    1.FunctionsThe implementation will consist of a series of AWS Lambda functions that constitute the integration API. What functions those are will depend on the design of the Communication Protocol, since thereโ€™s a direct correlation between the API and the protocol. The functions will be available in source code form, on GitHub.

    Milestone 4 โ€” Android Appโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationThe code will be documented inline with a format that enables for quick docs generation, such as Doxygen. The project also includes a README file with general guidelines, onboarding information, and licensing.
    0c.Testing GuideThe project will have a minimum test coverage of 50%. The testing process should be described in the README file.
    0d.Article/TutorialThe app includes an onboarding tutorial available to users, which is shown automatically on the first run.
    1.BLE BinaryThe first delivery for the app will be a binary with the BLE Drivers integrated, but without any form of relay. This will work for testing one-on-one connectivity using BLE, as well as initial UI and UX testing.
    2.BinaryThe app will be available in binary form in the Android Play Store, available to everyone in the public. It can also be built from the public repository, since the app can be used as a template for other developers that wish to integrate the technology.

    Future Plansโ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website and personal recommendation.

    - + \ No newline at end of file diff --git a/applications/validated-streams.html b/applications/validated-streams.html index 349fde9e635..4b9c3b70c1a 100644 --- a/applications/validated-streams.html +++ b/applications/validated-streams.html @@ -4,13 +4,13 @@ Validated Streams | Web3 Foundation Grants - +
    Skip to main content

    Validated Streams

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Validated Streams is a consensus primitive that aims to simplify the process of creating decentralized reactive oracles by providing a mechanism for verifying the authenticity and veracity of the data being used.

    In brief, we are providing a mechanism for proving the occurrence of events streamed from a custom application collocated with each of the validator nodes, facilitating developers of arbitrary off-chain applications in creating on-chain oracles sourced by those applications in a decentralized manner. To ensure the reliability and integrity of the data submitted on-chain, we require that at least two-thirds of the validators witness the event and confirm that it have indeed occurred off-chain.

    By implementing Validated Streams on top of Substrate, we hope it could integrate with Substrate-based smart contracts, allowing developers to build more powerful and sophisticated applications that take advantage of features from both Validated Streams and Smart Contracts.

    Validated Streams is a part of a grander vision of proactive blockchain applications that interact richly with the off-chain world while still remaining trustless and decentralized, that our team has been pushing for some years, and is now building piece-by-piece as we keep seeking the best ways to realize it.

    Project Detailsโ€‹

    Diagram of Validated Streams, with Stream service ingesting events from an application, passing them to a gossip, which then leads to on-chain transactions, that, after block finalization, get forwarded back to the application. (validated-streams.drawio.png)

    A Validated Streams oracle proves the occurrence of off-chain events, after they have been witnessed by at least 2/3-s of its validators.

    Each of validator is a Substrate node that has an attached trusted client. The client submits hashes representing events that have been witnessed locally. Since a malicious client could fabricate data or censor it instead of reporting to the validator, it is necessary that the operators of validators don't trust other validators (or thirdparties in general) with the task of witnessing events, but run their own trusted clients, perhaps even collocating them with the validator node.

    To avoid swamping or stalling the chain with blocks containing as-of-yet-invalid events (especially in cases where trusted clients have just started witnessing an event), after receiving an event hash, the validator first gossips that hash, signed, to other validators (using Substrate's sc_network_gossip API). The event hash is submitted as an extrinsic only once it has been witnessed by 2/3 of the validators (weighted by stake).

    Afterwards, the event is finalized through any of the usual on-chain mechanisms (such as GRANDPA), and once final, is considered proven by the Validated Streams oracle.

    As it is possible for momentary disruptions or malfeasance of validators or off-chain services sourcing the data for events to cause the state recorded on-chain and the state existing off-chain to differ, we send the finalized event hashes back to the trusted clients, which can then, depending on the exact use case, use this information to, e.g. adapt its own state to on-chain proceedings, witness some form of correction to the finalized events, or report the discrepancy to its users/operators.

    As noted on the diagram, we are planning to use a gRPC protocol for the communication of hashes between the trusted client and the validator node, instead of the more usual JSON-RPC used throughout Substrate, since such an API would allow the final product to be immediately usable with a wider variety of commonly-used programming languages and software development frameworks, and we aim to make the final product as accessible as we can.

    Do note that because the trusted client only ever submits hashes, a separate product (say, IFPS) would be required for it to retrieve the actual event contents.

    We have implemented a proof-of-concept implementation of Validated Streams as we've explored the Substrate API.

    While the Validated Streams concept is generic enough to apply to some existing oracles and maybe even blockchains, we want to encapsulate it in a way that other developers could then use to implement their own blockchain solutions on top. As such, within the scope of this project we will not be creating a new blockchain/consensus network, but only a software package implementing the Validated Streams protocol on top of Substrate, plus the related documentation, tutorials, suggested deployment configurations, and the like. Developers would then be free to take that package and run their own chains validating the events they configure them to.

    In addition, we find it important to note that Validated Streams as currently envisioned would only work in chains where the total number/weight of validators is known, such as proof-of-stake or private/consortium chains; further research might be able to lift that limitation in the future, but this is again outside the scope of this grant proposal.

    Ecosystem Fitโ€‹

    Creating reliable oracles can be challenging, as making a protocol, ensuring the accuracy of the data being used, and finding the validators to run one are all hard problems. While the Validated Streams abstraction doesn't automatically solve all of those problems, it allows developers to re-focus on providing validators with accurate data without needing to worry about creating a whole new protocol.

    Once finished, Validated Streams could be used to create decentralized oracles that provide off-chain data to other parts of the Polkadot/Kusama ecosystem, such as blockchains or applications that connect to the network via Polkadot's interchain communication protocols, or just Substrate-based smart contracts in general. In that case, parachain and dApp developers would benefit from having another way to provide real-time data to smart contracts or to build decentralized applications that interact with the real world.

    In addition, we see a use for Validated Streams in the creation of hybrid off-chain/on-chain applications, where developers use it to write traditional applications that are linked to a blockchain using a "validated" output "stream" of events. This can enable traditional application developers (such as ourselves, outside the Cooperative) to build applications that are more secure and trustworthy, as they can rely on the validation provided by the Validated Streams service.

    And, finally, we see some potential use cases around sourcing data for decentralized AI models (where Validated Streams would allow for a single consensus dataset to be built and added to in real-time, without necessarily giving any centralized party a final vote on what's included), and the creation of decentralized news platforms (where parties contribute news stories or verify the accuracy of existing stories), but it is possible that both of those would require additional thought, research, and development before they can be realized.

    There are existing projects similar to Validated Streams, many of which we've taken inspiration from.

    A major one would be Chainlink. While both work on providing ways to create and use oracles, Chainlink is a standalone decentralized oracle network that integrates with a variety of blockchain platforms, while Validated Streams is a Substrate-based blockchain-building framework that can used by decentralized applications directly. Also, Chainlink uses a reputation-based system to ensure the reliability of the data being provided by its oracles, while Validated Streams uses a consensus mechanism based on concrete events being witnessed to ensure the accuracy of the data being used by oracles.

    While a Chainlink Feed pallet already exists within the Polkadot / Kusama network, we hope that by offering something more directly based on top of Substrate, we might provide a viable alternative for developers who don't necessarily want to use Chainlink itself.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Team leader: Bozhidar Marinov
    • Team: Salih Houadef
    • Advisors: Todor Kolev, Branimir Angelov

    Contactโ€‹

    • Registered Address: 47, "Cherni vrah" blvd, Sofia 1407, Bulgaria
    • Registered Legal Entity: Comrade Cooperative

    Team's experienceโ€‹

    Bozhidar has roughly 13 years of programming experience (started programming at 7) on a wide variety of projects, from web interfaces to games to backend systems to smart contracts. He was once a core developer of Godot Game Engine, actively interacting in the FOSS community and is currently a maintainer of Perper, a reactive microservice framework.

    Salih is a recent college graduate with experience in creating various decentralized systems, in particular Blocksharp, a blockchain framework based on an actor model, used to complete his master's thesis on decentralized voting systems.

    Team Code Reposโ€‹

    Team GitHub accounts:

    Team LinkedIn Profiles (if available)โ€‹

    Advisors:

    Google Scholar Profiles (only for research projects)โ€‹

    Development Status ๐Ÿ“–โ€‹

    The current prototype of the Validated Streams code lives in the https://github.com/comrade-coop/validated-streams repository. It's an initial draft that we used to figure out what we want to achieve and if it's possible to use Substrate for it. Now that we have this proof of concept, we are ready to go for a full implementation.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 1
    • Total Costs: 10,000 USD

    Milestone 1 โ€” Implementation of Validated Streams gossip using Substrate's GossipEngineโ€‹

    • Estimated duration: 1.5 month
    • FTE: 1
    • Costs: 5,000 USD

    While our initial prototype is roughly functional in terms of delivering witness signatures to other validators, it is currently doing that in a very hacked and insecure manner. For the first milestone, we are looking to change that to use Substrate's existing gossip, as well as clean up the code overall, while also getting some documentation and tests in order.

    Once this milestone is complete, we expect that Validated Streams would be able to deliver its main functionality of validating events, though it might not be the most robust yet to real-world network connectivity issues (and perhaps even to some kinds of malicious interference).

    NumberDeliverableSpecification
    0a.LicenseMIT (most of the code) / GPLv3 (any sections depending on Substrate Client)
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile and bash script that can be used to test all the functionality delivered with this milestone.
    1.Substrate pallet: Validated StreamsWe will create a Substrate pallet that will receive witnessed event extrinsics and communicate them to other Substrate pallets.
    2.Substrate module: Witnessed events gossipThe Witnessed events gossip module will implement part of the Validated Streams protocol as described above, gossiping signatures about event hashes witnessed by the validator node and submitting them to the Tx pool once enough signatures are collected.
    3.Substrate module: Stream serviceThe Stream service module will allow applications to connect to the validator node as a "trusted client", witnessing events observed in the off-chain world and receiving receipts of completed events.

    Milestone 2 โ€” Implementation of block deferral for blocks that contain unvalidated eventsโ€‹

    • Estimated Duration: 1.5 month
    • FTE: 1
    • Costs: 5,000 USD

    After refactoring our codebase and reworking the gossip protocol used, we would like to work on improving the behavior of the project in real-life conditions, by implement deferral for blocks that arrive before they have been fully witnessed and making any necessary adjustments after testing and benchmarking the code in live settings.

    Once this milestone is complete, we would consider the Validated Streams project functionally ready for incorporation in other projects.

    NumberDeliverableSpecification
    0a.LicenseMIT / GPLv3 (same as above)
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone, including Dockerfiles/scripts which set up simulated poor network conditions.
    0e.ArticleWe will write up and publish an English article on our blog, making sure to link it on HN and relevant Reddit communities, that explains the Validated Streams project, how it works in brief, and how it can be used by developers to create decentralized oracles for their applications -- including brief notes on what to consider when actually deploying such an oracle.
    1.Substrate module: Witnessed events block importThe Witnessed events block import module will defer blocks before handling them to GRANDPA until all witnessed events included in those blocks are confirmed by the Witnessed events gossip module -- as outlined above.
    2.Real-life testingWe will test the Validated Streams code in a real network, documenting our results, and making adjustments to the code if any performance or reliability issues surface.
    3..NET client sampleWe will deliver a .NET/C# sample application implementing an example trusted client that can be used by developers as a starting point for their own work.

    Future Plansโ€‹

    Our team is interested in utilizing the Validated Streams project as a key component in the development of Apocryph, a novel (and, we hope, revolutionary) blockchain platform designed to support proactive smart contracts, or "agents", that are capable of autonomously communicating with each other and taking action without the express need for human(/centralized) input. There, the Validated Streams project would allow agents on a future Apocryph platform to react to real-world events as those occur.

    In fact, we are currently exploring the possibility of building (and refining) our vision for Apocryph in a piecemeal fashion where we build each of the components that might be useful in other projects independently, before eventually combining them.

    In the shorter term, we will strive to maintain the repository, bugfixing and perhaps even new features, after the grant is complete, especially if there is interest in the project from outside parties.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? We found the grants program via GitHub Trending, while simultaneously discovering that Substrate would be a great fit for our project on accident. As that seemed like too good of a coincidence to pass up, we decided to apply.

    While our coop organization has received a previous grant from Aragon Nest for an unrelated project, this is the first grant we are applying to in regards to the Validated Streams project.

    We have worked on the code and vision for Apocryph for a few years now, ever since we noticed that many of our Cooperative's projects were facing very similar issues around moving data and organizing code--and deciding we could do better. While not all of our attempts in bringing it about have been successful, we have been slowly coming to better solutions, and hope that it will all click one day.

    - + \ No newline at end of file diff --git a/applications/validators_selection.html b/applications/validators_selection.html index b5065398a64..355d9fb9f35 100644 --- a/applications/validators_selection.html +++ b/applications/validators_selection.html @@ -4,7 +4,7 @@ Validators selection | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ I was already involved in a research phase of this project hence I'd like to make a final version.

    Project Detailsโ€‹

    The aim of this project is only a backend. The final result will be a Python flask application exposing its functionality via RESTful API

    Ecosystem Fitโ€‹

    This application will be used in a validators selection phase, thus all nominators are its audience. The project makes the selection process easier and more robust. To the best of my knowledge, there isn't a similar project.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    I have 4 years of industry experience as a data scientist and 6 years of academic experience in a multicriteria decision support field. The most relevant project is of course study regarding this topic with the preprint available here: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4253515 Other related projects:

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 Example โ€” Basic functionalityโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains how this algorithm works and how to use the software
    1.Next pairDevelop an algorithm for efficient calculations of the next pair to be compared to maximize the modelโ€™s information gain.
    2.Ranking calculationDevelop an algorithm calculating a score for each validator
    3.New dataDevelop a function for the data preprocessing
    4.Internal testingUnit tests covering the functionality and logic

    Milestone 2 (Testing)โ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains how this algorithm works and how to use the software
    1.DeploymentDeploy the code on a test server provided by the Grants Team or by myself.
    2.Test live environmentTest the server efficiency by checking an average response time for each endpoint and provide a report
    3.PolishingReach out for feedback to the Grants Team. Integrate final feedback on functional, as well as cosmetic changes like the way data are provided, configuration, etc.

    Future Plansโ€‹

    The possible extensions are:

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Personal recommendation

    - + \ No newline at end of file diff --git a/applications/vanguard.html b/applications/vanguard.html index 858caa0acff..4a4f97831cb 100644 --- a/applications/vanguard.html +++ b/applications/vanguard.html @@ -4,13 +4,13 @@ Vanguard | Web3 Foundation Grants - +
    Skip to main content

    Vanguard

    • Team Name: Veridise
    • Payment Address: Ethereum: 0x0f8a5076a56b7ECD761562551FAd11DF631447B2 (USDC)
    • Level: 2
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Decentralized Finance (DeFi) is taking off at a very rapid pace, and smart contracts running on the Polkadot ecosystem are starting to entirely revolutionize the landscape of modern commerce. However, as with any technological revolution, this transformation ushers new security challenges that must be tackled head on: Because financial transactions are automatically executed by DeFi apps, bugs and security vulnerabilities in these programs can โ€”and currently doโ€” lead to significant amounts of financial loss. For example, over the past year alone, there have been repeated occurrences of so-called โ€œflash loan attacksโ€, which exploit contract logic to manipulate the price of valuable assets, such as tokens, to obtain a purchase price well below its actual market value. In fact, according to many estimates, over 1.3 Billion dollars worth of funds have been stolen in the year 2021 alone, all because of some underlying software vulnerability. If such numbers are not staggering enough, add to this the fact that smart contracts are immutable once deployed: this means that there is no way to fix the vulnerability post-deployment even after the problem has been discovered.

    This is exactly why it is so crucial to ensure that the smart contracts on the Polkadot ecosystem are free of security vulnerabilities and that they function as intended before they are deployed on a distributed ledger. Here, at Veridise, our mission is to ensure the correctness of modern DeFi applications through state-of-the-art technology based on cutting edge formal verification research.

    Because many DeFi apps suffer from a common set of vulnerabilities (e.g., arithmetic overflows, flash loan vulnerabilities, transaction order dependence etc), a key component of the Veridise toolchain is a static analyzer, called Vanguard, for detecting such common vulnerabilities in ink! contracts. Because Vanguard is based on a technique called abstract interpretation, it is guaranteed to report a vulnerability if one exists (among the vulnerability types checked by Vanguard).

    Project Detailsโ€‹

    Vanguard is a static smart contract analysis framework written in C++. It runs a suite of vulnerability detectors, prints visual information about contract details, and provides an API to easily write custom analyses. Vanguard enables developers to find vulnerabilities, enhance their code comprehension, and quickly prototype custom analyses. The Veridise team has been designing the product vision of the Vanguard for quite some time. We will go over the project details and provide references below for more in-depth context.

    Static Analysis via Abstract Interpretation. At a high level, most static analyzers are based on a paradigm known as โ€œabstract interpretationโ€. Just as a regular interpreter for a programming language executes the program on some specific input, an abstract interpreter symbolically executes the program over sets of inputs.

    To make this discussion more concrete, consider a simple function F that takes an integer x and returns x2 (letโ€™s assume unbounded integers for the purposes of this discussion). A regular interpreter can tell us that F will return 2 when executed on 1 and that it will return 4 when executed on 2 etc. However, when we do abstract interpretation, we can ask questions about what F returns on entire sets* of inputs. For example, an abstract interpreter can tell us that F will return a value in the range [2, 10] when x is in the range [1, 5] or that the return value of F is always an even integer for any input x.

    So, how can an abstract interpreter do that? The key idea is to define the semantics of the programming language over some underlying abstract domain, where each element in the domain represents a set of inputs. Again, the best way to understand this concept is to contrast it against a standard interpreter for a programming language. We can think of an interpreter as a program that takes as input a mapping M from variables to concrete values and a code snippet S and produces a new mapping Mโ€™ from variables to values, as depicted below:

    drawing

    The idea behind an abstract interpreter is exactly the same except that it operates over abstract values, which are elements of an underlying so-called abstract domain. For instance, an abstract value could be an interval of the form [a, b] denoting a set of integers x such that a โ‰ค x โ‰ค b. Then, just a standard interpreter executes the program over a concrete input, an abstract interpreter executes the program over such abstract inputs:

    drawing

    So what does it mean to execute a statement over abstract values? Letโ€™s try to understand that through an example (again, assuming mathematical integers). Consider a statement like x = y+z, and suppose that our abstract values are intervals of the form [l, u]. If we know that y is in the range [a, b] and z is in the range [c, d], we can conclude that x is in the range [a+c, b+d]. This is precisely what we mean by abstractly (symbolically) executing a given statement! Now, how can we leverage abstract interpretation to detect smart contract vulnerabilities?

    Reentrancy Detection. One of the oldest DeFi attacks (responsible for the DAO Hack of 2016) is caused by โ€œreentrancyโ€, which occurs when a contract invokes a function of another contract before it finishes updating any necessary contract state (such as a contract variable tracking refunds). Since the target contract can invoke functions in the source contract (hence the name โ€œreentrancyโ€), this will cause the vulnerable contract to use stale values. This, in turn, can allow an attacker to access resources that they donโ€™t have any claim to. Commonly, such an attack is used to withdraw more funds from a contract than they actually have, as illustrated below:

    drawing

    How to detect them: Such reentrancy vulnerabilities can be detected by statically checking that no storage variables are updated after an external function is called. In particular, the static analyzer needs to compute which function calls can be made at every program point and which variables are updated. Then, if there exist two program points L1 and L2 such that (1) L1 can execute before L2, (2) L1 can invoke an external function, and (3) L2 can write to a storage variable, then there is a possible vulnerability in the code. It is worth noting that reentrancy vulnerabilities cannot be checked in a sound way using syntactic pattern matching โ€” e.g., storage variables may be updated in subtle ways due to pointer aliasing and external functions may be called in non-obvious ways (e.g., through other function calls).

    For more information, please refer to the following resources:

    • Veridise Whitepaper here
    • Veridise Docs here

    Ecosystem Fitโ€‹

    It is well-known that bugs in blockchain ecosystem can have catastrophic consequences. As it stands today, the security landscape within the Polkadot ecosystem is not as mature as other ecosystems such as Ethereum. This is due to insufficient security tooling infrastructure in the ecosystem. Currently, the Polkadot ecosystem does not have the static analysis, symbolic execution, and other security tooling products as other major blockchains. By building the static analysis tooling products for ink! contracts, the Polkadot security landscape is hardened by utilizing the expertise from the Veridise team.

    The target audience of the Vanguard analyzer are web3 developers who require a tool to ensure the robustness and security of their applications. Using the technical capabilities that Veridise provides, our project will meet the needs of the Polkadot community to harden their own ink! contracts away from commmon vulnerabilities such as DoS, ToD, Reentrancy, flashloan attack, and many others.

    To the best of our knowledge, there is no comprehensive security tooling product for ink! contracts. The best option that the developers have is to leverage Linting rules that are supported by ink! 3.0. It is well-known that linting rules can only handle local and shallow patterns and they are completely insufficient for expressing common but serious vulnerabilities such as flashloan and reentrancy attacks. The only similar one is the Slither tool for Solidity. However, Vanguard differs from the Slither project in multiple ways. First, Slither can only support Solidity. On the other hand, Vanguard is language-agnostic and can easily support different versions of ink! language. Second, according to the results from our recent research paper, by evaluating both tools on the entire smart contracts from Etherscan, Vanguard significantly outperforms Slither in terms of both false positives and false negatives.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Yu Feng
    • Jon Stephens
    • Ben Mariano

    Contactโ€‹

    • Registered Address: 7109 Midwood Pkwy, Austin TX, USA, 78736
    • Registered Legal Entity: Veridise INC.

    Team's experienceโ€‹

    Founded by a team of well-known professors and researchers from academia, Veridise's cofounders collectively have over 30+ years of experience in formal verification, program analysis, and security. Veridise develops cost-effective security audits tooling products for dApps, regardless of the programming language they are implemented in or what blockchain platform they run on. Leveraging our expertise in automated program analysis, Veridise provides state-of-the-art solutions for ensuring security of decentralized finance applications. If youโ€™re interested in learning more information, please consider visiting our prior research.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Before applying for the Web3 Foundation Grant, the Veridise team conducted the following research:

    • Published a research paper at the top-one security conference (Oakland'22) here
    • Published a blog post about the technique behind Vanguard
    • The focus for Vanguard will be automatic detecting common vulnerabilities on ink! contracts
    • Spoke with David Hawig and Alberto Navarro from the Parity team regarding the development of Vanguard and the Web3 Grant application

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 30,000 USDC.

    Milestone 1 โ€” Implement Core Vanguard Frameworkโ€‹

    • Estimated duration: 1 month
    • FTE: 2
    • Costs: 15,000 USDC
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains the high-level overview of Vanguard as part of the grant, followed by a set of extensive examples.
    1.Basic infrastructureWe will build the basic infrastructure that is shared by all incoming detectors, including callgraph, alias analysis, and data-flow analysis.
    2.Taint analysisMany detectors can be reduced to static taint analysis. We will implement it as part of the core analysis
    3.Generic Vanguard APIDesign and implement the generic API that will be extended by 3rd-party developers
    4.Basic DetectorsImplement basic detectors based on the core framework, including transaction order dependency, DoS, and uninitialized storage variables.

    Milestone 2 โ€” Implement Common Vulnerability Detectorsโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 15,000 USDC
    NumberDeliverableSpecification
    0a.LicenseGPLv3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleIn our medium website, we will publish an article that explains the functionality and usage of those detectors using real-world examples from the Polkadot ecosystem.
    1.Design unused-state detectorUnused-state variables can potentially increase the attack surface. We will implement a detector to identify unused-state variables
    2.Improve Flashloan DetectorThe current flashloan detector only works for very specific situations. It relies on someone calling balanceOf and tracks the taint to a transfer. I think that we can come up with a more generic version of the flashloan detector.
    3.Pay without Withdraw DetectorAdd a detector that looks for contracts that will lock funds by having a payable function with no way of withdrawing the token.
    4.Evaluation on ink! contractsCoordinate with the Parity community to collect a curated list of ink! contracts that will be used to evaluate the effectiveness of Vanguard.

    Future Plansโ€‹

    • We will promote the project by giving talks in the community, writing tutorials and videos.
    • We will also work closely with the developers and clients of the Parity ecosystem for getting feedback and refine our project.
    • Our long-term plan is to make the tool become one of the default auditing tools for the Parity ecosystem.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website / Parity team / personal recommendation.

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    • Our team collectively has over 30+ years experience in formal methods and static analysis, which setups the foundation of the project: https://veridise.com/#research
    - + \ No newline at end of file diff --git a/applications/ventur.html b/applications/ventur.html index 55139fe76d0..784f6091804 100644 --- a/applications/ventur.html +++ b/applications/ventur.html @@ -4,7 +4,7 @@ Ventur | Web3 Foundation Grants - + @@ -21,7 +21,7 @@ Previous roles include designing and executing IT systems for multi-billion-dollar construction projects. Technical business liaison, responsible for strategically implementing new technology solutions that improve business efficiency while meeting corporate business goals.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    If you've already started implementing your project or it is part of a larger repository, please provide a link and a description of the code here. In any case, please provide some documentation on the research and other work you have conducted before applying. This could be:

    An overview presentation on Ventur is available on Google Docs.

    Documentation of our core functionality and architecture are available on Google Docs.

    An early stage MVP of the NT-NFT pallet has been developed and is located on GitHub. We wrote up a summary of the NT-NFT palletโ€™s goals on our submission of the pallet to the 2022 Polkadot Hackathon North America Edition.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Implement contracted-payment-process and escrow Substrate Modulesโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide Dockerfiles that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains the functionality of the contracted-payment-process pallet and the escrow pallet, and goes through how you can launch template substrate nodes with those pallets from the pallet repos using Docker.
    1.Substrate module: escrowWe will create a Substrate module that will implement an escrow functionality allowing for rfp submitters to lock up funds for funding rfps.
    2.Substrate module: contracted-payment-processWe will create a Substrate module that will implement a contracted payment process, paying out over the duration of a contract with defined functionality for resignation and termination.
    3.Substrate chain - VenturModules escrow and contracted-payment-process will be integrated into Ventur and interaction between them will be enabled, allowing for contracted-payment-process to source funds from an escrow address.

    Milestone 2 โ€” Implement rfp-process and nt-nft Substrate Modulesโ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide Dockerfiles that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article that explains the functionality of the rfp-process pallet and nt-nft pallet, and goes through how you can launch template substrate nodes with those pallets from the pallet repos using Docker.
    1.Substrate module: rfp-processWe will create a Substrate module that will implement an RFP bidding and acceptance process.
    2.Substrate module: nt-nftWe will refine our Substrate module that implements non transferable nfts. These non transferable nfts can be used for professional certifications as well as proof of membership to an advocacy-dao, or for subscriptions.
    3.Substrate chain - VenturModules rfp-process and nt-nft will be integrated into Ventur and interaction will be enabled between the rfp-process and the contracted-payment-process and escrow modules.

    Future Plansโ€‹

    Short Term Development Plans:

    Long-Term Development Plans and Project Intentions:

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?
    Web3 Foundation Website and personal recommendation.

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    - + \ No newline at end of file diff --git a/applications/vera_defi.html b/applications/vera_defi.html index 557a46cd650..4680b706adb 100644 --- a/applications/vera_defi.html +++ b/applications/vera_defi.html @@ -4,7 +4,7 @@ Vera Defi Phase 1 | Web3 Foundation Grants - + @@ -17,7 +17,7 @@ AssetManger was built in Ink to manage ERC721 deposit and ERC20 loans.
  • Are there are any teams who have already contributed (financially) to the project? Yes. Founders already invented in the project, founders are committed to keep investing in the project.
  • Have you applied for other grants so far? No.
    • - + \ No newline at end of file diff --git a/applications/verida_network.html b/applications/verida_network.html index 72824cd6a81..817684e9bc5 100644 --- a/applications/verida_network.html +++ b/applications/verida_network.html @@ -4,7 +4,7 @@ Verida | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ Nick is an experienced software professional with over 20 years of experience in a wide variety of roles. Prior to joining Verida he started and successfully exited an Artificial Intelligence company. He has significant experience in standards (eg W3C ActivityStream, JSR168) and open source (Apache Foundation).

    Verida Engineering Team The Verida engineering team consists of 6+ software engineers with expertise in Web3 development, Solidity smart contracts, Mobile Development and DevOps.

    Team Code Reposโ€‹

    A collection of Verida repos can be found here https://github.com/verida

    Repos relevant to this grant proposal include:

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We have made significant progress on the Verida roadmap, including releasing the Whitepaper, Alpha protocol, reference implementations, demos and developer documentation.

    The focus of this grant proposal is to build and enhance existing capabilities and make them developer-ready for builders in the Polkadot ecosystem.

    Verida Self-Funded Contributionโ€‹

    As part of this proposal, Verida will self-fund the software development to provide DOT support in the Verida Vault, and support for requesting a DOT payment via Verida decentralized messaging. This work will provide the necessary foundation to enable self-sovereign identity claims, verifiable credentials, encrypted personal data storage, single sign-on, and more for Polkadot as outlined in future milestones. Verida Self-Funded Contribution

    NumberDeliverableSpecification
    1DOT support in Verida Vault
    1a.Sign transactionsAdd PolkadotJS support into the Verida Vault to support signing transactions
    1b.Submit transactionsAdd PolkadotJs support into the Verida Vault blockchain API to submit transactions on chain
    1c.Transaction historySupport fetching and building up transaction history information for Polkadot addresses
    1d.On-chain eventsSupport listening to on-chain events relating to new transactions for Polkadot addresses
    1e.Transaction feeSupport for fetching and displaying transaction fee information
    1f.DOT token supportAdd support for the DOT token on the Polkadot parachain
    1g.DOT token priceSupport fetching price information for the DOT token
    1h.CAIP compatibility for PolkadotSupport CAIP compatible token specifications for Polkadot
    1i.Unit testsDevelop unit tests for all new capabilities
    2Support requesting a DOT payment via Verida message
    2a.Payment Request schemaDefine a new inbox message schema for โ€œPayment Requestโ€ message types that includes the recipient address and a description of the request purpose
    2b.Payment Request screensDesign new Verida Vault screens for handling โ€œPayment Requestโ€ inbox messages
    2c.Facilitating DOT paymentImplement an inbox handler that facilitates making a payment in DOT tokens to the requested address
    2d.Edge case handlingHandle edge cases such as insufficient DOT tokens
    2e.Purchase DOTRedirect the user to purchase more DOT tokens if required
    2f.Unit testsDevelop unit tests for the inbox handler
    2g.DocumentationDocument how Polkadot developers can initiate a Payment Request

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    See below for a summary of the software licencing for deliverables on the roadmap.

    NameDescriptionLicenceGitHub Link
    verida-jsThe core Verida protocol libraryISC (MIT equivalent)https://github.com/verida/verida-js
    Verida Account ExplorerA web front end showing details of each DIDISC (MIT equivalent)https://github.com/verida/account-explorer/
    Wallet-UtilsIntegration library between the Verida Vault and blockchainsISC (MIT equivalent)https://github.com/verida/wallet-utils
    Auth ServerDecentralized server that faciliates single sign-on connectionsISC (MIT equivalent)https://github.com/verida/vault-auth-server

    Milestone 1 - Single Sign-On for Apps in Polkadot Ecosystemโ€‹

    We are seeking a level 2 grant for the following deliverables:

    1. Single Sign-On (SSO) for DOT applications
    2. Implement generic transaction support for Polkadot
    3. Support requesting a Verifiable Credential from a Polkadot dApp
    4. Support storing encrypted personal data within a Polkadot dApp

    Single sign-on will provide users with a seamless experience for signing in across Polkadot dApps. Powered by Veridaโ€™s decentralized identity framework, these capabilities will allow users to maintain self-sovereign identity, without sacrificing on the user experience.

    We will provide the capabilities for developers to request verifiable credentials and build Polkadot dApps with encrypted data storage for private and sensitive data. This enables Polkadot developers to build user-oriented, privacy-preserving, feature rich dApps across industrial verticals including DeFi and metaverse.

    NumberDeliverableSpecification
    0a.LicenseISC (MIT equivalent)
    0b.DocumentationWe will provide both inline documentation of the code and update the necessary tutorials that explain how a user can use the application.
    0c.TestingCore functions will be covered by unit tests as far as reasonably applicable to ensure functionality and robustness. In the documentation, we will describe how to run these tests.
    0d.DockerN/A - We are not providing any infrastructure. All functionality can be tested via unit tests in the repo's.
    0e.ArticleWe will publish an article that explains what was done as part of the grant.
    1.Single Sign-On (SSO) for DOT applications
    1a.Establish SSO requestSupport establishing a SSO request for a Polkadot dApp
    1b.Link Polkadot to Verida DIDSupport linking a Polkadot account to a Verida DID account to unlock messaging and payment use cases
    1c.Show available Polkadot addressesSupport specifying a list of available Polkadot addresses for the user to select from
    1d.Specify Polkadot addressSupport a user specifying their Polkadot address during user sign
    1e.DocumentationDocument how Polkadot developers can establish a SSO request for a Polkadot dApp
    2.Implement generic transaction support for Polkadot
    2a.Support transaction signingSupport an application requesting a transaction to be signed by the end user
    2b.Support transaction submissionSupport an application requesting a transaction to be signed and submitted by the end user
    2c.Support signing any messageSupport an application requesting a message to be signed by the end user
    2d.Unit testsDevelop unit tests for the integration
    2d.DocumentationDocument how Polkadot developers can initiate a WalletConnect connection during user sign in
    3.Support requesting a Verifiable Credential from a Polkadot dApp
    3a.DocumentationDocument how a Polkadot dApp can make a Verifiable Credential request once connected
    4.Support storing encrypted personal data within a Polkadot dApp
    4a.DocumentationDocument how a Polkadot dApp can create, update, view, query and delete encrypted private data for a user of their application

    Future Plansโ€‹

    We will produce articles, tutorials and other content to promote the work completed in this grant proposal through our community channels.

    Off-chain Data Bridgeโ€‹

    Following the completion of this grant proposal, future capabilities on the Verida roadmap which could bring value to the Polkadot ecosystem include bridging off-chain personal data to on-chain decentralized applications.

    The Verida network stores personal data for end users. Every piece of data is signed by the originator of the data. For a patient record, a hospital visit may be signed by the doctor. For an insurance policy claim, a police incident may be signed by a police officer.

    Verida has developed a way to securely use this off-chain signed data as an input to smart contracts in a gas efficient manner. This capability unlocks a huge range of new use cases for smart contracts that can be leveraged by Polkadot applications.

    Expanding the Data Ecosystemโ€‹

    We are also developing an API Connector framework, trust framework and data schemas to enhance trust and enable growth in the Verida network. Once the Polkadot integration is complete, these capabilities can be unlocked for the broader Polkadot ecosystem.

    Supporting additional Polkadot Parachainsโ€‹

    Building on the foundational work completed as part of this grant proposal, Verida will be able to build support for additional parachains in the Verida Vault based on Chain Agnostic Improvement Proposal (CAIP) standards. Further examples and tutorials will be developed to support and enable developers.

    More details on our future plans can be found in the Verida Whitepaper.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program?

    Verida has had numerous conversations with Rohan Joseph and Surag Sheth from Parity Labs about Verida support for the Polkadot ecosystem.

    Work already completed

    Previous grants

    We have previously been successful in receiving grants from Open Web Collective and NEAR.

    - + \ No newline at end of file diff --git a/applications/visualize_rust_lifetime.html b/applications/visualize_rust_lifetime.html index fc81afcef9b..3debac23576 100644 --- a/applications/visualize_rust_lifetime.html +++ b/applications/visualize_rust_lifetime.html @@ -4,13 +4,13 @@ Avoiding Rust Deadlocks via Visualizing Lifetime | Web3 Foundation Grants - +
    Skip to main content

    Avoiding Rust Deadlocks via Visualizing Lifetime

    • Team Name: Song's research group at Pennsylvania State University
    • Payment Address: TBD
    • Level: 3

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Rust is a new programming language designed to provide both safety guarantees that are like high-level languages and performance guarantees that are like low-level languages. To achieve this design purpose, Rust leverages static compiler checks to rule out severe memory and thread safety issues at the compilation time. At runtime, Rust behaves like C/C++ and could deliver performance that is as good as C/C++. Due to its safety and performance benefits, Rust has seen increasing adoption in building low-level systems software, such as OSs and browsers. Rust is also used to implement many software systems in the Web3 technology stack (e.g., substrate, polkadot, ink!).

    Rust's compiler checks are based on a suite of ownership and lifetime rules. The basic rule allows one value to only have one owner variable, and the value is dropped (freed) when its owner variable ends its lifetime. Rust extends the basic rule to allow ownership to be moved and borrowed, while still guaranteeing all accesses to a value to be within its owner variable's lifetime scope. Besides safety checks, lifetime is also used for automated resource management. For example, there is no explicit Unlock() in Rust. A Lock() function call returns a reference to the protected variable, and when the reference ends its lifetime, Rust automatically releases the acquired lock (by implicitly calling Unlock()).

    Rust's lifetime rules are complex and different from all other existing languages. It is challenging for Rust programmers to infer where a variable's lifetime ends. As a result, it is not uncommon for programmers to incorrectly identify the location where an implicit unlock is called. When a lock is held longer than programmers' expectation, the same lock may be acquired again or a different lock may be acquired before releasing the acquired lock, leading to a double-lock error or a lock-in-conflicting-orders error.

    In our previous work [1], we conducted an empirical study on real-world Rust concurrency bugs. We inspected GitHub commit logs for five Rust applications and five Rust libraries to collect previously fixed concurrency bugs. In total, we found 37 deadlocks due to the misunderstanding of where the implicit Unlock() is called, including 30 double locks and seven locks acquired in conflicting orders. These deadlocks constitute almost all lock-related concurrency bugs (37/38) in our collection. They are all from popular Rust software systems (e.g., Servo, Parity-Ethereum, TiKV, Redox) and have severely hurt the reliability of those systems before they were fixed.

    A brief description of the project.We propose to build an IDE tool for visualizing the lifetime scope of a user-selected Rust variable. We believe our tool can help Rust programmers avoid deadlocks at the development stage. After writing a piece of code involving a mutex, a programmer can select the return value of a locking operation or the locking operation itself (when the return is not saved to a variable). Our tool will visualize the lifetime scope of the return value (i.e., the critical section). The programmer can then inspect whether the end of the critical section is expected. In addition, our tool will conduct deadlock detection for the selected critical section and provide detailed debugging information for identified bugs, such as highlighting blocking operations or function calls leading to blocking operations.How our tool will be integrated into Substrate/Polkadot?Both Substrate and Polkadot are implemented in Rust. Previously, double locks or locks in conflicting orders were fixed in Substrate [2, 3]. After applying our prototype, we identified four previously unknown double locks in Substrate or the dependent libraries of Substrate/Polkadot. We reported detected bugs. All of them were confirmed and fixed by developers [4, 5, 6]. We believe our tool will effectively prevent Substrate/Polkadot programmers from making similar mistakes and other types of mistakes our tool will reveal.Why are we interested in creating this project?We are interested in building the tool due to three reasons. First, our previous empirical study shows that deadlocks due to the misunderstanding of Rust's lifetime rules are common in Rust programs. Visualizing lifetime can avoid these bugs during the development stage, benefiting the whole Rust community. Second, the misunderstanding of Rust's lifetime rules can also cause memory bugs such as use-after-free and double free. Thus, the proposed tool has the potential to combat memory bugs. Third, the experience of building the proposed tool can inspire similar tools for other programming languages featuring lifetime (e.g., Kotlin).

    [1] Boqin Qin, Yilun Chen, Zeming Yu, Linhai Song, and Yiying Zhang. โ€œUnderstanding Memory and Thread Safety Practices and Issues in Real-World Rust Programs.โ€ In PLDI'2020.

    [2] https://github.com/paritytech/substrate/pull/197

    [3] https://github.com/paritytech/substrate/pull/6225/commits/61e3b8d53674687790d2b30bc450cd59e09f563d

    [4] https://github.com/paritytech/parity-db/pull/8

    [5] https://github.com/paritytech/substrate/pull/6277

    [6] https://github.com/paritytech/parity-common/pull/396

    Project Detailsโ€‹

    What have we already done?We have built a prototype of the proposed tool. Our prototype can visualize a selected variable and conduct double-lock detection. We published a demonstration paper at CCS'2020 to describe the prototype. The paper can be found here: https://songlh.github.io/paper/vr.pdf. We also recorded a video to explain the prototype, and the video can be found here: https://youtu.be/L5F_XCOrJTQ.

    We applied the double-lock detection component to Substrate, Polkadot, and ink!. We found four previously unknown deadlocks. One is in Substrate. The other three are in the dependent libraries of Substrate or Polkadot. We reported all the detected bugs. All of them were fixed by developers based on our reporting. The information of the detected bugs is listed as follows:

    [PR-1] https://github.com/paritytech/parity-db/pull/8

    [PR-2] https://github.com/paritytech/substrate/pull/6277

    [PR-3] https://github.com/paritytech/parity-common/pull/396

    What are we going to do?We propose to extend the prototype along four directions:

    First, we will integrate our existing implementation of lifetime computation and deadlock detection to rust-analyzer, so that our proposed technique can easily cooperate with different text editors.

    Second, we will detect more types of deadlock bugs. Specifically, we will add the detection of locks with conflicting orders and misuse of mutex and non-mutex synchronization primitives (e.g., channel, conditional variable).

    Third, we will identify and visualize more blocking operations that can potentially lead to deadlocks in a selected critical section such as receiving from a channel and waiting on a conditional variable.

    Fourth, we will implement the visualization functionality by parsing the analysis results generated by rust-analyzer in a text editor (i.e., VS Code) and document our tool.

    Ecosystem Fitโ€‹

    There is no existing project similar to ours.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Name of team leader: Linhai Song
    • Names of team members: Linhai Song, Yiying Zhang, Ziyi Zhang

    Contactโ€‹

    • Registered Address: Information of our legal structure will be disclosed privately.
    • Registered Legal Entity: Pennsylvania State University

    Team's experienceโ€‹

    The team conducted an empirical study on memory bugs and concurrency bugs in real-world Rust programs. The study was published in PLDI'2020. Through this project, the team has built a comprehensive understanding of common errors made by programmers when coding Rust.

    The team built a prototype for the proposed tool. The prototype was published in the demonstration track of CCS'2020, demonstrating the team's capability to build the proposed technique.

    The team has another research paper on understanding concurrency bugs in Go published in ASPLOS'2019. The team has more than three years' research experience on concurrency bugs.

    Team member Linhai Song has 10 years of expertise in programming analysis, and has published at top programming languages and software engineering conferences (e.g., PLDI, ICSE, FSE, OOPSLA).

    Team member Yiying Zhang has conducted various systems research with papers published at OSDI and SOSP.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    We have built a prototype of the proposed tool. We wrote one paper and recorded one video to describe the prototype.

    We applied the bug detection component of the prototype to Substrate, Polkadot, and ink!. We found four previously unknown deadlocks. We reported all the detected bugs and all of them were fixed based on our reporting [PR-1, PR-2, PR-3].

    [PR-1] https://github.com/paritytech/parity-db/pull/8

    [PR-2] https://github.com/paritytech/substrate/pull/6277

    [PR-3] https://github.com/paritytech/parity-common/pull/396

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    We will integrate the proposed tool into rust-analyzer and demonstrate the virtualization functionality in VSCode, which is an open-source IDE project. We will implement the proposed program analysis by analyzing Rust's MIR.

    We divide the project into three milestones. We aim to finish the whole project in three months and achieve a milestone in each month.

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 3
    • Total Costs: financial information will be disclosed privately.

    Milestone 1 โ€” Implement the bug detection componentโ€‹

    • Estimated duration: 1 month
    • FTE: 3
    • Costs: financial information will be disclosed privately.
    NumberDeliverableSpecification
    0a.LicenseBSD
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to run the bug detection component as a standalone tool on terminal.
    0c.Testing GuideWe will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs containing different types of deadlocks to demonstrate the bug detection capability. We will also run this component on the latest version of Substrate, Polkadot, and ink!. We will manually inspect all reported results to count the number of bugs and the number of false positives.
    1.Detecting Conflicting LocksWe will implement a detector that can identify deadlocks due to locks in conflicting orders through analyzing the MIR of Rust programs.
    2.Detecting Misuse of Mutex and ChannelWe will implement a detector to identify deadlocks due to errors when using a mutex together with a channel.
    3.Detecting Misuse of Mutex and Conditional VariableWe will implement a detector to identify deadlocks due to mistakes when using a mutex together with a conditional variable.
    4.DockerWe will provide a dockerfile to demonstrate the full functionality of this component.

    Milestone 2 โ€” Integrate the bug detection functionalities into rust-analyzerโ€‹

    • Estimated Duration: 1 month
    • FTE: 3
    • Costs: financial information will be disclosed privately.
    NumberDeliverableSpecification
    0a.LicenseBSD
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to install and use the changed rust-analyzer.
    0c.Testing GuideWe will also use the 10 toy programs designed in the last milestone to test whether the bug detection capability is successfully integrated into rust-analyzer.
    1.Extend Language Server Protocol (LSP)We will extend LSP to contain the key information related to deadlocks (e.g., the start and the end of a critical section, blocking operations in a critical section).
    2.Change rust-analyzer to emit MIRWe will change the build module of rust-analyzer to emit MIR for our bug detection functionalities.
    3.Conduct bug detection in rust-analyzerWe will change the analysis crate of rust-analyzer to execute the code for bug detection and change the server module to send the detection results out.
    4.DockerWe will provide a dockerfile to demonstrate the full functionality of this component.

    Milestone 3 โ€” Implement the visualization componentโ€‹

    • Estimated Duration: 1 month
    • FTE: 3
    • Costs: financial information will be disclosed privately.
    NumberDeliverableSpecification
    0a.LicenseBSD
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to install and use the visualization component in VSCode.
    0c.Testing GuideWe will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs to test whether channel operations are correctly identified, whether channel operations are correctly visualized, whether operations on conditional variables are correctly identified, and whether operations on conditional variables are correctly highlighted.
    1.Parse the Extended LSPWe will implement a component to parse the extended LSP and get computed information, such as the scope of a critical section and identified blocking operations.
    2.Highlight Blocking OperationsIf a selected variable is the return of a locking operation, besides visualizing the critical section, we will also highlight identified channel operations, conditional variable operations, and locking operations in the selected critical section.
    3.Tutorial WritingWe will write a tutorial and record a video to explain how to use our tool.
    4.DockerWe will provide a dockerfile to demonstrate the full functionality of this component.

    Future Plansโ€‹

    In the future, we plan to extend the proposed tool along two directions.

    First, we plan to extend the proposed tool to cover memory bugs. Our previous empirical study showed that there are also memory bugs due to misunderstanding Rust's lifetime rules, such as use-after-free bugs and double-free bugs. The proposed tool has the potential to help Rust programmers avoid these bugs. Of course, we need to explore what program elements should be visualized for memory bugs.

    Second, we plan to conduct a survey to understand what challenges programmers face when understanding Rust's lifetime rules and whether the proposed tool can really help them avoid deadlocks. The survey results will guide us on improving the proposed tool, and broadly speaking, the evolution of Rust.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    • Work you have already done.

    We have built a prototype of the proposed tool. We wrote one paper and recorded one video to describe the prototype.

    We applied the bug detection component of the prototype to Substrate, Polkadot, and ink!. We found four previously unknown deadlocks. We reported all the detected bugs and all of them were fixed based on our reporting [PR-1, PR-2, PR-3].

    [PR-1] https://github.com/paritytech/parity-db/pull/8

    [PR-2] https://github.com/paritytech/substrate/pull/6277

    [PR-3] https://github.com/paritytech/parity-common/pull/396

    • Wheter there are any other teams who have already contributed (financially) to the project.

    No

    • Previous grants you may have applied for.

    No

    - + \ No newline at end of file diff --git a/applications/vue-typescript-substrate-frontend-template.html b/applications/vue-typescript-substrate-frontend-template.html index 08345d48f95..3faf8e0d5ed 100644 --- a/applications/vue-typescript-substrate-frontend-template.html +++ b/applications/vue-typescript-substrate-frontend-template.html @@ -4,14 +4,14 @@ Vue.js + TypeScript Substrate Front-End Template | Web3 Foundation Grants - +
    Skip to main content

    Vue.js + TypeScript Substrate Front-End Template

    • Team Name: Wunderbar Network
    • Payment Address: 0x6F76BED39E9B9D57cAb4d9b81D65d2fa088cB68E (DAI)
    • Level: 2
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    When building our app (The Wunderbar Network team is part of the Substrate Builders Program), we have used a very useful existing community template - the Substrate Front End Template from the Substrate Developer Hub. This template is built using React.js and JavaScript. We are proposing to create an alternative version of this template, which would achieve three major outcomes:

    1) Create an extendable template app, where developers can quickly connect and interface with the Substrate blockchain, using simple, clear and strongly typed examples, with a great baseline UX (which could provide a starting point for an entire new project).

    This will build on top of what the current community template provides.

    2) It would use Vue.js instead of React.js

    According to StackOverflow's 2022 Developer Survey, React.js is still undeniably in the lead when it comes to web framework popularity (according to the survey, 42.62% of projects would be using React), however at 18.86% Vue.js is still in the top 6 and is on the rise.

    3) It would be written using TypeScript as opposed to JavaScript.

    Even though most developers who code in TypeScript can work well with JavaScript and vice versa, the "conversion" is not always straight-forward, and despite JavaScript being around for a very long time (and seemingly not going anywhere), TypeScript is gaining rapidly in popularity and most greenfield projects would prefer TypeScript over JavaScript.

    According to same survey mentioned above, JavaScript is the most commonly used technology (for the tenth year in a row!), however TypeScript is steadily closing in. Looking at the loved vs. dreaded category though, the picture is very different - TypeScript is loved by 73.46% of developers (and is near the very top of the list), whereas JavaScript achieved a score of 61.46% to be placed in the middle of the table.

    Overall, we believe that the combination of TypeScript's strong, static typing, and Vue's simplicity will together serve the purpose of providing an alternative source of very clear examples of how to interface with a Substrate Node from a modern front-end application, which should be of great value to the community.

    Project Detailsโ€‹

    The core technology stack is Vue 3 + Typescript, integrated with the Polkadot.js set of packages. The app will deliver Vue3 native components and "composables" (reusable functions), that other developers will easily be able to integrate/build on top of.

    The app will also provide a Dockerfile and container.

    We have created a mockup design (in both dark and light mode), screenshots below (we also have a high-fidelity Figma file that can be provided upon request).

    Dark version Light version

    Note that Wunderbar Network team is already using the same technology stack to consume Substrate blockchain features into the app we are building as part of the Substrate Builders Program, therefore we already have experience in both the core technology stack, and the Polkadot.js API packages.

    This grant will not include future ongoing maintenance of the deliverables, unless agreed prior (i.e. smaller grants to periodically refresh/keep up to date), or additional feature requests after the agreed milestone deliveries. We will however address reported bugs and major security vulnerabilities.

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem?

    This app provides a more robust and extendable example/template app compared to the current Substrate Front End Template app, which should be of great value to builders within the ecosystem, that are utilising the same or similar tech stack as ours.

    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

    Primarily UI developers, although any builders interfacing with Substrate would find value. New users, hackathon teams, etc - would also be strong contenders to use this app as a template/baseline for what they are building.

    • What need(s) does your project meet?

    The combination of TypeScript's strong, static typing, and Vue's simplicity will together serve the purpose of providing an alternative source of very clear examples of how to interface with a Substrate Node from a modern front-end application, which should be of great value to the community.

    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

    The Substrate Front End Template from the Substrate Developer Hub. Our project aims to provide a more robust example app, providing all the benefits and advantages mentioned above.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Dan Henton
    • Mila Dymnikova
    • Miloลก Ranฤ‘eloviฤ‡

    Contactโ€‹

    • Registered Address: Level 1, 320 Ti Rakau Drive, Burswood 2013, Auckland, New Zealand
    • Registered Legal Entity: Greengate Global Ltd

    Team's experienceโ€‹

    Wunderbar Network is a currently active participant of the Substrate Builders Program. We have extensive experience building Typescript + Vue.js apps, and interfacing with Substrate Nodes via API.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Not started yet, mockup designs/wireframes provided above.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 6 months
    • Full-Time Equivalent (FTE): 0.5 FTE
    • Total Costs: US$ 30,000.00

    Milestone 1 - Foundations + Header + Account panelsโ€‹

    • Estimated duration: 2 months
    • FTE: 0.5
    • Costs: US$ 10,000.00
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Foundations of a Vue.js appA standalone Vue.js/Typescript app (built using Vite)
    2.UI/UX elementsCommon UI/UX elements from the provided mockup designs for the Header, Balance Transfers and Account Balances panels
    3.ComposablesCommon composables to connect and interface with a Substrate node and all supported Web3 wallets
    4.HeaderProvide common Substrate node metadata and select an "active" account from a list of seeded and injected accounts
    5.Account Balance List & TransferProvide the ability to see the balances (and perform a transfer) between both seeded and injected accounts

    Milestone 2 - Runtime management, Event Panel and Pallet Interaction Composablesโ€‹

    • Estimated duration: 2 months
    • FTE: 0.5
    • Costs: US$ 10,000.00
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Runtime managementThe ability (via the header) to choose a Substrate Node connection and upgrade the runtime
    2.Event panelDisplay a panel which live-updates from global Substrate Node events
    3.Pallet interaction composablesComposables that are able to call queries, extrinsics, RPCs and read constants

    Milestone 3 - Complete Vue.js Appโ€‹

    • Estimated duration: 2 months
    • FTE: 0.5
    • Costs: US$ 10,000.00
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial.
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains [...] (what was done/achieved as part of the grant).
    1.Pallet Interaction PanelA panel that can execute extrinsics, RPC calls or display constants, using mapped parameters dynamically generated for each call, and displaying live events as the transaction transitions state
    2.Chain State Query PanelA panel that can display the chain state, optionally providing parameters, and displaying live events as the transaction transitions state

    Future Plansโ€‹

    We plan to promote this project within the development community. In case of significant Substrate/Polkadot.js API changes in the future, the app should be upgraded to reflect those (out of scope for the grant, as mentioned above).

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Via the Substrate Builders Program, networking with people from Parity/Web3 Foundation

    - + \ No newline at end of file diff --git a/applications/walt-id_nft-infra.html b/applications/walt-id_nft-infra.html index 1423cd4761b..5481e23be81 100644 --- a/applications/walt-id_nft-infra.html +++ b/applications/walt-id_nft-infra.html @@ -4,7 +4,7 @@ walt-id_nft-infra | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    walt-id_nft-infra

    Any implementation that is EVM compatible (e.g. Moonriver or RMRK with EVM bridge). Furthermore we will look into NFT specific solutions like Uniques FRAME pallet & Efinity.

    NFT infrastructure | by walt.id

    • Project Name: NFT infrastructure | by walt.id
    • Team Name: walt.id
    • Payment Address: Fiat (Mail: May 10, 2023, 8:55 AM)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Tagline: NFT infrastructure for Polkadot

    Goal: Offer the easiest and fastest way for developers to use NFTs on Polkadot via holistic open source (Apache 2) infrastructure and dev tooling.

    Project idea: This project will make NFTs on Polkadot available to developers and businesses across industries and around the globe. We will do so by building an open source NFT layer for Polkadot (and its Parachains). Technically speaking, we will extend our existing NFT infrastructure with an โ€œintegrationโ€ for the Polkadot ecosystem.

    Benefits for Polkadot:

    1. Dev Tooling: Developers will get new and powerful open source dev tools which will enable them to build new types of d/apps and services using NFTs on Polkadot. (This will be useful for d/apps from DeFi to marketplaces.)
    2. Traction: All our users/customers (public and private sector) will automatically be able to utilize the Polkadot ecosystem. In other words, we will funnel developers and business clients to the Polkadot ecosystem by making it accessible via our open source NFT infrastructure.
    3. Bridges to the โ€œold worldโ€: The project includes a component that enables backwards compatibility with todayโ€™s (web2) enterprise infrastructure like identity and access management tools (C/IAM; e.g. KeyCloak).
    4. Fueling adoption (Marketing): Walt.id is a top tier VC-backed startup that plans on fast growth (7-digits round, closure in Q4 2022/Q1 2023). Polkadot will strongly benefit from our marketing activities by participating at ecosystem events as well as our commercial enterprise activities. Our motivation: We are building an identity and NFT abstraction layer for enterprises. Consequently, we are adding support for more and more blockchains / web3 ecosystems and Polkadot is one of the most relevant web3 ecosystems.

    Project Detailsโ€‹

    Tech Stack: We will be using the following tech stack:

    • Walt.id solutions
      • Wallet Kit (incl. progessive web app, auth/exchange protocols like โ€œSign in with Ethereumโ€ or โ€œSelf-Issued OpenID Connectโ€, โ€ฆ)
      • NFT Kit (incl. OPA integration)
      • IDP Kit (incl. OpenID Connect integration)
    • 3rd party solutions

    More information about our solutions (incl. Architecture, APIs, data models) can be found in our docs https://docs.walt.id/ or on GitHub https://github.com/walt-id.

    Mock Ups/Designs: Please find some mock ups from our Cloud Platform here: https://drive.google.com/drive/folders/1zHGYcpRvjmWo9QXy9W24np80M10nugeH (Note: While the project will be open source under the Apache 2 license, weโ€™re currently building a managed service/SaaS that will re-use our open source libs to further facilitate use by developers.)

    Architecture: Please find a first high-level architecture of the planned project: https://drive.google.com/file/d/1-PYK6DbuTAOPx6covHkk224rvf7bJChV/view

    Relevant prior work: Our identity, NFT and wallet infrastructure solutions are already used by thousands of developers, governments, DAOs and enterprises across industries. Moreover, we already built / are building a number of similar projects for other web3 ecosystems like Etheruem, Polygon, IOTA, OCEAN, EBSI, Gaia-X, Velocity Network as well and other major web3 ecosystems which we cannot yet name.

    Scope: The project will be focused on building three infrastructure products, which will extend our current open source libraries:

    • Wallet Kit: Implementation of a wallet infrastructure that enables developers to extend their apps with the ability to view, manage and utilize NFTs.
    • NFT Kit: Implementation of an NFT infrastructure that enables the verification of NFTs (e.g. ownership, meta data) and against customizable verification policies. Our NFT solution will support the ERC721 ink-based implementation and the two pallet-based implementations (Uniques and RMRK).
    • IDP Kit: Implementation of an โ€œIDPโ€ (Identity Provider) that enables NFT-based authentication and access management for web2 apps.

    The following limitations follow from this scope:

    • The project is focused on enabling NFT โ€œutilityโ€ use cases (i.e. verification of NFT ownership and metadata) in a verticale agnostic way (as described above). However, in the future we foresee projects around minting of NFTs.
    • The deliverables are open source libraries, which are built for developers. We will not ship elaborate user interfaces or applications for consumers.

    Ecosystem Fitโ€‹

    Users: Developers

    Needs: NFTs are becoming a core technology to enable digital ownership of assets. At the end of the day, we believe that every asset will be tokenized and NFTs are a way of doing this. As a result, we see a growing need for solutions that make it easy for developers and businesses to build products with NFTs - in particular we see a need to realize the utility functions of NFTs such as in the context of access management. Recent projects by global brands like Starbucks (โ€œOdysseyโ€) reveal that the market is hungry for new applications of NFT that go beyond the simple tokenization of things.

    Value: We create value for

    • Developers
    • Businesses
    • Parachains / ecosystems based on Polkadot
    • Polkadot

    Similar Projects: There are no comparable projects according to our contact person at the web3 foundation. However, there is a number of organizations who are building Parachains and solutions in the NFT space like unique, RMRK, KodaDot, Enjin.

    USP: Enterprise-grade, open source NFT infrastructure layer for developers building on Polkadot.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Dominik Beron (Founder/CEO) - Business Lead
    • Phil Potisk (Founder/CTO) - Tech Lead
    • Severin Stampler
    • Kevin Burgmann
    • Walid Khemiri
    • Mike Plotean
    • Tamino Baumann
    • Fatima Beron
    • Raphael Baumann

    Contactโ€‹

    • Registered Address: LiechtensteinstraรŸe 111/115, 1090 Vienna, Austria
    • Registered Legal Entity: walt.id GmbH

    Team's experienceโ€‹

    Dominik Beron (CEO)

    • Serial entrepreneur and founder of walt.id
    • Law degree (Mag/JD) and executive education (from University of Pennsylvania and Oxford)
    • Advises EU Commission, governments, multinationals and top-tier consulting firms on web3, identity and tokenization
    • Co-author of Europeโ€™s new digital identity and wallet standards (EBSI, ESSIF)
    • Former advisor to the UN, Austrian Parliament

    Phil Potisk (CTO)

    • Serial entrepreneur and founder of walt.id
    • Software engineering and business economics degree (MSc).
    • +15y of work experience in software engineering
    • Built and led diverse tech teams
    • Built large-scale software-solutions for inter/national clients (Verisign, Telekom Austria, Infineon, Siemens, etc.)
    • Background in security, biometric passports and the corresponding inspection systems

    Severin Stampler (Chief Architect)

    • Software engineering and business economics degree (MSc).
    • +15y of work experience in software engineering
    • Built and led diverse tech teams
    • Built large-scale distributed systems in the field of AI/ML (e.g. NLP), big data, data processing, analysis, and retrieval

    Raphael Baumann (Business Development)

    • Serial entrepreneur
    • Business administration graduate at WU Vienna & ESADE Barcelona
    • +7y of building tech startups in the travel, sustainability, and web3 sector
    • Specialised on Go2Market, Fundraising, Company Strategy
    • Speaks English, Spanish, German

    Fatima Beron (People & Ops)

    • Business and economics degree
    • Former Founder / COO (Impact Venture)
    • Ex-Deloitte (Consultant)
    • Forbes 30 under 30 (by Forbes US)

    Walid Khemiri (Engineer)

    • Software engineering degree (BSc)
    • +5y of experience in engineering
    • 2y of experience in web3/NFT space

    Mike Plotean (Engineer)

    • Software engineering degree (MSc)
    • +8y of experience in engineering
    • Full-stack engineer with background in AR/VR

    Kevin Burgmann (Engineer)

    • 1st employee at walt.id
    • +5y of experience in engineering
    • 2y of experience in identity/SSI

    Tamino Baumann (Dev Advocate & Product Owner)

    • +3y of experience in engineering
    • Experienced dev advocate and customer success manager
    • (Incredibly smart and reflected generalist)

    Team Code Reposโ€‹

    Company GitHub

    Team GitHub

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    Libs/Repos

    Publications / Content

    • Whitepapers (e.g. whitepaper with BCG, NFTs for identity, SSI vs. NFTs)
    • Playbooks (e.g. NFT Playbook)
    • Blog (e.g. NFT Kit, IDP Kit) Also, we had a conversation with David Hawig about this project.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Milestone 1 โ€” NFT Kit + Wallet Kit + IDP Kitโ€‹

    • Estimated duration: 2 - 4 months, with final deliverys in Feb 2023.
    • FTE: 6
    • Costs: 29.750 USD (Total costs: 35.000 - 15% good will discount)
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
    0c.Testing and Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article or workshop that explains what was done/achieved as part of the grant.
    1.Architecture / DocumentationWe will plan and provide the architecture of the proposed project. (Note that the architecture may be updated / extended throughout the project based on learnings from the actual implementation.)
    2.Wallet KitImplementation of a wallet infrastructure that enables developers to easily integrate NFTs from the Polkadot ecosystem in any app (e.g. web3, banking, consumer products, marketplaces, โ€ฆ). In other words: Developers will be able to extend their existing apps with the ability to view, manage and utilize NFTs (e.g. for trading or access management). The Wallet Kit is developed in Kotlin and comes with a Docker container incl. REST API.
    3.NFT KitImplementation of an NFT infrastructure that enables developers to build holistic applications and end-to-end use cases based on Polkadot. In this first proposal we focus on enabling โ€œutilityโ€ use cases (e.g. ticketing, loyalty, vouchers, access). Therefore, the NFT Kit will enable the verification of NFTs across multiple dimensions (e.g. ownership, meta data) and against customizable verification policies (based on the Open Policy Agent). Our NFT solution will support the ERC721 ink-based implementation and the two pallet-based implementations Uniques and RMRK. The NFT Kit is developed in Kotlin and comes with a Docker container incl. REST API. Note, that it relies on 3rd Party libraries/services that also need to be hosted.
    4.IDP KitImplementation of an โ€œIDPโ€ (Identity Provider) that enables NFT-based authentication and access management for web2 apps. Backwards compatibility is enabled by transforming NFT verification results into tokens (e.g. JWT) that can be handled by potentially any web2 app (e.g. identity/access tools, messengers, website builders, eCommerce frameworks, CRM tools). The Wallet Kit is developed in Kotlin and comes with a Docker container incl. REST API.

    Future Plansโ€‹

    Walt.id has been funded by one of Europeโ€™s top tier early stage investors / VCs and we are just about to close another funding round (7-digits round, closure in Q4 2022/Q1 2023), less than a year after our pre-seed. This will help us to further extend our product portfolio and at the same time unlock a substantial amount of marketing budget in order to promote the usage of our tools within our supported ecosystems (like Polkadot). Hence by investing and launching our own professional commercial activities targeting developers and enterprises who potentially benefit from our tools, we will fuel the growth of the Polkadot ecosystem substantially. This includes participating at events, conferences, and hackathons. Further, we are planning on building our own dev community events and activities, in order to promote cross-chain collaboration and knowledge sharing.

    Summing up, we have big plans for the Polkadot ecosystem and we believe that Walt.id can become an integral part of it. Thatโ€™s why this first grant proposal is just the beginning, and we envision to build a holistic identity, NFT, wallet and storage infrastructure layer for developers and innovators building on top of the Polkadot ecosystem. As such, the project is aligned with our long-term goal of building an abstraction layer for every web3 identity and NFT ecosystems.

    Additional Information โž•โ€‹

    We heard about the program via the web3 foundation website.

    Further links that may be relevant incl:

    Content

    Products

    - + \ No newline at end of file diff --git a/applications/wasm-opt-for-rust.html b/applications/wasm-opt-for-rust.html index cd22f934435..e6a70ea7f20 100644 --- a/applications/wasm-opt-for-rust.html +++ b/applications/wasm-opt-for-rust.html @@ -4,7 +4,7 @@ wasm-opt for Rust | Web3 Foundation Grants - + @@ -64,7 +64,7 @@ get set up, and we did end up downloading the binary tarball, extracting it, and modifying our path. But the experience could be better.

    - + \ No newline at end of file diff --git a/applications/wasm_runtimes_fuzzing.html b/applications/wasm_runtimes_fuzzing.html index 2ca877fb644..d94801f642f 100644 --- a/applications/wasm_runtimes_fuzzing.html +++ b/applications/wasm_runtimes_fuzzing.html @@ -4,13 +4,13 @@ WebAssembly Runtimes Fuzzing (WARF) | Web3 Foundation Grants - +
    Skip to main content

    WebAssembly Runtimes Fuzzing (WARF)

    This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

    • Proposer: pventuzelo
    • Payment Address: 3An3qG2j5RJA3inJMVSzZ8uLp1T55JuL1M

    The above combination of your GitHub account and payment address will be your unique identifier during the program. Please keep them safe.

    Project Description ๐Ÿ“„โ€‹

    This project aim to improve security and resilience of WebAssembly runtimes and parsers using fuzzing. This project will help developers to audit automatically wasm runtime engines and identify security issues/bugs. Multiple fuzzing techniques will be used to achieve this goal but mainly grammar-based fuzzing and differential fuzzing. Complete documentation and user-friendly APIs will be provide to help developers to integrate new WebAssembly runtimes quickly and without any fuzzing skills.

    Team ๐Ÿ‘ฅโ€‹

    Patrick is an Independent Security Researcher specialized in vulnerability research, fuzzing, reverse engineering and program analysis. He is teacher of two training respectively about WebAssembly Security and Rust Security.

    Patrick found hundred of bugs in opensource projects mainly inside WebAssembly VMs and parsers. He is the author of Octopus, one of the first open-source security analysis tool supporting WebAssembly and multiple Blockchain smart contracts bytecode to help researchers perform closed-source analysis.

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 3 months
    • Total Costs: 4.5 BTC

    Milestone 1 - Discovery & project architectureโ€‹

    • Estimated Duration: 2 weeks
    • Costs: 0.75 BTC
    NumberDeliverableSpecification
    1.Integration PlanList of major WebAssembly runtimes used in Polkadot ecosystem and APIs to interact with them.
    2.Project developmentDevelopment of the project base (architecture and interface)
    3.APIsCreation of integration APIs + documentation
    4.Delivery reportTutorial for project installation and testings

    Milestone 2 - WebAssembly VM/parsers integrationโ€‹

    • Estimated Duration: 4 weeks
    • Costs: 1.5 BTC
    NumberDeliverableSpecification
    1.Runtimes IntegrationIntegration with previously listed runtimes engines.
    2.CLI toolCommand line tool allowing execution of wasm modules through all runtimes.
    3.Project developmentImprovement of the project (threading, runtimes perf monitoring)
    4.Project developmentDevelopment of fuzzing harness per runtimes.
    5.Runtimes dockersDockers to install runtimes engines easily
    6.Delivery reportsTutorial for runtimes installation, compilation, how to run tools and unittests
    7.Unittestunit test to verify all runtimes engines work as expected

    Milestone 3 - Fuzzing & improvementโ€‹

    • Estimated Duration: 4 weeks
    • Costs: 1.5 BTC
    NumberDeliverableSpecification
    1.Project developmentEvaluation fuzzing hardness + improvement
    2.Fuzzing ImplementationDifferential fuzzing implementation for wasm runtimes and parsers.
    3.Fuzzing ImplementationGrammar fuzzing implementation specific to WebAssembly module
    4.Project developmentImprovement of the fuzzing (input file sharing, mutation algorithm, speed).
    5.Delivery reportsTutorial for running fuzzers and use advanced CLI options
    6.Unittestunit test to verify fuzzing is deterministic and reproductible

    Milestone 4 - Performance & Documentationโ€‹

    • Estimated Duration: 2 weeks
    • Costs: 0.75 BTC
    NumberDeliverableSpecification
    1.TutorialRuntime integration tutorial
    2.TutorialUtilisation tutorial
    3.DocumentationInternal architecture
    4.DocumentationDetails fuzzing engines & techniques
    5.Performance testingImprove fuzzing performances and benchmarks

    Additional Information โž•โ€‹

    Some additional information :

    • I'm planning to support a maximum of wasm runtimes and parsers
    • The project will interact with runtimes implemented in different languages but mainly Rust, C, C++ and Go (potentially Python and JS)
    • Huge part of the project will be focused on improving fuzzing performance and create a friendly way to integrate new wasm runtime with the project.
    • Based on actual Polkadot hosts (Substrate, Kagome, Gossamer), I will start integrating parity-wasm, wasmi, wasmtime, wasmer and binaryen.
    - + \ No newline at end of file diff --git a/applications/wasmedge_substrate.html b/applications/wasmedge_substrate.html index 40f284cbff1..3bccb500b7e 100644 --- a/applications/wasmedge_substrate.html +++ b/applications/wasmedge_substrate.html @@ -4,13 +4,13 @@ WasmEdge for Substrate | Web3 Foundation Grants - +
    Skip to main content

    WasmEdge for Substrate

    • Team Name: Second State
    • Payment Address: 0xf212a28a62d01549c323a5feac7bbc8534064c41 (Ethereum USDT)
    • Level: 2
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Supporting WasmEdge as an alternative Substrate WebAssembly runtime. The project increases the Substrate ecosystem's node software diversity by supporting an alternative high-performance WebAssembly Runtime implementation. The project team are the maintainers of the WasmEdge WebAssembly Runtime project, and had successfully completed W3F projects in the past.

    Project Detailsโ€‹

    Software stack diversity (or โ€œdeveloper decentralizationโ€) is key to building a resilient blockchain network. As Ethereumโ€™s history has shown, the availability of multiple node software implementations, from GETH to Parity-Ethereum, has greatly improved network stability and security. When a critical bug is discovered or exploited on one implementation, the other would help sustain and stabilize the network.

    The Substrate framework and libraries are compiled into WebAssembly bytecode and run on a WebAssembly runtime in order to achieve safety and portability. It is therefore a low hanging fruit to support multiple alternative WebAssembly runtimes to improve software diversity at the foundation of the Substrate stack.

    Currently, Substrate runs on the Wasmtime WebAssembly runtime created by the Mozilla and Fastly team. WasmEdge is another leading WebAssembly runtime hosted by the Linux Foundation / Cloud Native Computing Foundation (CNCF). It is fully compliant to the WebAssembly specification as well as standard WebAssembly extensions. It is supported across many OSes including Linux, Windows, Mac OS X, seL4, and CPU architectures including x86, aarch64, and Apple M1. WasmEdge is among the fastest WebAssembly runtimes available today.

    Compared with Wasmtime, WasmEdge features a completely different software architecture. It is written in C++ and depends on the LLVM for runtime code generation, while Wasmtime is written in Rust and depends on Cranelift for dynamic compilation. That makes WasmEdge a compelling choice for improving Substrate software stack diversity.

    In this project, we propose to use WasmEdge as an alternative WebAssembly runtime for Substrate. We will create a software layer that allows users to choose between Wasmtime and WasmEdge when they build Substrate from source. We will also evaluate the performance characteristics of the two runtimes.

    Ecosystem Fitโ€‹

    The proposed project will bring an alternative runtime at the base of the Substrate stack and hence benefit the entire ecosystem.

    It could also bring Substrate developers communities closer to WasmEdgeโ€™s developer communities in cloud native (Linux Foundation / CNCF) and LLVM ecosystems.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Michael Yuan is the technical co-founder of Second State and ParaState. He is also the author of the book Building Blockchain Apps published by Addison-Wesley in 2019.

    Vincent Lin is the lead developer of the Substrate Ewasm Pallet based on WasmEdge. The pallet allows WasmEdge to act as an in-chain VM for Ethereum flavor WebAssembly smart contracts.

    Tim McCallum is a developerโ€™s advocate. He creates developer content, such as demos, tutorials, articles, videos, and podcasts, for blockchain developers.

    Antonio Yang is the lead developer of the Rust SewUp crate, which enables Rust developers to create Ethereum flavored WebAssembly application compliant to the EVMC interface.

    Contactโ€‹

    • Registered Address: PO Box 2075, #30 The Strand, 46 Canal Point Dr., Grand Cayman, KY1-1105, Cayman Islands
    • Registered Legal Entity: Second State Inc.

    Team's experienceโ€‹

    The team consists of maintainers and core developers of the open source WasmEdge project.

    The team has successfully completed a W3F grant in the past to adapt WasmEdge (previously known as SSVM) as an on-chain VM to execute Ethereum flavored WebAssembly (Ewasm) smart contracts.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Status ๐Ÿ“–โ€‹

    The WasmEdge Runtime is a fully standard compliant WebAssembly runtime hosted by the CNCF. Please see its github repository for key features and use cases. With LLVM-based AOT support, WasmEdge is one of the highest performing WebAssembly runtime available today.

    https://github.com/WasmEdge/WasmEdge#performance

    In the web3 ecosystem, WasmEdge is successfully adopted as an on-chain VM to execute Ethereum flavored WebAssembly (Ewasm) smart contracts on substrate-based blockchains.

    https://github.com/ParaState/substrate-ssvm-node

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 2 FTEs
    • Total Costs: $45,000 USD

    Milestone 1 โ€” Enable Substrate to run on WasmEdgeโ€‹

    • Estimated duration: 1 month
    • FTE: 2
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationProvide instructions for developers on how to use our forked repo to build and run Substrate with WasmEdge as the default WASM VM
    0c.Testing GuideProvide a step-by-step guide for building and running a Substrate blockchain on WasmEdge
    0d.DockerCreate Docker images with all build dependencies to faciliate the build process
    0e.ArticleCreate a blog article to annouce WasmEdge integration with Substrate
    1.Rust APICreate a wasmtime compatible Rust API for WasmEdge. That is because most of the existing Substrate hooks for WASM are designed for wasmtime's Rust APIs. To create a wasmtime compatible high-level API for WasmEdge will make the follow-up integration work much easier.
    2.Host wrapperCreate host wrappers for WasmEdge in Substrate. Those functions are in the client/executor/wasmtime package in the substrate source tree. We will create an alternative client/executor/wasmedge package, and use the wasmedge executor in our fork.
    3.TestBuild and test the entire Substrate project based on WasmEdge

    Milestone 2 -- Create docs and config options to select between multiple WebAssembly runtimesโ€‹

    • Estimated duration: 1 month
    • FTE: 2
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationProvide instructions for developers optionally select WasmEdge as the WASM VM for Substrate
    0c.Testing GuideProvide a step-by-step guide for selecting WasmEdge and then building and running a Substrate blockchain on WasmEdge
    0d.DockerCreate Docker images with all build dependencies to faciliate the build process
    0e.ArticleCreate a blog article to annouce Substrate's option to use WasmEdge
    1.SoftwareCreate configuration options to select between wasmtime and WasmEdge host wrappers. The option will allow the compiler / build system to choose between the wasmtime and wasmedge executors when building the substrate binary.

    Milestone 3 -- Performance benchmarks and analysisโ€‹

    • Estimated duration: 6 months
    • FTE: 2
    • Costs: 15,000 USD
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationProvide performance benchmark and profiler results
    0c.Testing GuideProvide instructions on how to run performance benchmark tests and performance profilers
    0d.DockerCreate Docker images with all build dependencies to run the benchmarks
    0e.ArticleCreate a blog article on WasmEdge's performance in Substrate
    1.ConfigMake sure that AOT is enabled for WasmEdge
    2.EvalCreate performance metrics Substrate integration tests for wasmtime vs WasmEdge, as well as WasmEdge interpreter vs AOT
    3.EvalIdentify performance bottlenecks in Substrate WasmEdge for future actions
    4.Upstream PRCreate and merge a PR for the Substrate project. Work with the Substrate team to make sure that the PR is up to the coding standard and testing requirements for Substrate to merge it.

    Future Plansโ€‹

    Our goal is to continuously improve WasmEdge's compatibility and performance in the Substrate environment, and hope to eventually become the default WASM runtime for Substrate.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website / Past grantee

    As discussed, the team has extensive experience with WebAssembly runtimes. We are the maintainers of CNCF's WasmEdge project, and had successfully completed past W3F grant projects in adopting WebAssembly for on-chain smart contracts.

    - + \ No newline at end of file diff --git a/applications/web3-compatible-api.html b/applications/web3-compatible-api.html index 16642588522..aee846138bd 100644 --- a/applications/web3-compatible-api.html +++ b/applications/web3-compatible-api.html @@ -4,13 +4,13 @@ Web3 Compatible API for Substrate EVM Chains | Web3 Foundation Grants - +
    Skip to main content

    Web3 Compatible API for Substrate EVM Chains

    Project Description ๐Ÿ“„โ€‹

    Project Moonbeam (https://moonbeam.network/) aims to create a Polkadot parachain that offers Ethereum compatibility. We envision Moonbeam serving as an easy entry point to Polkadot for existing Ethereum developers -- a place where Ethereum based Dapps can run with a minimal amount of changes required. We believe this will help drive adoption of Polkadot by reducing friction for existing Ethereum based projects and by providing compatibility and support for the rich set of Ethereum ecosystem tools such as Truffle.

    Substrate already includes key components needed to achieve Ethereum compatibility, most notably the EVM frame pallet which is a full EVM implementation in Rust, and a basic way to dispatch calls to the EVM. However, there are other critical missing pieces needed to achieve Ethereum interoperability. One of these is a Web3 compatible API that offers the same API as an Ethereum node. Another is Pallet-Ethereum, a Substrate runtime that Parity is developing that extends and enhances the way calls are dispatched to the EVM that is contained in Pallet-EVM.

    We are seeking grant funding to help build a Substrate based Web3 compatible API that will interface with Pallet-Ethereum. We plan to use this implementation as part of Moonbeam, but other projects that want to implement Ethereum compatible parachains or parathreads could also include them into their projects and benefit from them.

    Team ๐Ÿ‘ฅโ€‹

    The PureStake team has extensive experience developing and delivering complex web2 software systems. In the last year, PureStake has built a number of web3 infrastructure projects including Algorand API Services (https://developer.purestake.io/) and the Goalseeker block explorer (https://goalseeker.purestake.io/), among others.

    Derek co-founded Fuze in 2006 and as CTO was responsible for engineering, technical operations, product management, and design as the company grew over time into a 700 person cloud business. Alan was responsible for and hands on developed large parts of the Fuze cloud backend. Before joining Fuze, Alan was on the Google Streetview Team and also worked at NVidia developing drivers. Telmo has worked in a variety of roles as a backend engineer and is knowledgeable in C++, Rust, and a variety of backend data stores, data pipelines, and big data technologies.

    Development Roadmap ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 6 weeks
    • Full-time equivalent (FTE): 2 FTE
    • Total Costs: 2.5 BTC
    NumberDeliverableSpecification
    1.Substrate RuntimeWe will create a base Substrate runtime that will be capable of running Solidity based smart contracts that have been compiled to EVM bytecode, based on Pallet-EVM.
    2.Web3 RPC ModuleWe will deliver a working substrate module that implements the Web3 RPC API that can be added to a substrate runtime. The Web3 RPC module will depend on and require Pallet-Ethereum and Pallet-EVM. Note that Pallet-Ethereum is still under development by the Parity team. PureStake will assist Parity with the development of Pallet-Ethereum as necessary to demonstrate the scenarios below.
    3.Basic Transaction SupportRunning this module and its dependencies in a substrate runtime it will be possible to send a transaction between 2 EVM accounts using the standard Web3 API.
    4.ERC20 DemonstrationRunning this module and its dependencies in a substrate runtime it will be possible to deploy the Open Zeppelin ERC20 contract and exercise its transfer functionality.
    5.Truffle DemonstrationRunning this module and its dependencies in a substrate runtime it will be possible to configure Truffle to connect to the node to deploy smart contracts.
    6.Metamask DemonstrationRunning this module and its dependencies in a substrate runtime it will be possible to configure Metamask to connect to the node and send funds from one account to another.
    7.Unit TestsThe code will have proper unit-test coverage to ensure functionality and robustness.
    8.Docker ImageWe will build a Docker image with a substrate based chain, demonstrating its functionality.
    9.DocumentationWe will provide both inline documentation of the code and tutorials describing how the software can be used as well as how to deploy smart contracts. Code and documentation will be delivered according to the Web3 Milestone deliverables guidelines for each milestone.

    Additional Information โž•โ€‹

    We intend to use the developed module as part of our Moonbeam parachain project, however the functionality will not be Moonbeam-specific. We plan to first deploy Moonbeam to the Westend testnet, then to the Kusama network, and finally to the Polkadot mainnet.

    - + \ No newline at end of file diff --git a/applications/wika_network.html b/applications/wika_network.html index 6f24d2639c5..55e950ec7b4 100644 --- a/applications/wika_network.html +++ b/applications/wika_network.html @@ -4,7 +4,7 @@ wika.network | Web3 Foundation Grants - + @@ -66,7 +66,7 @@ As such, being able to present our project to a panel of experts, gather feedback and learn, would be fantastic for our team.

    So if our Grant request were to be approved, it would generate the right connections; and we would be set up for success to improve our blockchain codebase and graduate to mainnet afterwards.

    For these reasons, we are looking forward to starting a conversation with W3F, and as we learn, we are very open to re-visiting this request's scope and form together.

    - + \ No newline at end of file diff --git a/applications/workflow_testing.html b/applications/workflow_testing.html index fa4e7b2e38c..78779ee9038 100644 --- a/applications/workflow_testing.html +++ b/applications/workflow_testing.html @@ -4,13 +4,13 @@ DuoSwap Module | Web3 Foundation Grants - +
    Skip to main content

    DuoSwap Module

    • Team Name: Duo
    • Payment Address: 123mp123

    Contactโ€‹

    • Registered Address: High Street 1, London LK1 234, UK
    • Registered Legal Entity: Duo Ltd.

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Total Costs: 0.80 btc
    - + \ No newline at end of file diff --git a/applications/xNFT.html b/applications/xNFT.html index 474ff5d1df5..a5763949af3 100644 --- a/applications/xNFT.html +++ b/applications/xNFT.html @@ -4,13 +4,13 @@ xNFT | Web3 Foundation Grants - +
    Skip to main content

    xNFT

    • Team Name: Starks
    • Payment Address: 0x2492237FA7698B8F3B35F2be4be3B1128439Ec8d (USDC) **
    • Level: 1

    Project Overview ๐Ÿ“„โ€‹

    This application is in response to the open RFP xcm-tools

    Overviewโ€‹

    The Crosschain NFT Pallet is a unique initiative designed to facilitate the smooth movement of NFTs across various blockchain networks, utilizing the XCM protocol. Through the implementation of this pallet, individuals can effortlessly exchange NFTs between relay chains and parachains.

    Project Detailsโ€‹

    xNFT

    The xNFT Pallet provides the following extrinsics (functions):โ€‹

    1. transferSingleNFT(admin,collection_id, item_id, dest_collection_id, dest_item_id, mint_to, dest) โ€”> DispatchResult ; transfer an NFT with the NFT ID
      • admin โ€” the owner of the NFT being sent.
      • collection_id โ€” the ID of the collection of which the nft is being sent.
      • item_id โ€” the ID of the NFT being sent.
      • dest_collection_id โ€” the ID of the collection to which the nft is being sent.
      • dest_item_id โ€” the ID of the NFT being created.
      • mint_to โ€” the new owner of the NFT being sent.
      • dest โ€” a multilocation to define the destination address for the tokens being sent via XCM. It supports different address formats, such as 20 or 32-byte addresses (Ethereum or Substrate).
    1. transferMultiNFT(admin,collection_id, item_id, dest_collection_id, dest_item_id, mint_to, dest) โ€”> DispatchResult ; transfer multiple non-fungible tokens, defined by their multilocation
      • admin โ€” the owner of the NFT's being sent.
      • collection_id โ€” the ID of the collection of which the nft is being sent.
      • item_id โ€” the ID's of the multiple NFT's being sent.
      • dest_collection_id โ€” the ID of the collection to which the nft is being sent.
      • dest_item_id โ€” the ID's of the multiple NFT's being created.
      • mint_to โ€” the new owner of the NFT's being sent.
      • dest โ€” a multilocation to define the destination address for the tokens being sent via XCM. It supports different address formats, such as 20 or 32-byte addresses (Ethereum or Substrate)
    1. transferCollection(admin,collection_id, dest) โ€”> DispatchResult ; transfer a collection using collection id , defined by its multilocation
      • admin โ€” the owner of the collection.
      • collection_id โ€” the ID of the COLLECTION being sent.
      • dest โ€” a multilocation to define the destination address for the tokens being sent via XCM. It supports different address formats, such as 20 or 32-byte addresses (Ethereum or Substrate).
    2. transferCollectionOwnership(new_owner,collection_id, dest ) โ€”> DispatchResult ; transfer the collection ownership on another chain, defined by their multilocation
      • new_owner โ€” the new owner of the COLLECTION being sent.
      • collection_id โ€” the IDs of the COLLECTION being sent.
      • dest โ€” a multilocation to define the destination address for the tokens being sent via XCM. It supports different address formats, such as 20 or 32-byte addresses (Ethereum or Substrate).

    A feature will be added to the XCM VM for minting NFt on target chain using the encoded data from source chain.โ€‹

    This xNFT pallet will be tightly coupled with the NFT pallet in Substrateโ€‹

    Project does not include:โ€‹

    • This pallet does not let you create, mint or burn any NFT this just to send them to other chains by making use of the XCM functionality
    • This pallet will not be able to transfer any NFT that is not registered using the NFT pallet for Substrate(i.e NFT deployed as smart contracts).

    Ecosystem Fitโ€‹

    • The implementation of the xNFT pallet would introduce improved interoperability, expanded applications, increased liquidity, and enhanced flexibility to the Substrate ecosystem. It would foster the growth and vitality of the community, while facilitating seamless exchange and utilization of NFTs across different Substrate-based blockchains.
    1. Interoperability: The xNFT pallet would enable effortless transfer of NFTs across various blockchains within the Substrate ecosystem. This would enhance connectivity and compatibility between Substrate-based chains, promoting a more integrated and interconnected ecosystem.
    2. Expanded Applications: Cross-chain NFT transfers would unlock new possibilities and use cases for NFTs within the Substrate ecosystem. Developers and users would have the ability to leverage NFTs from different chains, enabling cross-chain collaborations, marketplace integrations, and enhanced utility for NFT-based applications.
    3. Improved NFT Liquidity: By facilitating cross-chain transfers, the xNFT pallet would enhance liquidity for NFTs within the Substrate ecosystem. NFTs from different chains could be freely traded and utilized, expanding their market reach and creating more opportunities for value exchange.
    4. Flexibility and Choice: The xNFT pallet would provide developers and users with the flexibility to choose the most suitable blockchain for their NFT requirements. They would be able to mint, transfer, and interact with NFTs on various Substrate chains, ensuring compatibility with specific needs or preferences.
    5. Ecosystem Growth: The introduction of the xNFT pallet would contribute to the growth of the Substrate ecosystem, attracting developers and projects interested in building NFT-related applications or platforms. This would foster innovation and expand the range of offerings within the ecosystem.
    6. Adoption of XCM: By utilizing XCM for cross-chain NFT transfers, the xNFT pallet would promote broader adoption of the Cross-Chain Messaging protocol within the Substrate ecosystem. This would reinforce the significance of interoperability and cross-chain communication, encouraging other projects and pallets to integrate XCM for various use cases.
    7. Community Engagement: The xNFT pallet would generate interest among developers, NFT enthusiasts, and users within the Substrate community. It would encourage collaboration, knowledge sharing, and participation in the development of cross-chain NFT solutions, further strengthening community bonds and promoting ecosystem growth.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    • Registered Address: C-208, Phase 8B, Industrial Area, Sector 74, Sahibzada Ajit Singh Nagar, Punjab 160059
    • Registered Legal Entity: AntLabs India Pvt. Ltd.

    Team's experienceโ€‹

    We are a skilled and dedicated group of professionals who possess extensive experience working with the Substrate ecosystem. Our team members have successfully completed numerous projects related to Substrate development, including building custom blockchains, implementing governance mechanisms, and designing smart contract for intuitive dApp functionalites. We understand the importance of technical partnerships in fostering innovation and growth within the blockchain industry. We are confident that our knowledge of the Substrate framework and its capabilities will enable us to contribute significantly to the development and expansion of Polka's ecosystem.

    Stack exchange profiles of some of our team members:

    1. https://substrate.stackexchange.com/users/3136/wakar-seraj-khan
    2. https://substrate.stackexchange.com/users/406/akash-singh
    3. https://substrate.stackexchange.com/users/4068/upendra-singh

    We are the technical partners for Peer Coin

    Development Status ๐Ÿ“–โ€‹

    xcm-tools

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” xNFT Palletโ€‹

    • Total Estimated Duration: 6 weeks
    • Total Costs: 9800 USD
    • FTE: 2
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can transfer nft across chains
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/workshop that explains [...] (what was done/achieved as part of the grant). (Content, language and medium should reflect your target audience described above.)
    1.xNFTWe will create a Substrate module that will handle cross-chain NFT transfers using these functions: 1. transferSingleNFT 2. transferMultiNFT 3. transferCollection 4. transferCollectionOwnership

    Future Plansโ€‹

    Currently this project is solely to transfer NFT between Substrate based chains. In future we plan to extend this functionality to non-substrate chains like Ethereum, Solana etc. We also plan to extend the functionality of this pallet to substrate based solo-chains as well(solo to solo). We will also add support to transfer NFT deployed to the chains as smart contracts.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? A friend recommended

    - + \ No newline at end of file diff --git a/applications/xbi-format-psp-t3rn.html b/applications/xbi-format-psp-t3rn.html index ba4be0e702e..fb222379254 100644 --- a/applications/xbi-format-psp-t3rn.html +++ b/applications/xbi-format-psp-t3rn.html @@ -4,7 +4,7 @@ XBI - xcm-based high-level standard and interface (ABI) for smart contracts | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ The state entry is updated with the output response to the requested XBI Payload. As such, it is available for trust-free validation on the requesting Parachain side by sending back the Witness that includes the dispatched call alongside accompanying bytes, which can be decoded to derive the status of the call after the inclusion has already been confirmed. We propose a form of Witness that should work with most external-to-Polkadot ecosystems; suitability will be assessed as part of the first Development Milestone.

    struct Witness {
        encoded_message: Vec<u8>, // Encoded message containing the call dispatch   
        trie_pointer: TriePointer, // Enum pointer, to a merkle tree in that block: state, transaction or logs   
        block_hash: Vec<u8>, // Pointer to a block including the message   
        merkle_path_proof: Vec<Vec<u8>> // Proof - a merkle path including message into block 
    }

    Location of XBI in the stackโ€‹

    XBI Format is a standard over XCM, enabling Parachains with effective communication to use the same interface with various smart contract VMs, installed both at local-to-Polkadot as well remote-to-Polkadot Consensus Systems.

    Communication using XCM Format traverses as follows:

    The above examples readability could also be enhances with the following example: (send XBIDefaultExecutor::call_custom) Moonbeam -> t3rn (send XBIRemoteExecutor::call_custom) -> Cosmos Bridge -> (native-to-Cosmos execution) Cosmos Chain -> Cosmos Bridge -> (send XBIExecutor::result) t3rn -> (receive XBIExecutor::result) Moonbeam

    XBI payload lifecycleโ€‹

    XBI payload lifecycle can be directed by developers using metadata. XBI Executors implement the functionalities allowing to handle the lifecycle:

    Metadataโ€‹

    Lifecycleโ€‹

    Expectationsโ€‹

    Ecosystem Fitโ€‹

    t3rn is a cross-chain smart contracts registry that enable smart contracts execution on multiple blockchians. The XCM-based Interface will come in a form of a FRAME pallet and will be used by t3rn and any other Substrate-based project that wishes to use it.

    The XBI Format and XBI Executors for cross-chain smart contracts will be tested live in a XCM Environment, such as the Rococo network with other selected Substrate builders.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    t3rn team - succesfully completed one Web3 Foundation grant to establish and implement the prototype of t3rn's cross-chain gateways and is now building as part of Substrate Builders Program.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Milestone 1 โ€” Produce PSP as a result of collaboration with Selected partners which sets requirements for XBI Format and XBI Executors Interfaceโ€‹

    NumberDeliverableSpecification
    1a.LicenseApache 2.0
    1b.DocumentationProvide both inline documentation of the code and a basic tutorial that establishes XBI Format. This assumes a series of consulations and feedback loops enhancing the XBI Format usability with min. 2 selected partnered Parachain teams. Tutorials will be done to show how to access the XBI-Executor interface and interact with XBI Format with it as a Substrate-based blockchain.
    1c.PSPTransform the XBI Format documentation into Polkadot Standard Proposal. Detail both the Metadata and all of the XBI execution orders of the format, as a consistent and unambiguous specification.

    Future Plansโ€‹

    This is the research-focused grant proposal on XBI which is assumed to be followed up with the grant focused solely on its implementation.

    XBI will help contribute to the t3rn vision of a fully connected cross-chain ecosystem, rooted in Polkadot. For the context, t3rn is building a cross-chain smart contract hosting platform that enable smart contracts execution on multiple blockchians.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? This is our second Web3 Foundation grant, having delivered on our first grant back in December 2020. We having been working tirelessly within the Polkadot ecosystem ever since, as part of the Substrate Builders Program and intend to launch as a Polkadot parachain in summer 2022.

    - + \ No newline at end of file diff --git a/applications/xcm-domain-service.html b/applications/xcm-domain-service.html index 12f99a88594..4bbe397c211 100644 --- a/applications/xcm-domain-service.html +++ b/applications/xcm-domain-service.html @@ -4,14 +4,14 @@ XCM Domain Name Service | Web3 Foundation Grants - +
    Skip to main content

    XCM Domain Name Service

    • Team Name: Scio Labs (AZERO.ID)
    • Payment Address: USDC (Ethereum Mainnet) to scio.eth - 0x8068a383797811734Cb4fAA1Cc8111897C461915
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    • Tagline:

    Research ink! based domain service integrated with XCM

    • Brief Description:

    Our team secured first place in the ETHWarsaw hackathon in 2022 with AZERO.ID, an on-chain domain service using ink!, by winning the Aleph Zero Foundation's bounty. The team has since developed a sophisticated on-chain NFT domain platform in ink! v4, and is set to launch on the Aleph Zero mainnet. Our next objective is to expand the platform to the Dotsama ecosystem and leverage its full potential by enhancing it with the use of XCM. Moreover, we have already challenged the potential value creation for the Polkadot ecosystem with different people at Parity.

    • An indication of how your project relates to / integrates into Substrate / Polkadot / Kusama:

    AZERO.ID is the first sophisticated on-chain domain name service natively written in ink!. Because at Scio Labs, we envision a future where Substrate smart contracts are predominantly WASM-based. Our plans include launching the initial version of our protocol on the Aleph Zero mainnet as well as our new landing page and dApp soon. We plan to enhance our platform by utilizing XCM, to evolve into a unified Dotsama/Substrate domain name service. As the shift towards WASM-based smart contracts gains momentum, we believe the Dotsama ecosystem is ready for a native on-chain domain system that offers interoperability and usability across all Parachains.

    • An indication of why your team is interested in creating this project:

    We harbor a profound interest in the domain of on-chain identity with the belief in Substrate and ink! as the leading tech stack for the future of web3. Bringing our domain platform to Dotsama will not only demonstrate the capabilities of ink! and XCM, but add a lot of utility for users in the Dotsama ecosystem. Also, we love to craft great end-to-end user-facing applications well beyond just the infrastructure layer.

    A unified on-chain domain standard significantly improves the user experience of handling cross-parachain transactions. Further, on-chain NFT domains are the key primitive of a user's on-chain identity and can be integrated into any kind of application. Our domains provide additional utility via a flexible metadata storage field to store DIDs, verifiable credentials, and subdomains to enable organizational and enterprise use cases. Further, tradeable on-chain NFT domains are a tangible product that increases demand for Polkadot block space and improves ecosystem adoption, as previously seen on Ethereum and other chains.

    Project Detailsโ€‹

    • The problem(s) that you want to investigate, and why these are important:

    We aim to resolve the challenge of identifying the optimal technical architecture for a Dotsama-wide on-chain NFT domain service and how XCM can be leveraged to achieve this. Thus, before we can build an XCM-based domain service in ink!, we will need an in-depth understanding of the XCM technology, currently available standards, and their limitations. Once we have developed a deep understanding, we will identify all potential levels of integration, assess their feasibility, and finally propose the technical architecture of an XCM-based domain service.

    • Research questions/hypothesis:

    Find below a list of research questions we have identified. This list is not final; other questions might arise in the research process. 

    * To what extent is it possible to make XCM calls via ink! smart contracts at the moment, and what will improve in the foreseeable future?

    * Does XCM support calls between different smart contract languages? Like ink! <> Solidity.
        
    * What does a cross-chain domain service via XCM actually mean?

    * How can XCM be used to achieve "cross-parachain" domain-to-domain asset transfers?

    * How is the gas & registration/renewal fee payment handled? 

    * Is XCM needed for cross-chain domain โ†” address resolving?

    * Can domains be registered from every parachain via XCM? How can a unique namespace be maintained across parachains?

    * Can XCM be used to enable cross-chain NFT domain trading and transfers?

    * Are domain/NFT assets stored on a single chain only? Or, if they are stored on multiple chains how are they tracked on the other ones accordingly?

    * What ink! NFT standard can be used for the best compatibility across the XCM ecosystem? Should a new one be proposed?

    * Can XCM enable smart contracts to access the metadata storage field of our domains regardless of where the smart contract is deployed, and the NFT domain is stored?

    * What general security implications must be considered when building a cross-chain domain system with XCM?

    * What happens if a domain is updated on one chain while it is being used to transfer assets on another chain at the same time? What kind of other race conditions could occur?

    • Methodology that will be applied:

      • Acquire in-depth knowledge about XCM from all available resources.
      • Identify the design principles to consider while building an XCM-based dApp.
      • Evaluate different ways (like teleportation vs reservation) to accomplish a given task and identify its pros & cons.
      • Propose a plausible high-level architecture of a cross-chain domain service implemented in ink! and integrated with XCM.

    • Expected results and how they would be double-checked by the grants team (reproducibility of the data analysis):

      • The first milestone will yield a report on our analysis of XCM and list potential domain integration options without assessing their feasibility.
      • The second milestone that concludes the scope of this research project delivers a detailed assessment of the potential ways to integrate XCM and proposes a high-level architecture of a cross-chain DNS using XCM.

    • Intended venue for results publication and the timeline for publication:

      • The results will be published for public access in the form of a Litepaper, and a reference is submitted to the w3f/Grant-Milestone-Delivery. Additionally, we plan to communicate the results in a dedicated blog post & our social channels.

    • What your project is not or will not provide or implement

      • This project's scope does not include any form of the actual development of the proposed solutions in the final deliverable. The development of a PoC and, moreover, production-ready implementation could be subject to follow-on grants. Though, we'll provide a technical deliverable in the form of a public repository that showcases some sample cross-chain contract interactions with ink! & XCM (see Milestone 2).

    Ecosystem Fitโ€‹

    • Where and how does your project fit into the ecosystem?

      • Our project aims to become the standard for on-chain domains on Polkadot, Kusama, and any Substrate chain such as Aleph Zero. Our protocol and NFT domains are developed with ink! and therefore prepared for the future of WASM-based smart contracts on Substrate.

    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

      • There are different target audiences for our NFT domains. First and foremost, our domains target any user on Substrate chains. On-chain domains are the first step in establishing an on-chain identity and improving the UX for on-chain interactions. Second, our project addresses all wallet providers as well as dApp/UI & parachain developers who are interested in implementing the user's on-chain domains.

    • What need(s) does your project meet?

      • Having a unified NFT domain standard on the smart contract level that works across all Substrate chains and is natively developed with ink!.
      • Improving the user experience for all Polkadot/Kusama and Substrate chain users
      • Attracting more users to Polkadot/Kusama and Substrate chains
      • Improving the security for Polkadot/Kusama/Substrate users by preventing address poisoning and other wallet address-related phishing attacks
      • Reducing the likelihood of losing funds by error-prone handling of wallet addresses while transferring assets
      • Demonstrating the capabilities of Substrate's user-facing application layer with great UX & Frontend.

    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

      • Polkadot Name Service
      • ASTR Domains (Astar Domains Service)

    • If so, how is your project different?

      • We are developing the very first sophisticated NFT domain name service fully written in ink!. Moreover, we are focusing on creating a standard that works across the whole Polkadot/Kusama ecosystem by integrating XCM. Our NFT domains include some unique functionalities, such as a flexible metadata storage field that enables the attachment of any kind of metadata to the domain. Further, we deliberately focus on crafting great user-facing applications with unmatched UX in the space of decentralized domain name services.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Name of team leader

      • Dennis Zollmann

    • Names of team members

      • Mike Schneider
      • Nimish Agrawal

    Contactโ€‹

    • Registered Address: Am Neuen Markt 9 E-F, 14467 Potsdam, Germany
    • Registered Legal Entity: Scio Labs UG (haftungsbeschrรคnkt)

    Team's experienceโ€‹

    Dennis Zollmann

    • B.Sc. Computer Science, Friedrich Schiller University Jena
    • 10+ years of experience in writing professional software
    • Serial hackathon winner (EthAmsterdam, EthCC Paris, EthBerlin, EthWarsaw)
    • Successfully worked on grants by AAVE, The Graph, Toucan Protocol, and Aleph Zero
    • Co-Founder of Scio Labs & AZERO.ID

    Nimish Agrawal

    • B.Sc. Computer Science, Indian Insitute of Information Technology
    • Prev. Rust/Substrate Developer @Laguna Labs & Core Developer @Nethermind
    • Serial hackathon winner (DotGlobal, ETHIndia, Polkadot APAC, Polkadot LATAM, Avalanche Developer Contest, etc. )
    • International Algorithmic computational research challenge - PACE winner
    • Experience building WASM contracts, e.g., AMM, P2E gaming platform, fractional/dynamic NFTs & more.

    Mike Schneider

    • B.Sc. Management & Economics and M.Sc. Finance, EBS University
    • Hackathon winner @EthWarsaw & grant received from Aleph Zero
    • Prev. worked in Venture Capital & Venture Building
    • Experience in researching web3 business models, token economics, and technologies
    • Co-Founder of Scio Labs & AZERO.ID

    Team Code Reposโ€‹

    Team Twitter Profilesโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 months
    • Full-Time Equivalent (FTE): 1,5 FTE
    • Total Costs: 30,000 USD

    Milestone 1 โ€” XCM & Integration Researchโ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: 10,000 USD
    NumberDeliverableSpecification
    0a.Copyright and LicensesGPLv3
    0b.Documentation/TutorialWe will document the entire research process
    0c.MethodologyResearch XCM and derive potential integration paths
    0d.ArticleWe will provide a report summarizing our research on XCM and giving an overview of potential integration, paths including applicable answers to our initial research questions
    1.List of resources regarding XCM, cross-chain domains/NFTsWe will provide a publicly accessible list of all sources we used for the research.
    2.Information to be extracted from the resourcesWe will provide a breakdown of the most relevant information gathered.
    3.Analysis proceduresWith the information gathered above regarding XCM and our understanding of domain name services, we are going to describe potential integration verticals between both. The technical assessment and architectural explorations will be conducted in the next milestone.

    Milestone 2 โ€” Technical Assessments & Architecture Proposalโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 20,000 USD
    NumberDeliverableSpecification
    0a.Copyright and LicensesGPLV3
    0b.Documentation/TutorialWe will document the entire research process
    0c.MethodologyPerform technical assessment of the integration paths derived in Milestone 1 and propose a technical architecture of an XCM-based domain name service
    0d.ArticleWe will provide a report summarizing our assessments and will propose a high-level technical architecture of the favored solution(s)
    1.Technical AssessmentsWe will reiterate the proposed integration options from Milestone 1 and assess their technical feasibility.
    2.ArchitectureBased on the assessments, we'll propose a feasible architecture for an XCM-based domain name service standard incl. sequence diagrams of the more complex cross-chain interactions, function interface definitions, and also some pseudocode-like implementations of interesting parts. This might include suggestions regarding further XCM/ink! developments or the necessity for certain new standards. Also, a separate PSP/PPP standard could be derived and then implemented in future efforts.
    3.Technical Deliverable (pallet-contracts-xcm)We'll supply a Dockerfile starting up two Substrate nodes being able to exchange XCM-messages via ink! & pallet-contracts-xcm. In the latter we're going to resolve issues #6 & #7 in a fork.
    4.Technical Deliverable (ink!)With 1-2 ink! smart contracts (depending on the assessed techniques from the preceding research items), we'll develop a simplified address-to-domain mapping that can be registered across these two nodes and maintains a unique namespace.

    Future Plansโ€‹

    • We plan to leverage the outcome of this research grant to develop this very XCM-based domain name service for the Dotsama & Substrate ecosystem and set the new standard for on-chain domains on Polkadot and Kusama. As mentioned above, this could also mean deriving a new Polkadot Standards Proposal (PSP) from this.
    • We will be working together with Parachain-, wallet-, and dApp-teams to foster the adoption of our domains and create value and utility via integrations for the users.
    • We envision the project to translate into a fully community-owned DAO with on-chain governance. With social consensus, we will develop AZERO.ID and its upcoming XCM-enhanced counterpart to become core pillars for on-chain identity.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website / Medium / Twitter / Element / Announcement by another team / personal recommendation / etc. Recommended from several sources and contacts in the Dotsama ecosystem.

    Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:

    The initial development and audit of the first version of the AZERO.ID platform has been financed via a grant from the Aleph Zero Foundation. AZERO.ID (via Scio Labs) is a member of the Aleph Zero Ecosystem Funding Program. The project has not yet received any additional grant funding beyond that.

    - + \ No newline at end of file diff --git a/applications/xcm-sdk.html b/applications/xcm-sdk.html index 9830a23e1cd..e45a38c1a25 100644 --- a/applications/xcm-sdk.html +++ b/applications/xcm-sdk.html @@ -4,13 +4,13 @@ Cross-Consensus Messaging Software Development Kit | Web3 Foundation Grants - +
    Skip to main content

    Cross-Consensus Messaging Software Development Kit

    • Team Name: Blockcoders
    • Payment Address: Ethereum (USDT/USDC/DAI) 0x0B7144E7960Ac666A6AD6B38Fe65C2fe96E65994
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    XCM SDK is a tool that provides an interface to send XCM messages for Substrate based blockchains. This library is written in Typescript so it can be imported in a whole new set of applications or dApps that use Javascript/Typescript engines such as Node.

    The idea of this project is to have fast way to send XCM messages between the relay chain and the parachains without having to use Rust-written tools or other platforms/applications.

    This project is focused on the Polkadot ecosystem but it can be used in any other Substrate-based blockchain that uses the XCM pallet.

    Blockcoders is a team that is always contributing to blockchain projects to help the growth of the ecosystem.

    Ecosystem Fitโ€‹

    Help us locate your project in the Polkadot/Substrate/Kusama landscape and what problems it tries to solve by answering each of these questions:

    • Where and how does your project fit into the ecosystem?
      • It provides a solution for all those who are interested in sending xcm messages from a project in typescript. It is a key tool to integrate this messaging format in applications.
    • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?
      • Mainly developers who are interested in creating applications/tools that need to send this type of messages since this sdk facilitates the integration of xcm messaging.
    • What need(s) does your project meet?
      • This sdk provides a fast and easy way to send xcm messages. Being written in typescript allows more developers to access this type of messaging without the need to use the polkadot.js browser or libraries that are written in Rust.
    • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?
      • There are other tools for sending xcm messages but none like the one proposed here. The rest of the tools are Rust libraries, applications like polkadot.js.org among others. This SDK is focused on being able to access these features from projects written in Javascript/Typescript.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Jose Ramirez
    • Fernando Sirni
    • Ruben Gutierrez

    Contactโ€‹

    • Registered Address: Bouchard 705, Buenos Aires Argentina
    • Registered Legal Entity: Blockcoders

    Team's experienceโ€‹

    Our team has been contributing with different projects in blockchain for a few years, building APIs, SDKs and developer tools. Our goal is to continue to drive the crypto space forward by investing intellectual capital into projects, participating actively to help shape the ecosystems we believe in.

    Team Code Reposโ€‹

    Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

    Team LinkedIn Profiles (if available)โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 3 month
    • Full-Time Equivalent (FTE): 2
    • Total Costs: 30000 USD

    Milestone 1 - Support for XCM messagesโ€‹

    • Estimated duration: 2 month
    • FTE: 2
    • Costs: 20,000 USD

    In this milestone the focus is on creating a new sdk to send xcm messages between the relay chain and parachains. The main idea is to create an interface that can handle all the xcm messages that are available in the polkadot.js library. The sdk will be written in typescript and will be able to be used in any project that is written in javascript or typescript.

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both english and spanish versions of the documentation. This will cover step by step how to configure the environment and send xcm messages.
    0c.Testing GuideUnit test and end to end tests will cover the core functions to ensure everything works as expected. The documentation will have an example on how to run these tests.
    1.Create Messages TypesDefinition of all messages types that can be sent via xcm supported by Polkadot API. We are gonna support all the types listed on out research document.
    2.Send XCM messagesCreation of an interface to send XCM messages using the types defined in (1) and the Polkadot API
    3.TestingAchieve a testing coverage of the functionalities above 90%

    Milestone 2 - Add support for other xcm messagesโ€‹

    • Estimated Duration: 1 month
    • FTE: 2
    • Costs: 10,000 USD

    This milestone is entirely about adding support for pending xcm messages not covered on milestone 1. Using generics and typescript interfaces we will be able to add support for new messages without having to change the code.

    NumberDeliverableSpecification
    0a.LicenseMIT
    0b.DocumentationWe will provide both english and spanish versions of the documentation. This will cover step by step how to send all kind of xcm messages.
    0c.Testing GuideUnit test and end to end tests will cover the core functions to ensure everything works as expected. The documentation will have an example on how to run these tests.
    0d.ArticleWe will post an article on Twitter and Reddit for both english and spanish speakers communities.
    1.CLI toolBuild an interactive command line tool to generate and send XCM message.
    2.Add support for new messagesAdd support to send XCM messages using a format that it's not defined on the Polkadot API. Using generics the send function allows the body to be defined by the user.
    3.TestingAchieve a testing coverage of the functionalities above 90%

    Future Plansโ€‹

    We plan to share our expertise creating workshops online, handling all relevant forums and social networks.

    Licenseโ€‹

    Apache license version 2.0

    - + \ No newline at end of file diff --git a/applications/xcm-tools.html b/applications/xcm-tools.html index 011275e0efa..a7cb486ce22 100644 --- a/applications/xcm-tools.html +++ b/applications/xcm-tools.html @@ -4,7 +4,7 @@ XCM Tools | Web3 Foundation Grants - + @@ -37,7 +37,7 @@ and scale.go, support signed & send transaction

    NumberDeliverableSpecification
    0a.LicenseMIT or Apache 2.0
    0b.DocumentationSimple documentation on how to use and how to test
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Sign messageAdd sr25519 & ed25519 sign message
    2.extrinsic encodeextrinsic.go Add encode feature
    3.Send extrinsicSend transaction support, include ed25519&sr25519
    4.Pull requestCreate pull request merge into substrate-api-rpc and scale.go

    Milestone 2โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT or Apache 2.0
    0b.DocumentationSimple documentation on how to use and how to test
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Send UMP messagesupport UMP message send
    2.Send DMP messagesupport DMP message send
    3.Send HRMP messagesupport HRMP message send

    Milestone 3โ€‹

    NumberDeliverableSpecification
    0a.LicenseMIT or Apache 2.0
    0b.DocumentationSimple documentation on how to use and how to test
    0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
    1.Parse xcm instructionsParse instructions raw data, support xcm format v1 & v2 & v3
    2.Tracing transactionSupport xcm format v1 & v2 & v3
    3.Cli supportAdd command line tool to send message & parse xcm instructions && tracking transaction

    Future Plansโ€‹

    I have been maintaining php-scale-code and php-api-lib for three years, and this application will also be maintained continuously

    - + \ No newline at end of file diff --git a/applications/xcmsend.html b/applications/xcmsend.html index 9527e0c48b6..90b1c872d6d 100644 --- a/applications/xcmsend.html +++ b/applications/xcmsend.html @@ -4,7 +4,7 @@ XCMSend | Web3 Foundation Grants - + @@ -26,7 +26,7 @@

    As XCM transactions are more complex than a simple balance transfer on a single chain, the average time of a transaction is higher and more โ€œmoving partsโ€ means there is an increased chance for errors during the transaction life cycle. This is why it is pertinent that the user is informed of the transaction status. We will enable real-time dynamic updates. As shown in the above screenshots. V0 for Milestone 1 and V1 for Milestone 2.

    we will provide generic functionality where we can that covers multiple chains, however if there is a unique integration required for a parachain, this will be left out of these milestones. Where will be as explicit as possible about which chains we will support, however that support could be generalised to other chains. We will make simple for other projects to clone our project add their chains, then can their host that instance themselves and/or make a PR to XcmSend official repo.

    Team ๐Ÿ‘ฅโ€‹

    Team's experienceโ€‹

    Filip "flipchan" Kalebo - Rust Syndicate - Developer, DevSecOps, Previously worked on early stage Picasso chain, Edgeware Solo chain and recently โ€œUptestโ€ that is funded by the Polkadot Treasury.

    Ramsey Ajram - Decentration - Substrate Developer, Product, Frontend, took a parachain into production on Kusama, W3F funded for Supersig (pallet and UI) https://subverse.decentration.org. Polkadot Blockchain Academy (PBA) Alumni.

    Ace Salazar - Rust Syndicate - Project coordination, Previous experience working on projects for the Rust programming languageโ€™s ecosystem.

    JelliedOwl(Paul) - Substrate based chain rpc provider, trusted community member, Moderator of the Polkadot Multisig.

    Team Code Reposโ€‹

    Proven Track Record:โ€‹

    The team has delivered previous projects in the substrate ecosystem:

    Contact:โ€‹

    Contact name:

    Filip Kalebo - Rust Syndicate

    Contact email:

    blockchain@firosolutions.com

    Contact name:

    Ramsey - Decentration

    Contact email:

    ramsey@decentration.org

    https://decentration.org

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1: XCM SEND MVP

    FTE: 2

    Duration: 4 weeks

    Costs: 15000 USD

    NumberDeliverableSpecification
    0a.LicenseMIT
    0bDocumentationWe will provide tutorials and usage examples of all features and milestones delivered.
    0cTesting and Testing GuideIn our published documentation and articles we will cover the steps needed to test XCMSend
    0dDockerWe will publish a docker image that users can use to test XCMSend locally
    0eArticleWe will publish an article that walks the end user hand in hand on how to use XCMSend
    1XCMSend UI (MVP)Build the first version of the XCMSend UI which begins with sending crosschain assets transfers.
    2Browser wallet integrationAllowing support for some of the most used wallets in the dotsama ecosystem: Subwallet, Talisman, Polkadot.js and metamask by integrating Subconnect
    3Rococo XCM TransfersWe will enable teleporting of assets across chains within the Rococo network. Such as ROC from Rococo to AssetHub.

    Milestone 2:

    FTE: 2

    Duration: 4 weeks

    Costs: 15000

    NumberDeliverableSpecification
    0a.LicenseMIT
    0bDocumentationWe will provide tutorials and usage examples of all features and milestones delivered.
    0cTesting and Testing GuideIn our published documentation and articles we will cover the steps needed to test XCMSend
    0dDockerWe will publish a docker image that users can use to test XCMSend locally
    0eArticleWe will publish an article that walks the end user hand in hand on how to use XCMSend
    1Support 3 chains or moreSupport at least 3 different parachains as source chains to send assets from
    2Json-rpc apiWe want to enable users to send XCM Transfers in a high level way and we will provide a basic api that can be used by client libraries, to seamlessly broadcast XCM asset transfers.
    3Parachain discoveryXCMSend will track which parachains are currently connected and filter the selection based on that. The lease times of each parachain needs to be accounted for as well.
    4Auto index XCM channelsFilter the options for source and destination chain based on the open channels that are available

    Future Plans:โ€‹

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? The team is familiar with the web3 foundation from previous projects.

    - + \ No newline at end of file diff --git a/applications/xtokens.html b/applications/xtokens.html index de48cbf9d17..590e77ee6d9 100644 --- a/applications/xtokens.html +++ b/applications/xtokens.html @@ -4,13 +4,13 @@ xtokens - XCM Implementation for Fungible Assets | Web3 Foundation Grants - +
    Skip to main content

    xtokens - XCM Implementation for Fungible Assets

    This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the Open Grants Program Process on how to submit a proposal.

    • Team Name: Acala
    • Payment Address: 1Q88PtW866r4bfv2eMphobP78QnsDrRKfY

    The above combination of your GitHub account submitting the application and payment address will be your unique identifier during the program. Please keep them safe.

    Project Overview ๐Ÿ“„โ€‹

    We are creating a XCM Implementation for Fungible Assets - xtokens.

    Overviewโ€‹

    Polkadot Cross-Consensus Message Format (XCM) is a generic message format that is very flexible but loosly defined. Therefore, we need to provide an implementation of required use case e.g. cross-chain transfer, for parachains to be interoperable with the same context, namely send/receive fungible assets between parachains, and between relay chain and parachains. We have developed an implementation guide, as well as a reference implementation xtokens that has been used by Acala, Laminar, Plasm, and HydraDX successfully completing cross-chain fungible token transfers on Rococo parachain testnet. We are supporting many more projects including Moonbeam, Centrifuge, PolkaBTC, Darwinia, Kilt, Crust and Snowfork to implement this and enable our chains to be composable with each other.

    We believe all chains on Polkadot/Kusama shall be composable with each other, from exchanging values to exchanging and altering states. The cross-chain fungible asset implementation is the first step towards this goal.

    Project Detailsโ€‹

    We have already delivered the work we outlined in a PoC state, we will continue the development to meet the best practice outlined in the implementation guide at a production-grade standard, and this grant is applied partially in retrospect.

    Below are deliverables:

    • XCM Fungible Asset Implementation Guide that outlines fungible asset design considerations and discussions, serving as a draft best practice. (see here)
    • A reference implementation of cross-chain fungible assets - xtokens PoC (see xtokens here and xcm-support here)
    • A detailed documentation for other parachains to use these pallets, configure cross-chain assets, open HRMP channels on Rococo to test the cross-chain transfer etc. (see docs here)
    • Further develop xtokens to implement parachain and fungible asset identifier to handle asset conversion, assetId conversion, and multi-location conversion etc in a more generic and extensible way as described in the implementation guide
    • We will contribute the xtokens code to the orml (open-runtime-module-library) so anyone can use and further extend it.

    Ecosystem Fitโ€‹

    This is another common-good implementation that would be useful to any parachains who want to send and receive fungible assets from other parachains, as well as send/receive relay chain token between relay chain and parachain. We have tackled many XCM and HRMP caveats while implementing xtokens, which would save much time for many other projects and accelerate innovations on top of cross-chain value exchange. We also foresee this work will inspire more collaboration and discussion within the parachain ecosystem, and could also inspire similar development for non-fungible assets.

    We are not aware of other implementations at this stage, but hope to inspire more.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Shaun Wang (Lead Developer)
    • Bryan Chen (Architect)
    • Bette Chen (Product Manager)

    Contactโ€‹

    • Registered Address: 462 Crawford Lane #02-39 Singapore 190462
    • Registered Legal Entity: ACALA PTE. LTD.

    Team's experienceโ€‹

    The team is made of experienced Substrate builders, various members are contributors to substrate, polkadot-js and other core libraries.

    Shaun Wang has been contributing to several Polkadot ecosystem open source libraries, including Substrate, parity-common, type-metadata, etc. He has worked extensively on launching Acala on Rococo testnet, implementing xtokens, helping various teams installing xtokens and successfully completing cross-chain transfers.

    Bryan Chen is one of the most active contributors to substrate codebase outside of Parity, a Polkadot community ambassador, and substrate/polkadot lecturer. He's the architect and technical brainpower behind the Laminar & Acala project.

    Bette Chen has more than a decade product/program/project management experience with background in Software Engineering and MBA from Otago and Duke. She's in charge of product and operation for Laminar & Acala.

    Team Code Reposโ€‹

    Team Githubโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 month
    • Full-time equivalent (FTE): 1.5 FTE
    • Total Costs: USD 25k (Payable in BTC)

    Milestone โ€” Implement xtokens PoCโ€‹

    • Estimated Duration: 1 month
    • FTE: 1.5
    • Costs: USD 15k
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to use xtokens
    0c.Testing GuideThe code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests
    1.Substrate module: xtokensWe will create a Substrate module that will handle cross-chain Account and balance transfers: transfer relay chain token e.g. DOT, transfer parachain tokens to parachain etc.
    2.Substrate module: xcm-supportWe will create a Substrate module that will provide support functionalities for XCM e.g. convert relay chain decimals to parachain decimals, supports multi-currency, and converts relay chain currencyId to parachain etc.
    3.Support parachain installing xtokenWe will support other parachains to install and test cross-chain fungible token transfer using xtoken, by providing necessary documentation, direct technical support, and trouble shooting.
    4.Article/TutorialWe will write a tutorial that explains the work done as part of the grant.

    Milestone โ€” Further Implement xtokens according to the XCM Fungible Asset Implementation Guideโ€‹

    • Estimated Duration: 1 month
    • FTE: 1.5
    • Costs: USD 10k
    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how to use xtokens
    0c.Testing GuideThe code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests
    1.Substrate module: xtokensWe will extend xtokens to include parachain fungible asset multi location mapping with parachainId as the namespace (in PoC it's just string identifiers), Asset Transactor to handle fungible asset balances and operations, Location Conversion to map multi-location and accountId, AssetId Conversion to map foreign multi-asset to native parachain assetId/currencyId and vice versa
    2.Substrate module: xcm-supportWe will extend xcm-support to support the added operations from #1
    3.Article/TutorialWe will write a tutorial that explains the work done as part of the grant.

    Future Plansโ€‹

    This is only the beginning of shaping up specific use cases of XCM, we will continue to improve fungible asset implementations so its generic enough for most if not all parachains. This work is likely to inspire non-fungible asset implementations, and we'd also be keen to contribute further as well.

    Additional Information โž•โ€‹

    Possible additional information to include:

    • The xtokens PoC has been implemented on multiple parachains on Rcococ, Plasm was the first amongst them, and here is the article describing it.
    • Are there are any teams who have already contributed (financially) to the project? Just Acala.
    • Have you applied for other grants so far? Yes, we have a grant for stablecoin that has been completed. We also have a grant for a Substrate composable EVM, of which the first milestone has been delivered.
    - + \ No newline at end of file diff --git a/applications/yatima.html b/applications/yatima.html index 6bce04cd790..b7fad34d2c9 100644 --- a/applications/yatima.html +++ b/applications/yatima.html @@ -4,7 +4,7 @@ Yatima | Web3 Foundation Grants - + @@ -142,7 +142,7 @@ indication that content addressing is a good fit for this, given the work Unison has done on distributed systems.

    Additional Information โž•โ€‹

    How did you hear about the Grants Program? Web3 Foundation Website

    Previous work on Yatima and predecessor projects has been supported by grants from the Ethereum Foundation and the IOTA Foundation.

    - + \ No newline at end of file diff --git a/applications/yiban_chen1.html b/applications/yiban_chen1.html index e800b6e2859..6c616ee541c 100644 --- a/applications/yiban_chen1.html +++ b/applications/yiban_chen1.html @@ -4,7 +4,7 @@ Yiban Chen (General chain) | Web3 Foundation Grants - + @@ -16,7 +16,7 @@ img

    Design of the note listing screen. img

    Design of the note view screen. img

    Ecosystem Fitโ€‹

    The YibanChen will provide users a way to start using web3 internet daily. The Note-pallet will provide the ecosystem with a streamlined method to create, store and transfer communication data. YibanChen will also enable users to move from centralized website hosting to a decentralized web3 model with the Site-pallet. The Name-service-pallet will provide a mechanism for federated login with an substrate user owned wallet.

    The audience will be users that want to start using web3 for communication, website hosting and login. We also expect to support Substrate blockchain developers, which will want to reuse our pallets and connect to our infrastructure. In the future we'll integrate and support cross-chain messaging by leveraging XCMP.

    We are unaware of any of project that is focusing on critical components, such as email/communication, basic web3 hosting, and decentralized federated login, these services will enable a user to move from web2 to web3.

    We looked at the system.remark call, while we found system.remark would allow for simple note creation, but would limit the ability to enhance our Note feature. In the future we plan to add two gatekeeper mechanisms on the note receiver side. First, whitelist a set of wallet address senders, and secondly the ability of a wallet address to set an amount of token required to be sent along with the note before the wallet address would accept the note. We also have had some initial feedback that users would be interested in selling the notes, which we believe utilizing ORML-NFT would be the best for this scenario for selling notes in the future.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Team's experienceโ€‹

    David Rhodus has been a software developer and development manager for 20 years. David has created multiple startups, worked at Amazon AWS via startup acquisition, Consensys on Ethereum data market research project(https://www.youtube.com/watch?v=l1xJC8d3g5E), and has been involved full time with blockchain since 2017. David has been studying rust for the past two years and substrate/polkadot development for one year.

    Max Rosenburg is a developer focused on full stack web development and machine learning. Max has a degree in Computer Science from Reed College.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Currently, work for the Dapp has started, the team has an initial Substrate node (wss://testnet.yibanchen.com:443).

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    Milestone 1 โ€” Build YibanChen Notes DApp with Substrate Wallet Supportโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideCore pallet functions will be fully covered by unit tests to ensure functionality and robustness. ReactUI testing will be covered by selenium tests. In the guide, we will describe how to run these tests.
    1.note-palletWe will create a Substrate module that will allow an Note to be created and transferred.
    2.Substrate Testnet ChainUsers can interact with the notes-pallet module through a simple substrate setup. We will run this substrate chain along with users being able to spin up their own copy.
    3.Build React app structureWe will have the core structure of the application in place.
    4.Settings screen: wallet selectionThis will be the landing screen of the app where users can select which substrate wallet they will to use from the Polkadot.JS browser extension injection.
    4b.Settings screen: IPFS storage configurationThis will be the screen of the app where users setup their IPFS storage by adding a Pinata API key.
    5.Sending a noteIn the UI, a user can enter a wallet address which will be the message receiver. The user will enter a data message. When the user sends the message, the data will be written to IPFS and the IPFS CID written as a note object to the substrate chain.
    6.Receiving a noteThe UI will enable a user to query a wallet address for a received notes. The interface will enable the user to click on a note and the data will be retrieved from IPFS, displaying the message onscreen.
    6.Write testsTests will need to be written for each view.

    Milestone 2 โ€” Site-Pallet & React front end for Web3 Sitesโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) create a site and modify the web3.0 sites.
    0c.Article/TutorialWe will publish an article/tutorial for non-technical users that explains what the Dapp is and how to use it.
    0d.Testing GuideCore pallet functions will be fully covered by unit tests to ensure functionality and robustness. ReactUI testing will be covered by selenium tests. In the guide, we will describe how to run these tests.
    1.site-palletThe Site-pallet will store a decentralized storage location such as a IPFS CID hash and a Site name as a String. The pallet will provide interfaces for create(), listing(), transfer(), burn().
    2.React frontendThis frontend will provide a UI for managing web3 sites. This will expand upon the existing ReactUI which enables wallet-to-wallet communication. Users will be able to create sites, upload website data to IPFS, modify IPFS hashes in the Site-pallet and transfer site ownership.
    3.Site SearchThe UI will enable users to search for existing site names by reading the site-pallet name String data structure.
    4.Connect to substrate with Polkadot.jsUsers should easily be able to connect the frontend using polkadot.js to manage their web3 sites.
    5.write testsTests will need to be written for each view.

    Milestone 3 โ€” Name-Service-Pallet, React javascript library & Riot/Matrix verification botโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
    0c.Testing GuideCore pallet functions will be fully covered by unit tests to ensure functionality and robustness. ReactUI testing will be covered by selenium tests. In the guide, we will describe how to run these tests.
    1.name-service-palletThis pallet will provide users the ability link a name to a wallet.
    2.Riot/Matrix botA Riot bot will be created that allows users to sign a data string with their Substrate based wallet. The bot will then place a judgement and verify the Riot user has control of the wallet.
    3.React Name ViewWithin the existing ReactUI the users will be able to set(), clear(), update() the name-service-pallet for their individual substrate wallet.
    4.React name-service-pallet authentication libraryA javascript library will be created which will provide helper methods to developers to enable easy integration with a React application and substrate chain running the name-service-pallet. This library will help enable federated login within existing React frontend by supporting Polkadot.js browser extension and YibanChen name-service-pallet.
    5.React Name authentication integration tutorialsA tutorial blog writeup and video will be created explaining to developers how they can use leverage verified accounts for federated login within their existing React frontend by supporting Polkadot.js browser extension and YibanChen name-service-pallet.
    6.Write testsTests will need to be written for each the pallet and the bot service.

    Future Plansโ€‹

    YibanChen plans operate on both the Kusama and Polkadot chains and will be the first application of it's kind that delivers decentralized communication, generalized name login service, and web3 website hosting, all built on Substrate.

    However, Development of the YibanChen won't end after all milestones are met. We plan to add features such as expanding Name Service feature to support more blockchain storage objects, such as other decentralized protocols and substrate chain discovery. We are looking at integrating with more decentralized storage protocols such as DatProtocol. Prototyping and testing additional user interfaces including more p2p driven interfaces such as removing IPFS gateways with a combination of IPFS.js and offchain::ipfs. Also supporting smolDot in the front-end for substrate communication. We also plan on building a community around Voting to help try and enable better forms of democracy and governance on and off chain.

    There are lot possibilities where this project YibanChen can go and we are very excited to get started on it and make a difference within the Web3 ecosystem.

    Additional Information โž•โ€‹

    Currently we have no funding for the YibanChen system, we feel getting the general web3 use-cases off the ground will kick-start the substrate ecosystem in a big way. We are excited to be part of the Substrate and Polkadot community and we will continue to contribute as much as we can. Thank you for your time and thank you for considering us for the Web3 Open Grant.

    - + \ No newline at end of file diff --git a/applications/yieldscan_phase_2.html b/applications/yieldscan_phase_2.html index 42f0023a091..40cd2054694 100644 --- a/applications/yieldscan_phase_2.html +++ b/applications/yieldscan_phase_2.html @@ -4,7 +4,7 @@ YieldScan | Web3 Foundation Grants - + @@ -13,7 +13,7 @@



    Team Motivationโ€‹

    After launch, we sat down to listen to our users to understand what to build next.

    We were inspired by Superhuman onboarding experience and we thought that if an email client can onboard their users 1:1, crypto staking - which is like hundred times more complex process - should deserve a 1:1 onboarding.

    Therefore we onboarded like 20 users on Zoom and 50 users through chat and patiently listened to their feedback as well as smoothening out a bunch of nonobvious things in the flow.

    An example of a user onboarding session is here (shared with the permission of the user).



    After going through all user onboarding sessions and discussions with users on chat/telegram, we came to an understanding that in the path to increase adoption, the next critical constraint to solve is to onboard users to the best practises of how to go about staking.

    To gain a sense of the problem, the traction we have mentioned above is all through funds that were sitting inside Polkadot browser extension ๐Ÿ˜ฑ.

    We believe that stakers shoudn't need to trade off security over convenience when they can have both with YieldScan.

    In that line of thought, we want to help stakers onboard to best practises by:

    1. Developing a wizard that helps user understand the why behind setting up distinct stash and controller account --> and them helping them do so.
    2. Recommend moving large asset holdings to hardware wallets.
    3. Combining point 1 and 2, a user will be able to use Ledger + distinct controller account to stake onto Polkadot and Kusama.


    Project Detailsโ€‹



    Ecosystem Fitโ€‹

    Where and how does your project fit into the ecosystem?โ€‹

    We simplify staking experience for Polkadot && Kusama.

    Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?โ€‹

    Users who are trying to participate in staking but finding it hard to do so.

    What need(s) does your project meet?โ€‹

    Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?โ€‹

    A similar project building in the space is Kusama Validator Center.

    The difference that YieldScan provides is:



    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    Contactโ€‹

    Registered Address: 3 Fraser Street, #05-25 Duo Tower, Singapore (189352) Registered Legal Entity: Find Signal Studio PTE. LTD.

    Team's experienceโ€‹

    We've been building within the Polkadot ecosystem for the past 1 year understanding user adoption problems in the ecosystem and solving a bunch of them with YieldScan.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Status ๐Ÿ“–โ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Overviewโ€‹

    IMPORTANT NOTE:

    Milestone 1 โ€” Incorporate Distinct Controller and Ledger support into YieldScanโ€‹

    NumberDeliverableSpecification
    0a.LicenseGNU GPL V3
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial (via Loom) that explains how a user can use YieldScan with Ledger
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.Article/TutorialWe will be developing YieldScan Gitbook to start laying the foundation of comprehensive user facing documentation. Inside this we will be incorporating ledger staking documentation + videos.
    1.Implement Controller Account SupportImplementation to detect account type (stash/controller) in the background and accordingly allow the user to stake through YieldScan.

    How to verify deliverable: you will be able to use YieldScan with a different controller and stash account.
    2.Implement Ledger Wallet SupportIntegrating the wizard that walks the user through setting up Ledger + controller setup

    How to verify deliverable: you will be able to stake using Ledger Wallet and leverage the built in recommendation system to select best validators onto Polkadot and Kusama.
    3.DockerWe will deliver both backend and frontend docker images

    Future Plansโ€‹

    A lot of the crypto products today cater to active traders and holders. We want to build for the users who believe in passive wealth creation and long term holding.

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/zenlink-cross-chain-dex.html b/applications/zenlink-cross-chain-dex.html index 8fe2350f854..c8d0165cffc 100644 --- a/applications/zenlink-cross-chain-dex.html +++ b/applications/zenlink-cross-chain-dex.html @@ -4,13 +4,13 @@ Zenlink DEX Smart Contract | Web3 Foundation Grants - +
    Skip to main content

    Zenlink DEX Smart Contract

    • Team Name: Zenlink
    • Payment Address: 3FyMZ4Y6wFXkaSzdBPetizppR5bD6BVLUy
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Based on the prediction of the further growth of the DEX ecosystem in the future and the rapid development of the public blockchain technology, we propose a Polkadot network-based, high-liquidity, cross-chain DEX Network, Zenlink.

    It is a decentralized exchange network that consists of Zenlink DEX Module, Zenlink DEX Aggregator and other DEX Application on parachains.

    System Componentsโ€‹

    In general, Zenlink project consists of the following parts:

    • Zenlink DEX Protocol: The top-level unified general DEX protocol which can be implemented by the following ways. We prefer to make it to have Auto Market Maker(AMM) function and be easy imported into parachain in multiple ways.
      • Module: it's implemented as a Substrate pallet which can be imported into the runtime of a parachain.
      • Smart Contract: it's implemented as a smart contract which can be deployed into the ink! pallet of a parachain.
    • Zenlink DEX Aggregator: A simple and user-friendly entrance of DEX world which is able to connect with most of DEX on Polkadot, so that user can do one-click trade with multiple DEX on low slippage
    • Zenlink Token(ZLK): The native token of Zenlink DEX Protocol which can be used to distribute liquidity benefits and governance, etc

    Zenlink Ecosystem

    As a result of the above components, a decentralized exchange network, Zenlink DEX Network, will be established.

    Benefitโ€‹

    Parachains don't need to implement dex functionality by themselves since Zenlink DEX Protocol has two implementations so it is easy to be integrated. After that, the tokens of parachains would be involved into Zenlink DEX Network by trading with other tokens of other parachains. The more parachains integrate with the protocol, the more tokens users can exchange, so that they would be like to be a market maker and benefit from the value of the flow.

    Firstly, Zenlink DEX Module and Smart Contract will be implemented based on Zenlink DEX Protocol. In order to complete the Zenlink ecosystem, we would like to deploy it to a substrate blockchain and build a front-end website application, Zenlink DEX Dapp, for test.

    Secondly, we would like to build another important component, Zenlink DEX Aggregator. It will connect to Zenlink DEX Dapp.

    Thirdly, we will test the full function of Zenlink DEX Module and Aggregator on Kusama. Users also can try it on Zenlink DEX Dapp.

    Finally, the whole infrastructure(Zenlink DEX Module and Aggregator) will be deployed to Polkadot, so that Zenlink DEX Dapp will be switched to Polkadot network and published.

    Zenlink Architecture

    What we will implement in this grantโ€‹

    We will make the protocol has cross-chain dex functionalities in this grant.

    In the past grants(Zenlink DEX Pallet and Zenlink DEX Smart Contract), We have implemented Zenlink DEX Protocol in two ways and verified its basic dex functionalities, such as token issue, trading, deposit funds, etc. However, the tests are all based on a single Substrate chain. So that, we would like to move further to make cross-chain value liquidity be possible on Zenlink DEX Network. For now, the best testnet should be Rococo which supports parachains and be free. There are still lots of things to do.

    Firstly, we will spike some asset modules, for example orml-xtoken which is used for identifying assets in different parachains. Then, we will adapt Zenlink DEX Module to the asset module.

    Secondly, using the asset module and Zenlink DEX Module, we will implement an one-click cross-chain assets swap. The result is that user can send a swap transaction in Parachain200 which targe to the dex in Parachain300, then user will get another token in Parachain300.

    Cross-chain Assets Swap

    Finally, we will deploy the whole system to Rococo v1 to open test for everyone.

    In generally, the purpose of this grant is to deploy Zenlink Protocol to Rococo V1, then verify the cross-chain dex functionalities.

    Ecosystem Fitโ€‹

    no

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Hui Guo(Leo Guo), Team Leader
    • Tianling, Principal Blockchain Expert
    • Jianbin Zhao, Senior Backend Engineer
    • Rui Shi, Senior Backend Engineer
    • Hui Yuan, Senior Product Manager

    Contactโ€‹

    Team Websiteโ€‹

    • Registered Address: Address: 3 FRASER STREET #05-25 DUO TOWER SINGAPORE(189352)
    • Registered Legal Entity: ZENLINK FOUNDATION LTD.
    • UEN: 202029221W

    Team's experienceโ€‹

    The team is made up of many experienced professionals in the blockchain industry.

    Guo hui(Leo Guo) is the project leader. He joined imToken very early (June 2017) and worked for 3 years as a data analyst and marketing operation specialist. He is very good at trading quotes and user data analysis which helps imToken get 10m users and Tokenlon, imTokenโ€™s DEX, achieve 600m trading volume as well.

    Tianling was a former senior expert of Alibaba. After leaving it, he joined a blockchain company as the core developer for 3 years. He is familiar with the underlying blockchain design and substrate development and also was in charge of the architecture design. Now, he is the principal blockchain expert of Zenlink team.

    Jianbin Zhao is a senior backend dev with 5 years experience, and he is helping the team build the first DEX web application.

    Rui shi is a senior backend dev with 5 years experience. He is not only familiar with C++/Rust, but also has good project experience on Substrate development.

    Hui Yuan has rich experience in product design and management. She has built many nice and user-friendly internet application.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    no

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4 weeks
    • Full-time equivalent (FTE): 4
    • Total Costs: 0.3 btc

    Milestone 1 โ€” Implementing Zenlink DEX DAppโ€‹

    • Estimated Duration: 4 weeks
    • FTE: 4
    • Costs: 0.3 btc
    DeliverableSpecification
    Asset Module Technical specificationsThese spec will describe the architecture and usage with Zenlink DEX Module, and also be included in the whitepaper.
    Zenlink DEX Pallet RepositoryA git repository containing the dex source code. The pallet will be adapted to a general asset module and achieve the cross-chain dex functionalities.
    TestsThe code will have proper unit-test coverage to ensure functionality and robustness
    TutorialThe tutorial will not only indicate that how to use set up and deploy it into Rococo testnet, and also introduce special user cases and potential extensibility. It will be be published on Medium.

    Community engagementโ€‹

    The tutorials and Documentation that we provide will be published as articles in Zenlink Medium and other social media platforms with due mention about Web3 grant.

    We also intend to engage community by running range of user testing to get more feedback from the real end-users to improve our product.

    Future Plansโ€‹

    • Build & deploy Zenlink DEX Aggregator on Kusama/Rococo.
    • Full function test on Kusama/Rococo.
    • Deploy the whole components to Polkadot including Zenlink DEX Module, DEX Dapp and DEX Aggregator.

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/zenlink-smart-contract.html b/applications/zenlink-smart-contract.html index 3e68f3232e9..a2eb88c4662 100644 --- a/applications/zenlink-smart-contract.html +++ b/applications/zenlink-smart-contract.html @@ -4,13 +4,13 @@ Zenlink DEX Smart Contract | Web3 Foundation Grants - +
    Skip to main content

    Zenlink DEX Smart Contract

    • Team Name: Zenlink
    • Payment Address: 3FyMZ4Y6wFXkaSzdBPetizppR5bD6BVLUy

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Based on the prediction of the further growth of the DEX ecosystem in the future and the rapid development of the public blockchain technology, we propose a Polkadot network-based, high-liquidity, cross-chain DEX Network, Zenlink.

    It is a decentralized exchange network that consists of Zenlink DEX Module, Zenlink DEX Aggregator and other DEX Application on parachains.

    System Componentsโ€‹

    In general, Zenlink project consists of the following parts:

    • Zenlink DEX Protocol: The top-level unified general DEX protocol which can be implemented by the following ways. We prefer to make it to have Auto Market Maker(AMM) function and be easy imported into parachain in multiple ways.
      • Module: it's implemented as a Substrate pallet which can be imported into the runtime of a parachain.
      • Smart Contract: it's implemented as a smart contract which can be deployed into the ink! pallet of a parachain.
    • Zenlink DEX Aggregator: A simple and user-friendly entrance of DEX world which is able to connect with most of DEX on Polkadot, so that user can do one-click trade with multiple DEX on low slippage
    • Zenlink Token(ZLK): The native token of Zenlink DEX Protocol which can be used to distribute liquidity benefits and governance, etc

    Zenlink Ecosystem

    As a result of the above components, a decentralized exchange network, Zenlink DEX Network, will be established.

    Benefitโ€‹

    Parachains don't need to implement dex functionality by themselves since Zenlink DEX Protocol has two implementations so it is easy to be integrated. After that, the tokens of parachains would be involved into Zenlink DEX Network by trading with other tokens of other parachains. The more parachains integrate with the protocol, the more tokens users can exchange, so that they would be like to be a market maker and benefit from the value of the flow.

    Firstly, Zenlink DEX Module and Smart Contract will be implemented based on Zenlink DEX Protocol. In order to complete the Zenlink ecosystem, we would like to deploy it to a substrate blockchain and build a front-end website application, Zenlink DEX Dapp, for test.

    Secondly, we would like to build another important component, Zenlink DEX Aggregator. It will connect to Zenlink DEX Dapp.

    Thirdly, we will test the full function of Zenlink DEX Module and Aggregator on Kusama. Users also can try it on Zenlink DEX Dapp.

    Finally, the whole infrastructure(Zenlink DEX Module and Aggregator) will be deployed to Polkadot, so that Zenlink DEX Dapp will be switched to Polkadot network and published.

    Zenlink Architecture

    What we will implement in this grantโ€‹

    We will implement the protocol as a smart contract in this grant.

    In the last grant, Zenlink DEX Module has been delivered within a docker image which has Auto Market Maker(AMM) function and is easy imported into parachain. Zenlink DEX Smart contract is not obsolete since those two implementation could be used by different cases. If a parachain doesn't want to integrate with Zenlink DEX Module into its runtime, it also has another option -- deploying the Zenlink DEX Smart Contract into its smart contract pallet, like ink!.

    The purpose of this grant is to offer more options for parachain projects to introduce Zenlink in a friendly way.

    Ecosystem Fitโ€‹

    no

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Hui Guo(Leo Guo), Team Leader
    • Tianling, Principal Blockchain Expert
    • Jianbin Zhao, Senior Backend Engineer
    • Rui Shi, Senior Backend Engineer
    • Hui Yuan, Senior Product Manager

    Contactโ€‹

    Team Websiteโ€‹

    • Registered Address: Address: 3 FRASER STREET #05-25 DUO TOWER SINGAPORE(189352)
    • Registered Legal Entity: ZENLINK FOUNDATION LTD.
    • UEN: 202029221W

    Team's experienceโ€‹

    The team is made up of many experienced professionals in the blockchain industry.

    Guo hui(Leo Guo) is the project leader. He joined imToken very early (June 2017) and worked for 3 years as a data analyst and marketing operation specialist. He is very good at trading quotes and user data analysis which helps imToken get 10m users and Tokenlon, imTokenโ€™s DEX, achieve 600m trading volume as well.

    Tianling was a former senior expert of Alibaba. After leaving it, he joined a blockchain company as the core developer for 3 years. He is familiar with the underlying blockchain design and substrate development and also was in charge of the architecture design. Now, he is the principal blockchain expert of Zenlink team.

    Jianbin Zhao is a senior backend dev with 5 years experience, and he is helping the team build the first DEX web application.

    Rui shi is a senior backend dev with 5 years experience. He is not only familiar with C++/Rust, but also has good project experience on Substrate development.

    Hui Yuan has rich experience in product design and management. She has built many nice and user-friendly internet application.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    no

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 2 weeks
    • Full-time equivalent (FTE): 4
    • Total Costs: 0.3 btc

    Milestone 1 โ€” Implementing Zenlink DEX DAppโ€‹

    • Estimated Duration: 2 weeks
    • FTE: 4
    • Costs: 0.3 btc
    DeliverableSpecification
    Technical specifications and Zenlink DEX Module designThese spec should be included in the whitepaper. For details, please see the section 'Zenlink DEX Protocol' and 'Zenlink DEX Module'
    Zenlink DEX Smart Contract RepositoryA git repository containing the dex smart contract source code. The smart contract can be deployed to a substrate chain using ink! which is a smart contract substrate pallet. The smart contract will has Automate Market Maker(AMM) function.
    TestsThe code will have proper unit-test coverage to ensure functionality and robustness
    DockerDocker image with a Substrate chain using our module, demonstrating its functionality
    TutorialThe tutorial will not only indicate that how to use set up and deploy it into the ink! module, and also introduce special user cases and potential extensibility. It will be be published on Medium.

    Community engagementโ€‹

    The tutorials and Documentation that we provide will be published as articles in Zenlink Medium and other social media platforms with due mention about Web3 grant.

    We also intend to engage community by running range of user testing to get more feedback from the real end-users to improve our product.

    Future Plansโ€‹

    • Migrate the above basic components to Kusama/Rococo for test
    • Build & deploy Zenlink DEX Aggregator on Kusama/Rococo.
    • Full function test on Kusama/Rococo.
    • Deploy the whole components to Polkadot including Zenlink DEX Module, DEX Dapp and DEX Aggregator.

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/zenlink.html b/applications/zenlink.html index 5f2d8867bd6..05ca05968aa 100644 --- a/applications/zenlink.html +++ b/applications/zenlink.html @@ -4,13 +4,13 @@ Zenlink | Web3 Foundation Grants - +
    Skip to main content

    Zenlink

    • Proposer: Victory Van
    • Payment Address: 3FyMZ4Y6wFXkaSzdBPetizppR5bD6BVLUy

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    Based on the prediction of the further growth of the DEX ecosystem in the future and the rapid development of the public blockchain technology, we propose a Polkadot network-based, high-liquidity, cross-chain DEX Network, Zenlink.

    It is a decentralized exchange network that consists of Zenlink DEX Module, Zenlink DEX Aggregator and other DEX Application on parachains.

    System Componentsโ€‹

    In general, Zenlink project consists of the following parts:

    • Zenlink DEX Protocol: The top-level unified general DEX protocol.
    • Zenlink DEX Module: Polkadot Network Module implemented according to the Zenlink Protocol standard. We prefer to make it to have Auto Market Maker(AMM) function and be easy imported into parachain in multiple ways.
    • Zenlink DEX Aggregator: A simple and user-friendly entrance of DEX world which is able to connect with most of DEX on Polkadot, so that user can do one-click trade with multiple DEX on low slippage
    • Zenlink Token(ZLK): The native token of Zenlink DEX Protocol which can be used to distribute liquidity benefits and governance, etc

    Zenlink Ecosystem

    As a result of the above components, a decentralized exchange network, Zenlink DEX Network, will be established.

    Benefitโ€‹

    Since Zenlink DEX Module is easy to integrate, Parachains don't need to implement dex functionality by themselves. After that, the tokens of parachains would be involved into Zenlink DEX Network by trading with other tokens of other parachains. The more parachains integrate with the module, the more tokens users can exchange, so that they would be like to be a market maker and benefit from the value of the flow.

    Firstly, Zenlink DEX Module will be implemented based on Zenlink DEX Protocol. In order to complete the Zenlink ecosystem, we would like to deploy it to a substrate blockchain and build a front-end website application, Zenlink DEX Dapp, for test.

    Secondly, we would like to build another important component, Zenlink DEX Aggregator. It will connect to Zenlink DEX Dapp.

    Thirdly, we will test the full function of Zenlink DEX Module and Aggregator on Kusama. Users also can try it on Zenlink DEX Dapp.

    Finally, the whole infrastructure(Zenlink DEX Module and Aggregator) will be deployed to Polkadot, so that Zenlink DEX Dapp will be switched to Polkadot network and published.

    Zenlink Architecture

    What we will implement in this grantโ€‹

    We will only build prototypes of basic components in this grant because the whole project is too large to be implemented in only one grant.

    In this grant, the functional prototypes, Zenlink DEX Module and Protocol, will be validated on a substrate chain. We prefer to make it to have Auto Market Maker(AMM) function and be easy imported into parachain in multiple ways. If it works, there will be only a small effect to migrate those components to the better test network, such as Kusama and Rococo.

    For the tech architecture details, please see whitepaper/Zenlink DEX Protocol

    For the AMM initial design, please see whitepaper/Trading Paradigms - CFMM

    In a word, The Zenlink DEX Module will be integrated with a substrate blockchain. And all the components will be packed into a docker image. Once testers run the docker image, the substrate blockchain will be running. At the same time, the dex functionality will be active. So that testers can not only call the functions via RPC request, but also some script in terminal.

    The purpose of this grant is that verification function prototype in lean way.

    Ecosystem Fitโ€‹

    no

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Guo hui(Leo Guo), team leader
    • Tianling, principal blockchain expert

    Team Websiteโ€‹

    The team has no legal entity now, however, the foundation register is in processing in Singapore.

    Team's experienceโ€‹

    The team is made up of many experienced professionals in the blockchain industry.

    Guo hui(Leo Guo) is the project leader. He joined imToken very early (June 2017) and worked for 3 years as a data analyst and marketing operation specialist. He is very good at trading quotes and user data analysis which helps imToken get 10m users and Tokenlon, imTokenโ€™s DEX, achieve 600m trading volume as well.

    Tianling was a former senior expert of Alibaba. After leaving it, he joined a blockchain company as the core developer for 3 years. He is familiar with the underlying blockchain design and substrate development and also was in charge of the architecture design. Now, he is the principal blockchain expert of Zenlink team.

    Besides, two core team members are joining us. One of the potential candidates has rich experience in product design and management. He has built a nice and user-friendly DEX application. And the other one is a senior front-end dev with 5 years experience, and he will help us build the first DEX web application.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    no

    Development Roadmapโ€‹

    Overviewโ€‹

    • Total Estimated Duration: 4 weeks
    • Full-time equivalent (FTE): 2 FTE
    • Total Costs: 0.76 btc

    Milestone 1 โ€” Implementing Zenlink DEX Moduleโ€‹

    • Estimated Duration: 4 weeks
    • FTE: 2
    • Costs: 0.76 btc

    Generally, we would like to verify the product prototype in a specific environment.

    DeliverableSpecification
    Technical specifications and Zenlink DEX Module designThese spec should be included in the whitepaper. For details, please see the section 'Zenlink DEX Protocol' and 'Zenlink DEX Module'
    Zenlink DEX Module RepositoryA git repository containing the dex module source code and a README that describes the work done during this milestone and how to use set up and run at the current stage. The module will has Automate Market Maker(AMM) function and be integrated with a substrate chain
    TestsThe code will have proper unit-test coverage to ensure functionality and robustness
    DockerDocker image with a Substrate chain using our module, demonstrating its functionality

    Community engagementโ€‹

    The tutorials and Documentation that we provide will be published as articles in Zenlink Medium and other social media platforms with due mention about Web3 grant.

    We also intend to engage community by running range of user testing to get more feedback from the real end-users to improve our product.

    Future Plansโ€‹

    • Migrate the above basic components to Kusama/Rococo for test
    • Build & deploy Zenlink DEX Aggregator on Kusama/Rococo.
    • Full function test on Kusama/Rococo.
    • Deploy the whole components to Polkadot including Zenlink DEX Module, DEX Dapp and DEX Aggregator.

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/zero-network.html b/applications/zero-network.html index af42940367a..010ac325a3e 100644 --- a/applications/zero-network.html +++ b/applications/zero-network.html @@ -4,7 +4,7 @@ Zero Network | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    Zero Network

    See the Grants Program Process on how to submit a proposal.

    • Team Name: Zero Network
    • Payment Address: 0x9061b0787D28d0fDaD845d670F7505EAE5F3B01B (DAI)
    • Level: 2
    • Status: Terminated

    Project Overview ๐Ÿ“„โ€‹

    We would like to implement a parachain which specializes in privacy.

    This parachain supports confidential transfers and privacy preserving smart contracts on the mainchain based on the plonk. To support privacy, the traditional blockchains need to implement L2 solutions, complex contract logic or depend on centralized security assumption. The L2 technologies often sacrifice the usability, the complex contract logic cost too much gas and development workload, and the centralized security assumption force us to believe someone you have never met before. As the solution for these problems, we are going to implement parachain supporting privacy on mainchain and depending on only cryptographic hardness assumption. The documentation is here.

    Overviewโ€‹

    Through this grant, we would like to implement confidential transaction functionalities for both transfers and smart contract executions. There are two types of privacy confidential and anonymous. In this scope, we support the confidential transactions which hide the input and output. The anonymous hides the users related to the transaction. The anonymous is going to be supported in the future. We provide the confidential transactions for both transfer and contract execution.

    Project Detailsโ€‹

    This parachain privacy preserving protocol relys on the cryptographic hardness assumptions. There are some components consisting this system and We divide the components as following.

    • primitive: Basic cryptography libraries necessary for the network.

    • functionality: Confidential transactions pallets to realize the privacy.

    • module: Developer tools to develop the confidential smart contracts and output the constraints metadata.

    • client: Wallet libraries to transfer and execute the confidential smart contracts.

    We describe the detail as following.

    Primitiveโ€‹

    The primitive provides crypto libraries necessary for functionality as pallet.

    1. Lifted-ElGamal encryption pallet
    2. zk-SNARKs plonk pallet which supports the plookup and aggregation proof on top of ZK-Garage/plonk
    3. Encrypted balance pallet

    Functionalityโ€‹

    The functionality provides the confidential transfers and confidential smart contracts functions as pallet.

    1. Confidential Transfer pallet
    2. Condidential Smart Contract pallet

    Moduleโ€‹

    The module provides the developer with tools and necessary libraries managing privacy application.

    1. Encrypted ink!
    2. Contract constraint builder
    3. Proof generation library
    4. Confidential smart contract IDE

    Clientโ€‹

    The client provides the transactor client libraries for users.

    1. Key generation wallet
    2. Decrypt and encrypt transaction and balance
    3. Create zero knowledge proof of plonk
    4. Confidential transfers
    5. Confidential smart contracts executor

    Use Caseโ€‹

    We explain the use case we assume.

    diagram1

    Ecosystem Fitโ€‹

    This is the world's first account based and plonk built-in parachain which supports confidential transactions for both transfers and contract executions only depending on the cryptographic hardness assumptions. We can contribute to Polkadot network mainly in three ways.

      1. High performance and Polkadot friendly cryptography primitive

    Our team has been working on zk-SNARKs probjects for long time so we are sure that we can contribute to implement cryptography pallets confidential smart contracts, homomorphic encryption and so on which require a high degree of skill and these will be used for many developers. Most parts of them are composed by cutting edge technologies for example plonk which supports plookup and proof aggregation, and encryption library which supports somewhat homomorphic encryption so we can catch up them. Especially, we have been working on prover time optimization using speed up algorithm, assembly and parallelize, and also exprienced implementing plonk as pallet so we can design the fastest encryption primitive which is Polkadot friendly no_std and parity SCALE Codec compatible.

      1. Privacy preserving XCMP

    We are planning to connect this blockchain to Polkadot as parachain after redesign and optimization. We will be able to use these blockchain functionalities in the entire network. It means that all parachain in Polkadot network can use privacy preserving transactions. We think that this is huge benefit for Polkadot network users because they can easily use the confidential transactions whatever parachain they use.

      1. Research and development

    We would like to improve privacy and scaling using cryptographic scheme. We are going to do experiment about rollup transactions and block compression for storage scaling, Fully Homomorphic Encryption and MPC for privacy. Especially the Fully Homomorphic Encryption will be the next hot topic we are going to focus on.

    Similar Projectโ€‹

    There are some similar projects. We compare their features.

    Comparisonโ€‹

    diagram2

    The most valuable point is that we implement zero knowledge friendly blockchain. The main problem of confidential smart contract projects is the gas limit problem. The additive homomorphic encryption and zk-SNARKs are using heavy arithmetic workload and these processes often exceed the gas limit so it's important to design the blockchain as zero knowledge friendly structure. To make it practical, we think that the Substrate is suitable for three reasons. The account base blockchain, customizable Wasm and zero knowledge scheme.

    The prover side, the more simple structure we generate the zero knowledge proof, the more efficiency we get. The account base blockchain using the key value mapping so it's more efficient than UTXO. We can save the prover time with account based structure.

    The verifier side, we need to optimize the virtual machine performing the zero knowledge function to define case specific bytecode. We can customize the bytecode and get benefit from efficiency of Wasm VM.

    Considering both sides, the zero knowledge scheme is related deeply to calculation workload and the zk-SNARKs is the most efficient one but has a setup scheme. Previously, the zk-SNARKs setup parameters depended on circuit so we needed to setup parameters when we deployed some new contracts. It's hard to ensure that there are enough parties for each deploy contracts so almost contract base confidential smart contract project uses the bulletproof. However, we use the plonk which can generate the parameters without depending on circuit so once we setup the parameters, we can reuse that parameters for every transaction with getting profit of zk-SNARKs efficiency.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Ash Whitehat
    • Kirill Karbushev

    Contactโ€‹

    • Registered Address: 2Fใƒป3F Emblem Nishiarai, 3-33-6 Umejima, Adachi City, Tokyo-to 121-0816, Japan
    • Registered Legal Entity: Invers Inc.

    Team's experienceโ€‹

    Our company is working on the blockchain scaling and information hiding technologies. We already delivered several grants with Astar Network.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    We are not on LinkedIn.

    Development Status ๐Ÿ“–โ€‹

    The information about this project and what we did are following.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Through this grant, we are going to develop the blockchain which supports confidential transactions for both transfers and smart contract executions.

    Overviewโ€‹

    • Total Estimated Duration: 6.5 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 45,000 DAI

    Milestone 1 | Confidential Transfersโ€‹

    • Estimated duration: 2 month
    • FTE: 2
    • Costs: 10,000 DAI

    In Milestone 1, we are going to implement confidential transfer pallet on top of balance pallet. With this pallet, the user can transfer the asset with hiding input and output with Lifted-ElGamal encryption.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how users send the confidential transfers.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide Dockerfiles that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/tutorial/workshop that explains
    1.Lifted-ElGamal palletWe are going to implement Lifted-ElGamal pallet which allows our calculation to remain encrypted. The Lifted-ElGamal allows us multiple addition and one time multiplication for encrypted number.
    2.encrypted-balance palletWe are going to implement encrypted-balance pallet which allows us to store the balance encrypted by Lifted-ElGamal encryption. The encrypted-balance allows us to hide whole network user's balance.
    3.plonk palletWe are going to implement plonk pallet which allows us to use plonk on Substrate. In confidential smart contracts execution, the plonk need to support lookup and aggregation proof.
    4.confidential-transfer palletWe are going to implement confidential-transfer pallet which allows us to send transactions without revealing any information of it.

    Milestone 2 | Confidential Smart Contract Executionsโ€‹

    • Estimated Duration: 3 month
    • FTE: 2
    • Costs: 25,000 DAI

    In Milestone 2, we are going to implement confidential smart contract execution pallet on top of contracts pallet and ink!.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how users send the confidential smart contracts.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide Dockerfiles that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/tutorial/workshop that explains
    1.zk-contracts palletWe are going to implement zk-contracts pallet which allows us to execute deployed contract WASM binary on top of contracts pallet.
    2.zk ink! eDSLWe are going to implement confidential smart contract eDSL on top of ink! which allows developer to develop the confidential smart contract.
    3.zk ink! compilerWe are going to implement zk ink! compiler on top of cargo-contract which allows developer to compile and deploy the confidential smart contract.
    4.zk ink! metadataWe are going to implement zk ink! metadata on top of ink_metadata which generate the contract constraint statement for zk contract used when the user create the proof.
    5.zk-contracts palletWe are going to implement zk-contracts on top of contract pallet which allows runtime to execute deployed contracts.
    6.zk-contracts-rpc palletWe are going to implement zk-contracts-rpc pallet on top of pallet-contracts-rpc pallet which allows the blockchain to have interface interacting with deployed contracts.

    Milestone 3 | Confidential Transaction Walletโ€‹

    • Estimated Duration: 1.5 month
    • FTE: 2
    • Costs: 10,000 DAI

    In Milestone 3, we are going to implement wallet which provides the user to interact with blockchain, send transactions and manage the secret on locally.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how users participate network and send transaction.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide Dockerfiles that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/tutorial/workshop that explains
    1.Key generationWe are going to implement key generation libraries which allow user to generate key with random and store the secret on locally.
    2.ElGamal crypto utilsWe are going to implement ElGamal encryption libaries which allow user to decrypt and encrypt transaction and balance.
    3.plonk proof generationWe are going to implement plonk proof generation which allows user to create proof for circuit constraint.
    4.Confidential transferWe are going to implement confidential transfer libraries.
    5.Confidential smart contract executionWe are going to implement executing smart contract libraries.

    Timelineโ€‹

    MilestoneDeliverableEstimated Duration (month)Deadline
    1Confidential Transfers22023 1/7
    2Confidential Smart Contract Executions32023 4/7
    3Confidential Smart Contract Executions1.52023 5/26

    Future Plansโ€‹

    • Rollup transactions
    • Compress block with zero knowledge proof
    • High performance and Polkadot friendly plonk library
    • Anonymous transactions
    • Wasm optimization

    Additional Information โž•โ€‹

    • How did you hear about the Grants Program?
      • Announcement by another team
    • Work you have already done.
    • Wheter there are any other teams who have already contributed (financially) to the project.
      • No.
    • Previous grants you may have applied for.
    - + \ No newline at end of file diff --git a/applications/zk-plonk.html b/applications/zk-plonk.html index 9527aaefbde..eca3cd740b0 100644 --- a/applications/zk-plonk.html +++ b/applications/zk-plonk.html @@ -4,7 +4,7 @@ zk plonk | Web3 Foundation Grants - + @@ -12,7 +12,7 @@
    Skip to main content

    zk plonk

    • Team Name: Plasm Network (Shinsaku Ashizawa, Sota Watanabe)
    • Payment Address: 0xb82EdE43D03fD23dcdb2d066720b3E77F3bedf6d

    Project Overview ๐Ÿ“„โ€‹

    We have been working on Zk projects and scalability solutions and now we would like to implement Zk plonk pallet.

    The plonk is called universal zkSNARK because of two reasons. The verification times are constant and original reference string can be used to build proofs with any type of circuit. These features bring significant benefits to both users and developers. For example, the verification time is the same so users don't have to wait so long even when they prove complicated proof, and original reference string can reuse so developers don't have to do trusted setup for each circuit. The plonk will be a core technology in terms of scaling and privacy so we should support.

    Overviewโ€‹

    Through this grant, we are going to make a plonk pallet in order for the developer to implement plonk on substrate easily. We are working on scalability solutions but currently, the substrate doesn't support zkSNARK pallet so we think it's a issue to fix. As aforementioned, zkSNARK will be a core technology in blockchain area and especially plonk is cutting edge technology so we are excited to implement this as pallet.

    Project Detailsโ€‹

    We'd like to implement the plonk library as a pallet in order for developers to customize circuits and use the plonk protocol.

    The following diagram is the libraries we are going to implement.

    • Polynomial commitment
    • Circuit builder
    • Generate proof and verify keys
    • Verify proof

    Ecosystem Fitโ€‹

    According to Web3 Foundation, there are at least 2 different teams that work on ZK technologies.

    Glacier is building a Distaff VM for zk-STARK proof generation and verification that are used to make private smart contracts and private credential verifications. The difference between us is that we are making a zkSNARK pallet and they are making a VM which supports STARKs. In terms of Zeropool, they are making private transactions contract pallet using bellman groth16 protocal and we are making zkSNARK libray using plonk.

    We believe zkSNARK with plonk will be core technology of next blockchain area. That allows Substrate to protect the privacy and scale on the huge number of transactions without decreasing the security level.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Shinsaku Ashizawa
    • Alexsandr Krrupenkin
    • Sota Watanabe

    Contactโ€‹

    • Incorporated in Singapore
    • Address: 63 Chulia Street Singapore

    Team's experienceโ€‹

    We have been making Plasm Network, a scalable multi-virtual machines smart contract platform on Polkadot supporting cutting edge layer2 solutions. Curretly, another team at Stake techologies is working on the Optimistic Virtual Machine, an unification for all layer2 solutions and a subset of Optimistic Rollup. We have already delivered 4 milestones out of 6. In addition to that, we have already delivered several grants such as Plasma, ECDSA, and ink! playground.

    We are also participating in Substrate Builders Program and Substrate Delivery Partners and we have done some PoCs with clients.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Summaryโ€‹

    We plan to provide a plonk pallet that allows Substrate-based blockchain to execute plonk-based zkSNARK.

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-Time Equivalent (FTE): 1 FTE
    • Total Costs: 30000 DAI

    Milestone 1 Example โ€” Implement Substrate Modulesโ€‹

    • Estimated Duration: 3 months
    • FTE: 1
    • Costs: 30000 DAI
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a developer builds a circuit and a user prove their computation through the circuit.
    0c.Testing GuideCore functions will be fully covered by unit tests and audit to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.Article/TutorialWe will publish an article/tutorial/workshop that explains
    1.make plonk compatibleThe dusk-network plonk is compatible with no-std so we are going to modify attributes according to parity-codec and Rng to be compatible withใ€€Substrate environment. This step allows this pallet to work on resource-constrained execution environments like Substrate runtime, attributes should be modified in accordance with SCALE codec and some versions of Rng canโ€™t be compiled to wasm so we need to research and make it stable as necessary.
    2.implement zkSNARK plonk palletWe will create a set of plonk-based zkSNARK libraries that allow a developer to build their own circuit and a user to prove their computation validity. Verifying proofs are done by on-chain. Creating the proofs are done by off-chain.

    This zkSNARK plonk is based on dusk-network plonk library. This zkSNARK plonk pallet provides us following function.

    • Building circuits
    • Creating proofs
    • Verifying proofs

    Future Plansโ€‹

    • Zk Rollup implementation
    • private transfer protocol

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/zk-rollups.html b/applications/zk-rollups.html index 9d84c3cf94b..d6f23d506e8 100644 --- a/applications/zk-rollups.html +++ b/applications/zk-rollups.html @@ -4,13 +4,13 @@ ZK Rollup on Polkadot/Substrate | Web3 Foundation Grants - +
    Skip to main content

    ZK Rollup on Polkadot/Substrate

    • Proposer: NoCtrlZ, akru, and SotaWatanabe
    • Payment Address: 1DJTSPajRFCjdfn5UgPXGRo6Di8EE1Dzox

    Project Overview ๐Ÿ“„โ€‹

    We have been working on off-chain scalability solutions aka layer2 solutions. After tremendous research, we have come to believe that ZK Rollup would be the killer layer2 solution because of its data availability. Currently, rollup is one of the potentially interesing topics of Web3 Foundation and Vitalik announced the rollup centric Ethreum roadmap last month. According to Vitalik, the Ethereum ecosystem is likely to be all-in on rollup (plus some plasma and channels) as a scaling strategy for the near and mid-term future. We know that Polkdot has a different technical architecture and tech stack but Rollup is still important because of severtal reasons.

    1. Bringing vertical off-chain scalability without sacrificing on-chain data availability, security and privacy (ร—3-10 scalability).
    2. Handling smart contracts on layer2.
    3. Sharding plus Rollups will be the future. Polkadot has the sharding ish architecture but it doesn't have Rollups yet.
    4. Currenntly, a lot of Ethereum projects are interested in migrating from Ethreum to Polkadot. And some of the great Ethereum projects have already started using Rollups. If we could build Rollups on Substeate/Polkadot, we would help these projects migrate smoothly.

    Through this grant, we will make a ZK Rollup pallet for Parachain builders to get zero-knowledge vertical scalability.

    Overviewโ€‹

    Throught this grant, we are going to make a ZK Rollup pallet for potential Parachains like Plasm. Our initial goal is to implement ZK Rollup on Plasm but we aim to make it public and adoptable for all Substrate based chains.

    The following diagram is the architecture we will implement.

    Screen Shot 2020-11-10 at 23 03 01

    There are four components we implement as a substrate pallet and these components allow substrate-based chain to do following things.

    • Prover: Create proof which verifies the block validity.
    • Operator: Collect transactions, create a block and submit the block to mainchain contract.
    • User Wallet: Send transaction to operator and deposit token on the mainchain contract.
    • Mainchain Contract: Hold user's desposit, verify block and update state.

    Ecosystem Fitโ€‹

    According to Web3 Foundation, there are at least 2 different teams that work on ZK technologies.

    In our understanding, Glacier is building a Distaff VM for zk-STARK proof generation and verification that are used to make private smart contracts and private credential verifications. The difference between us is that we are making a ZK Rollup pallet and they are making a VM which supports STARKs. In terms of Zeropool, we couldn't find their info on Web3 Foundation's github.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Shinsaku Ashizawa
    • Alexsandr Krrupenkin
    • Sota Watanabe

    Team Websiteโ€‹

    • Incorporated in Japan
    • Address: 1-30-3 Minamiaoyama Minato-ku Tokyo Japan

    Team's experienceโ€‹

    We have been making Plasm Network, a scalable multi-virtual machines smart contract platform on Polkadot supporting cutting edge layer2 solutions. Curretly, another team at Stake techologies is working on the Optimistic Virtual Machine, an unification for all layer2 solutions and a subset of Optimistic Rollup. We have already delivered 4 milestones out of 6. In addition to that, we have already delivered several grants such as Plasma, ECDSA, and ink! playground.

    We are also participating in Substrate Builders Program and Substrate Delivery Partners and we have done some PoCs with clients.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    Development Roadmap ๐Ÿ”ฉโ€‹

    Summaryโ€‹

    We plan to provide a ZK Rollup pallet that allows Substrate-based blockchain to execute ZK Rollup on its evm environment.

    Overviewโ€‹

    • Total Estimated Duration: 3 months
    • Full-time equivalent (FTE): 1 FTE
    • Total Costs: 0.2 (rate: 23 Nov, 10:27am UTC)

    Milestone 1โ€‹

    Prepare ZK Rollup Contracts On Substrateโ€‹

    • Estimated Duration: 0.75 months
    • FTE: 1
    • Costs: 0.20 BTC

    Our first step is to deploy matter-labs solidity contracts and test overall on substrate-based chain.

    NumberDeliverableSpecification
    1.Deploy ZK Rollup Contract To SubstrateDeploy matter-labs solidity contracts on substrate evm
    2.Integration Test On SubstrateTest for all contracts and sidechain network actors
    3.DocumentationDocument which describes how to test ZK Rollup on substrate

    Gantt Chartโ€‹

    There are three parts in the following gantt chart and it describes how long it takes to get things done for each milestone. First of all we implement ZK Rollup contracts and sidechain components on ropsten network to check whether it works correctly. And second, we implement sidechain components pallet that allow us to build ZK Rollup on substrate-based chain. At last, we prepare Dockerfile and tutorial that allow developer to user this pallet and build their own ZK Rollup.

    gantt_chart

    Detailโ€‹

    The following list describes our detail for each components.

    detail_tasks

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/applications/zkverse.html b/applications/zkverse.html index c9b154e2385..e5becccf36c 100644 --- a/applications/zkverse.html +++ b/applications/zkverse.html @@ -4,14 +4,14 @@ Zkverse | Web3 Foundation Grants - +
    Skip to main content

    Zkverse

    • Team Name: Zkverse
    • Payment Address: 0x8554fff69177C2cf470fA276b0C65dB58b5EfEE5(DAI)
    • Level: 2

    Project Overview ๐Ÿ“„โ€‹

    Overviewโ€‹

    At present, ZKP technology is constantly developing and innovating in the scaling and expansion track in Ethereum, especially some zk rollup projects, such as zksync, scroll, starknit, etc. So the main goal of this project is to introduce ZKP technology into the Polkadot/Substrate ecosystem. Polkadot/Substrate natively does not support ZKP, so this project(Zkverse, which means zk universe) will provide zk-related pallets to support substrate and more efficient zk proof generation ways.

    Project Detailsโ€‹

    There are three main goals for project:

    • Integrate some zkp libray(like bellman, plonk library and eg...) into substrate pallet
    • Maximize the efficiency and convenience of zk proof generation(The proof is not generated on the chain, but through some developer friendly libraries(like snarkjs) which will be adapted to the zk lib on substrate-based chain.). This is very important and convenient for scaling. It can realize rollup for app-specific Dapps and greatly increase the throughput of the substrated-based chain. It can be said "Off-chain execution and on-chain verification".
    • Publish some tutorial blogs/demos to let more substrate community developers enjoy the convenience of the above zkp development kits.

    Meanwhile, We know that snakjs and circom are excellent and popular zkp development libraries. They are very popular in the Ethereum ecosystem and can automatically generate verification contract codes. We observed this very good feature, so we want to generate circuit codes more easily through circom, and generate proofs by snarkjs, which will be verified on substrate-based chain. Due to many people using snakjs, and circom is developer friendly, Unlike some domain-specific circuit writing methods, our project can attract many developers who are familiar with snarkjs to develop zkp Dapps in substrate/polkadot ecosystem. They can also enjoy the convenience of developing zkp applications in Polkadot ecosystem. So our main goal is to provide zkp infrastructure that is convenient for Polkadot developers. Also ,we will show a minimal example with Merkle tree and ZKP for rollup.

    h(h(h(sm0+sm1) + h(sm2+sm3)) + sm4) (merkle root)
          /                         \
        h(h(sm0+sm1) + h(sm2+sm3))  sm4 (2 siblings)
        /          \                /
       h(sm0+sm1)   h(sm2+sm3)   sm4 (3 siblings)
      /   \        /   \         /
    sm0   sm1   sm2    sm3      sm4 (leaves are the base level, 5 siblings)
    ^     ^     ^      ^        ^
    |     |     |      |        |
    m0    m1    m2     m3       m4

    Ecosystem Fitโ€‹

    By integrating some very popular ZKP libraries into Substrate pallet, the rollup function of ZKP can be realized on the substrate-based chains, which is convenient for developers to develop zk applications on the substrate-based chains. Although zkp has been relatively active in the Ethereum ecosystem, zkp technology has not been widely popularized in polkadot ecosystem.

    • Zeropool implements zk on the substrate chain, but this library has not been updated for a long time. The substrate has gone through many development iterations and needs to be supported by the latest library.
    • Glacier is building a Distaff VM for zk-STARK proof generation and verification that are used to make private smart contracts and private credential verifications. Also, this project is outdate and not latest.
    • zk-plonk would like to implement Zk plonk pallet. However, plonk takes a long time to generate proofs and is generated on the chain, so there may be problems in efficiency. Also, the library this project using is not the latest.
    • ZK-Snarks tutorial want to introduce the substrate community into the zk-snarks concept๏ผŒbut their ideas and goals have been implmentd since last year. Our project will do more education and involve more zk libraries

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Name of team leader: Bun - Rust/substrate developer, mainly insterested in cryptography and blockchain
    • Name of team member: Aaron

    Contactโ€‹

    • Registered Address: 5001 BEACH ROAD, #07-37, GOLDEN MILE COMPLEX SINGAPORE (199588)
    • Registered Legal Entity: SYN UNIVERSAL PRIVATE LTD

    Team's experienceโ€‹

    • Bun
      • He has many years of blockchain experience, is familiar with the underlying protocols, consensus algorithms, and common cryptographic algorithms of blockchain.
      • He is mainly interested in zero-knowledge proof, post-quantum cryptography, etc
      • He was used to be a member of chainx, mainly develop pallet
      • Currently, he is a substrate ambassador jointly decided by oneblock+ community and parity

    Team Code Reposโ€‹

    Development Status ๐Ÿ“–โ€‹

    Currently, we have developed a substrate-based chain with zkp protocol and a practical zkp tool (which can adapt to two different zkp libraries to facilitate developers to develop zkp Dapps)

    Development Roadmap ๐Ÿ”ฉโ€‹

    We will implement two different proof systems(groth16 and plonk) separately to meet the needs of different developers

    Overviewโ€‹

    • Total Estimated Duration: 2.5 months
    • Full-Time Equivalent (FTE): 1FTE
    • Total Costs: 24,000 USD

    Milestone 1โ€‹

    • Estimated duration: 1 month
    • FTE: 1
    • Costs: 7,000 USD

    Implement groth16 pallet in Substrate and develop a tool which can let the proof of snarkjs(off-chain) verified by the bellman library(on-chain). In this way, We can make it convenient for developers to develop zkp applications using the groth16(Bellman is an excellent zkp lib, but it is easy to make mistakes when using bellman to develop circuits, and snarkjs can cooperate with circom to write circuit with few mistakes. So we combined them to make the development of zkp applications more safe and efficient). So far, we haven't seen any team do this, but we think it is very meaningful.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how users use these zk tools to generate proof and verify.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide Dockerfiles that can be used to test all the functionality delivered with this milestone.
    1.make groth16 compatible with substrateWe will create a Substrate pallet with groth16 algorithm. Bellman is not fully compatible with no_std, so we first make it possible and then we will modify attributes according to parity-codec and Rng to be compatible withใ€€Substrate environment. Finally, a zkp verification Pallet on the chain was developed
    2.adapt snarkjs and bellmanWe will use circom to write a minimal circuit example of zk rollup. Adapt snarkjs to bellman, so that the proof generated by snarkjs can be verified by the verification pallet on the substrate-based chain.
    3.ZKP education(introduction to theory and detailed example explanation)First, we will introduce the implementation principle of groth16 algorithm in an easy-to-understand way, and then explain its implementation method and architecture in detail of the example in 2 by a vedio and some articles๏ผŒso that substrate developers can know how to develop a dapp through zkp technology

    Milestone 2โ€‹

    • Estimated Duration: 1.5 month
    • FTE: 1.5
    • Costs: 17,000 USD

    Implement plonk pallet in Substrate and develop a tool which can let the proof of snarkjs(off-chain) verified by the plonk library(on-chain). In this way, We can make it convenient for developers to develop zkp applications using the Plonk(The reason is the same as that in milestone 1). So far, we haven't seen any team do this, but we think it is very meaningful.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / GPLv3 / MIT / Unlicense
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how users use these zk tools to generate proof and verify.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide Dockerfiles that can be used to test all the functionality delivered with this milestone.
    1.make plonk compatible with substrateWe will create a Substrate pallet with plonk algorithm. Many plonk librares are not fully compatible with no_std, so we first make it possible and then we will modify attributes according to parity-codec and Rng to be compatible withใ€€Substrate environment. Finally, a zkp verification Pallet on the chain was developed
    2.adapt snarkjs and plonk libWe will use circom to write a minimal circuit example of zk rollup. Adapt snarkjs to bellman, so that the proof generated by snarkjs can be verified by the verification pallet on the substrate-based chain.
    3.ZKP education(introduction to theory and detailed example explanation)First, we will introduce the implementation principle of plonk algorithm in an easy-to-understand way, and then explain its implementation method and architecture in detail of the example in 2 by a vedio and some articles๏ผŒso that substrate developers can know how to develop a dapp through zkp technology

    Future Plansโ€‹

    • Compatible with more groth16 and plonk libraries on substrate pallet
    • Develop pallet compatible with other proof system at substrate
    - + \ No newline at end of file diff --git a/applications/zkwasm-rollups-transfer.html b/applications/zkwasm-rollups-transfer.html index 4ae59bfe70f..428955294ea 100644 --- a/applications/zkwasm-rollups-transfer.html +++ b/applications/zkwasm-rollups-transfer.html @@ -4,14 +4,14 @@ Zkwasm Rollups Transfer | Web3 Foundation Grants - +
    Skip to main content

    Zkwasm Rollups Transfer

    • Team Name: Zkwasm Rollups Transfer
    • Payment Address: 0x9061b0787D28d0fDaD845d670F7505EAE5F3B01B (USDT)
    • Level: 3

    Project Overview ๐Ÿ“„โ€‹

    We would like to implement transfer rollups by zkwasm.

    This project enables us high speed and cheap gas fee transfer transactions by zkwasm. The structure is similar to zk rollup but we use wasm as execution environment.

    Overviewโ€‹

    Through this grant, we would like to implement rollup L2 envorinment for transfer transactions powered by zkwasm. The zk rollup allows us high speed and cheap gas fee transfer transactions, and to deposit asset safely. We inherit these features and execute transfer transactions on L2 wasm environment, and prove the validity of state transition by zero knowledge proof. The main differences from zk rollup are two things.

    General purpose rollupโ€‹

    The zk rollup is application specific and it can only execute transfer transactions. Supporting wasm allows us to extend to other functionalities easily as in zkevm and we can reuse the circuit which proves the validity of wasm instruction set. By implementing all wasm ISA, we can finally prove every kind of state transition.

    Implement verification function as built-inโ€‹

    The zk rollup is smart contract project. Users need to deposit their asset to smart contract on mainchain, transfer asset on chain after deposit is confirmed and withdraw asset from smart contract on mainchain. It's complicated process and needed a lot of developer workload. By implementing verification function as built-in, normal node can be L2, aggregate transfer transactions without any customizing and send it to verification on mainchain directly. This has huge usability benefit because users don't care about anything but just transfering asset as usual.

    Project Detailsโ€‹

    zkwasm depends on cryptography primitive and zero knowledge proof library.

    Cryptography Primitiveโ€‹

    In zkwasm scheme, proof generations needs heavy workload. The prover time is latency when users send transaction and verification time is gas cost for miner. We have two approach to resolve this problem. One is the optimization and the other is outsource. We already implemented curve so we would like to optimize and extend it. We are going to implement and optimize as following.

    1. implement RedDSA
    2. optimize jubjub curve
    3. implement client wallet

    RedDSA allows us to generate one time signing key which has same signature with private key. We can outsource the computation when generating proof by generating proof generation key. There are several ways to optimize jubjub so we are going to apply it to our implementation.

    Finally, we are going to implement client libraries.

    Zero Knowledge Proof Libraryโ€‹

    We generate the proof to prove the validity of wasm execution. To prove validity of execution, we use plonk. The main strategy is that writing circuits for each wasm instruction set and generate the proof. The transaction can be divided into sequence of instruction set. To prove each sequence of instruction set are executed correctly, we can prove the validity of transaction. Finally, we aggregate these proof and generate one proof. Users attach it with their transaction and blockchain verify the proof. We are going to implement following libraries to realize this scheme.

    1. implement plookup
    2. implement recursive proof
    3. implement instruction set circuits

    plookup allows us to reduce the complexity of instruction set by using lookup table and recursive proof allows us to generate one proof by aggregating proof for each instruction set.

    Ecosystem Fitโ€‹

    This zkwasm allows us to prove the validity of wasm state transition. In the future, we can extend it to general purpose rollup as in smart contract executions. This is totally compatible with wasm so every project work on wasm can use this library and rollup their transaction.

    Our project specializes in working with Substrate and Polkadot, and if we implement cryptographic libraries and optimize these, it would be used for whole network developer.

    I think this can be applied for XCMP to prove the validity of state transaction.

    Team ๐Ÿ‘ฅโ€‹

    Team membersโ€‹

    • Ash Whitehat
    • Kirill Karbushev

    Contactโ€‹

    • Registered Address: 2Fใƒป3F Emblem Nishiarai, 3-33-6 Umejima, Adachi City, Tokyo-to 121-0816, Japan
    • Registered Legal Entity: Invers Inc.

    Team's experienceโ€‹

    Our company is working on the blockchain scaling and information hiding technologies. We already delivered several grants and implemented cryptographic primitives which are compatible parity-scale-codec as described in Development Status.

    Team Code Reposโ€‹

    Team LinkedIn Profilesโ€‹

    We are not on LinkedIn.

    Development Status ๐Ÿ“–โ€‹

    We already implemented cryptographic primitives which are compatible with parity-scale-codec.

    Development Roadmap ๐Ÿ”ฉโ€‹

    Through this grant, we are going to implement the zkwasm which supports transfer transactions.

    Overviewโ€‹

    • Total Estimated Duration: 11 months
    • Full-Time Equivalent (FTE): 2 FTE
    • Total Costs: 40,000 USDT

    Milestone 1 | Crypto Primitiveโ€‹

    • Estimated duration: 2 month
    • FTE: 2
    • Costs: 10,000 USDT

    In Milestone 1, we are going to implement RedDSA, optimize Jubjub curve and client wallet. These can improve usability.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how users use the wallet and delegate proof generation.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide Dockerfiles that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/tutorial/workshop that explains
    1.RedDSA implementationWe are going to implement RedDSA. RedDSA implementation allows us to generate one time signing key to encrypt zero knowledge proof witness. One time signing key doesn't have permission to transfer asset. The specification is aligned with zcash sapling 5.4.6
    2.Jubjub curve optimizationJubjub curve optimization allows us to perform elliptic curve arithmetic quickly. In our scheme, zero-knowledge prover time is latency when users send transaction and verification time is gas cost on chain. Specifically, we implement Twisted Edwards Curves Revisited, Jacobian Coordinates and wNAF, pippenger.
    3.Client wallet implementationWe are going to implement client wallet of RedDSA. With this wallet, user can generate private key and one time signing key, and delegate their proof generation, in addition to normal wallet functionalities through RPC.

    Milestone 2 | Plonk Extensionโ€‹

    • Estimated duration: 3 month
    • FTE: 2
    • Costs: 10,000 USDT

    In Milestone 2, we are going to implement plookup and recursion on top of plonk. These can improve the performance and prove the validity of several circuits separatelly.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how users implement plookup circuit and aggregate proofs.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide Dockerfiles that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/tutorial/workshop that explains
    1.plookup implementationWe are going to implement plookup to our plonk. plookup allows us to use precomputed lookup table in zero knowledge circuit and reduce complexity of circuit.
    2.recursive proof implementationWe are going to implement recursive proof to our plonk. recursive proof allows us to generate aggregation circuit and bundle wasm ISA proofs to one.
    3.circuit implementationWe are going to implement zero knowledge circuit which supports combination of plookup and recursive proof. This circuit allows us to implement the circuit for zkwasm.

    Milestone 3 | Zk Wasm Transfer Prover and Verifierโ€‹

    • Estimated duration: 1.5 month
    • FTE: 2
    • Costs: 10,000 USDT

    In Milestone 3, we are going to implement plookup and recursive proof on top of plonk. These can improve the performance and prove the validity of several circuits separatelly.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how users prove the validity of wasm ISA execution.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide Dockerfiles that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/tutorial/workshop that explains
    1.wasm circuit implementationWe are going to implement zero knowledge circuit for wasm ISA. The transfer transaction consists of wasm ISA. We divide it into read and write access to each resource and prove with plookup and recursive proof.
    2.proof generator implementationWe are going to implement proof generator which generates the proof for wasm ISA. The input is execution trace of wasm ISA and output is zero knowledge proof. This is implemented on off-chain.
    3.proof verification implementationWe are going to implement proof verification function which verifies the proof. This is implemented on on-chain.

    Milestone 4 | Zk Wasm Transfer Rollup Nodeโ€‹

    • Estimated duration: 1.5 month
    • FTE: 2
    • Costs: 10,000 USDT

    In Milestone 4, we are going to implement rollup node. This can aggregate transfer transactions and generate proof.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0
    0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how users setup the node and send transfer transactions.
    0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
    0d.DockerWe will provide Dockerfiles that can be used to test all the functionality delivered with this milestone.
    0e.ArticleWe will publish an article/tutorial/workshop that explains
    1.rollup node implementationWe are going to implement rollup node. This allows to setup the execution environment of L2 transfer transactions, generate the proof and commit the state to mainchain.
    2.client transactor implementationWe are going to implement client library to request transfer transactions to rollup node. This is the combination of Redsa wallet and proof generator.
    3.integrate networkWe are going to integrate network. There are four actor mainchain, rollup node and transactor, prover. The transactor generates the transaction and delegate proof generation to prover. The prover generates proof and send it back to transactor. The transactor send transaction to rollup node. The rollup node aggregates these transaction and commit the state to mainchain.

    Timelineโ€‹

    MilestoneDeliverableEstimated Duration (month)Deadline
    1Crypto Primitive22023 7/31
    2Plonk Extension32023 10/31
    3Zk Wasm Transfer Prover and Verifier1.52023 12/14
    4Zk Wasm Transfer Rollup Node1.52024 1/31

    Future Plansโ€‹

    • Fully zkwasm rollup
    • Proof for XCMP
    • FHE
    • Verifiable hardware

    Additional Information โž•โ€‹

    - + \ No newline at end of file diff --git a/assets/js/90469ff1.5ad6c5b5.js b/assets/js/90469ff1.cf1e9b31.js similarity index 51% rename from assets/js/90469ff1.5ad6c5b5.js rename to assets/js/90469ff1.cf1e9b31.js index 1164202b733..ece082bf69c 100644 --- a/assets/js/90469ff1.5ad6c5b5.js +++ b/assets/js/90469ff1.cf1e9b31.js @@ -1 +1 @@ -"use strict";(self.webpackChunkgrants=self.webpackChunkgrants||[]).push([[4717],{30626:(e,t,a)=>{a.r(t),a.d(t,{assets:()=>s,contentTitle:()=>l,default:()=>h,frontMatter:()=>n,metadata:()=>o,toc:()=>p});var r=a(87462),i=(a(67294),a(3905));a(8209);const n={},l="Orochi Network's proposal for research and development MPC ECDSA",o={unversionedId:"applications/orochi-network-orosign-part1",id:"applications/orochi-network-orosign-part1",title:"Orochi Network's proposal for research and development MPC ECDSA",description:"- Team Name: Orochi Network",source:"@site/applications/orochi-network-orosign-part1.md",sourceDirName:"applications",slug:"/applications/orochi-network-orosign-part1",permalink:"/applications/orochi-network-orosign-part1",draft:!1,editUrl:"https://github.com/w3f/Grants-Program/edit/master/applications/orochi-network-orosign-part1.md",tags:[],version:"current",frontMatter:{}},s={},p=[{value:"Project Overview \ud83d\udcc4",id:"project-overview-",level:2},{value:"Overview",id:"overview",level:3},{value:"Project Details",id:"project-details",level:3},{value:"Ecosystem Fit",id:"ecosystem-fit",level:3},{value:"Team \ud83d\udc65",id:"team-",level:2},{value:"Team members",id:"team-members",level:3},{value:"Contact",id:"contact",level:3},{value:"Legal Structure",id:"legal-structure",level:3},{value:"Team's experience",id:"teams-experience",level:3},{value:"Team Code Repos",id:"team-code-repos",level:3},{value:"Team LinkedIn Profiles (if available)",id:"team-linkedin-profiles-if-available",level:3},{value:"Development Status \ud83d\udcd6",id:"development-status-",level:2},{value:"Development Roadmap \ud83d\udd29",id:"development-roadmap-",level:2},{value:"Overview",id:"overview-1",level:3},{value:"Milestone 1",id:"milestone-1",level:3},{value:"Future Plans",id:"future-plans",level:2},{value:"Additional Information \u2795",id:"additional-information-",level:2}],m={toc:p},u="wrapper";function h(e){let{components:t,...a}=e;return(0,i.kt)(u,(0,r.Z)({},m,a,{components:t,mdxType:"MDXLayout"}),(0,i.kt)("h1",{id:"orochi-networks-proposal-for-research-and-development-mpc-ecdsa"},"Orochi Network's proposal for research and development MPC ECDSA"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Team Name:")," Orochi Network"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Payment Address:")," 167Zj4mv1jBTzJimSe7LngcRS7SBixsx3ZSCFr45Eo1SjWCY (USDT Polkadot)"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},(0,i.kt)("a",{parentName:"strong",href:"https://github.com/w3f/Grants-Program/tree/master#level_slider-levels"},"Level"),":")," 1")),(0,i.kt)("h2",{id:"project-overview-"},"Project Overview \ud83d\udcc4"),(0,i.kt)("h3",{id:"overview"},"Overview"),(0,i.kt)("p",null,"Users are now able to take advantage of the highest security feature similar to a cold storage while experiencing flexibility and convenience of the mobile app at minimal cost. Orosign is a self-managing custodial Mobile App for digital assets/identity that suits all demands of Web3."),(0,i.kt)("h3",{id:"project-details"},"Project Details"),(0,i.kt)("p",null,"Orosign project utilize cryptographic primitives and Multiparty Computation (MPC) to help people manage/secure their digital assets, it could provide highest security meanwhile friendly to end-users. Orosign provides following features:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Gasless Multi-signature:")," We use ECDSA proofs to perform off-chain voting to manage multi-signature wallet."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Gaming & NFT:")," Support gaming by providing automation transaction signing for Web3 game, this wallet can manage and display NFTs."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"ZeroKey:")," A MPC based wallet, we build ECDSA on top of MPC to secure the signing process where user can perform the signing without any actual private key."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Web3 Passport:")," Support Proof of Carrying Data (PCD) for the Web3 authorization."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Account Abstraction with MPC:")," You could see the raise of Account Abstraction at the smart contract level, we want to take it a bit further with MPC. We want to provide a MPC based account abstraction for the end-users, so they can manage their digital assets in a more secure way.")),(0,i.kt)("p",null,(0,i.kt)("img",{parentName:"p",src:"https://orochi.network/assets/images/orosign.png",alt:null})),(0,i.kt)("h3",{id:"ecosystem-fit"},"Ecosystem Fit"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Non-custodial")," Users are holding their own digital asset that meant the encrypted private keys is stored in their crypto wallet and hold the major secret shares in MPC wallet. Orosign was design to make sure no one able to touch people digital asset even Orochi Network."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"High Customizability")," In gasless Multi-signature Wallet and MPC Wallet, user can customize number of participants and the threshold to perform signing process."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Highest Level of Security")," Orosign can be provide the first MPC Wallet on Polkadot."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"NFT & games optimization")," Automatic showcase for all NFT collectibles, and support automation transaction signing for Web3 game.")),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"What is the benefit of this solution compared to others?")),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Multi-signature and MPC Wallet enable highest level of security in co-ownership for vast majority of Polkadot's users."),(0,i.kt)("li",{parentName:"ul"},"Providing the first MPC Wallet as a mobile application on Polkadot"),(0,i.kt)("li",{parentName:"ul"},"Orosign is building toward the vision of Web3 passport, it allos user to manage their digital identity and assets in one place.")),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Is this meant to be an enterprise-grade security wallet such as this SaaS wallet?")),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Orosign is a self-custodian wallet, we offer enterprise-grade security for retail and semi-retail users.")),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Will it be cross-chain compatible or is it only meant for substrate chains?")),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"In the budget of this proposal we only able to support Polkadot's chain and its parachains. We will consider to support other chains in the future.")),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Can you further expand on the technical details of the wallet in the deliverables?")),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"We implement DKG to generate secret shares that will be used to perform signing process without actual private key."),(0,i.kt)("li",{parentName:"ul"},"User will hold let's say 3 shares (2 sign shares and 1 backup) of 5 shares (Orochi Network hold 2). We created a threshold signature 3 of 5, it's required at least 1 share from user to perform transaction co-signing.",(0,i.kt)("ul",{parentName:"li"},(0,i.kt)("li",{parentName:"ul"},"Orochi Network can't perform the signing process."),(0,i.kt)("li",{parentName:"ul"},"User can perform the signing process with or without Orochi Network.")))),(0,i.kt)("h2",{id:"team-"},"Team \ud83d\udc65"),(0,i.kt)("h3",{id:"team-members"},"Team members"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Chiro Hiro - CEO Orochi Network ",(0,i.kt)("a",{parentName:"li",href:"https://github.com/chiro-hiro"},"Github")),(0,i.kt)("li",{parentName:"ul"},"Hubert Nguyen - CGO Orochi Network ",(0,i.kt)("a",{parentName:"li",href:"https://github.com/hubertnguyen88"},"Github")),(0,i.kt)("li",{parentName:"ul"},"Minh - R&D Specialist ",(0,i.kt)("a",{parentName:"li",href:"https://github.com/phamnhatminh1292001"},"Github")),(0,i.kt)("li",{parentName:"ul"},"James - Front-end Developer ",(0,i.kt)("a",{parentName:"li",href:"https://github.com/seawish369"},"Github")),(0,i.kt)("li",{parentName:"ul"},"Kevin - Back-end Developer ",(0,i.kt)("a",{parentName:"li",href:"https://github.com/dqtkien"},"Github")),(0,i.kt)("li",{parentName:"ul"},"Trang - Business Analysis")),(0,i.kt)("h3",{id:"contact"},"Contact"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Contact Name:")," Hubert Nguyen"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Contact Email:")," ",(0,i.kt)("a",{parentName:"li",href:"mailto:hubert@orochi.network"},"hubert@orochi.network")),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Website:")," ",(0,i.kt)("a",{parentName:"li",href:"http://www.orochi.network"},"www.orochi.network"))),(0,i.kt)("h3",{id:"legal-structure"},"Legal Structure"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Registered Address:")," OROCHI NETWORK PTE. LTD,68 CIRCULAR ROAD , #02-01 , SINGAPORE (049422)"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Registered Legal Entity:")," OROCHI NETWORK PTE. LTD,68 CIRCULAR ROAD , #02-01 , SINGAPORE (049422)")),(0,i.kt)("h3",{id:"teams-experience"},"Team's experience"),(0,i.kt)("p",null,"We are focusing in cryptography and especially ZKP, we want to utilize cryptography to provide ",(0,i.kt)("strong",{parentName:"p"},"Verifiable Computation"),"."),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Our technical blog ",(0,i.kt)("a",{parentName:"li",href:"https://docs.orochi.network/"},"https://docs.orochi.network/")),(0,i.kt)("li",{parentName:"ul"},"Our Github repo ",(0,i.kt)("a",{parentName:"li",href:"https://github.com/orochi-network"},"https://github.com/orochi-network")),(0,i.kt)("li",{parentName:"ul"},"Our proposal for zkMemory ",(0,i.kt)("a",{parentName:"li",href:"https://hackmd.io/@chiro-hiro/SkqNGtcW2"},"https://hackmd.io/@chiro-hiro/SkqNGtcW2"))),(0,i.kt)("h3",{id:"team-code-repos"},"Team Code Repos"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"https://github.com/orochi-network"},"https://github.com/orochi-network"))),(0,i.kt)("h3",{id:"team-linkedin-profiles-if-available"},"Team LinkedIn Profiles (if available)"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"https://www.linkedin.com/in/chiro8x"},"Chiro Hiro")),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"https://www.linkedin.com/in/hungnguyen88"},"Hubert Nguyen"))),(0,i.kt)("h2",{id:"development-status-"},"Development Status \ud83d\udcd6"),(0,i.kt)("p",null,(0,i.kt)("a",{parentName:"p",href:"https://github.com/orochi-network"},"https://github.com/orochi-network")),(0,i.kt)("h2",{id:"development-roadmap-"},"Development Roadmap \ud83d\udd29"),(0,i.kt)("h3",{id:"overview-1"},"Overview"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Total Estimated Duration:")," 2"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Full-time equivalent (FTE):")," 2"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Total Costs:")," $10,000")),(0,i.kt)("h3",{id:"milestone-1"},"Milestone 1"),(0,i.kt)("p",null,"In this milestone, our team use cryptography to build a bridge from Digital Signature Algorithm (DSA especially ECDSA, EdDSA, Schnorr Signature) to Multi-Party Computation (MPC) allow the signing process to be performed without actual private key. There are 3 DSAs were used by Polkadot: ",(0,i.kt)("inlineCode",{parentName:"p"},"secp256k1"),", ",(0,i.kt)("inlineCode",{parentName:"p"},"ed25519"),", ",(0,i.kt)("inlineCode",{parentName:"p"},"sr25519"),". Before we can build a MPC based DSA, we need to research the algorithm and figure out how we could fit MPC into it. You may notice that each curve have different parameters and different field, after the research we can specify how MPC should be implement without harm its security."),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Estimated Duration:")," 2 months"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"FTE:")," 2"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Costs:")," $10,000")),(0,i.kt)("table",null,(0,i.kt)("thead",{parentName:"table"},(0,i.kt)("tr",{parentName:"thead"},(0,i.kt)("th",{parentName:"tr",align:null},"Number"),(0,i.kt)("th",{parentName:"tr",align:null},"Deliverable"),(0,i.kt)("th",{parentName:"tr",align:null},"Specification"))),(0,i.kt)("tbody",{parentName:"table"},(0,i.kt)("tr",{parentName:"tbody"},(0,i.kt)("td",{parentName:"tr",align:null},(0,i.kt)("strong",{parentName:"td"},"0a.")),(0,i.kt)("td",{parentName:"tr",align:null},"License"),(0,i.kt)("td",{parentName:"tr",align:null},"CC0 1.0")),(0,i.kt)("tr",{parentName:"tbody"},(0,i.kt)("td",{parentName:"tr",align:null},(0,i.kt)("strong",{parentName:"td"},"0b.")),(0,i.kt)("td",{parentName:"tr",align:null},"Research"),(0,i.kt)("td",{parentName:"tr",align:null},"Researching about Polkadot signature system and research their compatibility with MPC by which we can be fully comptabile with Polkadot and its parachains")),(0,i.kt)("tr",{parentName:"tbody"},(0,i.kt)("td",{parentName:"tr",align:null},(0,i.kt)("strong",{parentName:"td"},"0c.")),(0,i.kt)("td",{parentName:"tr",align:null},"Research"),(0,i.kt)("td",{parentName:"tr",align:null},"Public technical report for every research we made, everything published under ",(0,i.kt)("a",{parentName:"td",href:"https://creativecommons.org/publicdomain/zero/1.0/"},"CC0 1.0"))),(0,i.kt)("tr",{parentName:"tbody"},(0,i.kt)("td",{parentName:"tr",align:null},(0,i.kt)("strong",{parentName:"td"},"1.")),(0,i.kt)("td",{parentName:"tr",align:null},"Research"),(0,i.kt)("td",{parentName:"tr",align:null},"Researching about MPC in ECDSA (all supported signatures by Polkadot)")),(0,i.kt)("tr",{parentName:"tbody"},(0,i.kt)("td",{parentName:"tr",align:null},(0,i.kt)("strong",{parentName:"td"},"2.")),(0,i.kt)("td",{parentName:"tr",align:null},"Research"),(0,i.kt)("td",{parentName:"tr",align:null},"Researching MPC for ",(0,i.kt)("inlineCode",{parentName:"td"},"secp256k1")," and providing the document that describe how the MPC will be built and its security consideration")),(0,i.kt)("tr",{parentName:"tbody"},(0,i.kt)("td",{parentName:"tr",align:null},(0,i.kt)("strong",{parentName:"td"},"3.")),(0,i.kt)("td",{parentName:"tr",align:null},"Research"),(0,i.kt)("td",{parentName:"tr",align:null},"Researching MPC for ",(0,i.kt)("inlineCode",{parentName:"td"},"ed25519")," and providing the document that describe how the MPC will be built and its security consideration")),(0,i.kt)("tr",{parentName:"tbody"},(0,i.kt)("td",{parentName:"tr",align:null},(0,i.kt)("strong",{parentName:"td"},"4.")),(0,i.kt)("td",{parentName:"tr",align:null},"Research"),(0,i.kt)("td",{parentName:"tr",align:null},"Researching MPC in ",(0,i.kt)("inlineCode",{parentName:"td"},"sr25519")," and providing the document that describe how the MPC will be built and its security consideration")))),(0,i.kt)("h2",{id:"future-plans"},"Future Plans"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Implement MPC as a Rust crate that supports ",(0,i.kt)("inlineCode",{parentName:"li"},"secp256k1"),", ",(0,i.kt)("inlineCode",{parentName:"li"},"ed25519"),", ",(0,i.kt)("inlineCode",{parentName:"li"},"sr25519"),", supporting multiparty computation to perform transaction/message signing with mentioned DSA. This module will implement with Rust programing language and compile to Wasm opcode or native lib for React Native app."),(0,i.kt)("li",{parentName:"ul"},"Implement a node of MPC's distributed network to perform MPC."),(0,i.kt)("li",{parentName:"ul"},"Implement API interface for distributed system, allow Wallet API to connect to MPC nodes."),(0,i.kt)("li",{parentName:"ul"},"Integrate wallet API with node's RPC, provide back-end for Orosign front-end."),(0,i.kt)("li",{parentName:"ul"},"Integrate wallet API with Orosign front-end, allow users to use MPC wallet."),(0,i.kt)("li",{parentName:"ul"},"Integrate MPC in both front-end and back-end of Orosign, allow user to perform transaction signing with mobile device."),(0,i.kt)("li",{parentName:"ul"},"Support PCD (Proof of Carrying Data)")),(0,i.kt)("h2",{id:"additional-information-"},"Additional Information \u2795"),(0,i.kt)("p",null,"We do research about MPC, especially ECDSA threshold signature for 1 year, publish several articles on our blog (",(0,i.kt)("a",{parentName:"p",href:"https://docs.orochi.network"},"docs.orochi.network"),"). Drafting the paper to consider right method to Implement threshold signature (ECDSA), considering different methods to for implementation. Have some related work on MPC ",(0,i.kt)("a",{parentName:"p",href:"https://github.com/orochi-network/orochimaru/tree/main/libecvrf"},"ECVRF")," which is shared some similar primitives to ECDSA."),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Are there are any teams who have already contributed (financially) to the project?",(0,i.kt)("ul",{parentName:"li"},(0,i.kt)("li",{parentName:"ul"},"No, our project is self funded till now"))),(0,i.kt)("li",{parentName:"ul"},"Have you applied for other grants so far?",(0,i.kt)("ul",{parentName:"li"},(0,i.kt)("li",{parentName:"ul"},"No")))))}h.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkgrants=self.webpackChunkgrants||[]).push([[4717],{30626:(e,t,a)=>{a.r(t),a.d(t,{assets:()=>s,contentTitle:()=>o,default:()=>h,frontMatter:()=>n,metadata:()=>l,toc:()=>p});var r=a(87462),i=(a(67294),a(3905));a(8209);const n={},o="Orochi Network's proposal for research and development MPC ECDSA",l={unversionedId:"applications/orochi-network-orosign-part1",id:"applications/orochi-network-orosign-part1",title:"Orochi Network's proposal for research and development MPC ECDSA",description:"- Team Name: Orochi Network",source:"@site/applications/orochi-network-orosign-part1.md",sourceDirName:"applications",slug:"/applications/orochi-network-orosign-part1",permalink:"/applications/orochi-network-orosign-part1",draft:!1,editUrl:"https://github.com/w3f/Grants-Program/edit/master/applications/orochi-network-orosign-part1.md",tags:[],version:"current",frontMatter:{}},s={},p=[{value:"Project Overview \ud83d\udcc4",id:"project-overview-",level:2},{value:"Overview",id:"overview",level:3},{value:"Project Details",id:"project-details",level:3},{value:"Ecosystem Fit",id:"ecosystem-fit",level:3},{value:"Team \ud83d\udc65",id:"team-",level:2},{value:"Team members",id:"team-members",level:3},{value:"Contact",id:"contact",level:3},{value:"Legal Structure",id:"legal-structure",level:3},{value:"Team's experience",id:"teams-experience",level:3},{value:"Team Code Repos",id:"team-code-repos",level:3},{value:"Team LinkedIn Profiles (if available)",id:"team-linkedin-profiles-if-available",level:3},{value:"Development Status \ud83d\udcd6",id:"development-status-",level:2},{value:"Development Roadmap \ud83d\udd29",id:"development-roadmap-",level:2},{value:"Overview",id:"overview-1",level:3},{value:"Milestone 1",id:"milestone-1",level:3},{value:"Future Plans",id:"future-plans",level:2},{value:"Additional Information \u2795",id:"additional-information-",level:2}],m={toc:p},u="wrapper";function h(e){let{components:t,...a}=e;return(0,i.kt)(u,(0,r.Z)({},m,a,{components:t,mdxType:"MDXLayout"}),(0,i.kt)("h1",{id:"orochi-networks-proposal-for-research-and-development-mpc-ecdsa"},"Orochi Network's proposal for research and development MPC ECDSA"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Team Name:")," Orochi Network"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Payment Address:")," 167Zj4mv1jBTzJimSe7LngcRS7SBixsx3ZSCFr45Eo1SjWCY (USDT Polkadot)"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},(0,i.kt)("a",{parentName:"strong",href:"https://github.com/w3f/Grants-Program/tree/master#level_slider-levels"},"Level"),":")," 1")),(0,i.kt)("h2",{id:"project-overview-"},"Project Overview \ud83d\udcc4"),(0,i.kt)("h3",{id:"overview"},"Overview"),(0,i.kt)("p",null,"Users are now able to take advantage of the highest security feature similar to a cold storage while experiencing flexibility and convenience of the mobile app at minimal cost. Orosign is a self-managing custodial Mobile App for digital assets/identity that suits all demands of Web3."),(0,i.kt)("h3",{id:"project-details"},"Project Details"),(0,i.kt)("p",null,"Orosign project utilize cryptographic primitives and Multiparty Computation (MPC) to help people manage/secure their digital assets, it could provide highest security meanwhile friendly to end-users. Orosign provides following features:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Gasless Multi-signature:")," We use ECDSA proofs to perform off-chain voting to manage multi-signature wallet."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Gaming & NFT:")," Support gaming by providing automation transaction signing for Web3 game, this wallet can manage and display NFTs."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"ZeroKey:")," A MPC based wallet, we build ECDSA on top of MPC to secure the signing process where user can perform the signing without any actual private key."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Web3 Passport:")," Support Proof of Carrying Data (PCD) for the Web3 authorization."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Account Abstraction with MPC:")," You could see the raise of Account Abstraction at the smart contract level, we want to take it a bit further with MPC. We want to provide a MPC based account abstraction for the end-users, so they can manage their digital assets in a more secure way.")),(0,i.kt)("p",null,(0,i.kt)("img",{parentName:"p",src:"https://orochi.network/assets/images/orosign.png",alt:null})),(0,i.kt)("h3",{id:"ecosystem-fit"},"Ecosystem Fit"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Non-custodial")," Users are holding their own digital asset that meant the encrypted private keys is stored in their crypto wallet and hold the major secret shares in MPC wallet. Orosign was design to make sure no one able to touch people digital asset even Orochi Network."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"High Customizability")," In gasless Multi-signature Wallet and MPC Wallet, user can customize number of participants and the threshold to perform signing process."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Highest Level of Security")," Orosign can be provide the first MPC Wallet on Polkadot."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"NFT & games optimization")," Automatic showcase for all NFT collectibles, and support automation transaction signing for Web3 game.")),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"What is the benefit of this solution compared to others?")),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Multi-signature and MPC Wallet enable highest level of security in co-ownership for vast majority of Polkadot's users."),(0,i.kt)("li",{parentName:"ul"},"Providing the first MPC Wallet as a mobile application on Polkadot"),(0,i.kt)("li",{parentName:"ul"},"Orosign is building toward the vision of Web3 passport, it allos user to manage their digital identity and assets in one place.")),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Is this meant to be an enterprise-grade security wallet such as this SaaS wallet?")),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Orosign is a self-custodian wallet, we offer enterprise-grade security for retail and semi-retail users.")),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Will it be cross-chain compatible or is it only meant for substrate chains?")),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"In the budget of this proposal we only able to support Polkadot's chain and its parachains. We will consider to support other chains in the future.")),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Can you further expand on the technical details of the wallet in the deliverables?")),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"We implement DKG to generate secret shares that will be used to perform signing process without actual private key."),(0,i.kt)("li",{parentName:"ul"},"User will hold let's say 3 shares (2 sign shares and 1 backup) of 5 shares (Orochi Network hold 2). We created a threshold signature 3 of 5, it's required at least 1 share from user to perform transaction co-signing.",(0,i.kt)("ul",{parentName:"li"},(0,i.kt)("li",{parentName:"ul"},"Orochi Network can't perform the signing process."),(0,i.kt)("li",{parentName:"ul"},"User can perform the signing process with or without Orochi Network.")))),(0,i.kt)("h2",{id:"team-"},"Team \ud83d\udc65"),(0,i.kt)("h3",{id:"team-members"},"Team members"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Chiro Hiro - CEO Orochi Network ",(0,i.kt)("a",{parentName:"li",href:"https://github.com/chiro-hiro"},"Github")),(0,i.kt)("li",{parentName:"ul"},"Hubert Nguyen - CGO Orochi Network ",(0,i.kt)("a",{parentName:"li",href:"https://github.com/hubertnguyen88"},"Github")),(0,i.kt)("li",{parentName:"ul"},"Minh - R&D Specialist ",(0,i.kt)("a",{parentName:"li",href:"https://github.com/phamnhatminh1292001"},"Github")),(0,i.kt)("li",{parentName:"ul"},"James - Front-end Developer ",(0,i.kt)("a",{parentName:"li",href:"https://github.com/seawish369"},"Github")),(0,i.kt)("li",{parentName:"ul"},"Kevin - Back-end Developer ",(0,i.kt)("a",{parentName:"li",href:"https://github.com/dqtkien"},"Github")),(0,i.kt)("li",{parentName:"ul"},"Trang - Business Analysis")),(0,i.kt)("h3",{id:"contact"},"Contact"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Contact Name:")," Hubert Nguyen"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Contact Email:")," ",(0,i.kt)("a",{parentName:"li",href:"mailto:hubert@orochi.network"},"hubert@orochi.network")),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Website:")," ",(0,i.kt)("a",{parentName:"li",href:"http://www.orochi.network"},"www.orochi.network"))),(0,i.kt)("h3",{id:"legal-structure"},"Legal Structure"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Registered Address:")," Orochi Network LLC, Suite 305, Griffith Corporate Centre, Beachmont, Kingstown, Saint Vincent and the Grenadines (Postal code: VC0284)"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Registered Legal Entity:")," Orochi Network LLC (ID: 1416 LLC 2021)")),(0,i.kt)("h3",{id:"teams-experience"},"Team's experience"),(0,i.kt)("p",null,"We are focusing in cryptography and especially ZKP, we want to utilize cryptography to provide ",(0,i.kt)("strong",{parentName:"p"},"Verifiable Computation"),"."),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Our technical blog ",(0,i.kt)("a",{parentName:"li",href:"https://docs.orochi.network/"},"https://docs.orochi.network/")),(0,i.kt)("li",{parentName:"ul"},"Our Github repo ",(0,i.kt)("a",{parentName:"li",href:"https://github.com/orochi-network"},"https://github.com/orochi-network")),(0,i.kt)("li",{parentName:"ul"},"Our proposal for zkMemory ",(0,i.kt)("a",{parentName:"li",href:"https://hackmd.io/@chiro-hiro/SkqNGtcW2"},"https://hackmd.io/@chiro-hiro/SkqNGtcW2"))),(0,i.kt)("h3",{id:"team-code-repos"},"Team Code Repos"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"https://github.com/orochi-network"},"https://github.com/orochi-network"))),(0,i.kt)("h3",{id:"team-linkedin-profiles-if-available"},"Team LinkedIn Profiles (if available)"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"https://www.linkedin.com/in/chiro8x"},"Chiro Hiro")),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"https://www.linkedin.com/in/hungnguyen88"},"Hubert Nguyen"))),(0,i.kt)("h2",{id:"development-status-"},"Development Status \ud83d\udcd6"),(0,i.kt)("p",null,(0,i.kt)("a",{parentName:"p",href:"https://github.com/orochi-network"},"https://github.com/orochi-network")),(0,i.kt)("h2",{id:"development-roadmap-"},"Development Roadmap \ud83d\udd29"),(0,i.kt)("h3",{id:"overview-1"},"Overview"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Total Estimated Duration:")," 2"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Full-time equivalent (FTE):")," 2"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Total Costs:")," $10,000")),(0,i.kt)("h3",{id:"milestone-1"},"Milestone 1"),(0,i.kt)("p",null,"In this milestone, our team use cryptography to build a bridge from Digital Signature Algorithm (DSA especially ECDSA, EdDSA, Schnorr Signature) to Multi-Party Computation (MPC) allow the signing process to be performed without actual private key. There are 3 DSAs were used by Polkadot: ",(0,i.kt)("inlineCode",{parentName:"p"},"secp256k1"),", ",(0,i.kt)("inlineCode",{parentName:"p"},"ed25519"),", ",(0,i.kt)("inlineCode",{parentName:"p"},"sr25519"),". Before we can build a MPC based DSA, we need to research the algorithm and figure out how we could fit MPC into it. You may notice that each curve have different parameters and different field, after the research we can specify how MPC should be implement without harm its security."),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Estimated Duration:")," 2 months"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"FTE:")," 2"),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Costs:")," $10,000")),(0,i.kt)("table",null,(0,i.kt)("thead",{parentName:"table"},(0,i.kt)("tr",{parentName:"thead"},(0,i.kt)("th",{parentName:"tr",align:null},"Number"),(0,i.kt)("th",{parentName:"tr",align:null},"Deliverable"),(0,i.kt)("th",{parentName:"tr",align:null},"Specification"))),(0,i.kt)("tbody",{parentName:"table"},(0,i.kt)("tr",{parentName:"tbody"},(0,i.kt)("td",{parentName:"tr",align:null},(0,i.kt)("strong",{parentName:"td"},"0a.")),(0,i.kt)("td",{parentName:"tr",align:null},"License"),(0,i.kt)("td",{parentName:"tr",align:null},"CC0 1.0")),(0,i.kt)("tr",{parentName:"tbody"},(0,i.kt)("td",{parentName:"tr",align:null},(0,i.kt)("strong",{parentName:"td"},"0b.")),(0,i.kt)("td",{parentName:"tr",align:null},"Research"),(0,i.kt)("td",{parentName:"tr",align:null},"Researching about Polkadot signature system and research their compatibility with MPC by which we can be fully comptabile with Polkadot and its parachains")),(0,i.kt)("tr",{parentName:"tbody"},(0,i.kt)("td",{parentName:"tr",align:null},(0,i.kt)("strong",{parentName:"td"},"0c.")),(0,i.kt)("td",{parentName:"tr",align:null},"Research"),(0,i.kt)("td",{parentName:"tr",align:null},"Public technical report for every research we made, everything published under ",(0,i.kt)("a",{parentName:"td",href:"https://creativecommons.org/publicdomain/zero/1.0/"},"CC0 1.0"))),(0,i.kt)("tr",{parentName:"tbody"},(0,i.kt)("td",{parentName:"tr",align:null},(0,i.kt)("strong",{parentName:"td"},"1.")),(0,i.kt)("td",{parentName:"tr",align:null},"Research"),(0,i.kt)("td",{parentName:"tr",align:null},"Researching about MPC in ECDSA (all supported signatures by Polkadot)")),(0,i.kt)("tr",{parentName:"tbody"},(0,i.kt)("td",{parentName:"tr",align:null},(0,i.kt)("strong",{parentName:"td"},"2.")),(0,i.kt)("td",{parentName:"tr",align:null},"Research"),(0,i.kt)("td",{parentName:"tr",align:null},"Researching MPC for ",(0,i.kt)("inlineCode",{parentName:"td"},"secp256k1")," and providing the document that describe how the MPC will be built and its security consideration")),(0,i.kt)("tr",{parentName:"tbody"},(0,i.kt)("td",{parentName:"tr",align:null},(0,i.kt)("strong",{parentName:"td"},"3.")),(0,i.kt)("td",{parentName:"tr",align:null},"Research"),(0,i.kt)("td",{parentName:"tr",align:null},"Researching MPC for ",(0,i.kt)("inlineCode",{parentName:"td"},"ed25519")," and providing the document that describe how the MPC will be built and its security consideration")),(0,i.kt)("tr",{parentName:"tbody"},(0,i.kt)("td",{parentName:"tr",align:null},(0,i.kt)("strong",{parentName:"td"},"4.")),(0,i.kt)("td",{parentName:"tr",align:null},"Research"),(0,i.kt)("td",{parentName:"tr",align:null},"Researching MPC in ",(0,i.kt)("inlineCode",{parentName:"td"},"sr25519")," and providing the document that describe how the MPC will be built and its security consideration")))),(0,i.kt)("h2",{id:"future-plans"},"Future Plans"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Implement MPC as a Rust crate that supports ",(0,i.kt)("inlineCode",{parentName:"li"},"secp256k1"),", ",(0,i.kt)("inlineCode",{parentName:"li"},"ed25519"),", ",(0,i.kt)("inlineCode",{parentName:"li"},"sr25519"),", supporting multiparty computation to perform transaction/message signing with mentioned DSA. This module will implement with Rust programing language and compile to Wasm opcode or native lib for React Native app."),(0,i.kt)("li",{parentName:"ul"},"Implement a node of MPC's distributed network to perform MPC."),(0,i.kt)("li",{parentName:"ul"},"Implement API interface for distributed system, allow Wallet API to connect to MPC nodes."),(0,i.kt)("li",{parentName:"ul"},"Integrate wallet API with node's RPC, provide back-end for Orosign front-end."),(0,i.kt)("li",{parentName:"ul"},"Integrate wallet API with Orosign front-end, allow users to use MPC wallet."),(0,i.kt)("li",{parentName:"ul"},"Integrate MPC in both front-end and back-end of Orosign, allow user to perform transaction signing with mobile device."),(0,i.kt)("li",{parentName:"ul"},"Support PCD (Proof of Carrying Data)")),(0,i.kt)("h2",{id:"additional-information-"},"Additional Information \u2795"),(0,i.kt)("p",null,"We do research about MPC, especially ECDSA threshold signature for 1 year, publish several articles on our blog (",(0,i.kt)("a",{parentName:"p",href:"https://docs.orochi.network"},"docs.orochi.network"),"). Drafting the paper to consider right method to Implement threshold signature (ECDSA), considering different methods to for implementation. Have some related work on MPC ",(0,i.kt)("a",{parentName:"p",href:"https://github.com/orochi-network/orochimaru/tree/main/libecvrf"},"ECVRF")," which is shared some similar primitives to ECDSA."),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Are there are any teams who have already contributed (financially) to the project?",(0,i.kt)("ul",{parentName:"li"},(0,i.kt)("li",{parentName:"ul"},"No, our project is self funded till now"))),(0,i.kt)("li",{parentName:"ul"},"Have you applied for other grants so far?",(0,i.kt)("ul",{parentName:"li"},(0,i.kt)("li",{parentName:"ul"},"No")))))}h.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/runtime~main.260cc64b.js b/assets/js/runtime~main.49236439.js similarity index 99% rename from assets/js/runtime~main.260cc64b.js rename to assets/js/runtime~main.49236439.js index 462d2ad22c2..e23047a4f7a 100644 --- a/assets/js/runtime~main.260cc64b.js +++ b/assets/js/runtime~main.49236439.js @@ -1 +1 @@ -(()=>{"use strict";var e,b,d,c,a,f={},t={};function r(e){var b=t[e];if(void 0!==b)return b.exports;var d=t[e]={id:e,loaded:!1,exports:{}};return f[e].call(d.exports,d,d.exports,r),d.loaded=!0,d.exports}r.m=f,r.c=t,e=[],r.O=(b,d,c,a)=>{if(!d){var f=1/0;for(i=0;i=a)&&Object.keys(r.O).every((e=>r.O[e](d[o])))?d.splice(o--,1):(t=!1,a0&&e[i-1][2]>a;i--)e[i]=e[i-1];e[i]=[d,c,a]},r.n=e=>{var b=e&&e.__esModule?()=>e.default:()=>e;return r.d(b,{a:b}),b},d=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,r.t=function(e,c){if(1&c&&(e=this(e)),8&c)return e;if("object"==typeof e&&e){if(4&c&&e.__esModule)return e;if(16&c&&"function"==typeof e.then)return e}var a=Object.create(null);r.r(a);var f={};b=b||[null,d({}),d([]),d(d)];for(var t=2&c&&e;"object"==typeof t&&!~b.indexOf(t);t=d(t))Object.getOwnPropertyNames(t).forEach((b=>f[b]=()=>e[b]));return f.default=()=>e,r.d(a,f),a},r.d=(e,b)=>{for(var d in b)r.o(b,d)&&!r.o(e,d)&&Object.defineProperty(e,d,{enumerable:!0,get:b[d]})},r.f={},r.e=e=>Promise.all(Object.keys(r.f).reduce(((b,d)=>(r.f[d](e,b),b)),[])),r.u=e=>"assets/js/"+({38:"c214bc00",216:"a9d36e8e",263:"84f2dca8",369:"844d960c",463:"6a41a1d3",502:"2676e6c1",516:"47393571",543:"b827070c",783:"d718eb78",984:"23e65601",1001:"8b12cd00",1236:"70ef7226",1536:"885050db",2729:"217a1d82",2967:"2f44b910",3119:"ffafc25c",3141:"ffe39c7e",3290:"b8d83163",3351:"8f0894d7",3594:"a4861fb2",3820:"99e88449",3880:"c56a45db",3931:"d4d87a57",3990:"5d8a6e6c",4108:"d1bdd0fa",4485:"fa2dcbb0",4491:"4b6f3bbc",4510:"3c8991b9",4682:"2353df64",4717:"90469ff1",5094:"5218576a",5182:"e0c1e0d6",5319:"2fc65e44",5500:"c579011b",5546:"b626a9e3",6103:"8608173c",6210:"026f8a43",6296:"ce40746e",6795:"948cf876",6820:"c8a62906",6858:"133717db",7030:"95612694",7904:"0ea959d4",8107:"43db20c7",8493:"14ab011f",8616:"8a17d48d",8978:"92c0dc56",9145:"bda46832",9403:"b57d251e",9553:"033247b8",9844:"d595b519",10021:"c5432ea2",10080:"67183845",10444:"04a01ee2",10467:"1842ac24",10746:"56db29c6",10991:"2b2dd65a",11368:"8bc9ca9f",12002:"2e455d4b",12550:"c32240a8",12775:"c5e85f34",13129:"f3ce9685",13216:"40419be1",13451:"ab6518b5",13657:"6163dd53",13658:"2a802254",13713:"f9e765e6",13739:"071cfc94",13815:"fc587ea2",13989:"210762f3",14122:"04409633",14125:"e1527d61",14256:"917bc286",14634:"2db49e7b",15099:"6900e02e",15219:"4e299279",15359:"a473e6f5",15611:"c86840fe",15618:"7b8bf682",15804:"b54870c8",15892:"acdb258b",15897:"6e27b9d3",15906:"c1dd4621",15910:"4ca68b77",16165:"a55a9638",16676:"fc635dfc",16994:"93c7a379",17474:"b63241ae",17865:"c51cfce0",18095:"4a0590b1",18312:"5ac5eb1a",18600:"3876a1f1",18660:"6c48ccd2",18735:"7b44d16a",19006:"48d86b75",19072:"d64e42fb",19210:"e8900d59",19253:"13912f36",19291:"2d5ce48b",19619:"16b274ba",19782:"da5782cf",20886:"0211cf38",20923:"a400da89",21119:"0d2ec03f",21180:"ec059a4c",21209:"45b1d930",21324:"ee8ff1b5",21465:"51780fa8",21696:"3ab13cbf",22306:"67321f9e",22384:"c2268704",23144:"39454b3e",23240:"508e1e6a",23801:"7184e647",24566:"8bbe97eb",24586:"71f9d182",24751:"ce250987",24981:"74e36a4a",25227:"0dbc99ef",25525:"5e240566",25774:"f55cc0eb",25924:"fcbfe510",26158:"4831a431",26322:"d9fd7a7b",26372:"78a076dd",27010:"fa675db7",27174:"490c027b",27623:"05f401a8",27804:"ca3121dd",27918:"17896441",28010:"9b6c2d7b",28140:"7d5e3f2d",28732:"feb17923",28781:"29b20609",28900:"19eb7cef",28942:"6e2c89bf",28986:"fe36a4c7",29090:"466b77a0",29094:"c9a58d90",29135:"a96c1726",29271:"542b7d94",29470:"bf7d4bb0",29514:"1be78505",29654:"d17fc0cd",29803:"d1521ce5",29863:"f247b6fb",29933:"adc6f65e",30287:"c5540c98",30708:"29e919b4",30836:"0480b142",30975:"09ff2bba",31055:"743d2187",31216:"9c97aaef",31281:"7a901e9c",31668:"9a1f6492",31709:"f084b933",31759:"c9347341",32001:"6e3bb826",32051:"3acf0bda",32121:"2ed841b9",32198:"5179c3af",32305:"be394150",32409:"f107d3a3",32419:"b1853459",32599:"1f3e1758",32795:"f3d2149d",32894:"527790ee",33144:"22be61ad",33220:"0f0e6e72",33284:"72c515c0",33664:"00b945b6",33817:"0e9d4fd1",34394:"4993dcab",34494:"70eb7a71",34618:"feb5481f",34636:"5c1100ee",35001:"cbcd08eb",35172:"bb76a33d",35767:"b054b766",35798:"0fa8dfff",35849:"0f268954",35899:"37d50100",36104:"c999610f",36160:"16f90495",36599:"51eb9373",36770:"2061077e",36883:"db469a0a",37594:"146bbd18",37798:"496b07f8",37832:"cc22ecd4",38042:"ad8c84b0",38229:"7d3cadaf",38452:"e770214c",38591:"b51004e5",38751:"81026232",38781:"4c833bdc",38994:"bbe54ce8",39367:"4d29df01",39473:"33df698c",39660:"38746f92",39899:"d02b55c0",40176:"dab97983",40277:"e8d7a6d5",40398:"79fe45c9",40400:"b82dd0c5",40422:"769f7a44",40603:"f29ce45c",40659:"3de68b17",41096:"2ba08e95",41689:"77d35b39",42395:"e4d5e7b2",42606:"d4d4ccb3",42621:"2ceb8b1e",42624:"a258c9c2",42864:"8e010f80",43004:"a921adb8",43092:"b9221b05",43413:"9de97cf1",44109:"071b3461",44251:"c7df9e25",44942:"ddcf53d3",45445:"fedbe992",45713:"b029dc53",45753:"428dca98",45800:"aca0d75b",45801:"ac540a19",45802:"c367e46e",45943:"8ae0ca8b",45956:"75c173bc",46051:"14502dfa",46374:"9c461793",46514:"b7428429",46938:"83bceba8",47012:"f91a2579",47195:"a5e34c04",47260:"baf46722",47440:"b772b083",47891:"4fb110b7",47897:"f53d86c0",48344:"b6b0741b",48604:"0d247f98",48649:"f22b4b67",49039:"a13e5092",49611:"ec9bc115",49712:"512d8191",49755:"26716c91",49980:"9ed4e77f",49996:"919d73cf",50380:"6d8fec71",50401:"40aef452",50439:"8fccb5d2",50531:"181b6ec5",50722:"a2e3ec27",51127:"89da1492",51308:"746574b6",51450:"da4a9c2c",51711:"09be286f",51752:"fcd223e9",51849:"b9537d6a",51941:"9f4236b1",51948:"1c414f08",52041:"2a3d2d7f",52402:"f6136fc9",52833:"e2c93148",53116:"5d19e8c4",53640:"81fda92d",53831:"153eaba1",54123:"44d013a6",54153:"e418d32c",54463:"5b92b78e",54603:"1c362ccd",54782:"030c705f",54903:"8fb64a3d",55080:"e01469b8",55357:"c34cabf7",55557:"d2709487",55580:"6562b3cf",55868:"04a72ad1",55961:"3f3e03f1",56062:"bb9522fd",56344:"2b0e3906",56599:"c3f8e1c1",56881:"da55cb63",57254:"1c4f7bd7",57392:"8d924e0c",57422:"ddb791a8",57714:"35edfe5d",57829:"f8c8297c",58018:"039f99b9",58050:"af80e275",58159:"18db65fe",58220:"c9d90e52",58264:"51385bb4",58538:"4362a74c",58668:"686c40de",59005:"2ea27eca",59104:"ba4c506e",59138:"472f2b83",59248:"2fbfd176",59735:"4ba7e5a3",59840:"e3d564bd",60397:"34d0bf72",60407:"9a10b65c",60409:"709dd333",60622:"ef4cfc44",61026:"4fd7a5a5",61060:"bd96f483",61064:"8f41413c",61109:"dff106dc",61213:"3a064d4b",61338:"40249fd6",61422:"5dde2d34",61748:"d65a1863",61837:"8b1d6a66",61996:"dd9b495e",62155:"983a622a",62349:"d958c933",62580:"a6eb5934",62693:"3dbdd64e",62698:"d6b6deeb",63060:"80a4c802",63200:"7b2c6fa3",63227:"f5c3f7fb",63718:"3c38ea88",63877:"12e2b9b2",64047:"96c6e6da",64195:"c4f5d8e4",64240:"8b054d02",64264:"53d7406e",64429:"7d3f0232",64550:"bfd5220d",64555:"9cb18637",64634:"ce7b6de3",64763:"f036d650",65093:"aaad1650",65316:"7319d791",65569:"14854f7d",65575:"c03e4c45",65727:"9aadb410",65857:"5820f33f",66e3:"b967029f",66091:"765b73a7",66164:"9bf7be33",66183:"1553f58d",66347:"b4c938b6",66434:"81b6c359",66647:"f6fb0b44",66740:"66437b23",66979:"f4d11ede",67638:"b96f98be",67715:"55cca2cf",67780:"dbd82b5f",67883:"514186ba",67911:"97d883cd",68073:"58ba7d15",68306:"73e63d93",68472:"68fdbacf",68494:"e4a036e3",68505:"5903d9fe",68592:"common",69012:"0cf91a3d",69312:"966f33bd",69619:"a6cdc712",70051:"6475991a",70075:"d14c5b8b",70108:"6b66a434",70168:"7861fba0",70559:"cef840d9",70573:"c0035755",70761:"075bc5a3",70869:"9aee58cf",70960:"68923f8d",71273:"f42c9df1",71341:"89633389",71426:"dbbfd588",71770:"e0e0e5ec",71866:"628a0d36",71921:"f1e79774",72087:"eb2850a7",72221:"453e2297",72443:"99444684",72616:"7ffa0f98",72633:"d5510390",72748:"39658c48",72784:"437cf31d",72831:"e3f9abb2",73124:"d3a70d90",73150:"8da24fa5",73802:"3fb61c86",73832:"a144fa4f",73855:"265871a5",74302:"94e62ed7",74500:"f39c17a2",74627:"593ce03a",74643:"8ed0440b",75105:"d282fa21",75323:"b9312de0",75448:"ad7d9492",75694:"35a4d7a3",75778:"e0147a01",75809:"3edbd53d",75826:"49491008",75951:"62f57a8e",76295:"24eb123e",76458:"dbe24b2f",76774:"7dea7f5d",76840:"45727c44",76845:"8a62b5be",76983:"990fd983",77085:"9e95a131",77619:"af253e28",77798:"3f726e69",77904:"2a436572",77932:"2b8c5cd6",78112:"d1cc5cb2",78494:"484ef123",78837:"a8d723a6",79004:"c5db6f92",79233:"2ec9f803",79343:"6849bed7",79640:"bce5f2c2",79733:"6202ac8e",79815:"003507fd",79845:"83d1438d",79910:"bea3e1bc",80053:"935f2afb",81010:"84a9efaa",81381:"b1c20486",81629:"28c7acfc",81649:"6a5168b5",82002:"42b3845c",82072:"b248382e",82148:"a34c6988",82361:"ad0364aa",82535:"58916ddc",82787:"0f219439",83035:"0ca018de",83044:"5eb1d625",83184:"6d4aade0",83438:"160d2766",83816:"94c1ad37",83889:"2b11e6a2",84128:"a09c2993",84414:"79a77d53",84553:"58529492",84628:"e932408d",84982:"354a979d",85066:"348dcc60",85485:"704e19f0",85487:"1261ed3e",85628:"4c37424b",85635:"ca88de3b",85865:"e833faab",86027:"45eef51c",86042:"fae5e01b",86051:"86d7c441",86225:"203065fe",87054:"a78e484f",87114:"fcb5f29f",87264:"8f85b06a",87664:"0f3d9ed8",87746:"40dd01d7",87828:"f691884e",87831:"5d424605",87835:"4c6ba17a",88217:"35e8777e",88358:"074c5a9e",88441:"f6a3fab6",88540:"5fb8ca95",88552:"662bd64a",88602:"484ead6c",88758:"1859b273",88977:"42f4c5cc",89042:"f00d2ffa",89124:"fb79a9e5",89650:"4236a113",89715:"00c2b2a8",89996:"34dbcb71",90107:"828ccb3b",90216:"b70fab52",90218:"093042b1",90743:"fc7375fe",90994:"e3f32d12",91209:"689842b9",91373:"eb1aed0d",91539:"682cb337",91628:"250d73b2",91843:"db7ae0a9",91976:"adc2ae4e",91986:"efc88f4e",92437:"f8d3dbc8",92458:"cd24b208",92701:"ad588422",92927:"f4e7d353",92998:"fcba6891",93069:"7c6b0a32",93145:"99fad677",93209:"f6091eb4",93386:"600972a3",93466:"8cf6226e",93529:"1501273f",93665:"5e12a3a6",93868:"26a6d5df",93941:"478b05e2",94139:"79b9f7ae",94163:"f11c3e27",94183:"cd617144",94211:"667c2780",94322:"22fb5890",95111:"aa402b17",95731:"70ecfbb4",95926:"13684d46",95985:"145e8536",96027:"fbfb7b9b",96209:"31d3307a",96541:"5b4bd708",96914:"d743e462",97646:"f6e2ded6",97686:"f3dd1f7b",97920:"1a4e3797",98071:"e1c68ef1",98248:"a96e9a0c",98746:"8f656afc",98785:"618023cd",99056:"2ebf6bd3",99508:"5f2c2d9f",99769:"f8aa15ec",99796:"18ad0f10",99878:"c6b877b9",99980:"905708d8"}[e]||e)+"."+{38:"b2635bcc",216:"14a55eba",263:"d5a7434d",369:"e61846b9",463:"e2402170",502:"5091936d",516:"35763f65",543:"cf17390e",783:"6da88ff9",984:"d75b1362",1001:"70627e4a",1236:"f07bba98",1536:"1f8fd623",2729:"62828cd9",2967:"cd4b6c4e",3119:"4a40c5ce",3141:"a8f39186",3290:"25122efb",3351:"ed7bc8f6",3594:"1446a05d",3820:"bc73e4ad",3880:"3446b814",3931:"1652378a",3990:"86ca6092",4108:"0297eae3",4485:"558eae44",4491:"c2ef589e",4510:"187d0271",4682:"91f089aa",4717:"5ad6c5b5",4972:"9e3bdb71",5094:"c54583ff",5182:"955969c0",5319:"5e75731b",5500:"d2241cb0",5546:"6c005d8d",6103:"3c41f295",6210:"9d18cecb",6296:"83b2aee2",6795:"7aca5b57",6820:"d497a2e5",6858:"c7cc0a96",7030:"daa00586",7904:"27ce7428",8107:"662b6ab0",8493:"f4ddb845",8616:"25e43a1e",8978:"ecea5277",9145:"a873dad1",9403:"1ef4ac20",9553:"a2d7a6c5",9844:"f6c0b45e",10021:"34c38a93",10080:"5f5ce90c",10444:"86a2ac54",10467:"1e8b840b",10696:"6913c047",10746:"aa89a180",10991:"f7d4ba0c",11368:"e3268b1f",12002:"092510c1",12550:"d7b7c5a7",12775:"900bf0c0",13129:"25610ab1",13216:"6fac329a",13451:"07f14092",13657:"70e21339",13658:"3bb41d31",13713:"116a9a27",13739:"eaa4fb2e",13815:"a3a3b317",13989:"c14047dc",14122:"42ea3a1b",14125:"7131da35",14256:"7c0a64b3",14634:"11e00f91",15099:"7e268bca",15219:"6099f30d",15359:"c8b65575",15611:"ee9f4257",15618:"f85fa516",15649:"51768373",15804:"2a717478",15892:"5865000f",15897:"8eb6e1a1",15906:"635e2bf9",15910:"06229dfd",16165:"c549b13b",16676:"7ed80efe",16994:"6d59877a",17474:"53ab6250",17865:"7fd228c2",18095:"ad3b013f",18312:"e30853e8",18600:"40bd604c",18660:"2b525fdc",18735:"f5b3efd4",18894:"1e0de85f",19006:"f2bf69a7",19072:"fc376622",19210:"4b50ac43",19253:"bd69211f",19291:"8116d2dc",19619:"f068cd3c",19782:"9844cf7c",20886:"1c3ad06f",20923:"de8a1485",21119:"3c7042c7",21180:"49867a85",21209:"37523d47",21324:"5307eb4e",21465:"f66670c1",21696:"41da7652",22146:"64e2b6ba",22306:"fd924714",22384:"9e2f920e",23144:"6f6ef7df",23240:"04a74a04",23801:"e6ab185a",24535:"7d640f97",24566:"25852570",24586:"64912b1c",24751:"50fb9e4b",24981:"805fd090",25227:"adae8699",25525:"92789d0c",25670:"aa608768",25774:"3f28c3a7",25924:"8df32b24",26158:"7acd0cf9",26322:"f2e84b63",26345:"ef8ba99e",26372:"7fab9551",27010:"062cfc57",27174:"d7760474",27623:"6e6211ee",27804:"777c32de",27918:"3bc85d93",28010:"0a6f3e9e",28140:"aa29a3d3",28732:"1a78ca71",28781:"1c41ef1b",28900:"936e4789",28942:"c96a9f11",28986:"90a95817",29090:"58073b71",29094:"3334a310",29135:"e42644d1",29271:"6441706a",29470:"c5204677",29514:"36770ffd",29654:"699b4fe3",29803:"cf7706df",29863:"5824798f",29933:"fc5a0a8e",30287:"12d01fe7",30708:"115a8aca",30836:"dde746a4",30975:"404effef",31055:"086e3b39",31216:"d794b5ca",31281:"aaeba376",31523:"5e5991ea",31668:"f70909ba",31709:"a97adbce",31759:"5809e5e1",32001:"7d3a6799",32051:"b587b805",32121:"a3a8adfa",32198:"bec72262",32305:"2d759ac3",32409:"42fd7ae0",32419:"bfe0985b",32599:"1a8cf2a7",32795:"e5c71ca4",32894:"3bc42fec",33144:"0b8cfe3d",33220:"2962e0c7",33284:"9ea1683d",33664:"b9b18439",33817:"d80397ee",34307:"d0ab9e01",34394:"36b4ecb9",34494:"a5a7b9ca",34618:"a834a7c2",34636:"fb783e98",35001:"051950d7",35172:"c72dc7d1",35767:"0876ed47",35798:"b531245c",35849:"67a4e661",35899:"2a22af31",36104:"57065bc9",36160:"95539149",36599:"68cb3606",36770:"c1d86708",36883:"c43cf4c5",37594:"a65633d7",37798:"eb32075c",37832:"69f98bef",38042:"e32bb085",38229:"8ce823d1",38452:"7b50cbb5",38591:"2231909c",38751:"e014fc35",38781:"0a47fb06",38994:"29241f71",39186:"beb526ea",39367:"079586ae",39473:"0a4975f4",39660:"fe01ef43",39899:"eb67c7cd",40176:"7309e620",40277:"59377c6c",40398:"c9fc085f",40400:"ef628944",40422:"63b2c1e2",40603:"ea484d21",40659:"35f4c25b",41096:"b64b89ba",41689:"c57280ae",42070:"aaa5dec1",42395:"46b1873d",42494:"594ce7cb",42606:"5962bdc1",42621:"e3bdf192",42624:"13e8c36b",42864:"0cf9c538",43004:"cf62fb5a",43092:"5e305f23",43398:"a527d9e4",43413:"3c649c2f",44109:"592d08f2",44251:"3515fa6e",44942:"c37170e9",45445:"4220f1f7",45713:"f2f08a30",45753:"dd2d69e7",45800:"ed28e9b3",45801:"aa984602",45802:"20c5e9a0",45943:"100760e5",45956:"edaa40df",46051:"1e8f4f63",46374:"45f7ae9a",46514:"a8911fc6",46938:"e66a7cab",46945:"f70129bd",47012:"8a9b806c",47195:"293d9b1d",47260:"d418f744",47440:"b5a4b0fb",47891:"a6db4d75",47897:"c21aecd7",48344:"1f2a036a",48604:"cc072766",48649:"3677df10",49039:"9ac3d6ec",49611:"753c8d5a",49712:"c214079c",49755:"3b1ad2d9",49980:"f95369e7",49996:"85a038ef",50380:"fd648f5a",50401:"36a0aaae",50439:"82bcba9e",50531:"502d7aa6",50722:"779cf8fe",51127:"4ea23f97",51308:"b3cf611f",51450:"269b09f5",51711:"1d015114",51752:"05f330ac",51849:"e4ef9fcf",51915:"38541819",51941:"01d2e734",51948:"e7c733d2",52041:"2a30921c",52402:"ad1240fe",52833:"60442a7d",53116:"72b3e235",53640:"3ad85d02",53831:"6c2a4b4f",53868:"5509ba78",54038:"cc51a94a",54123:"51daedaf",54153:"6faef210",54463:"3bb0fd95",54603:"35398c7c",54782:"23dabfd0",54903:"240c5a2d",54954:"076e95f2",55080:"9a6a5cfa",55357:"2e87e00a",55557:"d4c0d9af",55580:"266a67f0",55868:"b82eab7a",55961:"59703ff4",56062:"6e280866",56344:"e993c4ec",56599:"4ddcbaf1",56881:"cda38dec",57254:"9328f383",57392:"3cf8ac74",57422:"3514cf78",57714:"3a8468a1",57829:"167036dc",58018:"9a9cd6ac",58050:"6b9bcc01",58159:"99c1b368",58220:"c66943e3",58264:"42b44f8e",58538:"d12f66ee",58668:"8b19bacc",59005:"fbcb5763",59104:"d33f1f6a",59138:"b4ced459",59248:"44c17486",59735:"d12cdd6e",59840:"494d8e51",60397:"21c241b0",60407:"122bb679",60409:"e3093902",60622:"bfdee689",61026:"21f148f1",61060:"4ab9c4ee",61064:"3ada3929",61109:"9ffcdffa",61213:"7d112706",61338:"168ad9d3",61422:"43dc2fb2",61426:"64640048",61748:"fb2afba9",61837:"c21a08f8",61996:"2da79123",62155:"1be46354",62349:"8ae57ca1",62580:"c2914c73",62693:"5bac9361",62698:"bbb4d4c2",63060:"0eaee253",63200:"5afe6abe",63227:"57e466a8",63718:"535ac941",63877:"05f20c4a",64047:"9ef2b0fd",64195:"3ad63c78",64240:"76746b26",64264:"c5c22b9e",64429:"7ffbacf3",64550:"20dd1de3",64555:"38a6725b",64634:"f35197e0",64763:"982a6ab6",65093:"e40fa264",65316:"27b079bd",65569:"777f975a",65575:"75d6cd70",65727:"26a0c09e",65857:"99a2cb61",66e3:"bb5b94f1",66091:"7f50313f",66102:"cf9f339d",66164:"e3b43a92",66183:"5534ec95",66347:"75e1fc22",66434:"a917e4a8",66647:"607f4d5e",66740:"0b6e1e76",66979:"a10b7451",67638:"752fc983",67715:"14cc52a2",67780:"3f2ed0a3",67883:"48e4d503",67911:"8d26fa76",68073:"2868f5f5",68306:"3a4bb161",68472:"9ff9a1d7",68494:"70c83c7a",68505:"7a8af038",68592:"fbdee77f",69012:"7b1db030",69312:"2dfa500c",69619:"a392b2d8",70051:"52915032",70075:"dd3482e5",70108:"2ae8740d",70168:"c87a8d24",70299:"bcc91462",70559:"c0cdc20c",70573:"7f9d7a4a",70761:"c356d643",70869:"81e26f23",70960:"da1e0949",71273:"e0af0a98",71341:"fb5d0144",71426:"adb002f1",71770:"c21f24b5",71866:"f84ac9cf",71921:"f9e2a60c",72087:"d3c0f641",72221:"b1fa9363",72443:"04066d4b",72616:"74d64306",72633:"22db9f45",72748:"1cbac600",72784:"3d134d12",72831:"da9a2497",73124:"a6fe2206",73150:"763db0e6",73802:"a07d6afe",73832:"96d419be",73855:"9859748f",74302:"fd6576a6",74500:"e138e795",74627:"2f6594c7",74643:"2a2e6567",75105:"f81d9b87",75323:"9f30e88b",75448:"ab1d7405",75694:"de36cf5c",75778:"fea6e1d8",75809:"0aeb568c",75826:"2b838d7b",75951:"d1be8d88",76295:"e11a1c60",76458:"3b7f2d64",76774:"d72864cc",76840:"d664d574",76845:"bb6b97d3",76983:"ba3c220d",77085:"5cb04cfa",77480:"c0bf5a14",77583:"c4b2cdba",77619:"d9d0712a",77798:"c0311b00",77904:"e3d2a6a4",77932:"42c59fb9",78112:"43ee9756",78494:"5aaa169e",78837:"081e57c2",79004:"adf72fdc",79233:"ef7cf084",79343:"7c9946b8",79640:"b769bf94",79733:"30de0c3c",79815:"f97dc900",79845:"1dda17bd",79910:"ab751cf0",80053:"7242f543",81010:"12e0386d",81381:"f1c6b650",81629:"5f1809df",81649:"151c2ebc",82002:"71041581",82072:"c0e4f358",82148:"be8c3f85",82361:"697bc030",82535:"1c6669a9",82787:"f9ea0df9",83035:"57672c53",83044:"74b13e1d",83145:"dfc6852e",83184:"12b42e23",83438:"af2f9657",83816:"46d6063f",83889:"f7103a27",84128:"11e39a3f",84414:"22935e5a",84484:"b63b0d7d",84553:"efa25d63",84628:"228fdbdc",84982:"8488054b",85066:"36b5c2d8",85485:"446b4a5a",85487:"58c3c36d",85628:"5644cb79",85635:"731e9d8c",85865:"0e19f6ff",86027:"2a1aff0f",86042:"cc954af9",86051:"1613163c",86225:"68122dc7",87054:"0f8ed7c1",87114:"0c1688a3",87264:"140bef78",87664:"19af5e0b",87746:"685a052b",87828:"78fdd5e9",87831:"d66f53f1",87835:"84d252f5",88217:"6c60b9f5",88358:"afb0c344",88441:"1aa31fa4",88540:"33d1157c",88549:"f76427c0",88552:"a4f6a91b",88602:"67b8f943",88758:"763daeef",88977:"2c5da874",89042:"8fdc0f87",89124:"809f8f1f",89419:"85850878",89650:"4bf7022d",89715:"dffe6809",89996:"d284e7ef",90107:"55d38895",90216:"7819b2b7",90218:"9cc4af84",90743:"1e01a9e0",90894:"38287227",90994:"37d140e0",91209:"661d750a",91373:"d2455d85",91539:"e2ab1c02",91628:"a618b036",91843:"9800ee9b",91976:"561445bd",91986:"44a217e8",92262:"c5ac8f1f",92437:"c588b3bd",92458:"a6438534",92701:"3d01dd36",92927:"191c5291",92998:"7bee07bc",93069:"7131a195",93145:"13c49f5f",93209:"cdc6dd2b",93386:"34bc6e7c",93466:"1fc4233b",93529:"1f4363e1",93665:"7593310a",93868:"4683066a",93941:"97b4bd7b",94139:"6e802814",94163:"44797c3f",94183:"483d133f",94211:"f2252d57",94322:"f4b77131",95111:"1d79244f",95731:"2d96c0e8",95926:"4fb538e6",95940:"fc42ba15",95985:"83c33628",96027:"4e9e7bfe",96209:"99a6816d",96541:"745b564e",96914:"a566a108",97646:"15710857",97686:"a9eb6f36",97920:"45f6cca8",98071:"ac5eb1f1",98248:"87ac0d33",98746:"147c314a",98785:"acf6d590",99056:"38ff4741",99508:"61d91d57",99769:"825d8952",99796:"3822c739",99878:"bbcee2f0",99980:"d869c6c5"}[e]+".js",r.miniCssF=e=>{},r.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),r.o=(e,b)=>Object.prototype.hasOwnProperty.call(e,b),c={},a="grants:",r.l=(e,b,d,f)=>{if(c[e])c[e].push(b);else{var t,o;if(void 0!==d)for(var n=document.getElementsByTagName("script"),i=0;i{t.onerror=t.onload=null,clearTimeout(s);var a=c[e];if(delete c[e],t.parentNode&&t.parentNode.removeChild(t),a&&a.forEach((e=>e(d))),b)return b(d)},s=setTimeout(l.bind(null,void 0,{type:"timeout",target:t}),12e4);t.onerror=l.bind(null,t.onerror),t.onload=l.bind(null,t.onload),o&&document.head.appendChild(t)}},r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.p="/",r.gca=function(e){return e={17896441:"27918",47393571:"516",49491008:"75826",58529492:"84553",67183845:"10080",81026232:"38751",89633389:"71341",95612694:"7030",99444684:"72443",c214bc00:"38",a9d36e8e:"216","84f2dca8":"263","844d960c":"369","6a41a1d3":"463","2676e6c1":"502",b827070c:"543",d718eb78:"783","23e65601":"984","8b12cd00":"1001","70ef7226":"1236","885050db":"1536","217a1d82":"2729","2f44b910":"2967",ffafc25c:"3119",ffe39c7e:"3141",b8d83163:"3290","8f0894d7":"3351",a4861fb2:"3594","99e88449":"3820",c56a45db:"3880",d4d87a57:"3931","5d8a6e6c":"3990",d1bdd0fa:"4108",fa2dcbb0:"4485","4b6f3bbc":"4491","3c8991b9":"4510","2353df64":"4682","90469ff1":"4717","5218576a":"5094",e0c1e0d6:"5182","2fc65e44":"5319",c579011b:"5500",b626a9e3:"5546","8608173c":"6103","026f8a43":"6210",ce40746e:"6296","948cf876":"6795",c8a62906:"6820","133717db":"6858","0ea959d4":"7904","43db20c7":"8107","14ab011f":"8493","8a17d48d":"8616","92c0dc56":"8978",bda46832:"9145",b57d251e:"9403","033247b8":"9553",d595b519:"9844",c5432ea2:"10021","04a01ee2":"10444","1842ac24":"10467","56db29c6":"10746","2b2dd65a":"10991","8bc9ca9f":"11368","2e455d4b":"12002",c32240a8:"12550",c5e85f34:"12775",f3ce9685:"13129","40419be1":"13216",ab6518b5:"13451","6163dd53":"13657","2a802254":"13658",f9e765e6:"13713","071cfc94":"13739",fc587ea2:"13815","210762f3":"13989","04409633":"14122",e1527d61:"14125","917bc286":"14256","2db49e7b":"14634","6900e02e":"15099","4e299279":"15219",a473e6f5:"15359",c86840fe:"15611","7b8bf682":"15618",b54870c8:"15804",acdb258b:"15892","6e27b9d3":"15897",c1dd4621:"15906","4ca68b77":"15910",a55a9638:"16165",fc635dfc:"16676","93c7a379":"16994",b63241ae:"17474",c51cfce0:"17865","4a0590b1":"18095","5ac5eb1a":"18312","3876a1f1":"18600","6c48ccd2":"18660","7b44d16a":"18735","48d86b75":"19006",d64e42fb:"19072",e8900d59:"19210","13912f36":"19253","2d5ce48b":"19291","16b274ba":"19619",da5782cf:"19782","0211cf38":"20886",a400da89:"20923","0d2ec03f":"21119",ec059a4c:"21180","45b1d930":"21209",ee8ff1b5:"21324","51780fa8":"21465","3ab13cbf":"21696","67321f9e":"22306",c2268704:"22384","39454b3e":"23144","508e1e6a":"23240","7184e647":"23801","8bbe97eb":"24566","71f9d182":"24586",ce250987:"24751","74e36a4a":"24981","0dbc99ef":"25227","5e240566":"25525",f55cc0eb:"25774",fcbfe510:"25924","4831a431":"26158",d9fd7a7b:"26322","78a076dd":"26372",fa675db7:"27010","490c027b":"27174","05f401a8":"27623",ca3121dd:"27804","9b6c2d7b":"28010","7d5e3f2d":"28140",feb17923:"28732","29b20609":"28781","19eb7cef":"28900","6e2c89bf":"28942",fe36a4c7:"28986","466b77a0":"29090",c9a58d90:"29094",a96c1726:"29135","542b7d94":"29271",bf7d4bb0:"29470","1be78505":"29514",d17fc0cd:"29654",d1521ce5:"29803",f247b6fb:"29863",adc6f65e:"29933",c5540c98:"30287","29e919b4":"30708","0480b142":"30836","09ff2bba":"30975","743d2187":"31055","9c97aaef":"31216","7a901e9c":"31281","9a1f6492":"31668",f084b933:"31709",c9347341:"31759","6e3bb826":"32001","3acf0bda":"32051","2ed841b9":"32121","5179c3af":"32198",be394150:"32305",f107d3a3:"32409",b1853459:"32419","1f3e1758":"32599",f3d2149d:"32795","527790ee":"32894","22be61ad":"33144","0f0e6e72":"33220","72c515c0":"33284","00b945b6":"33664","0e9d4fd1":"33817","4993dcab":"34394","70eb7a71":"34494",feb5481f:"34618","5c1100ee":"34636",cbcd08eb:"35001",bb76a33d:"35172",b054b766:"35767","0fa8dfff":"35798","0f268954":"35849","37d50100":"35899",c999610f:"36104","16f90495":"36160","51eb9373":"36599","2061077e":"36770",db469a0a:"36883","146bbd18":"37594","496b07f8":"37798",cc22ecd4:"37832",ad8c84b0:"38042","7d3cadaf":"38229",e770214c:"38452",b51004e5:"38591","4c833bdc":"38781",bbe54ce8:"38994","4d29df01":"39367","33df698c":"39473","38746f92":"39660",d02b55c0:"39899",dab97983:"40176",e8d7a6d5:"40277","79fe45c9":"40398",b82dd0c5:"40400","769f7a44":"40422",f29ce45c:"40603","3de68b17":"40659","2ba08e95":"41096","77d35b39":"41689",e4d5e7b2:"42395",d4d4ccb3:"42606","2ceb8b1e":"42621",a258c9c2:"42624","8e010f80":"42864",a921adb8:"43004",b9221b05:"43092","9de97cf1":"43413","071b3461":"44109",c7df9e25:"44251",ddcf53d3:"44942",fedbe992:"45445",b029dc53:"45713","428dca98":"45753",aca0d75b:"45800",ac540a19:"45801",c367e46e:"45802","8ae0ca8b":"45943","75c173bc":"45956","14502dfa":"46051","9c461793":"46374",b7428429:"46514","83bceba8":"46938",f91a2579:"47012",a5e34c04:"47195",baf46722:"47260",b772b083:"47440","4fb110b7":"47891",f53d86c0:"47897",b6b0741b:"48344","0d247f98":"48604",f22b4b67:"48649",a13e5092:"49039",ec9bc115:"49611","512d8191":"49712","26716c91":"49755","9ed4e77f":"49980","919d73cf":"49996","6d8fec71":"50380","40aef452":"50401","8fccb5d2":"50439","181b6ec5":"50531",a2e3ec27:"50722","89da1492":"51127","746574b6":"51308",da4a9c2c:"51450","09be286f":"51711",fcd223e9:"51752",b9537d6a:"51849","9f4236b1":"51941","1c414f08":"51948","2a3d2d7f":"52041",f6136fc9:"52402",e2c93148:"52833","5d19e8c4":"53116","81fda92d":"53640","153eaba1":"53831","44d013a6":"54123",e418d32c:"54153","5b92b78e":"54463","1c362ccd":"54603","030c705f":"54782","8fb64a3d":"54903",e01469b8:"55080",c34cabf7:"55357",d2709487:"55557","6562b3cf":"55580","04a72ad1":"55868","3f3e03f1":"55961",bb9522fd:"56062","2b0e3906":"56344",c3f8e1c1:"56599",da55cb63:"56881","1c4f7bd7":"57254","8d924e0c":"57392",ddb791a8:"57422","35edfe5d":"57714",f8c8297c:"57829","039f99b9":"58018",af80e275:"58050","18db65fe":"58159",c9d90e52:"58220","51385bb4":"58264","4362a74c":"58538","686c40de":"58668","2ea27eca":"59005",ba4c506e:"59104","472f2b83":"59138","2fbfd176":"59248","4ba7e5a3":"59735",e3d564bd:"59840","34d0bf72":"60397","9a10b65c":"60407","709dd333":"60409",ef4cfc44:"60622","4fd7a5a5":"61026",bd96f483:"61060","8f41413c":"61064",dff106dc:"61109","3a064d4b":"61213","40249fd6":"61338","5dde2d34":"61422",d65a1863:"61748","8b1d6a66":"61837",dd9b495e:"61996","983a622a":"62155",d958c933:"62349",a6eb5934:"62580","3dbdd64e":"62693",d6b6deeb:"62698","80a4c802":"63060","7b2c6fa3":"63200",f5c3f7fb:"63227","3c38ea88":"63718","12e2b9b2":"63877","96c6e6da":"64047",c4f5d8e4:"64195","8b054d02":"64240","53d7406e":"64264","7d3f0232":"64429",bfd5220d:"64550","9cb18637":"64555",ce7b6de3:"64634",f036d650:"64763",aaad1650:"65093","7319d791":"65316","14854f7d":"65569",c03e4c45:"65575","9aadb410":"65727","5820f33f":"65857",b967029f:"66000","765b73a7":"66091","9bf7be33":"66164","1553f58d":"66183",b4c938b6:"66347","81b6c359":"66434",f6fb0b44:"66647","66437b23":"66740",f4d11ede:"66979",b96f98be:"67638","55cca2cf":"67715",dbd82b5f:"67780","514186ba":"67883","97d883cd":"67911","58ba7d15":"68073","73e63d93":"68306","68fdbacf":"68472",e4a036e3:"68494","5903d9fe":"68505",common:"68592","0cf91a3d":"69012","966f33bd":"69312",a6cdc712:"69619","6475991a":"70051",d14c5b8b:"70075","6b66a434":"70108","7861fba0":"70168",cef840d9:"70559",c0035755:"70573","075bc5a3":"70761","9aee58cf":"70869","68923f8d":"70960",f42c9df1:"71273",dbbfd588:"71426",e0e0e5ec:"71770","628a0d36":"71866",f1e79774:"71921",eb2850a7:"72087","453e2297":"72221","7ffa0f98":"72616",d5510390:"72633","39658c48":"72748","437cf31d":"72784",e3f9abb2:"72831",d3a70d90:"73124","8da24fa5":"73150","3fb61c86":"73802",a144fa4f:"73832","265871a5":"73855","94e62ed7":"74302",f39c17a2:"74500","593ce03a":"74627","8ed0440b":"74643",d282fa21:"75105",b9312de0:"75323",ad7d9492:"75448","35a4d7a3":"75694",e0147a01:"75778","3edbd53d":"75809","62f57a8e":"75951","24eb123e":"76295",dbe24b2f:"76458","7dea7f5d":"76774","45727c44":"76840","8a62b5be":"76845","990fd983":"76983","9e95a131":"77085",af253e28:"77619","3f726e69":"77798","2a436572":"77904","2b8c5cd6":"77932",d1cc5cb2:"78112","484ef123":"78494",a8d723a6:"78837",c5db6f92:"79004","2ec9f803":"79233","6849bed7":"79343",bce5f2c2:"79640","6202ac8e":"79733","003507fd":"79815","83d1438d":"79845",bea3e1bc:"79910","935f2afb":"80053","84a9efaa":"81010",b1c20486:"81381","28c7acfc":"81629","6a5168b5":"81649","42b3845c":"82002",b248382e:"82072",a34c6988:"82148",ad0364aa:"82361","58916ddc":"82535","0f219439":"82787","0ca018de":"83035","5eb1d625":"83044","6d4aade0":"83184","160d2766":"83438","94c1ad37":"83816","2b11e6a2":"83889",a09c2993:"84128","79a77d53":"84414",e932408d:"84628","354a979d":"84982","348dcc60":"85066","704e19f0":"85485","1261ed3e":"85487","4c37424b":"85628",ca88de3b:"85635",e833faab:"85865","45eef51c":"86027",fae5e01b:"86042","86d7c441":"86051","203065fe":"86225",a78e484f:"87054",fcb5f29f:"87114","8f85b06a":"87264","0f3d9ed8":"87664","40dd01d7":"87746",f691884e:"87828","5d424605":"87831","4c6ba17a":"87835","35e8777e":"88217","074c5a9e":"88358",f6a3fab6:"88441","5fb8ca95":"88540","662bd64a":"88552","484ead6c":"88602","1859b273":"88758","42f4c5cc":"88977",f00d2ffa:"89042",fb79a9e5:"89124","4236a113":"89650","00c2b2a8":"89715","34dbcb71":"89996","828ccb3b":"90107",b70fab52:"90216","093042b1":"90218",fc7375fe:"90743",e3f32d12:"90994","689842b9":"91209",eb1aed0d:"91373","682cb337":"91539","250d73b2":"91628",db7ae0a9:"91843",adc2ae4e:"91976",efc88f4e:"91986",f8d3dbc8:"92437",cd24b208:"92458",ad588422:"92701",f4e7d353:"92927",fcba6891:"92998","7c6b0a32":"93069","99fad677":"93145",f6091eb4:"93209","600972a3":"93386","8cf6226e":"93466","1501273f":"93529","5e12a3a6":"93665","26a6d5df":"93868","478b05e2":"93941","79b9f7ae":"94139",f11c3e27:"94163",cd617144:"94183","667c2780":"94211","22fb5890":"94322",aa402b17:"95111","70ecfbb4":"95731","13684d46":"95926","145e8536":"95985",fbfb7b9b:"96027","31d3307a":"96209","5b4bd708":"96541",d743e462:"96914",f6e2ded6:"97646",f3dd1f7b:"97686","1a4e3797":"97920",e1c68ef1:"98071",a96e9a0c:"98248","8f656afc":"98746","618023cd":"98785","2ebf6bd3":"99056","5f2c2d9f":"99508",f8aa15ec:"99769","18ad0f10":"99796",c6b877b9:"99878","905708d8":"99980"}[e]||e,r.p+r.u(e)},(()=>{var e={51303:0,40532:0};r.f.j=(b,d)=>{var c=r.o(e,b)?e[b]:void 0;if(0!==c)if(c)d.push(c[2]);else if(/^(40532|51303)$/.test(b))e[b]=0;else{var a=new Promise(((d,a)=>c=e[b]=[d,a]));d.push(c[2]=a);var f=r.p+r.u(b),t=new Error;r.l(f,(d=>{if(r.o(e,b)&&(0!==(c=e[b])&&(e[b]=void 0),c)){var a=d&&("load"===d.type?"missing":d.type),f=d&&d.target&&d.target.src;t.message="Loading chunk "+b+" failed.\n("+a+": "+f+")",t.name="ChunkLoadError",t.type=a,t.request=f,c[1](t)}}),"chunk-"+b,b)}},r.O.j=b=>0===e[b];var b=(b,d)=>{var c,a,f=d[0],t=d[1],o=d[2],n=0;if(f.some((b=>0!==e[b]))){for(c in t)r.o(t,c)&&(r.m[c]=t[c]);if(o)var i=o(r)}for(b&&b(d);n{"use strict";var e,b,d,c,a,f={},t={};function r(e){var b=t[e];if(void 0!==b)return b.exports;var d=t[e]={id:e,loaded:!1,exports:{}};return f[e].call(d.exports,d,d.exports,r),d.loaded=!0,d.exports}r.m=f,r.c=t,e=[],r.O=(b,d,c,a)=>{if(!d){var f=1/0;for(i=0;i=a)&&Object.keys(r.O).every((e=>r.O[e](d[o])))?d.splice(o--,1):(t=!1,a0&&e[i-1][2]>a;i--)e[i]=e[i-1];e[i]=[d,c,a]},r.n=e=>{var b=e&&e.__esModule?()=>e.default:()=>e;return r.d(b,{a:b}),b},d=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,r.t=function(e,c){if(1&c&&(e=this(e)),8&c)return e;if("object"==typeof e&&e){if(4&c&&e.__esModule)return e;if(16&c&&"function"==typeof e.then)return e}var a=Object.create(null);r.r(a);var f={};b=b||[null,d({}),d([]),d(d)];for(var t=2&c&&e;"object"==typeof t&&!~b.indexOf(t);t=d(t))Object.getOwnPropertyNames(t).forEach((b=>f[b]=()=>e[b]));return f.default=()=>e,r.d(a,f),a},r.d=(e,b)=>{for(var d in b)r.o(b,d)&&!r.o(e,d)&&Object.defineProperty(e,d,{enumerable:!0,get:b[d]})},r.f={},r.e=e=>Promise.all(Object.keys(r.f).reduce(((b,d)=>(r.f[d](e,b),b)),[])),r.u=e=>"assets/js/"+({38:"c214bc00",216:"a9d36e8e",263:"84f2dca8",369:"844d960c",463:"6a41a1d3",502:"2676e6c1",516:"47393571",543:"b827070c",783:"d718eb78",984:"23e65601",1001:"8b12cd00",1236:"70ef7226",1536:"885050db",2729:"217a1d82",2967:"2f44b910",3119:"ffafc25c",3141:"ffe39c7e",3290:"b8d83163",3351:"8f0894d7",3594:"a4861fb2",3820:"99e88449",3880:"c56a45db",3931:"d4d87a57",3990:"5d8a6e6c",4108:"d1bdd0fa",4485:"fa2dcbb0",4491:"4b6f3bbc",4510:"3c8991b9",4682:"2353df64",4717:"90469ff1",5094:"5218576a",5182:"e0c1e0d6",5319:"2fc65e44",5500:"c579011b",5546:"b626a9e3",6103:"8608173c",6210:"026f8a43",6296:"ce40746e",6795:"948cf876",6820:"c8a62906",6858:"133717db",7030:"95612694",7904:"0ea959d4",8107:"43db20c7",8493:"14ab011f",8616:"8a17d48d",8978:"92c0dc56",9145:"bda46832",9403:"b57d251e",9553:"033247b8",9844:"d595b519",10021:"c5432ea2",10080:"67183845",10444:"04a01ee2",10467:"1842ac24",10746:"56db29c6",10991:"2b2dd65a",11368:"8bc9ca9f",12002:"2e455d4b",12550:"c32240a8",12775:"c5e85f34",13129:"f3ce9685",13216:"40419be1",13451:"ab6518b5",13657:"6163dd53",13658:"2a802254",13713:"f9e765e6",13739:"071cfc94",13815:"fc587ea2",13989:"210762f3",14122:"04409633",14125:"e1527d61",14256:"917bc286",14634:"2db49e7b",15099:"6900e02e",15219:"4e299279",15359:"a473e6f5",15611:"c86840fe",15618:"7b8bf682",15804:"b54870c8",15892:"acdb258b",15897:"6e27b9d3",15906:"c1dd4621",15910:"4ca68b77",16165:"a55a9638",16676:"fc635dfc",16994:"93c7a379",17474:"b63241ae",17865:"c51cfce0",18095:"4a0590b1",18312:"5ac5eb1a",18600:"3876a1f1",18660:"6c48ccd2",18735:"7b44d16a",19006:"48d86b75",19072:"d64e42fb",19210:"e8900d59",19253:"13912f36",19291:"2d5ce48b",19619:"16b274ba",19782:"da5782cf",20886:"0211cf38",20923:"a400da89",21119:"0d2ec03f",21180:"ec059a4c",21209:"45b1d930",21324:"ee8ff1b5",21465:"51780fa8",21696:"3ab13cbf",22306:"67321f9e",22384:"c2268704",23144:"39454b3e",23240:"508e1e6a",23801:"7184e647",24566:"8bbe97eb",24586:"71f9d182",24751:"ce250987",24981:"74e36a4a",25227:"0dbc99ef",25525:"5e240566",25774:"f55cc0eb",25924:"fcbfe510",26158:"4831a431",26322:"d9fd7a7b",26372:"78a076dd",27010:"fa675db7",27174:"490c027b",27623:"05f401a8",27804:"ca3121dd",27918:"17896441",28010:"9b6c2d7b",28140:"7d5e3f2d",28732:"feb17923",28781:"29b20609",28900:"19eb7cef",28942:"6e2c89bf",28986:"fe36a4c7",29090:"466b77a0",29094:"c9a58d90",29135:"a96c1726",29271:"542b7d94",29470:"bf7d4bb0",29514:"1be78505",29654:"d17fc0cd",29803:"d1521ce5",29863:"f247b6fb",29933:"adc6f65e",30287:"c5540c98",30708:"29e919b4",30836:"0480b142",30975:"09ff2bba",31055:"743d2187",31216:"9c97aaef",31281:"7a901e9c",31668:"9a1f6492",31709:"f084b933",31759:"c9347341",32001:"6e3bb826",32051:"3acf0bda",32121:"2ed841b9",32198:"5179c3af",32305:"be394150",32409:"f107d3a3",32419:"b1853459",32599:"1f3e1758",32795:"f3d2149d",32894:"527790ee",33144:"22be61ad",33220:"0f0e6e72",33284:"72c515c0",33664:"00b945b6",33817:"0e9d4fd1",34394:"4993dcab",34494:"70eb7a71",34618:"feb5481f",34636:"5c1100ee",35001:"cbcd08eb",35172:"bb76a33d",35767:"b054b766",35798:"0fa8dfff",35849:"0f268954",35899:"37d50100",36104:"c999610f",36160:"16f90495",36599:"51eb9373",36770:"2061077e",36883:"db469a0a",37594:"146bbd18",37798:"496b07f8",37832:"cc22ecd4",38042:"ad8c84b0",38229:"7d3cadaf",38452:"e770214c",38591:"b51004e5",38751:"81026232",38781:"4c833bdc",38994:"bbe54ce8",39367:"4d29df01",39473:"33df698c",39660:"38746f92",39899:"d02b55c0",40176:"dab97983",40277:"e8d7a6d5",40398:"79fe45c9",40400:"b82dd0c5",40422:"769f7a44",40603:"f29ce45c",40659:"3de68b17",41096:"2ba08e95",41689:"77d35b39",42395:"e4d5e7b2",42606:"d4d4ccb3",42621:"2ceb8b1e",42624:"a258c9c2",42864:"8e010f80",43004:"a921adb8",43092:"b9221b05",43413:"9de97cf1",44109:"071b3461",44251:"c7df9e25",44942:"ddcf53d3",45445:"fedbe992",45713:"b029dc53",45753:"428dca98",45800:"aca0d75b",45801:"ac540a19",45802:"c367e46e",45943:"8ae0ca8b",45956:"75c173bc",46051:"14502dfa",46374:"9c461793",46514:"b7428429",46938:"83bceba8",47012:"f91a2579",47195:"a5e34c04",47260:"baf46722",47440:"b772b083",47891:"4fb110b7",47897:"f53d86c0",48344:"b6b0741b",48604:"0d247f98",48649:"f22b4b67",49039:"a13e5092",49611:"ec9bc115",49712:"512d8191",49755:"26716c91",49980:"9ed4e77f",49996:"919d73cf",50380:"6d8fec71",50401:"40aef452",50439:"8fccb5d2",50531:"181b6ec5",50722:"a2e3ec27",51127:"89da1492",51308:"746574b6",51450:"da4a9c2c",51711:"09be286f",51752:"fcd223e9",51849:"b9537d6a",51941:"9f4236b1",51948:"1c414f08",52041:"2a3d2d7f",52402:"f6136fc9",52833:"e2c93148",53116:"5d19e8c4",53640:"81fda92d",53831:"153eaba1",54123:"44d013a6",54153:"e418d32c",54463:"5b92b78e",54603:"1c362ccd",54782:"030c705f",54903:"8fb64a3d",55080:"e01469b8",55357:"c34cabf7",55557:"d2709487",55580:"6562b3cf",55868:"04a72ad1",55961:"3f3e03f1",56062:"bb9522fd",56344:"2b0e3906",56599:"c3f8e1c1",56881:"da55cb63",57254:"1c4f7bd7",57392:"8d924e0c",57422:"ddb791a8",57714:"35edfe5d",57829:"f8c8297c",58018:"039f99b9",58050:"af80e275",58159:"18db65fe",58220:"c9d90e52",58264:"51385bb4",58538:"4362a74c",58668:"686c40de",59005:"2ea27eca",59104:"ba4c506e",59138:"472f2b83",59248:"2fbfd176",59735:"4ba7e5a3",59840:"e3d564bd",60397:"34d0bf72",60407:"9a10b65c",60409:"709dd333",60622:"ef4cfc44",61026:"4fd7a5a5",61060:"bd96f483",61064:"8f41413c",61109:"dff106dc",61213:"3a064d4b",61338:"40249fd6",61422:"5dde2d34",61748:"d65a1863",61837:"8b1d6a66",61996:"dd9b495e",62155:"983a622a",62349:"d958c933",62580:"a6eb5934",62693:"3dbdd64e",62698:"d6b6deeb",63060:"80a4c802",63200:"7b2c6fa3",63227:"f5c3f7fb",63718:"3c38ea88",63877:"12e2b9b2",64047:"96c6e6da",64195:"c4f5d8e4",64240:"8b054d02",64264:"53d7406e",64429:"7d3f0232",64550:"bfd5220d",64555:"9cb18637",64634:"ce7b6de3",64763:"f036d650",65093:"aaad1650",65316:"7319d791",65569:"14854f7d",65575:"c03e4c45",65727:"9aadb410",65857:"5820f33f",66e3:"b967029f",66091:"765b73a7",66164:"9bf7be33",66183:"1553f58d",66347:"b4c938b6",66434:"81b6c359",66647:"f6fb0b44",66740:"66437b23",66979:"f4d11ede",67638:"b96f98be",67715:"55cca2cf",67780:"dbd82b5f",67883:"514186ba",67911:"97d883cd",68073:"58ba7d15",68306:"73e63d93",68472:"68fdbacf",68494:"e4a036e3",68505:"5903d9fe",68592:"common",69012:"0cf91a3d",69312:"966f33bd",69619:"a6cdc712",70051:"6475991a",70075:"d14c5b8b",70108:"6b66a434",70168:"7861fba0",70559:"cef840d9",70573:"c0035755",70761:"075bc5a3",70869:"9aee58cf",70960:"68923f8d",71273:"f42c9df1",71341:"89633389",71426:"dbbfd588",71770:"e0e0e5ec",71866:"628a0d36",71921:"f1e79774",72087:"eb2850a7",72221:"453e2297",72443:"99444684",72616:"7ffa0f98",72633:"d5510390",72748:"39658c48",72784:"437cf31d",72831:"e3f9abb2",73124:"d3a70d90",73150:"8da24fa5",73802:"3fb61c86",73832:"a144fa4f",73855:"265871a5",74302:"94e62ed7",74500:"f39c17a2",74627:"593ce03a",74643:"8ed0440b",75105:"d282fa21",75323:"b9312de0",75448:"ad7d9492",75694:"35a4d7a3",75778:"e0147a01",75809:"3edbd53d",75826:"49491008",75951:"62f57a8e",76295:"24eb123e",76458:"dbe24b2f",76774:"7dea7f5d",76840:"45727c44",76845:"8a62b5be",76983:"990fd983",77085:"9e95a131",77619:"af253e28",77798:"3f726e69",77904:"2a436572",77932:"2b8c5cd6",78112:"d1cc5cb2",78494:"484ef123",78837:"a8d723a6",79004:"c5db6f92",79233:"2ec9f803",79343:"6849bed7",79640:"bce5f2c2",79733:"6202ac8e",79815:"003507fd",79845:"83d1438d",79910:"bea3e1bc",80053:"935f2afb",81010:"84a9efaa",81381:"b1c20486",81629:"28c7acfc",81649:"6a5168b5",82002:"42b3845c",82072:"b248382e",82148:"a34c6988",82361:"ad0364aa",82535:"58916ddc",82787:"0f219439",83035:"0ca018de",83044:"5eb1d625",83184:"6d4aade0",83438:"160d2766",83816:"94c1ad37",83889:"2b11e6a2",84128:"a09c2993",84414:"79a77d53",84553:"58529492",84628:"e932408d",84982:"354a979d",85066:"348dcc60",85485:"704e19f0",85487:"1261ed3e",85628:"4c37424b",85635:"ca88de3b",85865:"e833faab",86027:"45eef51c",86042:"fae5e01b",86051:"86d7c441",86225:"203065fe",87054:"a78e484f",87114:"fcb5f29f",87264:"8f85b06a",87664:"0f3d9ed8",87746:"40dd01d7",87828:"f691884e",87831:"5d424605",87835:"4c6ba17a",88217:"35e8777e",88358:"074c5a9e",88441:"f6a3fab6",88540:"5fb8ca95",88552:"662bd64a",88602:"484ead6c",88758:"1859b273",88977:"42f4c5cc",89042:"f00d2ffa",89124:"fb79a9e5",89650:"4236a113",89715:"00c2b2a8",89996:"34dbcb71",90107:"828ccb3b",90216:"b70fab52",90218:"093042b1",90743:"fc7375fe",90994:"e3f32d12",91209:"689842b9",91373:"eb1aed0d",91539:"682cb337",91628:"250d73b2",91843:"db7ae0a9",91976:"adc2ae4e",91986:"efc88f4e",92437:"f8d3dbc8",92458:"cd24b208",92701:"ad588422",92927:"f4e7d353",92998:"fcba6891",93069:"7c6b0a32",93145:"99fad677",93209:"f6091eb4",93386:"600972a3",93466:"8cf6226e",93529:"1501273f",93665:"5e12a3a6",93868:"26a6d5df",93941:"478b05e2",94139:"79b9f7ae",94163:"f11c3e27",94183:"cd617144",94211:"667c2780",94322:"22fb5890",95111:"aa402b17",95731:"70ecfbb4",95926:"13684d46",95985:"145e8536",96027:"fbfb7b9b",96209:"31d3307a",96541:"5b4bd708",96914:"d743e462",97646:"f6e2ded6",97686:"f3dd1f7b",97920:"1a4e3797",98071:"e1c68ef1",98248:"a96e9a0c",98746:"8f656afc",98785:"618023cd",99056:"2ebf6bd3",99508:"5f2c2d9f",99769:"f8aa15ec",99796:"18ad0f10",99878:"c6b877b9",99980:"905708d8"}[e]||e)+"."+{38:"b2635bcc",216:"14a55eba",263:"d5a7434d",369:"e61846b9",463:"e2402170",502:"5091936d",516:"35763f65",543:"cf17390e",783:"6da88ff9",984:"d75b1362",1001:"70627e4a",1236:"f07bba98",1536:"1f8fd623",2729:"62828cd9",2967:"cd4b6c4e",3119:"4a40c5ce",3141:"a8f39186",3290:"25122efb",3351:"ed7bc8f6",3594:"1446a05d",3820:"bc73e4ad",3880:"3446b814",3931:"1652378a",3990:"86ca6092",4108:"0297eae3",4485:"558eae44",4491:"c2ef589e",4510:"187d0271",4682:"91f089aa",4717:"cf1e9b31",4972:"9e3bdb71",5094:"c54583ff",5182:"955969c0",5319:"5e75731b",5500:"d2241cb0",5546:"6c005d8d",6103:"3c41f295",6210:"9d18cecb",6296:"83b2aee2",6795:"7aca5b57",6820:"d497a2e5",6858:"c7cc0a96",7030:"daa00586",7904:"27ce7428",8107:"662b6ab0",8493:"f4ddb845",8616:"25e43a1e",8978:"ecea5277",9145:"a873dad1",9403:"1ef4ac20",9553:"a2d7a6c5",9844:"f6c0b45e",10021:"34c38a93",10080:"5f5ce90c",10444:"86a2ac54",10467:"1e8b840b",10696:"6913c047",10746:"aa89a180",10991:"f7d4ba0c",11368:"e3268b1f",12002:"092510c1",12550:"d7b7c5a7",12775:"900bf0c0",13129:"25610ab1",13216:"6fac329a",13451:"07f14092",13657:"70e21339",13658:"3bb41d31",13713:"116a9a27",13739:"eaa4fb2e",13815:"a3a3b317",13989:"c14047dc",14122:"42ea3a1b",14125:"7131da35",14256:"7c0a64b3",14634:"11e00f91",15099:"7e268bca",15219:"6099f30d",15359:"c8b65575",15611:"ee9f4257",15618:"f85fa516",15649:"51768373",15804:"2a717478",15892:"5865000f",15897:"8eb6e1a1",15906:"635e2bf9",15910:"06229dfd",16165:"c549b13b",16676:"7ed80efe",16994:"6d59877a",17474:"53ab6250",17865:"7fd228c2",18095:"ad3b013f",18312:"e30853e8",18600:"40bd604c",18660:"2b525fdc",18735:"f5b3efd4",18894:"1e0de85f",19006:"f2bf69a7",19072:"fc376622",19210:"4b50ac43",19253:"bd69211f",19291:"8116d2dc",19619:"f068cd3c",19782:"9844cf7c",20886:"1c3ad06f",20923:"de8a1485",21119:"3c7042c7",21180:"49867a85",21209:"37523d47",21324:"5307eb4e",21465:"f66670c1",21696:"41da7652",22146:"64e2b6ba",22306:"fd924714",22384:"9e2f920e",23144:"6f6ef7df",23240:"04a74a04",23801:"e6ab185a",24535:"7d640f97",24566:"25852570",24586:"64912b1c",24751:"50fb9e4b",24981:"805fd090",25227:"adae8699",25525:"92789d0c",25670:"aa608768",25774:"3f28c3a7",25924:"8df32b24",26158:"7acd0cf9",26322:"f2e84b63",26345:"ef8ba99e",26372:"7fab9551",27010:"062cfc57",27174:"d7760474",27623:"6e6211ee",27804:"777c32de",27918:"3bc85d93",28010:"0a6f3e9e",28140:"aa29a3d3",28732:"1a78ca71",28781:"1c41ef1b",28900:"936e4789",28942:"c96a9f11",28986:"90a95817",29090:"58073b71",29094:"3334a310",29135:"e42644d1",29271:"6441706a",29470:"c5204677",29514:"36770ffd",29654:"699b4fe3",29803:"cf7706df",29863:"5824798f",29933:"fc5a0a8e",30287:"12d01fe7",30708:"115a8aca",30836:"dde746a4",30975:"404effef",31055:"086e3b39",31216:"d794b5ca",31281:"aaeba376",31523:"5e5991ea",31668:"f70909ba",31709:"a97adbce",31759:"5809e5e1",32001:"7d3a6799",32051:"b587b805",32121:"a3a8adfa",32198:"bec72262",32305:"2d759ac3",32409:"42fd7ae0",32419:"bfe0985b",32599:"1a8cf2a7",32795:"e5c71ca4",32894:"3bc42fec",33144:"0b8cfe3d",33220:"2962e0c7",33284:"9ea1683d",33664:"b9b18439",33817:"d80397ee",34307:"d0ab9e01",34394:"36b4ecb9",34494:"a5a7b9ca",34618:"a834a7c2",34636:"fb783e98",35001:"051950d7",35172:"c72dc7d1",35767:"0876ed47",35798:"b531245c",35849:"67a4e661",35899:"2a22af31",36104:"57065bc9",36160:"95539149",36599:"68cb3606",36770:"c1d86708",36883:"c43cf4c5",37594:"a65633d7",37798:"eb32075c",37832:"69f98bef",38042:"e32bb085",38229:"8ce823d1",38452:"7b50cbb5",38591:"2231909c",38751:"e014fc35",38781:"0a47fb06",38994:"29241f71",39186:"beb526ea",39367:"079586ae",39473:"0a4975f4",39660:"fe01ef43",39899:"eb67c7cd",40176:"7309e620",40277:"59377c6c",40398:"c9fc085f",40400:"ef628944",40422:"63b2c1e2",40603:"ea484d21",40659:"35f4c25b",41096:"b64b89ba",41689:"c57280ae",42070:"aaa5dec1",42395:"46b1873d",42494:"594ce7cb",42606:"5962bdc1",42621:"e3bdf192",42624:"13e8c36b",42864:"0cf9c538",43004:"cf62fb5a",43092:"5e305f23",43398:"a527d9e4",43413:"3c649c2f",44109:"592d08f2",44251:"3515fa6e",44942:"c37170e9",45445:"4220f1f7",45713:"f2f08a30",45753:"dd2d69e7",45800:"ed28e9b3",45801:"aa984602",45802:"20c5e9a0",45943:"100760e5",45956:"edaa40df",46051:"1e8f4f63",46374:"45f7ae9a",46514:"a8911fc6",46938:"e66a7cab",46945:"f70129bd",47012:"8a9b806c",47195:"293d9b1d",47260:"d418f744",47440:"b5a4b0fb",47891:"a6db4d75",47897:"c21aecd7",48344:"1f2a036a",48604:"cc072766",48649:"3677df10",49039:"9ac3d6ec",49611:"753c8d5a",49712:"c214079c",49755:"3b1ad2d9",49980:"f95369e7",49996:"85a038ef",50380:"fd648f5a",50401:"36a0aaae",50439:"82bcba9e",50531:"502d7aa6",50722:"779cf8fe",51127:"4ea23f97",51308:"b3cf611f",51450:"269b09f5",51711:"1d015114",51752:"05f330ac",51849:"e4ef9fcf",51915:"38541819",51941:"01d2e734",51948:"e7c733d2",52041:"2a30921c",52402:"ad1240fe",52833:"60442a7d",53116:"72b3e235",53640:"3ad85d02",53831:"6c2a4b4f",53868:"5509ba78",54038:"cc51a94a",54123:"51daedaf",54153:"6faef210",54463:"3bb0fd95",54603:"35398c7c",54782:"23dabfd0",54903:"240c5a2d",54954:"076e95f2",55080:"9a6a5cfa",55357:"2e87e00a",55557:"d4c0d9af",55580:"266a67f0",55868:"b82eab7a",55961:"59703ff4",56062:"6e280866",56344:"e993c4ec",56599:"4ddcbaf1",56881:"cda38dec",57254:"9328f383",57392:"3cf8ac74",57422:"3514cf78",57714:"3a8468a1",57829:"167036dc",58018:"9a9cd6ac",58050:"6b9bcc01",58159:"99c1b368",58220:"c66943e3",58264:"42b44f8e",58538:"d12f66ee",58668:"8b19bacc",59005:"fbcb5763",59104:"d33f1f6a",59138:"b4ced459",59248:"44c17486",59735:"d12cdd6e",59840:"494d8e51",60397:"21c241b0",60407:"122bb679",60409:"e3093902",60622:"bfdee689",61026:"21f148f1",61060:"4ab9c4ee",61064:"3ada3929",61109:"9ffcdffa",61213:"7d112706",61338:"168ad9d3",61422:"43dc2fb2",61426:"64640048",61748:"fb2afba9",61837:"c21a08f8",61996:"2da79123",62155:"1be46354",62349:"8ae57ca1",62580:"c2914c73",62693:"5bac9361",62698:"bbb4d4c2",63060:"0eaee253",63200:"5afe6abe",63227:"57e466a8",63718:"535ac941",63877:"05f20c4a",64047:"9ef2b0fd",64195:"3ad63c78",64240:"76746b26",64264:"c5c22b9e",64429:"7ffbacf3",64550:"20dd1de3",64555:"38a6725b",64634:"f35197e0",64763:"982a6ab6",65093:"e40fa264",65316:"27b079bd",65569:"777f975a",65575:"75d6cd70",65727:"26a0c09e",65857:"99a2cb61",66e3:"bb5b94f1",66091:"7f50313f",66102:"cf9f339d",66164:"e3b43a92",66183:"5534ec95",66347:"75e1fc22",66434:"a917e4a8",66647:"607f4d5e",66740:"0b6e1e76",66979:"a10b7451",67638:"752fc983",67715:"14cc52a2",67780:"3f2ed0a3",67883:"48e4d503",67911:"8d26fa76",68073:"2868f5f5",68306:"3a4bb161",68472:"9ff9a1d7",68494:"70c83c7a",68505:"7a8af038",68592:"fbdee77f",69012:"7b1db030",69312:"2dfa500c",69619:"a392b2d8",70051:"52915032",70075:"dd3482e5",70108:"2ae8740d",70168:"c87a8d24",70299:"bcc91462",70559:"c0cdc20c",70573:"7f9d7a4a",70761:"c356d643",70869:"81e26f23",70960:"da1e0949",71273:"e0af0a98",71341:"fb5d0144",71426:"adb002f1",71770:"c21f24b5",71866:"f84ac9cf",71921:"f9e2a60c",72087:"d3c0f641",72221:"b1fa9363",72443:"04066d4b",72616:"74d64306",72633:"22db9f45",72748:"1cbac600",72784:"3d134d12",72831:"da9a2497",73124:"a6fe2206",73150:"763db0e6",73802:"a07d6afe",73832:"96d419be",73855:"9859748f",74302:"fd6576a6",74500:"e138e795",74627:"2f6594c7",74643:"2a2e6567",75105:"f81d9b87",75323:"9f30e88b",75448:"ab1d7405",75694:"de36cf5c",75778:"fea6e1d8",75809:"0aeb568c",75826:"2b838d7b",75951:"d1be8d88",76295:"e11a1c60",76458:"3b7f2d64",76774:"d72864cc",76840:"d664d574",76845:"bb6b97d3",76983:"ba3c220d",77085:"5cb04cfa",77480:"c0bf5a14",77583:"c4b2cdba",77619:"d9d0712a",77798:"c0311b00",77904:"e3d2a6a4",77932:"42c59fb9",78112:"43ee9756",78494:"5aaa169e",78837:"081e57c2",79004:"adf72fdc",79233:"ef7cf084",79343:"7c9946b8",79640:"b769bf94",79733:"30de0c3c",79815:"f97dc900",79845:"1dda17bd",79910:"ab751cf0",80053:"7242f543",81010:"12e0386d",81381:"f1c6b650",81629:"5f1809df",81649:"151c2ebc",82002:"71041581",82072:"c0e4f358",82148:"be8c3f85",82361:"697bc030",82535:"1c6669a9",82787:"f9ea0df9",83035:"57672c53",83044:"74b13e1d",83145:"dfc6852e",83184:"12b42e23",83438:"af2f9657",83816:"46d6063f",83889:"f7103a27",84128:"11e39a3f",84414:"22935e5a",84484:"b63b0d7d",84553:"efa25d63",84628:"228fdbdc",84982:"8488054b",85066:"36b5c2d8",85485:"446b4a5a",85487:"58c3c36d",85628:"5644cb79",85635:"731e9d8c",85865:"0e19f6ff",86027:"2a1aff0f",86042:"cc954af9",86051:"1613163c",86225:"68122dc7",87054:"0f8ed7c1",87114:"0c1688a3",87264:"140bef78",87664:"19af5e0b",87746:"685a052b",87828:"78fdd5e9",87831:"d66f53f1",87835:"84d252f5",88217:"6c60b9f5",88358:"afb0c344",88441:"1aa31fa4",88540:"33d1157c",88549:"f76427c0",88552:"a4f6a91b",88602:"67b8f943",88758:"763daeef",88977:"2c5da874",89042:"8fdc0f87",89124:"809f8f1f",89419:"85850878",89650:"4bf7022d",89715:"dffe6809",89996:"d284e7ef",90107:"55d38895",90216:"7819b2b7",90218:"9cc4af84",90743:"1e01a9e0",90894:"38287227",90994:"37d140e0",91209:"661d750a",91373:"d2455d85",91539:"e2ab1c02",91628:"a618b036",91843:"9800ee9b",91976:"561445bd",91986:"44a217e8",92262:"c5ac8f1f",92437:"c588b3bd",92458:"a6438534",92701:"3d01dd36",92927:"191c5291",92998:"7bee07bc",93069:"7131a195",93145:"13c49f5f",93209:"cdc6dd2b",93386:"34bc6e7c",93466:"1fc4233b",93529:"1f4363e1",93665:"7593310a",93868:"4683066a",93941:"97b4bd7b",94139:"6e802814",94163:"44797c3f",94183:"483d133f",94211:"f2252d57",94322:"f4b77131",95111:"1d79244f",95731:"2d96c0e8",95926:"4fb538e6",95940:"fc42ba15",95985:"83c33628",96027:"4e9e7bfe",96209:"99a6816d",96541:"745b564e",96914:"a566a108",97646:"15710857",97686:"a9eb6f36",97920:"45f6cca8",98071:"ac5eb1f1",98248:"87ac0d33",98746:"147c314a",98785:"acf6d590",99056:"38ff4741",99508:"61d91d57",99769:"825d8952",99796:"3822c739",99878:"bbcee2f0",99980:"d869c6c5"}[e]+".js",r.miniCssF=e=>{},r.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),r.o=(e,b)=>Object.prototype.hasOwnProperty.call(e,b),c={},a="grants:",r.l=(e,b,d,f)=>{if(c[e])c[e].push(b);else{var t,o;if(void 0!==d)for(var n=document.getElementsByTagName("script"),i=0;i{t.onerror=t.onload=null,clearTimeout(s);var a=c[e];if(delete c[e],t.parentNode&&t.parentNode.removeChild(t),a&&a.forEach((e=>e(d))),b)return b(d)},s=setTimeout(l.bind(null,void 0,{type:"timeout",target:t}),12e4);t.onerror=l.bind(null,t.onerror),t.onload=l.bind(null,t.onload),o&&document.head.appendChild(t)}},r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.p="/",r.gca=function(e){return e={17896441:"27918",47393571:"516",49491008:"75826",58529492:"84553",67183845:"10080",81026232:"38751",89633389:"71341",95612694:"7030",99444684:"72443",c214bc00:"38",a9d36e8e:"216","84f2dca8":"263","844d960c":"369","6a41a1d3":"463","2676e6c1":"502",b827070c:"543",d718eb78:"783","23e65601":"984","8b12cd00":"1001","70ef7226":"1236","885050db":"1536","217a1d82":"2729","2f44b910":"2967",ffafc25c:"3119",ffe39c7e:"3141",b8d83163:"3290","8f0894d7":"3351",a4861fb2:"3594","99e88449":"3820",c56a45db:"3880",d4d87a57:"3931","5d8a6e6c":"3990",d1bdd0fa:"4108",fa2dcbb0:"4485","4b6f3bbc":"4491","3c8991b9":"4510","2353df64":"4682","90469ff1":"4717","5218576a":"5094",e0c1e0d6:"5182","2fc65e44":"5319",c579011b:"5500",b626a9e3:"5546","8608173c":"6103","026f8a43":"6210",ce40746e:"6296","948cf876":"6795",c8a62906:"6820","133717db":"6858","0ea959d4":"7904","43db20c7":"8107","14ab011f":"8493","8a17d48d":"8616","92c0dc56":"8978",bda46832:"9145",b57d251e:"9403","033247b8":"9553",d595b519:"9844",c5432ea2:"10021","04a01ee2":"10444","1842ac24":"10467","56db29c6":"10746","2b2dd65a":"10991","8bc9ca9f":"11368","2e455d4b":"12002",c32240a8:"12550",c5e85f34:"12775",f3ce9685:"13129","40419be1":"13216",ab6518b5:"13451","6163dd53":"13657","2a802254":"13658",f9e765e6:"13713","071cfc94":"13739",fc587ea2:"13815","210762f3":"13989","04409633":"14122",e1527d61:"14125","917bc286":"14256","2db49e7b":"14634","6900e02e":"15099","4e299279":"15219",a473e6f5:"15359",c86840fe:"15611","7b8bf682":"15618",b54870c8:"15804",acdb258b:"15892","6e27b9d3":"15897",c1dd4621:"15906","4ca68b77":"15910",a55a9638:"16165",fc635dfc:"16676","93c7a379":"16994",b63241ae:"17474",c51cfce0:"17865","4a0590b1":"18095","5ac5eb1a":"18312","3876a1f1":"18600","6c48ccd2":"18660","7b44d16a":"18735","48d86b75":"19006",d64e42fb:"19072",e8900d59:"19210","13912f36":"19253","2d5ce48b":"19291","16b274ba":"19619",da5782cf:"19782","0211cf38":"20886",a400da89:"20923","0d2ec03f":"21119",ec059a4c:"21180","45b1d930":"21209",ee8ff1b5:"21324","51780fa8":"21465","3ab13cbf":"21696","67321f9e":"22306",c2268704:"22384","39454b3e":"23144","508e1e6a":"23240","7184e647":"23801","8bbe97eb":"24566","71f9d182":"24586",ce250987:"24751","74e36a4a":"24981","0dbc99ef":"25227","5e240566":"25525",f55cc0eb:"25774",fcbfe510:"25924","4831a431":"26158",d9fd7a7b:"26322","78a076dd":"26372",fa675db7:"27010","490c027b":"27174","05f401a8":"27623",ca3121dd:"27804","9b6c2d7b":"28010","7d5e3f2d":"28140",feb17923:"28732","29b20609":"28781","19eb7cef":"28900","6e2c89bf":"28942",fe36a4c7:"28986","466b77a0":"29090",c9a58d90:"29094",a96c1726:"29135","542b7d94":"29271",bf7d4bb0:"29470","1be78505":"29514",d17fc0cd:"29654",d1521ce5:"29803",f247b6fb:"29863",adc6f65e:"29933",c5540c98:"30287","29e919b4":"30708","0480b142":"30836","09ff2bba":"30975","743d2187":"31055","9c97aaef":"31216","7a901e9c":"31281","9a1f6492":"31668",f084b933:"31709",c9347341:"31759","6e3bb826":"32001","3acf0bda":"32051","2ed841b9":"32121","5179c3af":"32198",be394150:"32305",f107d3a3:"32409",b1853459:"32419","1f3e1758":"32599",f3d2149d:"32795","527790ee":"32894","22be61ad":"33144","0f0e6e72":"33220","72c515c0":"33284","00b945b6":"33664","0e9d4fd1":"33817","4993dcab":"34394","70eb7a71":"34494",feb5481f:"34618","5c1100ee":"34636",cbcd08eb:"35001",bb76a33d:"35172",b054b766:"35767","0fa8dfff":"35798","0f268954":"35849","37d50100":"35899",c999610f:"36104","16f90495":"36160","51eb9373":"36599","2061077e":"36770",db469a0a:"36883","146bbd18":"37594","496b07f8":"37798",cc22ecd4:"37832",ad8c84b0:"38042","7d3cadaf":"38229",e770214c:"38452",b51004e5:"38591","4c833bdc":"38781",bbe54ce8:"38994","4d29df01":"39367","33df698c":"39473","38746f92":"39660",d02b55c0:"39899",dab97983:"40176",e8d7a6d5:"40277","79fe45c9":"40398",b82dd0c5:"40400","769f7a44":"40422",f29ce45c:"40603","3de68b17":"40659","2ba08e95":"41096","77d35b39":"41689",e4d5e7b2:"42395",d4d4ccb3:"42606","2ceb8b1e":"42621",a258c9c2:"42624","8e010f80":"42864",a921adb8:"43004",b9221b05:"43092","9de97cf1":"43413","071b3461":"44109",c7df9e25:"44251",ddcf53d3:"44942",fedbe992:"45445",b029dc53:"45713","428dca98":"45753",aca0d75b:"45800",ac540a19:"45801",c367e46e:"45802","8ae0ca8b":"45943","75c173bc":"45956","14502dfa":"46051","9c461793":"46374",b7428429:"46514","83bceba8":"46938",f91a2579:"47012",a5e34c04:"47195",baf46722:"47260",b772b083:"47440","4fb110b7":"47891",f53d86c0:"47897",b6b0741b:"48344","0d247f98":"48604",f22b4b67:"48649",a13e5092:"49039",ec9bc115:"49611","512d8191":"49712","26716c91":"49755","9ed4e77f":"49980","919d73cf":"49996","6d8fec71":"50380","40aef452":"50401","8fccb5d2":"50439","181b6ec5":"50531",a2e3ec27:"50722","89da1492":"51127","746574b6":"51308",da4a9c2c:"51450","09be286f":"51711",fcd223e9:"51752",b9537d6a:"51849","9f4236b1":"51941","1c414f08":"51948","2a3d2d7f":"52041",f6136fc9:"52402",e2c93148:"52833","5d19e8c4":"53116","81fda92d":"53640","153eaba1":"53831","44d013a6":"54123",e418d32c:"54153","5b92b78e":"54463","1c362ccd":"54603","030c705f":"54782","8fb64a3d":"54903",e01469b8:"55080",c34cabf7:"55357",d2709487:"55557","6562b3cf":"55580","04a72ad1":"55868","3f3e03f1":"55961",bb9522fd:"56062","2b0e3906":"56344",c3f8e1c1:"56599",da55cb63:"56881","1c4f7bd7":"57254","8d924e0c":"57392",ddb791a8:"57422","35edfe5d":"57714",f8c8297c:"57829","039f99b9":"58018",af80e275:"58050","18db65fe":"58159",c9d90e52:"58220","51385bb4":"58264","4362a74c":"58538","686c40de":"58668","2ea27eca":"59005",ba4c506e:"59104","472f2b83":"59138","2fbfd176":"59248","4ba7e5a3":"59735",e3d564bd:"59840","34d0bf72":"60397","9a10b65c":"60407","709dd333":"60409",ef4cfc44:"60622","4fd7a5a5":"61026",bd96f483:"61060","8f41413c":"61064",dff106dc:"61109","3a064d4b":"61213","40249fd6":"61338","5dde2d34":"61422",d65a1863:"61748","8b1d6a66":"61837",dd9b495e:"61996","983a622a":"62155",d958c933:"62349",a6eb5934:"62580","3dbdd64e":"62693",d6b6deeb:"62698","80a4c802":"63060","7b2c6fa3":"63200",f5c3f7fb:"63227","3c38ea88":"63718","12e2b9b2":"63877","96c6e6da":"64047",c4f5d8e4:"64195","8b054d02":"64240","53d7406e":"64264","7d3f0232":"64429",bfd5220d:"64550","9cb18637":"64555",ce7b6de3:"64634",f036d650:"64763",aaad1650:"65093","7319d791":"65316","14854f7d":"65569",c03e4c45:"65575","9aadb410":"65727","5820f33f":"65857",b967029f:"66000","765b73a7":"66091","9bf7be33":"66164","1553f58d":"66183",b4c938b6:"66347","81b6c359":"66434",f6fb0b44:"66647","66437b23":"66740",f4d11ede:"66979",b96f98be:"67638","55cca2cf":"67715",dbd82b5f:"67780","514186ba":"67883","97d883cd":"67911","58ba7d15":"68073","73e63d93":"68306","68fdbacf":"68472",e4a036e3:"68494","5903d9fe":"68505",common:"68592","0cf91a3d":"69012","966f33bd":"69312",a6cdc712:"69619","6475991a":"70051",d14c5b8b:"70075","6b66a434":"70108","7861fba0":"70168",cef840d9:"70559",c0035755:"70573","075bc5a3":"70761","9aee58cf":"70869","68923f8d":"70960",f42c9df1:"71273",dbbfd588:"71426",e0e0e5ec:"71770","628a0d36":"71866",f1e79774:"71921",eb2850a7:"72087","453e2297":"72221","7ffa0f98":"72616",d5510390:"72633","39658c48":"72748","437cf31d":"72784",e3f9abb2:"72831",d3a70d90:"73124","8da24fa5":"73150","3fb61c86":"73802",a144fa4f:"73832","265871a5":"73855","94e62ed7":"74302",f39c17a2:"74500","593ce03a":"74627","8ed0440b":"74643",d282fa21:"75105",b9312de0:"75323",ad7d9492:"75448","35a4d7a3":"75694",e0147a01:"75778","3edbd53d":"75809","62f57a8e":"75951","24eb123e":"76295",dbe24b2f:"76458","7dea7f5d":"76774","45727c44":"76840","8a62b5be":"76845","990fd983":"76983","9e95a131":"77085",af253e28:"77619","3f726e69":"77798","2a436572":"77904","2b8c5cd6":"77932",d1cc5cb2:"78112","484ef123":"78494",a8d723a6:"78837",c5db6f92:"79004","2ec9f803":"79233","6849bed7":"79343",bce5f2c2:"79640","6202ac8e":"79733","003507fd":"79815","83d1438d":"79845",bea3e1bc:"79910","935f2afb":"80053","84a9efaa":"81010",b1c20486:"81381","28c7acfc":"81629","6a5168b5":"81649","42b3845c":"82002",b248382e:"82072",a34c6988:"82148",ad0364aa:"82361","58916ddc":"82535","0f219439":"82787","0ca018de":"83035","5eb1d625":"83044","6d4aade0":"83184","160d2766":"83438","94c1ad37":"83816","2b11e6a2":"83889",a09c2993:"84128","79a77d53":"84414",e932408d:"84628","354a979d":"84982","348dcc60":"85066","704e19f0":"85485","1261ed3e":"85487","4c37424b":"85628",ca88de3b:"85635",e833faab:"85865","45eef51c":"86027",fae5e01b:"86042","86d7c441":"86051","203065fe":"86225",a78e484f:"87054",fcb5f29f:"87114","8f85b06a":"87264","0f3d9ed8":"87664","40dd01d7":"87746",f691884e:"87828","5d424605":"87831","4c6ba17a":"87835","35e8777e":"88217","074c5a9e":"88358",f6a3fab6:"88441","5fb8ca95":"88540","662bd64a":"88552","484ead6c":"88602","1859b273":"88758","42f4c5cc":"88977",f00d2ffa:"89042",fb79a9e5:"89124","4236a113":"89650","00c2b2a8":"89715","34dbcb71":"89996","828ccb3b":"90107",b70fab52:"90216","093042b1":"90218",fc7375fe:"90743",e3f32d12:"90994","689842b9":"91209",eb1aed0d:"91373","682cb337":"91539","250d73b2":"91628",db7ae0a9:"91843",adc2ae4e:"91976",efc88f4e:"91986",f8d3dbc8:"92437",cd24b208:"92458",ad588422:"92701",f4e7d353:"92927",fcba6891:"92998","7c6b0a32":"93069","99fad677":"93145",f6091eb4:"93209","600972a3":"93386","8cf6226e":"93466","1501273f":"93529","5e12a3a6":"93665","26a6d5df":"93868","478b05e2":"93941","79b9f7ae":"94139",f11c3e27:"94163",cd617144:"94183","667c2780":"94211","22fb5890":"94322",aa402b17:"95111","70ecfbb4":"95731","13684d46":"95926","145e8536":"95985",fbfb7b9b:"96027","31d3307a":"96209","5b4bd708":"96541",d743e462:"96914",f6e2ded6:"97646",f3dd1f7b:"97686","1a4e3797":"97920",e1c68ef1:"98071",a96e9a0c:"98248","8f656afc":"98746","618023cd":"98785","2ebf6bd3":"99056","5f2c2d9f":"99508",f8aa15ec:"99769","18ad0f10":"99796",c6b877b9:"99878","905708d8":"99980"}[e]||e,r.p+r.u(e)},(()=>{var e={51303:0,40532:0};r.f.j=(b,d)=>{var c=r.o(e,b)?e[b]:void 0;if(0!==c)if(c)d.push(c[2]);else if(/^(40532|51303)$/.test(b))e[b]=0;else{var a=new Promise(((d,a)=>c=e[b]=[d,a]));d.push(c[2]=a);var f=r.p+r.u(b),t=new Error;r.l(f,(d=>{if(r.o(e,b)&&(0!==(c=e[b])&&(e[b]=void 0),c)){var a=d&&("load"===d.type?"missing":d.type),f=d&&d.target&&d.target.src;t.message="Loading chunk "+b+" failed.\n("+a+": "+f+")",t.name="ChunkLoadError",t.type=a,t.request=f,c[1](t)}}),"chunk-"+b,b)}},r.O.j=b=>0===e[b];var b=(b,d)=>{var c,a,f=d[0],t=d[1],o=d[2],n=0;if(f.some((b=>0!==e[b]))){for(c in t)r.o(t,c)&&(r.m[c]=t[c]);if(o)var i=o(r)}for(b&&b(d);n Project Ideas | Web3 Foundation Grants - +

    Project Ideas

    An overview of existing projects in the Web 3.0 Technology Stack along with broad project ideas we would potentially be interested in funding can be found here, as well as a list of previously accepted applications here.

    Requests For Proposals (RFPs) represent concrete ideas for projects that we would like to see implemented. Several teams may apply for the same RFP, so even if another team has already applied to implement a certain RFP, we invite you to do the same if you're interested.

    Finally, you don't need to start your own project in order to be eligible for a grant. Instead, some teams choose to port existing work to Substrate, where the pertinent licenses allow, or even to contribute to an existing open-source project. In the latter case, you should check in advance that the maintainers of the project are interested in your contribution, and the acceptance of the milestones will generally be tied to the inclusion of your work in said project. See the Maintenance Grants section for more info.

    If you have a good concept of the technical challenges that your idea entails and would like feedback/input before submitting it, you can send us an email and tell us about it.

    - + \ No newline at end of file diff --git a/docs/Introduction/intro.html b/docs/Introduction/intro.html index e7249420dce..13723d21122 100644 --- a/docs/Introduction/intro.html +++ b/docs/Introduction/intro.html @@ -4,13 +4,13 @@ Guidelines | Web3 Foundation Grants - +

    Guidelines

    Anyone is welcome to apply for a grant. Projects funded through our program are broad in scope, but our focus lies on projects with a strong technical focus that add value to the Polkadot ecosystem. Furthermore, you should be able to demonstrate a solid, long-term roadmap, be it through the project's significance to the community (such as for research-oriented projects) or an in-depth market analysis (for business-oriented projects).

    Generally, your project will have better chances to be accepted if:

    • it presents a well-researched or tested concept, for which ideally you are able to show some prior work;
    • you have tangible proof how and to what extent the project is a benefit to the Polkadot ecosystem and its users;
    • you can demonstrate that the project will be maintained after completion of the grant, be it through an obvious commitment to the technology from your side, additional funding sources, or an existing business model;
    • your team has proven experience with the relevant languages and technologies and/or a strong technical background. You will be asked to provide the GitHub profiles of your team members as part of your application, which we will examine for past activity and code quality. Naturally, you can also link to projects on other platforms;
    • your application is rich in technical details and well-defined;
    • you can present how your project stands out among competitors or implements technology that doesn't exist in the ecosystem yet.

    Additionally, it must fulfill the following requirements:

    • All code produced as part of a grant must be open-sourced, and it must also not rely on closed-source software for full functionality. We prefer Apache 2.0, but GPLv3, MIT, or Unlicense are also acceptable.
    • We do not award grants for projects that have been the object of a successful token sale.
    • Applications must not mention a specific token. Furthermore, the focus of the application should lie on the software that is being implemented/research being carried out as part of the grant and less on your project/venture/operation. For the purpose of the application and delivery, think about how others might also benefit from your work.
    • As a general rule, teams are asked to finish a grant before applying for another one.
    • Lastly, we do not fund projects that actively encourage gambling, illicit trade, money laundering, or criminal activities in general.

    In addition to the information provided on your application, note that your project will need to comply with our Guidelines for Milestone Deliverables. In particular, we require all projects to create documentation that explains how their project works. At a minimum, written documentation is required for funding. Tutorials or videos are also helpful for new users to understand how to use your product.

    Please also heed our Announcement Guidelines for grant-related communications.

    Finally, we take licensing and the right of all teams in and outside the ecosystem to be recognized for their work very seriously. Using others' work with no attribution or indication that this was not your own work as part of a milestone delivery will lead to immediate termination. Please reach out to us before submitting if you have any doubts on how to comply with a specific license and we'll be happy to help.

    We also try to enforce our code of conduct and, based on this, may block users.

    - + \ No newline at end of file diff --git a/docs/Introduction/levels.html b/docs/Introduction/levels.html index fe5eee9cebb..35158c86ac6 100644 --- a/docs/Introduction/levels.html +++ b/docs/Introduction/levels.html @@ -4,13 +4,13 @@ Grant Levels | Web3 Foundation Grants - +

    Grant Levels

    The W3F Grants Program offers different grant levels to help you best depending on your current stage.

    ๐Ÿฃ Level 1 (= InstaGrants)โ€‹

    • Target: Individuals & small teams
    • Amount: Up to $10,000
    • Requirements: 2 approvals
    • Benefits: Feedback during application process and evaluation, introduction to related teams/projects

    ๐Ÿค Level 2โ€‹

    ๐Ÿ“ Level 3โ€‹

    • Target: Companies/foundations with a proven track record
    • Amount: Unlimited
    • Requirements: 5 approvals (for >$100k: Web3 Foundation Council approval + Pitch call)
    • Benefits: All of the above + VC introductions
    - + \ No newline at end of file diff --git a/docs/Introduction/support.html b/docs/Introduction/support.html index 9f5d924163b..3133f2087ad 100644 --- a/docs/Introduction/support.html +++ b/docs/Introduction/support.html @@ -4,13 +4,13 @@ Support | Web3 Foundation Grants - +

    Support

    The scope of our Grants Programs consists of funding and feedback on delivered milestones. This means that we do not provide hands-on support as part of a grant, but if you face specific issues during development, we will do our best and try to direct you to the correct resources. If this sounds like something you would like however, you may also want to apply to Parity's Substrate Builders Program, which provides hands-on technical, ecosystem and strategical long-term support and access to extensive resources. You can find general documentation and more information on Substrate on the Substrate Developer Hub, and we encourage you to join the community in order to get help with specific issues or to stay up to date with the most recent developments.

    For questions about the grants program itself, see our FAQ.

    - + \ No newline at end of file diff --git a/docs/Introduction/team.html b/docs/Introduction/team.html index f06f799d138..04bdad8e1b1 100644 --- a/docs/Introduction/team.html +++ b/docs/Introduction/team.html @@ -4,13 +4,13 @@ Team | Web3 Foundation Grants - +

    Team

    W3F Grants Committeeโ€‹

    The committee consists of individuals who know the funding priorities of the Polkadot ecosystem and is responsible for evaluating grant applications and providing feedback on these.

    In cases where a niche expert opinion is desirable, one of the committee members may request such a review.

    W3F Grants Evaluatorsโ€‹

    Evaluators are individuals able to evaluate the technology delivered as a result of the Grants Program. The committee has the right to add or remove evaluators on the basis of supermajority.

    W3F Operations Teamโ€‹

    The Operations Team takes care of legal documents, invoicing and remittances.

    - + \ No newline at end of file diff --git a/docs/Process/changes.html b/docs/Process/changes.html index e1368072215..ef591934c3c 100644 --- a/docs/Process/changes.html +++ b/docs/Process/changes.html @@ -4,13 +4,13 @@ 4. Changes to a Grant | Web3 Foundation Grants - +

    4. Changes to a Grant

    • Accepted grant applications can be amended at any time. However, this necessitates a reevaluation by the committee and the same number of approvals as an application (according to the levels). If your application has been accepted and, during development, you find that your project significantly deviates from the original specification, please open a new pull request that modifies the existing application. This also applies in case of significant delays.
    • If your delivery schedule significantly changes, please also open a pull request with an updated timeline.
    • If your deliveries are significantly delayed and we cannot get a hold of you, we will terminate the grant (3 approvals required, regardless of level. If a member of the committee creates the termination PR, only 2 more approvals are required).
    - + \ No newline at end of file diff --git a/docs/Process/how-to-apply.html b/docs/Process/how-to-apply.html index d7c1b3562a8..25beb6e7f47 100644 --- a/docs/Process/how-to-apply.html +++ b/docs/Process/how-to-apply.html @@ -4,13 +4,13 @@ 1. Application | Web3 Foundation Grants - +

    1. Application

    tip

    If you want to apply in private, you can do so โžก๏ธ here. Note that this is generally a slower process and imposes stricter requirements on applicants.

    info

    Payments can be made in USDT and USDC on the Polkadot AssetHub, Bitcoin and fiat (USD, EUR, CHF). Please indicate your preference in the application as outlined in our application template.

    How to apply:โ€‹

    1. Please read our FAQs, category guidelines, announcement guidelines and Terms & Conditions to familiarize yourself with the subtleties of grants, applications and the program as a whole.
    2. Fork our grants program repository.
    3. In the newly created fork, create a copy of the application template. If you're using the GitHub web interface, you will need to create a new file and copy the contents of the template inside the new one. Make sure you do not modify the template file directly. In the case of a maintenance application, use the maintenance template instead.
    4. Name the new file after your project: project_name.md.
    5. Fill out the template with the details of your project. The more information you provide, the faster the review. Please refer to our Grant guidelines for most popular grant categories and make sure your deliverables present a similar level of detail. To get an idea of what a strong application looks like, you can have a look at the following examples: 1, 2, 3, 4. Naturally, if you're only applying for a smaller grant that only consists of, say, UI work, you don't need to provide as much detail.
    6. Once you're done, create a pull request. The pull request should only contain one new fileโ€”the Markdown file you created from the template.
    7. You will see a comment template that contains a checklist. You can leave it as is and tick the checkboxes once the pull request has been created. Please read through these items and check all of them.
    8. Sign off on the terms and conditions presented by the CLA assistant bot as a Contributor License Agreement. You might need to reload the pull request to see its comment.
    - + \ No newline at end of file diff --git a/docs/Process/milestone_delivery.html b/docs/Process/milestone_delivery.html index 61b9aa05da4..82ca3ae699e 100644 --- a/docs/Process/milestone_delivery.html +++ b/docs/Process/milestone_delivery.html @@ -4,13 +4,13 @@ 3. Delivery and Payment | Web3 Foundation Grants - +
    - + \ No newline at end of file diff --git a/docs/Process/review.html b/docs/Process/review.html index c18dda97956..7f0cb8d3d65 100644 --- a/docs/Process/review.html +++ b/docs/Process/review.html @@ -4,13 +4,13 @@ 2. Review | Web3 Foundation Grants - +

    2. Review

    1. The committee can (and usually does) issue comments and request changes on the pull request.
    2. Clarifications and amendments made in the comments need to be included in the application. You may address feedback by directly modifying your application and leaving a comment once you're done. Generally, if you don't reply within 2 weeks, the application will be closed due to inactivity, but you're always free to reopen it as long as it hasn't been rejected.
    3. When all requested changes are addressed and the terms and conditions have been signed, someone will mark your application as ready for review and share it internally with the rest of the committee.
    4. The application will be accepted and merged as soon as it receives the required number of approvals (see levels), or closed after two weeks of inactivity. Unless specified otherwise, the day on which it is accepted will be considered the starting date of the project, and will be used to estimate delivery dates.
    - + \ No newline at end of file diff --git a/docs/RFPs/IDE_for_ink_Smart_Contracts.html b/docs/RFPs/IDE_for_ink_Smart_Contracts.html index 02ea888e3ae..9ca1304c7de 100644 --- a/docs/RFPs/IDE_for_ink_Smart_Contracts.html +++ b/docs/RFPs/IDE_for_ink_Smart_Contracts.html @@ -4,13 +4,13 @@ Browser based IDE for ink! Smart Contracts | Web3 Foundation Grants - +

    Browser based IDE for ink! Smart Contracts

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    Project Description ๐Ÿ“„โ€‹

    ink! is a domain-specific language for writing smart contracts in Rust and compiles to Wasm code. You can deploy ink! contracts on parachains that support the contracts pallet, as well as on stand-alone blockchains built with Substrate.

    The goal of this RFP is to find teams that would like to maintain the browser-based ink! Playground for editing, compiling & sharing ink! smart contracts. ink! Playground, previously maintained by Parity, utilizes Typescript, React, Docker, and Monaco Editor.

    Useful resources:

    Deliverablesโ€‹

    We recommend to initially apply for a regular grant to fix the following issues and make the playground compatible with different versions of ink! as well as automatic updates:

    After this we would sign a maintenance grant, which allows a more flexible structure and roadmap. The list of issues and features to be covered by the grant should be discussed with the previous maintainers and the community, but it is generally up to the applying team to come up with a milestone and delivery structure.

    - + \ No newline at end of file diff --git a/docs/RFPs/ISO_20022.html b/docs/RFPs/ISO_20022.html index d429c74f611..59ddb5b7ab9 100644 --- a/docs/RFPs/ISO_20022.html +++ b/docs/RFPs/ISO_20022.html @@ -4,13 +4,13 @@ RFP: ISO 20022 | Web3 Foundation Grants - +

    RFP: ISO 20022

    tip

    This Request for Proposal is currently open, meaning we are actively looking for (additional) teams to apply for it.

    Project Description ๐Ÿ“„โ€‹

    ISO (International Organization for Standardization) 20022 is becoming the de facto global data standard for payments and electronic data interchange between financial institutions. Itโ€™s a global message standard that is already adopted by a lot of countries and is independent of the network layer. Compared to older standards, like for example ISO 8583, ISO 20022, covers all transactions, whereas ISO 8583 covers only card transactions.

    The goal of this RFP is to find teams that implement tools that make it easy and possible for the traditional finance industry to leverage substrate and ink! smart contracts to interact with ISO 20022 in various ways (e.g. cross border payments, card payments, etc.). These tools could be, but are not limited to:

    • (Java) APIs or packages that make it possible for the traditional finance industry to integrate a substrate-based ISO 20022 solution into their existing tech stack.
    • Proof of concepts, potentially leveraging the unique Off-Chain Features of Substrate that show the advantages of using ISO 20022 together with Substrate.
    • Efficient on-chain representation of the ISO 20022 XML or ASN.1-based syntax

    Useful resources:

    Deliverablesโ€‹

    The structure of the grant and the milestones depends highly on the project itself. Itโ€™s therefore up to the applying team to come up with a milestone and delivery structure.

    - + \ No newline at end of file diff --git a/docs/RFPs/ISO_8583.html b/docs/RFPs/ISO_8583.html index 1d7c8bce7ad..b3ebcb31ff9 100644 --- a/docs/RFPs/ISO_8583.html +++ b/docs/RFPs/ISO_8583.html @@ -4,13 +4,13 @@ RFP: ISO 8583 | Web3 Foundation Grants - +

    RFP: ISO 8583

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    Project Description ๐Ÿ“„โ€‹

    ISO 8583 is an international standard for systems that exchange electronic transactions initiated by cardholders using payment cards. It defines a message format and a communication flow, but offers also custom fields and custom usages. Most transactions that involve ATMs are based on this standard and Mastercard, Visa and Verve networks base their authorization communications on the ISO 8583 standard.

    Even though ISO 8583 is going to be replaced by ISO 20022, it might take some time before itโ€™s actually fully replaced.

    The goal of this RFP is to find teams that implement tools that make it easy and possible for the traditional finance industry to leverage substrate and ink! smart contracts to interact with ISO 8583 in various ways. These tools could be, but are not limited to:

    • (Java) APIs or packages that make it possible for the traditional finance industry to integrate a substrate-based ISO 8583 solution into their existing tech stack.
    • Proof of concepts, potentially leveraging the unique Off-Chain Features of Substrate that show the advantages of using ISO 8583 together with Substrate.
    • Efficient on-chain representation of the ISO 8583 syntax

    Useful resources:

    Deliverablesโ€‹

    The structure of the grant and the milestones depends highly on the project itself. Itโ€™s therefore up to the applying team to come up with a milestone and delivery structure.

    - + \ No newline at end of file diff --git a/docs/RFPs/Static-Analysis-for-Runtime-Pallets.html b/docs/RFPs/Static-Analysis-for-Runtime-Pallets.html index 821e50cb880..92b6d55c16e 100644 --- a/docs/RFPs/Static-Analysis-for-Runtime-Pallets.html +++ b/docs/RFPs/Static-Analysis-for-Runtime-Pallets.html @@ -4,13 +4,13 @@ Static Analysis of Runtime Pallets | Web3 Foundation Grants - +

    Static Analysis of Runtime Pallets

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    Project Description ๐Ÿ“„โ€‹

    Runtime Pallets are modules for writing the business logic of blockchains in Substrate (a Rust framework fo rbuilding blockchians). These are usually concise pieces of standalone code with relatively few dependencies and clear specifications, hence tractable targets for performing static analysis and verification. We would like to develop tools and techniques to perform static analysis with reasonable soundness guarantees. In particular, we would like to target vunerability classes that are detectable using dataflow analysis techniques like tag analysis and taint analysis. Just to give a flavor, relevant might vulnerabilities include:

    • incorrect origin of dispatchable functions.
    • unsigned transaction validation.
    • tracking bad randomness: ensure bad randomness does not leak into sensitive functions.
    • detect panics statically to avoid potential DoS attacks: these include unsafe arithmetic operations, access outside bounds, assertion failures, etc.
    • tracking unsanitised input leakage for sensitive functions.

    We seek applications that either extend existing static analysers for rust like MIRAI, Prusti, or build Rust front-ends to static analysis engines. Our preliminary feasibility study shows that MIRAI would be a good starting point as it includes a tag analysis framework, however, we are open to other tools and techniques.

    Deliverablesโ€‹

    The deliverables listed are an innitial draft and can be modified taking into consideration the interests of the applicant.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationA document describing the design decisions for the tool and modeling of vulnerabilities. Clear usage guideline along with the trade-off of different modes if any.
    0c.Testing GuideTest-suite which exercises various features.
    0d.ArticleA brief outreach article describing the high-level technique used and outcomes of the grant, including asample of minimal examples.
    1ToolA robust static analysis tool that works on Subsstrate runtime pallets and analyses vulnerabilities classes described above.
    2EngaegmentEngage with teams at Web3 Foundation and Parity to prioritise targeting vulnerability classes.
    - + \ No newline at end of file diff --git a/docs/RFPs/a-and-v-topology.html b/docs/RFPs/a-and-v-topology.html index 1a4ea26e11e..ae2809f7041 100644 --- a/docs/RFPs/a-and-v-topology.html +++ b/docs/RFPs/a-and-v-topology.html @@ -4,13 +4,13 @@ Availability and Validity - Network Topology | Web3 Foundation Grants - +

    Availability and Validity - Network Topology

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    • Status: Closed, since research is outdated
    • Proposer: @infinity0, @skalman, @mmagician

    Project Description ๐Ÿ“„โ€‹

    A part of the promise of Polkadot is to bring scalability to the blockchains. The way it achieves it is via delegating application-specific logic from layer 0 (the relay chain) to layer 1 chains (parachains). In order to achieve this efficiently yet securely, each parachain has its own block production mechanism (achieving efficient block production), but the finalisation of candidate parachain blocks still happens with the involvement of the relay chain validators.

    The full mechanism is described in the host specification. In short, it is split into two parts: first, a publicly known subset of validators attests that the parachain block data is available to them (i.e., they must have it in their local storage); second, once 2/3+ of the first group have published their availability votes, a "secret" (VRF-based assignment) subset of validators checks the validity of the candidate, by checking its state transition against that parachain runtime, which is available on-(the relay)chain.

    Currently, the gossip network among the relay chain validators does not make use of the public assignment of a the first subgroup of validators to a particular parachain. Instead, the candidate block is passed around the network until it reaches 2/3+ of approvals, causing an additional delay in the process of finalization of the candidate.

    This proposal aims to solve this issue by creating a selective networking topology among the publicly known subset of validators assigned to a particular parachain ID. For full details of the topology and its considerations, please consult the Availability and Validity research document.

    Deliverables ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 14 weeks
    • Total Costs: 90,000 DAI

    Milestone 1 - update & implementation planโ€‹

    Given that the above linked research document was produced almost a year ago (at the time of writing the RFP) and the fast pace of polkadot development, especially parachain development, the first step should be related to understanding and updating, if necessary, that document.

    Tasks:

    • understand what is the current implemention status for parachain networking in Polkadot

    • understand in depth what the new topology design tries to achieve

    • produce a write-up detailing the differences between current and proposed design

    • develop a roadmap for implementation, clearly identifying which parts of the codebase would be affected

    • Estimated Duration: 3 weeks

    • Costs: 15,000 DAI

    Milestone 2 - Topology discovery by validatorsโ€‹

    As detailed in the Topology section, each validator should have a deterministic and equal view of the topology.

    This milestone is tasked with figuring out the topology for each validator.

    Note: The implementer might find that splitting Milestones 2 & 3 is counterproductive, and a more efficient approach is to actually combine these.

    Tasks:

    • perform the calculation of correct network topology for each validator

    • add a method that returns the above result. This can either be an RPC method, thus allowing it to be verified externally, or an internal method, where the validators report (could be as simple as console logs) their assignment

    • run tests to verify the correctness of the calculation and unanimous consensus

    • Estimated Duration: 6 weeks

    • Costs: 30,000 DAI

    Milestone 3 - Networking and benchmarkingโ€‹

    This should be a "simple" milestone in that it replaces the previous mechanism for candidate block distribution (broadcast medium B) with direct links(D), as proposed in the Overview.

    • Estimated Duration: 8 weeks
    • Costs: 45,000 DAI

    Tasks:

    • apply the topology calculated
    • distribute block data along the direct route
    • perform an extensive testing & benchmarking exercise on a network with at least 20 validators. The parachain block production can be mocked.
    - + \ No newline at end of file diff --git a/docs/RFPs/alternative-polkadot-js-api-console.html b/docs/RFPs/alternative-polkadot-js-api-console.html index 5117c09be33..f880c3f8c4b 100644 --- a/docs/RFPs/alternative-polkadot-js-api-console.html +++ b/docs/RFPs/alternative-polkadot-js-api-console.html @@ -4,7 +4,7 @@ Alternative javascript console for Polkadot JS API | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ https://polkadot.js.org/apps/#/js

    some examples -> https://playground.substrate.dev/ here we have to manually build and run our js bundles image

    Why alternative javascript console for Polkadot-JS API?

    Current polkadot js API console which I mentioned in beginning of this post, has some limitations, which we can overcome by creating a better version for smoother dev experience.

    Deliverables ๐Ÿ”ฉโ€‹

    The following items could be the initial deliverables of the project. Of course, improvements and additions are more than welcome.

    • Initial research:

    • Development:

      • design a new UI/UX with better experience than current javascript console with features like

        • save code preferably with secure session management
        • keyboard shortcuts
        • example

        Any additional features which make the Polkadot-JS experience more productive and smoother are welcome.

    - + \ No newline at end of file diff --git a/docs/RFPs/alternative_polkadot_host_implementations.html b/docs/RFPs/alternative_polkadot_host_implementations.html index 2473f85ad42..8288423e0c8 100644 --- a/docs/RFPs/alternative_polkadot_host_implementations.html +++ b/docs/RFPs/alternative_polkadot_host_implementations.html @@ -4,13 +4,13 @@ Alternative Polkadot Host Implementation | Web3 Foundation Grants - +

    Alternative Polkadot Host Implementation

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    Project Description ๐Ÿ“„โ€‹

    The architecture of Polkadot can be divided into two different parts, the Polkadot runtime and the Polkadot host. The Polkadot runtime is the core state transition logic of the chain and can be upgraded over the course of time and without the need for a hard fork. In comparison, the Polkadot host is the environment in which the runtime executes and is expected to remain stable and mostly static over the lifetime of Polkadot.

    The Polkadot host interacts with the Polkadot runtime in limited, and well-specified ways. For this reason, implementation teams can build an alternative implementation of the Polkadot host while treating the Polkadot runtime as a black box. For more details of the interactions between the host and the runtime, please see the specification.

    The Web3 Foundation is interested in supporting additional implementations of the Polkadot Host. If you are interested in this RFP, please reach out to spec@web3.foundation.

    Currently the following implementations are under development:

    Deliverables ๐Ÿ”ฉโ€‹

    For Polkadot Host Implementations, itโ€™s probably too complex to structure the entire implementation via milestones. Components of the Polkadot host are:

    • Networking components such as Libp2p that facilitates network interactions.
    • State storage and the storage trie along with the database layer.
    • Consensus engine for GRANDPA and BABE.
    • Wasm interpreter and virtual machine.
    • Low level primitives for a blockchain, such as cryptographic primitives like hash functions.
    • Availability & Validity components to support parachains.
    - + \ No newline at end of file diff --git a/docs/RFPs/analysis-website-and-data-platform.html b/docs/RFPs/analysis-website-and-data-platform.html index 823f013c824..143f2e2c2da 100644 --- a/docs/RFPs/analysis-website-and-data-platform.html +++ b/docs/RFPs/analysis-website-and-data-platform.html @@ -4,13 +4,13 @@ Analytics Website/Data Platform | Web3 Foundation Grants - +

    Analytics Website/Data Platform

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    Project Description ๐Ÿ“„โ€‹

    On-chain analysis is an important emerging field for the Polkadot & Kusama ecosystems. One can currently use GraphQL to query data via backend services such as Subquery and Subsquid. However, it would be nice to have an easy-to-use front-end with sharable customized dashboards as well. The end result might look similar to Dune Analytics, a popular data sharing dashboard used in the Ethereum community. Using Dune Analytics, users can quickly create and openly share queries which can then be forked and remixed in a variety of ways by others.

    This RFP, based on a forum post by Rob Habermeier, aims to fund a dashboard designed to allow analysts and power-users to interactively query high-quality data, and subsequently create custom charts and visualizations to share metrics with others. Ideally, many projects would create custom dashboards to share data with the Polkadot & Kusama community.

    At the moment, building custom dashboards requires quite a bit of effort since the data needs to be fed directly from the parachain via Polkadot.js, or through a custom squid or GraphQL via Subquery. This RFP aims to ease the process of building dashboards and sharing powerful data visualizations.

    Deliverables ๐Ÿ”ฉโ€‹

    The following items could be potential expected deliverables for the project. Of course, improvements and additions are more than welcome.

    • Define a common dataset and data model for Substrate that can be shared for interactive querying use cases such as on Dune Analytics.
    • Build a publicly accessible interactive query engine. The platform should allow users to aggregate raw data from relay chains and parachains into SQL databases that can be easily queried. This might include storing data on a postgreSQL database, for example.
    • Users should be able to perform simple SQL queries in a matter of minutes, and create visualizations and dashboards using these queries.
    • Provide the ability to integrate data from backend services such as Subsquid, Subquery.
    • Create UX/UI to make it easier for analysts and power-users to easily query human-readable data and follow key metrics. The front-end could be written in React, AngularJS, Vue, etc.
    - + \ No newline at end of file diff --git a/docs/RFPs/anti-collusion_infrastructure.html b/docs/RFPs/anti-collusion_infrastructure.html index 27afdd2f079..df5c2b54e6b 100644 --- a/docs/RFPs/anti-collusion_infrastructure.html +++ b/docs/RFPs/anti-collusion_infrastructure.html @@ -4,13 +4,13 @@ Anti-Collusion Infrastructure | Web3 Foundation Grants - +

    Anti-Collusion Infrastructure

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    Project Description ๐Ÿ“„โ€‹

    A lot of blockchain applications that involve some kind of voting, like on-chain quadratic funding, can potentially be exploited via collusion and bribery (see Vitalikโ€™s post about collusion). Therefore, itโ€™s important to design mechanisms that effectively prevent any kind of on-chain collusion or at least make it more difficult. The goal of this RFP is to encourage people to try to research and come up with their own solutions or to implement existing solutions, like Minimal anti-collusion infrastructure as a substrate pallet or ink! smart contract.

    Deliverables ๐Ÿ”ฉโ€‹

    The milestones below are just an initial draft. The milestones can be structured completely differently and the implementation can also leverage other tools and infrastructure as long as the overall goal of the RFP is met.

    Milestone 1 - Anti-collusionโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationInline documentation of the code and a basic tutorial that explains how a developer can use the project
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialArticle or tutorial that explains the work done as part of the grant.
    1.Anti-collusionImplement a mechanism to prevent bribery and collusion, leveraging encrypting votes (ZKPs) potentially via Minimum Anti-Collusion Infrastructure (MACI)
    2.Voting ExampleIntegrate a basic voting example that lets you test the mechanism

    Previous grant applicationsโ€‹

    - + \ No newline at end of file diff --git a/docs/RFPs/appi.html b/docs/RFPs/appi.html index a007de5e778..7b5f4b7a681 100644 --- a/docs/RFPs/appi.html +++ b/docs/RFPs/appi.html @@ -4,13 +4,13 @@ APPI: Auto-funded public P2P infrastructure | Web3 Foundation Grants - +

    APPI: Auto-funded public P2P infrastructure

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    In Ethereum, most user-facing applications default to Infura as an endpoint to access full node information.

    While it is tempting to conclude that this is because running home nodes is prohibitively expensive, the main reason is in fact inertia. Put simply, people weren't given the option or incentive to run their own nodes fast enough, and defaulted to an easier route which stuck.

    There have been attempts at financing home-run infrastructure - projects like VIPNode have lead the charge - but the aforementioned inertia prevented any significant adoption. Another recent contender is Pokt.network.

    This document describes auto-funded public p2p infrastructure (APPI) for the Polkadot and, specifically, Kusama ecosystem. The idea is to incentivize people to run full and archive nodes at home, without relying on cloud servers and centralized points of failure.

    Dependenciesโ€‹

    Depends on Treasury Recurring Payouts: https://github.com/paritytech/substrate/issues/6551

    Overviewโ€‹

    The payout, approved by a Council motion for a specific pool of nodes would go to the the payout script (identified as an address), then the pool would distribute the funds based on the database.

    Deliverables ๐Ÿ”ฉโ€‹

    Load Balancer (LB)โ€‹

    The Load Balancer is a tool that assigns an incoming connection request to a node in its pool. The Load Balancer should only accept nodes with the same settings as every other node.

    E.g. if a node is running with some RPC endpoints off, it should not share a pool with a node that has them all on, otherwise the users connecting to the pool might experience lower QoS.

    The Load Balancer should monitor for node freshness via LB Daemon and log penalties into the Database if a node is offline (not reporting a ping for more than 30 seconds) or not fresh (a node's latest and best block lag behind the best in the pool by more than 10 blocks).

    A penalized node should enter an initial cooldown of 1 minute, and issue another check after the cooldown expires. After every check, if the offense is still on-going, the duration of the last cooldown doubles. When a node's cooldown exceeds 17 hours, the node is permanently removed from the pool (automatically removed from the whitelist).

    An LB operator can define the following settings:

    • LB name
    • LB capacity (max number of nodes)
    • Whitelist (list of node IDs)
    • Fee (cut to take)
    • Selection method (random or round robin)
    • Aliases: if the operator is running alternative clones of the same LB on other infra, aliases can be defined here. All LB clones should also define the same list of aliases, including the original. This should reduce reliance on a single LB endpoint.
    • Payout period in days
    • Payout script executable path

    The LB should be able to automatically and periodically - based on payout period - call out to a Payout script which takes as input a list of addresses and points.

    Payout Calculationโ€‹

    The LB adds points to a node in the ratio of 90:10 for requests:liveness. In other words, a node that has been online but got no requests due to bad luck should still be paid something.

    Databaseโ€‹

    An append-only database for historical data (see below) should be running alongside the LB. The LB operator should be able to define the age of the data to store. The age should default to 30 days.

    Can be Prometheus if the daemon is built in a way that exposes this information.

    LB Daemonโ€‹

    The LB Daemon is a background process (perhaps with Prometheus metrics exposed) meant to run alongside a Substrate node. This Daemon:

    • pings its home LB every few seconds with the node's ID
    • alphabetically orders and standardizes, then hashes a node's startup settings (exclude basepath and name) and sends them along with every ping
    • retrieves the node's best and latest blocks and sends them along with every ping
    • reports telemetry data to the LB, like connected peers, memory use, etc. The LB stores this data into the Database

    Without a companion Daemon, a node cannot join a pool.

    Payout scriptโ€‹

    The Payout script is in charge of disbursing payments. This is a multi-pay script which takes as input a mapping of addresses and points. The payout script should be an account of the chain it is paying out for (e.g. a Kusama account if we're dealing with a Kusama pool), so that it can receive the auto-payout from the Treasury.

    The payout script should be a standalone executable. Future efforts can develop payout scripts for other chains, which would make them immediately compatible with the other components in this document.

    Dashboardโ€‹

    Similar to Telemetry, the Dashboard should output stats for all nodes of a given LB as well as that LB itself (fee, name, contact info). Alongside those standard stats, the dashboard should also show historical information on the LB's performance as well as the performance of individual nodes in that LB. This information comes from the Database.

    • Total Estimated Duration: 2 months
    • Full-time equivalent (FTE): 160 hours
    • Total Costs: ~20000 USD

    Milestonesโ€‹

    Milestone 1: LB Daemon and Databaseโ€‹

    See LB Daemon and Database for definitions.

    Summary: The LB Daemon, a standalone daemon to run alongside a Kusama or Polkadot node, should be able to feed node information into a remote database.

    • Estimated Duration: 2 weeks
    • FTE: 40 hours
    • Costs: 5000 USD

    Milestone 2: Load Balancerโ€‹

    See Load Balancer for definition.

    Summary: The LB should be able to read the database from milestone 1 and route RPC requests to qualified nodes.

    • Estimated Duration: 4 weeks
    • FTE: 80 hours
    • Costs: 10000 USD

    Milestone 3: Payout Scriptโ€‹

    See Payout Script and Payment Calculation for details.

    Summary: The Payout script should be callable externally and be able to distribute payments from a single stash of tokens to multiple addresses in a single call, using a provided data file of ratios provided by the caller.

    • Estimated Duration: 1 week
    • FTE: 20 hours
    • Costs: 5000 USD

    Milestone 4: Dashboardโ€‹

    See Dashboard for details.

    Summary: A dashboard for public insight into a given pool should be developed. The pool operator should be able to easily deploy this dashboard on his own infrastructure, with or without wrapper services like Docker.

    • Estimated Duration: 1 week
    • FTE: 20 hours
    • Costs: 5000 USD
    - + \ No newline at end of file diff --git a/docs/RFPs/bpf-contracts.html b/docs/RFPs/bpf-contracts.html index d15d0a69b11..a04b24c00d6 100644 --- a/docs/RFPs/bpf-contracts.html +++ b/docs/RFPs/bpf-contracts.html @@ -4,14 +4,14 @@ BPF-based ink! smart contracts | Web3 Foundation Grants - +

    BPF-based ink! smart contracts

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    Substrate's FRAME contracts pallet allows for WASM-based smartcontracts on Substrate, written in ink!, a Rust-based eDSL. WASM comes with a lot of advantages, such as high flexibility, tooling, a good compiler (wasmtime) and a lot of high level constructs. However, these features comes with a cost: complexity of the API and compiler implementation as well as impacts on performance. For example, Substrate does not embed the API for WASM VM due to its complexity.

    eBPF as a WASM alternativeโ€‹

    An alternative to WASM here would be eBPF, a technology for running sandboxed programs in an operating system kernel. It originated from BSD's BPF that comes with a permissive open-source license and represents a Linux-compatible implementation thereof, that instead uses a viral open-source license.

    eBPF constraintsโ€‹

    However, vanilla eBPF has some serious constraints:

    1. LLD can't link BPF code (LLD is the linker contained in LLVM which is the compiler framework that Rust's compiler rustc relies on).
    2. rustup doesn't include any core nor std library for LLVM (and rustc)'s a upstream BPF targets (bpfeb-unknown-none and bpfel-unknown-none)
    3. Loops are not fully supported.

    While 1) and 2) technically can be worked around by using bpf-linker, 3) needs further research. Also, 2) will only work if loops are bound statically due to constraints within the LLVM backend. A viable solution here would be to replace this constraint by using gas metering.

    eBPF advantagesโ€‹

    Despite the constraints, eBPF-based ink! smart contracts would be expected to have the following advantages over its WASM-based counterpart:

    • Simplicity: Due to its register-based instruction set it would be easier to compile
    • Efficiency and performance

    Previous workโ€‹

    Alex and pepyakin have attempted to use eBPF instead of WASM for ink! smart contracts when attending a hackathon. While they didn't manage to compile to BPF, their resources might be useful as a starting point:

    Conclusionโ€‹

    The goal of this RFP is to allow for eBPF-based smart contracts. To summarize, the rough process should be:

    1. Compile Rust-based ink! smart contracts using rBPF, returning an eBPF ELF file
    2. Store the ELF file on-chain
    3. Execute the ELF file within the eBPF VM that will convert it to machine code
    - + \ No newline at end of file diff --git a/docs/RFPs/candle-auction.html b/docs/RFPs/candle-auction.html index 60278784cc5..6ec72a76728 100644 --- a/docs/RFPs/candle-auction.html +++ b/docs/RFPs/candle-auction.html @@ -4,13 +4,13 @@ Candle auction smart contract | Web3 Foundation Grants - +

    Candle auction smart contract

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    Auctions will come in handy for various types of applications, but especially for NFTs.

    The idea behind this proposal is to create an ink! smart contract that is able to run a candle auction mechanism. This will be known to Polkadot followers from the parachain auction mechanism. One of the advantages of the candle mechanism is that it incentivises bidders to submit their true bids early, thus leading to more optimal market.

    Rather than restricting the use of candle auctions to parachain slot allocation only, users should be able to utilise it for other needs, e.g. auctioning off their NFTs.

    Such a smart contract could have specific call logic embedded and give the winner the right to execute that logic (with supplied parameters). For example, the smart contract could own an asset, and such call logic could transfer such asset to whichever account the winners supplies.

    Deliverables ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 1 month
    • Full-time equivalent (FTE): 1

    Milestone 1 - Basic auctionโ€‹

    • Estimated Duration: 3 weeks
    • Costs: 7500 DAI
    NumberDeliverableSpecification
    1.Start & close periodCreate an auction mechanism that has a fixed start and end period
    2.Accept bidsAny user can call the contract with a bid that is higher than the last highest bid
    3.Find winnerDetermine a winner at the close period
    4.Embed reward logicThe contract creator should set logic that will be executable by the winner. Such call logic should accept optional parameters. This logic should be set at the start and be immutable henceforth
    5.PayoutA winner should be able to make a call, with an arbitrary number of parameters, to the reward/payout method. The contract would then pass the arguments to whichever logic is encoded as the reward (and e.g. send tokens)

    Milestone 2 - Random closeโ€‹

    • Estimated Duration: 1 weeks
    • Costs: 2500 DAI
    NumberDeliverableSpecification
    1.Retroactive closeAt the close block, rather than announcing the highest bidder at that point, the contract should randomly determine a block in the past (between start & end blocks) and calculate the highest bidder at that block to be the winner
    2.Randomness source (optional)Randomness source should be configurable (e.g. from hash of the block in the relay chain, from a randomness beacon parachain etc.)
    - + \ No newline at end of file diff --git a/docs/RFPs/crowdloan_front_end_template.html b/docs/RFPs/crowdloan_front_end_template.html index 92b459daf87..218a227d730 100644 --- a/docs/RFPs/crowdloan_front_end_template.html +++ b/docs/RFPs/crowdloan_front_end_template.html @@ -4,13 +4,13 @@ Crowdloan Front End Template | Web3 Foundation Grants - +

    Crowdloan Front End Template

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    The following document intends to outline what a front-end white-label template could look like for teams to use to easily build their Polkadot Crowdloan (see Wiki: Parachain Crowdloans) websites. Teams applying for this RFP can change and adapt this.

    The overall objective of this project is to provide a white-label solution to teams to be able to plug into and offer all the information users need to contribute to their Crowdloan. In essence, it's a collection of:

    All of the above should be done style agnostic so that the project can plug their own look and feel into the site.

    Project Informationโ€‹

    This is just a place where the project can talk more about what they are doing.

    Rewards Schemaโ€‹

    This is just a place what the reward schema looks like. It's important to know that different teams can have different rewards mechanisms. For example, a team can offer higher contribution to early-birds (first x_amount_of_contributors; first y amount_of_tokens_contributed), they can offer referrals or even they can get smarter and offer higher rewards if they are losing.

    In the end, for this section it's more important to give the teams the ability to query easily the information than rather to get them a UI pre-defined. In general, it would be good for the template to offer two out-of-the-box mechanisms:

    1. Early Bird contributions.
    2. Rewards schema.

    Whichever the schema, there should be also a way of having this information available later on for the team to effectively give out the rewards.

    Current Contributionsโ€‹

    Some teams like to show the number of contributors, others the list of addresses and how much they contributed, and others nothing at all. We need to give them all an option.

    Time left in Crowdloan and competitionโ€‹

    Auctions have two phases: start_period and ending_period. During the start_period nothing important really happens, however every block of the ending_period matters, as this is when the candle can go out.

    On top of this, teams will have other teams competing for the slots as well. This information needs to be displayed as well.

    Contribute CTAโ€‹

    A simple button to allow users to contribute directly through the UI. This should open PolkadotJS or whatever wallet the user prefers, and add this directly on chain. Important to manage the entire cycle of the contribution:

    • contribute -> waiting for finalization -> finalized.
    • contribute -> waiting for finalization -> error.

    After the Crowdloanโ€‹

    Once the Crowdloan ends, it will be good for the team to easily query all contributors and have them sort it to calculate the rewards given the rewads schema.

    Available Toolsโ€‹

    Past examplesโ€‹

    - + \ No newline at end of file diff --git a/docs/RFPs/data_analysis_tools.html b/docs/RFPs/data_analysis_tools.html index 10760ac5848..1a6b99e0049 100644 --- a/docs/RFPs/data_analysis_tools.html +++ b/docs/RFPs/data_analysis_tools.html @@ -4,13 +4,13 @@ Data Analysis Tools for Substrate-based Blockchains | Web3 Foundation Grants - +

    Data Analysis Tools for Substrate-based Blockchains

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    Project Description ๐Ÿ“„โ€‹

    Block Explorers are tools that index blockchain data and allow people to easily exhibit it using a web user interface. Examples of Block Explorers in the Polkadot/Kusama ecosystem are (not exhaustive) Subscan, Calamar, and Statescan. For common users, the features commonly found in block explorers are enough. However, for advanced users, the data analysis involves accessing many screens and following long paths through blockchain data.

    For example, Accounts has some provenance information that is pretty difficult or currently impossible to extract in block explorers. The account reference counter, account balance reserved provenance (see: https://docs.substrate.io/reference/account-data-structures/), and OpenGov delegations are examples of it. Some questions raised that use this data:

    • Which transactions/accounts were responsible for the reserved balance in an account?
    • What modules currently depend on consumers, providers, and sufficients reference counters for a certain account, and which transactions introduced/removed those references?
    • Which accounts have delegated OpenGov votes to an account or to which accounts the account in question has delegated their votes to for each track, taking into account indirect delegations too (e.g. Account A delegates to Account B which delegates to Account C)?

    This information is useful and requested for actual heavy users of the Polkadot/Kusama ecosystem.

    This RFP is not limited to the example above and intends to support other analyses. This RFP is also not limited to adding new features to the existent block explorer, as applicants can propose new analysis tools as well. Please notice that the intention here is not to create new block explorers that would have the same information, presented in the same way, as the current ones.

    Deliverables ๐Ÿ”ฉโ€‹

    The expected deliverables are the tool features that provide specific data analysis. The data analysis provided by the tool should be detailed in the deliverables. Each analysis should be dynamic, reflecting the current state of the blockchain, and be presented in a web user interface, in a way that advanced non-technical users can consume, i.e., the user does not need to have programming skills. Please list each data analysis that will be supported by the tool in the deliverables including:

    • The data analysis question. (ex: Which transactions were responsible to reserve the balance amount in an account?)
    • The expected input for the data analysis (ex: an account)
    • The expected output for the data analysis (ex: a set of transactions that made/removed a balance reserve in the input account)

    The proposed analysis should not overlap with existing ones if the information is easy to extract in block explorers of the Polkadot/Kusama ecosystem. They can, however, overlap if the information is not simple or can't intuitively be found by non-technical users in the current block explorers (ex. based on multiple steps in the block explorer or based on events data).

    The user interface provided should allow the users to make or find the questions that can be answered by the tool. The tools should NOT demand that users need to know or learn technical query languages such as SQL, GraphQL, or any other.

    - + \ No newline at end of file diff --git a/docs/RFPs/decentralized-security-marketplace.html b/docs/RFPs/decentralized-security-marketplace.html index 2ba71df4946..53049564d21 100644 --- a/docs/RFPs/decentralized-security-marketplace.html +++ b/docs/RFPs/decentralized-security-marketplace.html @@ -4,7 +4,7 @@ Decentralized Security Marketplace | Web3 Foundation Grants - + @@ -12,7 +12,7 @@

    Decentralized Security Marketplace

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    Project Description ๐Ÿ“„โ€‹

    According to the Immunefi's 2022 annual report, there has been a total loss of ~$3.77B because of hacks in the web3 space. To increase a protocol's security, audits and bug bounties can be a useful tool.

    A decentralized security marketplace would allow projects to find reviewers/testers/auditors/whitehats and vice versa to pursue structured tests and audits. This would benefit everyone:

    • Projects would increase their security;
    • Developers would have the possibility to earn while using their skills, improving them;
    • The ecosystem would be more secure, with more projects being audited and more developers learning about security.

    Ideally, this marketplace would be built as a smart contract platform deployable on any existing parachain (that supports WASM smart contracts, such as Astar or Watr) using ink! (here you can see some examples).

    Note: This use case can be extended/applied to other areas. The main problem to solve here is to find a way to manage the delayed transaction between two parties (i.e., escrow), and to ensure fairness and transparency (e.g., a reviewer is not able to deliver all the reports in time, and the project's team would like to decide whether to extend the escrow duration or just to pay a lower percentage of the established bounty).

    Actors ๐Ÿ‘ฅโ€‹

    To ensure fairness and transparency, the marketplace could have the following actors:

    • Projects - The projects that want to be reviewed / tested;
    • Auditors - The developers that want to perform audits / hunt bugs;
    • Arbiters - The developers that will arbitrate the disputes between projects and auditors (they will be useful if a project opens a dispute for any reason). They could get a small percentage of the bounty.

    Deliverables ๐Ÿ”ฉโ€‹

    The followings could be the initial deliverables of the project. Of course, improvements and additions are more than welcome.

    1) Initial research and design of the protocol:

    • You can refer to what Immunefi and Code4rena are doing (but bring that on-chain);
    • How to ensure the trustless interaction (e.g., projects could lock a percentage of the bounty to open the request);
    • What types of disputes could be risen and how to solve them;
    • How to manage time delays;
    • Look for other use cases (in or outside the security field); 2) Development of the protocol:
    • Development of the governance smart contract (e.g. to add/remove projects, auditors, arbiters, etc.);
    • Development of the auditing smart contract (e.g. to create audits);
    • Development of the arbitration smart contract (e.g. to create/solve disputes); 3) Development of the frontend, that enables the actors to interact with the protocol.
    - + \ No newline at end of file diff --git a/docs/RFPs/epassport-zk-validation.html b/docs/RFPs/epassport-zk-validation.html index 51a747eb48f..fc7f05a2462 100644 --- a/docs/RFPs/epassport-zk-validation.html +++ b/docs/RFPs/epassport-zk-validation.html @@ -4,13 +4,13 @@ e-Passport ZK Validation [ON HOLD PENDING REVISIONS] | Web3 Foundation Grants - +

    e-Passport ZK Validation [ON HOLD PENDING REVISIONS]

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    The issue of verifying identities on-chain and providing Proof-of-personhood is a challenging one.

    One idea to authenticate users is to ask them to submit the details from their e-passports. While it would provide authentication, it forgoes the aspect of privacy.

    This proposal aims to provide the verifiability of personal data coming from e-passports, while ensuring protection of personal information by using zero-knowledge proofs.

    Deliverables ๐Ÿ”ฉโ€‹

    Please note that the below given details do not comprise neither detailed nor security-complete plan of development. The implementing party should perform in-depth research on each part of the protocol in order to understand its limitations and nuances.

    Milestone 1 - transparent solution PoC on substrateโ€‹

    • Estimated Duration: 3 months (incl. research)
    • Costs: 60,000 kUSD

    As the first step, we propose the creation of a working PoC without the use of zero-knowledge proofs that can be deployed on substrate.

    Deliverables:

    • Chain can store the necessary certificates from CSCA
    • User can upload their DSO (Document Security Object) as well as the associated DSC (Document Signer Certificate) on chain
    • The chain logic verifies:
      • DSC is valid against CSCA
      • the signature contained within the DSO checks out against DSC

    Milestone 2 - adding ZK functionalityโ€‹

    • Estimated Duration: 5 months
    • Costs: 100,000 kUSD

    Rather than supplying the entire DSO, which would reveal the user's personal information, users should be able to upload a cryptographic proof that they indeed know the data contained within the DSO, without revealing it in its entirety.

    There should be two parts to this functionality: off-chain prover and on-chain verifier.

    The users would supply all their private information to the off-chain prover (which they can either run themselves or use a trusted third party) and the prover would produce a cryptographic proof.

    Later, the proof is uploaded on-chain, and the chain logic performs verification of the proof given the pre-agreed circuit. The circuit must be shared between prover and verifier and should include public inputs such as the latest Master List of CSCA certificates, revocations, etc., as well as use the same algorithms and parameters.

    Milestone 3 - Updateabilityโ€‹

    • Estimated Duration: 1 month
    • Costs: 20,000 kUSD

    The Master List is expected to, albeit unfrequently, receive updates as new countries join the PKD or as they update their certificates periodically. Furthermore, countries are expected to publish the revocations of any compromised certificates.

    It is important that both prover and verifier circuits are updated accordingly - else the proof won't match.

    - + \ No newline at end of file diff --git a/docs/RFPs/formal_guarantees_for_grandpa.html b/docs/RFPs/formal_guarantees_for_grandpa.html index 238976bfaa5..a6cc8821f86 100644 --- a/docs/RFPs/formal_guarantees_for_grandpa.html +++ b/docs/RFPs/formal_guarantees_for_grandpa.html @@ -4,13 +4,13 @@ Formal Guarantees for GRANDPA Finality Gadget | Web3 Foundation Grants - +

    Formal Guarantees for GRANDPA Finality Gadget

    tip

    This Request for Proposal is currently open, meaning we are actively looking for (additional) teams to apply for it.

    Project Description ๐Ÿ“„โ€‹

    Consensus layers are the backbones of blockchains. Any vulnerability in the consensus mechanism can have far reaching consequences on the integrity and security of the whole system. Polkadotโ€™s Relay Chain uses GRANDPA (a deterministic finality gadget) to achieve consensus in the network.

    This proposal aims to provide formal guarantees of GRANDPAโ€™s correctness and security by modeling the consensus mechanism and verifying it against formal specifications. We expect this exercise would lead to better implementations, since writing formal specs exposes implicit assumptions. Furthermore, developers can identify invariants to guide implementation, and use counterexamples to produce tests that expose bugs.

    We are open to any reasonable formal methods approach that rigorously proves the correctness of GRANDPAโ€™s claims of validity, finality and liveness. Suggested list of techniques include:

    • Model-checking (in TLA+ Apalache, Ironfleet, IVY)
    • interactive theorem proving (in Isabelle/HOL, Coq, verdi)
    • Any other temporal property verification tool for distributed systems

    We envision the project to prove both safety and liveness properties of GRANDPA which interacts with a Block Production mechanism (like BABE or Sassafras) by assuming an abstract interface.

    Deliverablesโ€‹

    The structure of the grant and the milestones depends highly on the project itself. Itโ€™s therefore up to the applying team to come up with a milestone and delivery structure.

    The deliverables listed below are just an initial draft, assuming the project uses the approach of Modelcheking in TLA+ and can be changed. Proof of correctness can be delivered in stages. Verification of safety properties is mandatory and liveness properties is an optional objective.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationA document describing the design decisions in the modeling process, including justification for abstractions and assumptions (e.g. on the network model, latency, behavior of validators, nature of faults) w.r.t to protocol in the Paper and Spec. In-line comments in the TLA+/ PlusCal models that provide a clear mapping to the feature/property.
    0c.Testing GuideInstructions to set up the required environment to run the analysis, preferably a docker image with all the tools pre-installed.
    0d.ArticleHigh-level document summarizing the results of the verification efforts as well as a final presentation for a broader audience that summarizes the key take-aways.
    1Proof ArtifactModels and specs in TLA+ that adhere to protocol implementations with reasonable abstraction gaps. As a stepping stone, the block production mechanism could be instantiated with BABE.
    2Proof ArtifactFormalize the validity, finality and liveness of GRANDPA as temporal properties in TLA+.
    3EngagementsEngage with the Web3 research team via regular meetings to refine the models and specs. For eg., clarify any assume/ rely reasoning made in the protocols. Engage with Web3 team to determine if detected bugs's are spurious.
    - + \ No newline at end of file diff --git a/docs/RFPs/grant_management_webapp.html b/docs/RFPs/grant_management_webapp.html index 39e524c5197..06bccc5e440 100644 --- a/docs/RFPs/grant_management_webapp.html +++ b/docs/RFPs/grant_management_webapp.html @@ -4,7 +4,7 @@ Grant Management Web Application | Web3 Foundation Grants - + @@ -13,7 +13,7 @@ the W3F grants repositories in a way that facilitates easier navigation for the grants committee. Though the software would initially be used for the W3F Grants Program, any interested third parties should ideally be able to utilize the application for their own purposes.

    By providing an API, it will also allow for pulling the data in a structured way in order to make it easy to calculate statistics, track different metrics and publish data.

    The Web3 Foundation Grants Program is unique in that everything is openly and transparently published on GitHub. As a result of this RFP, we hope the W3F Grants Program can set an example of how other grant programs can leverage a simple yet powerful process to manage their grants. Therefore, the web application and the structure of our repositories should be reusable by other grant programs.

    Existing prototypeโ€‹

    A quick and dirty prototype already exists for the application:

    These examples are just an initial experiment to test how the app could work, and are completely undocumented, but please feel free to contact us if you need help trying them out or to simply discuss.

    Also, using these is completely optional and the RFP doesn't require building from these. Proposers are free to propose the framework and approach of their choice.

    Deliverables ๐Ÿ”ฉโ€‹

    Grants Pageโ€‹

    • Lists grants and their status.
    • Search
    • Filter

    For example:

    screenshot_grants_page

    Grants detailsโ€‹

    • Shows the grant information
    • Overview of the grant project
    • Milestones details and status
    • All documents related to the grant and links to their pull requests (application, deliveries and evaluations)

    For example: screenshot_grants_details

    Teamsโ€‹

    • Provide a view at the team level.
    • Contact information.
    • Grants and applications, and their current status.

    Applicationsโ€‹

    • Current grant applications.
    • Links to the PR on github, link to the team page to check their history.
    • Status of the application, date opened, number of approvals so far and how many remaining.

    Deliveriesโ€‹

    • Shows current deliveries pending evaluation.
    • Links to all relevant information and history.
    • Status of the delivery, submission date, evaluator, and if it's on stale.

    Statsโ€‹

    • Number of applications approved by month, with the corresponding total amount, and paid so far.
    • Map of applications by country of origin.
    • Chart of applications by status (Not yet delivered / delivered first milestone / completed / terminated)

    APIโ€‹

    • The web app should ideally separate frontend from backend logic, and publish an API to fetch the structured data.

    Additional Notesโ€‹

    • The features proposed above represent an suggestion on what the grant management webapp should do and look like, but are neither exhaustive nor strictly required. Teams are welcome to propose their own design and vision for this product.

    • The Web3 Foundation's Grants Program should be just an example/first step. Ideally, the tool (combining GitHub + website) can benefit other grant programs and on-chain treasuries.

    • Long term goals:

      • Oracles/pallets for treasury integration.
      • Using a decentralized alternative instead of github.
    - + \ No newline at end of file diff --git a/docs/RFPs/identity-directory.html b/docs/RFPs/identity-directory.html index 1e974285bfe..2be600555d0 100644 --- a/docs/RFPs/identity-directory.html +++ b/docs/RFPs/identity-directory.html @@ -4,13 +4,13 @@ RFP: Substrate Identity Directory | Web3 Foundation Grants - +

    RFP: Substrate Identity Directory

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    Project Description ๐Ÿ“„โ€‹

    In Substrate-based chains which implement the Identity pallet, users can register on-chain information about themselves. It is currently difficult to search by any of the identity fields. There is also no way to link directly to an on-chain account and see human-readable reports of its interactions with the chain, let alone quickly send tokens to it or otherwise interact directly with that account.

    The Identity Directory is a fully client-side web application which makes this possible.

    It accepts input such as https://kusama.polkaperson.com/swader or https://kusama.polkaperson.com/HviHUSkM5SknXzYuPCSfst3CXK4Yg6SWeroP6TdTZBZJbVT or https://polkaperson.com/ThJ.

    The service:

    • reads the input param
    • if the input param is an address or an index (second and third option respectively), the single page view opens
    • if the input param is not an address (first option), a list page view opens

    List Page Viewโ€‹

    The service looks through all the registered identities on Kusama or Polkadot, and lists all the identities that have the provided value set as ANY of the fields in their identity entry. Clicking any of them takes a person to the Single Page View and changes the URL to https://polkaperson.com/HviHUSkM5SknXzYuPCSfst3CXK4Yg6SWeroP6TdTZBZJbVT with the appropriate address, since addresses are unique.

    Alternatively, if the address has a frozen index attached, the index should replace the address in the URL for usability, i.e. https://polkaperson.com/ThJ.

    Single Page Viewโ€‹

    The single page view contains a beautifully rendered identity card of an on-chain identity along with all the metadata in the identity entry, an avatar if provided, any verifications from registrars in the chain, and buttons somewhere in the UI that allow you to Send tokens directly to the user.

    Above screenshot is from Pulse HTML template.

    The UI should be tweetdeck-like in that it offers multiple columns, each with a specific purpose, and the columns should be close-able and re-orderable, so users can just order them as they choose. The order should be remembered across the app, and there should be a toggle to freeze a layout for a specific user (i.e. maybe you only want Validator Performance for a certain validator but maybe you're interested in everything a high-profile account does on chain so you want all the columns).

    Pluginsโ€‹

    The application should support a plug-in ecosystem for different sub-views of identities. The hosted, on-line version would come with some default plugins activated (see Default Plugins) while the off-line version should support simple installation of other plugins. Most plug-ins will be rendered as additional columns of data, except in some cases (i.e. replace the "recent news" ticket at the top of the screen with a "recent on-chain tips issued", or a plug-in which adds push notifications).

    Note: if a user is not connecting to an archive node, archive data should be unavailable. The plugins (default, optional, and third party plug-ins) are responsible for realizing this and reporting to the user that some info won't be available if the user connects to only a full node.

    Layouts and Linkingโ€‹

    The individual events and positions in the various columns should be linkable, and URLs will dictate which columns are visible and in which order. So a URL like https://polkaperson.com/HviHUSkM5SknXzYuPCSfst3CXK4Yg6SWeroP6TdTZBZJbVT#governance@448217&rmrk@330589, would render a screen on which the governance default plugin would scroll to block 448217, and the RMRK column would scroll to block 330589, and RMRK would come AFTER the governance column in the view. Setting it as #rmrk@330589&governance@448217 would make rmrk appear BEFORE governance. Including a column/plugin without a block number serves to simply activate it in the UI, e.g. https://polkaperson.com/HviHUSkM5SknXzYuPCSfst3CXK4Yg6SWeroP6TdTZBZJbVT#governance@448217&rmrk@330589 would contain the default basic identity column + governance + rmrk, and https://polkaperson.com/HviHUSkM5SknXzYuPCSfst3CXK4Yg6SWeroP6TdTZBZJbVT#governance@448217&rmrk@330589&identityhistoyt&society&remarks would also activate optional columns which show an account's identity registration history, their Society participation, and all the system.remark calls they issued.

    Default Pluginsโ€‹

    • basic info: a column with basic information about an account, similar to the sidebar on Polkadot JS Apps UI. Should discern between registrars - it should list each registrar who verified this identity and the verification level they gave (i.e. KnownGood vs KnownBad etc.)
    • governance: a column listing all of an account's governance activity like votes, proposals, marking the times when the account was a council member, etc. It should resemble a vertical timeline, with related events referencing each other, quoted-tweet style. Events should be linkable as described above, i.e. governance@477723. The column should clearly mark when a user was a council member but failed to uphold their duties, i.e. there was a motion but the user did not vote, and other interesting info (i.e. the user did not do ANYTHING the council can do while being a council member).
    • treasury: a history of an account's interactions with the treasury - tip proposals and endorsements, treasury proposals and grant wins, votes on TP motions if user was council at the time (and clear marks if the user FAILED to vote on a TP motion during his activity as councilor).
    • validator: showing the history/summary of the account's participation in securing the network

    Optional Pluginsโ€‹

    The off-line version (self-run version) should support simple installation of plug-ins like so:

    yarn add @web3id/rmrk

    This would add the community-developed RMRK plugin column with details about an account's NFT activity on Kusama.

    Optional plugins to support at launch:

    • txhistory for listing all of an account financial transactions (moving of tokens)
    • identityhistory for listing all of an account's interactions with identities - when they submitted their info, when and who verified them, etc.
    • remarkshistory for listing all of an account's past issued remarks
    • society for displaying an account's participation in Society, including how much they bid, when they were accepted, when their full payout is due, how many times they defended, how many times they voted, and other Society-related ops.

    Deliverablesโ€‹

    Milestone 1โ€‹

    A basic application is developed which supports querying by address, index, or identity fields, and displays a basic mobile-friendly list view or single page view with the "basic info" column fully functional. The user should be able to set their own node endpoint.

    Milestone 2โ€‹

    Default plugins are developed: governance and treasury. Events in the columns are linkable, and layouts of the columns can be saved. The app is updated with these defaults and hosted on IPFS. Performance is crucial at this stage - caching queries and results and being creative with approaches is tantamount to UX. One example approach: allow users to enter their pinata key, and store set of fetched information to IPFS and pin on pinata (free tier of 1GB pins). On future queries of archive info, fetch from IPFS instead if faster. Along with pinata, users could also define their own IPFS node endpoint and serve their own IPFS data if they have one.

    Milestone 3โ€‹

    Optional plugins are developed, implemented into the app, and tested for per-identity layout saving and rendering on both mobile and desktop. The app should, at this point, support easy installation of plug-ins and have a yarn build step that builds the site for offline or IPFS use.

    Milestone 4โ€‹

    Maintenance phase - the team is expected to deliver comprehensive documentation on developing plugins and hosting your own Identity Directory with and without IPFS and other supporting options. The team should help plug-in implementers finalize their work and review their plug-ins.

    Please note that the proposal should include a proposal for medium to long term maintenance of this project, especially as architecture changes and parachains launch.

    Other considerationsโ€‹

    The application:

    • MUST be IPFS-hostable, so fully client-side
    • MUST be docker-less and SHOULD be react-less, for ease of use and installation on regular machines, and to conserve resources. The goal is to be able to download the app directly, even zipped, and run it on one's machine without much difficulty and technical know-how. (Of course, if one wishes to add plugins, one has to use NodeJS and install them with yarn, then build the app to get something runnable)
    • SHOULD be mobile-friendly, at least mobile-runnable. The Pulse theme linked above does come with mobile friendliness built-in, perhaps this is something to be inspired by.

    Additional Plug-in Ideasโ€‹

    These can later become RFPs of their own.

    • rmrk: lists a user's interactions with the NFT ecosystem on Kusama. More info.
    • standing: a card which visualizes someone's standing in the community. Can hook into Polkassembly to see how many discussions they participated in, look into votes and other on-chain activity, and build a subjective profile on how productive a member of the chain's society this person is.
    • earnings: visualizes and documents a user's earnings over time, both through staking and nominating, along with a historic overview of when the user was bonded, unbonded, etc.
    - + \ No newline at end of file diff --git a/docs/RFPs/implementation-benchmarking.html b/docs/RFPs/implementation-benchmarking.html index 0a420d43ccb..3b976db6a28 100644 --- a/docs/RFPs/implementation-benchmarking.html +++ b/docs/RFPs/implementation-benchmarking.html @@ -4,7 +4,7 @@ ink!/pallet/solidity performance benchmarking | Web3 Foundation Grants - + @@ -12,7 +12,7 @@

    ink!/pallet/solidity performance benchmarking

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    Project Description ๐Ÿ“„โ€‹

    When a new team comes to the ecosystem, they are faced with a decision on how to best implement the logic that they need. Traditionally in substrate, this has been a choice between a smart contract vs. runtime module (a.k.a. pallet) and elaborated on in this StackOverflow question or this entry in Substrate Developer Hub. The choice has since been augmented by the possibility to deploy solidity contracts to an EVM-compatible chain, or even writing solidity code and compiling it to WASM with the help of a solang compiler.

    As substrate is gaining traction, more and more tools will enable developers to write their logic in their language of choice and deploy on-chain, such as:

    This RFP calls for a benchmarking effort to help inform newcomers about the choice of the best tool for writing application logic. Apart from quantifiable metrics, we would like the outcome of this work to be a guide for developers, perhaps expanding on the aforementioned StackOverflow post. Depending on the outcome, the work might get integrated into our READMEs/wikis.

    Before starting this effort, it might make sense to take a look at the official runtime benchmarking docs to assess whether it can be leveraged in some way.

    Deliverables ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 4 weeks
    • Full-time equivalent (FTE): 1
    • Total Costs: 10,000 DAI

    Milestone 1 - Basic benchmarkingโ€‹

    • Estimated Duration: 2 weeks
    • Costs: 5000 DAI
    NumberDeliverableSpecification
    1.Devise performance metricsList the quantifiable metrics that can be compared across different implementations, such as storage footprint and execution speed.
    2.Pallets: basic read & writeCreate a pallet which exposes simple methods for writing to storage and reading from on-chain storage. Should be implemented for basic types.
    3.ink!: basic read & writeAs above, but for smart contracts
    4.Benchmarking frameworkCreate a set of tools that allows calling both the pallet's extrinsics and contract's public methods multiple times, measuring the execution time, impact on on-chain storage etc., to enable extraction of statistically meaningful data for performance comparison

    Milestone 2 - Integrate native solidity & solang-compiled solidityโ€‹

    • Estimated Duration: 2 weeks
    • Costs: 5000 DAI
    NumberDeliverableSpecification
    1."native" solidity: basic read & writeAs per previous milestone
    2.WASM-compiled solidityAs per previous milestone
    3.Adapt the benchmarking frameworkInclude both flavours of solidity into the tools

    Milestone 3 - More complex application logicโ€‹

    Apart from just reading & writing basic types, all the above implementations should be extended to include more complex logic. The scope is up to the implementers, but here are some ideas:

    • cross-contract calls
    • emitting events
    • storage-agnostic logic (self-contained methods performing e.g. some heavy computation)

    The cost is scope dependent.

    - + \ No newline at end of file diff --git a/docs/RFPs/ink_smart_contract_block_explorer.html b/docs/RFPs/ink_smart_contract_block_explorer.html index ad634b276c8..ff6649ae542 100644 --- a/docs/RFPs/ink_smart_contract_block_explorer.html +++ b/docs/RFPs/ink_smart_contract_block_explorer.html @@ -4,13 +4,13 @@ RFP: ink! block explorer | Web3 Foundation Grants - +

    RFP: ink! block explorer

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    Project Description ๐Ÿ“„โ€‹

    We are looking for a team or multiple teams to implement ink! smart contract block explorer. Ink! is a domain specific language for writing smart contracts in Rust and compiles to Wasm code.

    Deliverablesโ€‹

    The structure of the grant and the milestones depends highly on the supported features of the block explorer.

    - + \ No newline at end of file diff --git a/docs/RFPs/jsonrpsee-proxy-support.html b/docs/RFPs/jsonrpsee-proxy-support.html index 73560a66edf..e42a270a88f 100644 --- a/docs/RFPs/jsonrpsee-proxy-support.html +++ b/docs/RFPs/jsonrpsee-proxy-support.html @@ -4,7 +4,7 @@ Socks5 proxy support for JsonRpsee | Web3 Foundation Grants - + @@ -13,7 +13,7 @@

    In february 2023, a small public rpc provider was launched in order to provide .onion rpc endpoints for handful of chains in the ecosystem.
    Privhost was later listed on the awesome-substrate list.

    In order to connect to a .onion site, a user must pass it's connection through a tor socks5 proxy in order to resolve the .onion domain and connect.

    Several ecosystem projects want to add support for connecting to .onion, but are blocked due to JsonRpsee not having support for sock5 proxy.

    Third party pr's that are waiting for JsonRpsee to support socks5:

    On 4th of September of 2022 a pr was created to start the process of adding socks5 support for JsonRpsee.
    Noone has had time to fix this issue and implement this feature, therefor this RFP.

    Motivationโ€‹

    • Enable client libraries to connect to .onion rpc nodes.

    Ecosystem projects that rely on JsonRpseeโ€‹

    Deliverables ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 4 weeks
    • Full-time equivalent (FTE): 4 weeks
    • Total Costs: 9000 USD(may be changed by the future team)

    Milestone 1โ€‹

    Please add additional milestones in the same way:

    • Estimated Duration: Duration of milestone 1
    • FTE: 4 weeks
    • Costs: 9000 USD(may be changed by the future team)
    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationPublic documentation with implementation guides and sample code
    0c.Testing GuideRust Unit tests
    0d.ArticleArticle explaining how to utilize the socks5 support
    1.Middleware layerIn order to enable socks5 support, several modifications of the WsTransportClientBuilder needs to be implemented, described in issue #1162
    2.Socks5 supportenable a jsonrpsee client to proxy connections using a socks5 proxy

    Demonstrationsโ€‹

    • Connect to a .onion rpc node with jsonrpsee.
    - + \ No newline at end of file diff --git a/docs/RFPs/ksm-tipping-button.html b/docs/RFPs/ksm-tipping-button.html index b92e5fa2636..ab449a4acc7 100644 --- a/docs/RFPs/ksm-tipping-button.html +++ b/docs/RFPs/ksm-tipping-button.html @@ -4,13 +4,13 @@ Tip or Donate KSM Embeddable Button | Web3 Foundation Grants - +

    Tip or Donate KSM Embeddable Button

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    This is a request for proposals to build an embeddable self-contained "Propose tip or Donate KSM" button for websites.

    The applying team is more than welcome to apply through open grants, or the Kusama Treasury itself.

    The Tipping Systemโ€‹

    Most Substrate-based chains like Polkadot and Kusama have an on-chain treasury. This treasury is filled from transaction fees, slashes, inflation, and donations. The treasury supports three different disbursement mechanisms: proposals, bounties, and tips. This RFP deals with Tips.

    Anyone can propose a tip. The proposer becomes the finder, and receives a small fee if the tip is accepted. The Council votes on the tip by members seconding it with an arbitrary amount. The final amount to pay out is the median of all the amounts given by all Council members.

    The tip begins its closing process (a countdown) when more than a half of councilors have seconded a tip. During this countdown, the remaining members can still submit their tips, but don't have to. After the countdown has elapsed, the close_tip extrinsic has to be called (by anyone) to perform the actual payout.

    Proposalโ€‹

    The Kusama Tip Button should be a standalone embeddable snippet of HTML and JS code. When added to a website, a "Tip or Donate KSM" button should show, text customizable by website owner.

    Before the user interacts with the button, the button's embedded code should:

    1. Sanitize the current URL (remove UTM, hashes, alphabetically order query params, etc.)
    2. Convert this URL to bytes
    3. Check if a tip for the same URL already exists and IS ACTIVE (past tips for the same URL are OK)
      • if yes, grey out button and make it unavailable with the text "Tip already pending - click to see", linking to http://kusama.dotapps.io/#/treasury/tips (text customizable by website owner)
      • if no, button is available.

    Once clicked, the button should:

    • ask for permission to connect to PolkadotJS extension
      • if none is present, offer to install it (take user to Github page)
      • if allowed, a popup appears asking to "select an account"
      • if denied, cancel all
    • offer two options: Propose Tip and Donate Directly (text customizable by website owner)
      • Propose Tip
        • clearly inform visitor that they need to have enough funds for both a fee AND a deposit, and that they will only get the deposit back after the tip has been paid out, which doesn't have to ever happen.
        • if current user is a Council member, ask for amount and then create a new Tip entry with treasury.tip_new
        • if current user is not in Council, create a new Tip entry with treasury.report_awesome.
        • Optionally allow visitor to attach a message. If provided, use utility.batch to batch the tip creation with system.remark. Final system remark is: "Tip for URL: MESSAGE FROM TIPPER".
        • re-execute "tip exists" check to disable button and link to Tips page in treasury
      • Donate
        • ask visitor for amount
        • wrap Transfer in utility.batch function along with a system.remark. (not optional, always wrap)
        • allow visitor to enter a custom note
        • final system remark is "Donation for URL: MESSAGE FROM TIPPER".

    Challengesโ€‹

    Performanceโ€‹

    Websites must not be notably slowed down by this implementation. This is especially challenging because the button's code needs to do some checking well before a visitor interacts with it. Gating the approach more (i.e. behind an additional "Tipping" button) would degrade UX, especially if the click requires a long load and check time before even allowing progress into the Tip or Donate area.

    Ideally, the code would be a minimal extraction of PolkadotJS API, or even slimmer standalone version, which could do the check painlessly. The tipping code itself can then be bigger and be async loaded only once a visitor interacts with the button. We assume the vast majority of users never will, so this is an acceptable tradeoff, but we welcome creative solutions to this problem.

    Tip Spamโ€‹

    It is reasonable to assume that highly popular websites will, in time, have many users wanting to create tips for them. The tip-existence check helps with that, but it does not help with minor URL modifications (i.e. no-effect query params) or tipping every page on a website.

    The fee and deposit to create a Tip should take care of this problem.

    - + \ No newline at end of file diff --git a/docs/RFPs/move_smart_contract_pallet.html b/docs/RFPs/move_smart_contract_pallet.html index 36e3d1410b9..bf04d088561 100644 --- a/docs/RFPs/move_smart_contract_pallet.html +++ b/docs/RFPs/move_smart_contract_pallet.html @@ -4,13 +4,13 @@ Move Smart Contract Pallet | Web3 Foundation Grants - +

    Move Smart Contract Pallet

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    Project Description ๐Ÿ“„โ€‹

    The Move Virtual Machine (MoveVM) was initially developed by Facebook and is now maintained by the Aptos Foundation. Move is a smart contract programming language that emphasises access control and scarcity.

    Pontem Network initially developed the Move virtual machine pallet to execute Move smart-contracts on Substrate-based chains. However, they stopped working on this pallet to focus on other initiatives.

    The purpose of this RFP is to find other teams that are willing to pick up this initial work and continue with it or work on their own implementation of the Move virtual machine in Substrate.

    Useful resources:

    Deliverablesโ€‹

    The structure of the grant and the milestones depends highly on the project itself. Itโ€™s therefore up to the applying team to come up with a milestone and delivery structure.

    - + \ No newline at end of file diff --git a/docs/RFPs/multi-chain-block-explorer.html b/docs/RFPs/multi-chain-block-explorer.html index 9e714f60bf8..8877b79a7ed 100644 --- a/docs/RFPs/multi-chain-block-explorer.html +++ b/docs/RFPs/multi-chain-block-explorer.html @@ -4,13 +4,13 @@ Multi-chain Block Explorer | Web3 Foundation Grants - +

    Multi-chain Block Explorer

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    As parachains become an integral part of the Polkadot and Kusama ecosystems, a cross-chain block & accounts explorer becomes all the more useful.

    Some of the functionality that should be covered as part of the development:

    • select which chains to view (e.g. default when selecting Kusama is Kusama relay + all its parachains). Should be feasible to select alternative mainnets too.
    • input an address and see Tx's on all the selected mainnets, including teleports/XCMs between various parachains
    • when a Tx includes a XCM, it should be easy and intuitive to open the relevant block from the other chain(s).
    - + \ No newline at end of file diff --git a/docs/RFPs/on-chain-quadratic-funding.html b/docs/RFPs/on-chain-quadratic-funding.html index 469141bebea..af06e79aff3 100644 --- a/docs/RFPs/on-chain-quadratic-funding.html +++ b/docs/RFPs/on-chain-quadratic-funding.html @@ -4,13 +4,13 @@ On-chain Quadratic Funding | Web3 Foundation Grants - +

    On-chain Quadratic Funding

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    CLR, short for Constrained Liberal Radicalism algorithm, commonly called quadratic funding (QF), is a way to efficiently fund projects in the Web3 ecosystem. The way it works is that users contribute directly to projects which they value and in doing so, help the projects earn a share of a matching pool of funds. The number and amount of each contribution influences the total amount allocated to a project. This means even a small contribution is valuable and can result in a high matched amount.

    Gitcoin is currently using this mechanism to successfully fund and support public goods. However, Gitcoin is centralized. The goal of this RFP is to develop a decentralized solution on top of Substrate, which can potentially be integrated into Kusama, Polkadot or any other Substrate-based chain as a pallet. The on-chain treasury could potentially sustainably fund the matching pool in the long-run. However, the Web3 Foundation would also be committed to fund a matching pool of the solution for initial test rounds.

    Key-problems to solve as part of the grant:

    1. Anti-collusion
    2. Sybil resistance
    3. User-friendly UI

    Deliverables ๐Ÿ”ฉโ€‹

    The milestones below are just an initial draft. The milestones can be structured completely differently and the implementation can also leverage other tools and infrastructure as long as the overall goal of the RFP is met.

    Milestone 1 - Sybil resistanceโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationInline documentation of the code and a basic tutorial that explains how a developer can use the project
    0c.Testing GuideThe code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialArticle or tutorial that explains the work done as part of the grant.
    1.Sybil resistanceMechanism to prevent Sybil attacks, either implemented as its own Substrate pallet or possible integration of the existing on-chain identity on Kusama/Polkadot provided by specified registrar
    2.UIUI for verification of identities, including a polkadot.js extension support

    Milestone 2 - CLRโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationInline documentation of the code and a basic tutorial that explains how a developer can use the project
    0c.Testing GuideThe code will have unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialArticle or tutorial that explains the work done as part of the grant.
    1.CLR pallet(s)Implement the necessary substrate pallets, potentially containing a Token Curated Registry (TCR) to allow anyone to permissionlessly register eligible recipients each round and DAO to govern the protocol.
    2.Off-chain StorageIntegrate an off-chain storage solution, for example IPFS for storing the applications and information about the grants
    2.Test 1Set up a test network and leverage the extrinsics tabs of polkdaot.js to test the implementation and improve it. The Web3 Foundation provides a small matching pool as a incentive.

    Milestone 4 - UIโ€‹

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationInline documentation of the code and a basic tutorial that explains how a developer can use the project
    0c.Testing GuideThe code will have unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests
    0d.Article/TutorialArticle or tutorial that explains the work done as part of the grant.
    1.CLR UIUI for the whole process (creation and funding of grants), including polkadot.js extension support.
    2.Test 2Test the newly created UI. The Web3 Foundation provides another small matching pool as a incentive.
    - + \ No newline at end of file diff --git a/docs/RFPs/parachain_validation_conformance_testing.html b/docs/RFPs/parachain_validation_conformance_testing.html index 5e37b71767b..abae8d07c48 100644 --- a/docs/RFPs/parachain_validation_conformance_testing.html +++ b/docs/RFPs/parachain_validation_conformance_testing.html @@ -4,14 +4,14 @@ Parachain Validation Conformance Testing | Web3 Foundation Grants - +

    Parachain Validation Conformance Testing

    tip

    This Request for Proposal is currently open, meaning we are actively looking for (additional) teams to apply for it.

    • Status: Open
    • Proposer: bkchr

    Project Description ๐Ÿ“„โ€‹

    Each Polkadot host implementation that wants to take part in consensus needs to implement the Parachains protocol. Part of the Parachains protocol is the execution of the Parachain Validation Function (PVF). The PVF is a wasm blob that is required to provide the validate_block function that takes a fixed set of arguments (part is the proof of validity from a collator), validates the proof of validity and returns (on success) some information back to the Polkadot host implementation. The PVF is a black box for the Polkadot node and it can only use the validate_block to make use of it. The execution of these PVFs is required to stay in certain limits to reach consensus across different node implementations, node versions, different hardware configuration and OS configurations. Some of these limits are:

    • A deterministic maximum stack depth. All node implementations should support the same stack depth.
    • A deterministic maximum memory. All node implementations should support the same maximum memory usage per PVF execution.
    • A deterministic maximum execution time. All node implementations should execute a given PVF in the same maximum time frame.
    • A deterministic compilation/preparation of the PVF. All node implementations should compile/prepare a given PVF in the same maximum time frame and maximum memory budget.

    There are probably a lot of other limits as well. To ensure that all node implementations/versions are staying in these limits it is required to have conformance tests. These should include basic execution of valid wasm files over to complex wasm files that ensure that the compilation/preparation stays in the given limits and/or helps to define these limits properly across different implementations.

    Useful resources:

    Deliverables ๐Ÿ”ฉโ€‹

    • Basic conformance tests that are running valid wasm files
    • Conformance tests that are resulting in running over the limits.
    • Fuzzing across different implementations ensuring that all are coming to the same result

    This is more some never ending task trying to find issues in different implementations, getting them fixed and searching for new vulnerabilities. In the end these tests should ensure that updating wasm engines, introducing new node implementations etc can be done in a sane way without hoping for the best.

    - + \ No newline at end of file diff --git a/docs/RFPs/php-api.html b/docs/RFPs/php-api.html index cbdd9f77ae2..1472dc70a21 100644 --- a/docs/RFPs/php-api.html +++ b/docs/RFPs/php-api.html @@ -4,13 +4,13 @@ PHP Substrate API | Web3 Foundation Grants - +

    PHP Substrate API

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    The Substrate API is currently most developed in TypeScript and Rust. This RFP is looking for teams willing to implement a PHP version, perhaps in tandem with the PHP SCALE Coded (see relevant RFP).

    The PHP API should:

    • be able to hook into a running Substrate node via WS or HTTP
    • read and write to RPC endpoints (will need SCALE codec - see relevant related RFP)

    Optionally, the API should support types as exposed by the API. Supporting types is a long term project as those evolve constantly and differ from chain to chain, so if this road is taken by the applying team, it should be stated in a separate milestone and well defined in added maintenance time and cost (i.e. this is not something that can be delivered once - it would require a long term commitment).

    Deliverables ๐Ÿ”ฉโ€‹

    The basic deliverable of this project is an API package hosted on Packagist which can instantiate a connection to a Substrate node and talk to constants, chain storage, and RPC endpoints. For inspiration, see the JS version: https://polkadot.js.org/docs

    Example use:

    • reading from RPC
    $api = new SubstrateApi\Api("websocket_or_http_url");
    echo $api->rpc->system->chain(); // Kusama
    • writing a tx:
    $api = new SubstrateApi\Api("websocket_or_http_url");
    $signer = new SubstrateApi\Keyring\Signer("privatekey");
    $api->setSigner($signer);
    $tx = $api->tx->balances->transfer("recipient_address", 10000);
    $tx->signAndSend();

    Notesโ€‹

    - + \ No newline at end of file diff --git a/docs/RFPs/php-scale.html b/docs/RFPs/php-scale.html index 9b966710c8c..9c584e154d6 100644 --- a/docs/RFPs/php-scale.html +++ b/docs/RFPs/php-scale.html @@ -4,13 +4,13 @@ PHP Version of SCALE Codec | Web3 Foundation Grants - +

    PHP Version of SCALE Codec

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    The SCALE codec is the de-factor encoding method in Substrate-based chains. It is necessary for APIs to be able to communicate with a running node. There are several implementations already available in the wild, all listed here. This proposal is for a team to build a PHP version.

    Deliverables ๐Ÿ”ฉโ€‹

    The deliverable should be a standalone SCALE codec package, hosted on Packagist. It can (but does not have to) depend on existing Base58 packages already present on Packagist.org.

    The package can also be delivered as a companion PHP extension but the extension should be exclusively a performance upgrade to the existing package. In other words, the Packagist-installable library should work on its own, but can be improved by also downloading the (optional) PHP extension. If the applicant decides to also create the extension, they should submit it as a separate milestone.

    - + \ No newline at end of file diff --git a/docs/RFPs/polkadot-collator-setup.html b/docs/RFPs/polkadot-collator-setup.html index 82a0a2279dd..4a849491f90 100644 --- a/docs/RFPs/polkadot-collator-setup.html +++ b/docs/RFPs/polkadot-collator-setup.html @@ -4,14 +4,14 @@ Polkadot Collator Setup | Web3 Foundation Grants - +

    Polkadot Collator Setup

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    This is meant as a companion repository to polkadot-validator-setup, which allows anyone to launch a validator node in an automated and secure fashion.

    I would like to standardize (as much as possible) the process of spinning up new collator nodes for different parachains.

    I understand it might be tricky to bundle all the parachain launch setups into one repository, but there are some ideas of how this can be tackled:

    1. Have a single collator ansible role, and each branch would correspond to a specific parachain
    2. Have multiple ansible roles, and the main.yml in the project root to coordinate which roles get deployed.

    I would lean towards the second option. While it might lead to large repo size due to multiple collator setups (and multiple networks - the setup might be different on Kusama or Polkadot), it gives more flexibility to spin up multiple collators for independent chains without meddling with git branching too much.

    Deliverables ๐Ÿ”ฉโ€‹

    Ideally the PoC would Please list the deliverables of the project in as much detail as possible. Please also estimate the amount of work required and try to divide the project into meaningful milestones.

    • Total Estimated Duration: Duration of the whole project
    • Full-time equivalent (FTE): Amount of time (in days) required for a single person to complete this project (see)
    • Total Costs: Amount of Payment in USD for the whole project.

    Milestone 1โ€‹

    Please add additional milestones in the same way:

    • Estimated Duration: Duration of milestone 1
    • FTE: Amount of time (in days) required for a single person to complete this milestone
    • Costs: Amount of Payment in USD for milestone 1
    NumberDeliverableSpecification
    1.Title of the deliverablePlease describe the deliverable here as detailed as possible
    2.......
    - + \ No newline at end of file diff --git a/docs/RFPs/polkadot-protocol_conformance_tests.html b/docs/RFPs/polkadot-protocol_conformance_tests.html index 100c69f529a..de61c3bf350 100644 --- a/docs/RFPs/polkadot-protocol_conformance_tests.html +++ b/docs/RFPs/polkadot-protocol_conformance_tests.html @@ -4,13 +4,13 @@ Polkadot Protocol Conformance Tests | Web3 Foundation Grants - +

    Polkadot Protocol Conformance Tests

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    Project Description ๐Ÿ“„โ€‹

    The reliability and security of the Polkadot network crucially depends on bug-free implementation of Hosts/Nodes. Currently, Substrate and Smoldot (in Rust) are implementations in production, while Gossamer (in Go) and Kagome (in C++) are in advanced stages of development. This RFP invites teams to create and maintain a comprehensive test-suite to check conformance of Host implementations against the official Polkadot Protocol Specification.

    The objectives are multifold. The test-suite can:

    • be used to objectively evaluate the conformance of a Host Implementation against the Spec.
    • help implementers in early stages and steer their development efforts.
    • complement the specifications to clarify corner cases and intricacies of the Spec. In several scenarios, precise tests are highly valuable in clarifying the inevitable ambiguities in the Spec.

    Initially, the focus would be on unit tests with tests designed and generated at the right layer of abstraction to accommodate the existing implementations. The scope of the test-suite covers all the components/protocols described in the Specification but we would like to prioritise the following:

    • Mapping the consensus attack surface and producing fuzzing targets accordingly. An indicative, non-exhaustive list of potential targets:
      • Host API
        • Sequences of storage and child-storage operations
        • Cryptography primitives, particularly those exposed in the Host API
        • Trie root
      • BABE
        • Block import
        • Block validation
        • Next/current validators aka VRF/block lottery
        • Secondary slot verification
      • GRANDPA
        • Block import
        • Block validation
        • Justification import & validation/verification
    • Trie proof verification
    • Scale encoding and decoding, for specific message types, and randomly generated ones
    • Parachain candidate validation

    The goal of the initial grant should be to develop a PoC. The long-term goal should be to develop a comprehensive test suite that is funded by the on-chain treasury.

    Useful resources:

    Deliverablesโ€‹

    The structure of the grant and the milestones depends highly on the project itself and the goal of the initial PoC. Itโ€™s therefore up to the applying team to come up with a milestone and delivery structure.

    - + \ No newline at end of file diff --git a/docs/RFPs/privacy-enhancement-polkadot-extension.html b/docs/RFPs/privacy-enhancement-polkadot-extension.html index 2b0ebb61ec9..270a69d3ae2 100644 --- a/docs/RFPs/privacy-enhancement-polkadot-extension.html +++ b/docs/RFPs/privacy-enhancement-polkadot-extension.html @@ -4,13 +4,13 @@ Privacy Enhancement for Polkadot Extension | Web3 Foundation Grants - +

    Privacy Enhancement for Polkadot Extension

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    An increasing number of websites require access to the Polkadot extension with a growing ecosystem. By allowing access to the extension, websites (naturally) can see the addresses that are contained in the extension. This imposes a big risk to privacy, because malicious actors could create lists about which addresses belong to one entity and, in the worst case, even link it to real-world identities (if at least one address is linked to an on-chain identity). A feature to prevent this is currently the "hide" button on single addresses, which prevent websites from seeing that address. However, it is currently cumbersome to handle that feature. The idea of this RFP is to extend on that feature and include a few QOL functionalities to make it easier for users to protect their privacy.

    Deliverables ๐Ÿ”ฉโ€‹

    As outlined here, the deliverable should include five features to the extension and a successful completion of this RFP includes a merge of a PR to the main polkadot-js/extension repo. It is of great importance to generate clean code that follows best-practices.

    • Total Estimated Duration: 1 month
    • Full-time equivalent (FTE): Amount of time (in days) required for a single person to complete this project (see)
    • Total Costs: $10'000.

    Milestone 1โ€‹

    • Estimated Duration: 1 month
    • FTE: Amount of time (in days) required for a single person to complete this milestone
    • Costs: $10'000
    NumberDeliverableSpecification
    1."Hide all"A global button that hides/un-hides all addresses
    2."View-Groups"Create and name groups which a user can organize their accounts to. For example, a "polkadot-js" group could unhide all accounts, while a "Parachain X" group only unhides those accounts a user knows that they have those parachain tokens on.
    3."Privacy Mode"A setting that automatically changes the extension to a specific view group (which could be "hide all").
    4."Hide from Extension"A feature that lets users hide addresses in the extension itself. This is useful for doing demos or presenting the screen. Those accounts are listed in a special tab and can be unhidden from there.
    5."Link View-Groups to URLs"The extension already features an access control to specific URLs. To add on that, the extension could automatically switch to a defined view-group when entering an URL. Building on that, upon first authorization of a website, the extension could ask which view-groups to add it to or offer to create a new one.
    - + \ No newline at end of file diff --git a/docs/RFPs/raft-validators.html b/docs/RFPs/raft-validators.html index 33da2b4b8de..74ca8b04214 100644 --- a/docs/RFPs/raft-validators.html +++ b/docs/RFPs/raft-validators.html @@ -4,14 +4,14 @@ High-availability validator setup | Web3 Foundation Grants - +

    High-availability validator setup

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    • Status: Implemented
    • Proposer: mmagician
    • Projects you think this work could be useful for: Polkadot & Kusama Validators

    Project Description ๐Ÿ“„โ€‹

    Summaryโ€‹

    Validator leader selection via Raft consensus. Inspired by internal discussions & certus.one active-active validator setup.

    Present stateโ€‹

    Currently, the recommended setup is to have one active node per validator. The main advantage of this approach is that it removes the danger of equivocation, thus preventing slashing. The key drawback is the lack of a ready backup machine to takeover the responsibility of producing blocks, voting on finality etc. in case the primary one fails.

    The drawback can be somewhat remedied by having a backup node in sync, but without access to the session keys necessary for authoring blocks. The process of replacing the keys, however, is manual. Furthermore, the session keys cannot be replaced mid-session and this introduces a time delay for when the validator is active again.

    Solutionโ€‹

    Rather than relying on one validator node to perform the work, what if we had multiple nodes equally capable of signing messages, yet still avoiding the risk of equivocation? The proposed approach relies on recognising a distinction between signing a message and submitting it.

    Since all our validator nodes are trusted and we don't worry about censorship resistance, we can leverage a leader-follower model to ensure high availibility. Raft is a good candidate - it offers a simple consensus mechanism, fault-tolerance and performance. It ensures only one leader is ever in charge of interacting with the blockchain, while the followers simply receive the state updates and automatically replace the leader in case of a failure.

    Deliverables ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 3 months
    • Full-time equivalent (FTE): 1
    • Total Costs: 30,000 DAI

    Milestone 1 - Block production PoCโ€‹

    The main goal of the PoC is to add a switch to the substrate node which allows it to decide whether it's a valid block producer or not (i.e. to execute the BABE protocol). The concept could be analogous to the remote signing feature, in that the node could reach out to an endpoint (local or remote) which tells it whether the node is allowed to author new blocks.

    The service should contain only basic logic (e.g. return true for node0 and return false for node1 & node2).

    • Estimated Duration: 1 month
    • FTE: 1
    • Costs: 10,000 DAI
    NumberDeliverableSpecification
    1.Basic serviceCreate a microservice (to run locally or remotely) that accepts connections from the substrate node.
    2.Microservice logicHardcoded logic for deciding which node is the leader
    3.Update substrate clientModify the substrate code to reach out to a remote service for receiving permission (or not) for submitting blocks
    4.Allow as optionalThe choice of using an outside decision making agent for block submission should be configurable in the cli
    5.Integration testA dockerised setup that allows to test the developed PoC

    Milestone 2 - Voting & liveness PoCโ€‹

    Similar to the previous milestone, but concerning other validator jobs, namely voting on finalised blocks (GRANDPA) and communicating liveness (I'm online)

    • Estimated Duration: 2 weeks
    • FTE: 1
    • Costs: 5,000 DAI
    NumberDeliverableSpecification
    1.Update substrate client - finalisationModify the substrate code to reach out to a remote service for receiving permission (or not) for submitting votes for finalised blocks (GRANDPA)
    2.Update substrate client - I'm onlineModify the substrate code to reach out to a remote service for receiving permission (or not) for submitting I'm online messages

    Milestone 3 - Raft consensusโ€‹

    Replace the dummy microservice with a Raft consensus mechanism, responsible for leader selection.

    Each node should integrate a Raft client in its code. A good candidate is tikv-client. It should be able to push/receive information on what the latest authored block is (persistent data storage) & act accordingly.

    • Estimated Duration: 1 month
    • FTE: 1
    • Costs: 10,000 DAI
    NumberDeliverableSpecification
    1.Run the necessary Raft servicesAdd a key-value (or other) store binaries that follows a Raft consensus. They should run alongside the validator code
    2.Integrate a Raft client into the nodeExtend the block submission logic to allow only Raft-selected leader as a valid block submitter
    3.Integration testA dockerised setup that allows to test the Raft consensus mechanism

    Milestone 4 - Production readinessโ€‹

    Take the previous developments to a state where it's ready to be deployed in production as part of a Polkadot/Kusama validator setup.

    • Estimated Duration: 2 weeks
    • FTE: 1
    • Costs: 5,000 DAI
    NumberDeliverableSpecification
    1.SecurityMake sure that a firewall and proper networking is in place
    2.MonitoringFeed the Raft consensus data into Prometheus and display basic info in Grafana.
    3.Validator setup integrationIntegrate the above into one of the validator-setup repositories (e.g. https://github.com/w3f/polkadot-secure-validator)

    Future plansโ€‹

    At some point, BABE will be replaced with Sassafras (see 37 & 4600) which is likely going to affect the operation of the Raft consensus and thus should be addressed.

    Furthermore, there are plans for developing additional mechanisms for validator slashing protection (see 7398). In particular:

    • the leader might need to perform an on-chain key registration upon being appointed.
    • followers never increment counters nor generate new tags (unless being promoted)

    This high availability setup, when adapted, should still make conceptual sense, because its main purpose is ensuring redundance and quick replacement of the main node & as such will not interfere with the extended key registration proposed in the mentioned issue.

    - + \ No newline at end of file diff --git a/docs/RFPs/scale-codec-comparator.html b/docs/RFPs/scale-codec-comparator.html index 4e09a5cdec0..c554ac54245 100644 --- a/docs/RFPs/scale-codec-comparator.html +++ b/docs/RFPs/scale-codec-comparator.html @@ -4,14 +4,14 @@ SCALE Codec Comparator | Web3 Foundation Grants - +

    SCALE Codec Comparator

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    To date, there are 9 published implementations of the SCALE Codec. Since each is implemented by a different team & the reference implementation still introduces small fixes, it would be beneficial to compile a table of feature-completeness. This would provide (some) assurance that the implementation in a given language is safe & sound to use.

    One approach would be to provide wrappers to the Rust reference implementation, like in scale.rb and using the Foreign Function Interface (e.g. here) to call these directly from within the library.

    Stage 2: To take this a step further, a GitHub action could be integrated to run all native unit tests also against the Rust lib. For repos which provide feature completeness & pass all relevant tests, a SCALE specific badge could be awarded.

    Deliverables ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 2+ months
    • Full-time equivalent (FTE): 1
    • Total Costs: ~ 12,000 DAI

    Milestone 1: Feature-completeness & FFI to Rustโ€‹

    • Estimated Duration: 2 months
    • FTE: 1
    • Costs: ~ 10,000 DAI

    For each library listed on substrate.dev:

    • Create a PR, providing a FFI to Rust's reference implementation.
    • Ensure feature completeness, by ensuring there are comprehensive unit tests for each data type.

    Milestone 2: Badge integrationโ€‹

    • Estimated Duration: 1 week

    • FTE: 1

    • Costs: ~ 2000 DAI

    • Create a GitHub badge for SCALE feature complete libs

    • Ensure that each lib listed above has the process of publishing the badge integrated into the CI workflow (e.g. GitHub action to run tests & award badge on successful run)

    Note: The goal is to have your changes merged upstream. While the final decision is taken by the repo owners, you should make sure that your PRs pass all checks specific to each lib, conforms to their contributing guidelines etc.

    - + \ No newline at end of file diff --git a/docs/RFPs/social-recovery-wallet.html b/docs/RFPs/social-recovery-wallet.html index 4b347ce4fca..f85192ab437 100644 --- a/docs/RFPs/social-recovery-wallet.html +++ b/docs/RFPs/social-recovery-wallet.html @@ -4,13 +4,13 @@ Social Recovery Wallet | Web3 Foundation Grants - +

    Social Recovery Wallet

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    Managing your own private keys is a difficult task. The average person doesnโ€™t want to spend multiple hours to ensure the security of their keys. This leads to people having difficulties to join the blockchain space or even worse leads to the loss of funds. One solution to this problem is the implementation of a social recovery system. It allows users to recover their accounts if their key or other authentication mechanism has been lost. Therefore you usually set up at least 3 "guardians" (e.g. other devices, friends or family or institutions), of which a majority can cooperate to change the key of the account (often after some delay). Kusama has for this purpose currently the social recovery pallet implemented.

    The goal of this RFP is to find teams that are willing to leverage this or similar mechanism to create wallet solutions (desktop, web, mobile, extensions, etc.) which are as easy to use as possible and at the same time offer a high security for the average user.

    Apart from the social recovery pallet, the support of the Proxy Module and Multisig Module is encouraged as part of this RFP to further improve the user experience.

    Existing Social Recovery Wallets on Ethereum:

    Other interesting sources:

    Deliverables ๐Ÿ”ฉโ€‹

    The deliverables highly depend on the exact wallet implementation and therefore arenโ€™t further described as part of this RFP. For the grant application you should take a look at the application template and try to specify the deliverables as detailed as possible.

    - + \ No newline at end of file diff --git a/docs/RFPs/staking-rewards-collector-front-end.html b/docs/RFPs/staking-rewards-collector-front-end.html index 731f8afab1e..a40343f4692 100644 --- a/docs/RFPs/staking-rewards-collector-front-end.html +++ b/docs/RFPs/staking-rewards-collector-front-end.html @@ -4,13 +4,13 @@ Front-End for Staking Rewards Collector | Web3 Foundation Grants - +

    Front-End for Staking Rewards Collector

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    • Status: Implemented: Repo 1, finished, Repo 2, in progress
    • Proposer: JonasW3F
    • Your Project(s): -
    • Projects you think this work could be useful for Staking operations of all nominators and validators.
    • Teams/People that could deliver the RFP -

    Project Description ๐Ÿ“„โ€‹

    The staking-rewards-collector is a tool to gather staking rewards for given addresses and cross-reference those with daily price data. This is a very useful tool for every validator and nominator in the ecosystem. However, since it has currently a CLI and requires some technical knowledge to set up (git, nodejs, yarn). A front-end hosted on a website could help many users getting access to this tool and enjoy the benefits.

    The backend is already written in javascript, this should make it quite easy to host as a website and develop a front-end.

    Deliverables ๐Ÿ”ฉโ€‹

    In order to apply for the project, we will require you to propose the design in the form of mock-ups.

    • Implementation of a user interface:

      • Query input parameters (from the users):

        • Addresses (multiple ones are supported by the code).
        • Start and end date
        • Does the user want price data linked to staking rewards?
        • What are the startBalances of each address?

      • Data output viewer:

        • The code produces a .csv and .json file which should be displayed in the browser.
        • Visualization for the varying number of input addresses.
        • Some sorting based on network / amount.
        • Search for specific entries like dates.
        • Option to download to local storage.

      • Help page / buttons:

        • Both the input query and output viewer should have several help buttons to give explanations for all users.

    • Compatibility:

      • It should be easy to extend the underlying script and the UI should be flexible enough to incorporate that (e.g., adding another column in the data output).

    • Hosting

      • Centralized and preferably decentralized (IPFS).

    • Testing

      • Test if the code behaves as expected.
    • Total Estimated Duration: 3 Weeks
    • Full-time equivalent (FTE): 15 days
    • Total Costs: 4000 USD (provisional)

    Milestone 1 (Implementation)โ€‹

    • Estimated Duration: 9 days
    • FTE: 9
    • Costs: 3500 USD
    NumberDeliverableSpecification
    1.UI for user inputDevelop an UI to request necessary data from the users.
    2.UI for data visualizerDevelop an environment to display the output (.csv and .json) for the end user in a pleasurable way.
    3.Help pages / commentsImplement help texts and descriptions for users.
    4.Internal testingUnit tests covering the functionality and logic

    Milestone 2 (Testing)โ€‹

    • Estimated Duration: 3 days
    • FTE: 3 days
    • Costs: 500 USD
    NumberDeliverableSpecification
    1.DeploymentDeploy the code on a centralized server and IPFS.
    2.Test live environmentTest the homepage with various different OS and browsers and provide a report
    3.PolishingReach out for feedback to the Grants Team. Integrate final feedback on functional, as well as cosmetic changes like font size, colors, typos etc.
    - + \ No newline at end of file diff --git a/docs/RFPs/sub-consensus.html b/docs/RFPs/sub-consensus.html index 7768b0dffef..540a3175773 100644 --- a/docs/RFPs/sub-consensus.html +++ b/docs/RFPs/sub-consensus.html @@ -4,7 +4,7 @@ Sub-consensus mechanism | Web3 Foundation Grants - + @@ -12,7 +12,7 @@

    Sub-consensus mechanism

    tip

    This Request for Proposal is currently open, meaning we are actively looking for (additional) teams to apply for it.

    • Status: Open
    • Proposer: mmagician, laboon
    • Projects you think this work could be useful for: All parachains

    Project Description ๐Ÿ“„โ€‹

    Summaryโ€‹

    Parachain dApps suffer from long confirmation times due to the time taken for the Relay Chain to issue an on-chain verification of the parachain blocks. This proposal aims at providing an alternative mechanism for providing parachain users with an alternative, probabilistic sub-consensus mechanism.

    Project Detailsโ€‹

    Currently the time taken from collator producing a block on a parachain, to that block becoming finalised, is prohibitive to some applications deployed on the parachain. What we'd like to introduce is a mechanism for parachain collators to achieve consensus among themselves on the "best" block. This mechanism would most likely be realised as an additional runtime module in which all collators can (but don't have to) participate, thus providing a faster way for the users of parachain applications to see quasi-finalised blocks -> note that this sub-consensus on parachains will have no effect on the decision of relay chain validators' votes and can at times diverge from the outcome on the relay chain. Should this mechanism be opt-in for collators, they could be incentivised to participate honestly by bonding a small stake, that is later slashed (the stick) in case a relay-chain-finalised-block causes a reorg on the sub-consensus mechanism. Conversely, the carrot would be a small reward paid out by the parachain governance (tied to the decision by that governance to include such a module)

    Deliverables ๐Ÿ”ฉโ€‹

    • Total Estimated Duration: 3 months
    • Full-time equivalent (FTE): 1
    • Total Costs: 40,000 DAI

    Milestone 1 - Research and technical specificationโ€‹

    • Total Estimated Duration: 2 months
    • Full-time equivalent (FTE): 1
    • Total Costs: 20,000 DAI

    While normally the Grants Program doesn't fund the research phase, in this case a comprehensive write-up should proceed the implementation and should be subject to acceptance.

    At the end of the milestone, a detailed document should contain, at a minimum, the following parts:

    • summary of the current technical implementation and its limitations
    • technical proposal, including full specification of any pallets needed, as well as necessary changes (if any) to upstream substrate/cumulus repositories
    • security analysis of the proposed solution
    • summary of adoption of the proposed solution by a parachain team (either case study or general guidelines)

    Milestone 2 - PoCโ€‹

    • Total Estimated Duration: 2 months
    • Full-time equivalent (FTE): 1
    • Total Costs: 20,000 DAI

    A proof of concept implementation of the proposed solution, or a full-fledged delivery. The scope of this milestone is highly dependant on the proposal submitted in M1.

    - + \ No newline at end of file diff --git a/docs/RFPs/uncollateralized-stablecoin-research.html b/docs/RFPs/uncollateralized-stablecoin-research.html index 38cacaf258f..fa00edb9176 100644 --- a/docs/RFPs/uncollateralized-stablecoin-research.html +++ b/docs/RFPs/uncollateralized-stablecoin-research.html @@ -4,13 +4,13 @@ Uncollateralized Stablecoin Research | Web3 Foundation Grants - +

    Uncollateralized Stablecoin Research

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    • Status: Implemented
    • Proposer: Noc2
    • Projects you think this work could be useful for [optional]: Any Defi Project

    Project Description ๐Ÿ“„โ€‹

    Stablecoins are cryptocurrencies where the price is designed to be pegged (=fixed exchange rate) to a cryptocurrency, fiat money, or to exchange-traded commodities. Seigniorage-style, uncollateralized or algo stablecoin is a token that uses algorithms to control the circulating supply to get a stable value of the asset. In general the price volatility of cryptocurrencies is one of the biggest barriers to widespread adoption. Stablecoins therefore have become a key component of DeFi applications. However, all successful existing stable coins (e.g. DAI, USDT, USDC, etc) are asset backed. Therefore they are subject to the same volatility and risk associated with the backing asset and the underlying process. Some of the potentially issues based on this are:

    • Additional trust assumptions (e.g. USDT)
    • Scalability issues (restricted by the underlying asset)
    • Devalue under massive crashes in the underlying assets

    Purely algorithmic stablecoin would overcome these risks. Additionally it would be fairly simple to peg an algorithmic stablecoin to different assets (USD, EUR) or in the future even to a consumer price index (CPI). However, until now most algorithmic stablecoins introduced significant additional disadvantages or weren't able to maintain their peg for a longer period of time (e.g. AMPL, ESD, DSD, BAC, NuBits).

    The goal of this RFP is to research and create new uncollateralized stablecoin mechanisms and implement these as ink! smart contract or pallets. The biggest research question hereby is how to efficiently decrease the supply of the token.

    Useful resources:

    Deliverables ๐Ÿ”ฉโ€‹

    The milestones below are just an initial draft. The milestones can be structured completely differently and the implementation can also leverage other tools and infrastructure as long as the overall goal of the RFP is met.

    • Total Estimated Duration: 2 month
    • Full-time equivalent (FTE): 1
    • Total Costs: 30k

    Milestone 1 - Research & Designโ€‹

    • Estimated Duration: 1 month
    • FTE: 1
    • Costs: 10k
    NumberDeliverableSpecification
    1.Overview of existing solutionsCreate an overview of existing and previous uncollateralized stablecoin solutions and why they failed.
    2.Increasing SupplyDevelop a mechanism to deal with an increasing demand for the cryptocurrency and analyses potential attack vectors
    3.Decreasing SupplyDevelop a mechanism to deal with an decreasing demand for the cryptocurrency and analyses potential attack vectors

    Milestone 2 - PoC Implementationโ€‹

    Ideally part of a separate follow-up grant, since it depends on the outcome of the initial research!

    • Estimated Duration: 1 month
    • FTE: 1
    • Costs: 20k
    NumberDeliverableSpecification
    1.Implement PoCImplement the previous research as ink! Smart contract or pallets
    2.UI (optional)Implement a basic UI that can be used for testing
    - + \ No newline at end of file diff --git a/docs/RFPs/uptane-for-substrate-design-and-scope.html b/docs/RFPs/uptane-for-substrate-design-and-scope.html index d0f77408f40..d389baca633 100644 --- a/docs/RFPs/uptane-for-substrate-design-and-scope.html +++ b/docs/RFPs/uptane-for-substrate-design-and-scope.html @@ -4,7 +4,7 @@ Designing Upchain: A framework for securing Substrate software update systems | Web3 Foundation Grants - + @@ -14,7 +14,7 @@ A greenfield design should not be accepted.

    Rather, the Milestone 2 document accompanying the design specification should reference:

    Articulating:

    • Deviations
      • The section number and title in the Uptane and TUF specification that Upchain should deviate from.
      • The Relay-parachain functionality lost or gained by this deviation, described in terms of TUF/Uptane functionality
    • Extensions
      • The section number and title in the Uptane and TUF specification that should be extended by Upchain
      • The Relay-parachain functionality removed or added by this extension, described in terms of TUF/Uptane functionality
    • Omissions
      • The section number and title in the Uptane and TUF specification that should be omitted from Upchain
      • The Relay-parachain functionality lost or gained by this omission, described in terms of TUF/Uptane functionality

    Specifically, elements of these two specifications should not silently vanish.

    Contextโ€‹

    The Uptane (ECU update framework for automotives) is chosen as the template to begin with and contrast UpChain for a couple of reasons:

    • The specification should explicitly address Parachain scaling, see for example Parachain scaling by Parablock splitting.
    • While ECU updates have client-server model where centrally managed updates are pushed to clients, and upgrade failures must leave a vehicle in a safe and usable state. Substrate upgrades have a single source of truth that also must be pushed to nodes, and upgrade failures must leave a node in a safe and usable state.
    • Further, there are implementations of the Uptane spec that are not trivial and that experience could be expected to inform the design of how UpChain protects Parachain scaling e.g. motivate any deviations or extensions.

    Motivationโ€‹

    Iโ€™ve come across several reports of a para-relay chain update/upgrade going awry and a chain is bricked, unable to produce blocks - hi-jinx ensue, and everyone lives happily ever after.

    One such case is discussed here: How to recover a parachain. The consensus appears to be: Automatic rollback is not possible, and a Parachain being inoperable for some period is the way things will be (hi-jinx required).

    Potential utility for the wider community is evidenced by the Polkadot Summit: Barcamp (30 Nov, 1 Dec) topic Parachain Emergency Recovery

    Deliverables ๐Ÿ”ฉโ€‹

    Upchain Standard for Design and Implementation 1.0.0

    Scopeโ€‹

    The scope of "Designing UpChain" is limited to creating a spec which aims at mitigating/avoiding such upgrade failures.

    Guidelines to triage and recover after the issue occurred will likely depend on the detail of an implementation, hence should be deferred to the implementation phase.

    Scope includes providing recommendations and changes at the protocol level. It also include analysis of performance overheads (e.g., overheads on the blockspace). This may entail involving teams at parity/w3f.

    • Total Estimated Duration: Duration of the whole project
    • Full-time equivalent (FTE): Amount of time (in days) required for a single person to complete this project (see)
    • Total Costs: Amount of Payment in USD for the whole project.

    Milestone 1โ€‹

    • Estimated Duration: Duration of milestone 1
    • FTE: Amount of time (in days) required for a single person to complete this milestone
    • Costs: Amount of Payment in USD for milestone 1
    NumberDeliverableSpecification
    1.Upchain Standard for Design and Implementation 1.0.0The Update Framework Specification extended for Substrate Relay and Parachains

    This deliverable can be valuated by comparing the list of (sub-)sections with those from The Update Framework - there should be no omissions.

    Milestone 2โ€‹

    • Estimated Duration: Duration of milestone 1
    • FTE: Amount of time (in days) required for a single person to complete this milestone
    • Costs: Amount of Payment in USD for milestone 1
    NumberDeliverableSpecification
    1.Upchain: Deviations, Extensions and Omissions from The Update FrameworkAs detailed above, a document setting out all deviations, extensions and omissions from The Update Framework
    - + \ No newline at end of file diff --git a/docs/RFPs/user-account-access-analysis.html b/docs/RFPs/user-account-access-analysis.html index daa6407bdee..e2334212278 100644 --- a/docs/RFPs/user-account-access-analysis.html +++ b/docs/RFPs/user-account-access-analysis.html @@ -4,13 +4,13 @@ User Account Access Security Analysis for Wallets | Web3 Foundation Grants - +

    User Account Access Security Analysis for Wallets

    tip

    This Request for Proposal is currently open, meaning we are actively looking for (additional) teams to apply for it.

    • Status: Open
    • Proposer: Bhargav Bhatt, David Hawig
    • Objectives Security analysis of the user interface of Polkadot Wallets, particularly account access and recovery.

    Project Description ๐Ÿ“„โ€‹

    Security is as strong as its weakest link. More often than not, it's the users (humans) that are the most vulnerable point in the system. This proposal aims to comprehensively analyse the security of user-facing protocols of Polkadot. In particular, Polkadotโ€™s account generation and access is quite complex for users in the ecosystem. Several non-conventional mechanisms for account access like multi-signatures, intent-specific proxies, and social recovery mechanisms provide interesting functionalities but also result in non-trivial user experiences.

    The proposal intends to first formally model the account generation, access, backup, and recovery mechanism for popular Polkadot wallets considering human-interactions as part of the system. Secondly, a comprehensive security analysis (automated or otherwise) is warranted to detect loop-holes in account access by the user, covering features like multi-signatures and anonymous proxies. A systematic technique for modelling and analysing account access is described in the paper 'User Account Access Graphs'. The security analysis should focus on detecting unauthorised access across attack surfaces, and also detect possible scenarios of genuine users being locked-out of the account. This analysis may also lead to detecting redundancies in the authentication process and streamlining the user experience.

    Deliverables ๐Ÿ”ฉโ€‹

    The project is well-suited to be completed as a Bachelor's Thesis/ Master's Thesis/ Internship at an academic institute in collaboration with the Research Team at Web3 Foundation. The deliverables are just a template and can be modified taking into consideration the interests of the appplicant.

    NumberDeliverableSpecification
    0a.LicenseApache 2.0 / MIT / Unlicense
    0b.DocumentationDocument describing the threat model, scope of the analysis, and description of the approach/methodology used.
    1Analysis ReportSecurity analysis report of the current account generation, access, back-up, and restoring mechanism used in popular Polkadot wallets like Polkadot-JS Browser Extension, subkey, Polkadot-JS UI, Parity Signer, Talisman etc. The analysis should also take into consideration features like multi-signatures, stashing, proxies, and anonymous proxies. The analysis includes: 1) sound and complete detection of unauthorised access; 2) minimal counterexamples for exploits if any; 3) lockout risks for users
    2Analysis ReportPossible improvements in usability (e.g., getting rid of redundant authentication layers during restoration) stemming from the analysis should be documented.
    3Models/CodeModels developed to formalise and analyse the different wallets. Code and set-up for automated analysis, if any.
    4EngagementsEngage with the Web3 Foundation teams to validate the correctness of models and the specifications.
    - + \ No newline at end of file diff --git a/docs/RFPs/validator-selection-algorithm.html b/docs/RFPs/validator-selection-algorithm.html index 438c966ab08..d3ac7c25380 100644 --- a/docs/RFPs/validator-selection-algorithm.html +++ b/docs/RFPs/validator-selection-algorithm.html @@ -4,13 +4,13 @@ RFP: Validator Selection Algorithm | Web3 Foundation Grants - +

    RFP: Validator Selection Algorithm

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Descriptionโ€‹

    Together with colleagues from academia, we developed an interactive process for nominations to better find suitable validators and the study is published here. The process is non-opinionated, which means that we do not have any opinion on any validator ex ante. The score of a validator is purely derived by the choices of the nominators.

    After having validated the results in the study, I'd like to see this implemented. For that, we need to set up a proper backend that exposes an API for other services to connect to.

    Deliverables ๐Ÿ”ฉโ€‹

    The aim of this project is only a backend. The final result will be a Python flask application exposing its functionality via RESTful API

    • Functionality:

      • Providing a pair of validators for comparison:
        • Input:
          • previous comparisons
        • Output:
          • next pair
          • current modelโ€™s quality
          • current model
      • Providing a ranking for a given model
        • Input:
          • model
        • Output:
          • ranking of validators
      • Accepting new data
        • Input:
          • validators.csv file that contains information of recent era data from trusted sources

    • Requirements:

      • Linux system with python 3 and listed packages installed
      • 2GB of RAM
      • GPU (optional)
      • Network configuration allowing for communication on a selected port

    • Testing

      • Test if the code behaves as expected.
    • Total Estimated Duration: 6 weeks
    • Full-time equivalent (FTE): 30 days
    • Total Costs: 9000 USD (provisional)

    Milestone 1 (Implementation)โ€‹

    • Estimated Duration: 4 weeks
    • FTE: 20 days
    • Costs: 6000 USD
    NumberDeliverableSpecification
    1.Next pairDevelop an algorithm for efficient calculations of the next pair to be compared to maximize the modelโ€™s information gain.
    2.Ranking calculationDevelop an algorithm calculating a score for each validator
    3.New dataDevelop a function for the data preprocessing
    4.Internal testingUnit tests covering the functionality and logic

    Milestone 2 (Testing)โ€‹

    • Estimated Duration: 2 weeks
    • FTE: 10 days
    • Costs: 3000 USD
    NumberDeliverableSpecification
    1.DeploymentDeploy the code on a provided server.
    2.Test live environmentTest the server efficiency and provide a report
    3.PolishingReach out for feedback to the Grants Team. Integrate final feedback on functional, as well as cosmetic changes like the way data are provided, configuration, etc.
    - + \ No newline at end of file diff --git a/docs/RFPs/validator-setup-maintenance.html b/docs/RFPs/validator-setup-maintenance.html index 258428fa20f..be521c5a784 100644 --- a/docs/RFPs/validator-setup-maintenance.html +++ b/docs/RFPs/validator-setup-maintenance.html @@ -4,14 +4,14 @@ polkadot-validator-setup maintenance | Web3 Foundation Grants - +

    polkadot-validator-setup maintenance

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    • Status: Closed
    • Teams/People that could deliver the RFP: @melozo, @pmensik, @tylerztl, @bLd75

    Project Description ๐Ÿ“„โ€‹

    One of the more accessible ways of spinning up validator nodes is by using the polkadot-validator-setup repository, which uses a mix of terraform and ansible tools to create a server, adjust its configuration and install the necessary packages needed for running a substrate node.

    This RFP aims at providing maintenance to that repository and add some small features. UPDATE: This repo has been archived.

    Deliverables ๐Ÿ”ฉโ€‹

    A list of possible tasks to work on:

    • fixing issues and improving documentation
    • updating any libraries/deps needed
    • support additional terraform backends to store the terraform state (currently only gcp, could add s3: see this issue and local storage or even git - it should be discouraged in prod but very useful for testing). See also this issue
    • investigate pass-phrased ssh key deployment: issue 109
    • add additional cloud providers to terraform: alicloud, OVS
    - + \ No newline at end of file diff --git a/docs/RFPs/wallet-aggregator-library.html b/docs/RFPs/wallet-aggregator-library.html index 777f1731a1f..572e8801523 100644 --- a/docs/RFPs/wallet-aggregator-library.html +++ b/docs/RFPs/wallet-aggregator-library.html @@ -4,13 +4,13 @@ Wallet Aggregator Library | Web3 Foundation Grants - +

    Wallet Aggregator Library

    danger

    This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.

    Project Description ๐Ÿ“„โ€‹

    Users of Polkadot and Substrate-based projects need to connect their wallet to a front-end when using a dApp. At the moment, there are several wallets and browser extensions that can be used (Polkadot-JS, Talisman, Fearless, just to name a few). However, it's common that the frontends don't support all of them, and the users need to install a new wallet or browser extension to connect to the frontend.

    This project aims to create a React library that allows users to connect with any wallet or browser extension to the frontends that adopts it. This way, the users can use the wallet they prefer, and the frontends can support all of them without the need to implement the connection logic for each wallet, just integrating one library (making life easier for developers). Though we would prefer a React library, we would also consider implementations for other libraries as well.

    Deliverables ๐Ÿ”ฉโ€‹

    The following items could be the initial deliverables of the project. Of course, improvements and additions are more than welcome.

    • Initial research:
      • study from the RainbowKit library (which is the same thing, already developed for EVM chains);
      • understand which wallets/extensions can be integrated, what is needed to connect to them, etc.;
    • Library development:
      • various connectors for each wallet;
      • UI components (connect button, account and chain selector, etc.);
    • UI/UX (for both users/devs) improvement:
      • addition of a tool that scaffolds a new project with the wallet connection library (firable, for example, with npm init @user/wallet-aggregator@latest);
      • selective account disclosure implementation (view this RFP).
    - + \ No newline at end of file diff --git a/docs/RFPs/xcm-tool.html b/docs/RFPs/xcm-tool.html index 1d9ce75dd89..8b4919548bf 100644 --- a/docs/RFPs/xcm-tool.html +++ b/docs/RFPs/xcm-tool.html @@ -4,13 +4,13 @@ XCM library & tools | Web3 Foundation Grants - +

    XCM library & tools

    caution

    This Request for Proposals is currently considered under development, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.

    Project Description ๐Ÿ“„โ€‹

    XCM is the crosschain communication standard that will be used by all the parachains. Currently XCM is still in an early stage, but already supports some main usecases such as crosschain transfer of fungible tokens.

    There are currently two major areas of XCM that are still awaiting to be improved:

    • Extend & improve xcm-format to support more use cases
      • We have few issues & PRs so we are on track on getting this done, but of couse more help is as always welcome
    • Implement library & tools to ease the development of XCM related code
      • xtokens handles the fungible asset implementations, and we also need a similar one for NFTs
      • We need some tool to allow developers to test XCM related code: https://github.com/paritytech/polkadot/issues/2544
      • To implement more complicated XCM scenarios, we need some tools to help with async programming

    The scope of the new project count be one of:

    - + \ No newline at end of file diff --git a/docs/Support Docs/T&Cs.html b/docs/Support Docs/T&Cs.html index 85109a1e32a..9d630640c84 100644 --- a/docs/Support Docs/T&Cs.html +++ b/docs/Support Docs/T&Cs.html @@ -4,14 +4,14 @@ Grants Terms and Conditions | Web3 Foundation Grants - +

    Grants Terms and Conditions

    Updated February 2023

    By participating you acknowledge and accept theโ€‹ terms and conditionsโ€‹ of the Web 3.0 Foundation for the grant application (the "Terms and Conditions").

    These Terms and Conditions are entered into by and between the Web 3.0 Technologies Foundation, Baarerstrasse 14, 6300 Zug, Switzerland (CHE-332.596.347) (henceforth "Web 3.0" or "We") and you as an applicant for the technical grant for software development, research and/or the production of software documentation and technical education material as specified in Guidelines for technical grant of Web 3.0 Technologies Foundation (henceforth "User" or "You") (each also a "Party" and together the "Parties"). Please read these Terms and Conditions carefully. By signing off the terms and conditions via the CLA assistant, You confirm that You have read these Terms and Conditions and that You agree to be bound by them.

    We reserve the right to change, modify, add or remove portions of these Terms and Conditions from time to time. If this occurs, We will notify You in adequate form on such updates.

    1. Introductionโ€‹

    We are the Web3 Foundation and nurture and steward technologies and applications in the fields of decentralized web software protocols, particularly those which utilize modern cryptographic methods to safeguard decentralization, to the benefit and for the stability of the Web3 ecosystem. We have developed a network protocol which purports to operate as an umbrella network for independent blockchain offerings and shared data or tokens across different blockchains. Parallelizable blockchains (so called "parachains") can be connected within Our network with a so called "relay chain" which provides security to the "parachains" and relays messages between them.

    2. Defined Termsโ€‹

    The terms defined in this section whenever used in these Terms and Conditions shall have the respective meanings indicated below, both in singular and plural:

    "Affiliate" has the meaning with respect to any person, any other person directly or indirectly controlling, controlled by or under common control with such person;

    "BTC" means the blockchain tokens native to the Bitcoin Network;

    "Change of control" means any change in Your ownership or control or of a legal entity directly or indirectly owning or controlling You, whether by merger, consolidation, reorganization, take-over, change in the ownership of the share capital or otherwise;

    "Development Work" means any and all development activities related to the Software and undertaken by You. For the avoidance of doubt, any development activities undertaken before the Effective Date in relation to the Software are deemed to constitute Development Work and to form part of the deliverables to be provided by You and be subject to the terms of these Terms and Conditions;

    "Effective Date" means the date on which the application is accepted by the Grants Committee via the application review process defined below (the date of the merged commit of the application, which can be found under https://github.com/w3f/Grants-Program/pulls);

    "Grant" means the financial support granted by Web 3.0. to You (i) for the development of the Software in accordance with the Specifications; and (ii) the grant of license rights on the Intellectual Property Rights, according to the terms of these Terms and Conditions. The Parties agree that Grants are unrelated to the actual development costs and the commercial value of the Software;

    "Intellectual Property Rights" means any (i) patents, designs, copyright and related rights, database rights, trademarks, trade names (whether registered or unregistered), and the related rights to apply for registration thereof; (ii) applications, extensions and renewals in relation to any of these rights; (iii) know-how and confidential information; and (iv) all other rights of a similar nature and/or having an equivalent effect anywhere in the world;

    "Milestones" mean any and all of the milestones specified in the final version of the application under Development Roadmap and approved by the Grants Committee in accordance with the Procedure as well as placed in the applications folder of the W3F Grants Program Repository at https://github.com/w3f/Grants-Program/tree/master/applications;

    "Polkadot" means a scalable heterogeneous multi-chain framework developed by, or the development of which has been procured by Web 3.0. that has the features described in the white paper ("Polkadot: Vision For A Heterogeneous Multi-Chain Framework -- Draft 1") or as otherwise determined by Web 3.0. in its sole discretion from time to time) and utilizes DOTs as the blockchain token native to its operation and/or functioning;

    "Procedure" means the procedure in connection with the Web 3.0 Foundation Grants Program, as established in Section 4 below;

    "Software" means the deliverables created by You during the development activities performed according to these Terms and Conditions in their final and working version, and that are to be provided to the Foundation in accordance with the Specifications, Milestones and Time Schedule;

    "Specifications" mean the reasonably detailed technical and/or other requirements describing the features and functionality of the Software, as specified in the final version of the application approved by the Grants Committee in accordance with the Procedure and placed in the applications folder of the W3F Grants Program Repository at https://github.com/w3f/Grants-Program/tree/master/applications.

    "Terms and Conditions" means this terms and conditions together with any documents referred to in it;

    "Time Schedule" means the time schedule specified in the final version of the application approved by the Grants Committee in accordance with the Procedure and placed in the applications folder of the W3F Grants Program Repository at https://github.com/w3f/Grants-Program/tree/master/applications.

    3. Eligibilityโ€‹

    If You are submitting an application for a Grant, You represent and warrant that:

    • each of the following statements is true and accurate and all of the information You provided was and shall remain true and complete;

    • If You are registering on behalf of a legal entity, such legal entity is duly organized and validly existing under the applicable laws of the jurisdiction of its organization and you are duly authorized by such legal entity to act on its behalf;

    • You are of legal age to form a binding contract (at least 18 years old in most jurisdictions);

    • You have the right, full power and authority to enter into these Terms and Conditions, to exercise your rights and perform your obligations under these Terms and Conditions and in doing so will not violate any other agreement to which You are a Party nor any laws;

    • these Terms and Conditions constitutes a legal, valid and binding obligation on You which are enforceable against You in accordance with their terms;

    • no consent, authorisation, licence or approval of or notice to any governmental authority nor your shareholders, partners, members, other record or beneficial owners or other any relevant person (as applicable) is required to authorise the execution, delivery, validity, enforceability or admissibility in evidence of the performance by You of your obligations under these Terms and Conditions;

    • You are not a citizen of, or resident in or located in, or incorporated or otherwise :

      1. listed on any of the following lists (each a Sanctions List): the Consolidated United Nations Security Council Sanctions List; the Specially Designated Nationals and Blocked Persons List or the Sectoral Sanctions Identification List maintained by the US Office of Foreign Assets Control (OFAC); the Consolidated List of Persons, Groups and Entities subject to EU Financial Sanctions; the Consolidated List of Financial Sanctions Targets or List of persons subject to restrictive measures in view of Russia's actions destabilising the situation in Ukraine, maintained by the UK Treasury; the Overall List of Sanctioned Individuals, Entities and Organizations maintained by the Swiss State Secretariat for Economic Affairs (SECO); 'Ordinance lists of the Swiss Federal Council'; or any similar list maintained by, or public announcement of sanctions made by, any other Sanctions Authority (as defined below);
      2. owned or controlled by, or acting on behalf of or for the benefit of, any person on a Sanctions List;
      3. located in, resident in or incorporated under the laws of (as applicable) Syria, Iran, Cuba, Crimea or North Korea, or any other country or territory which, after the Effective Date, becomes the target of such comprehensive, country-wide or territory-wide Sanctions (as defined below) as currently apply to the aforementioned territories; or
      4. the target of any sanctions laws, regulations, embargoes or restrictive measures (Sanctions), as amended from time to time, administered, enacted or enforced by: the United Nations, the United States, the European Union or any Member State thereof, the United Kingdom, Switzerland or the respective Governmental Authorities and agencies of any of the foregoing responsible for administering, enacting or enforcing Sanctions, including without limitation, OFAC, the US Department of State, the United Kingdom Treasury or the SECO (Sanctions Authority).

    • You will comply with any laws applicable to Your software (built based upon the Polkadot network) and not engage in any illegal activities. In particular, You will not use the Polkadot network to facilitate infringement of any third party intellectual property rights or data privacy rights.

    You shall indemnify and hold harmless Web 3.0 from any third party claims (including reasonable attorney's costs) raised against Web 3.0 based on an alleged infringement of the above representations and warranties.

    4. Procedureโ€‹

    To apply for the Web 3.0 Foundation Grants Program, your application shall fulfill the following criteria:

    • it shall be a research or software-based project, which contributes to the advancement of the Polkadot ecosystem;
    • the Software shall be released under the Apache license version 2.0.;
    • You must accept payment in USDT or USDC/DAI on Polkadot AssetHub, fiat or BTC;
    • You will need to submit the application and deliver the milestones according to the process specified below;

    The grants process consists of five parts, each of them described in more detail below:

    (i) Grant application process:

    To apply for a grant of the Web 3.0 Foundation Grants Program, You shall comply with the procedures established in the README.md file under https://github.com/w3f/Grants-Program as well as the process defined inside this document.

    To apply for a grant of the Web3 Foundation Grants Program, the grantee needs to fork (= create a copy on GitHub of) the Grants-Program GitHub repository. In the newly created fork (=copy on GitHub), the grantee has to create a copy of the application-template.md. The copied application-template.md needs to be renamed as "project_name.md". "Project_name" needs to be replaced with the name of the project application. Additionally, the grantee has to fill out all mandatory parts of the application-template.md presented in bold letters. Once the grantees have completed the application, they need to create a new pull request (= in this case, a mechanism to submit the changes of the fork to the original Grants-Program GitHub repository) by clicking on the "create new pull request" button shown inside the fork of the W3F Grants-Program GitHub repository. After this, the grantee needs to sign off the terms and conditions presented via the CLA assistant.

    (ii) Application review process:

    The Web 3.0 grants committee, which is specified on the Grants-Program GitHub repository(the "Grants Committee"), can issue comments and request changes on the grant application pull request (the submission of the grant application on GitHub). As soon enough members of the Grants Committee approve the pull request, the terms and conditions are signed off and all requested changes are addressed, the application is officially accepted. The application is now a part of the W3F Grants-Program GitHub repository. The time point of the acceptance by the Grants Committee is hereby stored on GitHub and counts as the official beginning of the grant. The original submission is stored with a unique commit hash (identifier) and can not be altered by any party. The final version approved by the Grants Committee of the Specifications, the Time Schedule and Milestones will be placed in the applications folder of the W3F Grants Program Repository at https://github.com/w3f/Grants-Program/tree/master/applications via the merge function of GitHub.

    (iii) Milestone delivery process:

    To submit one of the possible multiple milestones specified in the application, You shall fork the Grant Milestone Delivery GitHub repository with the same Github account, used to submit the initial application. In the newly created fork, You shall create a copy of the milestone-delivery-template.md. Such milestone-delivery-template.md needs to be renamed as "project_name_milestone_number.md". "Project_name" needs to be replaced with the name of the project application and milestone number with the number of the delivered milestone. Additionally, You shall fill out all mandatory parts of the milestone-delivery-template.md as well as the invoice form linked inside the milestone-delivery-template.md. Once You have completed the milestone delivery document, You shall create a new pull request by clicking on the "create new pull request" button shown inside their fork of the Grant Milestone Delivery GitHub repository.

    (iv) Milestone review process:

    The Grants Evaluators, who are specified on the Grants-Program GitHub repository, can issue comments and request changes on the milestone delivery pull request.

    a) Purpose and object of the milestone review process

    The purpose of the milestone review process is to examine whether the Milestones and/or Software meets the requirements agreed in the Specifications. The milestone review process shall take place following the submission of each milestone as specified in the time schedule.

    The test criteria that must be met in order for the Milestones and/or Software to be considered as acceptable by Web 3.0 are determined in the Specifications.

    The milestone review process shall be deemed to have been successfully completed if no significant defects are found in any of the Milestones and/or Development Work. Insignificant defects shall not prevent acceptance by Web 3.0.

    b) Acceptance Procedure

    If any of the Milestones and/or the Software does not meet the test, review or inspection criteria, Web 3.0 shall grant You a period of 14 days to rectify the defects and any deviations from the Specifications found and objected to during the milestone review process. Rectification shall be free of charge for Web 3.0.

    If You are unable to remedy the defects within this additional period, You shall be considered to be in default, without any additional notice by Web 3.0.

    In the event of default, Web 3.0 may either, at its discretion:

    • insist on the rectification of the milestones and/or the Software;
    • delegate the completion of the Software to a third party at your expenses;
    • reduce payment of the Grant because of the reduced value of the Software; or
    • refuse payment of the Grant in full (for the avoidance of doubt, this may require You to refund all milestone and advance payments made under these Terms and Conditions).

    As soon as one evaluator approves the pull request, the delivery is officially accepted. The delivery is now a part of the Grant Milestone Delivery GitHub repository. The time point of the acceptance by the evaluator is hereby stored on GitHub. The original submission is stored with a unique commit hash (identifier) and can not be altered by any party.

    (v) Payment process:

    The Operations Team specified in the Grants-Program GitHub repository, gets notified once the above-specified delivery was accepted. As soon as any feedback is provided by the evaluators, this feedback first needs to be resolved. After this, the Operations Team makes the payment to the bank account, Bitcoin or Polkadot AssetHub (for USDT and USDC) address specified in the initial application.

    5. Scope of these Terms and Conditionsโ€‹

    The subject matter of these Terms and Conditions is (i) the development of the Software by You in accordance with the Specifications, Milestones and Time Schedule, as well as any related activities (including any development activities undertaken before the Effective Date in relation to the Software) (collectively referred to as "Development Work") in accordance with the terms of these Terms and Conditions.

    In performing your obligations under these Terms and Conditions, You shall:

    1. use reasonable skill and care;
    2. comply with any date or time specified according to the Time Schedule;
    3. perform your obligations in accordance with good industry practice, being practices in relation to the development of software and related deliverables the same as or similar to the Software that are usually followed by other suppliers in the same industry, including adherence to industry codes of practice and industry standards in relation to such products and services;
    4. perform your obligations in accordance with all laws and codes of conducts applicable;
    5. ensure that your development team consists of a sufficient number of appropriately skilled and experienced individuals
    6. develop the Software as an open source software under the Apache license version 2.0.

    Unless expressly agreed otherwise in writing by the Foundation, the Grantee shall not subcontract, even partially, the development of the project/deliverable to any third party. If the project/deliverable, in whole or in part, is subcontracted to a third party without the consent of the Foundation, the Foundation is entitled to immediately terminate the Grant Agreement and to recover the grant amount already disbursed.

    The Parties acknowledge and agree that the requirements set out in the Milestones may only be varied or amended by submitting another pull request and the following reevaluation by the committee under the same conditions as the initial application review process specified above.

    6. Obligations of Userโ€‹

    1. You shall deliver the Software, as well as all related deliverables, including but not limited to the source code, to Web 3.0 free of defects, fully compliant with the Specifications and in accordance with the Time Schedule.

    2. Web 3.0 shall be in the position to further developing, re-engineering and using the delivered Software without any technical or other limitations.

    3. You shall bear all costs and expenses incurred in connection with the Development Work.

    4. You shall remain positive towards the Foundation, the Foundation representatives and its goals, plans and projects. You shall advocate for the Foundation's projects' and sub-projects' aims during the term of the Agreement.

    5. You shall, at all times during the term of the Agreement refrain from making, causing to be made, publishing, ratifying, endorsing, re-publishing or promulgating any and all disparaging remarks or derogatory, false, negative, critical, vilifying or otherwise detrimental statements or comments, whether implied or expressed, made in any format to any party or entity with respect to the Foundation, its officers, directors, employees, council members, advisors or otherwise affiliated individuals, entities and projects, including, but not limited to negative statements pertaining to:

      1. any management style, methods of doing business, quality of products and services, the business affairs, operation, financial condition and standing in the community; and
      2. any treatment of its officers, directors, employees, council members, advisors or otherwise affiliated individuals and any circumstances surrounding any such employment and/or separation of employment from the Foundation or advisory relationships.

    1. You agree to forbear from making any public or non-confidential statement with respect to any claim or complaint against the Foundation without having obtained the Foundationโ€™s prior written consent.

    2. You agree that during the term of this agreement together with the Schedules (or any of each SOW), including extensions or modifications thereto, and for a period of nine (9) months thereafter, neither Grantee nor the Foundation will recruit, directly or indirectly hire, solicit or employ, engage as an independent contractor, any employee or independent contractor of either party, or any employee or independent contractor of any of the other subcontractors, who are involved in the development, use, or provision of the Services, without the prior written approval of the party whose employee or independent contractor is being considered for employment or engagement as an independent contractor, except as otherwise required by law. If one of the parties breaches this section, this party shall pay forty thousand dollars ($40,000.00) for each person hired as liquidated damages. The parties agree that quantifying losses arising from breach of this section is inherently difficult and stipulate that the agreed upon sum is not a penalty, but rather a reasonable measure of damages, based upon the partiesโ€™ experience in the software development industry and given the nature of the losses that may result from such breach.

    7. Terms of Grant Givingโ€‹

    Web 3.0. shall grant You, as compensation for the delivery of the Software and the related deliverables and the grant of license rights on the Intellectual Property Rights to the Web 3.0., a Grant as indicated in the application placed in the applications folder of the W3F Grants Program Repository at https://github.com/w3f/Grants-Program/tree/master/applications.

    The Parties agree that the Grant is a lump-sum payment and that no additional compensation is due for the actual development costs incurred.

    The Grant is paid as milestone payments for the accomplishment of the Milestones during several phases of the Development Work as indicated in the main readme file on Github (https://github.com/w3f/Grants-Program).

    You shall not be entitled to an increase in compensation, even if you have had more work or greater expenses than anticipated. An increase in compensation is also excluded if extraordinary circumstances which could not have been foreseen prevent the completion of the Software or make it excessively difficult.

    Except as specifically provided otherwise, the Grant shall be due and payable on or before thirty (30) calendar days after receiving an invoice from You and upon acceptance by the Web 3.0. of the Software and/or Milestones.

    The Parties acknowledge and agree that the Web 3.0. shall be entitled to make Milestones payments. The Parties acknowledge and agree that any partial or advanced payments by the Web 3.0. or any third party shall be set off against the total amount of the Grant.

    8. Taxes and other dutiesโ€‹

    You are solely responsible for determining what, if any, taxes or other duties apply to Your Grant. It is also Your responsibility to withhold, collect, report, and remit the correct taxes to the appropriate tax authorities, according to the legislation in force. Web 3.0 is not responsible and shall be in no way held liable for withholding, collecting, reporting, and remitting and taxes arising from, or in connection to Your Grant.

    9. Warranties and Liabilitiesโ€‹

    You hereby warrant that:

    (a) You are the owner of all Intellectual Property Rights, title and interest in and to the Software and the related deliverables, free and clear of all liens and encumbrances;

    (b) You have the exclusive and unlimited right and authority to use and dispose of the Software and the related deliverables by granting to Web 3.0. license rights according to these Terms and Conditions and such use and right to dispose did not and will not conflict with, infringe upon or violate any copyright or any other proprietary right of any other person;

    (c) there are no licenses or rights current in effect in favor of any third party to use the Software and the related deliverables which would impair the rights granted to Web 3.0. as provided for under these Terms and Conditions; and

    (d) You have disclosed all previous involvement of any team member in the Web 3.0 grant process, including, but not limited to: Closed, Rejected, Accepted, Delivered and Pending grant applications.

    (e) there is no pending or threatened claim, action, suit, investigation or proceeding of any kind challenging, alleging or asserting that the Software and the related deliverables were improperly or invalidly granted or are otherwise not protected as Intellectual Property Rights.

    You further warrant that the Software and the related deliverables:

    (a) are free of defects in materials and workmanship;

    (b) fully conform the Specifications and perform the functions and criteria as described in the Specifications; and

    (c) are sufficient and fit for the intended use as described in the Specifications.

    Your liability for a single loss event shall be limited to the aggregate total of all sums paid by Web 3.0. to You under these Terms and Conditions. Nevertheless, You shall not be held liable for indirect, special, punitive, exemplary, incidental or consequential damages or losses arising out of these Terms and Conditions.

    Furthermore, You shall hold Web 3.0. as well as its sublicensees harmless against any and all liability and damages for the infringement of Intellectual Property Rights of third parties, insofar as the infringement of such third party rights was caused by the intended use of the Software according to the Specifications. Web 3.0. shall immediately inform You in writing of any third party claims asserted and authorize You to conduct the defense, including the conclusion of a settlement, entirely at its own costs. In this respect, You shall use best efforts to provide Web 3.0. with the right to continue, or let continuing, using the Software or replace or modify the Software without deterioration or limitations of the functions and criteria agreed in the Specifications and without any additional costs. Should none of these measures be possible, Web 3.0. shall be entitled to withdraw from these Terms and Conditions and request the reimbursement of the Grant.

    If You or Web 3.0. delegates the performance of an obligation or the exercise of a right under these Terms and Conditions to an associate, they are liable to the other Party for any loss or damage the associate causes intentionally or negligently in carrying out such tasks.

    10. Term and Terminationโ€‹

    These Terms and Conditions (i) comes into force on the Effective Date (notwithstanding that these Terms and Conditions shall apply to Development Work carried out prior to the Effective Date); and (ii) shall remain in force (unless terminated earlier in accordance with its terms) until the acceptance of the Software by Web 3.0. and full payment of the Grant.

    Termination with immediate effect will occur if the terms of the Terms and Conditions agreement is violated, as follows:

    1. if a deadline according to the Time Schedule is not met;
    2. if it results from Your behavior that such a deadline will not be met;
    3. if You become bankrupt, insolvent, wound-up or dissolved or otherwise loses its legal personality as a validly standing entity;
    4. if there is a Change in Control and Web 3.0. has not given his prior written consent to such Change in control; and/or
    5. in the event You do not comply with Section 6.1, 6.4, 6.5, 6.6 and/or causes, in any way and at Web 3.0.'s discretion, any damage to Web 3.0. or Polkadot's image or reputation.

    Furthermore, termination can happen for any reason at the discretion of the Web 3.0 Technologies Foundation.

    11. Noticesโ€‹

    We may provide any notice to You under these terms and conditions by posting a notice on our Website, adding a comment to the initial pull request of your application on GitHub or sending an email to the email address associated with Your access account to the network. Notices We provide by posting on the Website will be effective upon posting. You will be deemed to have received any email sent to the email address then associated with Your account when We have sent the email (or the next regular working day thereafter), whether or not You actually receive or read the email. It is Your responsibility to keep Your email address current.

    To give Us notice under these terms and conditions, You must contact us by email to [grants@web3.foundation]. We may update this email address for notices to us by posting a notice on Our Website. Notices to us will be effective one business day after they are sent.

    All communications and notices to be made or given pursuant to these terms and conditions must be in English language.

    12. Miscellaneousโ€‹

    The Parties are independent contractors. These Terms and Conditions are an agreement at arms' length between the Parties and do not constitute a partnership, association or joint venture under any applicable law. Consequently, the provisions of these Terms and Conditions shall not, under any circumstances, be interpreted as creating any such relationship between the Parties. Neither Party may bind the other in any manner whatsoever or in favour of anyone whomsoever.

    The failure of any of the Parties to avail itself or to enforce any of the provisions of these Terms and Conditions or any rights with respect thereto shall in no way be considered to be a waiver of such provisions or rights, or in any way to affect the validity of these Terms and Conditions. No waiver shall be effective unless expressly made in writing and signed by an authorized representative of the waiving Party.

    If any provision of these Terms and Conditions is held to be void, invalid or inoperative, the remaining provisions of these Terms and Conditions shall not be affected and shall continue to be in effect, and the invalid provision shall be deemed modified to the least degree necessary to remedy such invalidity.

    These Terms and Conditions or individual rights and obligations arising from it may only be assigned or transferred to third parties with the prior written consent of the other Party, save that Web 3.0 may freely assign any of its Intellectual Property Rights and any rights or obligations pursuant to these Terms and Conditions to any of its Affiliates.

    These Terms and Conditions and any documents referred to in it shall constitute the entire agreement between the Parties in relation to the subject matter hereof, and shall supersede all previous agreements, arrangements and understandings between the Parties with respect hereto.

    The headings used herein are inserted only as a matter of convenience and for reference only. They shall not affect the construction or interpretation of these Terms and Conditions.

    13. Referral Programโ€‹

    If you were referred to the Web 3.0 Foundation Grants Program by a person who is either a Polkadot Ambassador or, in any case, a person considered by Web 3.0 as being active in the Polkadot Ecosystem (a โ€œValid Refereeโ€), upon signature of this Terms and Conditions you could indicate to Web 3.0 the name of this Valid Referee, provided that he/she gave you his/her consent to share his/her identity with Web 3.0. Web 3.0, as part of its grant referral program, will grant to the Valid Referee a referral bonus of the amount at that time allocated as bonus under such program. For the avoidance of any doubt, Web 3.0 reserves the right to decide - at its complete discretion - if an individual is (and/or continues to be) a Valid Referee, and only in this case the referee will be entitled to receive the referral bonus.

    14. Applicable Law and Jurisdictionโ€‹

    These Terms and Conditions shall be governed by and construed in accordance with the substantive laws of Switzerland without any reference to its conflict of law provisions. The provisions of the United Nation Convention on contracts for the International Sale of Goods (CISG) shall not apply.

    Any disputes arising out of or in connection with these terms and conditions and contracts entered into thereunder shall be submitted to the sole and exclusive jurisdiction of the courts of the city of Zug.

    15. Polkadot Networkโ€‹

    If You are using Polkadot network for the purpose of the software development, research and/or the production of software documentation and technical education material You agree to be bound by specific term as follows:

    You are free to use the software to gain access to and use the Polkadot network and to build your own network(s) and have your network interact with other networks which are also part of the Polkadot network.

    HOWEVER, YOU SHALL AT ALL TIMES NOTE THAT NO PARTY (NEITHER WE OR YOU), INCLUDING BUT NOT LIMITED TO ANY PARTY INVOLVED IN, OR HAVING CONTRIBUTED TO THE DEVELOPMENT OF, THE POLKADOT NETWORK AND ANY OF THE AFFILIATES, DIRECTORS, EMPLOYEES, CONTRACTORS, SERVICE PROVIDERS OR AGENTS OF SUCH PARTIES (THE "PARTIES INVOLVED") OWNS OR CONTROL THE POLKADOT NETWORK OR ANY ACCESSORY, UPGRADE, RELATED SOFTWARE OR ANY OTHER MODIFICATION TO IT (INCLUDING, BUT NOT LIMITED TO, POLKADOT NETWORK USER INTERFACE) AND YOU ARE SOLELY AND IN FULL RESPONSIBLE FOR YOUR USE OF EACH AND ANY OF THEM. THERE IS NO CENTRAL OVERSIGHT OVER THE POLKADOT NETWORK. IT IS BUILT BY THE PARTICIPANTS AND PARTICIPANTS OF THEIR NETWORKS THEMSELVES. FOR THE AVOIDANCE OF DOUBT, WEB 3.0 ASSUMES NO RESPONSIBILITY OR LIABILITY FOR (1) AVAILABILITY AND OPERABILITY OF THE POLKADOT NETWORK AND ITS UNDERLYING SOFTWARE, (2) INTEROPERABILITY OF YOUR NETWORK WITH OTHER THIRD PARTY NETWORKS (THIS LARGELY DEPENDS ON EXTERNAL FACTORS BEYOND OF WEB 3.0'S REASONABLE CONTROL SUCH AS, IN PARTICULAR THE INFRASTRUCTURE AND OPERABILITY OF THIRD PARTY NETWORKS AND THEIR INTERNET-CONNECTIVITY MEASURES) OR (3) SUITABILITY OF THE POLKADOT NETWORK FOR YOUR OWN BUSINESS PURPOSES. YOU ARE USING THE POLKADOT NETWORK FOR YOUR OWN BUSINESS PURPOSES AT YOUR SOLE AND OWN RISK.

    Acknowledgement and assumption of risksโ€‹

    You shall at all times acknowledge and agree that certain risks exist in relation to using the Polkadot network. You fully acknowledge and agree that:

    • No Party, including but not limited to the Parties involved, โ€‹owns or controls the Polkadot network. It is built by the end users themselves.
    • No Party, including but not limited to the Parties involved, has any authority to approve, prevent, restrict or anyhow exercise control over any interaction that occurs through the Polkadot network. You and end users are free to build their own network and network-based applications and provide them to customers under their own terms and conditions, provided that such applications should also run and be offered in a decentralized manner (as e.g. distributed ledger technology or often referred to as "blockchain" or any future adaptations of such technologies) without central oversight.
    • You shall not have any expectations over the performance, suitability for business or interoperability of the Polkadot network for Your own business purposes.
    • Polkadot network source code has not passed a third party security audit and can be potentially unstable and could cause unexpected effects and system failures. You are aware of this risk and must address it within Your own privacy compliance model when establishing technical and organizational measures on data security for Your end customers.
    • By using the Polkadot network You covenant, represent, and warrant that Your use of the network complies with Your jurisdiction of residence and You are fully able and legally competent to use the Polkadot network.
    • In the event Your use of the Polkadot network does not comply with the applicable law of Your jurisdiction of residence, You shall be fully liable for any consequences incurred thereof and fully acknowledge and agree that โ€‹We โ€‹shall not be held liable for Your use of the Polkadot network
    • There is a risk that advances in cryptography or technical advances (such as the development of quantum computers) could present risks to blockchain-based applications and cryptocurrencies, Ethereum or tokens which could result in the theft or loss of such elements.
    • The network (as well as any network You build based upon it) is susceptible to mining attacks (including but not limited to double-spend attacks, majority mining power attacks, "selfish-mining" attacks and race condition attacks. Despite the efforts of Web 3.0, the risk of known or novel mining attacks exists.
    • There are risks associated with using the network, such as e.g. failure of hardware, software and Internet connections. You acknowledge that Web 3.0 shall not be responsible for any communication failures, disruptions, errors, distortions or delays You may experience when using the network.
    • network source code is provided on an "AS IS" basis, without warranties and conditions of any kind, either express or implied, including, without limitation, any warranties or conditions of title, merchantability, fitness for a particular purpose, and non-infringement, unless otherwise required by mandatory applicable law.
    • The entire risk as to the quality and performance of using the network is borne by You.
    • You are solely responsible for determining the appropriateness of using or redistributing the network source code and/or any Derivative Work and assume any risks associated with Your exercise of permission granted under this License.
    • You are solely responsible to regularly check for any modifications and updates to the network source code published at https://github.com/paritytech/polkadot/

    Intellectual propertyโ€‹

    As regards the network and its underlying technology, Web 3.0 is offering You the right to use it open-source based and Web 3.0 does not retain any proprietary intellectual property rights therein (see the GPL-License Version 3 available under https://www.gnu.org/licenses/gpl-3.0.en.htmlโ€‹).

    However, Web 3.0 retains all rights, title and interest in any intellectual property rights relating to its business (such as e.g. trademarks or logos on its Website or copyrights/know-how in other business offerings not related to the network).

    Privacyโ€‹

    To the extent that You will gain access to and collect and process personally identifiable data through the network (or any own network built based upon it) and maybe even store it outside of these networks (i.e. "off-chain"). In this context, You represent and warrant to be compliant with the applicable data protection laws, in particular, to collect personal data lawfully, in good faith, and to retain and process such data proportionately only for the purposes of processing made evident at the time of collection and that such data will be secured with adequate technical and organizational measures against unauthorized use and to comply with third party data processing principles and not transfer such data into countries with a non-adequate data protection standard compared to Yours without adequate contractual safeguards.

    Limitation of liabilityโ€‹

    In no event and under no legal theory shall Web. 3.0 be liable to You for damages, including any direct, indirect, special, general, incidental or consequential damages of any character arising as a result of this License or out of the use or inability to use the network (including, but not limited to, loss of data or data being rendered inaccurate or losses sustained by You or third parties or a failure of the network to operate with any other programs, loss of goodwill, work stoppage, business interruption, computer failure or malfunction or any and all other commercial damages or losses), even if a contributor has been advised of the possibility of such damages. Web 3.0 does not control, take responsibility for, or assume liability for the data in any way processed and stored by You or any third party using the network and for any damage or loss incurred thereto. You shall solely be liable for the appropriateness, lawfulness, and accurateness of the data in any way processed by You using the network (and or if using such data outside of the network i.e. "off-chain".

    Indemnificationโ€‹

    The Grantee shall indemnify, defend, and hold the Foundation and its officers, agents, employees, and affiliates harmless from and against all claims, causes of action, damages, fines, third-party claims, penalties, losses, expenses, costs (including reasonable attorneyโ€™s fees), and liabilities the Foundation incurs which relate to or arise out of any breach of this Agreement by Grantee or of any express or implied representation or warranty by Grantee, or any negligent or willful acts or omissions of Grantee or its Personnel.

    - + \ No newline at end of file diff --git a/docs/Support Docs/announcement-guidelines.html b/docs/Support Docs/announcement-guidelines.html index cd50fcba594..792efd2e52f 100644 --- a/docs/Support Docs/announcement-guidelines.html +++ b/docs/Support Docs/announcement-guidelines.html @@ -4,14 +4,14 @@ Announcement Guidelines | Web3 Foundation Grants - +

    Announcement Guidelines

    Guidelines updated August 2021

    Web3 Foundation (W3F) supports many teams and organizations throughout the ecosystem. We often receive requests to participate in project announcements. Unfortunately, due to the high volume of requests, we rarely do joint announcements and do not provide quotes.

    In the context of the grants programs, we ask teams not to make any announcements before the first milestone has been accepted. This is in order to protect the community from projects that only intend to use the grant announcement to raise funds and/or interest but don't intend to deliver on the application, which has unfortunately happened in the past. For this reason, we reserve the right to terminate grants if this rule is not observed.

    Once you have completed your milestone, we can help by reviewing and proofreading your blogpost. When you have drafted your announcement, send it to grantsPR@web3.foundation and add grants@web3.foundation in cc. Please allow 1-3 working days where possible for proofreading articles and wait until the milestone has been accepted to publish it.

    We also cross-promote the most recent projects and their milestones on Twitter on the second Monday of every month, so please keep us updated and send us the links to your published tweets regarding your announcements.

    We recommend the following guidelines when writing your postโ€‹

    • The post should be strategic in nature, focusing on the tech rather than the "announcement" element.
    • The team should point to the work, in order to attract attention for the project and demonstrate momentum in the ecosystem. It should be informative for builders and the larger community.
    • The post should include a link to a GitHub repository or elsewhere to showcase what's been built so far.
    • Suggested flow for the post:
      • This is what the team has built so far.
      • These are the team's future development plans.
      • This is how the technology will contribute to the Polkadot ecosystem.

    Key componentsโ€‹

    1. A blog post header image

      • An image helps when sharing the announcement on social networks. It's more prominent in feeds and looks more professional.
      • Image ideas include showing how W3F or Polkadot fit into your flow. Or you can simply put the teams' logos next to each other.

    2. About your team

      • This is a chance to share more about your project and what it does.
      • You can also highlight additional use cases for this new integration.

    3. Why you chose to build on this tech stack

      • Illustrate the rationale for the relationship - why did you decide to work with Web3 Foundation?
      • Describe the benefits of building on Polkadot, Kusama etc. (shared security, ease of use, ease of deployment, ease of interchain communication, decentralized, trusted, etc.) and why it was important to have these features for your project.

    4. Quote

      • Your CEO / CTO / Founder may want to include a quote of why they picked Web3 Foundation to help gain more visibility and traction in the market.

    5. Description of Web3 Foundation

      • If you wish to mention W3F or Polkadot within the body of your text we recommend the following or similar:

        "Web3 Foundation funds research and development teams building the technology stack of the decentralized web. It was established in Zug, Switzerland by Ethereum co-founder and former CTO Gavin Wood. Polkadot is the Foundation's flagship project."

        "Polkadot is a scalable sharded chain and the first protocol that provides a secure environment for cross-chain composability across multiple shards. Polkadot also introduces a highly advanced, open governance system that will allow the network to innovate and grow at a much faster pace than legacy networks. Applications from DeFi to energy to gaming will thrive on Polkadot, challenging the centralized platforms of Web 2.0."

    6. Social connections

      • The following text regarding Web3 Foundation's social presence can be added at the end of your article:

        "Learn more about Web3 Foundation by visiting their website, and stay up to date with the latest developments by following them on Medium or Twitter."

    1. Use specific verbs such as integrate, support or build.
    2. Don't use descriptors like partner/partnership, collaborations, affiliate, strategic or long-term in these announcementsโ€”due to the various and evolving ways W3F works with the ecosystem.
    3. Don't describe your technology as the "first" to build on Polkadotโ€”timing for launch implementations across all our projects is indefinite.
    4. Don't indicate that W3F or Polkadot prefers a certain technology over all others:
      • As such, do not use: "W3F recommends that teams use this tech to build X"
      • Instead speak of the merits of the tech: "This technology provides great utility for the Polkadot network through..."

    We look forward to working with you in creating the next generation of the internet! If you have any questions or would like to be included in our next announcement, please email grantsPR@web3.foundation.

    - + \ No newline at end of file diff --git a/docs/Support Docs/grant-badge-guidelines.html b/docs/Support Docs/grant-badge-guidelines.html index 89fe382610e..0a58cddaa56 100644 --- a/docs/Support Docs/grant-badge-guidelines.html +++ b/docs/Support Docs/grant-badge-guidelines.html @@ -4,13 +4,13 @@ Usage guidelines for the W3F Grants Program badge | Web3 Foundation Grants - +

    Usage guidelines for the W3F Grants Program badge

    Once a project's first milestone has been accepted, we intend to help teams acknowledge their grant publicly while observing the foundationโ€™s guidelines.

    To that end, weโ€™ve created a badge for grant recipients. This is available for download in four formats under web3.foundation/grants/badge.

    Before you begin using the badge, please note the following points:

    • Use of the Grants Program badge is reserved for Level 2 and 3 grants.
    • Grants are awarded for specific projects, not to teams in general as a blanket endorsement.
    • Web3 Foundation and its grants program donโ€™t broker partnerships or joint ventures, or cosign wholesale any external teamโ€™s work. Bearing that in mind, the badge should only be displayed in project-specific contexts.
    • Please do: display the badge
      • in a GitHub repository that contains code connected with the grant project,
      • on any project-specific webpage that specifically concerns the deliverables completed as part of the grant, or
      • when appropriate, in a tweet or blog post announcing your grant in a project-specific context.
    • Please donโ€™t:
      • display the badge on your team or project's landing page,
      • use the badge before your first milestone has been accepted,
      • add it to any social media profiles, or
      • use it in any other context that could misrepresent your relationship with the Web3 Foundation.

    Also, please don't use the name or logo of the Web3 Foundation in any context that could misrepresent your relationship with Web3 Foundation. Infringement of these guidelines can result in an immediate annulment of the grant.

    In case of any questions, please donโ€™t hesitate to reach out to us at grantsPR@web3.foundation.

    - + \ No newline at end of file diff --git a/docs/Support Docs/grant_guidelines_per_category.html b/docs/Support Docs/grant_guidelines_per_category.html index baa226e545b..b14f9023803 100644 --- a/docs/Support Docs/grant_guidelines_per_category.html +++ b/docs/Support Docs/grant_guidelines_per_category.html @@ -4,13 +4,13 @@ Grant guidelines for most popular grant categories | Web3 Foundation Grants - +

    Grant guidelines for most popular grant categories

    While we ask teams to provide details of their envisioned solution, we are aware that precise implementation might slightly differ from the initial specification. Should there be large deviations from the original plan, please communicate this to the Grants Team ahead of time.

    The list below serves only as a guide and is not exhaustive.

    Runtime Modules/Chainsโ€‹

    Applies toโ€‹

    • Building/extending a Substrate pallet

    Requirementsโ€‹

    • List the publicly exposed methods
    • For each method, specify (to the best of present knowledge):
      • Method signature (incl. parameters with their types, return type)
      • Short description (code template)
    • Runtime Storage defined by your module
    • Use case diagram with e.g. UML or SysML (or similar tool demonstrating how external users/system components interact with one another)

    Development Toolsโ€‹

    Applies toโ€‹

    • CLI tools
    • IDE / IDE plugin

    Requirementsโ€‹

    • State what programming language you'll use
    • Describe the commands that you want to make available to the users:
      • Name
      • Parameters
      • Result (value returned / file created or modified / application started etc.)

    UI Developmentโ€‹

    Applies toโ€‹

    • Building a web application with front-end components
    • Developing a mobile app

    Requirementsโ€‹

    • Provide mockups and/or wireframes (e.g. Figma)
    • List frameworks & tools for development & testing (e.g. React Native, Angular)

    Backend Developmentโ€‹

    Applies toโ€‹

    • Building a service/mobile app/webapp that relies on a back-end component

    Requirementsโ€‹

    • State what language & framework you'll use (e.g. python with Django, Rust with Rocket)
    • Define your database requirements and which system you'll use
    • Choose how & where will your backend be hosted (cloud provider, IPFS, localhost?)
    • Consider scaling & how you plan to handle it
    • Consider CI/CD
    • If you are (planning on) hosting the backend yourself, consider adding a security.txt file so people can get in touch with you regarding (potential) security issues
    • Provide a link to your Github repository if you already have the structure in place

    Cryptographyโ€‹

    Applies toโ€‹

    • New crypto library
    • Extending existing library's functionalities

    Requirementsโ€‹

    • Specify what programming language you'll use
    • Provide any publications/papers you will base your work on
    • Research other crypto libraries providing similar functionalities. State whether/how you plan to use their work. If they don't suit your needs, provide a detailed explanation why and what's missing
    • List any existing crypto libraries that you will use as reference implementation (e.g. in a different language)

    Researchโ€‹

    Applies toโ€‹

    • Research projects

    Requirementsโ€‹

    • Specify the problem(s) that you want to investigate, and why these are important.
    • Declare the research questions/hypothesis.
    • State the methodology that will be applied.
    • Explain how the data will be collected and the analysis procedures.
    • Outline the expected results and how they would be double-checked by the grants team (reproducibility of the data analysis).
    • Research for relevant related work or declare how the literature review will be conducted.
    • Research and declare the intended venue for results publication and the timeline for publication.
    - + \ No newline at end of file diff --git a/docs/Support Docs/milestone-deliverables-guidelines.html b/docs/Support Docs/milestone-deliverables-guidelines.html index 9df85d6ed36..b68bbf6ebee 100644 --- a/docs/Support Docs/milestone-deliverables-guidelines.html +++ b/docs/Support Docs/milestone-deliverables-guidelines.html @@ -4,14 +4,14 @@ Milestone Delivery Guidelines | Web3 Foundation Grants - +

    Milestone Delivery Guidelines

    These are the guidelines to be followed for milestones submitted for evaluation.

    Submissionโ€‹

    Unless instructed otherwise, please submit all your milestones via PR to the Grant Milestone Delivery repository.

    Invoiceโ€‹

    After a milestone is reviewed and accepted, you can submit your invoice alongside your delivery pull request through this form.

    Contentโ€‹

    The submission should contain the following information:

    Licenseโ€‹

    Since all code developed under a grant must be open source, it is necessary to publish your code under an appropriate license. This license should already be defined in your grant application, but if you're unsure, check the Open Source Initiative database for available licenses. We prefer Apache 2.0, but MIT or Unlicense are also acceptable. If your delivery comprises multiple repositories, make sure to include the license in each of them.

    danger

    You should also verify that the code you submit doesn't violate any other licenses, as a failure to comply with the license of reused code will result in an immediate rejection of the milestone and termination of the grant.

    Documentationโ€‹

    We value high-quality open source code, but even the most performant code is of little use if it lacks proper documentation.

    We require that you document (where applicable):

    • API calls
    • Architecture overview and individual component details
    • Algorithms and protocols that are core to your project
    • Any other fundamental building blocks to your technology

    Unless absolutely necessary, make the documentation public as well, ideally as part of the appropriate code repository. This will make it easier for the community to contribute to and use your project.

    Note: Only focus on your own contributions. Do not write detailed explanations of already existing components, including Substrate, ink!, or IPFS.

    Formatted codeโ€‹

    A codebase that is easy to read is also easy to use. We suggest adopting one style from Day 1 and adhering to it across the entire team. This helps to keep the commit history clean and facilitates any reviews of the introduced changes.

    For Substrate, we strongly recommend formatting your code according to the official guidelines.

    For Rust, we encourage formatting any additional support libraries or helpers by following the Style Guidelines.

    For any other deliveries, please commit to a particular style & let us know which official guidelines you adopt.

    Testing Guideโ€‹

    We require that each milestone delivery includes a comprehensive test suite, consisting of:

    A step-by-step guide demonstrating how your code achieves the milestonesโ€‹

    Please provide documentation on how to install, compile, run and test the deliverable(s). Make sure to include all necessary prerequisites. Common issues while replicating test results involve, among others, undocumented dependencies and version numbers, local database setups, breaking changes in the main branch since delivery or OS- and browser-specific incompatibilities.

    Depending on the deliverable, this could include (but is not limited to)

    • how to embed your library in another application,
    • how to make example API calls to your service,
    • running your web app, and
    • steps to complete some desired action in your mobile app.

    Unit testsโ€‹

    As with any quality software project, each logical code component should be testable.

    Integration testsโ€‹

    We prefer Dockerfiles to avoid problems with versions and dependencies.

    Note: If you are not delivering code as part of your project, such a test suite is not applicable. This mainly applies to projects centering on design, research or hardware. If that is the case, please provide detailed instructions on how else we can test/run/replicate your deliverable.

    Milestone Deliverablesโ€‹

    Please provide a list of milestone deliverables. This list should closely reflect the list of deliverables agreed on in the pull request for grant application (or in Annex 1 of the grant contract for the private applications).

    Each item in the list should include a link to the deliverable itself, e.g.:

    • a Google Doc/Medium/blog link (make sure anyone with the link has View access),
    • a link to a file in a public repository (include the appropriate file/folder in the link),
    • a link to a specific commit, pull request or issue in a public repository.
    tip

    Please highlight anything that deviates from the contract and include further information that you think is relevant to the deliverable, either alongside the appropriate deliverable or under Additional Information.

    NumberDeliverableLinkNotes
    0a.Licensehttps://github.com/.../LICENSE...
    0b.Documentation......
    0c.Testing Guide......
    1..........
    2..........

    Additional Informationโ€‹

    Please add any additional comments that you consider relevant for the evaluation.

    - + \ No newline at end of file diff --git a/docs/Support Docs/polkadot_stack.html b/docs/Support Docs/polkadot_stack.html index 207326381ee..877950bc4d6 100644 --- a/docs/Support Docs/polkadot_stack.html +++ b/docs/Support Docs/polkadot_stack.html @@ -4,13 +4,13 @@ Open Source Polkadot Stack | Web3 Foundation Grants - +
    - + \ No newline at end of file diff --git a/docs/Support Docs/privacy_policy.html b/docs/Support Docs/privacy_policy.html index b07c130593d..dfc94429c62 100644 --- a/docs/Support Docs/privacy_policy.html +++ b/docs/Support Docs/privacy_policy.html @@ -4,14 +4,14 @@ Privacy Policy | Web3 Foundation Grants - +

    Privacy Policy

    Updated December 2022

    I.ย Data controllerโ€‹

    1. The operator of the Web 3.0 Foundation website available underย https://w3f.github.io/Grants-Program/ย (hereinafter referred to as the "Website") and offeror of blockchain-related services (such as currently e.g. the Polkadot Network, the Kusama Network and the Thousand Validators programme (hereinafter jointly and individually referred to as the "Services") and, thus, the Data Controller is the Web 3.0 Technologies Foundation, a company registered in the commercial register of the Canton of Zug, Switzerland (registration number CH-322.596.347), with the registered address Baarerstrasse 14, 6300 Zug, Switzerland (hereinafter referred to as "Controller", "we", "us").
    2. We nurture and steward technologies and applications in the fields of decentralized web software protocols, particularly those, which utilize modern cryptographic methods to safeguard decentralization. Data protection is important to us and Controller adheres to the applicable data protection laws and regulations. This includes both the Swiss Federal Act on Data Protection ("FADP") and privacy requirements where applicable to individuals in the European Union and the member states of EFTA under the General Data Protection Regulation (hereinafter "GDPR") and/or other applicable national laws.
    3. This Privacy Policy explains in particular how, for which purposes and to which extent your Personal Data is collected and processed by us through the Website or any type of Service we provide to you (whenever we are referring to you, hereinafter referred to as "User" or "you"). It also describes how your collected Personal Data can be verified, corrected or deleted. Our Services enable the collection of your Personal Data necessary for the establishment and maintenance of our blockchain-offerings.C
    4. As outlined in Sections II and X.A below, if you engage with us and use any of our blockchain-offerings, we may collect, by itself or through third parties, your data including, but not limited to: name, e-mail address, usage data and any information captured automatically through cookies. Complete details on each type of Personal Data collected are provided in the dedicated sections of this Privacy Policy or by specific explanation displayed to you online prior to the data collection.
    5. This Website contains links to other third party websites. If you follow a link to any of those third party websites, please note that they have their own privacy policies and that we do not accept any responsibility or liability for their policies or their processing of your personal information.
    6. For questions or requests related to data processing by us (such as request for information, deletion, revocation of consent, objection to data processing), you may revert by mail to the address above or write us an e-mail atย legal@web3.foundation

    II. Types of Data collectedโ€‹

    1. Controller respects the privacy of the User and will not collect and process any other data (such as name, address, phone number, e-mail address, IP address, device type etc.) unless they are

      • provided voluntarily by the User;
      • gathered as a result of specific verifications performed by third parties included in Section X.C below based on the Personal Data provided by the User;
      • automatically collected by cookies or other tracking technologies. For further information with regard to our use of cookies, please consult Section VII below.

    2. For further information on additional data collected through any of our blockchain-offerings, please consult Section XI below.

    III.ย Mode of Processingโ€‹

    A. Use of Personal Dataโ€‹

    1. Data transmitted by the User to Controller may be used as follows:

      • to create a user account;
      • to respond to your inquiries and your correspondence;
      • for marketing analysis purposes, in particular to better understand the needs of Users and improve the Services of Controller, and to provide Users with relevant information relating to any of our networks operated;
      • to ensure our Website functions correctly, in particular to ensure that content from our Website is presented in the most effective manner for you and for your computer;
      • to maintain or improve our services offered through the Website.

    2. Please consult Section XI below to get further information on additional use of your data collected on any of our network offerings.

    1. The Controller may process Personal Data of Users if one of the following applies:

      1. Users have given their consent for one or more specific purposes. Note: Under some legislations, the Controller may be allowed to process Personal Data until the User objects to such processing ("opt-out"), without having to rely on consent or any other of the following legal bases. This, however, does not apply, whenever the processing of Personal Data is subject to European data protection law (GDPR);
      2. provision of Data is necessary for the performance of an agreement with the User and/or for any pre-contractual obligations thereof;
      3. processing is necessary for the establishment, exercise or defence of legal claims or proceedings;
      4. processing is necessary for compliance with a legal and regulatory obligation to which the Controller is subject;
      5. processing is related to a task that is carried out in the public interest or in the exercise of official authority vested in the Controller;
      6. processing is necessary for the purposes of the legitimate interests pursued by the Controller or by a third party.

    2. In any case, the Controller will gladly help to clarify the specific legal basis that applies to the processing, and in particular whether the provision of Personal Data is a statutory or a contractual requirement, or a requirement necessary to enter into a contract.

    3. Within and to the extent under the scope of application of the GDPR, the data processing described in this clause III. is justified in order to provide our contractually agreed services to you pursuant to Art. 6 para. 1 sentence 1 letter b GDPR and to comply with legal obligations to which we are subject pursuant to Art. 6 para. 1 letter c GDPR.

    C. Methods of processing, access to data and disclosure to third partiesโ€‹

    1. The data processing is carried out using computers and/or IT enabled tools, following organizational procedures and modes strictly related to the purposes indicated.

    2. Access to Personal Data is limited to those employees and/or third parties assigned with processing tasks who therefore need to know about this data. These employees and/or third parties are subject to confidentiality undertakings and/or data processing agreements and must comply with applicable data protection laws.

    3. Controller does not sell, transfer or market your Personal Data to third parties (who may use them for their own purposes). However, we may disclose your Personal Data to trusted third parties and/or certain types of persons in charge, involved with the operation of this Website (administration, sales, marketing, legal, system administration) or external parties (such as third party technical service providers, mail carriers, hosting providers, IT companies, communications agencies, our auditors, third parties involved in hosting or organizing events or seminars) appointed, if necessary, as Data Processors by the Controller.

    4. Please consult Section XI below for lists of all third party processors currently assigned with processing activities on our behalf on any of our networks operated.

    5. Your Personal Data will not be disclosed to third parties for other purposes than the ones mentioned above or the following additional reasons:

      • you have given your express consent to it;
      • the disclosure is necessary to assert, exercise or defend legal claims and there is no reason to assume that you have an overriding interest worthy of protection in the non-disclosure of your data;
      • in the event that a legal obligation exists for the disclosure; or
      • this is legally permissible and necessary for the execution of our contractual relationship with you.

    D. Place of processing and export of dataโ€‹

    1. The data is processed at the Controller's operating offices and in any other places where the parties involved in the processing are located. Depending on the User's location, data transfers may involve transferring the User's data to a country other than their own.
    2. Therefore, we reserve the right to transfer, store, use and process your data, including any personal information, to/by recipients in countries outside of the European Economic Area ("EEA") including the United States and possibly other countries. You should note that laws vary from jurisdiction to jurisdiction, and so laws and regulations relating to privacy and data disclosure, applicable to the places where your information is transferred to or stored, used or processed in, may not provide the same level of protection as in your place of residency. We take the legally required safeguards and contractual measures to ensure that any recipients of your Personal Data abroad undertake to comply with the level of data protection and security prescribed by your applicable local data protection legislation.

    IV.ย Retention of dataโ€‹

    1. The Controller will retain Personal Data for as long as it is required to deliver the Services described in Sections III.A above and X.B below, and/or, upon termination, as long as required by law or regulations (e.g. mandatory retention periods), whichever is longer.

      Therefore,

      1. Personal Data collected for purposes related to the performance of a contract between the Controller and the User shall be retained until such contract has been fully performed;
      2. Personal Data collected for the purposes of the Controller's legitimate interests shall be retained as long as needed to fulfil such purposes.

    2. The Controller may be allowed to retain Personal Data for a longer period whenever the User has given consent to such processing, as long as such consent is not withdrawn.

    3. Once the retention period expires, Personal Data shall be deleted. Therefore, the right to access, the right to erasure, the right to rectification and the right to data portability cannot be enforced after expiration of the retention period.

    V.ย Security measuresโ€‹

    1. We take adequate technical and organizational precautions and security measures to prevent accidental or intentional manipulation, unauthorized access, disclosure, unauthorized destruction, partial or complete loss, misuse or alteration of your Personal Data. Accordingly, we store all the personal information you provide on secure (password- and firewall-protected) servers. Our security measures are continuously improved in line with technical developments. You are responsible for keeping the account information for accessing any of our networks operated confidential.
    2. The User is aware and acknowledges that no technical and organizational measures can fully eliminate security risks connected with transmission of information over the Internet. Once Controller has received the transmitted information, it shall adequately secure it in its systems.

    VI.ย The rights of Usersโ€‹

    1. Users may exercise certain rights regarding their Personal Data processed by the Controller.

      In particular, Users have the right to do the following:

      • Withdraw their consent at any time. Users have the right to withdraw consent where they have previously given their consent to the processing of their Personal Data. Please note that even after you have chosen to withdraw your consent, we may be able to continue to process your Personal Data to the extent required or permitted by law.
      • Object to processing of their data. Users have the right to object to the processing of their data if the processing is carried out on a legal basis other than consent (e.g. for a public interest, in the exercise of an official authority vested in the Controller or for the purpose of legitimate interests pursued by the Controller). Users may object to such processing by providing a ground related to their particular situation to justify the objection. In particular, under and to the extent of a scope of application of the GDPR, in those cases where we base processing on our legitimate interests, you have the right to object to the processing. Users must know that, however, should their Personal Data be processed for direct marketing purposes, they can object to that processing at any time without providing any justification.
      • Access their data. Users have the right to learn if the Controller is processing data, obtain disclosure regrading certain aspects of the processing and obtain a copy of the data undergoing processing.
      • Verify and seek rectification. Users have the right to verify the accuracy of their data and ask for it to be updated or corrected. Please note that you must advise us of any changes to your personal information so that we can ensure that your personal information is accurate and up to date.
      • Restrict the processing of their data. Users have the right, under certain circumstances, to restrict the processing of their data if the accuracy of the data is disputed. In this case, the Controller will not process their data for any purpose other than storing it.
      • Restrict the use of Personal Data whilst complaints are resolved.
      • Have their Personal Data deleted or otherwise removed.\ Users have the right, under certain circumstances, to obtain the erasure of their data from the Controller, unless the processing is justified by our legitimate interests, necessary to fulfil a legal obligation, for reasons of public interest or to assert, exercise or defend legal claims. We will take reasonable steps to inform other controllers that are processing the data that you have requested the erasure of any links to, copies or replication of it.
      • Receive their data and have it transferred to another controller. Users have the right to receive their data in a structured, commonly used and machine readable format and, if technically feasible, to have it transmitted to another controller without any hindrance. This provision is applicable provided that the data is processed by automated means and that the processing is based on the User's consent, on a contract which the User is part of or on pre-contractual obligations thereof.
      • Lodge a complaint. Users have the right to bring a claim before their competent data protection authority (depending on your country of residence and the applicable data protection laws โ€“ note that in certain countries you may only notify a data protection authority which may then decide to initiate legal steps based on its own discretion).

    2. Any requests to exercise User rights can be directed to the Controller through the contact details provided in this document.

    3. Where possible, Controller will fulfil such a request of the User within the statutory applicable timeframe, unless a delay or a retention of the relevant data is permitted by law (e.g. a lack of convincing identity proof by an information requestor), is required for another valid purpose, for example to enable the fulfilment of contractual obligations, or is covered by a valid limitation or exemption under relevant privacy or data protection regulations.

    4. Any requests will be free of charge, provided we do not incur unexpected and inadequate costs for providing you with details of your Personal Data.

    VII.ย Cookiesโ€‹

    1. When the User visits the Website, information can be automatically stored on his or her computer. This is done in the form of so-called "cookies" or a similar file, which help Controller in various ways, for example, to get to know the preferences of visitors and Users of the Website and to improve the Website. Both permanent cookies and functional, temporary session cookies may be used: permanent cookies remain on your computer after you close your session and until you delete them, while session cookies expire when you close your browser.
    2. Any use of Cookies โ€“ or of other tracking tools โ€“ by this Website or by the Controller of third-party services used by this Website serves the purpose of providing the Service required by the User, in addition to any other purposes described in the present document and in the Cookie Notice, if available. Please consult Section XI below to get information on any Cookie Notices available on any of our networks operated.
    3. You may refuse the use of any cookies by selecting the appropriate settings on your browser. Most browsers allow you to delete cookies, prevent their installation or generate a warning before a cookie is installed. The User can obtain further information on this subject from the relevant browser instructions. Note, however, that this may affect your experience of our Website. To find out more about cookies, including how to manage, reject and delete cookies, visitย www.allaboutcookies.org.
    4. Controller will use automatically stored information exclusively for statistical analysis and in particular will not associate any Personal Data with the User unless necessary. This Notice does not limit our use or disclosure to third parties of Non-Personal Information, and we reserve the right to use and disclose such Non-Personal Information to our partners, advertisers, and other third parties at our discretion.
    5. Within and to the extent under the scope of application of the GDPR, the data processed by cookies for the aforementioned purposes is justified in order to protect our legitimate interest and those of third parties pursuant to Art. 6 para. 1 sentence 1 letter f GDPR.
    6. Simple Analytics. Even if we don't need to disclose it, since we aim to be as much transparent as possible with our users, we inform you that to get information about the behaviour of our user, we use Simple Analytics (https://simpleanalytics.com/). This analytics software gives us insight about our user only in general, but not about individuals, as it does not track visitors and does not store any personal identifiable information. If you would like to, please go to their website to find out what Simple Analytics collects (and most importantly what they donโ€™t).

    VIII.ย Changes to This Privacy Policyโ€‹

    1. We reserve the right to make changes to this Privacy Policy at any time by giving notice to Users on this page and possibly within the Website and/or โ€“ as far as technically and legally feasible โ€“ sending a notice to Users via any contact information available to the Controller. Significant changes will go into effect 30 days following such notification. Non-material changes or clarifications will take effect immediately. It is strongly recommended to review the Website and the Privacy Notice periodically for updates.
    2. Should the changes affect processing activities performed on the basis of the User's consent, Controller shall collect consent from the User, where required.

    IX.ย Access to the Privacy Policyโ€‹

    1. The User can access, download, save or print this Privacy Policy in its' current/updated version at any time under the following addressย https://web3.foundation/privacy-and-cookies/.

    1. Personal Data

      Any information that directly, indirectly, or in connection with other information โ€“ including a personal identification number โ€“ allows for the identification or identifiability of a natural person.

    2. Usage Data

      Information collected automatically through this Website (or third-party services employed in this Website), which can include: the IP addresses or domain names of the computers utilized by the Users who use this Website, the URI addresses (Uniform Resource Identifier), the time of the request, the method utilized to submit the request to the server, the size of the file received in response, the numerical code indicating the status of the server's answer (successful outcome, error, etc.), the country of origin, the features of the browser and the operating system utilized by the User, the various time details per visit (e.g., the time spent on each page within the Website) and the details about the path followed within the Website with special reference to the sequence of pages visited, and other parameters about the device operating system and/or the User's IT environment.

    3. User

      The individual using this Website who, unless otherwise specified, coincides with the Data Subject.

    4. Data Subject

      The natural person to whom the Personal Data refers.

    5. Data Processor

      The natural or legal person, public authority, agency or other body which processes Personal Data on behalf of the Controller, as described in this Privacy Policy.

    6. Data Controller

      The natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of Personal Data, including the security measures concerning the operation and use of this Website. The Data Controller, unless otherwise specified, is the owner of this Website.

    7. Website

      The Website of Controller available underย https://w3f.github.io/Grants-Program/.

    8. Service

      The Services (and blockchain offerings) provided by Controller.

    9. European Union (or EU)

      Unless otherwise specified, all references made within this document to the European Union include all current member states to the European Union and the European Economic Area.

    10. Cookies

      Small sets of data stored in the User's device.

    11. Legal information

      This privacy statement has been prepared based on provisions of multiple legislations, including Art. 13/14 of Regulation (EU) 2016/679 (General Data Protection Regulation).

      This Privacy Policy relates solely to this Website, if not stated otherwise within this document.

    12. Effective date

      This Privacy Notice was created on and has been in effect since the 07.December 2022. We reserve the right, at our complete discretion, to change, modify, add, or remove portions of this Privacy Policy at any time. You should check back periodically at this page to read the most recent version of this Privacy Policy as your continued use of this Website following the posting of changes to these terms will mean you acknowledge these changes.

    - + \ No newline at end of file diff --git a/docs/contribute.html b/docs/contribute.html index 6194908dd52..b119793d6cd 100644 --- a/docs/contribute.html +++ b/docs/contribute.html @@ -4,13 +4,13 @@ ๐Ÿซถ Contribute | Web3 Foundation Grants - +

    ๐Ÿซถ Contribute

    The W3F Grants Program aims to be as open and accessible as possible. If you are interested in contributing or getting involved, there are several ways you can do that:

    We strive to continue improving our grants program and are always open to feedback. If you would like to share any suggestions or criticism, please reach out to us on Github or Matrix!

    - + \ No newline at end of file diff --git a/docs/faq.html b/docs/faq.html index 5a8c6195321..a8af2c8bf71 100644 --- a/docs/faq.html +++ b/docs/faq.html @@ -4,14 +4,14 @@ ๐Ÿ™‹ FAQ | Web3 Foundation Grants - +

    Frequently Asked Questions

    ๐Ÿงญ Generalโ€‹

    How do I apply?โ€‹

    Please refer to the "How to Apply" section in our documentation.

    How much can I ask for?โ€‹

    Generally, there is no upper limit to grant amounts. However, the higher the requested amount, the stricter the review. For guidance, please refer to the grant levels section in our documentation.

    What activities/positions do you fund?โ€‹

    The Web3 Foundation's Grants Program aims to fund software development and research activities that are beneficial for the ecosystem as a whole. As such, we don't usually fund tangential costs such as business-oriented activities (marketing, business planning), events or outreach, andโ€”for non-infrastructure projectsโ€”deployment and hosting costs, maintenance or audits. We also expect you to have a good understanding of the technologies you are planning to use, meaning that we don't fund time spent learning how to use Substrate or how to write ink! smart contracts.

    Can anyone apply?โ€‹

    Projects for which a token sale has been or is being conducted are not eligible for a Web3 Foundation grant. Also, we do not fund projects that actively encourage gambling, illicit trade, money laundering or criminal activities in general. See also the application guidelines in our documentation.

    Can I get an upfront payment?โ€‹

    The W3F Grants Program does not offer upfront payment. If you absolutely require upfront payment, have a look at our list of alternative funding programs, some of which allow upfront payment.

    When do I get paid?โ€‹

    Payments are issued once a milestone has been successfully delivered. Successful delivery requires that you have submitted the milestone as per our delivery guidelines and that the Grants team has reviewed and officially accepted your submission. Payment is made within 14 days after approval.

    Can I reuse someone elseโ€™s open-source code?โ€‹

    Open source software and the Web3 movement are all about collaboration. As long as you meet the codeโ€™s license, we encourage you to find, modify and contribute to already existing libraries and projects if it is of use for your project. However, we expect you to honour other peopleโ€™s work and their right to attribution, and your published code to adhere to the license requirements of the code you are benefiting from. Submitting code as part of a milestone that violates someone elseโ€™s license will result in immediate termination. We will furthermore continue to monitor any repositories you may have submitted as part of a milestone for possible license infringements and reserve the right to terminate the grant if we find you going out of your way to hide external contributions.

    I am starting a company that [...]. I want to use Polkadot/Kusama/Substrate to build a blockchain/parachain and connect [...]. Would I be eligible for a grant?โ€‹

    What the Web3 Foundation is mainly looking for to support are projects "driving advancement and adoption of decentralized software protocols [and] that make it easier for developers to build useful applications using these protocols." As such, we do not award grants to individual companies developing their private infrastructure. However, if part of your work is to build a library or another piece of software that could be of interest to the general Polkadot/Kusama/Substrate ecosystem and ask for funding specific to that, we are happy to look into it.

    My application was rejected. Do you have any recommendations on where to go from here?โ€‹

    We usually give reasons why an application was rejected. We always try to be constructive and work with you towards an application that is beneficial to all parties. If we find no common ground, please have a look at our list of alternative funding opportunities.

    One of your grantees is using my code without respecting the terms of its licenseโ€‹

    Please reach out to us asap.

    Why are other grant applications being accepted faster than mine?โ€‹

    There are many reasons why your application might take longer than others: some applications are straightforward and simple and address an obvious issue, others require deeper understanding and discussion. If your application is highly technical or specialised, we might have to bring in an external evaluator. Sometimes, this specialised evaluator is busy with another evaluation. And sometimes, the committee is simply unsure or not quite convinced.

    ๐Ÿ–Š๏ธ Application Processโ€‹

    How long does it take from application to decision?โ€‹

    Depending on the requested amount, quality of the application and desirability for the ecosystem, a grant application could be approved within a week. Usually, there will be a discussion and requests for changes, additions or improvements. If no one in the committee finds the application approval-worthy or you don't react to our comments, it will be closed after two weeks of inactivity. Very large grants require the approval of the council, which convenes once a month. Thus, once an editor declares your application sufficient, it may take up to one month until a decision is made.

    A W3F member approved my application. Does that mean it is accepted?โ€‹

    Depending on the size of the grant, applications require two to five committee members to approve it. Since we have many different members with different backgrounds and specializations, it is possible that the committee disagrees and your application gets rejected even though one or two members approved it. The application is accepted once the pull request is merged.

    How do I apply if I want to keep information private?โ€‹

    For special cases that do not fit the regular grants structure, we provide a form. You can provide all application data by submitting this form, or submit the form with a reference to a pull request with data you are willing to make public.

    Our application template also offers the possibility to make the application public, but to keep its discussion private.

    ๐Ÿฅณ After Approvalโ€‹

    When can I apply for a follow-up grant?โ€‹

    Anyone who has successfully completed a grant project (i.e. all milestones were accepted, or the previous grant was terminated in mutual agreement) can apply for a follow-up grant. Concurrent grants are only granted in special circumstances.

    Something came up and I cannot finish the project in time. Can we postpone or call off the rest of my project?โ€‹

    The Web3 Foundation reserves the right to terminate an agreement that is behind schedule. However, we are not interested in taking away your grant for any slight hiccup. More often than not, delays are part of the journey and do not constitute a reason for concern. The best way to handle changes in your plans is to get in touch with us. If you would like to prematurely end your work, we can amend your application and remove the milestones you won't be able to complete. If you decide to continue work at a later date, you can always reapply for the remaining milestones and potentially adapt them to take into account any insights you have gained in the meantime.

    Can I list the Web3 Foundation as a partner?โ€‹

    No. Once the grants team has accepted your first milestone, you may display our grants badge in a project-specific context, such as the repository containing the grant project work.

    Can you help me advertise my project?โ€‹

    The Web3 Foundation does not provide PR services to its grantees. However, once per month we co-promote announcements from grants that have delivered a milestone on Twitter. Note that the milestone needs to have been accepted prior to the announcement. Lastly, please observe our announcement guidelines for all grant-related communications. This document also lists an email address through which you can get in touch with our PR team for feedback and in case you have specific questions.

    I found one of my deliverables to be unnecessary, impossible or already done elsewhere. What do I do?โ€‹

    Plans change. If you find parts of your original grant application to be unnecessary or you decide to pivot, but you still want to finish the project: get in touch with us. If your new plans are in line with the Web3 Foundationโ€™s values and the council approves the amendment, you can continue your work. If your plans change significantly or you find yourself not being able to finish the grant, we can mutually agree to terminate the grant early. You are always welcome to reapply another time.

    ๐Ÿšš Milestone Deliveryโ€‹

    How do I submit a milestone?โ€‹

    For details, please refer to the milestone delivery guidelines. Generally speaking, the most important part of a delivery is a list of the same deliverables listed in the application with links to their implementation/realisation (ideally pointing to a specific commit or tag, so you can continue working on your repository without messing up your delivery and complicating our evaluation) and any additional notes you might have. The list of deliverables for each of your milestones should be defined in your grant agreement.

    Can I submit two or more milestones at once?โ€‹

    You can. However, we strongly encourage you to submit your work in increments (milestones), so that you can be sure we didnโ€™t misunderstand (an aspect of) your application, and you didn't make changes to your plan or delivery that would have required a reevaluation of the application.

    Can I add a badge to my repo once Iโ€™ve completed a milestone?โ€‹

    If yours is a Level 2 or 3 grant and your first milestone has been submitted and accepted, yes. Please make sure that you follow the badge guidelines when doing so.

    Why are other milestones being accepted or discussed faster than mine?โ€‹

    While we try to process deliveries chronologically, some milestones aren't processed quite as fast as others. One obvious reason is the complexity of the delivery and its evaluation. Other times, your submission might require internal discussion or delegation. In any case, if you have any question on the processing of your delivery, you can reach out to us via email or Github.

    - + \ No newline at end of file diff --git a/docs/funding.html b/docs/funding.html index 30fbd16d599..62763b135bb 100644 --- a/docs/funding.html +++ b/docs/funding.html @@ -4,13 +4,13 @@ ๐Ÿช™ Alternative Funding | Web3 Foundation Grants - +

    ๐Ÿช™ Alternative Funding

    Some funding sources might be more and some less suitable for your project throughout its various stages. We encourage you to explore alternative funding options listed below. Please note, however, that you should not seek to fund the same scope of work from multiple sources and that any team found doing so will have its Web3 Foundation support terminated.

    tip

    If you are unsure about what's the best next step for you and your project, consider reaching out to the Substrate Square One team.

    Treasuryโ€‹

    The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See:

    Hackathonsโ€‹

    From time to time, Web3 Foundation and/or Parity organise hackathons to promote quick prototyping of Polkadot related ideas. We highly encourage you to participate in these hackathons. Bear in mind, however, that you cannot submit the same work for a hackathon and the Grants Program. If you have worked or are planning to work on a project for a hackathon, your grant application should either propose a different set of features or otherwise build on top of your hackathon work. The same applies in reverse, although that will likely be less common.

    The best way to find out about upcoming hackathons is by following Polkadot on the various social channels, such as Element or Twitter.

    Other Grant or Bounty Programsโ€‹

    Below is a list of other grant and bounty programs in the Polkadot/Substrate ecosystem:

    - + \ No newline at end of file diff --git a/docs/help.html b/docs/help.html index 47750089d6d..e9d30359cf9 100644 --- a/docs/help.html +++ b/docs/help.html @@ -4,13 +4,13 @@ ๐Ÿ’ก Help | Web3 Foundation Grants - +

    ๐Ÿ’ก Help

    Real-time Conversationโ€‹

    We have a Matrix channel for grant-related questions and activities. Head over there to ask grants-related questions, share your experience with other applications and grantees, or simply hang out:

    We also have Matrix/Element channels for real-time discussions on Web3 and Polkadot. Join the conversation!

    Office Hoursโ€‹

    Web3 Foundation Grants Office Hours are a chance to ask the grants team questions regarding a specific (potential) grant application. It offers

    • general guidance regarding the grants program,
    • some quick initial feedback and
    • help how to navigate the ecosystem.

    Apply for Office Hours if you

    • need feedback before submitting an application,
    • want to find out what kind of support there might be available or
    • need help finding the resources you need.

    It is not a chance to pitch your project, especially since only a small subset of the committee will participate in the call. To apply, please fill out the Office Hours โฐ form. Be as specific as possible, so we can help you more quickly. We will get back to you with follow-up questions or a link for booking a timeslot.

    Additional Informationโ€‹

    - + \ No newline at end of file diff --git a/docs/introduction.html b/docs/introduction.html index 30c25f5288e..fe7fb605640 100644 --- a/docs/introduction.html +++ b/docs/introduction.html @@ -4,13 +4,13 @@ Introduction | Web3 Foundation Grants - +

    ๐Ÿ‘‹ Introduction

    As part of our commitment to promoting the Web3 ecosystem, we offer a comprehensive grants program focused on funding software development and research efforts related to Polkadot and Kusama. For more information about the Web3 Foundation, please visit the About page on our website.

    The following pages describe the scope, intentions and processes behind the W3F grants program. Please familiarize yourself and, if you have a project you would like to present, apply!

    - + \ No newline at end of file diff --git a/docs/maintenance.html b/docs/maintenance.html index e939a4a7404..c87b30c6fcc 100644 --- a/docs/maintenance.html +++ b/docs/maintenance.html @@ -4,13 +4,13 @@ ๐Ÿ› ๏ธ Maintenance Grants | Web3 Foundation Grants - +

    ๐Ÿ› ๏ธ Maintenance Grants

    Maintenance Grants are yet another idea to get involved with the Polkadot community. If you are a user of an open-source library that has gone out of date, or you simply want to work on small new features/fix bugs in these repos, we can support your contributions via a grant. We are happy to award rolling grants on a monthly basis, as long as the work done within each time period is performed to a quality standard deemed satisfactory by the grant evaluators.

    Application Processโ€‹

    The process of applying for a Maintenance Grant is similar to what was already outlined above, but instead of defining very detailed deliverables for each milestone upfront, we will ask you to specify, where possible:

    • the repo(s) that need maintenance,
    • outline of why the specific project should continue being supported,
    • broad overview of the features/bugs that need development contributions,
    • an assurance that the current project owners are willing to review/accept your contributions (a note here: if you're fully taking over the project, it would make more sense for the current owners to transfer the repository to your organisation. If you can't get in touch with them, you may, of course, work on a fork), and
    • max budget per month.

    Then, at the end of each month, you will need to provide a comprehensive report of the work done, including the list of issues/bugs/pull requests worked on, time spent on each of these & finally the associated cost. It is quite likely that the time allocation & cost will vary from month to month, depending on the nature of the project you're contributing to. The delivery process and format should follow that of a typical milestone delivery, as will the processing of the payment.

    Notesโ€‹

    • Maintenance grants, as the name suggests, are meant to allow teams/individuals to maintain a certain project, and not to continue its development or implement larger features. Please use the traditional application process for this purpose.
    • The 1-month timeframe is just a guideline. If you find it unsuitable for you or the chosen project for any reason, feel free to adjust as seen fit and point this out in your application.
    • Please bear in mind that the Grants Committee might be stricter in accepting maintainers when compared to typical grants, mostly selecting for applicants with proven experience in the relevant tech stacks.
    • Maintenance Grants are only awarded for fixed timeframes. The requested duration needs to be specified in the application.

    Helpโ€‹

    • For a list of previously accepted maintenance grants, see the applications/maintenance folder in our grants repository.
    • For a list of ways to reach us and ask questions, see our Help page.
    - + \ No newline at end of file diff --git a/docs/process.html b/docs/process.html index 89a5058fc18..fbad61803e6 100644 --- a/docs/process.html +++ b/docs/process.html @@ -4,7 +4,7 @@ Apply | Web3 Foundation Grants - + @@ -46,7 +46,7 @@ click F "Process/how-to-apply" "Apply now" click D "https://wiki.polkadot.network/docs/en/learn-treasury" "https://wiki.polkadot.network/docs/en/learn-treasury" _blank click H "https://www.substrate.io/builders-program/" "https://www.substrate.io/builders-program" _blank

    For a longer list and a description of the programs listed below, check out the Substrate Square One website and our page on alternative funding opportunities.

    - + \ No newline at end of file diff --git a/docs/referral-program.html b/docs/referral-program.html index 66ac2bacfdd..e20de54d233 100644 --- a/docs/referral-program.html +++ b/docs/referral-program.html @@ -4,13 +4,13 @@ ๐Ÿ’ฐ Referral Program | Web3 Foundation Grants - +

    ๐Ÿ’ฐ Referral Program

    We give away 500 USD to each referral of a successful grant application by anyone having previously worked on a Web3 Foundation grant or a Polkadot Ambassador. Web3 Foundation and Parity employees do not qualify for the program, even if they previously worked on a grant.

    In order to be eligible for the referral bonus, the application itself must contain the name of the Polkadot Ambassador or the GitHub account of the grantee as well as the payment address for the referral bonus (see the application template). Payment is made in Bitcoin or USDT/USDC on Polkadot AssetHub.

    - + \ No newline at end of file diff --git a/docs/rfps.html b/docs/rfps.html index d5ae30b5acf..e53f4611c62 100644 --- a/docs/rfps.html +++ b/docs/rfps.html @@ -4,13 +4,13 @@ Requests for Proposals | Web3 Foundation Grants - +

    Requests for Proposals

    โ” What is an RFP?โ€‹

    An RFP (Request for Proposals) is a declaration of interest for others to submit a grant or a treasury application regarding a specific project. They usually revolve around issues that the author (often someone from our team, but anyone can suggest one) deems useful and missing or unsolved in our ecosystem.

    If you find an open RFP here that you think you can address, feel free to submit a grant application. There is a section in our application template where you can reference the RFP you are addressing. Alternatively, you can always submit an on-chain treasury application for an RFP.

    ๐Ÿ“œ List of RFPsโ€‹

    ๐ŸŸข Open: We are looking for (additional) teams to implement this.
    ๐ŸŸก Under Development: One or more teams are working on this. We might be interested in additional implementations, but itโ€™s better to double check this with the grants team.
    ๐Ÿ”ด Closed: This RFP is either closed, on hold, or no longer useful. However, if itโ€™s implemented and not maintained, we might be interested in signing a maintenance grant.
    RFPLast Updated
    a-and-v-topology.md04.09.2023
    alternative-polkadot-js-api-console.md19.05.2023
    appi.md20.07.2021
    bpf-contracts.md06.01.2023
    candle-auction.md02.02.2022
    crowdloan_front_end_template.md25.04.2023
    epassport-zk-validation.md21.03.2023
    grant_management_webapp.md25.09.2023
    ksm-tipping-button.md20.07.2021
    multi-chain-block-explorer.md27.09.2023
    on-chain-quadratic-funding.md29.03.2022
    php-api.md27.05.2022
    php-scale.md23.11.2022
    polkadot-collator-setup.md22.03.2023
    privacy-enhancement-polkadot-extension.md27.09.2023
    scale-codec-comparator.md27.09.2023
    social-recovery-wallet.md03.03.2023
    staking-rewards-collector-front-end.md20.07.2021
    uncollateralized-stablecoin-research.md01.01.2023
    uptane-for-substrate-design-and-scope.md04.03.2023
    validator-selection-algorithm.md25.09.2023
    validator-setup-maintenance.md24.08.2023
    wallet-aggregator-library.md09.03.2023

    ๐Ÿ“ฌ Suggest an RFPโ€‹

    If you think that we should support the development of certain tools or projects (related to Polkadot, Kusama or Substrate) that aren't in the Polkadot/Kusama tech stack, please submit a suggestion using the process described here. We are particularly interested in supporting projects that could be leveraged by other builders in our ecosystem.

    - + \ No newline at end of file diff --git a/docs/suggesting.html b/docs/suggesting.html index 296c32e6a4a..819c4d4e5e1 100644 --- a/docs/suggesting.html +++ b/docs/suggesting.html @@ -4,13 +4,13 @@ ๐Ÿ“ฌ Suggesting a Project | Web3 Foundation Grants - +

    ๐Ÿ“ฌ Suggesting a Project

    If you think that we should support the development of certain tools or projects that aren't in the Polkadot/Kusama tech stack, feel free to submit a suggestion ("Request for Proposal") using the process described below. We are particularly interested in supporting projects that could be leveraged by other builders in our ecosystem.

    For a list of previous Requests for Proposal and their status, see our separate RFP page below.

    Submit an idea:

    If you have an idea for a project or would like to highlight an area in which you'd like to see teams build, but lack the technical background to create a detailed outline, you're welcome to open an issue or add it to the tech stack as a potentially interesting project. We will review your suggestion and, if necessary, will create an RFP based on it and reach out to teams able to build it.

    Submit an RFP (Request for Proposals):

    Ideas generally have better chances of being implemented if they're presented in a project outline format that can be picked up straight away by a team, so if you have a good concept of the milestones required to bring your project to life, you can follow the process below and directly submit an RFP:

    1. Fork this repository.
    2. In the newly created fork, create a copy of the suggestion template (rfps/suggestion-template.md) inside the rfps folder. Make sure you create a new file and copy the contents of the template into the new one, and do not modify the template file directly.
    3. Name the file after your idea: project_name.md.
    4. Fill out the template with the project details. Please include as many details as possible.
    5. Once you're done, create a pull request in our main Grants-Program repository. The pull request should only contain one new fileโ€”the Markdown file you created from the template.
    6. You will see the same template as for creating an application. Please replace it with the RFP PR template.
    7. The RFP will be accepted and merged as soon as it receives three approvals from W3F Grants Committee members.
    - + \ No newline at end of file diff --git a/index.html b/index.html index 2c23a86ae25..466a5dba56b 100644 --- a/index.html +++ b/index.html @@ -4,13 +4,13 @@ Web3 Foundation Grants | Web3 Foundation Grants - +

    Web3 Foundation Grants

    Funding Software Development and Research Efforts related to Polkadot and Kusama.

    ApplyBrowse RFPs

    +

    applications

    +

    projects funded

    +

    countries

    - + \ No newline at end of file diff --git a/search.html b/search.html index 5923131bc16..0620e1ee537 100644 --- a/search.html +++ b/search.html @@ -4,13 +4,13 @@ Search the documentation | Web3 Foundation Grants - +

    Search the documentation

    - + \ No newline at end of file