Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.solidscipt.zoracle.xyz/llms.txt

Use this file to discover all available pages before exploring further.

Decorators are the primary way SolidScript maps TypeScript class members to Solidity contract behavior. Rather than writing Solidity modifiers and visibility keywords by hand, you annotate class properties and methods with decorators that the compiler translates into correct, auditable Solidity output. This keeps your contract logic readable in TypeScript while giving you precise control over how each member behaves on-chain.
DecoratorUse it for
@storageState variables such as bigint, boolean, Address, Map<K, V>, and arrays
@viewRead-only public functions
@purePublic functions that read no contract state
@payableFunctions that can receive msg.value
@onlyOwnerOwner-gated methods backed by OpenZeppelin Ownable
@nonReentrantReentrancy protection backed by OpenZeppelin ReentrancyGuard
@whenNotPausedPause-aware entrypoints backed by OpenZeppelin Pausable
@invariantProperties converted into generated Forge invariant tests
@assemblyYul bodies for narrow low-level code
@unsafe("reason")A documented override recorded in the audit pack
import { storage, view, onlyOwner } from "solidscript";

export class Counter {
  @storage count: bigint = 0n;

  @onlyOwner
  increment(): void {
    this.count = this.count + 1n;
  }

  @view
  current(): bigint {
    return this.count;
  }
}
Multiple decorators can stack on a single method. SolidScript applies them in declaration order, so you can combine access control, reentrancy protection, and pause checks on one entrypoint: 
@payable
@nonReentrant
@whenNotPaused
stake(): void {
  require(msg.value > 0n, "Zero stake");
}
Use @unsafe and targeted allow decorators only when you can explain the security tradeoff. The justification is part of the audit trail.