Chapter 6: Justification for Using Sovereign AI and LLMs¶

Data Sovereignty in Smart Contract Auditing¶

6.1 Introduction: The Confidentiality Dilemma¶

6.1.1 Nature of Pre-Launch Audit Code¶

The source code of a smart contract before its mainnet deployment represents a particular type of computing asset that combines three characteristics that make it especially sensitive:

First characteristic: Direct economic value. Unlike traditional software, where code has indirect value through the product it produces, a smart contract IS the product. The contract of a DeFi protocol managing 100 million dollars in TVL (Total Value Locked) does not simply "serve to" handle that money: the contract is the mechanism that defines the rules for handling it. Exposing the code before launch allows attackers to prepare exploits that can be executed in the first seconds after deployment.

Second characteristic: Post-deployment immutability. Once deployed on blockchain, a smart contract's code cannot be modified without extraordinary procedures (upgrades requiring governance consensus, or complete protocol forks). This means that a vulnerability detected by an attacker before launch can be exploited indefinitely if the deployed code is identical to what was leaked.

Third characteristic: Temporal competition. In the DeFi ecosystem, the first protocol to implement an innovative mechanism captures most of the market. Leaking an innovative protocol's code allows competitors to launch clones before the original, capturing the market the innovator expected to conquer.

6.1.2 The Problem with Commercial AI APIs¶

The emergence of large language models (LLMs) like GPT-4 and Claude has transformed the possibilities of code analysis. Sun et al. (2024) demonstrated that GPTScan, a tool combining LLM with program analysis, detects 90.2% of business logic vulnerabilities that escape traditional tools. This result is significant because logic vulnerabilities, unlike technical patterns like reentrancy, require semantic understanding of the code's purpose.

However, using these models via commercial APIs implies transmitting source code to third-party servers. Consider the data flow when an auditor uses OpenAI's GPT-4 to analyze a contract:

[Confidential code]
    -> HTTPS to api.openai.com
    -> Servers in Virginia, USA
    -> Processing by model
    -> Storage in logs for 30 days
    -> Possible use for training (per ToS)

Each of these steps introduces risks:

1. Transmission: Traffic, although encrypted, traverses third-party infrastructure. Metadata (source IP, timestamps, payload size) is visible to intermediaries.

2. Jurisdiction: The code becomes subject to US laws, including the CLOUD Act that allows authorities to access data stored by US companies without notifying the owner.

3. Retention: OpenAI's retention policies (30 days for API), Anthropic (30 days), and Google (variable) imply that code remains accessible in their systems long after analysis.

4. Memorization: Carlini et al. (2023) demonstrated that LLMs can memorize and reproduce fragments of their training data. Although commercial APIs have policies not to train with API data, the technical possibility exists.

6.1.3 Risk Quantification¶

Table 6.1 presents a risk value estimate for different types of audited contracts.

Table 6.1. Value at risk by contract type

The common pattern in these incidents is that attackers had time to analyze the code and prepare exploits before or immediately after deployment. If the code had leaked during the audit, the attack preparation time would have been even longer.

6.2 Commercial API Risk Analysis¶

6.2.1 Technical Risks¶

1. Interception in transit

Although HTTPS provides end-to-end encryption, attack vectors exist: - Compromise of certificate authorities (precedent: DigiNotar, 2011) - Man-in-the-middle attacks on corporate networks with SSL inspection - Vulnerabilities in TLS implementations (precedent: Heartbleed, 2014)

For high-value code, these risks are not theoretical but rather vectors that sophisticated actors can exploit.

2. Exposure by provider employees

OpenAI, Anthropic, or Google staff with access to API logs can potentially view client code. Precedents of insider threats at technology companies (Twitter, 2020; Tesla, 2018) demonstrate this risk is real.

3. Model memorization and extraction

Carlini et al. (2023) demonstrated the "memorization attack": through carefully designed prompts, it is possible to extract training data fragments from LLMs. If a model were trained (inadvertently or not) with client code, that code could be subsequently extracted by third parties.

