Attestto

• Name: Attestto
• URL: https://attestto.com/
• Tags: solana-ecosystem
• Category: wallet identity-resolution middleware / credential-wallet interoperability / compliance-oriented trust infrastructure
• Summary: Attestto is identity-resolution and compliance middleware. Its job is to answer what a wallet address maps to — DID, domain, credential wallet, or compliance signal — before some regulated or policy-gated action happens. The notable crypto-native wrinkle is did:sns; otherwise this is mostly trust-routing glue, not a protocol center of gravity.
• What it does:
  • Publishes a wallet-identity resolver that maps a connected wallet to DIDs, domains, KYC or credential signals, and related trust metadata
  • Ships a browser credential-wallet discovery layer so apps can find and verify W3C-style identity-wallet extensions instead of assuming one wallet stack
  • Maintains did:sns, a DID method that binds Solana Name Service names to DID Documents and adds higher-layer hooks for payment and compliance metadata
  • Packages document verification, compliance checks, and approval/governance tooling around that identity layer
  • Extends the stack into treasury and payment workflows with stablecoin- and multisig-oriented operational hooks
• Key claims:
  • The main platform site says Attestto combines identity verification, document signing, treasury management, compliance tooling, and a credential wallet in one stack, including USDC/EURC and Circle-linked payment flows
  • The open site says Attestto is building on W3C and IETF standards and publishes open-source identity infrastructure rather than only a closed SaaS frontend
  • The wallet-identity-resolver README says ordinary wallet connectors stop at returning an address and signer, while Attestto aims to resolve what that address means in institutional or compliance terms
  • The id-wallet-adapter README frames the product as a discovery and verification layer for credential-wallet browser extensions, which is a real interoperability job even if it is still a narrow one
  • The did:sns specification says the method maps SNS aliases to DID Documents and leaves room for Travel Rule and ISO 20022-style attachments above the identifier layer
  • Across the materials, the recurring pitch is not a new base protocol. It is trust middleware that sits between wallet control and institution-facing workflows
• Whitepaper: No canonical standalone Attestto whitepaper or litepaper surfaced in this pass. The clearest current source of truth was the combined platform site, open standards site, and open-source repository network around wallet identity resolution, wallet discovery, and DID specifications; see ../whitepapers/attestto-primary-sources-2026-05-03.md.
• Sources:
  • https://attestto.com/
  • https://attestto.org/
  • https://raw.githubusercontent.com/Attestto-com/identity-resolver/main/README.md
  • https://raw.githubusercontent.com/Attestto-com/id-wallet-adapter/main/README.md
  • https://raw.githubusercontent.com/Attestto-com/did-sns-spec/main/README.md

Internal linkages

• Best upward reads: did-pkh for wallet-linked subject formatting and spruceid for a stronger identity-and-verification middleware stack.

Practical control points

• The leverage is in resolver policy, accepted credential sources, wallet-extension discovery defaults, and whichever compliance mappings downstream apps actually honor.

• So the useful question is not whether Attestto is open. It is who gets to decide what a wallet address means when payments, approvals, or onboarding depend on that answer.

• Last reviewed: 2026-06-04 UTC