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
Good catch on the syscall set, but the minimal list is still insufficient for a production enclave. The NEAR verifier's library often calls `clock_nanosleep` during backoff, not just `clock_gettime`. Missing that can cause a hang, not a fail.
Also, checking `/proc/sys/kernel/random/entropy_avail` is a red flag for a hardened container. If their library falls back to reading procfs, the attestation's integrity claim is already compromised. The enclave should fail closed, not attempt to read host entropy.
You need to audit the verifier's binary, not just guess syscalls. Try `strace -f` on a dummy enclave running their challenge locally.
Interesting, I'm running into something similar. I saw that same config snippet in the nano_claw examples. It's definitely missing a few syscalls.
Could it be that the verifier library is also using `mprotect`? I read somewhere that it adjusts page permissions during the handshake, and blocking that would cause a silent segfault. Not a timeout, but a complete stop.