Figure 21. Attack surface in commercial API analysis

+--------------------------------------------------------------------+
|                    ANALYSIS WITH COMMERCIAL API                      |
|                                                                      |
|  [AUDITOR]                                                          |
|      |                                                              |
|      | Confidential                                                 |
|      | source code                                                  |
|      v                                                              |
|  +--------+     +-----------+     +------------+    +---------+    |
|  | HTTPS  |---->| CDN/Edge  |---->|  API GW    |--->| Model   |    |
|  | Client |     | Cloudflare |     | (OpenAI)   |    | GPU     |    |
|  +--------+     +-----------+     +------------+    +---------+    |
|       |              |                  |                |          |
|       v              v                  v                v          |
|   VECTOR 1       VECTOR 2          VECTOR 3         VECTOR 4       |
|   Man-in-        Logs at           Retention       Memorization    |
|   middle         edge nodes        30+ days        in model        |
|                                                                      |
|  Each node represents a potential exposure point                    |
+--------------------------------------------------------------------+

6.2.2 Regulatory Risks¶

1. GDPR (European Union)

Article 44 of GDPR establishes restrictions on personal data transfers to third countries. If source code contains wallet addresses, user-based function names, or any personal data, its transmission to US servers requires specific legal mechanisms (SCCs, Privacy Shield certification, etc.).

2. LGPD (Brazil)

The Lei Geral de Protecao de Dados, in its Article 33, requires that international personal data transfers meet specific conditions that commercial APIs typically do not guarantee for programmatic use.

3. LFPDPPP (Mexico)

The Federal Law for Protection of Personal Data in Possession of Private Parties establishes security obligations that may be compromised when transmitting data to cloud services in third countries.

4. Sector financial regulations

• SOC 2: Requires demonstrable control over sensitive data processing
• PCI DSS: For contracts handling card data, explicitly prohibits certain transfers
• HIPAA: For healthcare contracts, imposes severe restrictions

6.2.3 Economic Risks¶

Table 6.2. Commercial API cost structure (November 2024)

*Estimate for analysis of ~500 line contract with multiple passes

Annual cost projection:

Scenario: Audit team performing 100 monthly audits

Annual cost with GPT-4 Turbo:
100 audits x 12 months x $1.20 = $1,440/year

Plus API key management overhead, rate limits, retries:
$1,440 x 1.5 = ~$2,160/year

Plus pricing change risk (precedent: OpenAI raised prices 3x in 2023):
Contingency reserve: +$500/year

Total estimated cost: ~$2,660/year

Although these costs appear modest, they represent a significant barrier for: - Open source projects without funding - Individual developers in countries with weak currencies - Educational organizations - Academic researchers

6.2.4 Three openness tiers: cost is not binary¶

The "expensive commercial API vs. free local model" contrast hides a third, intermediate tier that is key to the economic argument. Separating the weight license from the access method, the model space sorts into three tiers:

Table 6.2b. Model openness tiers and their measured performance on EVMBench (40 real DeFi audits, 120 HIGH-severity vulnerabilities; single run per model, same pipeline and matcher).

The central finding for this chapter: the open-weight model (DeepSeek-R1, MIT weights) obtains the best precision (88.5%) and best F1 (78.7%) in the whole comparison, at an estimated ~\(0.08 per audit — 15 to 69 times cheaper** than the frontier providers. Its single-pass recall (70.8%) trails the frontier, but a three-pass self-ensemble (≈\)0.24/audit) lifts it to 81.7%, inside the frontier single-run range. The ~$0.08 is **hosting-convenience cost, not a license toll: anyone with a sufficient GPU can run the same weights at zero marginal cost.

The economic conclusion is not "free or very expensive" but a spectrum: paying frontier prices buys no precision/F1 advantage over an open-weight model, and full sovereignty (local tier, $0) is available with a quantified — not assumed — recall drop. Methodology and reproducible sources for these numbers are in docs/methodology/DATASETS.md and Paper 1.

