Permissionless-000 or MIP-24

MIPs
1

Problem statement:
In the web3 world, although the base layer is permissionless, decentralised and uncensorable (for those L1s which have a big number of nodes, a good decentralisation and the possibility to run the validators from home) and we have tokens/smart contracts which are running on the chain directly, the frontend and the microservices of those dApps are running on centralised servers.

We know that there is a possibility and there are cases where you have multiple frontends/microservices deployed for the same set of smart contracts, however, the code of those is not verifiable by the user, not always open sourced and frontends/microservices tend to censor access according to law enforcement in general. Like no access to perpetual DEXs in the US, no access to launchpads for some Asian/African countries and all kinds of complications.

Another issue we see is (especially after the ByBit hack) that microservices and frontends can show whatever information they want, the user cannot verify whether those are correct. Although web3 people say that in code we trust, we trust in the closed source frontends/microservices, thus the reputation of the companies running those.

The Solution - permissionless, decentralized, verifiable code everywhere:
The basic idea is to put all the code on the chain. Everything, not stopping at the smart contract level, but frontends and microservice code. But putting the code on a chain is not enough, if the user cannot verify it on his own, on his own device. Executing code in your own device opens up a lot of security issues - like installing keyloggers or sending all your data to Chinese/UK/DE servers. But there is a way for it, and the KEY is WASM - WebAssembly, which by design can be executed in a totally siloed environment, totally sandboxed, without access to anything else, just his own data.

Why WASM? Because of the sandbox execution model and because it works in any phone, any laptop, any PC, microPCs, RaspberryPI and most known hardware. Making it perfect for verifiability, running at the user’s device, giving it clear responses, which cannot be faked. Verifiable LightClients will play a big role in this.

So how do we connect the dots and solve and create a true permisisonless, decentralised and verifiable world on the whole web3 space? Starting from MultiversX, but expanding everywhere.

We need a standard: PERMISSIONLESS-000
Starting from an account based model, where every SmartContract has its own address and its own storage, we can define a clear place where the frontend and microservices could be deployed and held as a WASM binary. We also want to have multiple frontends/microservices for the same smart contract but also different microservices/frontends which incorporate complex systems. Thus a many to many mapping needs to be created which is permissionless and verifiable.

Standard: PERMISSIONLESS-000
Title: On-Chain Verifiable SmartContract-Microservice-Frontend Framework

Objectives:

  • Store all code (SmartContracts, microservices, frontends) as WASM binaries on-chain.
  • Enable a permissionless many-to-many relationship between SmartContracts, microservices, and frontends.
  • Ensure verifiability by allowing users to execute code locally in a sandboxed WASM environment.
  • Eliminate dependency on centralized servers, ensuring censorship resistance and transparency.
  • Leverage light clients for data retrieval and validation.

Guiding Principles

  • Permissionless Registration: Anyone can link their MS or FE to any SC, or their FE to any MS, without owner approval.
  • Validation Without Central Authority: Use decentralized mechanisms (e.g., community signals, code compatibility, user filtering) to validate mappings.
  • Decentralized Trust: Shift trust from owners to the ecosystem and end-users.
  • Objectives
  • Base Layer: Simple, permissionless, on-chain storage and registration of SmartContracts (SCs), microservices (MS), and frontends (FE) with basic validation and compatibility checks.
  • Social Layer: Optional community-driven trust signals (voting, scores) layered on top, without affecting the base functionality.

Core Components

  1. SmartContract (SC) Storage

    • Every SmartContract is deployed to an account-based blockchain (e.g., MultiversX) with a unique address (SC_Address).
    • The SC’s WASM binary is stored in its own storage, accessible via its address.

  2. Microservices and Frontend Storage

    • Microservices and frontends are also WASM binaries, stored on-chain under their own unique addresses (MS_Address for microservices, FE_Address for frontends).
    • Each binary is uploaded permissionlessly by developers, similar to deploying a SmartContract.

  3. Registry SmartContract (RSC)

    • A global, permissionless Registry SmartContract (RSC_Address) maintains the many-to-many mappings between SmartContracts, microservices, and frontends.
    • Anyone can register a microservice or frontend and link it to one or more SmartContracts.
      WASM Execution Environment
    • Users run all WASM binaries (SC, microservices, frontends) locally in a sandboxed environment on their devices.
    • The sandbox ensures no external access (e.g., no network calls beyond blockchain queries, no local file access).

  4. Verifiable Light Clients

    • Light clients fetch on-chain data (WASM binaries, registry mappings, SC state) and validate it using cryptographic proofs (e.g., Merkle proofs).
    • Ensures users interact with untampered code and data.

