Smart Contracts

🎯 Three Levels of Smart Contracts

Level Smart Contract Purpose

I Entire platform VotingFactory Version management, templates, licensing

II Community CommunityRegistry Membership, roles, deposits, settings

III Individual poll Poll (created by factory) Specific poll logic, votes, results

Why: security, flexibility, efficiency.

Level	Smart Contract	Purpose
I Entire platform	VotingFactory	Version management, templates, licensing
II Community	CommunityRegistry	Membership, roles, deposits, settings
III Individual poll	Poll (created by factory)	Specific poll logic, votes, results

🧱 Detailed Architecture

1. Platform Smart Contract (VotingFactory)
Single instance for the entire solution

Stores smart contract templates (bytecode)

Allows creation of new CommunityRegistry instances

Handles upgrades (versioning)

Controls who can deploy a Community
VotingFactory (platform)
    │
    ├── template_community_v1 (bytecode)
    │
    ├── template_poll_v1 (bytecode)
    │
    └── deployed_communities: [CommunityRegistry_1, CommunityRegistry_2, ...]
    
2. Community Smart Contract (CommunityRegistry)
A separate smart contract for each Community. Contains:

Organizer deposit (gas budget)

List of administrators (operators who can invite members and create polls)

Member registry (wallet addresses → membership / roles)

List of all polls ever created within this Community

Settings: delegation allowed / default quorum / voting periods
CommunityRegistry (party "United")
    │
    ├── members: { wallet_A: "member", wallet_B: "operator", ... }
    │
    ├── deposit_balance: 500 EUR
    │
    ├── polls: [Poll_1, Poll_2, Poll_3]
    │
    └── settings: { delegation_enabled: true, max_delegation_level: 2, quorum: 50% }
        
3. Poll Smart Contract (Poll)

Each poll is a separate smart contract

Criteria Advantage of this approach

Security High (error in one poll does not affect others)

Ability to delete a poll Easy (by operator)

Transparency (explorer) Each poll has its own identifier → easy to filter

Scalability Unlimited

Audit Each poll can be verified independently

Criteria	Advantage of this approach
Security	High (error in one poll does not affect others)
Ability to delete a poll	Easy (by operator)
Transparency (explorer)	Each poll has its own identifier → easy to filter
Scalability	Unlimited
Audit	Each poll can be verified independently

🧩 Final Architecture Diagram



VotingFactory (platform)  (smart contract level I)
    │
   ...
    │
    │ createCommunity(parameters)
    │
    ▼
    CommunityRegistry (party "United") (smart contract level II)
           │
          ...
           │
           │ createPoll(type: "simple", question: "...", options: [...])
           │
           ▼
           Poll_1  (smart contract level III)
              │
              └── votes: { wallet_A: option_1, wallet_B: option_2 }
          ...
           │
           │ createPoll(type: "delegation", question: "...")
           │
           ▼
           Poll_2 (smart contract level III)
              │
              ├── votes: ...
              │
              └── delegations: { wallet_C: wallet_A, wallet_D: wallet_A }