6.3 Solution: Sovereign LLMs with Ollama¶

6.3.1 Data Sovereignty Concept¶

The term "data sovereignty" has multiple meanings in the literature. For the purposes of this work, we adopt the Digital Public Goods Alliance (2023) definition:

"Data sovereignty is the principle that data is subject to the laws and governance structures of the nation or entity where it is generated and processed, and that said entity maintains effective control over its use and distribution."

Applying this principle to smart contract analysis implies that: 1. Source code must not leave infrastructure controlled by the auditor 2. Processing must occur on computational resources under auditor control 3. There must be no transmission to third-party services introducing external jurisdiction

6.3.2 Ollama as Sovereign Backend¶

Ollama is an open source framework that enables running LLMs locally on consumer hardware. Its key features for MIESC are:

1. Completely local execution

The Ollama server listens exclusively on localhost (127.0.0.1) by default. There is no remote server, no data transmission:

# Network binding verification
$ netstat -tlnp | grep ollama
tcp   0   0   127.0.0.1:11434   0.0.0.0:*   LISTEN   12345/ollama

# Verification of outgoing connections during analysis
$ tcpdump -i any "not localhost" during analysis
tcpdump: listening on any
^C
0 packets captured  # ZERO external traffic

2. Models with open weights

Ollama supports models whose weights are public and auditable:

Table 6.3. Models supported by MIESC

The last row is the open-weight hosted tier: open (MIT) weights too large for the test hardware, accessed via a low-cost hosted API (~$0.08/audit). It is the open-weight model with the best precision and F1 in the EVMBench comparison (Table 6.2b).

3. No telemetry

Unlike commercial services, Ollama does not include telemetry code. This is verifiable because the source code is public and auditable:

// No telemetry code exists in ollama/server/routes.go
// No analytics endpoints
// No tracking beacons

6.3.3 MIESC Architecture with Sovereign LLM¶

Figure 22. Analysis architecture with sovereign LLM

100% local infrastructure with zero external traffic

6.3.4 Configuration in MIESC¶

# src/config/llm_config.py
"""
Sovereign LLM configuration for MIESC.

Design prioritizes data sovereignty over performance:
- Only localhost connections
- No fallback to external APIs
- Explicit locality verification
"""

LLM_CONFIG = {
    # Mandatorily local backend
    "backend": "ollama",
    "base_url": "http://localhost:11434",

    # Default model (quality/speed balance)
    "model": "llama3.2:3b",

    # Timeouts
    "timeout": 120,
    "max_retries": 3,

    # Generation parameters
    "temperature": 0.1,  # Low for consistency
    "max_tokens": 4096,
    "top_p": 0.9,

    # Security configuration
    "verify_localhost": True,  # Fail if not localhost
    "allow_external": False,   # NEVER connect to external APIs
    "log_prompts": False,      # Don't persist analyzed code
}

def verify_sovereign_backend() -> bool:
    """
    Verify that the LLM backend is sovereign (local).

    This verification runs on each analysis to guarantee
    there is no misconfiguration leaking code.
    """
    base_url = LLM_CONFIG["base_url"]

    # Whitelist of sovereign hosts
    sovereign_hosts = ["localhost", "127.0.0.1", "::1"]

    from urllib.parse import urlparse
    parsed = urlparse(base_url)

    if parsed.hostname not in sovereign_hosts:
        raise SovereigntyViolation(
            f"LLM backend {parsed.hostname} is not local. "
            f"MIESC requires local LLM for data sovereignty. "
            f"Configure Ollama on localhost:11434"
        )

    return True

6.4 Detailed Technical Justification¶

6.4.1 Capability Comparison: Local vs. Commercial¶

The most frequent objection to local LLMs is that their capability is inferior to frontier commercial models. This section examines to what extent this difference affects the specific use case of smart contract analysis.

Table 6.4. Capability comparison for code analysis

*On RTX 3090 GPU or equivalent

Key observations:

