Carteira do usuário
Armazena material de assinatura local, apresenta os fatos da transação, aplica verificações locais de risco e assina somente após aprovação do usuário.
A autoridade de assinatura permanece com a pessoa que detém a carteira.
O VelarumPay encaminha e valida solicitações, mas não move chaves privadas para um servidor nem concede a comerciantes e agentes a capacidade de assinar transações do usuário.
Limites centrais
Projetado para reduzir autoridade, não para escondê-la.
A segurança começa definindo o que cada participante pode e não pode fazer.
Platform API
Autentica, valida, encaminha, armazena o estado da solicitação, aplica políticas e sincroniza status. Não assina pelos usuários.
Comerciante ou agente
Cria solicitações e lê o status permitido dentro de um acesso com escopo. Não pode exportar chaves, aprovar nem assinar.
Controles
Estruturado em camadas ao redor do ciclo de vida da solicitação.
Nenhum rótulo isolado torna um pagamento seguro. O produto combina custódia local de chaves, validação determinística, conexões limitadas e revisão explícita pelo usuário.
Custódia local de chaves
Frases de recuperação, chaves privadas e material de assinatura derivado permanecem no dispositivo do usuário.
Aprovação por padrão
Pagamentos reais exigem que o usuário da carteira revise e aprove antes da assinatura local.
Conexões com escopo
As conexões recebem capacidades limitadas e explícitas, e podem ser revogadas.
Expiração
Solicitações e convites têm limites de tempo e não podem permanecer acionáveis silenciosamente para sempre.
Idempotência
As tentativas de criação foram projetadas para não produzir solicitações de pagamento duplicadas.
Histórico de status
O estado da solicitação e os eventos apoiam o diagnóstico sem dar poder de assinatura aos observadores.
Verdade antes da apresentação
Os fatos da cadeia não podem ser substituídos por texto de marketing.
Um contexto de transação pode explicar uma compra. Ele não pode alterar a rede, o ativo, o valor, o destinatário, o contrato ou emissor, o memo ou a taxa em análise.
01
Fatos imutáveis do pagamentoRede, ativo, valor, destinatário, contrato ou emissor, memo e taxa
02
Separar contexto da transaçãoMotivo, evidência, detalhes do pedido e atividade do agente
03
Risco visível de divergênciaAfirmações conflitantes são motivo para parar, não para reinterpretar os fatos
Limites da testnet oficial
A arquitetura de segurança não é um certificado de lançamento.
O Official Testnet continua sujeito a testes em dispositivos, exercícios de implantação, revisão de licenças, revisão jurídica e evidências de release.
Use apenas caminhos de teste e explicitamente habilitadosNão infira segurança de produção, disponibilidade regulatória, suporte de rede, suporte de ativos ou conclusão de auditoria a partir deste site ou de um exemplo de protocolo.
Para usuários da carteira
- Nunca compartilhe uma frase de recuperação nem uma chave privada.
- Verifique o destinatário e a rede exatos.
- Rejeite solicitações inesperadas ou urgentes.
- Use apenas capacidades mostradas como suportadas na sua build.
Para integradores
- Mantenha tokens fora dos logs do cliente e do código-fonte.
- Solicite os escopos mínimos necessários.
- Use strings de valor exatas e idempotência.
- Não coloque material privado ou de assinatura nos metadados.
Encontrou uma preocupação de segurança?
Não inclua segredos nem dados sensíveis de usuários na primeira mensagem. O processo de divulgação coordenada continua fazendo parte da prontidão da testnet oficial.