home / skills / multiversx / mx-ai-skills / mvx_entry_points

mvx_entry_points skill

/antigravity/skills/mvx_entry_points

This skill identifies and analyzes MultiversX smart contract entry points to reveal attack surfaces and improve security.

npx playbooks add skill multiversx/mx-ai-skills --skill mvx_entry_points

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.9 KB
---
name: mvx_entry_points
description: Identify and analyze MultiversX Smart Contract entry points (#[endpoint], #[view], #[payable]).
---

# MultiversX Entry Point Analyzer

This skill helps you identify the attack surface of a smart contract by enumerating all public interaction points.

## 1. Identification
Scan for `multiversx_sc` macros that expose functions:
- **`#[endpoint]`**: Public write function. **High Risk**.
- **`#[view]`**: Public read function. Low risk (unless used on-chain).
- **`#[payable]`**: Accepts EGLD/ESDT. **Critical Risk** (value handling).
- **`#[init]`**: Constructor.
- **`#[upgrade]`**: Upgrade handler. **Critical Risk** (migration logic).

## 2. Risk Classification

### A. Non-Payable Endpoints
Functions that change state but don't accept value.
- *Check*: Is there `require!`? Who can call this (Owner only?)?
- *Risk*: Unauthorized state change.

### B. Payable Endpoints (`#[payable]`)
Functions receiving money.
- *Check*:
    - Does it use `self.call_value().all()` or `self.call_value().single()`?
    - Is `amount > 0` checked?
    - Are token IDs validated?
- *Risk*: Stealing funds, accepted fake tokens.

### C. Views
- *Check*: Does it modify state? (It shouldn't, but Rust allows interior mutability or misuse).

## 3. Analysis Workflow
1.  **List all Entry Points**.
2.  **Tag Access Control**: `OnlyOwner`, `Whitelisted`, `Public`.
3.  **Tag Value handling**: `Refusable`, `Payable`.
4.  **Graph Data Flow**: Which storage mappers do they touch?

## 4. Specific Attacks
- **Privilege Escalation**: Is a sensitive endpoint accidentally public?
- **DoS**: public endpoint inserting into UnorderedSetMapper (unbounded growth).

## Output Format

### Entry Point Inventory
```
| # | Endpoint | Type | Payable | Access Control | Risk Level | Storage Touched | Location |
|---|----------|------|---------|----------------|------------|-----------------|----------|
| 1 | stake | endpoint | EGLD | Public | Critical | user_stake, total_staked | src/lib.rs:42 |
| 2 | claim | endpoint | No | Public | High | user_rewards | src/lib.rs:87 |
| 3 | set_fee | endpoint | No | #[only_owner] | Medium | fee_percent | src/admin.rs:12 |
| 4 | get_balance | view | No | Public | Low | - | src/views.rs:5 |
| 5 | init | init | No | Deploy only | Critical | all mappers | src/lib.rs:1 |
```

### Attack Surface Summary
```
Total endpoints: [N]
  Critical (payable/init/upgrade): [N]
  High (state-changing, public): [N]
  Medium (state-changing, restricted): [N]
  Low (views): [N]

Unchecked payable endpoints: [list or "none"]
Public state-changing without access control: [list or "none"]
Endpoints missing from Mandos scenarios: [list or "none"]
```

## Completion Criteria
Entry point analysis is complete when:
1. Every `#[endpoint]`, `#[view]`, `#[payable]`, `#[init]`, `#[upgrade]`, and `#[callback]` is in the inventory table.
2. Every entry has a risk classification.
3. Attack Surface Summary is filled.
4. Any endpoint that is payable without token validation is flagged.

Overview

This skill identifies and analyzes MultiversX smart contract entry points to reveal the contract attack surface. It enumerates functions annotated with multiversx_sc macros and classifies risk levels so developers can prioritize fixes. The output is a clear inventory and attack-surface summary for security reviews and audits.

How this skill works

The analyzer scans source files for multiversx_sc macros such as #[endpoint], #[view], #[payable], #[init], #[upgrade], and #[callback]. It lists each entry point, tags access control and payable behavior, maps touched storage mappers, and assigns a risk classification (Critical/High/Medium/Low). It also highlights missing token validation, unchecked payable paths, and endpoints lacking access restrictions.

When to use it

  • Before deployment to identify and harden public interaction points.
  • During security audits to produce a prioritized entry-point inventory.
  • While developing new features to catch accidental public exposure early.
  • When preparing test scenarios (Mandos) to ensure coverage of critical endpoints.
  • After upgrades to validate upgrade handlers and migration safety.

Best practices

  • List every #[endpoint], #[view], #[payable], #[init], #[upgrade], and #[callback] in the inventory.
  • Enforce strict access control on state-changing endpoints (OnlyOwner, role checks).
  • Validate all incoming value and token IDs on payable functions; avoid implicit acceptance.
  • Avoid unbounded storage writes from public endpoints; limit set sizes and validate inputs.
  • Treat init and upgrade handlers as critical: require multi-sig or governance checks.

Example use cases

  • Generate an endpoint inventory table for an upcoming audit with risk tags and storage touched.
  • Find payable functions that accept EGLD/ESDT without token ID validation to prevent fund theft.
  • Detect accidentally public admin or upgrade handlers that enable privilege escalation.
  • Identify public functions that cause unbounded growth (DoS via storage exhaustion).
  • Create a checklist of endpoints missing Mandos scenarios for integration test coverage.

FAQ

What makes a payable endpoint critical?

Payable endpoints handle value transfers; without token validation or proper checks they allow theft or unintended fund acceptance, making them critical.

How are access controls inferred?

The skill looks for explicit guards and common patterns (OnlyOwner annotations, require! checks) and flags endpoints lacking clear restrictions as public.

Does the analyzer detect state changes in views?

It flags views that perform unexpected mutations or use interior mutability patterns, since views should normally be read-only.