Skip to content

Integrations and automation

Periphery contracts compose ordinary AccountCore and orderbook entrypoints. They do not bypass custody or market authorization. Integrators should prefer the core interfaces for canonical behavior and use periphery contracts only for the UX or automation they explicitly provide.

One-click trading wallets

The EIP-7702 flow delegates immutable KuruTradingWallet logic into a disposable trading EOA. The EOA remains the AccountCore-authorized signer, the EIP-712 verifying contract, the orderbook caller, and the owner of nonce and trigger storage. Immediate actions and trigger creation/cancellation are permissionless to relay; only trigger firing is restricted to the standalone keeper registry.

See one-click trading wallets for enrollment, exact signed types, nonce rules, trigger lifecycle, entrypoints, indexing, and keeper trust.

SpotPeriphery

SpotPeriphery is an immutable, unprivileged facade around one AccountCore:

  • pulls an ERC20 from the caller, approves AccountCore, and deposits it;
  • forwards native MON deposits;
  • can fund a different recipient account without acquiring control over it; and
  • batches read-only estimateSwap calls across markets and fee contexts.

It does not place orders, execute swaps, withdraw assets, or hold a protocol role. Actual orderbook execution still requires the caller to be the account/owner or an AccountCore-authorized TRADE signer.

Call only its deposit functions when sending value. The contract's bare receive() accepts native MON, but there is no rescue or withdrawal function; direct native transfers—and ERC20s sent without the deposit flow—can be stranded.

Builder context

A taker action may name a builder and requested fee PPS. At settlement, AccountCore resolves the account's root, requires a live builder approval, checks the requested rate against the root's maximum and protocol cap, and accrues the resulting fee by asset.

Builder approval is not a trading permission and a builder referral is not an execution-fee approval. Referral tiers only discount protocol maker/taker fees. Integrations should show protocol fee, builder fee, and referral discount as separate concepts.

Post-fill hooks

Hooks are currently Spot-only and configured per maker/account ID on one orderbook. The hook contract is not trusted by the protocol: its callback and returned plan are gas-bounded, decoded, and revalidated by the book. Invalid plans fail open without reverting the triggering fill.

A live partial fill does not call the hook. It is staged when a maker fill clears the resting slot, including a partial fill whose remaining dust is removed at that boundary.

An accepted plan can replenish the filled slot, replace one opposite-side slot with expected-order-ID protection, or do both. In the hook codec only, expected sibling ID 0 skips the sibling identity check; it does not mean “slot must be empty” as it does for signed intents. Refresh orders are post-only and reserve-backed. They may execute later in the same taker action.

There is no dedicated “hook succeeded/failed” event. Accepted actions appear as normal packed book updates; hook-specific observability must come from the hook contract itself.

ExamplePostFillHook demonstrates a four-lane market maker with tight/wide bid/ask slots, owner-managed publishers, dislocation thresholds, and block-based quote freshness. It is example operator infrastructure, not a protocol oracle or privileged implementation. The maker must authorize it for TRADE and register it as the hook.

Integration safety checklist

  • Bind chain ID, verifying contract, account ID, market, signer, authorization epoch, payload hashes, nonce, and deadline in every signed flow.
  • Preserve exact integer units and PPS rounding; never infer human decimals from UI metadata alone.
  • Treat quote views as snapshots and enforce slippage/deadlines on execution.
  • Resolve current route and product type before decoding packed events or calldata.
  • Reconcile AccountCore snapshot events after settlement.
  • Do not treat client order ID, slot index, or trigger condition hash as a canonical fill/order proof.
  • Give each delegated trading EOA only the AccountCore permissions required by its product flow.