← back to build & deploy plan
Decision support · machine-consent onboarding · 3-model panel

How do agents get attested? — (a) vs (b) Two ways an agent gives the consent signature for its Shyft attestation. This decides how agents onboard before they can cite. Panel: Grok + Gemini + Codex.

▲ PANEL 3/3 → RECOMMENDATION (a) · grok 440115b3 · gemini e37e13d6 · codex
The one fact that decides it: Shyft's own code says "smart contracts cannot be consenting constructs" — a contract agent cannot sign its own consent (the ecrecover needs an EOA key). So if your agents are contracts / headless / mass-onboarded → only (a) works. If they're all wallets (EOAs) → either works, (b) is simpler to ship.
(a) MCH-delegated RECOMMENDED
Walkthrough
  1. Operator registers each agent's aux-signer in the MCH (registerExternalAuxSigner(agent, key)).
  2. An off-chain auto-runner holds those keys.
  3. A thin RMT-layer controlling contract (set as primaryMachineConsentHelperAddress) calls setAttestation as the MCH; the auto-runner auto-signs the agent's consent.
  4. Agent is attested without ever transacting → joins trust channel → cites.
UX

Agents need no gas, no key, no interaction. Mass / headless onboarding, fully automated. This is the "generalized trust channel" UX.

What's blocked

Nothing — works for contract agents AND wallets.

Easier / harder
＋ onboarding at scale＋ no per-agent gas/keys－ build a controlling contract－ run + secure the auto-runner keys
(b) Bot self-submit FAST / EOA-ONLY
Walkthrough
  1. Each agent is an EOA funded with USDT0 (gas) + its own key.
  2. Trust Anchor attests it.
  3. The agent itself calls setAttestation / signs its own consent (direct path, line 254).
  4. Agent attested → joins trust channel → cites.
UX

Every agent must be a funded, transacting, signing wallet, self-onboarding one at a time. No operator automation of consent.

What's blocked

Contract agents — entirely. They can't self-consent. Also: no headless/mass onboarding; not automatable.

Easier / harder
＋ no new contract — ships now－ every agent needs gas + key + a tx－ contract-agents impossible－ doesn't scale
▶

If you pick (a): the build (no Shyft-core change)

One thin RMT-layer contract. Per Codex: the current MachineConsentHelper is a pure registry (no setAttestation forwarder), so the new controlling contract must be set as primaryMachineConsentHelperAddress and forward the setAttestation/consent calls (so msg.sender == the MCH) while implementing the aux-signer registry interface. Plus the off-chain auto-runner that holds aux-signer keys. Shyft core stays untouched. It goes through the same CODE_REVIEW + AUDIT gate as everything else.

⚠ One thing to verify first (affects either flow):

Codex flagged a guard at Attestations.sol:234 (consent runs only when userSignatureRS[0] != 0) that looks inverted for fresh consent. Our attest-infra proof test already drives a real attestation → citation successfully, so the path works as-deployed — but I'll confirm the exact line-234 semantics before shipping (a). No core change implied — just verification.

Panel. 3-model architecture review (Grok 440115b3 + Gemini e37e13d6 + Codex), grounded in verified source: Attestations.sol signAttestationUserSignature (line 238 MCH-delegated branch / 254 direct branch / docstring 220), MachineConsentHelper.sol (registry-only), TrustAnchorStorage.sol (setAttestation, primaryMachineConsentHelperAddress). All three: RECOMMENDATION (a).
Not a deploy-blocker. The attestation infra deploys either way; this only sets how agents are onboarded for the citation path. Decision is yours.