SOLstice

Real-world conditions. On-chain action.

SOLstice is a devnet proof of concept for connecting real-world conditions to Solana escrow. Describe a condition in plain language, review how the app plans to check it, and enable the automation. If the verifier returns true and a funded deal is linked, the Solana program can release the smart contracts in devnet SOL.

Inspiration

Smart contracts can enforce rules, but many agreements depend on events in the real world. We wanted to explore how someone could describe one of those conditions in plain language, verify it using public information, and connect the result to an on-chain escrow.

What it does

SOLstice lets a user describe a condition and generate a plan for checking it. The user can review and edit the plan before enabling it. In our demo, a simulated trigger starts verification.

The server searches public web sources and Reddit results through Firecrawl, then uses Grok to evaluate whether the returned information supports the checks. The frontend receives live condition and verification updates through SpacetimeDB.

If the result is true and a funded deal is linked, a centralized server-side verifier signs a result submission to our Solana program. The Anchor program checks the submitted result and releases the smart contract's native SOL on devnet. If the result is false, the escrow stays locked. If no funded deal is linked, the app reports that no funds moved.

How we built it

We built the web app with Next.js and use SpacetimeDB for live condition, check, evidence, and execution state. Verification requests run through server-side API routes, keeping external service calls out of the database reducers.

The smart contract program is written with Anchor. A configured server-side verifier evaluates the condition and signs the result submission. The frontend does not hold the verifier’s private key or submit the final verification result.

Challenges we ran into

One of our biggest challenges was connecting SOLstice’s programmable condition layer to the Solana escrow contract. Our app can evaluate a plain-language condition, but the Solana program can only act on a result submitted through a transaction. We had to make that handoff work: the verifier signs the result, the program checks it against the deal, and only then can the smart contract release devnet SOL. Getting those pieces to work together—and keeping the off-chain verification separate from the on-chain enforcement—was the hardest part of the build.

Accomplishments that we’re proud of

We’re proud to have built a demo that connects a plain-language condition to a real devnet smart contract flow. It shows the verification result, the Anchor condition check, and the transaction’s actual progress instead of treating verification and payment as one step.

What we learned

We learned that connecting real-world information to a smart contract introduces a trust boundary. The contract can enforce a result on-chain, but it cannot independently prove that the off-chain evidence is true. The verifier and the way its result is authorized are central to how the system works.

What’s next for SOLstice

This is a devnet proof of concept. Next, we would improve authorization and verifier controls, restrict access to condition data, and define a stronger trust model before considering any production use.