# /1 The Genesis – Setting the Stage – Creating the Initial Smart Contract Analyser (Solidsight v1 & v2)

### **Overview**

When I started building **Solidsight**, the idea was straightforward yet ambitious: automate the process of reviewing Solidity smart contracts by leveraging local Large Language Models (LLMs). I envisioned an app that could quickly dissect contracts and produce clear, informative reports detailing their functionality, potential vulnerabilities, and user interactions.

---

### **Building the Core Functionality**

The initial goal was simple: parse Solidity files, generate a detailed functions report, describe the typical user journey, and visualise the function interactions using Mermaid diagrams.

Here’s the basic API interaction function I started with:

```python
pythonCopyEditdef call_llm(prompt):
    headers = {"Content-Type": "application/json"}
    payload = {
        "model": "deepseek-r1",
        "prompt": prompt,
        "temperature": 0.7,
        "max_tokens": 8000
    }
    try:
        response = requests.post(LLM_API_URL, json=payload, headers=headers)
        response.raise_for_status()
        return response.json()["choices"][0]["text"].strip()
    except Exception as e:
        print(f"LLM API call failed: {e}")
        return ""
```

---

### **Challenges Encountered**

The early versions struggled significantly with handling large Solidity files, often hitting token limits or experiencing API timeouts. Error handling at this stage was minimal, causing unexpected failures that required restarting the entire analysis—a frustrating user experience.

### **Reflections and Improvements**

From these initial setbacks, I learned how crucial robust error handling was. Implementing structured error catching and refining my prompts reduced crashes and improved reliability, paving the way for more ambitious developments.

We will stop here, and I’ll see you on the next one.

pxng0lin.