Data Structures

  1. SmartContract (SC) Storage
    • Address: SC_Address
    • Metadata:
      • SC_WASM: WASM binary.
      • SC_Hash: Hash of the binary.
      • SC_Registry_List: List of linked MS_Address and FE_Address.
      • SC_InterfaceSpec: Optional ABI (e.g., JSON defining functions and data types).
  2. Microservice (MS) Storage
    • Address: MS_Address
    • Metadata:
      • MS_WASM: WASM binary.
      • MS_Hash: Hash of the binary.
      • MS_Registry_List: List of linked SC_Address and FE_Address.
      • MS_InterfaceSpec: Optional spec of inputs/outputs.
  3. Frontend (FE) Storage
    • Address: FE_Address
    • Metadata:
      • FE_WASM: WASM binary.
      • FE_Hash: Hash of the binary.
      • FE_Registry_List: List of linked SC_Address and MS_Address.
      • FE_InterfaceSpec: Optional spec of required data.
  4. Registry SmartContract (RSC) State
    • Stored at RSC_Address:
      • Mapping[SC_Address] → {MS_Addresses, FE_Addresses}: Maps SCs to their microservices and frontends.
      • Mapping[MS_Address] → {SC_Addresses, FE_Addresses}: Maps microservices to SCs and frontends.
      • Mapping[FE_Address] → {SC_Addresses, MS_Addresses}: Maps frontends to SCs and microservices.
      • Version_Hash: A hash of the current registry state for light client verification.
      • Compatibility[Mapping] → Verified/Unverified: Compatibility status for each mapping.

Workflow

1. Deployment

  • SmartContract: A developer deploys a SmartContract to SC_Address, uploading SC_WASM.
  • Microservice: A developer deploys a microservice to MS_Address, uploading MS_WASM.
  • Frontend: A developer deploys a frontend to FE_Address, uploading FE_WASM.
  • All deployments are permissionless and stored on-chain.
  • No Owner Restriction:
    • Anyone can call registerSCtoMS(SC_Address, MS_Address), registerSCtoFE(SC_Address, FE_Address), or registerMStoFE(MS_Address, FE_Address) without signatures or owner approval.
    • The Registry SmartContract (RSC) accepts all registrations permissionlessly and updates the mappings.
  • Many-to-Many Freedom:
    • Any developer can deploy an MS or FE and link it to any existing SC or MS, fostering an open ecosystem.
    • Example: A community member creates an alternative FE for a DEX SC and registers it without needing the DEX SC owner’s consent.

2. Registration

  • Anyone can call the RSC to register relationships:
    • registerSCtoMS(SC_Address, MS_Address): Links a SmartContract to a microservice.
    • registerSCtoFE(SC_Address, FE_Address): Links a SmartContract to a frontend.
    • registerMStoFE(MS_Address, FE_Address): Links a microservice to a frontend.
  • These calls update the RSC’s mappings and the metadata at each address.
    • RSC checks MS_InterfaceSpec against SC_InterfaceSpec (if provided) and records the mapping with Compatibility: Verified/Unverified.
    • Mapping metadata includes DeployerAddress,

3. User Verification and Execution

  • Fetch: A user’s light client queries the chain for:
    • SC_WASM from SC_Address.
    • Associated MS_WASM and FE_WASM via the RSC mappings.
    • Validates all binaries using their hashes (SC_Hash, MS_Hash, FE_Hash).
  • Execute: The user runs:
    • SC_WASM to interact with the blockchain state.
    • MS_WASM to process data or perform computations.
    • FE_WASM to render the UI.
  • All execution occurs in a WASM sandbox on the user’s device (phone, laptop, Raspberry Pi, etc.).
    • RSC mappings with Compatibility, CommunityScore, UsageCount, and DeployerAddress.
  • The user applies filters (e.g., “Compatibility: Verified, UsageCount > 50”) and runs the sandboxed WASM locally.

