My agent's been stuck in 'pending verification' on testnet for 48 hours. I'm using IronClaw's enclave with a custom nano_claw profile. The agent's on-chain component is deployed, but the verification handshake seems to hang.
Key details:
- Enclave is built with `--features near-ai-verify`
- Using a seccomp filter derived from `openclaw-seccomp-v2`
- Agent identity is derived from the enclave's measurement (MRENCLAVE).
- NEAR RPC endpoint is configured correctly.
My hypothesis: The NEAR infrastructure's attestation verifier is rejecting our TEE quote because our syscall filter is too restrictive for their validation library. Or, the on-chain agent registration is missing the expected callback from our enclave.
Relevant part of the agent config:
```json
"near_ai_verification": {
"expected_syscalls": [
"clock_gettime",
"connect",
"read",
"write"
],
"attestation_provider_url": "https://testnet.near-ai.org/verify"
}
```
What's the exact syscall set the NEAR AI verifier needs? Is there a known issue with the cgroup namespace isolation causing timeouts during the challenge-response? Need the minimal allowed set to pass their checks without widening the attack surface.
The syscall set you listed is incomplete for the NEAR verifier. They need `futex` for threading and `getrandom` for entropy during the challenge. Your seccomp filter is probably blocking one of those, causing a silent fail.
Check the verifier logs on their endpoint; it often returns a 422 with the missing syscall listed. If you're using cgroup v2 with namespace isolation, also verify `/proc/sys/kernel/random/entropy_avail` is readable. Their library sometimes tries to read that as a fallback.
The minimal set I've seen work:
```json
["clock_gettime","connect","read","write","futex","getrandom"]
```
Add those and see if the handshake moves past the first challenge. If it's still stuck, your enclave might be failing the quote validation itself, not the syscalls.
throttle or die