docs: complete testnet addresses and remove third-party references

- README: show full contract addresses and transaction hashes for the Arc
  x402 and Tempo MPP live tests.
- docs/design.md: remove references to the external capability-token
  reference project; describe the authz-layer design principles in
  LedgerFlow's own terms.
- .gitignore: drop the stale third-party directory exclusion.

Author: Akagi201

.gitignore

@@ -33,7 +33,6 @@ bun.lockb
 # Leptos
 /site/
 .rumdl_cache/
-tenuo/
 x402-docs/
 mutants.out/
 mutants.out.old/

README.md

@@ -77,29 +77,33 @@ a real wallet (OneCipher) signing the payment credentials.
 ### x402 exact (EIP-3009) on Arc Testnet
 
 - **Network**: `https://rpc.testnet.arc.io` (chainId 5042002); native USDC
-  with an ERC-20 interface at `0x3600...` (6 decimals; gas token is the
-  18-decimal native USDC).
+  with an ERC-20 interface at `0x3600000000000000000000000000000000000000`
+  (6 decimals; gas token is the 18-decimal native USDC).
 - **Flow**: merchant issues a 402 `PaymentRequired` (advertising
   `scheme=exact, asset=USDC@eip155:5042002, payTo=merchant`) → OneCipher signs
   an EIP-3009 `TransferWithAuthorization` typed-data message → merchant settles
   on-chain via `transferWithAuthorization`.
-- **On-chain confirmation**: tx `0x38a531c9...` status=0x1 with both
-  `AuthorizationUsed` and `Transfer` (10000 units) events.
+- **On-chain confirmation**: tx
+  `0x38a531c917b44c2bceec7cf9d2bbe9f9a7c8e696fc5bcf4926d9a034038abb5f`
+  status=0x1 with both `AuthorizationUsed` and `Transfer` (10000 units)
+  events.
 - **Signature correctness**: OneCipher's EIP-712 signature is byte-identical
-  to `cast wallet sign --data` (`66a4352d...`), proving standards-compliant
-  EIP-712 signing.
+  to `cast wallet sign --data` (signature prefix `66a4352d...`), proving
+  standards-compliant EIP-712 signing.
 
 ### MPP charge on Tempo Moderato
 
 - **Network**: `https://rpc.moderato.tempo.xyz` (chainId 42431); escrow
-  contract `0xe1c4d3dc...`, pathUSD `0x20c0...`.
+  contract `0xe1c4d3dce17bc111181ddf716f75bae49e61a336`, pathUSD
+  `0x20c0000000000000000000000000000000000000`.
 - **Flow**: server issues a `WWW-Authenticate: Payment` challenge (realm
   "MPP Payment", intent charge, method tempo) → the client signs a TIP-20
   transfer transaction → the server broadcasts a fee-sponsored transaction
   (Tempo type-0x76 with `feePayerSignature` / `feeToken` / `calls`).
-- **On-chain confirmation**: tx `0xa678fb46...` status=0x1, sender is the
-  payer account, 3 logs (2× `Transfer` + fee event), pathUSD balance decreased
-  by exactly 0.01 + a small fee.
+- **On-chain confirmation**: tx
+  `0xa678fb46754092655ef8a3f2587ccfc1c61764ab3b31deb34b88a90190ea5f38`
+  status=0x1, sender is the payer account, 3 logs (2× `Transfer` + fee event),
+  pathUSD balance decreased by exactly 0.01 + a small fee.
 
 Reusable live-test scripts live in [`testnet-tests/`](testnet-tests/); the
 gaps found and fixes applied to the wallet are tracked in

docs/design.md

@@ -107,12 +107,13 @@ services.
 
 ## 3. Research and Benchmarking
 
-### 3.1 Deep Reference: tenuo (Authz-layer template)
+### 3.1 Authz-Layer Design Principles
 
-`/home/akagi201/tmp/tenuo` is the **primary reference** for the Authz-layer
-design, but the protocol and brand are independent (LedgerFlow naming).
+The Authz-layer design builds on well-established capability-token patterns
+(attenuating capability systems and signed-delegation chains) and adapts them
+to payment semantics under the LedgerFlow naming.
 
