Real-person video with RealFace

Seedance ships with a server-side filter that refuses prompts naming real people or celebrities. The bypass is a face-reference asset that proves the person being depicted has actively participated in the enrollment (nod + blink liveness from their phone).

The liveness check exists to prevent unauthorized deepfakes — you can't enroll a celebrity from a photo alone, because the live face in the H5 must match the photo you upload. The check is biometric only; it does not collect government identity.

1. Open the studio. Go to /studio/realface and connect your wallet.
2. Provide the face image. Paste a public HTTPS URL to a clear front-facing photo of the person. JPG / PNG / WEBP, under 10 MB.
3. Click "Start enrollment". BlockRun creates an upstream asset group and returns a QR code + verification link. The QR is valid for 120 seconds.
4. Have the real person open the link on their phone. See the next section for the full phone-side walkthrough.
5. Sign payment ($0.011 USDC) to finalize. BlockRun uploads your photo, the upstream service matches it against the live face from the H5, and you get back a ta_… id within seconds.
6. Use it on Seedance. Pass the id as real_face_asset_id on any Seedance 2.0 / 2.0-fast / 2.0-mini video generation. Reusable across unlimited videos.

This is the step that catches most first-time operators off-guard, so here's the literal sequence the rights-holder sees on their phone when they scan the QR or open the link.

The happy path (~60 seconds)

1. Open the link. If they scanned a QR, iOS / modern Android show a banner — tap it. The H5 page loads in their phone's browser. The URL is kyc.byteintl.com — that's our identity-verification partner.
2. Camera permission prompt. The browser asks "Allow camera access?" — they tap Allow. (If they tap Deny, see the alternate path below.)
3. Face alignment. A circle appears with a live camera feed. They position their face inside the circle. Good lighting + neutral expression + no sunglasses / heavy mask. Front-facing.
4. Action prompts. The page says "please nod" then "please blink". They do each action for ~1-2 seconds. Total recording is 2-4 seconds.
5. Wait for "Verification completed". Page shows a green checkmark and "You can close this page now". That's it. They close the tab. No login, no password, no email confirmation.

Alternate path — camera blocked or not available

If the rights-holder can't / won't grant camera permission, the page offers an alternate flow:

1. The page shows "Use the alternate authentication method".
2. It asks them to record a 2-4 second video using the phone's native camera, doing the same nod + blink.
3. They upload the recorded file.
4. BytePlus processes the upload the same way as the live capture — extracts a face frame, runs liveness checks, matches against the photo you provided.

Same end result, just one extra tap and ~30s slower.

Failure modes the rights-holder might see

• "Session expired" — they took longer than 120 seconds and the H5 token timed out. In the operator's studio UI, click Generate fresh QR and try again.
• "Verification failed" — liveness check didn't pass. Common causes: poor lighting, face partially out of frame, didn't complete the action prompt in time. The H5 page typically offers a retry — they can redo the capture in the same session.
• 404 / "Not found" — historically a backend webhook race at our partner. Fixed 2026-05-24. If you see this again, contact support — it's a regression, not user error.

What data leaves the rights-holder's phone

• The live face video (or the alternate uploaded video) → kyc.byteintl.com (the upstream identity service).
• Nothing goes to BlockRun during the phone session. We don't see the video, the camera feed, or any biometric template.
• The upstream service stores enough to perform the face-match against the photo you supply (typically a face embedding, not the raw video). Once the match is decided, your photo is the asset of record — the live video isn't referenced again in subsequent video generations.

No phone? Use a laptop

The H5 link works in any modern browser with a webcam. If the rights-holder doesn't want to use a phone, they can open the link on a laptop and grant the webcam permission. Same flow.

Pass real_face_asset_id on any Seedance 2.0 / 2.0 Fast / 2.0 Mini call. Mutually exclusive with image_url — the asset id IS your first-frame reference.

curl -X POST https://blockrun.ai/api/v1/videos/generations \
    -H "Content-Type: application/json" \
    -H "x-payment: <signed-x402-payload>" \
    -d '{
      "model": "bytedance/seedance-2.0-fast",
      "prompt": "She walks through a neon-lit Tokyo alley, smiling",
      "real_face_asset_id": "ta_a1b2c3d4e5f6g7h8i9j0",
      "duration_seconds": 5
    }'

The response is a job id you poll until the video is ready. Settlement only happens after generation completes — failed generations don't cost USDC.

• Unauthorized celebrities. You can't enroll a person who isn't physically present for the liveness check. The H5 captures their live face and matches it against the photo you upload — there's no way to fake this with a photo alone.
• Trademark / IP characters. RealFace authorizes a real person, not a fictional character or brand. Disney IP, named-character animation, etc. remain blocked.
• Seedance 1.5 Pro. Only Seedance 2.0, 2.0-fast and 2.0-mini accept real_face_asset_id. 1.5 Pro is text/image-only.

The face / liveness data goes from the rights-holder's phone directly to the upstream identity service — it never touches BlockRun servers. We only see:

• The wallet address that signed the x402 payment
• The display name you supplied
• The image URL you supplied (for previewing in your list)
• The resulting ta_… id

That's it. No selfie, no biometric template, no ID document. Mapping of wallet → enrolled ta_… ids is stored in BlockRun's GCS so the dropdown in the video playground can show your enrolled faces.

"QR session expired" before the person finished — click "Generate fresh QR" in the studio. The original group is preserved; only the session token rotates.

"Face-match failed" after upload (HTTP 422) — BytePlus could not verify the photo matches the live face. Common causes: photo lighting / angle differs sharply from the H5 capture, photo is too small or blurry, photo shows multiple faces. Try a clearer single-subject photo. No payment is taken on this failure.

"Group is not active" (HTTP 425) — the rights-holder hasn't completed the H5 yet. Wait for the QR poll to flip to "ready" before clicking finalize. No payment is taken on this either.