1. For known technical vulnerabilities (reentrancy, overflow, access control), local models achieve performance comparable to commercial ones. This is because these vulnerabilities follow predictable patterns that 7-13B parameter models can learn.

2. For business logic vulnerabilities, commercial models have an advantage. However, this advantage is mitigated in MIESC because:

3. The AI layer is one of seven layers, not the only defense
4. AI findings are correlated with traditional tool findings

5. The human auditor remains the final decision maker

6. Local model speed is frequently superior because there is no network latency or API queues.

6.4.2 Trade-off Analysis¶

Trade-off 1: Capability vs. Sovereignty

The decision to use local LLMs implies accepting lower reasoning capability in exchange for complete data sovereignty. This trade-off is acceptable when:

• The code has significant value (>$10M at stake)
• Regulatory confidentiality obligations exist
• The auditor cannot accept leak risk
• Other MIESC layers compensate for LLM limitations

The trade-off is NOT acceptable when: - The code is already public (post-audit analysis of deployed contracts) - There are no confidentiality restrictions - Maximum business logic detection capability is required

MIESC allows configuring hybrid analyses where traditional layers always run locally, and the AI layer can be configured to use external models only for non-confidential code.

Trade-off 2: Initial cost vs. Operational cost

For organizations performing audits regularly, sovereign LLM has better ROI even ignoring sovereignty benefits.

6.4.3 Limitation Mitigation Strategies¶

1. Multi-layer architecture

Local LLM limitations are mitigated because it operates within a 7-layer architecture where 24 non-LLM tools provide complementary coverage:

def run_comprehensive_audit(contract_path: str) -> AuditReport:
    """
    Comprehensive audit that does not depend exclusively on LLM.

    Even if the local LLM doesn't detect a logic vulnerability,
    other layers may detect related symptoms.
    """
    all_findings = []

    # Layers 1-5: Traditional tools (24 total)
    all_findings.extend(run_static_analysis(contract_path))    # Slither, etc.
    all_findings.extend(run_fuzzing(contract_path))            # Echidna, etc.
    all_findings.extend(run_symbolic(contract_path))           # Mythril, etc.
    all_findings.extend(run_invariant_testing(contract_path))  # Scribble, etc.
    all_findings.extend(run_formal_verification(contract_path))  # SMTChecker, etc.

    # Layers 6-7: Local LLM for semantic analysis
    all_findings.extend(run_llm_analysis(contract_path))  # GPTScan, etc.

    # Deduplication correlates findings from multiple sources
    return deduplicate_and_prioritize(all_findings)

2. Prompts optimized for smaller models

MIESC prompts are designed to maximize effectiveness with 7-8B parameter models:

OPTIMIZED_SECURITY_PROMPT = """
Analyze this Solidity contract for security vulnerabilities.

FOCUS ON THESE SPECIFIC PATTERNS:
1. External calls before state updates (reentrancy)
2. Unchecked arithmetic operations
3. Missing access control on sensitive functions
4. Dangerous delegatecall usage
5. Improper handling of ETH transfers

For each vulnerability found, provide:
- Line number
- Vulnerability type
- Severity (CRITICAL/HIGH/MEDIUM/LOW)
- Brief explanation (1-2 sentences)

CONTRACT:
```solidity
{contract_code}

Respond in JSON format only: {{"vulnerabilities": [...]}} """

The prompt is:
- Specific (exact list of what to look for)
- Structured (clear response format)
- Concise (minimizes context tokens for response)

**3. RAG (Retrieval-Augmented Generation)**

MIESC implements RAG with a local knowledge base of known vulnerabilities:

