# Permissionless-000 or MIP-24

**URL:** <https://agora.multiversx.com/t/permissionless-000-or-mip-24/478>\
**Category:** MIPs\
**Created:** [March 5, 2025, 5:27pm UTC](https://agora.multiversx.com/t/permissionless-000-or-mip-24/478 "2025-03-05T17:27:15Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@robert](https://agora.multiversx.com/u/robert)\
**Post date:** [March 5, 2025, 5:27pm UTC](https://agora.multiversx.com/t/permissionless-000-or-mip-24/478/1 "2025-03-05T17:27:15Z")

</div>

**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**

2. **Microservices and Frontend Storage**

3. **Registry SmartContract (RSC)**

4. **Verifiable Light Clients**

**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.