Traditional payout systems treat each payment as an isolated transfer. Enterprises do not operate this way. They manage working capital, milestone approvals, vendor delays, reconciliation cycles, and liquidity buffers. Funds sit idle between events.

GigPay models payouts as a capital system rather than a transfer function.

The system works as follows:

• A company funds a treasury vault once.
• The treasury funds multiple escrow intents over time.
• Idle balances are optionally deployed into an ERC4626 yield vault.
• Each escrow has clear ownership of principal and yield.
• Settlement is finalized deterministically through escrow state transitions and support off/on ramps with cross border capabilities.

The result is a programmable treasury rail that is capital-efficient, auditable, and modular.

GigPay consists of three tightly integrated but logically separated layers.

The treasury is the capital root of the system.

Primary contract:

• CompanyTreasuryVault

Responsibilities:

• Hold company working capital (IDRX in the demo deployment).
• Provide funding for escrow intents.
• Route idle liquidity to the yield layer.
• Maintain operator-level access control.

Design principle: The company does not re-fund per payout. It maintains a single onchain treasury balance and allocates from it.

The escrow layer governs payment lifecycle and settlement.

Primary contract:

• GigPayEscrowCoreV2

Escrow lifecycle:

1. Create
2. Fund
3. Submit
4. Release or Refund (terminal states)

Escrow properties:

• Deterministic state machine.
• Explicit custody of principal.
• Optional yield activation for long acceptance windows.
• Settlement is self-contained and final.

Design principle: Escrow is the only component that finalizes payouts.

The yield layer is a separate repository providing a UUPS-upgradeable ERC4626 vault used as the treasury yield buffer.

Primary contracts:

• BaseVaultUpgradeable (ERC4626 proxy)
• VaultStorage
• StrategyRegistry
• RebalanceManager
• WithdrawManager

Responsibilities:

• Deploy idle capital to strategies.
• Enforce debt caps.
• Perform oracle-assisted rebalancing.
• Guarantee deterministic withdrawals via a liquidation queue.
• Protect against share dilution via locked-profit accounting.

Design principle: Yield complexity is isolated from payment logic. The escrow and treasury interact with the yield vault through a narrow adapter boundary.

The system enforces strict ownership boundaries.

While funds are in the treasury:

• Yield belongs to the treasury.

Once principal is committed to escrow:

• Escrow becomes the yield owner for that principal (if escrow yield is enabled).

Settlement rule:

• Treasury yield and escrow yield never mix.
• Yield accounting is finalized during escrow release/refund.
• Principal has exactly one yield owner at any time.

This eliminates cross-contamination between obligations and treasury earnings.

Network: Base Sepolia Explorer: https://base-sepolia.blockscout.com

This section explains the live wiring between deployed contracts.

GigPayRegistry acts as the address resolver.

It stores:

• Active YieldManager
• Active SwapManager
• Other module pointers

Escrow and Treasury never hardcode module addresses. They query the registry.

This enables safe module upgrades.

Flow:

1. Treasury holds IDRX.
2. Treasury calls YieldManagerV2.
3. YieldManager deposits into ERC4626 vault via adapter.
4. ERC4626 vault allocates across strategies.

Connection path:

CompanyTreasuryVault → YieldManagerV2 → Yield Aggregator Adapter → ERC4626 Vault Proxy

Treasury never interacts directly with strategy contracts.

Flow:

1. Operator creates intent via EscrowCore.
2. Treasury funds escrow.
3. Principal custody moves from treasury to escrow.

Connection path:

CompanyTreasuryVault → GigPayEscrowCoreV2

Escrow maintains internal accounting for principal.

If escrow yield is enabled and acceptance window exceeds threshold:

1. Escrow calls YieldManagerV2.
2. Escrow principal is deposited into ERC4626 vault.
3. Yield accrues.
4. On release/refund, escrow withdraws principal + yield.
5. Escrow finalizes settlement.

Connection path:

GigPayEscrowCoreV2 → YieldManagerV2 → ERC4626 Vault

Escrow yield accounting is independent from treasury yield.

Escrow may release with swap.

Connection path:

GigPayEscrowCoreV2 → CompositeSwapManager → SwapRouteRegistry

Swap layer is modular and replaceable without touching escrow logic.

Settlement is always executed via escrow terminal functions:

• release
• releaseWithSwap
• refund

At settlement:

• Principal amount is resolved.
• Yield attributable to escrow is resolved.
• SplitRouter distributes funds.
• State becomes terminal.

No offchain reconciliation is required.

The composed system enforces:

• One principal has one yield owner at a time.
• Treasury yield and escrow yield are never mixed.
• Escrow settlement is self-contained.
• ERC4626 vault cannot exceed strategy debt caps.
• Withdrawals follow deterministic queue liquidation.
• Strategies cannot mutate vault storage.

If any invariant is violated, the architecture is considered broken.

forge test
forge test -vvv

Test categories:

• Unit tests per contract.
• Integration tests for Treasury → Escrow → Settlement flows.
• Invariant tests ensuring no stuck funds and accounting integrity.

Key integration tests:

• Flow.TreasuryToEscrow.Release.t.sol
• Flow.TreasuryToEscrow.Refund.t.sol
• Flow.LongAcceptanceWindow.EscrowYieldThenRelease.t.sol
• Flow.LongAcceptanceWindow.EscrowYieldThenRefund.t.sol
• Invariant.NoStuckFunds.t.sol

Requirements:

• Foundry

forge install
forge build
forge test

Solidity version: 0.8.28 Optimizer enabled with 200 runs.

The protocol contains production-grade modular contract architecture and extensive testing.

The yield layer is upgradeable and isolated from escrow logic.