Conversation
README.md
Outdated
| # Predicate Registry - Solana Programs | ||
|
|
||
| A comprehensive predicate registry program for managing attestors, policies, and task validation on Solana. This program provides a decentralized way to register attestors, set client policies, and validate tasks with cryptographic attestations. | ||
| A decentralized attestation validation system for Solana programs. The Predicate Registry enables programs to validate off-chain attestations before executing protected operations. |
There was a problem hiding this comment.
While it is deployed / executed on Solana 'decentralized' would infer that any user has access to all functions. This is more of a "Trusted" vs "trustless/decentralized" application given there is a single attester and single Admin
Further (nit)
on line -> online
on chain -> onchain
off chain -> offchain
| - **Signature Verification**: Ed25519 signature validation for attestations | ||
| - **Expiration Handling**: Time-based validation for tasks and attestations | ||
| **1. Predicate Registry Program** | ||
| - Central registry for managing attesters and program policies |
There was a problem hiding this comment.
So the registry is what is implemented by customer Programs right? Hence why It manages policyIDs
There was a problem hiding this comment.
Wonder, if we needed to change the attester address, would this be easily done or would It require every customer to update their programs?
There was a problem hiding this comment.
So this is one major difference currently in Solana vs. EVM. There's not really an "implementation" for customer programs. They will have to call set_policy_id directly on the registry using their program ID. It's basically a manual mapping of programID -> PolicyID. We don't currently have an interface to simplify this.
Wonder, if we needed to change the attester address, would this be easily done or would It require every customer to update their programs?
The attester is set directly on the registry and customer programs are unaffected. I saw this as being something we'd need to update ourselves for the time being.
There was a problem hiding this comment.
Technically a customer program can call set_policy_id via CPI and create their own interface.
README.md
Outdated
| **Why program-based?** | ||
| - Programs like DEXs, DAOs, or games need consistent validation rules for all users | ||
| - Upgrade authorities control program logic and security policies together | ||
| - Simplifies validation: one policy per program instead of per user |
There was a problem hiding this comment.
Applications have compliance policies which users must adhere to
There was a problem hiding this comment.
Sorry, not fully following the suggestion here. Reading it back, I think these bullets may not make a lot of sense though. I might rework it entirely.
README.md
Outdated
| ├── ARCHITECTURE.md # Detailed architecture guide | ||
| └── README.md # This file | ||
| ``` | ||
| A minimal stub program serving as a policy anchor in the registry. |
There was a problem hiding this comment.
We can ride with this but is stub and anchor the best terminology?
There was a problem hiding this comment.
I landed on a "Policy Holding Program" but I'm not attached to It. The sole purpose being folks who do not have the registry integration but want to access the API logically
There was a problem hiding this comment.
(nvm I see It in the below line)
There was a problem hiding this comment.
Yeah, we can definitely change this up, I'm not attached to those terms at all. I'll just note that this isn't actually a product offering, it's just an example of a program that has zero logic but can still be used as a policy ID reference. "Holding Program" is definitely better language from a customer perspective, but "stub" is what it actually is 😅
2 participants
Updates the README to be current with the latest changes to the programs.
Rendered