Am/example/tvc chainalysis#1
Conversation
…est and deploy commands in README
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub. |
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
richardpringle
left a comment
There was a problem hiding this comment.
Basically all nits. I do think you should consider my comments, but I think it would be better to apply changes in a follow up
| func (c *ChainalysisClient) CheckAddress(ctx context.Context, address string) (*chainalysisResponse, error) { | ||
| if mocked, ok := mockedAddresses[strings.ToLower(address)]; ok { | ||
| return mocked, nil | ||
| } |
There was a problem hiding this comment.
I'm not sure this really matters, but it's a little strange to me that the request either goes to the real Chainalysis OR you get a cached mock-response. I would have a mock-client that gives back 100% mocked responses or a real client, not a combination of the two.
There was a problem hiding this comment.
My thinking here was that I can get mocked responses for two addresses, one sanctioned and one not sanctioned. And any other address would actually attempt to call Chainalysis API. The latter case remained so that I can view the error thrown and in case egress became available, but it was more useful during testing than it is right now. I agree it should be 100% mock response now, and I can always update in the future for egress availability.
| mux.HandleFunc("GET /health", func(w http.ResponseWriter, r *http.Request) { | ||
| w.Header().Set("Content-Type", "application/json") | ||
| w.WriteHeader(http.StatusOK) | ||
| fmt.Fprintln(w, `{"status":"ok"}`) | ||
| }) |
There was a problem hiding this comment.
When I'm looking at examples, I often want to look at the meat of the example and ignore the boilerplate. If would be nice if instead of using a closure here that we just had a func healthcheck.
| if identifications == nil { | ||
| identifications = []Identification{} | ||
| } |
There was a problem hiding this comment.
You could add this normalization to the chainalysis client. It might also be good to add a comment as to why it's needed
| }) | ||
|
|
||
| // Screen an address for sanctions. | ||
| mux.HandleFunc("POST /screen", func(w http.ResponseWriter, r *http.Request) { |
There was a problem hiding this comment.
It would also be good if we had a named function instead of a closure for this
|
|
||
| const ephemeralKeyFile = "/qos.ephemeral.key" | ||
|
|
||
| // QOS derive paths — must match qos_p256/src/lib.rs |
There was a problem hiding this comment.
this should probably be a permalink or a link to the docs:
https://docs.rs/qos_p256/0.10.2/qos_p256/constant.P256_ENCRYPT_DERIVE_PATH.html
| | `TURNKEY_API_PRIVATE_KEY` | Same (shown once on creation) | | ||
| | `TURNKEY_ORG_ID` | Turnkey dashboard → Settings → Organization | | ||
| | `NEXT_PUBLIC_TURNKEY_ORG_ID` | Same as above | | ||
| | `NEXT_PUBLIC_AUTH_PROXY_CONFIG_ID` | See Step 2 below | |
There was a problem hiding this comment.
Why not set up the Auth Proxy before setting the .env file?
| 4. On success `authState` becomes `Authenticated` and the screening tool appears | ||
| 5. Sign-out calls `logout()` from `useTurnkey()` — no server-side session involved | ||
|
|
||
| Authentication is entirely client-side via `@turnkey/react-wallet-kit`. No cookies, no JWTs, no custom session management. |
There was a problem hiding this comment.
Is this a plug? Do we want to link docs for those interested?
| | `0x1da5821544e25c636c1417ba96ade4cf6d2f9b5a` | Sanctioned (OFAC SDN — Secondeye Solution) | | ||
| | `0xffc93b73e5f9fa038598b675ed394faed168688b` | Clean | | ||
|
|
||
| Any other address will attempt the real Chainalysis API call (which will fail inside the enclave until egress is enabled). |
| 3. Paste your operator public key (from `tvc login`) | ||
| 4. Click **Create new TVC App** | ||
|
|
||
| ### Option B — CLI |
There was a problem hiding this comment.
Wait, we shouldn't push the audience to download and build the cli from source if they use the UI. I think we can just point them to the tvc readme for installation here.
There was a problem hiding this comment.
Connected to the earlier comment on the options for installing the tvc CLI, the audience require the CLI to login and obtain the operator key and API public key. I wanted this readme to cover both dashboard and CLI flows originally, but the first step and the approval step require the CLI in either flow.
I am adding a link to the tvc readme in the prerequisites so that the audience is always able to get the current installation instruction.
|
|
||
| --- | ||
|
|
||
| ## Database schema |
There was a problem hiding this comment.
Better to just link to the file here, otherwise it'll be confusing if the file gets updated and this gets out of sync.
adds TVC-Chainalysis Example
Imports a new Turnkey Verifiable Cloud example application:
tvc-chainalysis.This app mocks calls to Chainalysis for OFAC sanctions screening, demonstrating how to run a verifiable screening service on TVC.
Details
tvc-chainalysis/viagit subtree(full history preserved).apps/tvc-app— Go service (the verifiable workload + proof generation)apps/web— Next.js frontend (screening UI, send-ETH flow, proof badge)README.mdis a full walkthrough/guide for building, deploying, and verifying the TVC app