4. Many-to-Many Flexibility

  • A single SC can link to multiple microservices and frontends.
  • A single microservice can serve multiple SCs or frontends.
  • A single frontend can interface with multiple SCs and microservices.
  • The RSC ensures all mappings are transparent and verifiable.

Security and Verifiability

  1. Sandboxing
    WASM’s siloed execution prevents malicious code from accessing the user’s device or network beyond predefined blockchain APIs.
    Inputs/outputs are restricted to blockchain data and user-provided parameters.
  2. Hash Verification
    Every WASM binary’s hash is stored on-chain and checked by the light client before execution.
    Ensures no tampering by intermediaries.
  3. Light Client Validation
    Light clients fetch data directly from the blockchain (via nodes or peers) and verify it against the Version_Hash of the RSC.
    Eliminates trust in centralized servers.
  4. Open Source Incentive
    While not enforced, developers are incentivized to open-source their WASM code off-chain, as users can inspect and refuse to run unverifiable binaries.

Validation Mechanisms

  • Compatibility Check:
  • Each SC, MS, and FE includes an optional InterfaceSpec field in its metadata:
    • SC_InterfaceSpec: Defines the SC’s ABI (functions, inputs, outputs) as a JSON-like structure.
    • MS_InterfaceSpec: Specifies the data it expects from SCs and outputs it provides.
    • FE_InterfaceSpec: Lists the MS or SC data it consumes.
  • When registering, the RSC optionally checks if MS_InterfaceSpec or FE_InterfaceSpec is compatible with the target SC_InterfaceSpec (e.g., matching function calls or data formats).
  • If incompatible, the mapping is still recorded but flagged as Compatibility: Unverified.

Social Layer: Community Enhancements
This layer builds on the base layer, adding optional trust signals like voting and scores, implemented as a separate system that users can opt into.

Components

  1. Social Registry Contract (SRC)
    Address: SRC_Address (distinct from RSC_Address).
    State:
    • SocialMapping[SC_Address, MS_Address] → {CommunityScore, UsageCount}
    • SocialMapping[SC_Address, FE_Address] → {CommunityScore, UsageCount}
    • SocialMapping[MS_Address, FE_Address] → {CommunityScore, UsageCount}
      Tracks social data for base layer mappings.
  2. Fields
    CommunityScore: Net score from user votes (e.g., +10/-3).
    UsageCount: Number of times the mapping is queried/executed by light clients opting into the social layer.
    DeployerAddress: Added to MS and FE metadata for reputation tracking.

Workflow

  1. Voting
    Function: voteOnMapping(SC_Address, MS_Address, VoteType: Positive/Negative)
    Requires a small stake (e.g., 0.01 EGLD) to vote, locked or slashed for abuse.
    Updates CommunityScore in the SRC.
  2. Usage Tracking
    Light clients opting into the social layer report usage to the SRC (e.g., via a recordUsage(SC_Address, MS_Address) call).
    Increments UsageCount.
  3. User Filtering
    Light clients query both RSC (base layer) and SRC (social layer).
    Apply filters like:
    CommunityScore > 5
    UsageCount > 100
    DeployerAddress in TrustedList
    Optional: Ignore social layer entirely for simplicity.
  4. User-Driven Filtering
    Light Client Role:
    Users fetch all mappings from the RSC but apply filters locally:
    Compatibility: Verified (based on InterfaceSpec).
    CommunityScore > X (e.g., >5).
    UsageCount > Y (e.g., >100).
    DeployerAddress in TrustedList (user-defined whitelist).
    Example: “Show me FEs for this SC with UsageCount > 50 and CommunityScore > 10.”
    Default Recommendations:
    Light clients can default to showing mappings with the highest UsageCount or CommunityScore, while still allowing users to explore unfiltered options.
  5. Anti-Spam Measures
    Economic Cost:
    Retain a small registration fee (e.g., 0.01 EGLD) to deter frivolous mappings.
    Fee is burned or locked, ensuring permissionlessness without owner gatekeeping.
    Rate Limiting:
    Cap registrations per address per epoch (e.g., 10 per day) to prevent mass spam.

