Setup
wss://staging.manas-rpc.palliora.org is the confirmed-working endpoint. The SDK’s own default (wss://manas-rpc.palliora.org, no staging. prefix) is not independently confirmed for the full guardian/compute flow. Always pass the staging URL explicitly.
Plain inference, the default starting point
gemma3:1b, deepseek-r1:1.5b, llama3.2:1b, qwen3:0.6b. Any other model submits fine and fails at execution.
Fee rules, read before writing agreement code
A compute agreement clears two independent checks, failing one tells you nothing about the other:- The network’s fee floor.
feesmust clear a formula over live parameters. CallestimateMinFee({ computeRate })first, don’t hardcode a number, it’s root-settable and changes. - Each guardian’s own rate threshold, per compute type. If
computeRateis under a named guardian’s declared minimum, the transaction gets included and then emitsAgreementFailed, nothing is reserved.
compute.agreement does not error, it sits in a future queue indefinitely with no feedback. Name guardians you have reason to believe are actually live (getGuardianAddress(), recent activity).
computeRate must be nonzero on Active/Subscription contracts (ZeroComputeRate otherwise). Only Dormant contracts may have a zero rate.
Threshold-encrypted (private) compute
Needs a 3-guardian group and several crypto helpers (createGuardianGroupAndWatch, testCrypt, gen_stretched_key, encrypt/decrypt, gen_shared_key). See Encrypted Compute for the full worked example before attempting this from scratch, the parameter shapes are large and order-sensitive.
Known gap: there’s no reliable way to look up an arbitrary guardian’s Ed25519 result-decryption key from its address. The publicly-recorded- looking field (staking.guardians(address).pubKey) is actually that guardian’s sr25519 signing key, feeding it to gen_shared_key throws. Use an out-of-band map instead:
Common failures
Full table with more entries: Troubleshooting.