```python
class LocalRAGEngine:
    """
    Local RAG engine to enrich LLM analysis.

    Knowledge base includes:
    - Complete SWC Registry with examples
    - Historical smart contract CVEs
    - Documented attack patterns
    """

    def __init__(self):
        # Local knowledge base (no internet required)
        self.knowledge_base = load_local_embeddings("data/swc_knowledge.faiss")

    def augment_prompt(self, code: str, base_prompt: str) -> str:
        """
        Enrich prompt with relevant KB context.
        """
        # Search for similar patterns in KB
        similar_vulns = self.knowledge_base.search(code, top_k=3)

        # Add relevant examples to prompt
        context = "SIMILAR KNOWN VULNERABILITIES:\n"
        for vuln in similar_vulns:
            context += f"- {vuln['swc_id']}: {vuln['description']}\n"
            context += f"  Example: {vuln['example'][:200]}...\n"

        return f"{context}\n{base_prompt}"

6.5 Implementation in MIESC¶

6.5.1 Integrated LLM Tools¶

MIESC integrates six LLM-based tools, all configured for local execution:

Table 6.5. LLM tools in MIESC

6.5.2 Base LLM Adapter Implementation¶

# src/adapters/base_llm_adapter.py
"""
Base adapter for sovereign LLM-based tools.

This adapter guarantees that all MIESC LLM tools
use exclusively local backends, with no possibility
of accidental code leakage to external services.
"""

import requests
from typing import Dict, Any, Optional
from abc import ABC, abstractmethod

from src.config.llm_config import LLM_CONFIG, verify_sovereign_backend

class SovereigntyViolation(Exception):
    """Exception for data sovereignty violations."""
    pass

class BaseLLMAdapter(ABC):
    """
    Base adapter guaranteeing sovereign LLM execution.

    All MIESC LLM tools inherit from this class,
    automatically inheriting sovereignty guarantees.
    """

    def __init__(self):
        self.base_url = LLM_CONFIG["base_url"]
        self.model = LLM_CONFIG["model"]
        self.timeout = LLM_CONFIG["timeout"]

        # Critical sovereignty verification
        if not self._verify_sovereignty():
            raise SovereigntyViolation(
                "Cannot initialize LLM adapter: backend is not sovereign"
            )

    def _verify_sovereignty(self) -> bool:
        """
        Verify that LLM backend is local.

        This verification runs:
        1. When instantiating the adapter
        2. Before each analysis call

        Redundancy is intentional: protects against
        runtime configuration changes.
        """
        return verify_sovereign_backend()

    def _verify_ollama_local(self) -> bool:
        """
        Verify Ollama responds and is effectively local.
        """
        try:
            response = requests.get(
                f"{self.base_url}/api/tags",
                timeout=5
            )

            # Verify response comes from localhost
            # (not from a proxy that could forward to external service)
            if response.headers.get("X-Ollama-Version"):
                return True

        except requests.exceptions.ConnectionError:
            raise SovereigntyViolation(
                f"Ollama not running at {self.base_url}. "
                f"Start Ollama with: ollama serve"
            )

        return False

    def generate(self, prompt: str) -> str:
        """
        Generate response from local LLM.

        Analyzed code never leaves the local system.
        """
        # Re-verify sovereignty before each call
        self._verify_sovereignty()

        response = requests.post(
            f"{self.base_url}/api/generate",
            json={
                "model": self.model,
                "prompt": prompt,
                "stream": False,
                "options": {
                    "temperature": LLM_CONFIG["temperature"],
                    "num_predict": LLM_CONFIG["max_tokens"]
                }
            },
            timeout=self.timeout
        )

        if response.status_code != 200:
            raise RuntimeError(f"Ollama error: {response.text}")

        return response.json()["response"]

    @abstractmethod
    def analyze(self, contract_path: str, **kwargs) -> Dict[str, Any]:
        """Specific analysis implementation."""
        pass

6.5.3 Sovereignty Verification¶

MIESC includes a verification script that the auditor can run to demonstrate sovereignty to clients or regulators:

#!/bin/bash
# verify_sovereignty.sh - MIESC Data Sovereignty Verification

echo "+=================================================================+"
echo "|        DATA SOVEREIGNTY VERIFICATION - MIESC                    |"
echo "+=================================================================+"
echo ""

# 1. Verify Ollama only listens on localhost
echo "[1/4] Verifying Ollama network binding..."
OLLAMA_BIND=$(netstat -tlnp 2>/dev/null | grep 11434 || ss -tlnp | grep 11434)
if echo "$OLLAMA_BIND" | grep -q "127.0.0.1:11434"; then
    echo "      OK - Ollama listens ONLY on localhost (127.0.0.1:11434)"
else
    echo "      WARNING: Ollama may be externally exposed"
    echo "      Output: $OLLAMA_BIND"
fi
echo ""

# 2. Monitor traffic during test analysis
echo "[2/4] Monitoring network traffic during analysis..."
timeout 30 tcpdump -c 100 -i any "not host localhost" 2>/dev/null &
TCPDUMP_PID=$!

# Run test analysis
python3 -c "
from src.adapters.gptscan_adapter import GPTScanAdapter
adapter = GPTScanAdapter()
adapter.analyze('contracts/test/TestContract.sol')
" 2>/dev/null

# Verify no external traffic
wait $TCPDUMP_PID 2>/dev/null
if [ $? -eq 0 ]; then
    echo "      OK - ZERO external connections during analysis"
else
    echo "      WARNING - External traffic detected (investigate)"
fi
echo ""

# 3. Verify model location
echo "[3/4] Verifying local model storage..."
if [ -d "$HOME/.ollama/models" ]; then
    MODEL_SIZE=$(du -sh "$HOME/.ollama/models" 2>/dev/null | cut -f1)
    echo "      OK - Models stored locally: $MODEL_SIZE"
    echo "      Location: $HOME/.ollama/models/"
else
    echo "      WARNING - No local models found"
fi
echo ""

# 4. Verify MIESC configuration
echo "[4/4] Verifying MIESC configuration..."
python3 -c "
from src.config.llm_config import LLM_CONFIG, verify_sovereign_backend
print(f'      Backend: {LLM_CONFIG[\"backend\"]}')
print(f'      URL: {LLM_CONFIG[\"base_url\"]}')
print(f'      Allow External: {LLM_CONFIG[\"allow_external\"]}')
if verify_sovereign_backend():
    print('      OK - Configuration is SOVEREIGN')
"
echo ""

echo "+=================================================================+"
echo "|                  VERIFICATION COMPLETED                         |"
echo "+=================================================================+"

6.6 Compliance with Standards¶

6.6.1 Digital Public Goods Alliance (DPGA)¶

MIESC is designed to comply with the nine DPGA standard indicators:

6.6.2 Community Benefits¶

1. Access democratization

Local execution eliminates cost barriers for: - Open source projects without budget - Developers in developing countries - Educational institutions - Academic researchers

2. National technological sovereignty

Government organizations and companies in jurisdictions with data localization requirements can use MIESC without compromising compliance: - No international data transfer - No dependency on foreign services - Total control over processing infrastructure

3. Transparency and auditability

The entire stack is open source and auditable: - MIESC code: Public GitHub - Ollama: Open source (MIT) - Llama models: Public weights and training documentation

6.6.3 Sovereignty as a requirement, not a preference¶

The preceding sections justify open-weight models and local execution by the risks they avoid (confidentiality, jurisdiction) and their cost. That is a correct but incomplete defense: it frames sovereignty as a concession accepted in exchange for security and savings. The stronger argument is the inverse and it is foundational: control over the tool is a first-order requirement of security analysis, and — in light of this work's empirical evidence — it no longer demands sacrificing capability. What is controlled is epistemically superior to what is not, for six convergent reasons. The distinction is not new: Illich (1973) separated convivial tools — those a person masters, inspects, and adapts — from those that dominate the user and create dependency; an opaque security tool that cannot be examined or modified belongs by construction to the second class.

1. Cyberdefense doctrine. Cyberdefense is defined by control and sovereignty over one's own means. Floridi (2020) characterizes digital sovereignty as effective control over the data, software, and processes an organization depends on; delegating security reasoning to an external service cedes exactly that control. Building a defensive tool on a proprietary, foreign- jurisdiction black box is doctrinally self-contradictory: it inserts, at the core of the defensive posture, a dependency and an attack surface the defender neither controls nor can inspect. A sovereign cyberdefense capability requires, by definition, sovereign tooling; delegating security reasoning to an opaque third party subordinates the defensive decision to an external actor.

2. Reproducibility and forensic value. An audit with forensic value must be reproducible: another expert, given the same input, must reach the same result. A versioned, open-weight model executed locally is a freezable, verifiable artifact. A commercial API is a moving target: the provider can silently update the model, change its behavior, or deprecate it (as happened to prior frontier generations). Reproducible forensic evidence cannot be built on an artifact one does not control; sovereignty over the model is therefore a condition of the method's scientific validity, not a luxury.

3. Authorship and accountability. When the human auditor signs a report, they assume authorship and responsibility for its claims. The freedom to study how the program works — freedom 1 of Stallman's (2002) free-software definition — is the technical precondition of that accountability: with open weights the auditor can inspect, attribute, and answer for the analysis; with a black box, the authorship of a finding dissolves into an inscrutable service they can neither examine nor cite precisely. As Winner (1980) observes, artifacts are not neutral: they embody power relations, and a closed model inscribes the provider's authority over that of the human expert in the analysis itself. Accountability requires being able to explain why the tool concluded what it did; a closed model turns that authorship chain into an act of faith.

4. Longevity and non-abandonment. MIT and Apache 2.0 licenses are irrevocable: once published, weights cannot be withdrawn. A proprietary model, by contrast, can be deprecated or discontinued by unilateral provider decision. A reproducible baseline — the foundation of this thesis and its associated papers — cannot depend on a resource a third party can delete.

5. Digital Public Good. MIESC is a Digital Public Goods Alliance candidate. A public good whose core component requires a paid API effectively has a gatekeeper charging a toll: it is not fully public. Open weights and local execution are coherent with the universal-access mission — including researchers, educational institutions, and developers in weak-currency economies — that a commercial service excludes by cost.

6. Empirical parity. The argument above would be idealistic if sovereignty cost capability. This work's evidence shows it does not: on the EVMBench evaluation (§6.2.4, Table 6.2b), the open-weight DeepSeek-R1 obtains the best precision (88.5%) and F1 (78.7%) in the whole comparison — above the frontier providers — at ~$0.08 per audit (15–69× less). The sovereign choice stopped being a sacrifice and became, on the metrics that matter for triage, a dominant one.

Table 6.6 synthesizes the argument in a scorecard: the local tier wins on every sovereignty dimension, the hosted open-weight tier is the balance point (near-full sovereignty, best precision/F1, and minimal cost), and the frontier tier retains an advantage only in single-run recall.

Table 6.6. Sovereignty scorecard by access tier (✓ full · ◑ partial · ✗ absent)

Honest limits. The argument is a spectrum, not an absolute, and its strength depends on acknowledging that. The best open-weight result (DeepSeek-R1, ~671B parameters) was obtained via a hosted API, not fully local execution: its weights are open and self-hostable in principle, but the test hardware cannot run it locally. Full sovereignty — the local 32B model, with no external calls — has a quantified recall cost (59.2% vs the 70.8–82.5% of larger models), partly recoverable via low-cost self-ensemble. Frontier models also retain a single-run recall advantage. The defensible conclusion is not "open always wins" but that control over the tool is obtained without giving up competitive capability, and that each point on the spectrum (hosted frontier, hosted open-weight, local open-weight) offers a measured — not assumed — trade-off between sovereignty, cost, and recall.

6.7 Conclusions¶

6.7.1 Justification Summary¶

The decision to implement sovereign LLMs in MIESC responds to a rigorous risk and trade-off analysis. Its underlying premise (§6.6.3) is that control over the tool is a first-order requirement of security analysis, not a preference: what is controlled — open weights, auditable execution — is doctrinally, scientifically, and epistemically superior to what is not, and this work's evidence shows that sovereignty no longer demands sacrificing capability. The justification is based on:

1. Pre-audit smart contract code has direct and significant economic value. Leaking this code can result in losses of tens or hundreds of millions of dollars.

2. Commercial LLM APIs introduce unacceptable risk vectors for high-value code: transmission to foreign jurisdictions, extended retention periods, possible memorization in models.

3. Open-weight models provide sufficient capability for the security analysis use case, especially within a multi-layer architecture. This is no longer just an expectation: on the EVMBench evaluation (§6.2.4) the open-weight DeepSeek-R1 obtains the best precision (88.5%) and F1 (78.7%) in the whole comparison, above the frontier providers; and a local 32B model reaches 59.2% recall with no external calls.

4. Total cost of ownership of sovereign LLMs is lower than commercial APIs for organizations performing audits regularly. Measured on EVMBench, the open-weight tier costs ~$0.08 per audit (15–69× less than frontier) and the local tier $0, without sacrificing detection precision.

5. Local execution guarantees automatic regulatory compliance with GDPR, LGPD, LFPDPPP and sector regulations.

6. Control is reproducibility, authorship, and longevity. Only a versioned, open-weight model enables reproducible forensic evidence, an authorship chain in which the auditor can answer for their claims, and a baseline no provider can unilaterally deprecate. These three properties — absent by construction in a closed API — are conditions of the scientific and forensic method, not incidental benefits. The honest counterpart is that full sovereignty is a spectrum: the 100%-local tier has a measured recall cost, and the best open-weight result was obtained via a hosted API; control over the tool is preserved across the whole spectrum, with quantified trade-offs among sovereignty, cost, and recall.

6.7.2 Recommendation¶

For smart contract audits handling confidential code with significant economic value:

Using sovereign (local) LLMs is the only option that provides verifiable guarantees of source code confidentiality during the audit process.

Capability limitations compared to commercial models are mitigated through: - Seven-layer architecture with 25 tools - Prompts optimized for smaller models - RAG with local knowledge base - Finding correlation across multiple sources

6.8 Chapter References¶

Carlini, N., et al. (2023). Extracting Training Data from Large Language Models. USENIX Security Symposium.

Digital Public Goods Alliance. (2023). Digital Public Goods Standard. https://digitalpublicgoods.net/standard/

European Parliament. (2016). General Data Protection Regulation (GDPR). Regulation (EU) 2016/679.

Floridi, L. (2020). The fight for digital sovereignty: What it is, and why it matters, especially for the EU. Philosophy & Technology, 33(3), 369-378. https://doi.org/10.1007/s13347-020-00423-6

Illich, I. (1973). Tools for conviviality. Harper & Row.

Meta AI. (2024). Llama 3 Model Card. https://ai.meta.com/llama/

Ollama. (2024). Ollama Documentation. https://ollama.ai/

OpenAI. (2024). API Data Usage Policies. https://openai.com/policies/api-data-usage

Presidencia de la Republica. (2010). Ley Federal de Proteccion de Datos Personales en Posesion de los Particulares (LFPDPPP).

Republica Federativa do Brasil. (2018). Lei Geral de Protecao de Dados (LGPD). Lei n. 13.709.

Stallman, R. M. (2002). Free software, free society: Selected essays of Richard M. Stallman. GNU Press.

Sun, Y., Wu, D., Xue, Y., Liu, H., Wang, H., Xu, Z., Xie, X., & Liu, Y. (2024). GPTScan: Detecting logic vulnerabilities in smart contracts by combining GPT with program analysis. Proceedings of the 46^th International Conference on Software Engineering (ICSE), Article 166. https://doi.org/10.1145/3597503.3623318

Winner, L. (1980). Do artifacts have politics? Daedalus, 109(1), 121-136.

Touvron, H., et al. (2023). LLaMA: Open and efficient foundation language models. arXiv:2302.13971.

Note: References follow APA 7^th edition format. Document updated: 2025-11-29