-| tenuo design | LedgerFlow adoption / adaptation |
+| Established pattern | LedgerFlow adaptation |
 |---|---|
 | Warrant: signed envelope (CBOR payload + Ed25519 signature), UUIDv7 id | adopted; fields redefined for payment semantics (§6.1) |
 | Delegation chain: `parent_hash` cryptographic link + `depth/max_depth`, six invariants I1–I6 | adopted and adapted; **attenuation now uses runtime conjunction** (§6.2), avoiding the undecidable static-subset problem |
@@ -124,10 +125,10 @@ design, but the protocol and brand are independent (LedgerFlow naming).
 | Control/Data plane separation (feature gated) | adopted as deployment modes rather than crate splits (§5.3) |
 | IETF AAT draft alignment | conceptual alignment only; no spec-chasing |
 
-**Deliberately not done** (tenuo has it, LedgerFlow does not need it): 16+
-constraint types, CEL expressions, language-binding matrix (Python/WASM),
-orchestrator, gateway templates. LedgerFlow converges to the minimal complete
-set for payment semantics.
+**Deliberately not done** (other capability systems have it, LedgerFlow does
+not need it): 16+ constraint types, CEL expressions, language-binding matrix
+(Python/WASM), orchestrator, gateway templates. LedgerFlow converges to the
+minimal complete set for payment semantics.
 
 ### 3.2 Protocol Implementation References
 
@@ -330,8 +331,8 @@ sponsorship deferred, extensions frozen):
 
 ### 6.2 Delegation and Attenuation (protocol invariants)
 
-Adopts tenuo I1–I6 adapted for payment semantics; **attenuation uses runtime
-conjunction** (v0.2 revision):
+Defines invariants I1–I6 adapted for payment semantics; **attenuation uses
+runtime conjunction** (v0.2 revision):
 
 | ID | Invariant |
 |---|---|
@@ -355,10 +356,9 @@ conjunction** (v0.2 revision):
 - fail-closed: unknown constraint types, unknown constraint fields, and
   unknown warrant extensions are all rejected.
 
-> Design trade-off note: tenuo implements a full constraint lattice (partial
-> order + monotonic attenuation judgment), but its correctness depends on a
-> decidable subset of a custom DSL and is complex to implement
-> (constraints.rs ~224 KB). LedgerFlow trades static containment for
+> Design trade-off note: a full constraint lattice (partial order +
+> monotonic attenuation judgment) depends on a decidable subset of a custom
+> DSL and is complex to implement. LedgerFlow trades static containment for
 > decidability and interop via runtime conjunction; the cost is the loss of
 > immediate "static rejection of over-limit child at issuance". Since every
 > payment still verifies node-by-node, the security semantics are equivalent
@@ -421,7 +421,7 @@ paymaster (roadmap).
 
 ### 6.5 Approval Gates (m-of-n human approval)
 
-For high-value / high-risk payments (inspired by tenuo approvals):
+For high-value / high-risk payments (m-of-n approval pattern):
 
 ```
 Agent initiates payment (no approval)
@@ -461,7 +461,7 @@ Agent initiates payment (no approval)
 
 ### 6.7 Signatures and Domain Separation
 
-Reuses tenuo's domain-separation idea to prevent cross-purpose replay:
+Uses domain-separated signing to prevent cross-purpose replay:
 
 | Domain prefix | Purpose |
 |---|---|
@@ -816,7 +816,7 @@ persistent implementation lives in `ledgerflow-facilitator` /
 | Clock-skew TTL/PoP bypass | time-server drift | expired tokens replayed | bidirectional clock-tolerance window (§6.3) |
 | MPP session revocation delay | streaming payments | continued consumption inside the pre-revocation window | next-tick effect + active stream close (§6.6) |
 
-### 12.3 Explicitly Not Protected (aligned with tenuo)
+### 12.3 Explicitly Not Protected
 
 - A fully compromised agent process (RCE) — requires sidecar/gateway
   deployment isolation (deployment docs);