Contracts and deployments

The X Layer testnet manifest is contracts/deployments/xlayer-testnet.json. It contains the Grantline proxy, internal module proxies and implementations, Vault template, dependency wiring, authority, versions, and runtime code hashes.

Current wiring

Grantline (user-facing facade)
├── GrantlineAdmin (protocol coordinator)
├── MandateRegistry
├── MandateEvaluator
├── EscalationManager
├── VaultExecutor
├── VaultFactory
│   └── Vault proxies
└── Swap adapters (e.g. UniswapV3Adapter)

Arrows show contract dependency or call direction.

The roles are separate so each part has one job:

• Grantline is the stable public entrypoint for controller and agent workflows. It routes all operations to internal modules.
• GrantlineAdmin is a non-upgradeable protocol coordinator. It manages module configuration, module upgrades, Vault template changes, existing Vault upgrades, Vault controller reassignment, and adapter validation. It has no independent owner; its authority derives from Grantline.owner().
• Vault holds native and token capital, exposes controller custody through Grantline, and accepts agent execution only from its configured executor.
• MandateRegistry stores Mandates, lineage, effective rules, nonce usage, and escalation reservations.
• MandateEvaluator reads the registry and returns a structured authorisation result without moving capital.
• EscalationManager stores complete escalated plans, accepts permissionless submission through Grantline, and restricts approval or denial to the current controller.
• VaultExecutor binds the evaluator, escalation manager, registry, and Vault execution path, then translates supported actions (TRANSFER, SWAP) into atomic Vault calls.
• VaultFactory creates Vault proxies, validates implementations, and manages the Vault template.
• Swap adapters (e.g. UniswapV3Adapter) validate and execute token swaps. Adapter support is immutable after one-time module configuration.

Deployment manifests

Each registered Grantline deployment will produce its own table below in the declared order:

After deployment, the verifier checks that the evaluator, escalation manager, executor, factory, Vault proxies, and swap adapters all match the manifest-defined wiring and versions.

Verification before use

Load the contracts environment and run the read-only verification script:

cd contracts
set -a
source .env
set +a
forge script script/VerifyGrantlineDeployment.s.sol:VerifyGrantlineDeployment --rpc-url xlayer_testnet

VerifyGrantlineDeployment checks the expected chain, proxy implementations, runtime hashes, initialiser state, UUPS identifiers, ownership, authority, controller assignments, module wiring, adapter configuration, factory state, and every recorded Vault. A mismatch stops verification instead of allowing an internally inconsistent manifest to look valid.

Updating a deployment

Run DeployGrantline for the fresh Grantline stack, then verify its runtime code and dependency wiring before treating it as current. Update the tracked manifest only after the broadcast succeeds and the resulting addresses, authority, versions, and code hashes have been checked. This ordering keeps a failed or misdirected deployment visible instead of hiding it behind an edited record.

Use the addresses from the current manifest rather than an old integration log. Deployment scripts verify those values, and the relevant network page should be updated whenever the deployment changes.

See X Layer testnet for network-specific details and Enforcement boundary for how the deployed components constrain execution.