Implementation on MultiversX
Account-Based Model: Leverage MultiversX’s account system to assign addresses to SCs, microservices, and frontends.
Storage: Use MultiversX’s key-value storage to hold WASM binaries and metadata.
Gas Costs: Optimize WASM binary size and execution to minimize gas fees (e.g., compress binaries, batch registrations).
Light Clients: Build on MultiversX’s existing node infrastructure to support light client queries.
Expansion to Other Chains
Adapt PERMISSIONLESS-000 to EVM-compatible chains (Ethereum, BSC) by using contract storage instead of account storage.
For Solana, use Program Derived Addresses (PDAs) to store WASM binaries and mappings.

Example Use Case

  1. Perpetual DEX
    • SC_Address: Hosts the DEX’s trading logic.
    • MS_Address: A microservice calculating real-time prices.
    • FE_Address: A frontend displaying the UI.
    • User fetches all three WASM binaries, verifies their hashes, and runs them locally.
    • No censorship possible (e.g., US access restrictions), as everything is on-chain and executed client-side.
  2. Launchpad
    • Multiple frontends (FE_Address1, FE_Address2) link to a single SC for token sales.
    • A microservice (MS_Address) verifies eligibility rules.
    • Users in restricted regions (e.g., Asia/Africa) can still participate by running the code themselves.
  3. DEX Scenario:
    • SC1: A DEX SC deployed by Alice.
    • MS1: A price oracle MS deployed by Bob, registered to SC1 without Alice’s approval.
      Compatibility: Verified (MS1 matches SC1’s ABI).
      CommunityScore: +15 (users vote positively).
      UsageCount: 200 (widely used).
    • FE1: A UI deployed by Charlie, registered to MS1.
      CommunityScore: +8, UsageCount: 50.
    • A spammer registers MS2 to SC1:
      Compatibility: Unverified, CommunityScore: -5, UsageCount: 2.
    • User filters for UsageCount > 100, sees only MS1 → FE1, and executes it.

Benefits
Permissionless: Anyone can deploy and link components.
Decentralized: No reliance on centralized servers.
Verifiable: Users validate all code and data locally.
Censorship-Resistant: Sandboxed execution bypasses regional restrictions.
Scalable: Many-to-many mappings support complex dApps.
Decentralized Validation: Compatibility checks, community voting, and usage metrics validate mappings without central authority.
Trust in Ecosystem: Users rely on collective signals (scores, usage) rather than owner approval.
Flexibility: Developers can innovate freely, linking to any SC or MS.

Challenges and Mitigations
Storage Costs: Large WASM binaries increase gas fees.
Mitigation: Store the microservice/frontend as InscriptionNFT directly on the chain. The big binary will be stored in the passive data of executed transactions and can be fetched through the HASH existing on the InscriptionNFT.

Execution Overhead: Running WASM locally may be slow on low-end devices.
Mitigation: Optimize WASM compilation and provide pre-built binaries for common hardware. The user’s device will keep the used versions and can keep those in Ahead of Time compiled format. No compilation overhead.

User Adoption: Requires users to run light clients.
Mitigation: Develop user-friendly wallets or browser extensions integrating this standard.

Gaming Community Voting:
Risk: Sybil attacks with fake votes.
Mitigation: Require staking with slashing for negative behavior; weight votes by stake size.
Initial Trust Gap:
New mappings start with CommunityScore: 0 and UsageCount: 0, making adoption slow.
Mitigation: Allow deployers to “bootstrap” visibility by open-sourcing code off-chain or integrating with popular wallets.

Complexity for Users:
Filtering options might overwhelm non-technical users.
Mitigation: Pre-configure light clients with sensible defaults (e.g., “Top 5 by UsageCount”).

This PERMISSIONLESS-000 standard creates a truly decentralized web3 ecosystem where trust is placed in code, not companies. Starting with MultiversX, it can expand to any blockchain supporting WASM and light clients. WASM is a must to make the code runnable directly at the user’s device. This will also scale frontends / microservices to all the users horizontally.